跳到正文
RadarAI· Hugging Face 社区博客(混合发现)·· 4 小时前AI 评分58

Dharma-AI 用 VocabX 专精 SLM 词表,实测推理成本降低 77%

如何通过专精 SLM 词表将实际应用推理成本降低 77%

AI 导读

Dharma-AI 在 Hugging Face 博客介绍即将发表的 VocabX 论文,基于 Qwen3-4B 的葡萄牙语作文评分器在基座模型、数据和训练配方不变的情况下,仅重建词表就把实测推理成本降低 77%,平均输出从 350 个 token 降到 101 个。

正文 · AI 翻译

Hugging Face 社区博客·2026-10-22 01:35· 1 小时前AI 评分45

专精 SLM 词表如何在真实应用中将推理成本降低 77%

AI 导读

基于 Qwen3-4B 的葡萄牙语作文自动评分器通过 VocabX 方法重建词表,在基座模型、数据和训练配方不变的情况下将实测推理成本降低 77%。该方法按每个 token 的成本而非词频来专精词表,使输出层从约 152,000 行缩减到约 65,000 行。原文指出生成 token 的成本约为读取 token 的 7.4 倍,词表是领域专精模型最大的成本杠杆之一。

正文 · 原文

通过微调 Qwen 和 Gemma 等通用开源模型而针对某一领域或任务专精的模型,会继承一个为多领域和通用应用构建的词表。

在我们生产环境中运行的作文评分器中,该词表将模型最常写出的文本切分成了许多 token。本文预览了 VocabX 论文的部分结果(论文即将发布):我们如何围绕每个 token 的成本而非其频率来专精词表,并在不改变基座模型的情况下将实测推理成本降低 77%。

Same sentence, fewer tokens: 14 tokens with the base tokenizer, 4 with VocabX

分词器通常被视为基座模型的固定属性,被继承下来并保持原样。对于专精于单一领域的模型,它可能是最大的成本杠杆之一,而且它在任何训练步骤之前就已确定。

我们在生产环境中运行的系统之一是一个葡萄牙语作文自动评分器,基于 Qwen3-4B 构建。它接收作文、题目和支持文本,并返回一个 JSON 评估,包含分数和针对每项能力的评语。

该模型本身已经很小,只有 40 亿参数,并且已经针对该任务进行了训练。然而,它的分词器仍然是原始的 Qwen3-4B 分词器,为多种语言和多种文本构建。在评分器中,它只用于单一语言葡萄牙语和单一响应格式。这带来了两项成本:评分器在每次请求时写出的文本占用了超出所需的 token 数,并且每生成一个 token,模型都要对 151,669 个词表条目进行打分,其中许多条目该任务几乎从不使用。

我们用一种称为 VocabX 的方法重建了该词表,保持相同的基座模型、相同的数据和相同的训练配方。本文中的数字来自论文的当前版本,该论文仍在评审中,发布前可能有所变动。

为所有人构建的词表

领先的语言模型以 token 读写,而分词器决定文本如何变成 token。领先的通用模型的分词器是在来自许多领域和语言的大量文本集合上训练的,从源代码到合同再到中文。对于通用模型来说,这一选择是合理的。

对于在单一领域使用的模型,它同时造成两种浪费。

第一种是碎片化。分词器恰好把该领域重复最多的内容切分成许多片段。在评分器中,每个响应都以相同的 JSON 外壳、相同的能力名称、相同的评估短语开头。在合同中,是样板条款。在代码中,是标识符。这些序列每一个都花费多个 token,而一个 token 本可足够,并且模型在每次请求时都要为每一个付出代价。

The span the grader writes in every response takes 12 tokens with the base tokenizer and 1 with VocabX

第二是冗余。词表包含数万个该领域从不使用的条目,而模型在生成的每个 token 上都会为所有这些条目计算分数。一个针对美国中学生物考试评分调优的模型几乎不会用中文写作,但它在每一步都会计算每个中文 token 的概率。词表把该领域最常重复的内容拆成许多片段,同时包含该领域从不使用的条目。

151,669 vocabulary entries in the base tokenizer, 64,767 with VocabX

读取便宜,写入昂贵

自然的反应是统计 token 数量并设法减少数量。但数量并不是账单。

要理解为什么生成的 token 成本更高,需要看看推理是如何工作的。它有两个阶段。在预填充阶段,模型通过一次网络前向传播处理整个输入:从 GPU 内存读取的每个权重都会为每个输入 token 复用,限制因素是计算。在解码阶段,模型一次生成一个 token,每个 token 都需要一次完整的前向传播。每次权重读取只被使用几次,GPU 大部分时间都在等待数据从内存到达:限制因素变成了内存带宽。

这种效应在我们实际运行的场景中最强:以中等批次服务的小模型。批处理请求将权重读取分摊到多个请求上,缓解了问题,但并未解决。在每个解码步骤中,模型还会读取 KV 缓存,即保存已处理上下文并随上下文增长的注意力内存。在我们测量的案例中,评分器生成一个 token 的成本是读取一个 token 的 7.4 倍,但该比例会随硬件、问题、批次大小、上下文长度和其他因素而变化,并且可能更大。总的来说,方向是成立的:生成比读取更昂贵。

In the case we measured, writing a token cost 7.4 times reading one

想象一家航运公司按箱子收费,但寄出箱子的费用是收到箱子的七倍。减少箱子总数有帮助。减少寄出箱子有帮助七倍之多。一种对输入和输出同等压缩的方法会错过大部分可能的节省。

账单的第三个组成部分是词表本身。模型的最后一层,即 LM head,将内部状态转换为每个可能 token 的分数。为此,它为每个词表条目保留一行参数。在 Qwen3-4B 规模的模型中,该矩阵几乎占参数的 10%。大模型可以不知不觉地吸收这一份额,但它对小模型造成负担。

而且这笔成本不是只付一次。输入层只查找正在读取的 token 所在的行,但 LM head 会为每个生成的 token 读取并乘以整个矩阵。由于解码已经受内存带宽限制,每一行额外数据都意味着每一步要移动更多数据。一个该领域从不使用的条目与一个频繁使用的条目成本完全相同。这就是为什么添加 token 可以同时降低数量并提高账单。VocabX 在其选择标准中不包含这一项,但它通过两个步骤控制词表大小:子词合并用更小的、领域特定的词表替换基础词表,而宏在固定预算下进入。在评分器中,输出层从约 152,000 行减少到约 65,000 行。

为什么现有解决方案不够

调整模型的词表并不是新想法。文献中的参考方法,如快速词表迁移(FVT)、多词分词(MWT)以及 Liquid AI 的原地分词器扩展(in-place BPE,从原始词表继续 BPE 训练),已经能减少碎片化。当我们在自己的问题上测试这些方法时,发现了两个局限。

它们按频率而非成本选择 token。对它们来说,一个在输入中频繁出现的表达,比一个在响应中出现较少但服务成本更高的表达更有价值。

它们只作用于单一层面。它们要么调整单词被切分成片段的方式,要么将整个短语合并为一个 token。这三者都没有在同一标准下同时做到两者。而评分器的最大浪费恰恰在于长而重复的片段,例如 JSON 外壳,子词方法只能通过逐个合并各部分才能触及。

我们如何解决

VocabX 解决了这两个局限,以及一个在解决第一个问题的显而易见路径上出现的第三个问题。

首先,我们改变了问题。我们不再问候选 token 能节省多少个 token,而是问它能节省多少成本和时间。每个被消除的 token 都乘以它所在字段的价格:系统提示、用户消息或模型响应。在我们测量的案例中,评分器响应中节省的一个 token 价值是输入中节省的一个 token 的 7.4 倍,词表据此构建。

其次,我们同时作用于两个层面。回到航运公司的例子:你可以通过更好地打包每件物品来切割箱子,或者通过认识到同一套十二件套件每周都发货、将套件装进一个箱子来切割。VocabX 两者都做。在子词层面,它重建领域词被切分成片段的方式。在多词层面,它寻找重复的整个片段,从短表达式到整行和 JSON 外壳,并将每个转换为单个 token,我们称之为宏 token。两个层面都在相同的成本标准下选择,各自有自己的预算。

Twelve boxes become one, and 7 tokens become one macro token

为了找到这些片段,我们使用了五个挖掘器,自动搜索在语料库中重复出现的片段,每个专门针对一种重复类型:长词、整行、表达式、完整句子,以及带标点的结构,如 JSON 和标签。在八个语料库上平均,最后一个贡献最大,在代码上它单独就占了 17.5 分。如果没有全部五个,评分器上的 token 减少量将下降 55.6 分。

Two layers, one cost criterion

第三,我们估计样本看不到的内容。按成本选择 token 需要知道每个候选在已选 token 之后还能节省多少。精确测量这一点需要在每次选择后重新处理整个语料库,数万次。在大规模下做到这一点的常见方法是在文档样本上测量,然后样本中不存在的候选获得零收益。

一个在 50,000 份文档中出现 37 次的表达式,在 400 份文档的样本中只有约 26% 的概率出现。在合同语料库中,只有 16.6% 的候选出现在 400 份文档的样本中;其余的从未被评估。

None of the 37 occurrences lands in the 400-document sample

候选词的收益分为两部分。一是它在整个语料库上能节省多少,这可以精确计算,无需采样。二是这部分节省中有多少尚未被已选出的 token 覆盖,只有这部分需要估计。对于采样看不到的候选词,我们根据可见候选词的行为进行统计估计,而不是将其视为零。在采样中罕见但在语料库中频繁的候选词重新进入候选行列。

仅这一项改动,在相同采样和相同预算下,将合同语料库上的 token 缩减率从 44.7% 提升到 52.8%。

With an estimate instead of zero: 44.7% to 52.8% token reduction

评分器的变化

为了衡量真实效果,我们用相同的基础模型、相同的数据、相同的配方和相同的随机种子训练了七个版本的评分器。它们之间唯一的区别是分词器。所有版本都在同一台测试机器上运行相同的 500 个请求,配备 RTX 5090 GPU 和 vLLM 推理服务器,成本根据实测运行时间计算。

Grader results: 77.0% cost reduction, bench score from 0.703 to 0.810

模型的响应平均从 350 个 token 降至 101 个 token。成本下降了 77.0%。质量以基准分数衡量,该分数综合了评分准确率以及筛选离题或违规文章准确率,从 0.703 上升到 0.810。

实现这一目标需要一次方向修正。词表的第一版将每项能力的评分与周围的 JSON 融合为单个宏 token。这是最紧凑的方案,但质量下降了:其基准分数为 0.689,低于生产评分器的 0.703。当评分被包含在宏 token 内时,评分与结构的每种组合都成为同一 token 的不同变体,模型在一步中同时选择两者。让评分拥有自己的 token 使每次响应多花 2 个 token,将基准分数提升到 0.810,并且在测量中甚至更便宜:缩减了 77.0%,而融合版本为 73.3%。

这一教训适用于评分器之外。当被压缩的片段承载的正是模型存在的目的所要做的决策时,压缩是有代价的。目标不是尽可能最便宜的词汇表,而是保留重要 token 的最便宜词汇表。

评分器之外

为了查明这一收益是否特定于我们的场景,我们在五个公共领域(合同、医学论文、科学论文、新闻和 Python 代码)和三个模型系列(Qwen3、Llama-3.1 和 Gemma-3)上,将 VocabX 与三种参考方法进行了比较。所有方法使用相同的挖掘和测试文档,以及相同的词汇表上限。

VocabX 在所有十五种组合中都比最强的参考方法压缩得更多,高出 1.2 到 9.3 个百分点。在估计推理成本方面,VocabX 的剪枝版本也在所有十五种组合中领先,在 Qwen3 上平均领先 10.2 个百分点,在 Llama-3.1 上领先 7.5 个百分点,在 Gemma-3 上领先 13.6 个百分点。在合同上,剪枝版本以 113,426 个词汇表条目达到 62.6% 的 token 缩减率,而最佳就地 BPE 配置为 61.8%,其使用了 207,803 个条目。

VocabX average lead: +10.2 (Qwen3), +7.5 (Llama-3.1), +13.6 (Gemma-3) points

只为重要的 token 付费

VocabX 不会让模型变得更聪明。它让模型不再为不需要逐段写出的文本付费,也不再为永远不会使用的词汇表评分。在我们的评分器中,在相同的基础模型和相同的训练配方下,这将实测推理成本降低了 77%。

专业化通常从数据和权重开始。它也可以早一层开始,从词汇表开始。

完整方法、每个实验的表格以及被弃用的干预措施将收录在 VocabX 论文中,我们很快就会发布。

来源

延伸阅读

探索 Dharma AI 在 Hugging Face 上的主页,试用我们的演示、下载我们的开放模型,并了解专用 AI 系统如何在真实企业应用中胜过通用模型。

来源:Hugging Face 社区博客 · huggingface.co

来源:RadarAI · aihot.news