降低响应时间:优化延迟最有效的着力点
并非每一个拖慢速度的因素代价都相同——模型选择、缓存和流式传输在不同环节、以不同程度影响速度。
延迟不等于成本
本章讨论的是感知到的和实际测得的响应时间——而不是每次请求的价格。两者相关,但并不相同:更换模型可以同时既更便宜又更快,而流式传输只会改变时间上的感受,不会改变成本。
最大的着力点:模型选择
对于许多日常任务而言,像 claude-haiku-4.5 这样更小、更快的模型,响应速度明显快于像 claude-sonnet-5 这样更大的模型——这种差异往往比其他所有优化手段加起来还要大。
限制思考预算(Thinking-Budget)
对于推理模型(Reasoning-Modelle)而言,不受限制的内部思考过程会耗费大量时间,而这些时间对于简单任务来说其实并不需要。为常规任务设置一个较低的思考预算,可以明显节省时间,同时不会明显降低这类任务的回答质量。
提示缓存(Prompt-Caching)与流式传输
提示缓存(Prompt-Caching)可以跳过对重复出现的上下文部分的重新处理,对于较长且重复的提示词,最多可将延迟降低 85%。流式传输不会改变实际的总耗时,但由于文字是逐步可见地生成的,会让人感觉等待时间明显缩短。
精简上下文与并行化
更少的输入和输出 token 意味着更少的计算时间。当存在多个相互独立的请求时,并行处理比按顺序依次处理更能节省等待时间。
示例
在一个典型的客服回答任务中比较四种手段(参考数值): 更换模型(claude-sonnet-5 → claude-haiku-4.5):响应时间缩短约 60%-70% 对重复出现的 8000 token 系统提示词使用提示缓存:被缓存部分的延迟最多缩短 85% 将简单请求的思考预算从“不限”调整为“低”:每次请求节省数秒 开启流式传输:总耗时不变,但第一段可见文字立即出现,而不是要等到最后才出现
🎬 短视频版
降低响应时间:优化延迟最有效的着力点
🛠️ 练习——自己动手试试
在两种不同的延迟设置下,测量同一任务的响应时间。
- 选定一个固定的、中等难度的任务(例如对一段文字做简短摘要)。
- 分别用你能用到的最大模型和一个更小、更快的模型执行该任务,并分别记录得到完整回答所需的时间。
- 用较大的模型再次执行该任务,但这次开启流式传输,并测量出现第一段可见文字所需的时间。
- 将这三个测量结果并排列出。
✅ 自查清单
- ☐ 哪一个单独的手段对缩短总耗时的效果最明显?
- ☐ 尽管总耗时不变,流式传输是否改变了感知到的等待时间?
小测验
流式传输实际上改变了回答的什么?
来源
- Claude Platform 文档:降低延迟(Reducing latency) ↗ platform.claude.com
- Claude Platform 文档:提示缓存(Prompt caching) ↗ platform.claude.com
- Anthropic:提示缓存(Prompt caching,公布 90%/85% 数据的公告) ↗ www.anthropic.com