80M参数实验给了我一记重锤：Token 越小，模型反而越难学

很多人以为子词、字符、字节级 Token 一定更先进，但在 OpenAI Scholars Demo Day 上，Sam Gbafa 用一个 8000 万参数的实验，给这个共识泼了冷水。结果不但反直觉，还直接影响你今天怎么选 tokenizer、怎么配上下文窗口。

一个被严重低估的问题：模型到底“读”的是什么

在大模型时代，我们讨论参数、算力、数据，却很少认真问一句：模型眼里的“文字”到底长什么样？Sam Gbafa 的项目切口非常小，却极其致命——tokenization。他做的不是造一个更大的模型，而是把同一个 12 层 decoder-only Transformer（约 8000 万参数），在完全相同算力、相同上下文长度下，喂给它三种世界观：词级、子词级、字符级。

这件事之所以重要，是因为 tokenizer 决定了模型的最小认知单元。你让模型用“单词”理解世界，它学到的是词与词的关系；你拆成字符，它必须先在内部“拼词”，才能谈语义。这不是工程细节，而是认知路径的选择。

最反直觉的结果：子词，没有赢

在实验前，Sam 自己的预期是：子词 > 字符。因为过去大量工作都表明，更细粒度的分词有助于泛化。但结果恰恰相反：字符级模型在这个设置下，表现优于子词模型。

原因并不玄学，而是非常“工程化”：数据规模太小。实验用的是 Penn Treebank 级别的数据，词汇量大约 1 万；但子词 tokenizer 却设到了 4 万词表。这直接导致模型在子词空间里学得很散，泛化反而更差。

Sam 在这里点出了一个经常被忽略的事实：tokenizer 不是越精细越好，而是必须和数据规模、模型容量一起配套。小模型 + 小数据 + 大词表，是非常容易翻车的组合。

字符、字节、上下文窗口：你迟早要还的债

字符级和字节级看似优雅，但代价也很残酷：上下文长度被迅速吃光。Sam 用了一个简单但致命的对比：同一句话，11 个单词，对应 59 个字符。

这意味着什么？如果你想让模型“看到”同样多的信息，字符级模型的 context length 必须显著更长。而 Transformer 的计算复杂度，大家都知道。

这也解释了一个现象：为什么很多多语言模型、字节级模型，最后都走向了更大的模型规模。因为当 token 足够小，语义不是消失了，而是被推迟到了更深的层里——模型得先学会“拼字”，才能谈“理解”。

从 Token 到多模态：这不是文本问题

在 Q&A 里，Sam 把话题抬到了一个更大的层面：tokenization 和多模态有什么关系？他的答案很克制，但信息量极大——学习分割（segmentation）本身，可能是一种通用能力。

在文本中，学习子词边界能提升泛化；在多语言翻译中，学会跨语言的分割方式能显著提升性能。那在图像、音频、视频里呢？如果模型能自己学会“什么是一个有意义的片段”，而不是人类强行规定 patch、frame、byte，那多模态模型的上限可能会被重新定义。

换句话说，tokenization 不是 NLP 的遗产，而是通向多模态的入口。

总结

这场 Demo 的价值，不在于跑赢了谁，而在于它提醒了一个残酷现实：tokenization 是建模决策，不是预处理步骤。如果你在做模型训练，今天就该重新审视三件事：你的 tokenizer 是否匹配数据规模？上下文窗口是否真的够用？模型容量是否能“消化”更细粒度的表示？

再往前一步，这个问题迟早会从文本蔓延到图像、音频、视频。未来真正强的模型，可能不是用了哪种 tokenizer，而是学会了什么时候、如何去“切分世界”。这个能力，才是真正的通用表示。

关键词： Tokenization， Transformer， 上下文窗口， 大语言模型， 多模态

事实核查备注： 需要核查：模型参数规模（约8000万）、模型结构（12层 decoder-only Transformer）、子词词表大小（4万）、字符词表规模（约50+）、使用的数据集（Penn Treebank、Wikipedia、WSJ）、视频发布时间（2021-05-10）