本文由上海交通大学、北京航空航天大学与LightLLM团队联合完成。作者陈俊一是上海交通大学二年级硕士研究生，研究方向聚焦于大模型推理加速算法与推理框架优化，长期关注推测解码、动态 MTP 以及高性能推理系统等问题。其余三位位作者白世豪，汪再军和龚睿昊均来自 LightLLM团队，该团队长期致力于大语言模型推理引擎、分布式并行、推测解码与系统级性能优化，并持续推动前沿推理算法在真实服务场景中的工程化落地。
随着 DeepSeek 发布 DSpark，动态 MTP（多 Token 预测）成为了对抗高并发、提升 GPU 利用率的绝对焦点。然而，DSpark 高度绑定特定模型且需要额外训练。
今天，LightSpec团队正式开源了业内首个通用动态 MTP 推理框架方案 —— 它采用创新的两阶段 Training-free 设计，完全无需训练，不仅能直接兼容 DSpark 策略，还完美支持 Eagle3 等不同草稿模型。LightSpec首次实现了从算法到运行时的完整系统级优化，真正让动态 MTP 从 “特定模型的专属技巧” 演进为 “通用推理的基建能力”！
事实上，早在今年年初，LightSpec团队便已率先聚焦动态 MTP 方向，围绕算法设计、系统调度与推理系统实现持续推进相关工作，目前已完成首个开源通用动态 MTP 系统的实现。
相比 DSpark，LightSpec的优势可以概括为两个关键词：更通用，也更完整。
更通用，意味着动态 MTP 不再局限于某一种草稿模型。LightSpec采用创新的两阶段 Training-free 动态调度设计，无需额外训练置信度预测模型，而是通过运行时在线统计实时完成动态决策。因此，它不仅能够直接兼容 DSpark 的动态验证策略，还进一步支持 Eagle3 等自回归草稿模型、MTP Layer 等不同类型的动态 MTP 实现，并能够自然扩展到未来树形草稿、多分支推测解码等更加复杂的推理架构。
更完整，意味着开源的不只是一个动态调度算法，而是一套真正可落地的动态 MTP 系统。动态 MTP 真正落地远不止增加一个调度器，还涉及运行时统计、预算优化、模型输入构建、流水线协同等多个模块之间的协同设计与系统优化。
LightSpec首次将这些关键模块完整实现并开源，使动态 MTP 真正具备了可复用、可扩展、可落地的系统能力，也让现有推理框架能够以更低成本支持动态 MTP。
本文将围绕这一通用动态 MTP 系统，介绍其动态调度算法设计、运行时统计机制、完整系统实现、流水线优化以及实验结果，并展示LightSpec如何将动态 MTP 从一种面向特定模型的优化技巧，进一步演进为推理系统的一项基础能力。
从 “动态调整验证长度” 到 “动态 MTP 系统”
现有动态投机解码工作主要围绕验证预算展开，即根据当前推理状态动态决定哪些草稿 Token 值得送入主模型验证，从而避免低收益 Token 占用 GPU Batch 容量。
LightSpec则进一步将动态 MTP 扩展到整个解码流程。整个运行时规划器被拆分为两个连续优化阶段。
- 第一阶段（验证预算优化）：系统结合上一轮草稿步数、运行时代价模型以及历史统计信息，在可选验证预算中搜索最优动态 Batch 大小，动态决定当前轮真正送入主模型验证的 Token 数量。
- 第二阶段（草稿预算优化）：在确定当前验证预算后，运行时规划器继续搜索下一轮最优草稿步数，将草稿模型的计算成本显式纳入优化目标，动态决定下一轮需要生成多少草稿 Token。
这种双层运行时规划器不仅减少了验证浪费，也进一步降低了草稿浪费。相比仅动态调整验证长度，LightSpec将草稿预算与验证预算统一纳入运行时规划器，使动态调度覆盖整个 MTP 解码周期。
无需额外训练，基于运行时统计的动态调度
DSpark 的硬件感知调度器依赖预先 Profile 得到的 SPS (B) 曲线，并结合模型预测得到的 Token 置信度完成动态 Token 准入，因此需要额外训练专用的置信度预测模块。
LightSpec则采用了一条更加通用的系统路线。整个动态 MTP 运行时规划器不依赖额外训练的置信度预测模型，而是直接利用推理系统运行过程中自然产生的统计信息完成动态调度。
其中，主模型和草稿模型在不同批次大小下的推理耗时，会在 CUDA Graph 构建过程中自动统计并维护为运行时代价表；不同请求规模、不同动态 Batch 大小下的接受率，以及不同 MTP 长度对应的接受率变化，则通过运行时持续更新的指数移动平均（EMA）统计进行维护。
对于统计样本尚不充分的配置，运行时规划器会利用不同 MTP 长度上的历史统计进行插值估计；随着系统持续运行，EMA 统计不断收敛，调度策略也能够逐渐适应真实工作负载，而无需依赖额外训练的置信度预测模型。相比需要专用预测模块的方案，这种基于运行时统计的运行时规划器更容易迁移到不同草稿模型和不同推理框架中，也降低了动态 MTP 的落地门槛。
调度与 Draft 架构解耦，支持更多草稿模型
动态 MTP 的另一个挑战，在于不同草稿模型的推理模式并不相同。DSpark、DFlash 等并行解码草稿模型（Parallel Drafter） 能够一次前向传播生成完整草稿块，因此动态调度主要围绕验证长度展开。而 Eagle3 等自回归草稿模型（Auto-regressive Drafter），则需要逐步生成草稿 Token，草稿本身就是整个推理过程中不可忽略的计算开销。
LightSpec将验证预算与草稿预算解耦之后，不再依赖具体草稿模型的生成方式。对于并行解码草稿模型，运行时规划器可以动态调整验证预算；对于自回归草稿模型，则能够进一步动态调整草稿步数，减少不必要的草稿计算。
这种设计使动态 MTP 首次从某一种草稿模型上的专用优化，扩展成为整个开源 MTP 生态都可以复用的通用运行时能力。与此同时，两阶段运行时规划器也天然具备更好的扩展能力。未来无论是树形草稿、多分支草稿，还是更加复杂的投机解码架构，都能够继续沿用同一套运行时规划器，而无需重新设计调度机制。
首个开源动态 MTP 系统功能实现
除了动态调度器本身，LightSpec还首次将动态 MTP 的完整系统实现进行了开源。
整个系统并非单一的调度模块，而是围绕动态预算决策构建了一套完整的推理系统。运行时代价表持续维护不同批次大小下的计算开销，为动态调度提供代价估计；EMA 接受率统计实时跟踪不同工作负载下的接受行为，为预算决策提供在线反馈；动态调度器则综合这些运行时统计，在每一轮推理过程中联合决定验证预算与草稿预算，并同步完成动态模型输入的构建与更新。
LightSpec构建的不仅是一套动态 MTP 调度算法，而是一套覆盖运行时统计、预算优化、输入构建、流水线执行与系统协同的完整动态 MTP 系统实现，打破了动态 MTP 调度与 GPU 推理之间的运行时数据依赖，为不同 Draft 架构和更复杂的投机采样算法提供了统一的系统基础。
LightSpec采用历史统计驱动的运行时规划器。由于规划器所依赖的接受率和接受长度估计均来自前几轮持续维护的 EMA 统计，而非当前 Batch 的实时推理结果，因此 CPU 无需等待当前批次的草稿推理完成，即可提前完成下一轮动态 Batch 大小、草稿步数以及模型输入的规划。
与此同时，系统会在推理开始之前按照最大可能的草稿长度预留 Token 槽位，在 GPU 推理结束后，仅根据估计得到的接受长度完成切割，只保留真正需要验证的 Token，而无需重新组织输入。
这种设计彻底消除了规划器与 GPU 执行之间的运行时数据依赖，实现了 CPU 调度与 GPU 执行的完全重叠，将调度、输入构建以及统计维护几乎全部隐藏在 GPU 推理过程中。对于高并发在线推理而言，这类流水线优化往往比单个 Kernel 优化更加重要，因为真正决定端到端吞吐的，通常是调度、同步、数据组织、后处理以及 GPU 执行能否实现完全重叠。
实验结果：LightSpec 持续优于固定 MTP 步数
在 Qwen3-14B（TP=1）、H200、256 并发环境下，LightSpec 分别在 ShareGPT、HumanEval 和 GSM8K 三类工作负载上，对动态投机采样与固定 MTP 步数进行了对比。
结果表明，LightSpec 的整体性能始终不劣于固定配置，并且随着推测步数增加，其优势进一步扩大。当固定 MTP 步数从 3 提升至 11 时，静态方案会生成越来越多低收益候选 Token，导致接受率持续下降；动态方案则能够根据在线接受率和模型执行成本动态收缩无效预算，使接受率保持在相对稳定的水平。在 MTP=11 时，ShareGPT、HumanEval 和 GSM8K 的接受率分别提高约 43、29 和 19 个百分点。
更高的有效接受率直接减少了主模型的验证工作量。在 MTP=11 时，LightSpec 在 ShareGPT、HumanEval 和 GSM8K 上所需的验证行数分别降低约 3.2×、1.8× 和 1.5×；其中 ShareGPT 的实际验证量仅约为静态方案的三分之一。相应地，LightSpec 的请求吞吐分别提升 64%、39% 和 8.9%。即使在较浅的 MTP=3 配置下，其吞吐也能保持不劣，并在 ShareGPT 上获得 14% 的提升。
这些结果说明，固定 MTP 步数难以同时适应不同任务的接受率特征：较小的步数可能限制潜在加速收益，较大的步数又容易引入过量 Draft 和 Verification 开销。LightSpec 的运行时规划器通过联合调整 Draft Budget 与 Verification Budget，能够在不同任务和系统状态下持续寻找更合理的计算预算，而无需为每类工作负载反复人工选择固定 MTP 步数。
从一种优化技巧，到一项基础系统能力
动态 MTP 的意义，正在从一种模型优化策略，逐渐演进为推理系统的一项基础能力。
随着树形草稿（Tree Draft）、混合草稿（Hybrid Draft）、多策略投机解码等更加复杂的推理架构逐渐落地，系统需要动态优化的将不仅是验证长度，而是整个投机预算（Speculative Budget），包括草稿深度、草稿宽度、树扩展（Tree Expansion）、分支剪枝（Branch Pruning）等多个维度。未来的动态 MTP，也将不再是单一调度策略，而是一套覆盖整个推测解码流程的系统能力。
LightSpec的设计正是围绕这一方向展开。通过验证预算与草稿预算分离建模的双层动态调度器，以及围绕运行时统计、预算优化、模型输入构建和流水线协同设计的完整系统实现，动态调度不再局限于 "验证多少 Token" 的算法设计，而是扩展到整个推测解码系统的实现，并与具体草稿模型生成方式解耦，从而能够自然支持并行草稿模型、自回归草稿模型以及未来更加复杂的推理架构。
目前，LightLLM 动态 MTP 系统已正式开源，相关代码已经集成至 LightLLM 开发分支：https://github.com/ModelTC/LightLLM/tree/mtp_optimization。
从动态验证到动态 MTP 系统，从单一草稿模型到通用动态调度框架，从模型优化技巧到推理系统基础能力，LightSpec希望推动动态 MTP 从针对特定模型的局部优化，发展为整个开源 MTP 生态共享的系统基础设施。
热门跟贴