Liquid AI 原地扩展 LFM2.5-8B-A1B 的 tokenizer 至 128K
Tokenizer Expansion: Upgrading a Model's Tokenizer in Place
Liquid AI 发布 LFM2.5-8B-A1B 的新 tokenizer,在不从头重训的前提下把词表从 65K 原地扩展到 128K。做法是冻结原有 BPE 合并规则后继续训练,新 token 的嵌入向量取其子 token 的均值,再分两阶段适配:先只训练新嵌入行 600B token,再全参数继续预训练 400B token。
原文给出原地扩展 tokenizer 的两阶段配方与逐语言压缩、解码数据,可迁移到自有模型的词表升级。
今天,我们分享 LFM2.5-8B-A1B 中新分词器背后的方法。它就地升级预训练模型的分词器,无需从头重新训练。我们将词表从 65K 翻倍到 128K,以修复原分词器切分过细的语言。印地语和越南语现在分别少用约 2.4× 和 2.6× 的 token,泰语最多少用 4.0×,我们估计这使这些语言在端侧按字符解码快 2.2 到 3.7×。模型原本处理良好的语言质量保持稳定。
LFM2.5-8B-A1B 已在 Hugging Face 上提供,扩展后的 128K 分词器也随之一同发布。完整方法、消融实验和各设备数据见技术报告。
为什么端侧分词器一直很小
分词器在预训练开始时就被固定,它按当时训练语料的样子来分配词表。在那个时间点代表性不足的语言,每个词会被拆成比分词器所针对的语言多得多的 token [1, 2]。由于模型每输出一个 token 就要运行一次解码器,这种额外的碎片化会给这些语言的用户带来真实的延迟、计算和能耗成本。
云端模型可以把这一成本隐藏在庞大的词表之后,因为嵌入矩阵和输出(LM-head)矩阵只占其参数的一小部分。而在小型端侧模型上,情况并非如此。在 batch size 为 1 时(这通常是我们在端侧关心的场景),解码受内存带宽限制,而 LM-head 在每一步都要读取整个词表。更大的词表意味着每个 token 都要流式读取更大的矩阵,并常驻 RAM,因此边缘模型通常采用紧凑的词表,并忍受其优先语言之外的碎片化。
LFM2 最初的 65K 字节级字节对编码(BPE)[3, 4] 分词器是为英语、代码和一组固定语言构建的,几乎没有给印地语、越南语或泰语留出预算。我们想在一个已经训练好的检查点上解决这个问题。重新训练分词器并再次预训练会浪费那些算力,而直接换上一个无关的第三方分词器则会迫使我们解决一个比所需更难的迁移问题 [5]。
方法:扩展,而非替换
我们的分词器扩展方法分两部分:构建新分词器,然后让模型适配它。由于分词器由我们自己设计,我们可以把新分词器构建为旧分词器的直接扩展,这使下游的一切都保持简单。
1. 继续 BPE 合并
BPE 分词器由一组有序的合并规则定义,这些规则将较小的 token 组合成较大的 token。在我们的方法中,我们用原始合并规则初始化新分词器的合并表,将其冻结,并在多语言语料上继续 BPE 训练。这带来两个有用的性质。第一,原始 65K 个 token 中的大多数原样保留,因此它们学到的表示可以直接迁移。第二,每个新 token 都能精确分解为一系列原始 token。
2. 用模型已知的信息初始化新嵌入
这种精确的分解方式让新 token 的嵌入初始化变得很简单。保留下来的 token 保留其原始嵌入行。每个新 token 取其子 token 行的均值。没有任何随机初始化,也不需要处理跨分词器的对齐问题。由于 LFM2.5-8B-A1B 将输入和输出嵌入绑定在一起,一个矩阵即可同时覆盖两者。
3. 分两个阶段适配模型
一次性训练所有参数会损害模型中原本已经正常工作的部分,因此我们将适配拆分为两个阶段,二者都在常规的中期训练和后训练之前运行:
- 阶段 1,仅嵌入层。在模型其余部分冻结的情况下,仅用 600B token 训练新的行。新 token 在不干扰主体的情况下稳定下来,仅此一步就能恢复替换时损失的大部分质量。
- 阶段 2,完整继续预训练。解冻所有参数,并在 400B token 的均衡多语言混合数据上继续预训练。这将新词表融入模型主体,并弥合剩余的差距。
阶段 2 之后,检查点可直接接入标准的 LFM2.5 流水线,无需其他改动。
新分词器带来了什么
主要收益体现在我们最需要的地方——压缩率。英语和代码按设计保持持平,而我们原本已支持的语言略有改善,此前分词不足的语言则大幅改善。
缩减幅度最大的是泰语(4.0×)、孟加拉语(3.4×)、越南语(2.6×)和印地语(2.4×)。
下面是同一句话在多种语言中分别由旧分词器和新分词器分词的结果。
更少的 token,更快的解码
只有当节省的开销超过更大词表的成本时,每词更少的 token 才有意义。从 65K 增加到 128K 会使我们参考设备(M4 Max CPU 和 GPU,以及 Snapdragon 8 Elite Gen 5)上的每 token 解码速度降低 7% 到 10%,因为每一步都要读取更大的 LM-head。用户实际感受到的是每字符的时间,而不是每 token 的时间。将压缩率与每 token 成本结合起来,得到下面的净结果。
这正是我们设计的权衡。此前服务不足的文字系统获得了大幅加速,而旧分词器已经处理良好的语言则承担了少量、均匀的每 token 成本,表现为最高约 9% 的解码回退。对于我们目标语言和设备而言,这一权衡非常值得。我们止步于 128K,因为将词表进一步扩大在手机上带来的吞吐量损失(在 Snapdragon 上 256K 时高达 37%)远超额外压缩率所能带来的收益。
质量保持稳定
只有当原地升级能在不放弃模型已有能力的前提下增加覆盖范围时,才值得去做。为了将分词器变更与后续训练区分开来,我们在四个受控节点上追踪一个八项基准的聚合指标:源模型、零样本替换、阶段 1 和阶段 2。
恢复过程是稳定的。替换损失了 5.8 个聚合分,阶段 1 赢回了其中的 4.8 分,阶段 2 恢复了剩余部分并超过了源模型。超出源模型的部分很可能反映的是阶段 2 中额外的 400B token 预训练,而非词表变更本身。重要的是,扩展后的模型在使用 128K 分词器的同时,在知识、数学、代码和多语言基准上保持或提升了表现。
按语言划分的 Global-MMLU [6] 同时展示了目标的两半。我们已经支持的语言保持稳定,而分词不足的语言则有所提升:
适用范围
这套方案适用于一种特定情况:你拥有分词器,并且可以继续其原始的 BPE 合并,这需要原始的合并规则和特殊 token 配置。当你转向现成的第三方分词器时,它就不适用了,此时零样本迁移方法才是正确的工具 [5]。阶段 2 还会消耗一些持续预训练算力,因此当原始训练运行足够昂贵、复用比从头开始更划算时,这种方法收益最大。
开始使用
LFM2.5-8B-A1B 以开放权重形式在 Hugging Face 上发布,采用 LFM Open License v1.0,并提供 llama.cpp、MLX、vLLM 和 SGLang 的部署指南。扩展后的 128K 分词器随权重一同发布。你可以在技术报告中找到完整方法、消融实验和各设备数据。
引用
如果你使用这项工作,请引用技术报告:
Jimmy T.H. Smith, Tarek Dakhran, Alberto Cabrera, Simon S. Lee, Paul Pak, Aditya Tadimeti, Tim Seyde, Maxime Labonne, Alexander Amini, and Mathias Lechner (2026). In-Place Tokenizer Expansion for Pre-trained LLMs. arXiv:2607.15232.
参考文献
[1] Aleksandar Petrov, Emanuele La Malfa, Philip H. S. Torr, and Adel Bibi. (2023). Language model tokenizers introduce unfairness between languages. NeurIPS. https://arxiv.org/abs/2305.15425
[2] Phillip Rust, Jonas Pfeiffer, Ivan Vulić, Sebastian Ruder, and Iryna Gurevych. (2021). How good is your tokenizer? On the monolingual performance of multilingual language models. ACL-IJCNLP. https://arxiv.org/abs/2012.15613
[3] Rico Sennrich, Barry Haddow, and Alexandra Birch. (2016). Neural machine translation of rare words with subword units. ACL. https://arxiv.org/abs/1508.07909
[4] Alec Radford, Jeff Wu, Rewon Child, David Luan, Dario Amodei, and Ilya Sutskever. (2019). Language models are unsupervised multitask learners. OpenAI Technical Report. https://shorturl.at/hHoQR
[5] Benjamin Minixhofer, Edoardo M. Ponti, and Ivan Vulić. (2024). Zero-shot tokenizer transfer. NeurIPS. https://arxiv.org/abs/2405.07883
[6] Shivalika Singh 等(2024)。Global MMLU:理解并解决多语言评估中的文化和语言偏见。arXiv。https://arxiv.org/abs/2412.03304
来源:Liquid AI Blog · liquid.ai