Helion集成vLLM：PyTorch原生DSL取代CUDA内核，加速Qwen3模型FP8推理

PyTorch团队今日发布与Red Hat合作的博客文章，介绍将九个Helion内核集成至vLLM用于Qwen3模型FP8推理的工作。作者为Red Hat的Sean Chen和Meta Platforms（PyTorch团队）的Yanan Cao。

什么是Helion，为什么开发者应该关注？

Helion是一种领域特定语言（DSL，domain-specific language），被描述为「带分块的PyTorch」——使用扩展了分块编程（tile-programming）概念的PyTorch语法编写高性能GPU内核，无需直接编写CUDA代码。目标是硬件可移植性：同一内核应在NVIDIA H100、B200和未来架构上运行，无需手动移植。

Helion提供先进的提前（AOT）自动调优基础设施——自动为每种目标GPU架构和输入维度搜索最优分块大小和内存布局。内核开发速度快：作者表示，九个内核中的大多数都是在一个工作日内实现和验证的。

集成至vLLM的内核列表

九个内核覆盖了FP8推理的几乎整个前向传播过程：

1. dynamic_per_token_scaled_fp8_quant
2. rms_norm_dynamic_per_token_quant
3. silu_and_mul_dynamic_per_token_quant——新的融合内核
4. fused_qk_norm_rope
5. per_token_group_fp8_quant
6. rms_norm_per_block_quant
7. silu_and_mul_per_block_quant
8. scaled_mm
9. scaled_mm_blockwise

集成将逐token量化前向传播中的内核调用次数从11次以上减少至10次融合操作。

单内核层面的性能

非GEMM内核在H100上相比此前实现（torch.ops._C）表现出一致且显著的加速：

• rms_norm_per_block_quant：+67%（2.055× vs torch.ops._C）
• silu_and_mul_per_block_quant：+73%（2.269× vs torch.ops._C）
• rms_norm_dynamic_per_token_quant：1.80× vs torch.ops._C
• fused_qk_norm_rope：1.38× vs torch.compile

GEMM内核（scaled_mm）呈现混合结果：H100上1.08×，但B200上0.739×。作者坦承原因是Triton在Blackwell架构上的代码生成限制，并表示正在开发CuteDSL后端以解决这一问题。

全模型层面的加速

测试在H100和B200上的Qwen3模型（1.7B、8B和32B参数）上进行：

• 逐token量化（H100）：Qwen3-1.7B整体吞吐量约1.05×
• 推测解码，Qwen3-8B，H100：总吞吐量最高1.09×（批大小16时TTFT加速1.15×）
• 逐组量化（H100和B200）：所有工作负载约1.05×

对于带3个推测token的Qwen3-8B推测解码，实测首token时间（TTFT）加速1.33×。

实际局限性

作者对权衡保持透明。对scaled_mm等大型内核的自动调优，覆盖所有输入形状（三种Qwen3变体的168个不同维度）需要约一天时间。Helion的运行时分发每次内核调用会引入数十微秒的延迟，因此必须使用CUDA graph capture才能实现最优性能。

Helion的逐组量化内核目前还不兼容B200上DeepGEMM所需的UE8M0格式，这是另一个有待解决的问题。

未来展望

该项目已作为GitHub issue vllm-project/vllm#32962发布，包含所有九个内核的实现。目标是将Helion支持扩展到更多架构，并通过CuteDSL后端解决Blackwell上的GEMM性能问题。Red Hat与Meta PyTorch团队在这一问题上的合作，表明PyTorch生态系统正在认真对待高性能推理内核的硬件可移植性问题。