vLLM 与蚂蚁开源量化推理内核 Humming：国产加速卡第一次进了支持列表

先把「支持面」讲清楚：Turing 之后的卡，加上国产兼容卡

按 vLLM 官方博客，Humming 的设备支持范围是 NVIDIA Turing 及之后的 GPU 架构，外加 CUDA 兼容设备——文中举的例子正是平头哥的 Zhenwu 810E。这句话在工程上很关键：过去国产卡的适配往往要做一整套私有补丁，版本一升级就全部作废；如果一颗卡能跑 CUDA 兼容路径，就能直接吃 vLLM 生态的更新。

量化支持则是这个库真正的技术债偿还。官方描述是「统一的架构」支持多种权重与激活格式的组合，覆盖不同的整型、浮点位宽与缩放方案，dense GEMM 与 MoE GEMM 都在范围内。落实到运维层面，意味着同一套部署不必再为每个模型、每种量化格式单独挑一个内核实现。

官方给的数字：吞吐 +14%–43%，首 token 快 25%–32%

vLLM 博客给出的端到端测试口径是一次「换内核」的对比：把 DeepSeek-V4.1-Flash 的 MoE 从 Marlin W4A16（BF16 激活）切到 Humming W4A8（tokenwise FP8 激活），端到端吞吐提升约 14%–43%，平均首 token 延迟（TTFT）下降约 25%–32%；并注明优势随并发增大而扩大——并发 64 时，输出吞吐从 442.37 tokens/s 升到 633.94 tokens/s。

同精度层面的对比也有：在中小批量下，W8A8、W4A8、W4A4 分别达到约 1.25×、1.6×、1.4× 的基线性能，并在多类负载上优于对应的 FlashInfer 实现。另外一项容易被忽略的收益是编译时间：在一台 CUDA 13.4 的 H200 服务器上做 W4A16 单内核编译测试，CUTLASS + NVCC 需要 23.35 秒，Humming 用 NVCC 为 1.82 秒、用 NVRTC 为 1.88 秒。

工程上最省事的一点：vLLM 0.29.0 起开箱内置

官方明确：从 vLLM 0.29.0 开始，CUDA 安装会把 Humming 作为依赖一起装上，不需要单独安装。这对运维是好消息——升级 vLLM 就顺带把量化内核换新了，而不是「装一个第三方库、再赌它和主版本兼容」。仓库在 github.com/vllm-project/humming。

对本地化部署的三点含义

国产卡的地板抬高了「CUDA 兼容」这条路一旦走通，国产加速卡的适配成本从「改内核」降到「改参数」，混合部署（存量英伟达 + 新增国产）的运维复杂度明显下降。
量化不再是精度换速度的赌博W4A8 相比 W4A16 同时拿到吞吐与首 token 的双向改善，说明在这条路径上「更激进的量化」可以兼得体验，前提是内核实现足够好。
复测仍要自己做官方数据是 DeepSeek-V4.1-Flash 在自家测试环境下、指定并发与上下文的口径；换模型、换卡、换上下文长度，收益会变，甚至可能为负。

机悟的建议：把「内核层」也写进 POC 清单

以前 POC 只比模型，现在要往下一层看内核与引擎：

同题对比拿自有 20–50 条真实任务，在「同模型 + 同卡 + 不同内核」下比首 token 延迟、输出吞吐与答案质量，别只比峰值。
盯住长上下文并发 64 的收益不等于长文档场景的收益，K/V 与显存占用要单独测一遍。
国产卡先小规模验用一颗或两颗国产兼容卡跑通链路，再谈批量采购；跑通了才谈整机。
版本锁定把 vLLM / 内核版本写进交付清单与升级策略，避免「顺手升级」把生产性能打回原点。

来源：vLLM 官方博客《Announcing Humming: Fast, Flexible Kernels for Quantized Inference》（2026-10-21，作者为蚂蚁集团与 vLLM 社区）、GitHub（vllm-project/humming）。吞吐、延迟与编译时间为官方测试口径，换硬件、模型与并发后表现不同，需以自有任务集复测为准。本文仅转述公开报道，不评判任何企业与产品，不构成投资建议。