这周 LocalLLaMA 论坛上有个不起眼的小实验，但结果让我们编辑部多看了两眼：有人把同一段 330 行的 HTML/JS 代码分别喂给 Qwen 35B 和 Gemma 26B，两款参数规模相近的开源模型，token 化（把文本切成模型能理解的最小单位）出来的数字分别是 1609 和 4258，差距接近 2.6 倍。

这是什么

这件事的本质是两款模型的"分词器"（tokenizer，决定模型怎么把人类文字拆成自己认识的小块）从一开始就走上了不同的路。Qwen 的分词器在面对代码时，显然更倾向于把整段结构当成"代码模式"来切，颗粒度更粗；Gemma 则沿用接近自然语言的切法，把代码也当成普通英文拆。结果是同一段代码，在 Qwen 眼里是 1609 个有意义的"积木"，在 Gemma 眼里是 4258 块零碎词。

这直接影响两件事：一是上下文窗口的利用效率，二是模型对代码结构的"感知"。颗粒度细未必是坏事，但同一段代码被切成 2.6 倍的 token，意味着 Gemma 在理解和生成时不得不处理更多噪音。

行业怎么看

支持这一观察的证据不少。社区里长期有印象：Qwen 系列在编程任务上口碑稳定领先，Gemma 则更像"擅长聊天的语言模型"。一个反面的声音是，LiquidAI 这类团队正在做的事——给已有模型重新训练更高效的分词器——如果成功，Gemma 的短板有可能被补上。但反过来也有开发者指出，分词器只是起点，决定模型上限的还是预训练数据分布和后训练（post-training，即模型基础训练完成后的微调与对齐阶段）策略；换了分词器未必能让 Gemma 立刻追上 Qwen 的代码能力。我们认为，分词器差异是必要条件而非充分条件，但它确实是被长期低估的一个变量。

对普通人的影响

对企业 IT：如果正在选型开源模型做代码助手或内部工具，Qwen 系的代码能力优势不只是"训练得好"，分词效率也意味着更省推理成本、更长上下文能装下。

对个人职场：用 AI 写代码的普通员工不必懂分词器，但可以记住一个经验：同一段提示词丢给不同模型，输出风格可能差很多，这不是你 prompt（提示词）写得不好，是底层机制就不一样。

对消费市场：国内大模型公司正在把 Qwen 当作"开源门面"输出，背后是中国团队对工程细节的把控；这件事值得传统行业决策者注意，开源不是慈善，是竞争。