30 tokens/s 听起来很快。

但它落到屏幕上，到底是“顺滑输出”，还是“用户还在等”？很多模型宣传页不会回答这个问题。

Mike Veerman 做了一个 HTML 小工具，可以模拟 LLM 从每秒 5 到 800 token 的输出速度。Simon Willison 推荐了这个链接，来源线索也出现在 Hacker News。

我更在意的不是这个工具本身有多复杂。它的价值在于，把 tokens/second 这种参数，拉回到人的等待感。

10 tokens/s 不是抽象参数，是屏幕上的节奏

tokens/s 是大模型推理服务里常见的输出速度指标。意思是模型每秒生成多少 token。

但 token 不是中文字符，也不等于英文单词。它是模型分词器切出来的文本片段。不同语言、不同模型、不同分词方式下，一个 token 对应多少可读内容，并不固定。

这也是 Mike Veerman 这个小工具有用的地方。它不告诉你哪家模型更强，也不证明某个模型真实跑得快。它只做一件事：让你看到不同输出速率的观感差异。

比如看到模型宣传“30 tokens/second”时，你可以先看一眼模拟效果。这个数字到底像是顺手的聊天回复，还是生成长文时仍然要等，至少能有一个直觉。

看到的指标或场景可以帮助判断什么不能推出什么
10 tokens/s文本会有明显逐段吐出的感觉不能代表完整请求耗时
30 tokens/s输出节奏通常会比 10 tokens/s 更连贯不能说明回答更准确
5-800 tokens/s 模拟范围可以对比慢速到高速的体感差别不是厂商性能排名
token 数能粗略比较生成节奏不等于中文字符、英文单词或最终阅读速度

对开发者来说，这能减少一个常见误判：把宣传页上的速度数字，直接等同于用户体验。

做客服机器人、代码助手、写作工具时，流式输出节奏会影响用户是否继续等。开发者可以据此调整前端展示，比如是否需要更早显示占位状态、是否拆分长回答、是否让用户先看到摘要。

对产品经理来说，它是一个低成本沟通工具。团队讨论“30 tokens/s 够不够”时，不必只围着抽象参数争。先看输出观感，再回到业务场景。

短问答、代码补全、长文生成，对速度的容忍度不同。同一个 tokens/s，放在不同产品里，不是同一个体验。

tokens/s 能比较体验，但不能单独评价模型

tokens/s 有用，但边界很清楚。它主要描述输出阶段的速度，不等于一次请求从开始到结束的完整延迟。

完整等待感还包括首 token 延迟、排队时间、网络往返、上下文长度、工具调用和后处理。用户点下发送后，最先感受到的往往不是每秒生成多少 token，而是多久开始出字。

一个系统可能首 token 很慢，但后面输出很快。另一个系统可能马上出字，但后续速度一般。两者的 tokens/s 对比未必能解释真实体感。

这也是采购和选型里最容易踩空的地方。只看 tokens/s，可能买到“看起来跑得快”的方案，却没有解决真实工作流里的卡顿。

更稳妥的动作是延后单凭速度数字做决策。开发团队应该拿自己的提示词、上下文长度和并发条件测试。产品经理也应该要求供应商说明测试条件，而不是只接收一个漂亮数字。

如果是本地部署或模型迁移，tokens/s 只能作为初筛项。真正决定能不能迁移的，还包括稳定性、成本、响应质量、隐私要求和服务等级。

这几个变量缺一个，速度数字都容易失真。

接下来要看服务商怎么拆指标

这个小工具的意义，不是替代压测。它更像一把直尺，帮人校准对宣传数字的直觉。

接下来更该看的，是模型服务商会不会把速度指标拆开讲清楚。只报 tokens/s 太省事，也太适合营销。

比较负责任的写法，至少应该同时说明这几件事：

应该披露的指标为什么重要
首 token 延迟决定用户多久看到系统开始响应
输出速度 tokens/s决定流式文本吐出的节奏
测试上下文长度长上下文会影响推理表现
并发条件影响排队、抖动和稳定性
网络和部署环境决定线上体感是否接近宣传值

如果这些条件没有给出，30 tokens/s 就只是一张半截账单。

对关注 LLM 推理速度的开发者，实际动作很明确：不要只复制厂商数字进方案文档。先用可视化工具校准体感，再在自己的任务里测首 token、总耗时和并发稳定性。

对需要理解模型宣传指标的产品经理，也有一个简单判断：看到 30 tokens/s，不要立刻把它翻译成“用户体验够快”。先问它是在什么上下文、什么并发、什么网络条件下测出来的。

问不清，就不要急着为“更快”付费。

这就是这个小工具提醒人的地方。参数可以写得很漂亮，但用户看到的是屏幕什么时候动、动得是否顺、等完以后答案是否有用。