这项由荷兰Nebius公司研究团队完成的工作以预印本形式发布于2026年5月论文编号为arXiv:2605.10453感兴趣的读者可通过该编号查阅完整原文。每当你和ChatGPT或其他大语言模型对话时你有没有想过那些文字是一个字一个字吐出来的这不是设计上的噱头而是这类模型工作的本质——它必须一个词、一个词地预测下一步该说什么。这种逐字生成的方式虽然保证了语言的连贯性但也带来了一个让工程师头疼的现实问题速度太慢成本太高。为了解决这个问题研究人员早已发明了一种叫做投机解码Speculative Decoding的加速技巧。用一个更直观的说法来理解它大模型就像一位极其严谨的主编每次只亲自写一个字审查再发出。于是工程师们给这位主编配了一个实习生——一个小得多、快得多的模型让实习生先大胆地一口气草拟出好几个字主编只需要快速扫一眼确认没问题就全部通过有问题就从出错的地方开始重写。这样一来主编的精力被大大节省整体出稿速度显著提升。然而Nebius团队在仔细拆解这位实习生的工作流程时发现了一个被忽视已久的效率黑洞。实习生在草拟每一个字之前都要做一件事把自己内部的思考结果翻译成对整个词汇表中所有词语的打分——这个词汇表在现代大模型中动辄包含十万个以上的词语。这个翻译步骤就是所谓的LM-Head语言模型头部而它消耗的计算时间竟然占到了实习生总工作时间的45%到60%。换句话说实习生有将近一半的时间都在做这个给十万个词打分的繁琐工作而大多数时候最终被选中的词只有寥寥几个。这不是很浪费吗研究团队提出的解决方案叫做**SlimSpec**核心思路是与其让实习生用全尺寸的脑子去给十万个词打分不如先把实习生的思考结果压缩成一个更精简的摘要再用这个摘要去打分。十万个词的候选池一个都不少但完成这件事所需要的计算量却大幅缩减了。经过实验验证SlimSpec在多个主流大模型上将LM-Head的计算时间压缩到了原来的五分之一左右同时几乎没有损失推理质量端到端的生成速度比此前最优的竞争方案还要快出8%到9%。这篇文章就来详细讲讲这个给实习生瘦身的方案究竟是怎么做到的。一、理解投机解码主编与实习生的分工艺术在深入了解SlimSpec之前需要先把投机解码这套工作机制讲清楚因为它是整个故事的舞台。回到主编与实习生的比喻。主编目标模型即我们真正想用的大模型能力极强但每次出手都要消耗大量时间。实习生草稿模型Drafter虽然水平差一些但速度很快。投机解码的流程是这样的实习生先飞速草拟出一串候选词比如六个然后主编一次性验证这六个词。如果实习生猜对了前四个主编就接受这四个再加上自己生成的第五个词作为奖励下一轮从第五个词之后继续。用一个公式来衡量这套机制的效率平均每轮接受多少个词这个数字叫做平均接受长度记为τ读作tau。τ越大说明实习生猜得越准系统整体速度越快。整个系统的吞吐量每秒能生成多少词可以用一个简单的比值来描述用τ除以完成一轮投机所需的总时间。总时间由三部分组成主编验证的时间、实习生起草的时间以及各种调度、同步的系统开销。Nebius团队的关键发现是实习生起草的时间中将近一半都被LM-Head这个打分环节所占据如图2所示——对于Llama-3.1-8B模型LM-Head占实习生总时间的46%对于GPT-OSS-20B这个比例高达58%对于Qwen3-30B-A3B也有51%。这意味着如果能大幅压缩LM-Head的时间整体速度就会显著提升。这就是SlimSpec的切入点。二、现有的瘦身方案为什么不够好在Nebius团队提出SlimSpec之前研究界已经有一些压缩LM-Head计算量的思路它们大致可以分为两类但都有各自的局限。第一类方案叫做静态词汇裁剪代表作有FR-Spec和VocabTrim。这类方案的逻辑是既然候选词汇表有十万个但实际上常用的词只有几万个那就直接裁掉那些几乎从不出现的词让实习生只在一个缩减版的词汇表上打分。FR-Spec通过分析通用文本语料的词频来决定保留哪些词VocabTrim则通过分析目标模型自己的生成样本来做决定。后来的BCL方案则将裁多少变成了一道可以数学优化的问题。这类方案的问题在于被裁掉的词就像是从实习生的候选名单上彻底删除了一样——无论主编多么想选那个词实习生都永远不会提议它。这就给接受率设置了一个天花板如果被裁掉的词恰好是主编想要的这一轮草稿直接作废。在某些需要生成罕见词汇的任务中这个天花板会非常低。更微妙的问题是在训练实习生时如果用的是一种叫KL散度的损失函数可以理解为衡量实习生打分和主编打分有多像的指标裁剪词汇会让训练时的参考答案和推理时的评判标准产生错位导致实习生变得过度自信反而降低接受率。第二类方案叫做动态词汇选择代表作有CORAL、DynaSpec和SpecVocab。这类方案更聪明不预先裁剪而是在每次生成时根据当前上下文动态地挑选最可能被用到的那几千个词。SpecVocab用了一个低秩的路由器来预测哪些词值得考虑然后只在这些词上打分。这种方法确实比静态裁剪更灵活但它引入了新的麻烦每次生成时都需要额外做一步挑词的操作涉及全局排序、部分排序、不规则索引、动态抓取权重矩阵的某个子集……这些操作在GPU上并不高效因为GPU最擅长的是密集矩阵乘法这类规整的计算而非这种散乱的随机访问。所以实际测量下来SpecVocab虽然减少了打分的词数但LM-Head的时间只降到了原来的46%左右节省效果有限。Nebius团队的判断是这两类方案都在从词汇表的出口端做文章而他们想从另一个方向入手——压缩实习生在打分之前的那个内部表示。三、SlimSpec的核心思路给内部表示瘦身正式介绍SlimSpec之前先搞清楚LM-Head究竟在做什么。实习生草稿模型在处理完当前上下文之后会在内部产生一个隐藏状态向量可以把它理解成实习生对接下来应该说什么的一个综合性思考结果。这个向量的维度等于模型的隐藏层宽度记为d。LM-Head的工作就是把这个d维的向量通过一个巨大的矩阵乘法投影成一个V维的打分向量V是词汇表大小约十万。这个矩阵的大小是V×d每次投影需要的计算量是O(V×d)。SlimSpec做的事情用一个比喻来说就是在这道投影之前先把思考结果压缩一下。具体做法是用两个小矩阵的乘积来代替原来那一个大矩阵。第一步用一个d×r的矩阵记为W_down把d维的隐藏状态压缩成一个r维的更小向量其中r远小于d第二步再用一个V×r的矩阵记为W_up把这个r维的小向量展开成V维的打分向量。计算量从原来的O(V×d)变成了O(r×d V×r)。由于V远大于d十万远大于几千这个新的计算量近似等于O(V×r)大约是原来的r/d倍。如果取rd/8计算量就降到了原来的八分之一左右——这正好解释了为什么实验中LM-Head时间能压缩到原来的约五分之一除了纯计算量还有内存访问等实际因素的影响。关键在于这个方案全程保留了V个词的打分词汇表一个都没减少。被压缩的只是实习生的思考摘要从d维变成了r维而从这个摘要到全部词汇的打分这一步计算量就小得多了。整个过程是两次普通的密集矩阵乘法GPU最擅长处理这种计算。SlimSpec唯一的超参数需要人工设定的参数就是这个秩r论文建议取d/8作为默认值在各模型上都表现最佳。对比之下CORAL有三个需要调整的超参数DynaSpec有四个SpecVocab有两个——SlimSpec的配置之简单是它的重要优势之一。此外SlimSpec在训练和推理时都不需要任何特殊改动。它只是把原来的一个大矩阵换成了两个小矩阵训练时照常用KL散度损失推理时照常做密集矩阵乘法完全没有词汇裁剪带来的那些理论缺陷。四、为什么压缩内部表示比裁剪词汇更干净这里值得多停留一会儿因为SlimSpec的这个设计选择背后有一些很有意思的理论逻辑。首先是关于接受率天花板的问题。当实习生只有一个裁剪过的词汇表时那些被裁掉的词的生成概率被硬性设为零。用数学语言说实习生的草稿分布q在裁剪词汇之外的所有词上都是零。而接受率的计算方式是对每一个词取min(主编概率, 实习生概率)然后求和。只要某个词在实习生那边概率为零这个词对接受率的贡献就是零。所以裁剪词汇方案的接受率无论实习生训练得多好都被上界限制在主编在裁剪词汇范围内的概率总和这个上界是硬性的无法突破。SlimSpec不存在这个问题。它只是改变了实习生预测每个词的方式但每个词的预测概率都可以是任意正值不存在被强制设为零的情况。其次是训练和推理的错位问题。用裁剪词汇来训练实习生时为了让KL散度可以计算KL散度要求分母不为零研究者们不得不把主编的目标分布也裁剪成只在保留词上有概率。但推理时主编用的是完整的概率分布来做验证。这种训练和推理时参考标准不一致的情况会让实习生对保留词产生过度自信实际接受时反而吃亏。SlimSpec完全不存在这个问题训练时和推理时用的是同一套完整词汇表标准完全统一。五、一个衡量值不值得的数学框架Nebius团队不仅提出了方案还建立了一套分析框架来回答一个更根本的问题把LM-Head做得更快一定会让整体更快吗答案是不一定。这里面有一个权衡关系值得仔细理解。设想一下整个投机解码的时间由两部分组成LM-Head的时间和其他所有时间包括主编验证时间、实习生骨干网络时间、系统调度时间等。定义κ为LM-Head时间除以其他所有时间的比值。κ越大说明LM-Head越是瓶颈κ越小说明LM-Head在整体中占比越低。对于一个改造过LM-Head的方案用ν表示其LM-Head时间与原始方案的比值越小越好用ρ_τ表示其平均接受长度与原始方案的比值越接近1越好。那么改造方案相对于原始方案的端到端加速比是ρ_τ × (1κ)/(1ν×κ)。这个公式揭示了一个重要规律要想让整体加速不仅需要ν足够小LM-Head够快还需要ρ_τ足够大接受率不能损失太多。具体来说接受率至少要满足一个由κ决定的下界ρ_τ (1ν×κ)/(1κ)。κ本身不是一个固定的数它随部署环境的变化而变化。当目标模型越大验证时间越长κ越小LM-Head的改进对整体的影响就越弱。当词汇表越大、实习生隐藏维度越小时κ越大LM-Head加速的收益越显著。批次大小同时处理多少个用户的请求也会影响κ因为大批次时各个组件的计算模式都会改变。甚至采样温度也有影响高温采样需要在整个词汇表上做softmax这增加了其他时间的占比从而降低了κ。这个框架非常实用因为它告诉工程师们在决定用哪种LM-Head加速方案之前先算一算自己的部署场景下κ大概是多少再对照不同方案在(ν, ρ_τ)平面上的位置就能判断哪种方案真正划算。六、实验结果在接受率-成本平面上的全面胜出为了验证理论Nebius团队在三个目标模型上做了全面测试分别是Llama-3.1-8B-Instruct、GPT-OSS-20B和Qwen3-30B-A3B覆盖了三个基准测试集MT-Bench指令跟随、HumanEval代码生成、GSM8K数学推理在贪心解码温度0和随机采样温度1两种模式下测试了单请求批次大小1和批量服务批次大小64两种场景。实验环境是vLLM 0.17.1框架加NVIDIA H200 GPU。所有方案都以EAGLE-3作为基础的草稿模型骨干架构用66万条指令数据训练唯一的差异就是LM-Head的设计。这样的控制变量设计让结果的对比极为干净。从图3的接受率-成本平面图来看各方案的表现一目了然。以Llama-3.1-8B为例原始全词汇方案Full Vocab的位置在右上角LM-Head成本最高ν1.0接受率当然也是基准ρ_τ1.0。静态裁剪方案沿着左下方向移动把词汇从128K裁到64KLM-Head成本降到约0.58但接受率也跌到约0.99裁到32K成本降到0.33接受率降到0.96裁到16K成本降到0.20但接受率也跌到0.90已经进入得不偿失的区间。FR-Spec因为用通用语料统计词频与模型实际生成的词分布不匹配在同等词汇规模下表现比VocabTrim更差。BCL选择的截断规模太激进接受率的损失超过了成本节省带来的收益端到端加速比反而低于全词汇基准。动态裁剪方案SpecVocab的表现明显优于静态裁剪用rd/8的路由器能在保持接受率约等于1ρ_τ≈1.01的同时把LM-Head成本降到约0.46。但由于路由和动态抓取权重的额外开销实际节省不如理论上的纯计算量分析所预期的那么大。SlimSpec在这张图上占据了最左侧的位置用rd/8LM-Head成本只有约0.21约原来的五分之一而接受率维持在ρ_τ0.99几乎没有损失。这个位置对应的端到端加速曲线κ0.25的等加速线是所有方案中最高的。从具体数字来看以表2中温度0的结果为例在Llama-3.1-8B上SlimSpecrd/8在单请求场景下平均加速比达到2.94倍相对于无投机解码的基准而SpecVocab是2.86倍VocabTrim-T是2.70倍提升幅度超过8.5%。在批量服务场景下SlimSpec达到1.52倍SpecVocab是1.46倍同样领先。对于GPT-OSS-20B在批量服务场景下SlimSpec比SpecVocab高出8.9个百分点。Qwen3-30B-A3B是个有趣的例外。由于这个模型是混合专家架构MoE其LM-Head在总延迟中的占比相对较低κ较小所以各方案之间的差异都不大SlimSpec的优势收窄到1-2%左右。这完全符合理论框架的预测当κ小时LM-Head的改进对端到端的影响自然有限。从平均接受长度τ的数据来看以Llama-3.1-8B为例Full Vocab的τ约为4.42SlimSpec rd/8的τ约为4.37差异不足0.5%而VocabTrim 32K的τ降到了4.25FR-Spec 32K更是跌到3.86。这直观地说明了SlimSpec在不损伤质量方面的优势。还有一个细节值得关注在温度1的随机采样场景下SlimSpec相对于静态裁剪方案的优势更加明显。原因在于高温采样时主编验证的计算开销更大需要在完整词汇表上做softmax采样这降低了κ使得静态裁剪方案词汇受限的硬天花板问题更加突出而SlimSpec没有这个问题。七、研究的边界与未来的方向研究团队对自己工作的局限性做了诚实的描述这值得一提。首先所有实验都基于EAGLE-3这一种草稿模型框架还没有在MEDUSA、Hydra等其他框架上做直接验证。SlimSpec理论上应该对所有辅助头式草稿模型都适用但需要实验证实。其次测试的三个目标模型最大只有30B参数对于更大规模的模型比如超过50B参数的κ值可能更小SlimSpec的相对优势可能进一步收窄。第三测试环境只使用了NVIDIA H200和vLLM框架在其他硬件或推理框架上的表现可能有所不同。第四秩r目前是人工选择的文章没有提供自动确定最优秩的方法只是建议通过实验确认rd/8在大多数场景下是合适的起点。研究团队在展望未来时提出了两个方向。一是接受率导向的训练目标既然SlimSpec通过压缩表示已经在成本轴上走到了很好的位置下一步应该专注于在不改变推理时计算量的前提下通过更好的训练策略提高接受率在接受率-成本平面上把SlimSpec的位置向上推。二是位置自适应的秩分配当前所有草稿位置用同一个秩r但实际上不同的草稿位置第1个预测词、第2个、第3个……可能需要不同的表达能力可以考虑对早期位置更难预测分配更大的秩对后期位置分配更小的秩在保持总计算量的同时进一步提升接受率。说到底这项工作给了整个推理加速领域一个清醒的提醒速度和质量之间的权衡不是一个孤立的工程问题而是一个需要在完整系统视角下思考的优化问题。一个看起来让某个零件快了很多的方案不一定真的让整辆车跑得更快——关键要看那个零件是不是真正的瓶颈以及提速时付出的质量代价值不值得。SlimSpec的价值在于它找到了一条几乎不用付出质量代价就能大幅压缩瓶颈计算量的路径而且实现极其简单——不需要维护词频统计不需要动态路由逻辑不需要修改训练框架只需要把一个大矩阵换成两个小矩阵。对于任何在生产环境中部署大语言模型的团队来说这是一个颇具吸引力的选项。---QAQ1SlimSpec是如何在不减少词汇表的情况下加速LM-Head计算的ASlimSpec把原本的一个大矩阵维度是词汇量×隐藏维度替换成两个小矩阵的连乘第一个矩阵先把隐藏状态从d维压缩到r维第二个矩阵再从r维展开到词汇量维度。计算量从O(V×d)降到了O(r×d V×r)当rd/8时大约是原来的八分之一而词汇表的大小和所有词的打分都完全保留不存在词汇被遗漏的问题。Q2投机解码中的平均接受长度具体是什么意思为什么它很重要A平均接受长度τ衡量的是草稿模型平均每轮投机能让主模型接受多少个草稿词。比如τ4.5意味着每一轮投机平均产出4.5个词。τ越高每次主模型验证的成果越多整体速度就越快。SlimSpec的设计让τ几乎不下降保持在原方案的99%左右而LM-Head时间却大幅缩短所以端到端速度显著提升。Q3SlimSpec在哪些场景下效果最明显哪些场景下提升有限ASlimSpec在LM-Head占总延迟比例较高的场景下效果最好比如词汇表大、目标模型较小验证快、使用单请求低延迟模式的场景。对于混合专家架构MoE的大模型如Qwen3-30B-A3B由于LM-Head在总延迟中占比相对较低各方案之间差距缩小SlimSpec的优势收窄到1-2%。总体而言部署场景中κLM-Head时间与其他时间的比值越大SlimSpec带来的收益越明显。
荷兰Nebius团队：给AI“起草员“瘦身，大模型推理速度提升5倍
发布时间：2026/5/16 20:39:11
这项由荷兰Nebius公司研究团队完成的工作以预印本形式发布于2026年5月论文编号为arXiv:2605.10453感兴趣的读者可通过该编号查阅完整原文。每当你和ChatGPT或其他大语言模型对话时你有没有想过那些文字是一个字一个字吐出来的这不是设计上的噱头而是这类模型工作的本质——它必须一个词、一个词地预测下一步该说什么。这种逐字生成的方式虽然保证了语言的连贯性但也带来了一个让工程师头疼的现实问题速度太慢成本太高。为了解决这个问题研究人员早已发明了一种叫做投机解码Speculative Decoding的加速技巧。用一个更直观的说法来理解它大模型就像一位极其严谨的主编每次只亲自写一个字审查再发出。于是工程师们给这位主编配了一个实习生——一个小得多、快得多的模型让实习生先大胆地一口气草拟出好几个字主编只需要快速扫一眼确认没问题就全部通过有问题就从出错的地方开始重写。这样一来主编的精力被大大节省整体出稿速度显著提升。然而Nebius团队在仔细拆解这位实习生的工作流程时发现了一个被忽视已久的效率黑洞。实习生在草拟每一个字之前都要做一件事把自己内部的思考结果翻译成对整个词汇表中所有词语的打分——这个词汇表在现代大模型中动辄包含十万个以上的词语。这个翻译步骤就是所谓的LM-Head语言模型头部而它消耗的计算时间竟然占到了实习生总工作时间的45%到60%。换句话说实习生有将近一半的时间都在做这个给十万个词打分的繁琐工作而大多数时候最终被选中的词只有寥寥几个。这不是很浪费吗研究团队提出的解决方案叫做**SlimSpec**核心思路是与其让实习生用全尺寸的脑子去给十万个词打分不如先把实习生的思考结果压缩成一个更精简的摘要再用这个摘要去打分。十万个词的候选池一个都不少但完成这件事所需要的计算量却大幅缩减了。经过实验验证SlimSpec在多个主流大模型上将LM-Head的计算时间压缩到了原来的五分之一左右同时几乎没有损失推理质量端到端的生成速度比此前最优的竞争方案还要快出8%到9%。这篇文章就来详细讲讲这个给实习生瘦身的方案究竟是怎么做到的。一、理解投机解码主编与实习生的分工艺术在深入了解SlimSpec之前需要先把投机解码这套工作机制讲清楚因为它是整个故事的舞台。回到主编与实习生的比喻。主编目标模型即我们真正想用的大模型能力极强但每次出手都要消耗大量时间。实习生草稿模型Drafter虽然水平差一些但速度很快。投机解码的流程是这样的实习生先飞速草拟出一串候选词比如六个然后主编一次性验证这六个词。如果实习生猜对了前四个主编就接受这四个再加上自己生成的第五个词作为奖励下一轮从第五个词之后继续。用一个公式来衡量这套机制的效率平均每轮接受多少个词这个数字叫做平均接受长度记为τ读作tau。τ越大说明实习生猜得越准系统整体速度越快。整个系统的吞吐量每秒能生成多少词可以用一个简单的比值来描述用τ除以完成一轮投机所需的总时间。总时间由三部分组成主编验证的时间、实习生起草的时间以及各种调度、同步的系统开销。Nebius团队的关键发现是实习生起草的时间中将近一半都被LM-Head这个打分环节所占据如图2所示——对于Llama-3.1-8B模型LM-Head占实习生总时间的46%对于GPT-OSS-20B这个比例高达58%对于Qwen3-30B-A3B也有51%。这意味着如果能大幅压缩LM-Head的时间整体速度就会显著提升。这就是SlimSpec的切入点。二、现有的瘦身方案为什么不够好在Nebius团队提出SlimSpec之前研究界已经有一些压缩LM-Head计算量的思路它们大致可以分为两类但都有各自的局限。第一类方案叫做静态词汇裁剪代表作有FR-Spec和VocabTrim。这类方案的逻辑是既然候选词汇表有十万个但实际上常用的词只有几万个那就直接裁掉那些几乎从不出现的词让实习生只在一个缩减版的词汇表上打分。FR-Spec通过分析通用文本语料的词频来决定保留哪些词VocabTrim则通过分析目标模型自己的生成样本来做决定。后来的BCL方案则将裁多少变成了一道可以数学优化的问题。这类方案的问题在于被裁掉的词就像是从实习生的候选名单上彻底删除了一样——无论主编多么想选那个词实习生都永远不会提议它。这就给接受率设置了一个天花板如果被裁掉的词恰好是主编想要的这一轮草稿直接作废。在某些需要生成罕见词汇的任务中这个天花板会非常低。更微妙的问题是在训练实习生时如果用的是一种叫KL散度的损失函数可以理解为衡量实习生打分和主编打分有多像的指标裁剪词汇会让训练时的参考答案和推理时的评判标准产生错位导致实习生变得过度自信反而降低接受率。第二类方案叫做动态词汇选择代表作有CORAL、DynaSpec和SpecVocab。这类方案更聪明不预先裁剪而是在每次生成时根据当前上下文动态地挑选最可能被用到的那几千个词。SpecVocab用了一个低秩的路由器来预测哪些词值得考虑然后只在这些词上打分。这种方法确实比静态裁剪更灵活但它引入了新的麻烦每次生成时都需要额外做一步挑词的操作涉及全局排序、部分排序、不规则索引、动态抓取权重矩阵的某个子集……这些操作在GPU上并不高效因为GPU最擅长的是密集矩阵乘法这类规整的计算而非这种散乱的随机访问。所以实际测量下来SpecVocab虽然减少了打分的词数但LM-Head的时间只降到了原来的46%左右节省效果有限。Nebius团队的判断是这两类方案都在从词汇表的出口端做文章而他们想从另一个方向入手——压缩实习生在打分之前的那个内部表示。三、SlimSpec的核心思路给内部表示瘦身正式介绍SlimSpec之前先搞清楚LM-Head究竟在做什么。实习生草稿模型在处理完当前上下文之后会在内部产生一个隐藏状态向量可以把它理解成实习生对接下来应该说什么的一个综合性思考结果。这个向量的维度等于模型的隐藏层宽度记为d。LM-Head的工作就是把这个d维的向量通过一个巨大的矩阵乘法投影成一个V维的打分向量V是词汇表大小约十万。这个矩阵的大小是V×d每次投影需要的计算量是O(V×d)。SlimSpec做的事情用一个比喻来说就是在这道投影之前先把思考结果压缩一下。具体做法是用两个小矩阵的乘积来代替原来那一个大矩阵。第一步用一个d×r的矩阵记为W_down把d维的隐藏状态压缩成一个r维的更小向量其中r远小于d第二步再用一个V×r的矩阵记为W_up把这个r维的小向量展开成V维的打分向量。计算量从原来的O(V×d)变成了O(r×d V×r)。由于V远大于d十万远大于几千这个新的计算量近似等于O(V×r)大约是原来的r/d倍。如果取rd/8计算量就降到了原来的八分之一左右——这正好解释了为什么实验中LM-Head时间能压缩到原来的约五分之一除了纯计算量还有内存访问等实际因素的影响。关键在于这个方案全程保留了V个词的打分词汇表一个都没减少。被压缩的只是实习生的思考摘要从d维变成了r维而从这个摘要到全部词汇的打分这一步计算量就小得多了。整个过程是两次普通的密集矩阵乘法GPU最擅长处理这种计算。SlimSpec唯一的超参数需要人工设定的参数就是这个秩r论文建议取d/8作为默认值在各模型上都表现最佳。对比之下CORAL有三个需要调整的超参数DynaSpec有四个SpecVocab有两个——SlimSpec的配置之简单是它的重要优势之一。此外SlimSpec在训练和推理时都不需要任何特殊改动。它只是把原来的一个大矩阵换成了两个小矩阵训练时照常用KL散度损失推理时照常做密集矩阵乘法完全没有词汇裁剪带来的那些理论缺陷。四、为什么压缩内部表示比裁剪词汇更干净这里值得多停留一会儿因为SlimSpec的这个设计选择背后有一些很有意思的理论逻辑。首先是关于接受率天花板的问题。当实习生只有一个裁剪过的词汇表时那些被裁掉的词的生成概率被硬性设为零。用数学语言说实习生的草稿分布q在裁剪词汇之外的所有词上都是零。而接受率的计算方式是对每一个词取min(主编概率, 实习生概率)然后求和。只要某个词在实习生那边概率为零这个词对接受率的贡献就是零。所以裁剪词汇方案的接受率无论实习生训练得多好都被上界限制在主编在裁剪词汇范围内的概率总和这个上界是硬性的无法突破。SlimSpec不存在这个问题。它只是改变了实习生预测每个词的方式但每个词的预测概率都可以是任意正值不存在被强制设为零的情况。其次是训练和推理的错位问题。用裁剪词汇来训练实习生时为了让KL散度可以计算KL散度要求分母不为零研究者们不得不把主编的目标分布也裁剪成只在保留词上有概率。但推理时主编用的是完整的概率分布来做验证。这种训练和推理时参考标准不一致的情况会让实习生对保留词产生过度自信实际接受时反而吃亏。SlimSpec完全不存在这个问题训练时和推理时用的是同一套完整词汇表标准完全统一。五、一个衡量值不值得的数学框架Nebius团队不仅提出了方案还建立了一套分析框架来回答一个更根本的问题把LM-Head做得更快一定会让整体更快吗答案是不一定。这里面有一个权衡关系值得仔细理解。设想一下整个投机解码的时间由两部分组成LM-Head的时间和其他所有时间包括主编验证时间、实习生骨干网络时间、系统调度时间等。定义κ为LM-Head时间除以其他所有时间的比值。κ越大说明LM-Head越是瓶颈κ越小说明LM-Head在整体中占比越低。对于一个改造过LM-Head的方案用ν表示其LM-Head时间与原始方案的比值越小越好用ρ_τ表示其平均接受长度与原始方案的比值越接近1越好。那么改造方案相对于原始方案的端到端加速比是ρ_τ × (1κ)/(1ν×κ)。这个公式揭示了一个重要规律要想让整体加速不仅需要ν足够小LM-Head够快还需要ρ_τ足够大接受率不能损失太多。具体来说接受率至少要满足一个由κ决定的下界ρ_τ (1ν×κ)/(1κ)。κ本身不是一个固定的数它随部署环境的变化而变化。当目标模型越大验证时间越长κ越小LM-Head的改进对整体的影响就越弱。当词汇表越大、实习生隐藏维度越小时κ越大LM-Head加速的收益越显著。批次大小同时处理多少个用户的请求也会影响κ因为大批次时各个组件的计算模式都会改变。甚至采样温度也有影响高温采样需要在整个词汇表上做softmax这增加了其他时间的占比从而降低了κ。这个框架非常实用因为它告诉工程师们在决定用哪种LM-Head加速方案之前先算一算自己的部署场景下κ大概是多少再对照不同方案在(ν, ρ_τ)平面上的位置就能判断哪种方案真正划算。六、实验结果在接受率-成本平面上的全面胜出为了验证理论Nebius团队在三个目标模型上做了全面测试分别是Llama-3.1-8B-Instruct、GPT-OSS-20B和Qwen3-30B-A3B覆盖了三个基准测试集MT-Bench指令跟随、HumanEval代码生成、GSM8K数学推理在贪心解码温度0和随机采样温度1两种模式下测试了单请求批次大小1和批量服务批次大小64两种场景。实验环境是vLLM 0.17.1框架加NVIDIA H200 GPU。所有方案都以EAGLE-3作为基础的草稿模型骨干架构用66万条指令数据训练唯一的差异就是LM-Head的设计。这样的控制变量设计让结果的对比极为干净。从图3的接受率-成本平面图来看各方案的表现一目了然。以Llama-3.1-8B为例原始全词汇方案Full Vocab的位置在右上角LM-Head成本最高ν1.0接受率当然也是基准ρ_τ1.0。静态裁剪方案沿着左下方向移动把词汇从128K裁到64KLM-Head成本降到约0.58但接受率也跌到约0.99裁到32K成本降到0.33接受率降到0.96裁到16K成本降到0.20但接受率也跌到0.90已经进入得不偿失的区间。FR-Spec因为用通用语料统计词频与模型实际生成的词分布不匹配在同等词汇规模下表现比VocabTrim更差。BCL选择的截断规模太激进接受率的损失超过了成本节省带来的收益端到端加速比反而低于全词汇基准。动态裁剪方案SpecVocab的表现明显优于静态裁剪用rd/8的路由器能在保持接受率约等于1ρ_τ≈1.01的同时把LM-Head成本降到约0.46。但由于路由和动态抓取权重的额外开销实际节省不如理论上的纯计算量分析所预期的那么大。SlimSpec在这张图上占据了最左侧的位置用rd/8LM-Head成本只有约0.21约原来的五分之一而接受率维持在ρ_τ0.99几乎没有损失。这个位置对应的端到端加速曲线κ0.25的等加速线是所有方案中最高的。从具体数字来看以表2中温度0的结果为例在Llama-3.1-8B上SlimSpecrd/8在单请求场景下平均加速比达到2.94倍相对于无投机解码的基准而SpecVocab是2.86倍VocabTrim-T是2.70倍提升幅度超过8.5%。在批量服务场景下SlimSpec达到1.52倍SpecVocab是1.46倍同样领先。对于GPT-OSS-20B在批量服务场景下SlimSpec比SpecVocab高出8.9个百分点。Qwen3-30B-A3B是个有趣的例外。由于这个模型是混合专家架构MoE其LM-Head在总延迟中的占比相对较低κ较小所以各方案之间的差异都不大SlimSpec的优势收窄到1-2%左右。这完全符合理论框架的预测当κ小时LM-Head的改进对端到端的影响自然有限。从平均接受长度τ的数据来看以Llama-3.1-8B为例Full Vocab的τ约为4.42SlimSpec rd/8的τ约为4.37差异不足0.5%而VocabTrim 32K的τ降到了4.25FR-Spec 32K更是跌到3.86。这直观地说明了SlimSpec在不损伤质量方面的优势。还有一个细节值得关注在温度1的随机采样场景下SlimSpec相对于静态裁剪方案的优势更加明显。原因在于高温采样时主编验证的计算开销更大需要在完整词汇表上做softmax采样这降低了κ使得静态裁剪方案词汇受限的硬天花板问题更加突出而SlimSpec没有这个问题。七、研究的边界与未来的方向研究团队对自己工作的局限性做了诚实的描述这值得一提。首先所有实验都基于EAGLE-3这一种草稿模型框架还没有在MEDUSA、Hydra等其他框架上做直接验证。SlimSpec理论上应该对所有辅助头式草稿模型都适用但需要实验证实。其次测试的三个目标模型最大只有30B参数对于更大规模的模型比如超过50B参数的κ值可能更小SlimSpec的相对优势可能进一步收窄。第三测试环境只使用了NVIDIA H200和vLLM框架在其他硬件或推理框架上的表现可能有所不同。第四秩r目前是人工选择的文章没有提供自动确定最优秩的方法只是建议通过实验确认rd/8在大多数场景下是合适的起点。研究团队在展望未来时提出了两个方向。一是接受率导向的训练目标既然SlimSpec通过压缩表示已经在成本轴上走到了很好的位置下一步应该专注于在不改变推理时计算量的前提下通过更好的训练策略提高接受率在接受率-成本平面上把SlimSpec的位置向上推。二是位置自适应的秩分配当前所有草稿位置用同一个秩r但实际上不同的草稿位置第1个预测词、第2个、第3个……可能需要不同的表达能力可以考虑对早期位置更难预测分配更大的秩对后期位置分配更小的秩在保持总计算量的同时进一步提升接受率。说到底这项工作给了整个推理加速领域一个清醒的提醒速度和质量之间的权衡不是一个孤立的工程问题而是一个需要在完整系统视角下思考的优化问题。一个看起来让某个零件快了很多的方案不一定真的让整辆车跑得更快——关键要看那个零件是不是真正的瓶颈以及提速时付出的质量代价值不值得。SlimSpec的价值在于它找到了一条几乎不用付出质量代价就能大幅压缩瓶颈计算量的路径而且实现极其简单——不需要维护词频统计不需要动态路由逻辑不需要修改训练框架只需要把一个大矩阵换成两个小矩阵。对于任何在生产环境中部署大语言模型的团队来说这是一个颇具吸引力的选项。---QAQ1SlimSpec是如何在不减少词汇表的情况下加速LM-Head计算的ASlimSpec把原本的一个大矩阵维度是词汇量×隐藏维度替换成两个小矩阵的连乘第一个矩阵先把隐藏状态从d维压缩到r维第二个矩阵再从r维展开到词汇量维度。计算量从O(V×d)降到了O(r×d V×r)当rd/8时大约是原来的八分之一而词汇表的大小和所有词的打分都完全保留不存在词汇被遗漏的问题。Q2投机解码中的平均接受长度具体是什么意思为什么它很重要A平均接受长度τ衡量的是草稿模型平均每轮投机能让主模型接受多少个草稿词。比如τ4.5意味着每一轮投机平均产出4.5个词。τ越高每次主模型验证的成果越多整体速度就越快。SlimSpec的设计让τ几乎不下降保持在原方案的99%左右而LM-Head时间却大幅缩短所以端到端速度显著提升。Q3SlimSpec在哪些场景下效果最明显哪些场景下提升有限ASlimSpec在LM-Head占总延迟比例较高的场景下效果最好比如词汇表大、目标模型较小验证快、使用单请求低延迟模式的场景。对于混合专家架构MoE的大模型如Qwen3-30B-A3B由于LM-Head在总延迟中占比相对较低各方案之间差距缩小SlimSpec的优势收窄到1-2%。总体而言部署场景中κLM-Head时间与其他时间的比值越大SlimSpec带来的收益越明显。
