速度还是智商？API延迟与成本的三方权衡，90%团队只算了一边

选模型时，大家习惯做一张表：价格、跑分、上下文长度。然后选一个“性价比最高”的。这个流程有个系统性缺陷——它把延迟当成了一个可接受的常量，实际上延迟是用户流失的主因。

延迟不是线性的

先看一组我们统计的交互式产品数据（首字延迟 TTFT 与任务完成率的关系）：

TTFT	用户中途放弃率	连点重试率
< 0.8s	1.2%	0.4%
0.8–1.5s	2.8%	1.1%
1.5–3s	6.4%	3.9%
3–5s	14.7%	11.2%
> 5s	29.3%	22.8%

拐点在 1.5 秒和 3 秒。跨过3秒，放弃率翻倍；跨过5秒，近三成用户直接走掉。

也就是说，延迟的价格不是线性的，是阶梯式的。从1.4秒优化到1.2秒几乎没有意义，从5.2秒优化到2.8秒价值巨大。

三种延迟成分要分开看

很多团队测“延迟”时只测了端到端总时长，结果优化方向搞错。必须拆成三段：

第一段：TTFT（首字延迟）。由输入长度、队列、网络RTT决定。影响用户是否觉得“它开始动了”。 第二段：TPS（输出速度）。由模型规模、推理服务配置决定。影响用户是否觉得“它在流畅输出”。 第三段：总时长。等于 TTFT + 输出token数 / TPS。

三段各自的优化手段完全不同：

• TTFT 高 → 缩短输入、减小系统提示、启用缓存、换更快的区域节点
• TPS 低 → 降低推理精度、换小模型、开启投机解码（speculative decoding）
• 总时长高 → 减少输出token，这往往是最快见效的

第三条被严重低估。实测中，一份输出从 1200 token 压到 600 token，总时长砍掉一半，而质量损失远小于换成小模型。合理的做法是给每个场景定义最大输出预算，并在系统提示中明确要求“先给结论，再给理由，不要复述题目”。

一个可用的加权评分

不要用单一指标排序，用加权分。我们自己在用的公式：

Score = Quality^2 × 0.5
      + LatencyScore × 0.3
      + CostScore × 0.2

三个分项都归一化到 0~1，其中：

• Quality：在你的任务集上的正确率，不是公开跑分。注意用平方——质量不达标时其他两项没有意义。
• LatencyScore：按上面的阶梯做分段映射，而不是线性倒数。1.5秒以内满分，超过3秒线性降到0。
• CostScore：1 - 单条成本 / 预算上限。

权重不是固定的，按场景调：

场景	Quality²	Latency	Cost
实时对话/客服	0.45	0.45	0.10
代码补全	0.35	0.55	0.10
后台批处理	0.65	0.05	0.30
内容生成（非实时）	0.60	0.10	0.30

注意代码补全的延迟权重最高——补全场景下用户容忍度在 500ms 级别，模型再好，慢半秒就没人用。

三个常见的算错

算错一：用平均值代替 P95。 平均值好看但没用。一个 99% 请求 300ms、1% 请求 12 秒的系统，用户体验是灾难。选型时看 P95，最好看 P99。

算错二：忽略输出长度差异。 不同模型的默认啰嗦程度差异巨大。同样任务，A 模型输出 400 token，B 模型 900 token，即使 B 的单价便宜一半，总成本也持平，但延迟翻倍。比较时应当固定输出长度（或用stop序列控制）。

算错三：把限流当过客。 峰值时被限流降级的那部分请求，成本会转移到重试上，实际延迟翻倍。选型时必须测高并发下的表现，而不是单请求跑分。

结论：延迟是可以“买”的

一个务实的判断：如果你的场景是实时交互，延迟预算应该先定，再选模型。

先确定“TTFT ≤ 1.2s，总时长 ≤ 3s”，然后在这个约束下找质量最高的模型，而不是先选最好的模型再去优化延迟。前者是工程问题，后者是无底洞。

三者权衡的本质，是承认你要的不是最强模型，而是在你的延迟约束下最强的模型。这个约束一旦写清楚，选型就从玄学变成了算术。