论文导读
麻省理工学院与英伟达提出Lightning Weave，把“答得更准”和“用更少Token”两类后训练能力组合进同一个学生模型。Qwen3.5-4B在LiveCodeBench v5上从41.7%升至54.2%，响应Token同时少9.6%；这为模型服务提供一条质量与成本同时优化的路径，但论文仍标为进行中，代码也尚未发布。
准确专家和省字专家各有一套习惯
推理模型想提高准确率，往往会展开更长的思考；专门压缩回答长度，又可能删掉关键步骤。团队没有让一个模型从零同时优化两个目标，而是先利用各自后训练好的专家：一个擅长准确，一个擅长效率，再提取它们相对训练前模型发生了哪些策略变化。
论文图：准确率和效率锚点分别提供能力，再共同蒸馏到学生模型。
每组“训练前—训练后”模型形成一个锚点对。二者在同一Token状态上的概率差异，被视作该项能力的策略位移。这样提取的是模型行为怎样改变，而不是简单平均两个专家的参数或答案。
在每个Token位置重新配能力
Lightning Weave把多个锚点对共享的缓存轨迹对齐，在学生模型当前Token状态上组合对数概率位移。相容的变化会相互加强，冲突的变化则按位置协调；随后通过Tilted-Target DOPD把组合信号转成稳定的蒸馏目标。
论文图：调整两类能力权重，可得到一组不同准确率与回答长度的学生模型。
一个实用点是，每个锚点对只需给缓存轨迹评分一次。训练学生模型时，不必让多个大专家一直在线运行，降低了组合能力的训练开销。改变锚点强度，还能让部署者在“更准”与“更短”之间选择不同位置。
数学和代码都出现反向改进
在Qwen3.5-4B上，HMMT 2025准确率由59.2%升至64.0%，响应Token减少10.7%；LiveCodeBench v5由41.7%升至54.2%，同时少用9.6% Token。也就是说，代码准确率增加12.5个百分点，并没有以更长回答为代价。
论文图：多种学生模型在不同回答Token预算下的精度表现。
论文还在多种学生模型与数学、代码基准上比较，并报告更好的精度—效率前沿。不过基准分数不能直接换算为所有业务成本；提示长度、并发、缓存和输出定价都会影响真实节省。
与把多个专家答案再投票不同，最终部署的仍是单个学生模型，因此推理时不必为两位专家各付一次计算。代价主要发生在锚点评分和蒸馏阶段，这部分训练开销需要代码开放后进一步核算。
下一步看代码复现与服务成本
若代码按计划开放，最值得验证的是锚点评分、缓存规模和学生训练总成本，以及能力超过两种后是否稳定。对模型服务而言，这种方法提供的不是一个固定“更强模型”，而是一条可调曲线：同一尺寸下按场景选择更准或更省。只有在真实流量上同时报告质量、延迟与费用，它的工程价值才会完整显现。
