tokenspeed：用一串假 token，看懂 LLM 的“快“和“慢“
tokenspeed：用一串假 token，看懂 LLM 的"快"和"慢"
一个纯 Python 的终端小玩具，用假 token 模拟 LLM 的输出速度。没有实际模型，没有 API 调用，只是让你看看 30 tok/s 到底有多快、800 tok/s 又有多快。
这工具是干什么的
每个 LLM 基准测试都在报吞吐量：“M3 上 47 tok/s”、“4090 上 180 tok/s”、“Groq 上 500 tok/s”。但这些数字除非你亲眼见过 token 以这个速度流出来，否则很难产生体感。
tokenspeed做的事很简单：在终端里以你设定的速度流出一串假 token，让你看看那些数字实际看起来是什么样。
三种模式：
- code— 带语法高亮的伪代码（Python / Rust / JS），模拟看 LLM 写代码的场景
- text— Wikipedia 散文，模拟聊天/回答场景
- think— 暗淡斜体的推理句子和代码交替出现，模拟推理模型"边想边说"
用法：
python3 tokenspeed.py# 默认 30 tok/s，交互式选模式python3 tokenspeed.py120# 120 tok/s，交互式选模式python3 tokenspeed.py--modecode# 跳过选模式python3 tokenspeed.py120--modethink# 组合参数无任何依赖——只要 Python 3 和一个真正的终端（不是 IDE 内嵌的）。
核心洞察：数字是一样的，体感完全不一样
这个工具最有价值的地方，不是帮你测速度，而是帮你建立对速度的直觉。
作者给出的建议是这样试：
- 默认
30tok/s，读一读 - 按
1（5 tok/s）——树莓派级本地模型 - 按
5（60 tok/s）——托管 Claude 或 GPT - 按
7（200 tok/s）——Groq - 按
9（800 tok/s）——Cerebras，瓶颈变成你的眼球
然后在同一个速率下，切换--mode code和--mode text。
差距很明显，而且是有意设计的。
原因在于 token 密度。
30 tok/s 的英文散文，每秒大约传递 23 个单词，信息密度高，你读得过来。30 tok/s 的代码，每秒可能只传递 10-15 个字符，因为标识符和关键字经常被 BPE tokenizer 拆成多块——processUserInput可能被拆成process+User+Input，calculate_score被拆成calculate+_score。
这意味着相同 tok/s 下，代码落地到屏幕上的可见内容远少于自然语言。基准测试的数字没有错，但体感差异非常大，取决于你在看什么类型的输出。
控制
| 按键 | 作用 |
|---|---|
+/- | 按 ×1.25 微调速率 |
1-9 | 跳转预设（5/10/20/30/60/100/200/400/800 tok/s） |
| 空格 | 暂停/继续 |
q | 退出 |
这个预设的设计也很讲究——不是均匀分布，而是按数量级分布，从 5 到 800 全覆盖。因为不同部署方案的速度差距本质上是数量级的。
"Token"到底是什么
工具用近似 BPE（Byte-Pair Encoding）的方式模拟了常见 tokenizer 的行为，但不是精确复现任何一个具体 tokenizer（tiktoken、Claude、或其他厂商的 tokenizer 之间本身就存在分歧）。
大致规律：
- 短单词往往是一个 token
- 较长的标识符经常被拆成多个 chunk
- 标点和运算符通常也算 token
英文散文平均约 1.3 tokens/word，30 tok/s ≈ 23 words/s。这个换算关系是那串预设数字背后真正的意义。
价值和局限
价值
- 建立速度直觉：这是最核心的价值。看数字和看实际流出的区别，就像看菜单和吃菜的区别。
- 零门槛：纯 Python，零依赖，一行命令就能跑。
- 三种精心设计的模式：覆盖了 LLM 输出的主要场景，特别是 code 和 think 模式，针对的都是前沿使用场景。
- 信息密度差异的显式暴露：代码 vs 文本的 token 密度差异被设计成核心功能，而不是一个附带发现。
局限
- 模拟而非真实：它生成的是伪代码和固定文本，不是真正的 LLM 输出。真实模型输出时会有停顿、思考、修正，这种"不均匀性"没有被模拟。
- 终端依赖：在 IDE 内嵌终端或受限环境中效果不好。
- 没有网络版本的可比展示：虽然有一个
index.html文件，但核心体验在终端。 - 单机/单 session：不能模拟并发或多轮对话的累积效应。
- 没有提供真实的 tokenizer：无法精确复现某个具体模型的 token 开销，对于需要精确计费评估的场景帮助有限。
这个工具的存在说明了什么
tokenspeed很小——一个 Python 文件，两百多行代码，189 个 stars（对于一个纯玩具来说已经不少了）。
但它指向了一个真实的问题：LLM 行业在"快"的定义上缺乏统一标准。
tok/s 是一个技术指标，不是用户体验指标。同样的 tok/s，不同内容类型、不同终端、不同阅读速度下，体感可以差几倍。而绝大多数基准测试只报一个数字，没有人去解释"这个速度下用户实际看到的是什么"。
这个工具有点像一个"翻译器"——把 tok/s 翻译成人类可感的体验。虽然它没有解决标准化问题，但至少让更多的人意识到了这个问题的存在。
Sources:
- MikeVeerman/tokenspeed - GitHub
- tokenspeed - index.html（Web 版）