同一句中文被切成不同Token，跨模型蒸馏时会丢掉什么？

教师和学生读到的是同一句话，却可能不使用同一组“文字零件”。训练时用来指导学生的信号，还能原样传过去吗？

假设教师模型把一句话切成：

[知识] [蒸馏] [很好] [用]

学生模型却切成：

[知] [识] [蒸] [馏] [很好用]

如果只把教师生成的完整回答交给学生训练，这种差异未必会阻止蒸馏。学生可以用自己的Tokenizer重新编码整段文字。

但如果训练目标要求学生逐Token模仿教师，问题就变得具体了：教师第二个Token的判断，究竟对应学生的哪几个Token？如果文本是订单号、代码标识符或中英混排，边界错位会不会先影响这些内容？这里说的“监督信号”，就是训练过程中告诉学生“应该更偏向哪种输出”的信息。

这就是跨Tokenizer蒸馏的难点。它不是“中文分词不准”这么简单，也不能从一次切分示意直接推导出模型能力下降。本文先区分只传递文本和传递教师内部信号两种情况，后面的Token对齐难点主要针对后一种。

先给出本文的直接答案。在原始字符串、Unicode/字节处理（文本怎样保存和读取）、聊天模板（角色和分隔符格式）、截断和训练标签掩码都没有出错的前提下，只传递完整回答，通常不会因为切法不同而丢掉这段文字；但教师对其他候选写法的判断，以及这些候选项之间的相对偏好，无法仅凭最终字符串恢复，也通常不会随文本一起传给学生。若要把这些细节也教给学生，就必须解决词表和位置对不上的问题。对齐做得不好，首先损失的是监督信号的准确性；是否进一步损害中文、数字或代码能力，现有资料还不能给出统一结论。

这里要分清两个原因。只保存最终回答，本来就会舍弃其他候选项的分数，这不是Tokenizer差异造成的。跨Tokenizer额外增加的问题，是教师和学生的候选项与位置不同，想传这些分数也不能直接照搬。

本文是“知识蒸馏的能力、评测与风险”系列第四篇。前三篇分别讨论公开测评、教师模型预筛和风险继承，这一篇继续追到训练过程。本文只做公开资料分析与机制解释，不包含147AI自有测试，没有运行Tokenizer对比，也没有调用真实API或训练学生模型。文中的切分示例均为示意，不是某个模型的实测结果。资料查阅日期为2026年8月6日。

Tokenizer到底改变了什么

Tokenizer通常译作分词器，但它处理的并不只是中文里的词。它把文本切成模型使用的基本单位，再去词表中查出每个单位的编号。这里的词表，可以理解成模型自己的“零件目录”。一个Token可能是完整英文单词、词的一部分、一个汉字、多个常见汉字、数字片段、标点，或者代码中的一小段符号。

模型接收的不是“知识蒸馏”四个字本身，而是一串Token ID，也就是代表这些片段的编号。每个编号还会被转换成模型计算所需的一长串数字。生成时，模型预测下一个Token，最后再由Tokenizer把这些编号还原成人类能读的文本。

原始文本
   ↓ Tokenizer编码
Token序列与Token ID
   ↓ 模型计算
新的Token ID
   ↓ Tokenizer解码
输出文本

不同模型的训练语料、词表大小和文字预处理规则可能不同，所以同一段文本的切法也可能不同。即使两个Tokenizer采用同类算法，只要各自学到的词表不同，切分边界仍可能不一样。

切得更碎也不等于模型一定更差。在模型一次能处理的文本长度（上下文上限）固定时，更长的Token序列会占掉更多位置；生成步骤增加，也可能抬高延迟和计算量。最终能力仍取决于训练数据、模型结构和训练方法。API费用则应以服务返回的实际用量为准，不能拿一个未确认版本的本地Tokenizer替代账单口径。

两种蒸馏场景，问题不在同一个位置

跨Tokenizer问题首先要区分蒸馏信号是什么。

只蒸馏教师回答：基于文本的蒸馏

常见的做法是把教师生成的回答当作训练样本：

教师生成完整回答
    ↓
保存完整文本
    ↓
学生用自己的Tokenizer重新编码
    ↓
用这些问答样本训练学生（监督微调，也就是把教师答案当作学习目标）

在这种方式下，教师和学生不需要共享词表。教师输出以完整文本保存，学生再按照自己的规则编码。第二篇文章中的闭源教师API预筛实际保存的也是完整响应，但那次工作没有把响应拿去训练学生，不能称为蒸馏实测。

但这种做法也有代价。教师在生成每个Token之前，实际上会给词表里的许多候选项打分，再从中产生下一步输出。若数据只保存最终文本，其他候选项及其相对分数通常不会一起留下。学生能模仿教师说了什么，却看不到教师当时还考虑过什么。

把教师的内部判断也交给学生

如果团队能够访问教师模型内部，就不必只保存最后的回答。教师会为每个“下一个可能输出的片段”产生一组原始分数，这组分数通常叫 Logit；把它们换算后，可以看出模型对各种续写的相对偏好。它不是“答案在现实中有多大概率正确”。训练时还可以使用隐藏状态，也就是模型在中间计算阶段形成的数字表示。

能访问教师内部分数或中间表示的做法，常被称为“白盒蒸馏”。它能提供比最终文本更丰富的信号，但传统的逐Token比较通常要求两边的位置和词表能够对应。

如果教师和学生使用不同Tokenizer，同一句文本可能对应两个长度不同的序列：

教师：[知识] [蒸馏]
学生：[知] [识] [蒸] [馏]

在两边仍对应同一段文本和可比上下文时，教师某个Token位置的输出分布如何映射到学生的一个或多个Token位置，是跨Tokenizer蒸馏的核心问题；如果生成前缀已经不同，就不能只靠字符边界得到唯一映射。两边的词表大小和内容也可能不同：假设一边有十万量级的候选项，另一边有十五万量级，而且两份目录并不重合。这里的数字只是说明两份目录大小不同的示意，不对应特定模型。此时直接比较两组分数，没有明确含义。

“学生可以重新编码字符串”解决了基于回答的蒸馏所遇到的输入问题，却没有解决Token级概率对齐问题。这是两件事。

研究者怎样处理“零件对不上”

跨Tokenizer蒸馏已经形成一条研究线。这里的“对齐”，就是找出教师和学生哪些片段表达的是同一部分内容。问题不是“有没有办法做”，而是怎样减少这种匹配误差。下面介绍的是公开论文中的研究路线，不是对所有项目都适用的生产配置；选择方法前，还要确认教师能否提供Logit或隐藏状态、训练框架是否支持对应损失，以及目标任务是否覆盖论文评测范围。

先看一张简表。只想理解本文结论的读者，看完这张表可以直接跳到“哪些内容可能更容易受影响”。

方法路线	主要解决什么	直观理解
DSKD	两边的内部表示和词表不同	先把两张评分表换算到同一种格式
MultiLevelOT	一个教师Token可能对应多个学生Token	不强求一对一，寻找整体匹配
DWA-KD与SRA	两边序列长短不同、单Token边界不稳	允许序列伸缩，或改用更长片段
跨Tokenizer的On-Policy蒸馏	学生按自己的方式生成，教师再提供指导	学生先作答，教师再按对应位置纠正

路线一：先把两边的评分表换成同一种格式

《Dual-Space Knowledge Distillation for Large Language Models》讨论了一个基础问题：教师和学生各自使用自己的内部表示与词表给候选项打分，两张评分表的候选项和分数体系不同，即使勉强算出差值，也未必是在比较同一件事。

论文提出的 DSKD 通过统一输出空间，并结合跨模型注意力或映射机制，让两边的内部表示和输出分布变得可比较。面对不同词表时，它也需要处理教师Token和学生Token之间的对应关系。

这类方法解决的是“两张评分表怎样变得可比较”，不是证明任意中文任务都能无损迁移。

路线二：不强求一对一，寻找整体匹配

《Multi-Level Optimal Transport for Universal Cross-Tokenizer Knowledge Distillation on Language Models》不要求教师和学生做简单的一对一匹配。它把对齐想成货物运输：教师的一块信息可以分配给学生的多个Token，算法寻找整体代价较低的分配方案。论文把这种方法同时用在单个Token和整段序列上。

论文在问答和摘要任务中比较了不同方法，报告 MultiLevelOT 在其实验设置下优于拿来比较的其他方法。对本文主问题来说，重要的是它允许“一块对多块”，不再强行按位置编号配对。论文中的具体距离算法属于实现细节，本文不展开。

但“在论文任务上更好”不等于“所有文本类型都没有损失”。这项工作主要报告总体任务表现，并没有给出中文汉字、长数字、代码标识符或URL的统一损失排序。

路线三：按上下文或更长片段对齐

2026年的《DWA-KD: Dual-Space Weighting and Time-Warped Alignment for Cross-Tokenizer Knowledge Distillation》会根据教师和学生输出分布的不确定性或熵来设计位置权重。它还允许两条长短不同的Token序列伸缩配对，不要求第几个位置必须对应第几个位置。论文把这种可伸缩的序列匹配称为 Soft-DTW，读者把它理解成“允许序列拉伸后再对齐”即可。

同年提出的《SRA: Span Representation Alignment for Large Language Model Distillation》更进一步，把对齐单位从单个Token换成由若干Token组成的文本片段（论文称为 Span）。比如不再争论“蒸”和“馏”分别对应哪里，而是先把“蒸馏”视为一个片段，再比较两边对这个片段形成的内部表示。

这两个方向给出了一条重要提示：如果单个Token边界太脆弱，可以尝试对齐更长的片段或更抽象的表示。不过，方法在论文中的平均分提升，仍然不能直接回答“哪类中文、数字或代码最容易受伤”。

路线四：当学生自己回答时，教师再来纠正

《Breaking the Tokenizer Barrier: On-Policy Distillation across Model Families》讨论的是On-Policy蒸馏。简单说，训练样本不再全部来自教师的标准答案。学生先按自己的方式生成一段回答，教师再针对这段回答中的生成位置提供指导，因此训练时遇到的内容更接近学生实际使用时可能生成的内容。这里的“跨模型家族”，指教师和学生来自不同系列，而不只是同一系列中的大小版本。

作者指出，很多这类方法要求教师和学生共享Tokenizer。跨模型家族时，实践中常退回到“收集教师回答再微调”，于是放弃了教师对各个候选Token的细粒度分数。

这项工作提出Token映射方法，让On-Policy蒸馏跨不同Tokenizer运行，并报告在其基准和计算设置下优于对照方法。它说明这条路线可以走通，但仍没有把所有文本类型的损失机制讲完。不同模型家族、映射方法和部署任务之间是否存在稳定的选择性损失，仍需单独验证。

哪些内容可能更容易受影响

下面的表格描述的是待验证风险区，不是已经证实的普遍规律。

文本类型	可能出现的对齐问题	可以观察的指标
常用中文	常见词组在不同词表中被拆成不同长度	Token数量、切分边界重合率
生僻字与专有名词	词表中可直接使用的完整片段可能较少	片段长度、每百字符Token数
长数字与金额	位数边界不同，数值片段难以对应	数字分段、算术或复制准确率
代码标识符	下划线、大小写和单词片段的切法不同	标识符完整率、代码测试通过率
URL与文件路径	符号密集，边界容易错位	URL复制准确率、链接可用率
中英混排	两个模型合并中英文片段的方式不同	混排片段长度、任务准确率

“Token数量更多”只能说明序列编码更长，不能直接证明下游能力下降。表中的“切分边界重合率”需要先规定边界单位；如果按Unicode码点统计，就应明确组合字符和特殊Token怎样处理，不能和UTF-8字节边界混用。一个可行的定义是，用两套切法共有的边界数，除以两套切法所有不同边界组成的并集数量；“每百字符Token数”也应说明分母按Unicode码点还是其他字符计数。它们都是诊断指标，不是模型能力分数。真正的损失需要经过训练，并在独立的中文、数字、代码或混排测试集上验证。

看到切分图时，先别把它当能力排名

本文没有运行Tokenizer对比，因此不会给出任何具体模型的真实切分数量。文章开头的方括号只是示意。即使以后做本地演示，也需要同时查看普通中文、长数字、代码、中英混排和URL，而不是挑一句效果最夸张的文本：

普通中文：退款将在三个工作日内到账。
长数字：订单号为202608051472。
代码：get_user_profile(user_id)
中英混排：调用getUserInfo接口。
URL：https://api.example.com/v1/chat/completions（示意地址）

切分结果还会受到Tokenizer具体版本、文字预处理（例如怎样处理空格）和特殊Token规则影响。所谓特殊Token，是模型用来表示句子开始、结束或角色边界的控制标记。如果版本或这些设置变了，重新统计的结果也可能变化；同一版本、同一设置下通常可以复现。

这种演示只能回答“不同Tokenizer怎样切分同一文本”，不能回答“学生能力下降了多少”。只有实际训练学生，并用独立任务评测，才能讨论能力损失。

这对蒸馏工程意味着什么

第一，先确认自己采用的是哪种蒸馏信号。只收集教师回答时，重点是数据清洗、文本能否正确还原，以及学生能否重新编码；需要教师内部原始分数（Logit）或隐藏表示时，则要先确认原始字符串、Unicode/字节处理、聊天模板、截断和loss mask（哪些位置计入训练损失）保持一致，再设计两张评分表以及不同位置如何匹配。

第二，不要只记录平均Token数。中文、数字、代码和URL可能有不同的边界风险，应该按文本类别分开统计。一个总体平均值很容易把不同类别之间的差异混在一起。

第三，保留对齐记录。至少保存教师和学生的Tokenizer名称与版本、特殊Token规则、原始文本、映射关系和训练方法。这里的“映射关系”就是记录教师的一段Token最终对应学生哪些Token。否则，下一次换模型后，很难判断能力变化来自模型本身、Tokenizer，还是对齐实现。

第四，把对齐指标和任务指标分开。边界一致率高，不等于代码一定能运行；Token膨胀率低（先指定一套Tokenizer为比较基准，再看同样文本的Token数量增加了多少），也不等于中文问答一定更准。它们是训练诊断信号，不是业务结论。

如果团队通过多个教师模型生成“只保存完整回答”的蒸馏数据，可以考虑使用147AI等OpenAI兼容服务，让调用脚本保持一致，并在服务确实返回这些字段时保存完整响应、模型ID和用量信息。具体是否返回usage、Logit或其他教师信号，要按实际使用日期的接口文档和响应样例核对。接口统一只解决接入层差异，不保证提供论文所需的完整教师Logit，也不会替团队完成跨Tokenizer对齐或学生训练评测；模型ID和价格变化也需要单独留档。

现在还不能回答什么

现有论文已经给出多种跨Tokenizer对齐方法，但还缺少一套能够跨模型家族复用的“文本类型与能力损失”地图。本文资料回答不了几个实际问题：

• Token序列变长，能否预测某类任务会损失多少？
• 数字、代码和中英混排是否存在跨方法都稳定的高风险区？
• 把对齐单位从Token换成长片段，是否更能保护中文和代码结构？
• 训练中的对齐误差下降后，真实任务是否也会同步改善？

这些问题需要实际训练学生模型，再用没有参与训练的测试样本，按文本类型分别评测。仅仅比较Tokenizer输出，最多建立一个值得继续验证的假设。

结语

跨Tokenizer蒸馏真正麻烦的地方，不是把一段文字重新编码，而是判断教师的一个片段，应该以什么形式成为学生的监督。

教师和学生可以处理同一句中文，却未必用同一组Token表达它。只收集教师回答，可以绕过一部分词表差异，但会放弃教师对其他候选项的细粒度判断；使用Logit或中间表示进行蒸馏，保留的信号更丰富，却必须让两张评分表、两条不同长度的序列和各自的切分边界正确对应。

现有研究说明，跨Tokenizer蒸馏可以做，也已经有不少方法在公开任务上取得改进。它们还没有证明中文、数字或代码会按固定顺序退化。真正稳妥的做法，是先确认蒸馏信号，再记录Tokenizer版本和对齐方式，最后用分类型任务评测学生到底保留了什么。

参考资料

1. Songming Zhang et al., Dual-Space Knowledge Distillation for Large Language Models, arXiv v3，EMNLP 2024 camera-ready版本。
2. Xiao Cui et al., Multi-Level Optimal Transport for Universal Cross-Tokenizer Knowledge Distillation on Language Models, arXiv v2；论文注明被AAAI 2025接收。
3. Duc Trung Vu et al., DWA-KD: Dual-Space Weighting and Time-Warped Alignment for Cross-Tokenizer Knowledge Distillation, arXiv v1，EACL Findings。
4. Quoc Phong Dao et al., SRA: Span Representation Alignment for Large Language Model Distillation, arXiv v2，ACL 2026。
5. Yifan Niu et al., Breaking the Tokenizer Barrier: On-Policy Distillation across Model Families, arXiv v1，2026年6月8日提交。