【Bug已解决】[BUG] FP8 model cannot inference on B200 (SM100) 解决方案一、现象长什么样把一个 FP8 量化的模型或开启 FP8 推理的 transformers 模型放到 NVIDIAB200Blackwell 架构compute capabilitySM100即sm_100/sm_120上推理常见两种失败RuntimeError: FP8 is not supported on this device (compute capability ...)或者RuntimeError: FP8 scaling format mismatch / invalid scale tensor dtype又或者更隐蔽——推理不报错但输出全是 NaN/Inf或精度严重崩坏。这种静默错误在 B200 上尤其危险因为 B200 确实支持 FP8sm_100是 Blackwell 的 FP8 代只是FP8 的 scaling 格式变了B200 引入了新的UE8M0scale 格式无符号 8 位指数、无尾数而老 GPUH100sm_90用的是e4m3/e5m2的 per-tensor/per-block scale。若代码还按老格式构造 scale 张量B200 上直接不兼容或数值错乱。本质FP8 在 B200 上的底层支持与老 GPU 不同新 scale 格式、新指令而推理框架的 FP8 检测/scale 构造逻辑没覆盖SM100于是要么拒绝运行要么用错 scale 格式导致数值错误。二、背景FP8 在 NVIDIA GPU 上有两个层面的代差H100sm_90时代FP8 用e4m3有符号 4 指数 3 尾数表示数据e5m2表示梯度scale 通常是fp32标量或较小的 per-block scale 张量。B200sm_100/sm_120Blackwell时代支持 FP8 的同时引入了UE8M0scale 格式——纯指数、无尾数、无符号专门配合新的 FP8 矩阵乘指令做高效的 per-block/per-tensor scaling。transformers / torchao 里做 FP8 推理时会先检测设备是否支持 FP8通过torch.cuda.get_device_capability()和能力表判断。若代码里的支持表只到sm_90那么 B200sm_100会被判为不支持直接拒绝。再构造 scale 张量用fp32标量或特定 dtype 的 scale buffer。若 B200 要求UE8M0而代码造了fp32/e4m3scale指令执行报错或数值崩。下面用可运行代码复现FP8 支持检测表未覆盖 SM100 导致拒绝推理以及scale 格式不匹配。三、根因根因一句话B200SM100的 FP8 支持新UE8M0scale 格式、新指令未被推理框架的 FP8 检测表与 scale 构造逻辑覆盖导致要么被判为不支持而拒绝运行要么用旧 scale 格式构造 scale 张量而在新硬件上数值错误/崩溃。三个具体失配能力检测表停在 sm_90B200sm_100被判不支持推理被拒。scale 格式未适配 UE8M0B200 要UE8M0scale代码造了fp32/e4m3不兼容。静默数值错误scaling 错误不报错输出 NaN/Inf比拒绝更危险。四、最小可运行复现用纯 Python 模拟FP8 支持检测表未覆盖 SM100 导致拒绝推理from dataclasses import dataclass from typing import Tuple # 老代码的能力支持表只到 sm_90 LEGACY_FP8_SUPPORT {(8, 0): True, (8, 6): True, (9, 0): True} def device_capability() - Tuple[int, int]: # 模拟 B200 sm_100 - (10, 0) return (10, 0) def can_run_fp8() - bool: cap device_capability() # 错误点表里没有 (10,0)返回 False - 拒绝 return LEGACY_FP8_SUPPORT.get(cap, False) def main(): supported can_run_fp8() if not supported: print(复现到拒绝: B200(SM100) 不在 FP8 支持表中推理被拒) # 正确把 SM100 加入支持 extended dict(LEGACY_FP8_SUPPORT) extended.update({(10, 0): True, (12, 0): True}) assert extended[device_capability()] is True print(修正后: B200 被识别为支持 FP8) if __name__ __main__: main()运行会打印复现到拒绝: B200(SM100) 不在 FP8 支持表中推理被拒——正是检测表未覆盖新架构的本质。五、解决方案第一层最小直接修复最立竿见影的修复把 FP8 支持检测扩展到SM100并针对 B200 使用正确的 scale 格式UE8M0。即不再用硬编码到 sm_90 的表而是capability (9,0) 即支持并在 B200 上用UE8M0构造 scale。import torch def fp8_supported(capability: tuple) - bool: 修复compute capability (9,0) 即支持 FP8含 B200 的 10.0。 major, minor capability return (major, minor) (9, 0) def make_scale(buffer, capability): 修复B200(10.0) 用 UE8M0 scale老卡用 fp32 scalar。 if capability (10, 0): # Blackwell: UE8M0 scale纯指数无尾数 # 这里示意把 scale 转成 uint8 表示的 UE8M0 scale_u8 (buffer.float().clamp(1e-6, 1e6).log2().round() .clamp(0, 255)).to(torch.uint8) return scale_u8 else: return buffer.float() # 老卡 fp32 scale def main(): cap (10, 0) # B200 assert fp8_supported(cap) s make_scale(torch.tensor([0.5, 1.0]), cap) print(B200 上 scale dtype:, s.dtype, (UE8M0 应为 uint8)) if __name__ __main__: main()第一层修复让 B200 被正确识别为支持 FP8且 scale 格式适配 Blackwell推理通过。六、解决方案第二层结构性改进把FP8 能力检测 scale 格式选择收口成一个Fp8Backend根据 capability 自动选择支持状态与 scale 策略避免散落的硬编码表再次遗漏新架构。import torch from dataclasses import dataclass from typing import Tuple dataclass class Fp8Backend: capability: Tuple[int, int] property def supported(self) - bool: # 所有 (9,0) 的架构H100/B200/...都支持 FP8 return self.capability (9, 0) property def scale_format(self) - str: # B200(10.0) 用 UE8M0其余用 fp32 return ue8m0 if self.capability (10, 0) else fp32 def make_scale(self, raw: torch.Tensor) - torch.Tensor: if self.scale_format ue8m0: return (raw.float().clamp(1e-6, 1e6).log2().round() .clamp(0, 255)).to(torch.uint8) return raw.float() def main(): for cap in [(9, 0), (10, 0), (12, 0)]: b Fp8Backend(cap) print(fcap{cap}: supported{b.supported}, scale{b.scale_format}) if __name__ __main__: main()第二层的关键是Fp8Backend用capability 比较而非枚举表新架构11.0/12.0...自动被纳入且 scale 格式随架构自动切换杜绝支持表漏更新的回归。七、解决方案第三层断言 / CI 守护加 pytest 守护(1) B200 capability 必须判定为支持 FP8(2) scale 格式在 10.0 必须是 ue8m0(3) 老卡(9.0)用 fp32 scale(4) 不支持的架构(9.0)必须拒绝。import torch import pytest class Fp8Backend: def __init__(self, cap): self.cap cap property def supported(self): return self.cap (9, 0) property def scale_format(self): return ue8m0 if self.cap (10, 0) else fp32 def test_b200_supported(): assert Fp8Backend((10, 0)).supported is True def test_b200_ue8m0_scale(): assert Fp8Backend((10, 0)).scale_format ue8m0 def test_h100_fp32_scale(): assert Fp8Backend((9, 0)).scale_format fp32 def test_old_gpu_rejected(): assert Fp8Backend((8, 0)).supported is False if __name__ __main__: pytest.main([__file__, -q])CI 里test_b200_supportedtest_b200_ue8m0_scale通过就能保证新架构B200 及以后的 FP8 推理能力被正确识别与适配防止支持表漏更新回归。八、排查清单FP8 模型在 B200 上推理失败时按此顺序查看报错类型是不支持 FP8的拒绝还是 scale 格式不匹配的 RuntimeError还是 NaN 的静默错误。查能力检测表torch.cuda.get_device_capability()在 B200 返回(10,0)或(12,0)确认框架的 FP8 支持判断 (9,0) 而非枚举到 (9,0)。查 scale 格式B200 要求UE8M0scale确认代码在capability (10,0)时切换到该格式。升级 transformers/torchao较新版本已支持 Blackwell FP8老版本需打补丁。NaN 静默错误若推理不报错但输出乱重点查 scale dtype 是否错配fp32 scale 喂给要 UE8M0 的指令。用 Fp8Backend 兜底用capability 比较替代枚举表新架构自动支持。验证数值合理在 B200 上跑一个小样本确认输出与 H100 量级一致允许 fp8 正常误差。九、小结FP8 模型无法在 B200SM100推理根因不在硬件不支持——B200 是支持 FP8 的 Blackwell 架构问题在于推理框架的 FP8 能力检测表停在sm_90把 B200 判为不支持而拒绝即使放行FP8 的 scale 格式也从 H100 的fp32/e4m3变成了 B200 的UE8M0旧 scale 构造逻辑会不兼容或数值崩坏。后者更危险因为可能静默输出 NaN。修复三层第一层把 FP8 支持判断从枚举到 sm_90改成capability (9,0)并在10.0用UE8M0scale第二层用Fp8Backend把能力scale 格式收口用比较替代枚举新架构自动纳入第三层用 pytest 断言B200 支持、用 ue8m0、老卡用 fp32、旧卡拒绝。记住B200 的 FP8 不是不支持是 scale 换了 UE8M0检测别再写死 sm_90。