成本与延迟纳入评测是什么
质量提升往往有代价：加了示例、加了检索、加了自我检查，token 用量、单请求成本和响应延迟都会上涨。把成本与延迟作为护栏指标和质量一起评审，才能回答「这次改动值不值」。做法是把 token 用量、成本倍率、P95 延迟列进同一张对比表，并事先设上限——超过上限的方案即使质量更高也要协商，而不是默认上线。
基本信息
| 适用平台 | 所有按 token 计费或自建推理的 LLM 应用 |
|---|---|
| 需要记录 | 平均输入与输出 token、单请求成本倍率、P95 延迟 |
| 护栏设置 | 为成本与延迟各设上限，触线时阻断或触发复审 |
| 口径建议 | 同时给出单请求数字与按业务量的月度估算 |
典型使用场景
- 提示改版评审：质量涨了 2 分但成本涨了 70%，需要明确决策依据
- 模型选型：大模型效果更好时，用成本与延迟判断是否只用于高价值链路
- 容量规划：按预期业务量估算月度花费与峰值并发下的排队风险
- 限流设计：为超预算请求设置降级路径（缩短检索、换小模型）
- 对外承诺：向业务方提供延迟与成本的量级预期，避免上线后被动
对比报告字段示例
对比报告字段示例
# 指标 v11 v12 变化
# 主指标 91.5% 93.3% +1.8
# 平均输入 tokens 1180 2140 +81%
# 平均输出 tokens 220 205 -7%
# 单请求成本倍率 1.0x 1.7x +0.7x
# P95 延迟 2.1s 2.6s +0.5s
# 结论：质量提升明显，但成本接近翻倍；需确认业务收益是否覆盖成本护栏指标与处置
| 护栏指标 | 观察口径 | 触线处置 |
|---|---|---|
| 输入 token | 按分位统计，关注长尾 | 裁剪示例或检索片段，压 top_k |
| 单请求成本 | 相对基线的倍率 | 分层处理：高价值链路保留，其余降级 |
| P95 延迟 | 端到端含排队时间 | 拆解 TTFT 与逐 token 耗时后优化 |
| 失败重试成本 | 重试率 × 单次成本 | 减少无效重试，设置重试上限 |
中文与代码场景下按字符估算 token 误差较大，尤其是英文单词、代码符号与中文混排时。成本核算应以分词器实际计数或接口返回的 usage 为准。
成本与延迟要一起看：长输出在质量指标上可能更好，但会同时抬高成本与延迟。若两者的上限不能同时满足，说明需要把任务拆成两步或用不同档位的模型。