大模型的答案往外蹦的速度，有个量化指标叫每秒 token 数，缩写 TPOT；把它和同时服务的请求量放在一起看，就是常说的吞吐。token 是模型处理文字的底层单位，一个汉字大约对应一两个，英文单词常被拆成多个，所以写字的手速要用每秒多少个 token 来量，而不是每秒几个字。
token 手速怎么量
TPOT 量的是单个请求的输出节奏：从第一个字出现开始，到最后一个字结束，平均每个 token 花多少时间，反过来就是每秒多少个。这个指标直接决定体感：数值高，答案像机关枪，眼睛要追着看；数值低，答案一个字一顿，聊长天会急死人。
它和首字时间是搭档：一个管起步，一个管巡航。两个数放在一起，才能说清一个产品“快不快”的全貌。而它衡量的对象，正是解码阶段的推进节奏，两者是同一件事的两种说法。
像传送带出货
理解每秒 token 数，可以类比流水线末端的传送带。传送带每秒送出多少件货，取决于产线节奏：前面工序顺，出货就密；前面卡一下，出货就断。模型的解码阶段就是这条产线，每算出一个 token 就往外送一件货，送得越密，你看到的字蹦得越快。
传送带类比还解释了为什么偶尔会卡一下。产线换料、质检抽检，出货节奏就会出现空档；模型这边，服务端调度、缓存未命中，也会让输出出现短暂的停顿。这类卡顿多数不是坏了，是节奏被别的事情插了队，流式输出的缓冲那篇专门讲来龙去脉。
传送带类比错在哪
这个类比有两处对不上。其一，传送带的货是提前备好的，模型的 token 是现算现送，送每一个都要把前文重新过一遍，写得越久单字成本越高。其二，传送带速度可以随意调，模型的解码速度受算力、负载、上下文长度多重约束，不是想快就能快。
还有一处要提醒：单看每秒 token 数会骗人。一个请求飙得飞快，可能只是因为同时服务的用户少；把负载加满，速度立刻下来。所以它要和并发接待量合起来读，才能反映真实服务水平。
吞吐和单人速度别混
吞吐是另一个维度：单位时间整个服务能处理多少请求、产出多少 token。它大致等于单人速度乘同时服务的请求数，但两者经常互相拉扯——同时招待的人多了，每人的速度就被摊薄。产品宣传的“吞吐提升”，说的通常是这个总量。
智谱清言和讯飞星火都公布过各自的推理性能数据，横向比较时记得分清是单人速度还是系统吞吐。看性能数据还要注意测试条件：上下文长度、并发档位、输出长度上限，三项不同，数字就没有可比性。同一把尺子量出来的差距，才是真差距，跨条件对比数字意义有限。输出长度也得对齐，让一个产品写两百字、另一个写两千字，比速度不公平。带走一个判断：每秒 token 数管单人巡航手感，吞吐管系统运力，两个数分开记，才不会把“人少时的快”当成“永远的快”。
两个指标量的是不同层面的东西，并排读才不混。
| 指标 | 量的是什么 | 怎么读才不被骗 |
|---|---|---|
| 每秒 token 数（TPOT） | 单个请求的输出节奏，平均每个 token 花多少时间 | 单看会骗人，一个请求飙得飞快可能只是同时服务的用户少 |
| 吞吐 | 单位时间整个服务能处理多少请求、产出多少 token | 大致等于单人速度乘同时服务的请求数，宣传的“吞吐提升”说的是这个总量 |
| 首字时间 | 起步那一段，开口前的准备耗时 | 和每秒 token 数一个管起步、一个管巡航，两个数一起才说清全貌 |
速查表：TPOT=单请求每 token 平均耗时的倒数；吞吐=系统总量；类比传送带出货；失效在 token 现算现送；两指标必须合读。
每秒 token 数快问快答三则
- 每秒 token 数越高越好吗？不一定，快到看不清反而影响阅读，匹配阅读节奏的手速才舒服。
- 为什么开着多个对话会变慢？并发上来了，算力被摊薄，单请求的输出节奏随之下降。
- 中英文的输出速度一样吗？token 单位不同，同样一句话的 token 数差异明显，换算成“字”的观感也就不同。
