FP4/FP8 量化:值域、Scale 与运行时合同
区分 FP4/FP8 数值格式、Current/Delayed/Block scaling、NVFP4 与 MXFP8,并说明 Checkpoint 到 Kernel 的能力边界
讨论 FP4/FP8 时必须拆成三层:E4M3、E5M2、E2M1 等值格式,Scale 的时间来源、共享粒度与自身类型,以及设备和引擎最终执行的运行时路径。少写其中一层,就无法判断模型到底存了什么、算了什么。
旧式“FP8 固定使用 per-128×128”“NVFP4 就是 per-32 E8M0”“MXFP4 等于 NVFP4”都不成立。数值格式和 Scale recipe 不能混为一谈。
- 一句话:FP4/FP8 只有与 Scale recipe 和实际 Kernel 一起描述,才是一份可执行的低精度合同。
- 三个判断:E4M3/E2M1 不定义 Scale 粒度;NVFP4 不等于 MXFP4;Checkpoint 标签不能证明原生低精度执行。
- 核心模型:用
低精度值 × block Scale × global Scale还原数值,再用checkpoint + recipe + engine + architecture + shape定位实际路径。 - 边界:理论 payload 不是实例显存,硬件峰值也不是端到端 TPS;版本、shape、padding 与 fallback 都要进入验收。
从 AMX 迁移的直觉:E4M3/E2M1 对应低精度 operand 格式,Scale 对应表示范围合同,Tensor Core 类似专用 tile 矩阵乘单元,FP32 accumulator 则对应 AMX 中“窄输入、宽累加”的数值保护。类比只到执行合同为止;两者的并行规模、存储层次和支持格式并不相同。
1. FP8 值格式
NVIDIA Transformer Engine 当前定义两种 FP8:
| 格式 | 位布局 | 最大有限幅值 | 取舍 |
|---|---|---|---|
| E4M3 | 1 sign + 4 exponent + 3 mantissa | 448 | 尾数更多,精度相对更高 |
| E5M2 | 1 sign + 5 exponent + 2 mantissa | 57344 | 动态范围更大,精度相对更低 |
这张表只描述值本身。同一个 E4M3 张量可以使用 per-tensor、per-channel 或 block scaling,Scale 也可能来自当前 amax、历史 amax 或每个 block 的动态计算。
2. FP8 的三种典型 Scale 配方
2.1 Current Scaling
Current Scaling 根据当前张量的 amax 计算 Scale,然后再执行 cast:
它能跟随当前分布,但通常需要一次读取求 amax、再读取并转换。
2.2 Delayed Scaling
Delayed Scaling 使用历史 amax 估计当前 Scale。它减少了本次量化前的张量扫描,但 Scale 对突发分布变化的响应更慢。
Current 与 Delayed 都可以使用 E4M3/E5M2;区别在 Scale 的时间来源,不是值格式。
2.3 MXFP8
MXFP8 是 microscaling FP8:
- 数据值使用 FP8 E4M3。
- 每 32 个连续元素共享一个 E8M0 Scale。
- Scale 是 2 的幂,适合硬件 block scaling。
- 每个 block 独立,减少整个张量被少数 outlier 拉宽的问题。
MXFP8 的 32 + E8M0 不能套到 NVFP4 上。
3. NVFP4 的分层 Scale
NVFP4 的低精度值采用 E2M1,可表示的幅值集合为:
0, ±0.5, ±1, ±1.5, ±2, ±3, ±4, ±6
Transformer Engine 的 NVFP4 使用分层 scaling:
x_E2M1:4 bit E2M1 值。s_block:每 16 个连续元素共享的 FP8 E4M3 Scale。s_global:整个张量共享的 FP32 Scale。
对于权重,Transformer Engine 默认还可以采用 16×16 的二维 scaling;激活和梯度使用一维 16-element block。二维权重 Scale 的布局不能用一维公式直接估算。
NVFP4 与 MX 家族不是同义词
| 方案 | 数据值 | Local Scale | Block | 额外全局 Scale |
|---|---|---|---|---|
| MXFP8 | FP8 E4M3 | E8M0 | 32 | 无 |
| NVFP4 | FP4 E2M1 | FP8 E4M3 | 16 | FP32 per-tensor |
| OCP MXFP4 | FP4 E2M1 | E8M0 | 32 | 无 |
NVFP4 与 MXFP4 都使用 E2M1,不代表它们拥有相同的 Scale 类型、block size、数值误差或 Kernel 合同。
4. 从 Checkpoint 到 Kernel
Checkpoint 中出现 fp4 或 nvfp4,只能证明存储或 recipe 元数据;不能自动证明硬件执行了原生 FP4 MMA。
真实路径由以下联合决定:
(checkpoint format,
recipe and scale layout,
engine version,
kernel backend,
GPU architecture,
operand shape)
→ executed runtime path
可能结果包括:
| 结果 | 含义 | 验证证据 |
|---|---|---|
| Native | 低精度 operand 直接进入目标 Tensor Core 路径 | Kernel 名、operand dtype、设备能力 |
| Cast / dequant | 存储为低精度,计算前转换为 FP8/BF16 | Q/DQ 或 cast Kernel、额外中间张量 |
| Pre-expand | 加载阶段展开为更高精度常驻 | 加载日志、实际 HBM、权重 buffer dtype |
| Fallback / reject | 不支持该 recipe 或 shape | Warning/error、替代 Kernel、性能与容量异常 |
Hopper 支持原生 FP8 Tensor Core;原生 FP4 计算属于 Blackwell 及之后的设备能力。H100/H200 如何处理一个 FP4 Checkpoint 不是统一答案:引擎可能转换、展开、回退或拒绝,因此不能直接写死“显存一定翻倍”。
5. Scale Metadata 的容量账本
以下只用于理解数量级,真实实现还要加 padding、alignment、transpose copy 和未量化层:
| 配方 | 数据 bytes/value | Scale 开销 | 备注 |
|---|---|---|---|
| FP8 per-tensor | 1 | 每张量约一个 FP32 Scale | 不包含 amax history |
| MXFP8 | 1 | 每 32 值一个 E8M0 byte | 约 1 + 1/32 bytes/value |
| NVFP4 1D | 0.5 | 每 16 值一个 E4M3 byte + 全局 FP32 | 约 0.5 + 1/16 bytes/value |
| NVFP4 2D weight | 0.5 | 按 16×16 tile 组织 Scale | 以实际布局和 padding 计算 |
模拟器不应只存一个 dtype -> bytes 映射。至少要记录:
value format
scale format
scale granularity
packing and padding
runtime expansion
excluded high-precision tensors
6. FP4/FP8 的性能边界
容量收益
只要低精度数据保持压缩存储,权重或 KV 的 HBM 占用就会下降;但比例要包含 Scale、padding 和高精度例外。
带宽收益
Decode 等 memory-bound 路径可能因为读取字节减少而受益。前提是解包、Scale 读取、cast 和不连续访问没有抵消收益。
计算收益
只有设备和 Kernel 对目标 operand 组合提供原生支持,低精度峰值算力才有意义。不要用硬件峰值表直接推导端到端 TPS:
对于混合精度模型,每个算子应使用自己的精度峰值和实际时间建模,而不是把 FP4、FP8、BF16 FLOPs 相加后统一除以一个峰值。
7. 实际核对清单
Checkpoint
- 权重值格式是什么?
- Scale dtype、shape 和 block size 是什么?
- 哪些层没有量化?
- 是否同时保存 rowwise/columnwise 或 transpose copy?
Runtime
- 引擎版本是否支持该 recipe?
- 设备 compute capability 是否支持目标低精度 Kernel?
- 日志和 trace 中的 operand dtype 是什么?
- 是否出现 cast、dequant、pre-expand 或 fallback?
Acceptance
- 实际峰值 HBM 是否与容量账本一致?
- TTFT、TPOT、TPS 是在完全相同 Case 下比较的吗?
- 质量是否覆盖 PPL、任务分数、长上下文和业务样本?
相关页面
- CPU 工程师理解量化 — AMX/VNNI 与 Tensor Core 的共性和边界
- 量化基础 — 量化对象、Scale 粒度和性能边界
- 量化方法与评测 — PTQ/QAT 方法族和四道验收门
- GLM-5.2 量化执行图 — 混合精度如何落到真实算子
- MoE 推理 — Expert 权重、Grouped GEMM 与 EP
- 模拟器建模指南 — 精度和 metadata 如何进入容量与吞吐模型
参考资料
← 被以下页面引用(8)
- 量化方法与评测:从 PTQ/QAT 到可复现实验ai-systems · synthesis
- 模拟器建模指南:显存与吞吐公式ai-systems · synthesis
- CSA/HCA 注意力:DeepSeek-V4 的混合压缩稀疏机制ai-systems · synthesis
- Kimi K3:架构、训练与推理系统研究ai-systems · synthesis
- MoE 推理:Expert Parallelism(EP)、显存与调度ai-systems · synthesis
- 从 AVX/AMX 到 Tensor Core:CPU 工程师理解 LLM 量化ai-systems · comparison
- 量化:从 Scale 到 W4A8 的完整坐标ai-systems · concept
- GLM-5.2 量化执行图:W4A8、BMM 与 KV8ai-systems · concept
修改历史7 次提交
- docs: refine LLM inference knowledge systemxiaocheng··
f8756b9 - docs(wiki): bridge CPU and GPU quantizationxiaocheng··
a04dd83 - docs(wiki): deepen quantization researchxiaocheng··
98221ea - feat(site): polish wiki discovery and reading experiencexiaocheng··
e5d16c9 - feat(wiki): enforce lifecycle metadata and search aliasesxiaocheng··
1dad7ef - feat(wiki): connect core topics and add reading seriesxiaocheng··
9fc9884 - feat(wiki): ingest 4 raw articles + split inference survey into 5 pagesxiaocheng··
483c321