vLLM 在 8 月 10 号、11 号连着发了 v0.27.0 和 v0.27.1，561 个 commit、242 位贡献者，changelog 看着是真丰盛：Kimi K3 day-0 全栈支持、DeepSeek-V4 一大串性能优化、FlashAttention 4 的 FP8 KV cache 在 SM100 上落地，甚至连英伟达下一代 Rubin 的 sm_107 都提前铺了路。GitHub
但发版不到 48 小时，issue 区就成了翻车现场：一边有人美滋滋地 day-0 新模型，另一边有人发现，升到 v0.27 之后自己的 DeepSeek-V4-Flash 直接起不来了，还有个 8 卡 B300 的生产集群把 Kimi K3 部署默默回滚了。
这篇把社区这两天的排坑、定位、修复全过程捋成一张地图。准备升级的、已经卡住的，都建议先看完再动手。
先说值得升的部分，都是对老用户有实感的：
Kimi K3 是一个 release 内全栈落地——模型文件、kernel、Python 和 Rust 前端、DeepGEMM 支持、量化 checkpoint 一步到位，这种待遇在 vLLM 里不多见。GitHubDeepSeek-V4 的性能优化包也很实在：序列并行、跳过空 c128 launch 带来接近 2 倍的 kernel 提升、TTFT 几个百分点几个百分点地抠，外加 448 MiB 的 PP buffer 显存节省。
v0.27.1 这个补丁更有意思：它加了“量化 DSpark Markov head”支持——这玩意儿正好接住了这周英伟达刚发的 Nemotron 3.5 Lightning 附带的 DSpark 推测解码草稿模型，等于 day-0 适配的一部分。GitHub
但代价是：这个版本把 PyTorch 升到了 2.13.0，官方自己标注了“breaking environment change”，XPU 和 CPU 后端也跟着动。升级前先想想你的环境、镜像和自定义插件跟不跟得上。
然后是最大的坑：DeepGEMM 依赖回退，Blackwell 工作站和 DGX Spark 首当其冲。现象很明确：DeepSeek-V4-Flash-0731（FP8 + UE8M0 scale 格式）在 v0.26.0 上跑得好好的，换到 v0.27.0/v0.27.1 官方镜像直接加载失败，报“Unknown SF transformation”。受影响的正是这波本地 AI 的热门硬件：RTX PRO 6000 Blackwell、RTX 5090 这一档的 SM120 卡，还有 DGX Spark（SM121）。GitHub
社区把根因挖得很干净：7 月初 vLLM 本来已经把 DeepGEMM 指到带 SM120 支持的 nv-dev 分支；7 月底为了修 Kimi K3 的 DeepGEMM 支持，pin 被换成了 vllm-project 自己 fork 的一个 commit——它带 Kimi K3 需要的 SiTU 特性，但恰好丢了 SM120/SM121 的 scale-factor layout 分发分支。GitHub这个 pin 就这么进了 v0.27.0 发布。一个模型支持 PR，回退了一整档硬件，这就是事故链条。
好消息是修复已经落地，但落地的位置很讲究：8 月 12 号晚间，PR #52035 合进 main，把 DeepGEMM pin 直接换成上游 deepseek-ai/DeepGEMM nv_dev 分支最新的 8b1392b9——这个版本同时有 Kimi K3 要的 SiTU 和 SM120/SM121 kernel，两边都保住。GitHub但注意两点：第一，目前最新的 release 还是 v0.27.1，没有任何官方镜像带这个修复；第二，早期 issue 里流传的 #50796 和 pin 到 2fd67329 的方案，那个 PR 最后关闭没合入，跟着旧教程走的朋友需要更新一下姿势。
等不及下个版本的，现在有两条路。一是正经路：用仓库里的 tools/install_deepgemm.sh，–ref 指定 8b1392b978f5a03c828dd1711090d7fb50958b8a 重装 DeepGEMM，社区已经在 SM120/SM121 上实测过这个 commit。二是免重编译的应急路：issue #51758 里两位用户把 SM120 上的失败拆成了三道墙，并给出了绕过法——第一道墙用 --kernel-config ‘{“linear_backend”: “cutlass”}’ 把 dense fp8 线性层切回 CUTLASS。GitHub第三道墙（tf32_hc_prenorm_gemm 无条件调用）用一段 20 行左右的纯 Python guard 补丁绕过去。组合起来，原版 v0.27.1 镜像不重编也能把 DeepSeek-V4 跑在 SM120 上。不过说清楚：这是 fallback 不是修复，性能路径和修好 DeepGEMM 不一样，应急可以，长期还是建议换 pin。
顺带一个意外收获：那位在两台 DGX Spark 上做实验的用户反馈，换了新 pin 之后 TP=2 跑 400 请求 soak test 零挂起——而 v0.26.0 上 TP=2 跑 50 到 400 请求是必挂的。也就是说这波修复对 DGX Spark 用户可能是净赚。
第二个坑要单独说，因为它更隐蔽：B200/B300 数据中心卡上疑似出现“服务健康、输出损坏”的语义回归。issue #51798 里，8 卡 B300 跑 RedHatAI/Kimi-K3-NVFP4，v0.27.0 上 reasoning 通道输出退化、语无伦次，prompt 就一句 hello how are you，而且这是生产部署，已经回滚。GitHub同一个 issue 下，8 卡 B200 上的 GLM-5.2-FP8 也撞上了同类问题，换 kv-cache-dtype 没用，同样回滚 v0.26.0。
目前只有这两例，根因还没定位，不能直接下“v0.27 在 Blackwell 数据中心卡上全面翻车”的结论。但“健康检查绿、延迟正常、推理语义坏掉”是最难发现的一类故障，维护者也在征集 bisect 数据。如果你的生产集群在 B200/B300 上跑 FP8/NVFP4 的 MoE 大模型，升级前务必拿固定 prompt 做一轮输出对比 canary，别只看服务起没起来。
还有一笔账要算清楚，别算错到 v0.27 头上：DeepSeek-V4-Flash-0731 的 KV cache 膨胀是 checkpoint 自己的问题。H20 上实测每个 token 的 KV 占用约 56 字节、是 preview 版的 8 倍左右，max_model_len 被压到 12 万上下。GitHubB300 上 1M 上下文的并发从 preview 的 27 倍掉到 7.7 倍，KV 支撑的并发量大约缩水 3.5 倍。GitHub这个在 v0.26 上就存在，升级 v0.27 不会让它变好，回滚也不会让它消失，等的是 DeepSeek 那边修 checkpoint。
最后给个对照表，按你的硬件和模型对号入座：
Hopper/Ampere（H100/H200/A100）上跑常规模型的：可以升，但先处理 torch 2.13 的环境变化，回归一遍关键路径再切流量。
SM120/SM121（RTX PRO 6000 Blackwell、RTX 5090 档、DGX Spark）上跑 DeepSeek-V4-Flash 或其他 block-scaled FP8 模型的：别直接拉官方镜像升。要么等带 #52035 的下一个版本，要么按上面的方法手动换 DeepGEMM pin 并完整验证后再上。
B200/B300 生产集群跑 Kimi K3 NVFP4、GLM-5.2 FP8 这类 FP8 MoE 的：先观望 #51798 的根因结论，升级必须带输出级 canary。
想在 vLLM 上体验 Nemotron 3.5 Lightning 的 DSpark 推测解码的：v0.27.1 的量化 Markov head 支持已经就位，但 DeepSeek-V4 系的 DSpark 草稿量化修复 PR #51835 还没合，这条路径现在属于“部分可跑”。
接下来值得盯三个信号：下个版本（v0.27.2 或 v0.28）什么时候带上 DeepGEMM 修复；#51798 的语义回归能不能定位到具体 commit；#51835 合入后 DSpark 在 SM12x 上的完整验证。有进展我们再更新。
