大模型速度测试 token/s

你大概遇到过这种场景：同一个模型，别人说飞快，自己接上却慢得想砸键盘；或者本地刚部署完，想知道到底该不该换显卡、换量化档。问题往往不在于模型本身，而在于没量过自己的基线，也不知道该量哪几段。这篇讲清楚测什么、怎么测、测完怎么读，最后给一份能直接照着跑的排查顺序。

同一个模型，别人说飞快，你接上却慢得想砸键盘；本地刚部署完，想知道到底该不该换显卡、换量化档。这类问题多半不是模型本身差，而是你没量过自己的基线，也不知道该量哪几段。这篇讲清楚测什么、怎么测、测完怎么读，最后给一份能照着跑的排查顺序。

先说一个前提：速度不是模型的一个固有属性，而是你这条链路的合成结果。同一份权重，换机器、换量化、换提示词长度、换并发，数字都能差出一大截。所以本文不给你一个「达标线」，只给你方法和判断标准。想找参照数字，到站内 /tools/speed-test 和 /models/deploy 核对当时的实测口径，别拿别处的宣传数字直接类比。

先搞清楚：为什么别人的 token/s 不能直接用

token/s 是端到端链路的合成结果，中间夹着排队、预填充、逐 token 解码三段，任何一段拖后腿都会把整体数字拉下去。别人公布的数字通常取自理想条件：独占卡、短上下文、批量很小、没有别的请求在抢资源。你这边带并发、带长系统提示词、还跑着别的服务，跟人家根本不是一个场景。

判断标准很简单：只有当输入长度、输出长度、并发数、量化档位这四项跟你一致时，跨来源的数字才有可比性。不一致的时候，那些数字只能当量级参考，不能当验收线。换句话说，你要测的不是「这个模型多快」，而是「我这条链路在我这个用法下多快」。

• 别人测的是短提示词 + 短输出，你跑的是长文档摘要，两边的 token/s 没有可比性
• 别人是独占机器，你是共享云主机，邻居一忙你就抖
• 别人用的是显存装得下的量化档，你是勉强塞进去靠卸载跑，速度天差地别
• 别人只报了一个总数，没告诉你首 token 多慢，而你最在意的恰恰是首 token

把速度拆成三段量，别只测一个总数

只测一个总数，出问题时你根本不知道往哪修。建议把一次请求拆成三段分别记录，三段各有各的用途，也各有各的优化手段。

三段要分开记，不要合成一个数就完事。做知识库的人经常发现：模型解码明明不慢，但每问一次要等好几秒才出第一个字，问题就在预填充这一段，跟解码速度没关系。反过来，交互式助手首 token 很快、后面越吐越慢，那是解码或输出缓冲的问题。

动手测：一份不依赖特定框架的最小流程

测试的第一原则是固定变量：同一提示词、同一输出上限、同一量化档位、同一并发数，只改你要对比的那一项。同时改两项以上，得出的结论基本是废的。下面这套流程不依赖具体框架，用你能拿到的任何客户端都能跑。

1. 固定一组测试参数写死提示词文本、输出上限、温度、并发数、量化档位，存成一个文件或脚本，每次测试都用它，别凭记忆手打。
2. 先跑一轮热身扔掉第一轮通常包含模型加载、显存分配、缓存冷启动，直接丢弃。后面连跑三轮，取中位数，比取平均更抗单次抖动。
3. 在接口层计时不要只看生成器自己报的数，要在客户端记录「发出请求」「收到第一个 token」「收到最后一个 token」三个时间点，自己算三段耗时。
4. 本地部署同时看资源一边测一边看显存占用和 GPU 利用率。利用率长期打不满、显存贴着上限，说明瓶颈在搬运不在算力。
5. 换一项再测一次比如只换量化档位，其余全不动，再跑同样三轮，这样你才知道变化到底是谁带来的。

如果你只是想先摸个底，可以到站内 /tools/speed-test 先量一条延迟基线，再用同一套逻辑去测你要评的模型，保证两边口径一致。注意这只是起点，不是结论。

# 计时思路示意，不是可以直接跑的成品；重点是三个时间点\n# t0 = 发出请求前\n# t1 = 收到第一个 token\n# t2 = 收到最后一个 token\n# TTFT = t1 - t0；解码速度 ≈ 输出token数 / (t2 - t1)

数字怎么读：判断快慢的坐标轴

测出数字只是第一步，关键是把它放进正确的坐标里。第一个坐标是瓶颈位置：GPU 利用率长期打不满、显存接近上限，说明卡在显存搬运或模型卸载，这时候换更大显存往往比换更快的卡有效。利用率打满、显存还有余量，才轮到考虑算力问题。

第二个坐标是任务匹配。聊天助手对首 token 延迟敏感，批量文档处理对总体吞吐敏感，同一个模型在这两种任务下的「快」标准完全不一样。拿批处理的吞吐数字去评价交互体验，是常见的错位。

第三个坐标是横向对照。到站内 /models/deploy 看部署测算的口径，到 /compute/sizing 看规模估算，把自己的数字放进同一坐标系再下结论。特别提醒：别拿在线接口的单次数字去推本地部署能达到的水平，两者的资源边界完全不同。

• 先定位瓶颈：算力满还是显存满，决定了你该换什么
• 再匹配任务：你更在意首 token 还是总吞吐
• 最后再横向比：口径不一致的数字不要放一起比大小

六个最容易把测试做废的坑

下面这些坑，踩一个就够让整轮测试白做。对照自己的流程过一遍，比事后怀疑人生划算。

• 用短提示词测出的解码速度，直接拿去评估长文档场景，忽略了预填充占比
• 对比两个模型时，同时改了量化档位和并发数，然后得出「A 比 B 快」
• 忽略服务端输出缓冲，客户端测到的是攒完才一次性吐出来的时间
• 在共享卡或共享云主机上测，邻居负载直接污染结果，测前没确认机器是否独占
• 只跑一轮就下结论，没有取中位数，也没有排除冷启动
• 只看模型自己报的速度，不记录提示词长度和输出长度，事后无法复现

补一条判断标准：如果你的三轮结果彼此差异很大，先别急着比较快慢，说明系统本身不稳定，先把稳定性问题解决掉，再谈速度。不稳定的系统上做出来的速度对比，基本都是噪声。

这些情况下，token/s 不该作为决策依据

token/s 很有用，但它不是万能的，下面几种场景里盯着它做决策反而会跑偏。

第一种是推理型任务，瓶颈在模型「想」多久，而不是解码多快。这时候提速手段应该是缩短思考过程或者任务拆分，而不是硬提解码速率。第二种是按次计费的托管服务、且你对延迟不敏感，比如离线批处理，那成本口径比速度口径更值得盯，去 /inference 对比开源模型价格更有意义。

第三种是你的评测样本太少。只测了一两轮就得出「A 比 B 快」的结论，数字差异大概率是噪声。先补足样本量，再谈结论。第四种是你其实在纠结要不要换机器，这时候更该看的是显存、并发承载能力和成本，而不是单一的速度指标。

测完别只记一个数：留下可比对的记录

很多人测完随手记一个数字，过两个月想复盘，发现自己完全分不清是环境变了、模型变了还是流量变了。解决办法很简单：用同一份模板记录，每次填一遍。

换卡、换框架、换量化档位前后各测一次，用同一份模板对齐。把结果和站内 /usage 的真实用量口径、/ai-status 的服务状态对照看，能帮你区分「模型真的变慢了」和「只是服务在抖」。这一步做得越早，后面排查越省事。

最后提醒一句：这套方法的价值不在于测出一个好看的数字，而在于当有人跟你说「这个模型很快」时，你能知道该问哪几个问题——输入多长、输出多长、并发多少、什么量化、独占还是共享。问清楚这五个，比记十个数都管用。