vLLM 与蚂蚁集团推出 Humming 量化内核：项目方称 H20 上吞吐提高 14%–43%
Humming 是 vLLM 社区与蚂蚁集团的量化内核库。项目方称，8 张 H20 上 DeepSeek-V4.1-Flash 输出吞吐提高 14%–43%。
Humming 是 vLLM 社区与蚂蚁集团推出的量化推理内核库，用 JIT（即时编译）按需生成 GEMM 内核，许可证为 Apache-2.0。10 月 21 日，vLLM 官方博客公布了一组端到端测试：在 8 张 H20 上跑 DeepSeek-V4.1-Flash，只把 MoE 后端从 Marlin W4A16 换成 Humming W4A8，输出吞吐提高 14%–43%。这些是项目方自己测的数字，我们没有找到独立的复测。
要点
- 许可与安装：仓库为 Apache-2.0。PyPI 上的 humming-kernels 最新版是 0.1.18，10 月 21 日上传，x86_64 的 wheel 为 517,199 字节。vLLM 0.29.0 起，CUDA 版安装已把它列为依赖。
- 测试条件：8 张 H20，张量并行度 8，模型为 DeepSeek-V4.1-Flash，MXFP4 权重保持不变。博文没有写请求长度、数据集和压测工具。
- 启用方式：在
vllm serve上加--linear-backend humming --moe-backend humming。vLLM 这两个选项的默认值都是auto，博文的示例都显式指定了 humming。
背景
Humming 的代码并不是今天才公开的。GitHub 上的 vllm-project/humming 创建于 2026 年 2 月 11 日，旧地址 inclusionAI/humming 会重定向到这里。PyPI 上的 humming-kernels 从 0.1.0 到 0.1.18 共 19 个版本，0.1.0 在 5 月 13 日上传。vLLM 0.29.0 于 9 月 9 日发布，把 Humming 写进了 CUDA 依赖，发行说明里也列出了几项 Humming 改动，比如 MXFP4 权重配合 block-FP8 激活的 MoE 路径（#51332）。博文标题是 Announcing Humming，正文说双方“正在开源”，但仓库和包早已可用。所以这次博文更像是正式介绍，而不是首次开源。
博文的部署示例用的是 DeepSeek-V4.1-Flash-1017，我们 10 月 17 日报道过这个模型卡。我们 10 月 20 日报道过的推理框架 DeepInfer 也与 vLLM 有关：它的 README 写明最初主要基于 vLLM 构建（DeepInfer 报道）。vLLM 原班人马另创的 Inferact，9 月在 TPU 上跑 Kimi K3 的推理内核，我们也报道过（Inferact 报道）。
博文还说，Humming 已经完整支持阿里平头哥的真武 810E（T-Head Zhenwu 810E），并计划扩展到真武 M890。
事实部分
下表是 Humming 在博文里报告的端到端数据。测试平台为 8 张 H20，张量并行度 8，只切换 MoE 后端。表中的变化列是 Humming 相对 Marlin 的增减，数字取自博文表格。博文表中输入吞吐的变化与输出吞吐完全相同。
| 并发 | Marlin W4A16 输出吞吐（tokens/s） | Humming W4A8 输出吞吐（tokens/s） | 输出吞吐变化 | TTFT 变化 | TPOT 变化 |
|---|---|---|---|---|---|
| 1 | 88.30 | 100.77 | +14.1% | −29.3% | −8.5% |
| 2 | 149.33 | 176.38 | +18.1% | −30.0% | −10.9% |
| 4 | 231.99 | 286.12 | +23.3% | −31.7% | −12.9% |
| 8 | 287.04 | 383.04 | +33.4% | −32.3% | −22.2% |
| 16 | 348.96 | 475.89 | +36.4% | −25.1% | −27.1% |
| 32 | 398.83 | 560.49 | +40.5% | −30.5% | −28.5% |
| 64 | 442.37 | 633.94 | +43.3% | −29.0% | −30.5% |
这组数据有三点限制。第一，两边的激活精度不同：Marlin 是 BF16 激活，Humming 是 tokenwise FP8 激活，这不是同精度的替换。第二，博文没有给出这组测试的精度或质量评测数字，我们无法判断换激活精度后输出质量是否有变化。第三，博文没有写请求长度、数据集和压测工具，这组数字目前无法复现。另外，博文正文写 TPOT 在并发 64 时降低约 31%，表中为 30.5%，本文以表格为准。
博文另有一批 vLLM 社区跑的算子级测试（microbenchmark）。小批量时，稠密 W4A16 相对 cuBLAS 的加速约为 3 到 4 倍，博文称在多款设备上如此；H200 大批量时约为 Marlin 的两倍。在 H20 和 H200 上，MXFP4 W4A16 的 MoE 路径在中大批量时约为 Marlin 的两倍。编译速度也是博文强调的一点：在 H200、CUDA 13.4 上，单个 W4A16 内核的编译时间从 CUTLASS 加 NVCC 的 23.35 秒降到 Humming 加 NVCC 的 1.82 秒（关闭编译缓存）。这些都是单个算子或编译阶段的结果，不能换算成整机吞吐。
包的信息我们直接从 PyPI 与 vLLM 仓库读取，列在下表。
| 项目 | 数值 | 出处 |
|---|---|---|
| humming-kernels 最新版 | 0.1.18，2026-10-21 上传 | PyPI 元数据 |
| x86_64 wheel | 517,199 字节 | PyPI 文件列表 |
| 基础依赖 | torch≥2.7、triton、numpy、safetensors、jinja2、cuda-bindings、tqdm、tabulate | PyPI requires_dist |
| vLLM 0.29.0 的固定版本 | humming-kernels[cu13]==0.1.12 | vLLM requirements/cuda.txt |
各方说法
英文媒体 Pandaily 在同一天转述了这组数字，并写明这些结果尚未经过独立验证。它也转述了 README 的说法：依赖只需要 PyTorch 与 NVCC，pip 包约 100 KB。这与 PyPI 的元数据不符。0.1.18 列出了 triton、numpy、cuda-bindings 等依赖，x86_64 wheel 为 517 KB。我们以 PyPI 为准。
新浪财经 1 月 29 日的报道说，平头哥官网上线了真武 810E，官网介绍的规格是 96GB HBM2e 显存和 700 GB/s 片间互联带宽。报道同时引用“业内人士”的说法，称它的整体性能与英伟达 H20 相当，但没有给出测试条件，我们也没有找到对应的公开测试。
个人仓库 Qwen3x-Orin 里有一份 2026 年 8 月的审计文档，针对 Jetson Orin（SM87）。它检查的是 8 月 7 日至 8 日的 vLLM 与 Humming 主干源码，本地比较环境为 vLLM 0.26.0 与 Humming 0.1.10，并明确说不给性能结论。其中一条观察与自动选择有关：在它检查的选择器里，A16 的自动路径仍然选择 Marlin，所以把 Humming 说成 SM87 上 Qwen3.5 的自动路径并不准确。这是单机、旧版本的观察，我们没有在 v0.29.0 上复核。
vLLM 仓库里还有三个仍为 open 的 Humming 相关问题（截至 10 月 21 日查询）。#60162 报告，在 Ampere 上 Humming 的 FP8 线性层会因 per-tensor 或 per-channel 的 FP8 权重而崩溃，开启 VLLM_BATCH_INVARIANT=1 时 FP8 模型无法启动。#60700 指出，W4A8 MoE 的断言要求 hidden 与 intermediate 维度是 256 的倍数，适用于所有后端，所以 CUTLASS 拒绝的形状（例如 intermediate 为 640）Humming 也加载不了。#62136 报告，quantization="mxfp8" 配合 moe_backend="humming" 时，权重转换以 KeyError: 'weight_scale' 崩溃。
编辑判断
14% 到 43% 的范围对应并发 1 到 64。并发为 1 时只有 14.1%，并发越高增益越大。如果你的服务主要是低并发，别指望 40% 左右的提升。
“吞吐提高”不等于单位成本下降。博文没有给出 H20 的价格、功耗或每个 token 的成本，所以不能把这组数字换算成省下多少钱。
版本要核实。vLLM 0.29.0 固定的是 humming-kernels 0.1.12，PyPI 上已经有 0.1.18。README 说只需要 PyTorch 与 NVCC，而 PyPI 的依赖列表更长。上线前用 pip show 或锁文件确认实际装上的版本。
精度是最大的未知数。端到端对比把激活从 BF16 换成了 FP8，博文又没有给精度数字。切换之前，先在自己的评测集上比较输出质量。
博文称真武 810E 是 CUDA 兼容设备，而 1 月的报道描述的是“全栈自研软件栈”，没有提到兼容层。这一点我们无法独立确认。
需要盯的有三件事：#60700 和 #62136 两个 MoE 问题何时关闭；博文说计划引入的 autotune（在目标设备上对候选配置做基准测试），我们没有确认它是否已经发布；以及真武 810E 上是否出现独立测试数据。
最适合试一试的是在 vLLM 上跑量化 MoE 模型、用 H20 或其他 Hopper、Blackwell 卡的团队。用自己的请求长度与并发复现一遍，值得花一个下午。用真武 810E 的团队，目前只有博文的说法。
怎么试
如果你用的是 vLLM 0.29.0 或更新版本的 CUDA 安装，不需要单独安装 Humming。博文给出的部署示例是 8 卡张量并行：
vllm serve deepseek-ai/DeepSeek-V4.1-Flash-1017 \
--tensor-parallel-size 8 \
--linear-backend humming --moe-backend humming
只想单独试内核的话，可以 pip install "humming-kernels[cu13]"（CUDA 13）或 pip install "humming-kernels[cu12]"（CUDA 12）。README 里还有一个 HummingLayer 的 Python 例子。以上命令我们都没有在 GPU 机器上运行，文中的数字也没有复现。