用 Helion 构建高性能可移植的 vLLM 线性后端

为什么要给 vLLM 换一套线性后端

大语言模型的推理性能，很大程度上取决于底层算子（kernel）的执行效率。在 vLLM 这类高吞吐推理框架中，线性层（Linear）是最频繁被调用的核心组件之一——从注意力投影到 MLP 的每一次矩阵乘法，都会落到线性后端上。

传统做法是为不同硬件、不同数据类型手写高度优化的 kernel。这种方式虽然能压榨出极致性能，但代价是巨大的工程复杂度：每新增一种量化格式、每适配一款加速器，都意味着一批新的手写 kernel 需要维护。这正是 Helion 试图解决的痛点。

Helion 是什么

Helion 是一种面向 GPU kernel 的高层领域专用语言（DSL）。它的核心思路是：开发者用相对高层、接近 Python 的方式描述计算逻辑，而由编译器和自动调优（autotuning）系统负责把这段描述映射成针对具体硬件的高性能实现。

换句话说，Helion 把「写什么算」和「怎么算得快」这两件事解耦开来。开发者专注于表达算法语义，调优器则在编译期自动搜索最优的 tile 尺寸、循环切分、内存布局等参数组合。这样既保留了手写 kernel 的性能上限，又大幅降低了实现和维护的门槛。

Helion 在技术谱系上与 Triton（OpenAI 开源的 GPU 编程语言）类似，都属于介于 CUDA/HIP 等底层语言与 cuBLAS 等高层库之间的中间层抽象。Triton 已被 PyTorch 2.0 广泛采用，而 Helion 则在 tile 级别的自动调优粒度上做了进一步探索。所谓 tile 参数，是指将大矩阵分割成小块（tile）进行并行计算时的块大小设置——这是影响 GPU 内存带宽利用率和计算吞吐的关键超参数。手工选择 tile 尺寸需要深入了解目标硬件的缓存层次与 warp 调度机制，而 Helion 的自动调优系统可以通过编译期搜索代替这一过程，使开发者无需成为硬件专家也能获得接近最优的配置。

单一通用 kernel 的意义

这次集成工作的一个关键成果，是用一个 Helion 编写的通用线性 kernel，覆盖了 vLLM 线性后端原本需要多个专用实现才能支持的场景。

这一点对框架维护者的价值不可小觑。过去为了兼顾不同形状（shape）、不同精度的矩阵乘法，后端往往需要维护一整套分散的 kernel 代码。而 Helion 的自动调优能力意味着，同一份高层描述可以在不同输入规模和硬件上分别调优出各自的最优配置，从而用一份代码替代一堆特化实现。

复杂度与性能的权衡

长期以来，推理框架的 kernel 层面临一个两难：

• 追求极致性能，就要大量手写、特化、硬件绑定的代码，维护成本高；
• 追求可移植与简洁，往往要牺牲一部分性能。

Helion 的集成实验，本质上是在验证「高层 DSL + 自动调优」这条路线能否同时拿到两头的好处——既接近手写性能，又具备跨硬件的可移植性。

在 vLLM 的线性后端中，需要处理的场景组合相当复杂：输入矩阵可能是 FP16、BF16、INT8 或各种 GPTQ/AWQ 量化格式，批次大小（batch size）从单请求的小矩阵到大批量的宽矩阵差异悬殊，而不同 shape 下最优的计算策略往往截然不同。传统做法是为每种组合维护独立的专用 kernel，导致代码库中存在大量近似重复但微妙不同的实现。用一个通用 Helion kernel 覆盖这些场景，意味着新增量化格式支持时只需修改高层描述逻辑，而非从头编写并验证新的底层 kernel，显著缩短了功能迭代周期。

可移植性为何重要

AI 加速硬件的格局正在快速多元化，除了主流 GPU，还有越来越多的异构加速器进入推理场景。如果每换一款硬件都要重写一遍 kernel，框架的适配成本会随硬件种类线性增长。

Helion 这类高层 DSL 的吸引力正在于此：算法描述保持不变，只需让编译器针对新后端重新调优，就能获得可用的高性能实现。对 vLLM 这种需要服务广泛部署环境的开源项目来说，这种「写一次、调优多处」的能力具有战略意义。

值得注意的是，这里的「可移植性」不仅指跨不同品牌 GPU（如 NVIDIA 与 AMD），还包括同一厂商不同代际架构之间的迁移。例如，针对 NVIDIA Ampere（A100）架构手工调优的 kernel，在 Hopper（H100）上未必仍是最优，因为新架构引入了 Tensor Memory Accelerator（TMA）等新型内存访问指令。高层 DSL 方案的优势在于，当编译器后端更新以支持新架构特性时，已有的算法描述代码可以自动受益，无需人工逐一修改每个 kernel。这对开源社区尤为重要——核心贡献者数量有限，却需要维护横跨多代硬件的性能表现。

对推理工程实践的启示

从这次集成可以看到一个趋势：LLM 推理的底层优化正从「人工精雕每个 kernel」向「用高层语言描述 + 自动化调优」转变。这并不意味着手写优化会立刻消失，但对于绝大多数线性算子场景，自动调优已经能给出足够有竞争力的结果，同时把工程负担降到很低。

对于正在构建或维护推理栈的团队，这提供了一个可参考的方向：在性能关键但模式相对规整的算子上，优先评估高层 DSL 方案，把宝贵的手写优化精力留给真正需要极限压榨的特殊路径。

注：本文基于原始技术博客的摘要信息撰写，部分实现细节与具体基准数据以官方完整文档为准。