TableTune：为动态投机解码实测并自校正草稿长度表

查看 PDF HTML（实验性）

摘要：推测解码只有在 GPU 有空闲算力时才能加速大语言模型（LLM）服务，因此随着批次增大，最佳草稿长度（小模型草稿器每步猜测的 token 数）会缩小。vLLM 允许运维人员通过手写表格为每个批次大小设置草稿长度，但没有任何机制测量或修正该表格。我们提出 TableTune。其调优器在 vLLM 自身的服务路径上对每个批次大小和草稿长度的解码步骤计时，并在几分钟内计算出使吞吐量最大化的表格。其控制器是一个 vLLM 插件，跟踪实时流量中被接受的猜测数量，并在服务过程中重建表格。我们仅将 TableTune 与其他推测方式进行比较。在 H100 上，在五种草稿器设置中的四种里，调优后的表格在每种负载下都能达到最佳固定草稿长度吞吐量的至少 94%（第五种为 88%），而运维人员无需知道该长度是多少。在同一引擎上对 TurboSpec 和 Nightjar 风格控制的重新实现进行对比，其最坏情况损失从不高于它们，而在 EAGLE-3 草稿器下为 3% 对 9% 和 12%。在混合专家模型上，vLLM 文档中的表格损失最高达 18%，而调优后的表格最多损失 3%。从调优不当的表格出发，控制器将吞吐量提升最高达 58%（在 vLLM 默认运行器上最高达 45%），而在使用 DFlash 草稿器的工作负载切换后，它能挽回陈旧表格损失的 96%。在 llm-d 按发布状态提供的优化基线部署中，即四个 GPU 上的两个 Qwen3-32B 副本，调优后的表格在高负载下比固定草稿长度 3 快最高达 32%，比 vLLM 文档中的表格快最高达 25%，并且控制器将文档表格的吞吐量提升最高达 29%。

提交历史

来自：Abhishek Malvankar [查看电子邮件]
[v1] 2026 年 10 月 28 日星期三 21:52:13 UTC（100 KB）