Humming v0.1.0–0.1.4：量化内核库从开源首版到 H20 实战调优的三周冲刺

一句话结论

本站曾解读过蚂蚁 inclusionAI 开源的量化 GEMM 内核库 Humming（总览见「Humming 量化 GEMM 内核库」一文），其后 5 月 15 日至 6 月 4 日三周内连发五个版本（v0.1.0 至 v0.1.4），29 个提交的主线只有一个：把「格式任意」的设计承诺变成「真实硬件上跑得快、装得上」的工程现实。这段窗口期的工作高度聚焦两类问题：一是面向 H20 这张国内高频部署卡的 W4A8 与 DeepSeek-V4 专项优化，二是把它从「基准工具」改造为「可安装软件包」——削减内核启动 CPU 开销、NVRTC 编译独立进程化、修复 SM90 调优导致的 block_shape_k 不可用问题，都是这个改造的具体环节。仓库现已迁移至 vllm-project/humming，Apache-2.0 协议。

v0.1.0 之后的前置冲刺：H20 W4A8 与 TMA 对齐（5 月 14–15 日）

v0.1.0 发布于 5 月 15 日，但发布前的四个提交已经把本窗口的第一条主线立起来了：H20 的 W4A8（4 比特权重、8 比特激活）性能优化。W4A8 是「显存占用与计算精度」的折中热门档位，H20 又是国内算力环境下批量部署的绝对主力，两者叠加就是最真实的生产需求。5 月 14 日连续四个提交围绕它展开：整体性能优化、小 K 维（small k）场景专项、按 k block 修正激活 scale 的索引偏移（PR #20），以及综合修复。5 月 15 日再补 H20 fused E8M0 scale 优化与 TMA 共享内存对齐修复（PR #21）——TMA 是 Hopper 架构的异步张量搬运引擎，对齐错误会直接让内核跑不起来。首版 tag 打在这些工作之上，说明开源第一天的卖点就不是格式列表，而是 H20 上的实测性能。

v0.1.1：把内核启动开销打下来（5 月 21–22 日）

5 月 21 日一天六个提交构成本窗口的工程化高峰。第一条主线是「reduce kernel launch cpu overhead」：量化内核的优势在 GPU 计算侧，但如果每次启动内核都要在 CPU 侧付出高昂的准备开销，端到端延迟就被 CPU 拖累——这对在线推理服务是实打实的吞吐损失。配套动作是把 NVRTC 编译挪进独立进程（use a separate process for nvrtc compilation）：JIT 编译不再占用主进程，编译崩溃也不再连带推理进程，这是「库」与「脚本」的分界线。同日还修了 launch_kernel 与 launcher stable ABI 错误、编译源打包问题（PR #24）、sm120 支持与 fake ops。第二天 5 月 22 日出现本窗口含金量最高的适配提交之一：「optimize for h20 deepseek-v4」——DeepSeek-V4 的模型结构直接驱动内核优化方向，并修正 actual_shape_m 的计算（PR #25）。v0.1.1 于当日发版。

v0.1.2：发布工程起步（5 月 23 日）

v0.1.2 节奏放缓，两个提交：修调和配置（fix and optimize tune config），以及「add release workflow and release 0.1.2」——建立正式的发布工作流。到此版本发布从手工打 tag 变成流程化产出，这也是后续三周四连发能稳定推进的基础设施。同窗口稍后还有一个防御性修复：屏蔽 LazyLoader 模块在 torch.library._register_fake 周边的冲突（5 月 24 日）。

v0.1.3：wgmma fence 精修（5 月 27 日至 6 月 2 日）

v0.1.3 间隔十天，四个提交。核心是 mma(wgmma) 修复：在 fused E8M0 路径上跳过 kApplyScaleOnC 的 fence（PR #27）——wgmma 是 Hopper 上 warp 级矩阵乘累加的核心指令，fence（内存序屏障）放错位置要么牺牲正确性要么牺牲性能，这个「按路径选择是否插 fence」的修复属于指令级精修；同路径另有 fused E8M0 scale 优化与之呼应。工程侧修复 NVRTC 链接问题后于 6 月 2 日发版。

v0.1.4：修好调优脚本挖的坑（6 月 4 日）

v0.1.4 是本窗口收尾，两个提交解决同一个问题：SM90 调优产生的 block_shape_k 参数不可用（fix the issue of unusable block_shape_k caused by the sm90 tune）。内核库的调优配置本该提升性能，但调优脚本若产出非法参数组合，用户按调优结果跑反而报错——「调优结果自己不可用」是典型的工具链信任问题，v0.1.4 把这条链修直。另有主循环 kNumBSPerSubBlock 运算符优先级修复并覆盖 uint4（PR #28，6 月 3 日）。

这三周对使用者的意义

五版演进对新老用户的含义不同。已经在 H20 上跑 W4A8 或 DeepSeek-V4 类模型的团队：v0.1.1 的内核启动开销削减与 NVRTC 独立进程、v0.1.4 的 block_shape_k 修复都是直接影响服务稳定性的版本，最低升级线应设在 v0.1.4。准备第一次试用的用户：直接装 v0.1.4，它包含发布工作流与全部 H20 优化，且是本站此前解读过的 v0.1.5（Hadamard 变换与后台 JIT 进程回收）的直接前置。关注硬件适配节奏的读者：从这批提交能看出明确的优先级排序——H20 与 Hopper（SM90）是第一梯队，Blackwell（sm120）已进入修复清单，老 Turing 架构维持兼容。

上手核对清单

实际把这套量化内核接入 AI 推理工作流时，按序操作：先在自己的 H20 或 Hopper 卡上安装 v0.1.4，配置 LayerConfig 填写 W4A8 的量化格式与 scale 类型，运行官方基准脚本确认内核能正常启动；再用 DeepSeek-V4 类真实模型的权重跑 transform 转换与推理，输出与未量化 matmul 对照检查精度；长时间压测观察 CPU 侧启动开销与 NVRTC 编译进程是否稳定（v0.1.1 前后差异明显）；如果使用调优工具生成 block_shape_k，务必确认版本已含 v0.1.4 修复，最后把验证过的配置固化进部署脚本。这套配置-运行-测试-替换的流程，就是三周 29 个提交换来的可用性底线。

原文信息

• 作者：inclusionAI（蚂蚁集团开源团队），仓库现已迁移至 vllm-project
• 开源协议：Apache-2.0
• 项目地址： 原文地址：