7.4成本、延迟与吞吐

先给直觉

模型选择不能只看“答得好不好”。

真实产品还要问：

每次回答要花多少钱？
用户要等多久？
同时来 100 个请求会怎样？
成本突然上涨能不能发现？
简单任务有没有必要用最强模型？

一个模型在 Demo 里表现很好，不代表它适合上线。

质量决定它能不能用，成本和延迟决定它能不能持续用。

三个核心指标

成本

成本回答：

完成一次任务要花多少钱？

成本可能来自：

• 输入 Token。
• 输出 Token。
• Embedding。
• 图片、音频、视频处理。
• 工具 API。
• 存储和检索。
• 人工审核。

模型价格变化很快。课程中不写死具体单价，真实项目必须查官方价格。

延迟

延迟回答：

用户从发起请求到得到结果要等多久？

延迟可以拆成：

• 网络请求时间。
• 检索时间。
• 工具调用时间。
• 模型首 token 时间。
• 模型完整输出时间。
• 后处理时间。

流式输出能降低用户感知等待，但不一定降低总耗时。

吞吐

吞吐回答：

系统单位时间内能处理多少请求？

吞吐受影响因素：

• 模型服务限制。
• 并发数量。
• 上下文长度。
• 输出长度。
• 工具调用速度。
• 数据库和向量检索性能。
• 队列和限流策略。

吞吐不足时，少量用户测试没问题，一上线就排队。

图：质量、成本、延迟很难同时拉满，先确定任务最看重哪个顶点，再选模型与参数。

成本估算

成本估算不要从“模型单价”开始，而要从使用场景开始。

需要估算：

项目	示例
日活用户	每天多少人使用
人均请求数	每人每天多少次
单次输入长度	用户问题 + 系统提示 + 检索资料
单次输出长度	回答、总结、报告长度
是否使用 RAG	是否有 Embedding、检索和存储
是否使用工具	搜索、代码执行、转写、图片生成
是否需要人工审核	审核比例和人力成本

基础公式：

每日成本 ≈ 请求次数 × 单次平均成本

单次平均成本要考虑输入、输出和额外服务。

输入成本

输入成本常被低估。

输入不只是用户问题，还包括：

• 系统提示词。
• 历史对话。
• 检索资料。
• 工具返回结果。
• 格式说明。
• 安全规则。

RAG 系统如果每次塞入大量资料，输入 Token 会很快膨胀。

优化方式：

• 缩短系统提示。
• 控制历史对话长度。
• 只检索必要资料。
• 对长文档先摘要。
• 用结构化字段代替长段描述。

输出成本

输出越长，成本越高，延迟也越高。

适合限制输出长度的场景：

• 分类。
• 标签生成。
• JSON 提取。
• 简短答疑。
• 操作建议。

不适合过度限制的场景：

• 教学解释。
• 报告生成。
• 复杂方案分析。

产品要按任务设计输出长度，而不是所有任务都让模型自由发挥。

延迟拆解

用户等待时间通常不只来自模型。

例子：课程问答助手

用户提问
  ↓
权限检查：50ms
  ↓
向量检索：300ms
  ↓
重排：500ms
  ↓
模型首 token：1.2s
  ↓
完整输出：6s
  ↓
引用后处理：200ms

如果只盯模型，就可能忽略检索和重排。

延迟优化要先测量，再优化。

首 token 与总耗时

首 token 时间是用户看到第一个字的时间。

总耗时是完整回答完成的时间。

流式输出适合：

• 长回答。
• 解释型内容。
• 写作辅助。
• 代码生成。

不适合：

• 必须一次性返回 JSON 的接口。
• 需要完整校验后才能展示的高风险结果。
• 批量后台任务。

流式输出改善体验，但不能替代性能优化。

并发与限流

并发是同时处理多个请求。

限流是控制请求进入系统的速度。

没有限流时，可能出现：

• 成本暴涨。
• 服务超时。
• 队列堆积。
• 第三方 API 报错。
• 正常用户被异常请求影响。

常见限流方式：

• 单用户每分钟请求数限制。
• 单团队每日预算限制。
• 高成本功能单独限制。
• 失败重试次数限制。
• 后台任务排队。

限流不是为了为难用户，而是为了让系统不被一波请求打趴。

缓存

缓存适合重复性高的任务。

适合缓存：

• 公共课程问答。
• 固定资料摘要。
• 文档 Embedding。
• 常见概念解释。
• 评估集运行结果。

谨慎缓存：

• 用户隐私内容。
• 个性化建议。
• 权限不同的 RAG 结果。
• 高变化信息。

缓存要考虑权限和过期时间。否则缓存可能把不该给 A 用户看的内容给了 B 用户。

模型路由

模型路由是按任务选择不同模型。

例子：

任务	模型策略
意图识别	小模型或规则
普通知识解释	中等模型
复杂推理	强模型或推理模型
高风险结论	强模型 + 引用 + 人工审核
批量摘要	便宜模型 + 抽样检查

模型路由的目标不是永远省钱，而是让每类任务使用合适资源。

降级策略

当成本、延迟或服务限制出现问题时，需要降级策略。

可选方式：

• 强模型切换到备用模型。
• 长回答改为摘要。
• 同步任务改为后台任务。
• 暂停高成本功能。
• 提示用户稍后重试。
• 只返回资料引用，不生成长答案。

降级要提前设计。出事后临时改，通常比较刺激，像半夜给服务器做急诊。

评估取舍

比较模型时，不要只看质量分。

建议记录：

模型	质量	单次成本	首 token	总耗时	失败率	适用任务
A
B
C

最终选择要结合任务。

低风险高频任务：

• 成本和延迟很重要。

高价值低频任务：

• 质量和可靠性更重要。

实时交互任务：

• 首 token 和稳定性很重要。

后台批处理任务：

• 吞吐和总成本更重要。

常见误区

误区 1：模型越便宜越好

便宜模型如果错误率高，可能带来更多人工审核和用户损失。

误区 2：模型越强越好

简单任务用最强模型，常常是用跑车送外卖。

误区 3：流式输出等于延迟低

流式输出降低等待感，但总耗时可能不变。

误区 4：只看平均延迟

平均值会掩盖长尾问题。少数特别慢的请求也会严重影响体验。

误区 5：上线后再管成本

没有预算和监控，上线后可能很快收到一张很有教育意义的账单。

动手练习

为一个 AI 功能做成本、延迟和吞吐估算。

填写：

项目	内容
功能名称
目标用户
日请求量
单次输入长度
单次输出长度
是否使用 RAG
是否使用工具
可接受首 token 时间
可接受总耗时
高峰并发
成本控制策略
降级策略