PolyGraph 提案解决自适应推测解码中 CUDA Graph 捕获冲突

一句话结论

PolyGraph 通过计划缓冲区机制，以 28 字节的传输成本解决自适应推测解码中 CUDA Graph 固定形状与动态批处理尺寸冲突的问题。

关键要点

• 传统服务系统在处理自适应推测解码时需为 64 种不同形状预捕获 CUDA Graph，或在线捕获新形状，或将每一步填充至最大草稿长度。
• PolyGraph 捕获单一最大网格图并在每次重放前将活跃形状写入 GPU 内存，仅 28 字节的更新传输即可动态调整计算负载。
• 内核跳过超出活跃形状范围的计算瓦片，而保持图形拓扑、内存分配、布局、指针和启动网格完全固定。
• 基于 Qwen2.5-3B 模型的追踪驱动原型在单块 NVIDIA H800 上将 P50 步骤延迟从基线的 17.8 毫秒降至 17.7 毫秒。
• 该机制将服务前图形构建时间从 3915 毫秒大幅缩短至 93 毫秒，固定草稿控制实验表明性能收益来自避免填充负载浪费。

背景与事实

自适应推测解码是提升大语言模型推理速度的关键技术，其核心优势在于每一步解码过程中激活的批处理尺寸 B 和草稿长度 d 会动态变化。然而，这种动态特性与 CUDA Graph 的工作机制产生根本性冲突，因为 CUDA Graph 通常重放固定的启动配置。由此导致的验证宽度 M 等于 B 与 d 的乘积，使得服务系统面临艰难取舍：必须预先捕获大量不同形状的图形，或者在服务路径上在线捕获新形状，又或者将每一步都填充至最大的草稿长度。这种取舍直接影响了系统性能和部署复杂度。

2026 年 8 月 14 日，研究团队在 arXiv cs.LG 提交了名为 PolyGraph 的论文，提出了一种针对自定义 Triton 内核的计划缓冲区机制，旨在彻底避免上述三选一困境。该机制的核心设计是捕获一个最大网格图形，并在每次重放前将当前活跃形状写入 GPU 内存。内核在执行过程中会跳过超出该活跃形状范围的所有计算瓦片，但图形的拓扑结构、内存分配、数据布局、指针和启动网格始终保持不变。整个形状更新过程仅需传输 28 字节数据，极大地降低了运行时开销。

研究团队在单块 NVIDIA H800 显卡上构建了基于 Qwen2.5-3B 模型维度的追踪驱动原型系统进行验证。实验结果表明，该系统成功用单个图形替代了原本需要的 64 个特定形状图形，且观测到的 P50 步骤延迟为 17.7 毫秒，与 17.8 毫秒的已预热基线性能持平。更重要的是，服务前的图形构建时间从 3915 毫秒锐减至 93 毫秒。固定草稿长度的对照实验进一步揭示了收益来源：性能提升完全归功于避免了填充负载带来的浪费，在零填充浪费时 P99 差异可忽略不计，而在 100% 填充浪费时实现了 18.7% 的延迟降低。

影响分析

对于中文开发者与大模型推理从业者而言，PolyGraph 提出的方案具有显著的实际工程价值。首先，它大幅简化了基于 CUDA Graph 的推理服务部署流程，开发者不再需要为不同批处理尺寸维护庞大的图形缓存，降低了显存占用和初始化时间。其次，93 毫秒的图形构建时间意味着服务启动速度大幅提升，这对需要频繁冷启动或弹性伸缩的云原生推理场景尤为重要。然而，必须明确指出，这一判断基于论文提供的实验数据。当前证据仅证明了该机制在自定义内核和单卡环境下的可行性，尚未验证其在生产级多卡分布式系统中的表现。开发者在考虑将其应用于实际业务前，需评估模型规模、显卡架构及并发负载等变量对机制有效性的影响，避免直接外推单卡实验结论到复杂生产环境。

适用边界

该结论存在明确的适用范围限制。PolyGraph 的证据基础是建立在对自定义 Triton 内核有界的形状机制验证之上，而非完整的生产级服务系统。实验仅在一块 NVIDIA H800 显卡上使用合成追踪数据完成，涉及 Qwen2.5-3B 模型维度。因此，该结论不适用于无法使用自定义内核的传统推理框架，也不直接适用于其他显卡架构或多卡分布式推理场景。对于需要处理非合成真实工作负载、多模型混合服务或大规模并发请求的生产环境，该机制的有效性和性能收益尚未经过验证。

孤本观察

本文观察认为，PolyGraph 的核心贡献在于将动态形状适配转化为固定图形拓扑下的轻量级数据更新，这一思路为调和 GPU 图执行效率与自适应推理灵活性提供了新路径。判断这一机制能否真正落地，关键在于后续能否扩展至支持多种模型架构及复杂生产工作负载的开源实现。

来源：arXiv cs.LG