[Bug]: Kimi-K3-NVFP4 on 8xB300 produces degenerate, incoherent output in the reasoning channel on v0.27.0

问题场景

在单节点 8x B300 上使用 vllm/vllm-openai:v0.27.0 镜像，以 tensor parallel 8 方式 serving RedHatAI/Kimi-K3-NVFP4。同物理节点、同 GPU、同 driver、同 weights、同 flags 的情况下，仅将 nightly build（2026-08-09）切换为 v0.27.0 release tag，即出现输出退化。同样的症状也出现在 GLM-5.2-FP8 on 8x B200、以及 v0.27.1 + B200 + NVFP4 的配置上。

报错原文

[Bug]: Kimi-K3-NVFP4 on 8xB300 produces degenerate, incoherent output in the reasoning channel on v0.27.0

G now now now now now now now now now now now now now now now now now now now now now now
{ how are now now now now now now
)
[ how are now }
[ are now now now now now now now now
 are now
[ is now now is now
[ G is now now is now now
 )
G is now
[ now now is now now now now now now now now now now now
= is now now
= now now is now
- is now
-G is now
- now now
- G now
-G is this
- this
- this
- this

没有 CUDA errors、没有 illegal memory access、没有 assertion failures、没有 NaN 相关 abort、没有 engine restart。Pod 保持 Running，0 restarts，latency 正常，health checks 与 metrics 也完全正常。

原因分析

可能原因是 v0.27.0 这条 release branch 上引入的某个改动，导致在该硬件 + 量化精度组合下推理语义被破坏，但进程层没有暴露任何错误。根据 Issue 中列出的 v0.27.0 相对 2026-08-09 nightly 的 commit 列表，非 model-specific 的候选只有三个：[CI] Fix Batch Invariance (B200) #51417、[Bugfix] Keep mamba align prefill chunks block-aligned past last_cache_position #51113、Bump Flashinfer version to 0.6.16.post3 #50892。其中 #51417 只是把 quack-kernels 固定到 0.6.1（与 v0.26.0 相同），可基本排除。剩余最可疑的是 mamba 对齐修复或 FlashInfer 版本更新，但这只是基于 commit 列表的推测，报告者本人也未做逐 commit bisect。

另一个值得注意的信号是跨模型复现：Kimi-K3/NVFP4 on B300 与 GLM-5.2/FP8 on B200 都在 v0.27.0 边界出现回归，且 GLM 案例中把 --kv-cache-dtype 从 fp8_e4m3 改成 fp_ds_mla 再改回来，都不能恢复。这进一步指向 v0.27.0 本身，而非模型权重或 KV cache dtype 配置。

环境排查

• 确认 vLLM 镜像 tag 与内部版本：vllm/vllm-openai:v0.27.0 / vLLM 0.27.0；同题报告还涉及 v0.27.1。
• 确认 torch 版本：2.13.0+cu130。
• 确认 FlashInfer 版本：0.6.16.post3。
• 确认 Triton：3.7.1；transformers：5.15.0。
• 确认 CUDA runtime：13.0.88；NVIDIA driver：595.71.05。
• 确认 GPU：8x NVIDIA B300 SXM6 AC（288 GB each，NV18 full mesh）或 8x B200。
• 确认 Python：3.12.3；glibc：2.39；OS：Ubuntu 24.04.3 LTS / Talos Linux kernel 6.18.34-talos。
• 对照可用的 nightly 构建（本例中为 2026-08-09 nightly），确认其为未出现该症状的对照组。
• 记录启动日志中解析出的 attention / MoE backend 路径，便于后续 bisect。

解决步骤

1. 在出现退化输出的节点上，先确认当前运行的是否为 vllm/vllm-openai:v0.27.0（或 v0.27.1）。
2. 首选处理：将部署回退到 2026-08-09 的 nightly build，或回退到 v0.26.0。报告者分别在两种回退下恢复正常输出，GLM-5.2 案例在回退到 v0.26.0 后恢复。
3. 如果业务允许跟进修复，升级到 v0.28.0。Issue 中明确记录 v0.28.0 不再复现该问题，GLM 5.2 正常 serving。
4. 若必须停留在 v0.27.x 排查，不要仅调整 --kv-cache-dtype（在 GLM 案例中从 fp8_e4m3 改为 fp_ds_mla 再改回均无效），应转向比较 build / commit 差异。
5. 在下一次复现时，按 Issue 维护者建议采集以下材料以便定位：可复现的 immutable image digest（尤其是工作正常的 Aug 9 nightly）、其 vLLM commit 与依赖版本、启动日志中解析出的 attention/MoE backend 路径、以及固定 prompt 的 token-ID / logprob diff。
6. 可优先尝试添加一个小的确定性 semantic canary：用一个固定短 prompt，检查 reasoning channel 是否出现重复退化 token；这种 canary 能在 health 与 latency 都正常时捕捉到“语义被破坏”的失败模式。

验证方法

使用 Issue 中同样的极短 prompt（例如 hello how are you）发请求，检查 reasoning channel 是否还出现 now now now now ... 之类的重复退化文本。同时确认进程没有 CUDA error、无 engine restart、latency 与升级前一致。若回退到 nightly 或 v0.26.0 后输出恢复正常语义、升级到 v0.28.0 后也能正常输出，即可确认问题已解决。由于原报告者已经回滚并删除了故障容器，无法再对 v0.27.0 现场取证，所以验证应基于固定 canary prompt + logprob 差异来做，而不是依赖曾经的历史日志。

参考来源

vllm-project/vllm #51798

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。