Chord开源：面向Kimi K2.x的高性能INT4 MoE内核

导语

MoE模型的推理性能，往往不只取决于矩阵乘法本身，还取决于每个专家实际接收到多少token、路由后的填充方式，以及GPU能否在小批量计算中保持足够利用率。Novita AI近日开源Chord，试图为Kimi K2.x的INT4 MoE服务提供更贴合实际工作负载的CUDA内核。

Chord采用W4A16方案，即BF16激活配合INT4权重和group-32缩放因子。项目当前包含两类内核：一类是源自公开Humming实现的indexed路径，使用vLLM已有的sorted_ids、expert_ids和num_tokens_padded路由数据；另一类是基于DeepGEMM思路构建的SM90 grouped路径，分别面向prefill和decode，并采用不同的权重打包布局。

核心要点

• 在与公开Humming匹配路径的单层测试中，Chord在H200 EP8 prefill上的加速约为1.11至1.20倍，在H200 TP8单实例服务上约为1.17至1.33倍。
• H200 EP8 decode的提升约为1.16至1.24倍，其中down阶段最高达到1.31倍。
• B300 EP8 decode相较未调优的Humming默认配置达到1.81至2.15倍。不过，公开Humming并未提供SM100/SM103调优表，因此这一对比并非“调优对调优”。
• grouped路径在H200 EP8 prefill和decode上的结果约为1.00至1.31倍和1.16至1.35倍；测试还覆盖EP16与EP32。

Chord的关键思路是避免用单一kernel应对所有请求。prefill和decode中的每专家路由token数量可能相差很大，因此调度器会根据实际形状选择block-M、占用率和stream-K策略。H200 indexed prefill路径会参考每专家路由token数量，在较大规模下调整block-M；部分中等尺寸则通过限制寄存器使用，争取让更多warp驻留在SM上。WGMMA流水线还把权重加载、反量化和矩阵计算进行重叠，以减少等待。

使用与限制

在兼容的vLLM版本中，用户可安装Chord并显式选择Humming后端。其indexed路径可以复用现有集成，但grouped路径与vLLM Humming后端的整合仍在进行中。项目支持Kimi K2.x使用的uint4、group-32、BF16缩放因子及相关压缩权重格式；不支持的量化方案会在加载阶段失败，而不是静默选择错误内核。

需要注意，Chord公布的是kernel-level benchmark，不等同于所有业务场景的端到端加速。实际收益还会受到专家并行规模、请求批次、路由分布、权重布局和vLLM版本的影响。对部署者而言，最重要的启示不是简单替换一个kernel，而是让MoE后端根据路由形状进行更细粒度的调度，并在目标GPU和真实请求分布上重新验证。

来源：vLLM Blog