大模型 API 的速度怎么测？首 token 延迟与输出速度分开看
「哪家更快」这个问题得先拆成两个：多久开始出字（首 token 延迟），和出字有多快（输出速率）。交互式产品在乎前者，批量处理在乎后者，两者的排名经常不一样。
这篇讲怎么自己测，而不是抄别人的跑分——速度受地域、时段、请求结构影响很大，别人的数在你这里通常复现不了。
三个要分开看的指标
首 token 延迟（TTFT）：从发出请求到收到第一个 token 的时间。它决定用户「等了多久才看到反应」，是交互式产品的体感核心。
输出速率（TPS）：每秒生成多少 token。它决定长回答要写多久。
端到端耗时：从发出到完整收完。等于首 token 延迟加上「输出 token 数 ÷ 输出速率」。批量任务只关心这个。
三者的关系决定了优化方向：短回答场景，首 token 延迟占大头，优化它收益最大；长回答场景，输出速率是主导。
怎么设计一次公平的对比
一、固定请求结构。 同样的 system prompt、同样的输入长度、同样的 max_tokens。输入长度对首 token 延迟影响很大，长度不一致的对比毫无意义。
二、覆盖你的真实长度分布。 至少测三档：短输入短输出、长输入短输出、短输入长输出。三档的排名可能完全不同。
三、多次采样看分位数。 单次测量的噪声很大。每档跑至少几十次，看 P50 和 P95，别看单次或平均值——用户体验由 P95 决定。
四、同一时段测。 不同时段的服务端负载不同，早上测 A、晚上测 B 得出的结论不可信。交叉轮询是更好的做法：A、B、A、B 交替发，把时间因素摊平。
五、从部署环境测。 从你的服务器测，不是从本地笔记本。网络路径不同，结果可能差很远。
六、区分流式与非流式。 首 token 延迟只有流式才测得到。非流式调用只能测端到端。
影响速度的五个变量
一、输入长度。 输入越长，首 token 延迟越高——模型要先把输入全部处理完才能开始生成。这是长上下文的隐性代价之一。
二、缓存命中。 命中的前缀不用重算，首 token 延迟会明显下降。所以开了缓存之后重测速度，数字会好看不少，这也是缓存被低估的一个收益。
三、输出长度。 直接决定端到端耗时。max_tokens 设大且模型真写满时，耗时线性上升。
四、模型档位。 轻量档通常更快。如果你的场景对延迟敏感而对能力要求不高，小模型可能在两个维度上都赢。
五、并发压力。 你自己的并发过高时，请求要排队，端到端耗时里包含了等待时间。测速度时要区分「模型慢」和「排在队里」——见大模型 API 的并发怎么规划。
别忽略稳定性
平均速度快但偶尔卡很久，体验往往比稳定的中等速度更差。所以测试报告里除了 P50，一定要有 P95 甚至 P99。
一个实用的判断：P95 与 P50 的比值。比值接近 1 说明稳定；比值很大说明有长尾，用户会周期性地遇到「今天怎么这么慢」。长尾通常来自服务端负载波动、网络抖动或你自己的排队。
速度和成本要一起看
更快通常意味着更贵，但不绝对。实际决策里建议算一个综合指标：达到可接受体验的最低成本。
具体做法：先定一个体验底线（比如首 token 延迟 P95 不超过某个值），把达不到的候选排除，再在剩下的里面比成本。这比单独排速度榜或价格榜都实用。
一份可复用的测试脚本该记什么
自己写测试脚本时，每次调用至少记这些字段，缺一项后面分析就少一个维度：
- 时间戳、厂商、模型名
- 输入 token 数、max_tokens、实际输出 token 数
- 首 token 时间、总耗时
- 是否流式、是否命中缓存
- 结束原因（正常完成 / 达到上限 / 错误）
- 错误码（如果失败）
有了这些字段，就能算出所有派生指标：输出速率等于输出 token 数除以（总耗时减首 token 时间），单位成本、每秒 token 的性价比也都能算。
分析时按输入长度分档看，而不是把所有样本混在一起平均。首 token 延迟和输入长度强相关，混着算会把结论完全抹平。
别被这三个假象骗了
假象一：某次测得特别快。 单次结果没有意义，可能刚好赶上服务端空闲。至少几十次采样看分位数。
假象二：本地测比服务器快。 网络路径不同，家里的宽带和机房出口的表现可能相反。以部署环境的测量为准。
假象三：新版本一定更快。 更强的模型往往更慢，更长的上下文也更慢。升级后务必重测，别假设。
还有一个不算假象但常被忽略的：厂商侧的性能会随时间变化。今天测的结论三个月后可能不成立，重要决策前重测一次。
几个降低延迟的手段
开流式输出。 不改变总耗时，但用户几秒内就能看到内容，体感改善巨大。这是性价比最高的一招。
提高缓存命中率。 前缀不用重算，首 token 更快。见提示缓存命中率上不去。
缩短输入。 检索替代整份文档，历史做摘要。既省钱又降延迟。
把非必要步骤并行或后置。 安全检查、日志、埋点这些不必卡在主链路上串行执行。
给长任务加进度反馈。 实在快不了的场景，用交互设计弥补：显示处理阶段、先返回部分结果。用户对「有反馈的等待」容忍度高得多。
三个高频问题
问：为什么我测的结果和官方宣传差很多？ 宣传数字通常是理想条件下的峰值。你的输入长度、网络路径、并发压力都会拉低实测值，以自己的测量为准。
问：流式输出能提高实际速度吗？ 不改变总耗时，但大幅改善体感——用户几秒内就看到内容，而不是干等到最后。
问：首 token 延迟高怎么优化？ 优先两件事：缩短输入、提高缓存命中率。两者都直接减少生成前的计算量。
一句话记住
速度这件事没有通用结论，只有你自己的测量。地域、时段、输入长度、并发压力任何一项不同，排名就可能翻转。与其收藏别人的跑分表，不如花半天写一个能反复跑的测试脚本——它在你每次换模型、换厂商、改架构时都能用上。
接着往下看
测完速度之后，把它和成本放在一起做决策：各家单价见价格对比表，按你的用量结构排序见月成本估算器，候选并排看参数见模型横向对比。如果延迟瓶颈来自输入太长，先读上下文长度怎么选——缩短输入通常能同时改善速度和成本。