你可能没想过一个问题：当今最强大的AI模型——GPT-4、Claude、Gemini——它们连"strawberry里有几个r"都数不对。这不是模型不够聪明，而是它们看世界的方式从根本上就错了。它们看到的不是字母、不是字符，而是一个个被粗暴切分的"Token"。
2026年5月25日，ThePrimeagen——Twitch上最火的程序员主播之一，在YouTube频道The PrimeTime发布了一条视频《Everyone is Wrong about Tokens》，用他标志性的高能风格，把LLM分词这个"房间里的大象"彻底拆了一遍。三天内B站就出现了多个搬运版本，评论区炸成一片。
这不是一条普通的科普视频。ThePrimeagen不只是告诉你"tokenization有问题"，他深入到了BPE（Byte Pair Encoding）的数学本质、T-FREE等前沿替代方案，以及一个更根本的追问：如果我们从底层重新设计LLM的文本表示方式，AI的能力天花板会提高多少？
| 项目 | 内容 |
|---|---|
| 视频标题 | Everyone is Wrong about Tokens |
| 频道 | The PrimeTime（ThePrimeagen） |
| 发布日期 | 2026年5月25日 |
| 频道订阅 | ThePrimeagen主频道543K / The PrimeTime 190K+ |
| 核心主题 | LLM Tokenization的根本性缺陷与替代方案 |
ThePrimeagen在视频开头就丢出了一个让人坐不住的事实：GPT-4在发布将近两年后，依然无法正确回答"strawberry里有几个r"这种小学生都会的问题。 原因不是模型"笨"，而是它压根就不看字母。
这是怎么回事？当前几乎所有主流LLM都使用BPE（Byte Pair Encoding）或其变体来处理文本。BPE的核心逻辑是：把文本切分成变长的子词单元（subword），高频词整体保留，低频词拆成更小的片段。比如"strawberry"在GPT-4的tokenizer中可能被切分为["str", "aw", "berry"]三个token——注意，模型只看到了三个"石板"，每个石板内部的字母结构对模型来说是不可见的。
ThePrimeagen的比喻很精准：这就像让你数一本书里有多少个字母"e"，但你只能看到被撕成碎片的书页，每片碎片上的字母你都看不到。 你当然数不对。
我个人的延伸分析：这个问题比大多数人想象的更深。它不仅影响"数字母"这种看似无用的任务，还直接限制了LLM在以下场景的能力：
ThePrimeagen在视频中深入拆解了BPE tokenizer的三个结构性问题：
BPE需要预训练一个固定的词汇表（vocabulary）。GPT-4的词汇表大约有10万个token，但这些token的分配极度不均衡。英语占据了大部分高频token，而其他语言——尤其是非拉丁字母的语言——被迫用更多的token来表达相同的意思。
这意味着什么？同样一句话，日语可能需要3倍于英语的token数量。 这不仅推高了API调用成本（按token计费），还直接影响了模型的推理速度和质量。ThePrimeagen指出，这种"英语优先"的设计本质上是一种算法层面的语言霸权。
BPE词汇表是从训练数据中学习的。这意味着tokenizer的质量完全取决于训练数据的分布。如果你的训练数据中"www"出现频率极高，它就会被合并为一个独立token，即便这从语言学角度毫无意义。
ThePrimeagen特别提到了Andrej Karpathy在minbpe教程中揭示的一个经典案例：GPT-2的tokenizer把很多常见域名字符串合并成了单个token，这导致模型在处理URL时表现诡异。tokenizer在"学习"的是训练数据中的统计规律，而不是语言的内在结构。
BPE的切分经常产生人无法预测的结果。"play"可能是一个token，"playing"可能是两个token（"play" + "ing"），但"player"可能是三个。这种不一致性意味着模型对"同一个词根"的理解被切分方式人为地碎片化了。
ThePrimeagen在这里举了一个精彩的例子：对于程序员来说，这意味着"getString"和"get_string"在模型眼中是完全不同的token组合。你的命名习惯直接影响模型对你代码的理解质量。
视频中最具前瞻性的部分，是ThePrimeagen对T-FREE论文的解读。这篇来自Aleph Alpha和达姆施塔特工业大学的论文（EMNLP 2024发表），提出了一种完全不同的思路：干脆不要tokenizer。
T-FREE的核心思想是：不使用预训练的词汇表，而是直接在字符三元组（character triplet）层面操作，通过稀疏激活模式来表示文本。
具体来说： - 不把文本切分成subword，而是用字符三元组的稀疏组合来编码 - 每个字符三元组对应embedding空间中的一个固定位置 - 相同词根的词（如"play"、"playing"、"played"）自动共享大量激活模式
这意味着模型天然就能理解词根关系，不需要通过海量数据来"学习"这个规律。ThePrimeagen对这点的评价是："This is how it should have been from the start."
T-FREE的关键优势： - 跨语言公平性：字符级操作对所有语言一视同仁 - Embedding压缩：稀疏表示使embedding矩阵大幅缩小 - 形态学理解：天然捕捉词缀、词根等形态学关系 - 无需预训练tokenizer：去掉了整个pipeline中的一个脆弱环节
ThePrimeagen在视频中提出了一个尖锐的问题：既然tokenization问题如此明显，为什么主流模型还在用BPE？
答案很现实：换tokenizer的成本太高了。 整个AI生态——从训练框架到推理引擎，从API计费到评测体系——都建立在token之上。换掉tokenizer意味着：
这是一个典型的"技术债务"困局：当初的选择在短期内是最优的，但随着系统规模扩大，它变成了一个你无法摆脱的结构性枷锁。
我在这里补充一个ThePrimeagen没有深入展开的角度：Google在Gemini系列模型中已经尝试了SentencePiece等替代方案，但本质上还是BPE的变体。真正跳过tokenization的方案（如T-FREE、ByT5等字节级模型）目前在大规模训练中的效率还无法和BPE竞争。这不是技术问题，而是工程问题。
ThePrimeagen在视频后半段转向了一个更实际的话题：既然tokenization的问题短期内不会解决，作为开发者你能做什么？
理解tokenizer的行为可以帮你写出更高效的prompt。比如： - 避免使用会导致大量罕见token的表述 - 在代码生成任务中，使用token友好的命名规范 - 在多轮对话中，注意之前上下文是否引入了低效的token模式
ThePrimeagen算了一笔账：如果你的应用大量使用非英语文本，tokenization的低效可能让你的API成本翻3-5倍。考虑使用专门优化过多语言tokenization的模型（如Cohere的Command系列），或者在发送前做文本预处理来减少token数量。
知道LLM在字符级操作上的弱点，你应该在设计系统时加入防护： - 密码/密钥生成不要依赖LLM - 代码生成后加入编译检查和单测 - 对涉及精确字符串操作的任务，用传统代码而非LLM
mindmap
root((Tokenization问题全景))
根本缺陷
BPE切分丢失字符信息
词汇表英语优先
训练数据路径依赖
切分边界反直觉
实际影响
AI数不对字母
跨语言成本3-5倍
代码拼写错误
字符级操作失败
替代方案
T-FREE字符三元组
ByT5字节级模型
字符级RNN回归
稀疏表示+形态学
开发者应对
Token感知的Prompt工程
API成本优化
系统鲁棒性设计
选择合适模型
未来趋势
Agent系统绕过限制
多模态减少文本依赖
下一代架构可能抛弃BPE
工程瓶颈待突破
ThePrimeagen在视频结尾提出了一个哲学性的问题：如果AI连最基本的字符操作都做不好，我们谈论AGI是否为时过早？
这是一个值得深思的观点。Tokenization不只是一个小bug，它反映了一个更根本的架构问题：当前LLM对世界的理解是被人为压缩的。它们看不到像素、听不到声波、也无法数清字母——它们只能处理经过预处理的信息碎片。
不过，我也部分不同意ThePrimeagen的悲观态度。2026年的趋势表明，行业正在用两条路径绕过这个限制：
Tokenization可能是LLM时代的天花板，但它不会是AI时代的天花板。
看完这个视频，一个有技术背景的开发者能获得什么？
第一，架构决策的底层意识。 当你在选型LLM时，不再只看benchmark分数。你会问：这个模型的tokenizer对中文的支持如何？对我的业务领域文本的token效率怎样？这些问题的答案直接影响你的系统成本和用户体验。
第二，Prompt工程的降维打击。 大部分人写prompt还是在"说人话"层面。但如果你理解了tokenizer的行为，你可以做到"说机器能更好理解的话"——这就是token-aware prompting。这可能是2026年prompt engineering最重要的进化方向。
第三，对AI能力的理性预期。 知道LLM在字符级操作上的结构性弱点，你就不会在错误的地方抱有过高期待，也不会在AI犯错时完全失去信任。理解局限性是有效使用任何工具的前提。
Tokenization不是LLM的一个bug，而是一个设计选择——只不过这个选择的代价，我们现在才开始真正理解。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。