AI使用进阶之七：成本、延迟与模型选型：会用，也要会省
真正会用 AI 的人，不只是知道哪个模型更强，还知道什么时候不该用最强的那个。
控得住效果是一种能力，控得住账单和等待时间，是另一种能力。
先给结论
掌控 AI 使用，最终一定会碰到三个现实问题：
- 太贵
- 太慢
- 太不稳定
而这三个问题，很多时候不是模型本身决定的，而是你的任务拆分、模型路由、上下文长度和调用方式决定的。
模型选型，不是排行榜选型
很多人选模型，第一反应是“哪个更强”。
但实际落地时，更应该问：
- 这个任务真的需要最强模型吗
- 它需要的是推理深度，还是格式稳定
- 它对延迟敏不敏感
- 它是实时任务，还是离线任务
- 它的调用频率高不高
如果这些问题没想清楚，系统通常会既贵又慢。
一个很实用的路由思路
1. 简单任务，用小模型
例如：
- 分类
- 改写
- 提取字段
- 固定模板生成
这类任务常常不需要顶级模型。
2. 复杂判断，用强模型
例如：
- 多条件推理
- 模糊决策
- 复杂计划生成
- 高价值输出审核
这类任务才值得上更强模型。
3. 高价值少量请求，优先质量
如果调用次数少，但每次都重要，那就别省错地方。
4. 高频低风险请求，优先成本
如果一天几万次调用，成本控制往往比单次极致表现更重要。
延迟不是只有“总时间”
对用户体验来说，至少要分三种延迟看：
- 首 token 延迟
- 总生成时长
- 整条工具链完成时长
嵌入式工程师对这个会很有感觉。
因为很多系统不是“最终能出结果就行”，而是“前 500ms 有没有反馈”。
最常见的四个省钱提速动作
1. 减少无效上下文
上下文越长，不一定越好，但几乎一定越贵、越慢。
能摘要就摘要，能裁剪就裁剪，能分层就分层。
2. 拆任务
不要把所有事都丢给一次大调用。
很多时候：
- 小模型先分类
- 强模型再处理少量难例
整体效果会更优。
3. 用缓存、批处理和异步
如果任务不要求立即返回，就别都走实时路径。
OpenAI 现在官方把这些优化手段拆得很清楚：
- Prompt caching
- Batch
- Flex processing
这几类能力都不是“可选锦上添花”，而是成本控制的重要杠杆。
4. 把“看起来慢”和“真的慢”分开
流式输出能显著改善体感延迟。
它不一定减少总计算量，但会让用户更早看到反馈。
一个成熟团队会长期记录什么
- 哪类任务用什么模型
- 每类任务平均 token 成本
- 每类任务首 token 延迟
- 错误率和重试率
- 模型切换前后的收益
这些数据一积累起来，你的选型就不再靠印象。
一句带走
会用模型，是第一层；会选模型、会省成本、会控延迟，是第二层。
AI 应用真正开始成熟，往往就是从“追最强”转向“做权衡”的那一刻。