选型时你多半见过「每秒多少 token」这种数字，但真拿去比，往往发现同一模型不同人给出的数差好几倍。这篇不给你一个标准答案，而是把指标口径、影响因素和自测方法拆开讲：什么时候该看首字延迟，什么时候该看吞吐，别人报的数在什么条件下才跟你的场景可比。看完你能自己判断某个速度数字是不是靠谱，也能用站内工具量出自己的基线。
选型时你多半见过「每秒多少 token」这种数字，但真拿去比，往往发现同一模型不同人给出的数差好几倍。问题不在于谁在说谎，而在于口径、硬件、并发配置压根不是一回事。所以这篇不给你一个标准答案，而是把指标口径、影响因素和自测方法拆开讲：什么时候该看首字延迟，什么时候该看吞吐，别人报的数在什么条件下才跟你的场景可比。
看完你能自己判断某个速度数字是不是靠谱，也能用站内工具量出自己的基线。核心思路只有一句：速度不是模型的一个属性，而是「模型 + 硬件 + 配置 + 任务形态」的组合结果。任何脱离条件单独抛出来的速度数字，都只能当参考值，不能当结论。
先分清在说哪个速度
速度这个词在大模型场景里至少对应三类完全不同的指标，它们互相牵制，报一个不提另外两个的数字基本没法用。问别人速度、看文档速度、自己做容量规划之前，先把说的是哪一类定下来，后面所有比较才成立。
- 首字延迟（TTFT）
- 发出请求到吐出第一个字要等多久，直接决定交互体感，长上下文会让它明显变长
- 单路生成速度（token/s）
- 一个用户连续输出时每秒能出多少 token，看的是「写得顺不顺」
- 总吞吐
- 整个服务每秒处理多少 token，多人共用才有意义，看的是「扛不扛量」
- 同一模型同一张卡，单路测出的速度和开高并发时的单路速度是两回事，前者看体验、后者看容量，一定要问清对方测的是哪种
- 延迟还分端到端和纯推理：网络往返、排队、预处理都可能占大头，尤其跨区调用官方接口时，这部分跟模型本身没关系
- 只做离线批处理（比如半夜批量跑摘要）只需看总吞吐，首字延迟高一点无所谓；做交互式对话或代码补全，首字延迟就是体感天花板，吞吐再高也救不回来
- 拿不准自己该看哪个，就去 /tools/speed-test 各测一组，用实际感受反推指标优先级，比看文字定义快得多
同一模型为什么数字差好几倍
模型权重没变，速度却能差出好几倍，通常不是模型的问题，而是下面这几项里至少有一项没对齐。比较任何两个速度数据前，先把这张表里的条件拉齐，否则比出来的差值没有意义。
| 影响因素 | 会怎么改变数字 | 比较时要对齐什么 |
|---|---|---|
| 硬件与显存 | 显存装不下整个模型就要分层卸载到内存，速度断崖式下降 | 卡型、数量、显存是否够装下权重 |
| 量化档位与推理框架 | 不同精度、不同推理引擎，速度和并发能力差别明显 | 量化方式与所用推理框架版本 |
| 输入与输出长度 | 长上下文拖慢首字延迟，长输出拉低平均速度 | 固定的输入规模与输出规模 |
| 并发与批处理 | 批处理抬高总吞吐，同时抬高每路等待时间 | 并发档位、批大小是否一致 |
这张表里最容易漏掉的是最后一项。服务方对外给的往往是能跑出的漂亮数字，但不会主动说明当时的并发配置；你按这个容量做规划，实际单用户体验可能差很远。量化档位具体怎么影响速度，可以到 /models/deploy 里按模型和量化方式对照测算。
别追别人的数，先量自己的基线
与其到处收集别人的速度数字，不如在自己环境里测一条基线。基线的好处是：它跟你的网络、你的任务长度、你的调用方式一致，之后任何参数改动、换服务商、换模型，都能拿它当尺子量出真实差异。
- 先拆网络与推理两部分用 /tools/speed-test 把接口的端到端延迟和首字延迟量出来，如果端到端远大于纯推理，问题在链路或排队，不在模型，优化方向别找错。
- 确认模型是否完整进显存看部署配置里有没有发生分层卸载，一旦卸载，先解决显存问题再谈速度，其他调参都是白折腾。
- 再看框架与量化档位同一权重换精度或换推理引擎，速度和并发表现会明显变化；这一步的取舍可以参照站内量化相关页面。
- 最后调并发与批处理参数前面三项没问题了再动并发，否则你会把瓶颈误判成并发不足，越调越乱。
验收式测法：固定一段贴近真实业务的代表性输入，覆盖你实际会遇到的长短分布，跑上几十次取中位数而不是单次最好值，再记录不同并发档位下的表现。什么情况下不用纠结速度？如果业务是低频、非实时调用，比如每天几百次的后台任务，速度通常不是瓶颈，把精力放在质量和成本上更划算。
拿到一个速度数字怎么判真假
别人给你一个速度数字，或者你在某个页面上看到一个数字，可以用下面这张清单快速判它是不是能用。四件事缺一项，就当参考值而不是结论；缺两项以上，基本只能当宣传看。
| 检查项 | 交代了什么才算合格 |
|---|---|
| 硬件 | 卡型与卡的数量，显存是否够装下权重 |
| 量化与框架 | 量化精度、所用推理框架 |
| 任务规模 | 输入输出长度、是否固定 |
| 并发档位 | 单路还是高并发，批处理怎么配 |
- 特别警惕只报峰值吞吐不报单路延迟的宣传，那意味着你按这个容量做规划，用户实际体验可能很差
- 用真实任务的完成时间替代速度数字：同样一段活跑完要多久，比每秒多少 token 更贴近决策
- 看榜单和评测数据时注意口径差异，如何识别水分可以参考站内榜单解读相关页面
- 拿不准就去 /benchmarks 与 /usage 对着看好几组来源，别只信一家，各家口径放在一起差异会自己浮现
- 同一家前后两次给的数据对不上时，大概率是配置变了而非模型变了，先问配置再问结论
速度不是模型的一个属性，而是模型、硬件、配置和任务形态凑在一起的结果；换掉任何一项，数字就该重测。下一步先把自己的基线量出来，再去看别人的数字，你会发现大部分争议自己就消失了。→
常见问题
每秒多少 token 才算够用？
没有通用门槛，取决于场景。做代码补全这类边打字边出结果的交互，慢一点就会被察觉；做后台批处理，慢几倍也不影响交付。建议先定一个可接受的单次等待时间，倒推需要的速度，再用 /tools/speed-test 实测比对，而不是先找一个「标准值」。
为什么我自己测的比官方或别人说的慢很多？
通常是口径不同：对方可能报的是短输入短输出、低并发的理想值，而你的输入很长或同时在跑多个请求。也可能是网络跨区、显存不够触发卸载、量化档位不同。按「网络 → 显存 → 框架与量化 → 并发」的顺序逐项排查，一般能定位到原因。
推理速度和模型质量要二选一吗？
不是硬二选一，但确实有取舍关系。同一系列里更大的模型、更高的精度通常更慢更贵。常见做法是主链路用质量优先的模型，对速度敏感的环节（补全、意图识别、预筛）换更小的模型，具体怎么分可以参考站内模型选型的方法论页面。
