AI 系统的性能，不只是“模型跑得快不快”。真正拖慢体验的，通常是 prompt 太长、工具调用太多、上下文反复传、或者本来能异步处理的任务被你写成了同步等待。
本文要点
- 先测 first-token latency、总耗时、工具调用次数、缓存命中率，再谈优化
- 静态前缀适合缓存，交互输出适合流式，非紧急任务适合批处理
- 真正省时间的地方，往往不是模型本身，而是减少重复上下文和重复调用
- 先改最贵的环节，别一上来就盯着“换更强模型”
先测哪几个指标
我现在会先看这几个数：
- 首个 token 出来的时间
- 完整响应结束的时间
- 一次任务里用了多少次工具调用
- prompt 里有多少静态内容可以复用
- 缓存命中了多少
如果这几个指标没测出来，很多“优化”其实只是感觉更快了。
先改最贵的地方
1. 把静态前缀放前面
系统提示、工具定义、规则说明、固定示例，这些内容如果每次都重复传，就很浪费。OpenAI 的 prompt caching 文档明确提到，静态前缀更容易命中缓存，也更省时省钱。
对中级开发者来说，最实际的做法不是研究缓存原理，而是直接问自己：
- 哪些内容每次都一样
- 哪些内容每次才变
- 能不能把前者固定在最前面
2. 交互场景先流式输出
用户正在等的时候，别等模型完整想完再吐结果。OpenAI 的 streaming 文档说得很直接：流式输出可以让你在模型还在生成时就开始处理前半段内容。
这对问答、代码解释、审查建议都很有用。用户看到第一段内容，体验就已经变了。
3. 不着急的任务直接批处理
如果一个任务不需要立刻回应，比如评估、分类、批量摘要、离线整理，直接用 Batch API 比同步请求更合理。OpenAI 官方文档给出的方向很明确：这类任务适合异步批量处理，而且成本更低。
4. 少做重复工具调用
很多 Agent 慢，不是慢在模型，而是慢在每一步都去问一次文件系统、一次数据库、一次搜索接口。能合并的调用尽量合并，能并行的任务尽量并行。
比如：
- 先把同一目录下的文件一次性读完
- 能一起完成的检查不要拆成串行
- 一次能返回多个结果的接口，不要切成多个小请求
一个很实用的判断
如果任务是“人正在等结果”，先想流式和缓存。 如果任务是“结果今天之内出来都行”，先想批处理。 如果任务里有很多互不依赖的子步骤，先想并行。 如果任务里有大段固定上下文，先想缓存前缀。
这个判断比“换哪个模型”更值钱。模型升级当然有帮助，但它通常不是最先该动的地方。
容易踩的坑
只盯模型，不盯工作流
很多人一遇到慢，就想换更强的模型。结果本质问题还在：prompt 还是很长，工具调用还是很多，流程还是一层套一层。
把所有事情都塞进一个大 prompt
大 prompt 看起来像“上下文完整”，实际很容易把成本和延迟一起放大。该固定的内容固定，该变的内容放后面。
不区分在线和离线任务
交互场景和批处理场景应该走不同路径。一个追求感知快，一个追求总体吞吐。不要把这两个目标混在一起。
一个落地清单
如果你现在就要改一个 AI 工作流，我会按这个顺序来：
- 记录当前的 first-token latency 和总耗时。
- 找出最重复的 prompt 前缀。
- 把交互场景改成流式。
- 把非紧急任务改成批处理。
- 减少重复工具调用，能并行的就并行。
- 再考虑换更强的模型。
结语
AI 系统的性能优化，本质上是把“重复、等待、串行”这三件事拆掉。
先测清楚，再改最贵的地方，通常比直接换模型有效得多。