FineGrainedFP8 DeepGEMM path returns silently wrong results on SM100 (UE8M0 scale rounding without requantization)

问题场景

在 NVIDIA B200（SM100）上使用 transformers 加载 FineGrainedFP8 模型（如 Qwen/Qwen3-4B-FP8），通过默认的 from_pretrained 路径执行推理时触发。具体涉及 fp8_linear 在 SM100 上优先选择 DeepGEMM Hub 内核的 sm100_fp8_gemm_1d1d 路径，该路径要求 UE8M0（2 的幂）scale factor。复现时加载模型并比较启用/禁用 DeepGEMM 的隐藏状态输出：启用时 cosine 相似度接近 0（预期约 1.0），norm 比高达 7-15 倍（预期约 1.0）。该问题还可能导致生成文本完全无意义（如 Issue #46209 中 Qwen3-0.6B-FP8 在 B200 上的不连贯输出）。

报错原文

FineGrainedFP8 DeepGEMM path returns silently wrong results on SM100 (UE8M0 scale rounding without requantization)

原因分析

根本原因是 scale 处理不一致。具体来说：

• DeepGEMM 的 SM100 FP8 GEMM 内核（sm100_fp8_gemm_1d1d）只接受 UE8M0（2 的幂）scale factor。
• transformers 通过 _ceil_to_ue8m0 函数将 fp32 的 dequant scale 向上取整到最近的 2 的幂（系数在 [1,2) 之间），但没有对数据本身重新量化。
• Checkpoint 权重是基于原始 fp32 weight_scale_inv 量化的；激活值也使用原始 fp32 scale 进行量化（_select_fp8_cast_kwargs 对 fp32-scale checkpoint 返回 use_ue8m0=False）。
• 这样每个 128-block 的部分和都会被放大 1 到 2 倍（每个激活行块和每个 128×128 权重块独立放大），结果有限且无警告，但完全错误。

可能原因：该问题的修复（_assert_sm100_scales_are_ue8m0）在 Issue #46818 中已合并但未发布，且只保护了 MoE experts 前向路径，dense 路径的 deepgemm_fp8_fp4_linear 仍调用未加保护的 _coerce_sf_for_kernel。此外，DeepSeek 上游 DeepGEMM 已添加 non-power-of-two scale 的设备端断言（deepseek-ai/DeepGEMM#364），但 Hub 构建为兼容 cudagraph 移除了 Python 侧断言（huggingface/kernels-community#940），所以当前不会触发任何报错。

环境排查

• 确认 GPU 是否为 NVIDIA B200（SM100）——该问题仅影响 Blackwell 架构；SM90（H100）结果正确。
• 确认 transformers 版本是否为 5.12.1 或更早版本；main 分支已修复，检查是否有包含修复的发布版本。
• 确认 torch 版本（2.10.0+cu130）和 kernels 版本（0.12.3）。
• 确认 Hub 内核 kernels-community/deep-gemm 的 pinned 版本（rev 9590415046fa，内部 __version__ 2.5.0）。
• 确认模型是否为 FineGrainedFP8 checkpoint（fp32 weight_scale_inv，weight_block_size=[128,128]）。

解决步骤

1. 临时 workaround：在运行脚本前设置环境变量 TRANSFORMERS_DISABLE_DEEPGEMM_LINEAR=1，强制使用 Triton 回退路径。这是 Issue 中用户实际部署的已验证方案。
2. 升级 transformers 到包含修复的版本。main 分支已通过 assertion 修复（在 SM100 上检查 scale 是否为 UE8M0），并在 PR #47623 中增加了回归测试。可优先尝试升级到包含该 PR 的发布版本。
3. 如需继续使用 DeepGEMM，可参考 vLLM 的修复方向：在加载时对 UE8M0 scales 重新量化权重（见 vllm-project/vllm#22399）。但这需要自定义加载逻辑，且 vLLM 后续发现即使正确 requantization 仍有 5-12pp 精度下降（vllm-project/vllm#37804），最终在 Blackwell 上对这些模型类型自动禁用 DeepGEMM（vllm-project/vllm#38083）。
4. 验证当前环境：运行 Issue 中提供的复现脚本，比较启用/禁用 DeepGEMM 的隐藏状态 cosine 相似度和 norm 比，确认问题是否触发。

验证方法

运行 Issue 中提供的复现脚本，比较 TRANSFORMERS_DISABLE_DEEPGEMM_LINEAR=1 和 0 两种情况下的输出：

• 修复前（SM100 + DeepGEMM）：cosine 接近 0（约 -0.16 到 -0.03），norm 比 7-15 倍。
• 修复后（禁用 DeepGEMM 或使用修复版本）：cosine 约 1.0，norm 比约 1.0。

也可直接检查单次 FP8Linear 前向的相对误差（修复前约 0.8-1.1）和输出增益（修复前约 1.8-2.1 倍）。

参考来源

huggingface/transformers #47030

AI 工具推荐

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

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

了解 GamsGo AI

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