Helion 接入 vLLM：用统一 GEMM 内核探索更高效的推理后端

导语

在大语言模型推理中，量化线性层往往直接决定吞吐与延迟。vLLM 已经为 FP8、INT8、INT4 和 NVFP4 等格式接入 CUTLASS、DeepGEMM、FlashInfer 等优化库，但不同模型和输入形状对矩阵乘法的需求并不相同。PyTorch 博客介绍了一项新尝试：把 Helion 接入 vLLM 的 linear backend，用更高层的内核描述和自动调优，减少为每种形状手工编写内核及调度规则的工作。

核心做法

• 一个实现覆盖多种算法。 Helion 的统一 GEMM 可以通过可调参数覆盖标准 GEMM、Split-K 和 Swap-AB。前者适合常规情况，Split-K 能在 M 或 N 较小时增加并行度，Swap-AB 则通过转置计算改善小 M 场景下的 GPU 利用率。
• 按形状选择配置。 自动调优器不仅搜索内存布局、切块和调度等底层参数，也会选择算法变体。这样，系统不必完全依赖固定启发式规则，而是可以针对具体工作负载寻找配置。
• 聚焦 Hopper 与量化 GEMM。 当前实现主要使用 Helion 的 Triton 后端，支持 FP8 动态量化、W8A8 INT8 和 Block-FP8。团队也报告称，Helion 的 CuteDSL 后端在 Blackwell 上的初步 GEMM 结果具有竞争力，但相关扩展仍取决于后端成熟度。
• 采用混合调度。 在 Hopper GPU 上，Helion linear backend 结合按形状调优和 hybrid dispatch，在所评估模型中超过了 vLLM 默认的 CUTLASS 与 DeepGEMM 后端，部分工作负载的端到端吞吐提升超过 10%。这些结果属于特定硬件、模型和测试范围，不能直接视为所有部署环境的普遍收益。

代价与限制

Helion 并没有消除内核优化的成本，而是把成本转移到更系统化的搜索过程。细粒度 AOT 调优可能需要数小时；vLLM 启动阶段的 CUDA Graph capture 会触发 JIT 编译，从而增加冷启动时间，缓存编译产物后温启动可明显缓解。若内核运行在 CUDA Graph 覆盖范围之外，额外的 CPU 调度和启动开销还可能抵消部分 GPU 收益。

此外，若上游为热门模型预置大量调优配置，维护、验证和持续更新都会变得困难。换言之，性能、易用性和可维护性之间存在难以回避的三角权衡：更高的工作负载专用性能，通常意味着更长的调优时间或更多配置管理工作。

意义与影响

这项工作展示了推理框架内核开发的一种方向：把算法选择、硬件适配和参数搜索统一纳入 DSL 与自动调优系统，让部署方有机会针对自身模型继续优化，而不必从零掌握复杂的 GPU 内核开发。它更适合形状相对稳定、能够使用 CUDA Graph、并且愿意承担一次性调优成本的服务场景。对于频繁变化的请求、强调快速启动的应用，传统预优化后端仍可能更实用。Helion 的价值最终取决于调优收益能否覆盖编译、调度和维护成本。

PyTorch Blog