大模型推理速度 token/s

你调一个模型，界面上一秒蹦出几十个字，感觉很流畅；换个模型或者换台机器，同一段提示词像挤牙膏。这时候网上那些「多少 token/s」的说法基本帮不上忙，因为测得口径不一样。这篇不排座次、不给死数字，只讲清这个指标在量什么、哪些环节会拖慢它，以及你自己该怎么量、怎么读，最后判断它对你手上的活到底重不重要。

你调一个模型，界面上一秒蹦出几十个字，感觉挺流畅；换个模型或者换台机器，同一段提示词像挤牙膏。这时候网上那些「多少 token/s」的说法基本帮不上忙，因为大家测的口径不一样：有人报单请求峰值，有人报服务总吞吐，有人干脆把首 token 时间藏起来只报生成段。

这篇不排座次、不给死数字，只讲清这个指标在量什么、哪些环节会拖慢它，以及你自己该怎么量、怎么读，最后判断它对你手上的活到底重不重要。看到任何速度数字，先去站内页面核对当时的条件和口径，再决定信不信。

token/s 到底在量什么

token 是模型处理文本的最小单位，中文一个字不一定等于一个 token，常见情况是一个汉字对应一个到两个 token 不等，标点和英文单词的切法也不一样。所以「字/秒」和 token/s 不能直接换算，拿字数除以 token 数估速度，误差能到一半以上。报速度的时候，把单位说清楚比把数字说大更重要。

输出速度

生成阶段每秒产出多少 token，是大家默认说的那个 token/s

首 token 延迟

从发出请求到吐出第一个 token 的时间，包含排队、输入预处理和预填充

总吞吐

整个服务在并发下每秒处理的总 token 数，和单请求速度是两回事

量化档位

权重压缩程度，档位越低通常越快，但输出质量会变，得单独验证

真正影响体感的是首 token 延迟加输出速度的组合。只报输出速度会显得很快，可如果第一个字要等好几秒，聊天场景里的体验照样很差；反过来，首 token 很快但后面一个字一个字往外蹦，长文任务会让人等到失去耐心。两个数字要分开看，别被其中一个带跑。

一次请求的时间花在哪几个环节

很多人把「慢」直接归到模型头上，其实一次请求要经过好几段路，每段都可能成为瓶颈。先分清时间花在哪，才知道该动哪一刀，不然改了半天都是白费劲。

• 排队等待：并发高时请求要先排队，这段延迟跟你本地机器无关，换本地部署也躲不掉；
• 输入预处理：提示词越长、上下文越满，模型先把输入读一遍的时间越久，长文档问答尤其明显；
• 逐 token 生成：这才是 token/s 主要反映的阶段，和显存带宽、批大小强相关；
• 网络回传与前端渲染：流式输出怎么分段、前端打字机效果怎么实现，也会影响你眼睛看到的速度。

一个常见误判是：本地跑得慢就以为是显卡不行。其实先看输入长度和并发数，同一张卡上，短提示词和塞满上下文的请求，等待时间能差出好几倍。排查时先把变量砍到最少，再谈硬件。

硬件与部署侧的影响因素

生成阶段是逐 token 迭代，每一步都要把权重读一遍，所以显存带宽往往比纯算力更关键。显存带宽高、权重读得快，出字就顺；反过来，算力再强但数据供不上，一样卡。选卡之前先搞清自己跑的是哪种负载。

关于量化档位的取舍，别只看速度，要拿自己的任务过一遍质量关，具体档位和对应表现到 /tools/quality-check 这类检测页核对当时的结论再定。部署框架之间的差异也可以对照站内导航页，换框架前后用同一套用例各测一次，才说得清是哪一步起了作用。

模型侧与任务侧的影响因素

模型这边，参数量越大一般越慢，但同样规模下，架构设计和注意力实现方式的差别也很大，不能只按参数个数推断。更重要的是任务侧：你让它干什么，往往比它自己多快更决定等待时间。

• 推理型模型会先输出一长段思考内容，你按秒算体感会慢很多，但这是设计使然不是故障；
• 输出长度比速度更影响总等待时间，长文任务先看能不能流式返回，能流式就别死等；
• 多模态输入里图片、音频要先编码，同一句话带图和不带图，速度不可比；
• 系统提示词、工具定义这些固定前缀也会计入输入，写得越长每次请求的预处理越久。

把任务分个类会很有帮助：人盯着屏幕等结果的，优化首 token 延迟；没人等的批处理，优化总吞吐；输出很长的，优化流式体验。方向错了，速度数字再好看，你的实际体验也不会有改善。

想比较就先统一测量口径

想让自己的测试有意义，核心就一句：控制变量。别人的数字只能当参考，你要比的是「同一套条件下，A 和 B 谁更快」。下面这套流程按顺序走一遍，结果基本可复现。

1. 固定测试用例用同一段提示词、同样的输出长度上限、同样的温度等采样参数，别每次随手换内容。
2. 先跑一轮预热第一次请求包含模型加载和缓存冷启动，不能计入平均值，跑完丢弃再正式测。
3. 分开记录两个数分别记首 token 时间和整体输出耗时，再算每秒 token 数，别混成一个指标。
4. 重复多次取中位数单次测试波动大，跑若干轮取中间值，比只看最快那次更接近真实表现。
5. 换条件前后各测一次换机器、换框架、换档位之前测一次，之后测一次，留档对比，改完才说得清是哪步起作用。

想先量自己网络和接口的延迟基线，可以用站内 /tools/speed-test 跑一遍，把端到端延迟拆出来，再去比不同模型或平台，这样不会把网络问题误算成模型慢。测试记录建议留一份表格，写清条件、时间和结果，过几天回头看才认得出。

看到别人给的 token/s 数字怎么读

判断一个速度数字能不能信，先问条件，再看口径，最后才看数值。缺条件的数字当宣传语看就行，别拿它当选型依据。

• 先问条件：什么卡、什么量化、多大并发、输入输出多长，缺一项基本没法比；
• 区分单请求速度和服务总吞吐，宣传材料里常拿后者当卖点；
• 注意是否包含首 token 时间，有的只报生成阶段，看起来会快不少；
• 榜单口径和实测不一定一致，去 /benchmarks 看榜单说明，对照 /usage 的用量侧画像会更稳。

还有一种情况要特别小心：数字本身没错，但测试环境和你的环境差太远。比如对方在显存充裕的大卡上测，你在显存刚够的机器上跑，速度差一个量级很正常。这种情况不是被骗，是条件不同，判断时把环境差异一起算进去。

速度对你的场景到底重不重要

不是所有场景都值得为速度优化。判断标准很简单：有没有人在等结果，以及等的那个人能不能接受。人盯着屏幕的场景和后台批处理的场景，优化目标完全相反，用同一把尺子量会得出错误结论。

还有一条底线：如果任务本身质量不达标，再快也没意义。先过质量关，再看速度。质量怎么算过关，各家标准不同，到站内 /tools/quality-check 相关检测页对着自己的用例跑一遍，比听介绍靠谱。

觉得慢时的排查顺序与动作

觉得慢的时候，最容易犯的错是直接换模型或换平台，结果问题可能出在输入长度或并发设置上。推荐按下面这个顺序排查，从便宜的动作做起，每一步都留记录。

1. 看硬件占用先看显存是否打满、有没有发生卸载，名词不清楚就对照 /ai-dict/category/hardware 认一遍。
2. 砍条件做对照缩短输入、限制输出长度、降低并发，看速度是否回升，回升说明瓶颈在条件不在硬件。
3. 换档位或换框架本地部署框架之间的差异可对照 /ai-nav/category/ai-model-platform，换完用同一套用例再测一次。
4. 最后才换模型或平台换之前把成本和对齐口径一起算，参考 /inference 与 /compute/gpus 上的资料，别只看速度一个维度。
5. 留档对比全程记录改动前后的条件与结果，否则改完说不清是哪一步起了作用，下次还得从头来。

速度数字只有在条件说清楚之后才有意义；条件不清，数字越大越要打问号。