一句话定义：tok/s（tokens per second，每秒 token 数）是衡量模型出字速度的单位，但这个数字只有配上“在什么条件下测出来的”才有意义——这套条件就是测量口径。
先补一句 token：模型不按“字”处理文本，而是按 token（词元）切分，一个汉字大致对应一个 token 上下，英文里一个 token 大约是半个到一个短单词。所以 tok/s 大致可以理解成“每秒蹦出几个字”。
一个请求其实分两段跑。第一段是 prefill（预填充）：把你输入的整段提示词一次性读完，这段是纯算力活，可以高度并行，速度极快。第二段是 decode（解码）：一个字一个字往外蹦，每蹦一个都要把整个上下文重新过一遍，越到后面越慢。这两段的耗时性质完全不同，很多漂亮的 tok/s 数字，是只算 prefill、或者只算 decode 里最顺的那一小段。
打个餐厅的比方。你一个人进店点一份菜，从下单到上菜的时间，是单请求时延（per-request latency）；而“本店每小时出餐一千份”，是把后厨一百口锅同时开火的总量算进去的系统吞吐（system throughput）。这两个数不但不是一回事，往往还反向：同时服务的客人越多，GPU 越忙，总吞吐越高，但每一桌等得越久。厂商宣传的“上千 tok/s”，绝大多数是后厨总量；你坐在桌前感受到的，是前厅那一份。
所以看到一个大 tok/s 数字，值得追问四件事：batch 多大（同时跑多少条请求）、输入多长、输出多长、算的是总吞吐还是单条请求速度。此外还有几个容易忽略的变量：有没有算首 token 延迟（TTFT，time to first token）、是否命中前缀缓存（prefix caching）、用的什么量化精度和采样参数、报的是平均值还是 p99。
| 指标 | 含义 | 谁真正关心 |
|---|---|---|
| 单请求 decode 速度 | 你独占资源时的出字速度 | 聊天、写代码的体感 |
| 系统总吞吐 | 全机器所有并发加起来的 tok/s | 容量规划、单位成本 |
| TTFT 首 token 延迟 | 从发出请求到看见第一个字 | 交互“跟手”程度 |
| 端到端时延 | 排队 + 预填充 + 全部生成 | 用户实际等待 |
实际意义：人的中文阅读速度大约是每秒几个到十几个字，对应下来几十 tok/s 的单用户速度已经超过多数人的阅读上限，再快对人的体感意义有限——除非你在跑批量任务，那才该看总吞吐。对从业者，压测时要复现自己的真实流量画像（并发数、输入输出长度分布），看 p50/p95/p99 而不是均值，别拿厂商的峰值数字直接做容量规划。对普通用户，记住 tok/s 只说明“出字快”，不说明“答得好”，模型能力是另一个维度。具体规格以各家官方页面为准。