BF16/FP8/MXFP4/MXFP8/UE8M0：数字格式与 511GB 显存账本
"MXFP4 量化"翻译成人话就是一个参数半个字节。把官方 511 GB 的账本逐项算一遍：专家 259.5 GiB、Engram 183.1 GiB，而光"块 scale"就要占 21.9 GiB。顺带说明数字格式如何决定硬件能不能跑（MI325X 没有 FP4 MFMA，MXFP4 专家只能走 Triton），以及 GB 与 GiB 之间那 7% 的差异。
本篇属于系列 关于deepseek部署你要知道的一切 · 第 9 篇
来源：vLLM Recipes · deepseek-ai/DeepSeek-V4.1-Flash（页面标注 Updated 2026-09-20）
说明 本文是系列《关于deepseek部署你要知道的一切》的第 9 篇，面向只熟悉 vanilla transformer 的读者，把官方页面里的术语逐个拆开解释。文中所有数字、参数与命令均来自上述页面，未作独立核实。
一句话结论
“这台模型是 MXFP4 量化的”这句话，翻译成人话就是：一个参数只占半个字节。 本篇把官方给出的 511 GB 权重账本逐项算一遍，你会看到三件事： ① 量化格式的选择完全跟着“哪块参数最多”走；② 省下来的显存有一部分要还给“块 scale”（23.6B 个，21.9 GiB）；③ 量化不是部署时的可选项，权重的格式是发布时就定死的。
先扫盲：一个“数字”到底能有多小
计算机里存一个浮点数，需要三样东西：符号（正负）、指数（量级，比如 10⁻³ 还是 10³）、尾数（有效数字）。
| 格式 | 总位数 | 组成 | 单个参数占多少字节 |
|---|---|---|---|
| FP32 | 32 | 1 + 8 + 23 | 4 |
| BF16 | 16 | 1 + 8 + 7 | 2 |
| FP8（E4M3 / E5M2） | 8 | 1 + 4/5 + 3/2 | 1 |
| MXFP4 | 4 | 1 + 2 + 1（+ 共享 scale） | 0.5 |
规律很直白：位数越少，能表示的范围和精度越差。FP4 只有 4 个 bit， 理论上只能表示 16 个不同的值——听起来完全不能用来存权重。
所以真正的招数是“分块共享 scale”。 MXFP 是 OCP 的微缩放（microscaling）规范： 把若干个元素（常见是 32 个）划成一块，这一块共用同一个缩放系数， 块内的每个 4 bit 数只存“相对这块的偏移量”。读取时，取出来乘上这块的 scale， 就恢复成接近原来的量级。（这部分属于通用背景知识，页面只给了结论。）
那个共享的 scale 用 E8M0 格式：8 位、全是指数、没有符号位也没有尾数。 一个纯指数意味着它只能表示 2 的幂次——对“缩放”来说刚好够用，而且便宜（1 字节）。
官方账本，逐项算一遍
| 组件 | 条目数 | 存储 | 格式 |
|---|---|---|---|
| 路由专家 + DSpark 专家 | 557.2B | 259.5 GiB | MXFP4 |
| Engram 表 | 196.6B | 183.1 GiB | FP8 |
| 注意力、dense 投影、路由器 | 7.4B | 6.9 GiB | FP8 |
| Embedding + LM head、norm | 2.0B | 3.9 GiB | BF16 / FP32 |
| UE8M0 块 scale | 23.6B | 21.9 GiB | E8M0（1 字节/个） |
自己验算一下，这套账是自洽的：
- 专家：557.2B × 0.5 字节 = 278.6 GB ≈ 259.5 GiB ✅（正好对上）
- Engram：196.6B × 1 字节 = 196.6 GB ≈ 183.1 GiB ✅
- 块 scale：23.6B × 1 字节 = 23.6 GB ≈ 21.9 GiB ✅
注意最后一行：光“缩放系数”就占了 21.9 GiB。 这是量化文章里最容易被忽略的一笔——你省下的显存，有一部分要还给 scale。 （顺便说：scale 有 23.6B 个，而专家有 557.2B 个参数，说明不是每 32 个参数才一个 scale， 真实的分块粒度比教科书例子更细。这个数字就是证据。）
同一份权重，为什么有两个大小？
官方说“磁盘上约 511 GB（476 GiB）”。两个数字指同一份东西：
GB 是 10 的 9 次方（1000³），GiB 是 2 的 30 次方（1024³）。
511 ÷ 1.0737 ≈ 476——买卡时按 GiB 算，看文件大小时按 GB 算，差出来的 7% 经常让人算错容量。
为什么是“混合格式”而不是全用一种
看格式分配就知道设计逻辑：按参数规模分配精度。
- 专家最多（557.2B）→ 用最狠的 MXFP4。 省下的绝对值最大，而且 MoE 专家每个只被少数 token 用到， 单个专家的精度损失对整体影响相对可控。
- Engram、注意力、dense 投影（合计 204B）→ 用中间档 FP8。
- Embedding 和 LM head（2.0B）→ 保持 BF16。 这两块直接对应“词表”和“输出分布”， 是精度最敏感的地方，但它俩加起来才 2B 参数——用最高精度也不心疼。
- norm 用 FP32。 归一化层的数值范围小、又影响每一层的动态，32 位换稳定性，值。
一句话：把位数花在刀刃上，把省下来的字节花在最胖的地方。
部署视角：格式决定了你能选哪些硬件和内核
这是本篇最实用的一节——数字格式不是抽象的精度话题，它直接决定硬件能不能跑。
- MI325X（gfx942）没有 FP4 MFMA（AMD 的矩阵乘加指令），所以 MXFP4 专家只能走 Triton 内核， 官方在页面上也点了这个原因，并说“设备显存用在 KV 上比用在常驻 Engram 表上更划算”。
- MI355X / Blackwell 有 FP4 支持，所以能用上更快的路径（Blackwell 上走
deep_gemm_mega_moe）。 - KV cache 也在量化：KV 被训练为以 FP4 存储，全局 KV 是 890 字节/token；
Blackwell 上还额外把 indexer 的 KV 设为
mxfp4、把--kv-cache-dtype设为fp8。 - 量化权重不是你选的：你下载的 checkpoint 本身就是 MXFP4/MXFP8 混合格式， 没有“先下载 BF16 再自己量化”的选项（50 多个 B 参数级模型 + 特殊架构，也不现实）。
三个常见误解
你以为：4 bit 就意味着精度只有 16 分之一之类。 实际上：精度取决于“分块粒度”和“训练时是否按这个格式训练”。 这台模型是带着 MXFP4 训练/发布的，不是事后硬压——模型知道并适应了自己的精度。
你以为：量化只省显存，不影响速度。 实际上：省显存最直接，但也改变了内存带宽占用（decode 阶段的主要瓶颈），所以通常同时变快； 代价是解包（把 4 bit 还原成可计算格式）本身要算力，且需要硬件支持——所以才有上面那些内核差异。
你以为：vram_minimum_gb: 614 是权重大小，所以装不下就是配置问题。
实际上：614 = 511 GB × 1.2，那 20% 是 schema 给运行时留的余量（KV、CUDA graph、框架开销、碎片）。
权重只是门槛，不是全部。
术语卡片
| 术语 | 中文 | 一句话定义 |
|---|---|---|
| BF16 | — | 16 位浮点，1 符号 + 8 指数 + 7 尾数 |
| FP8 | — | 8 位浮点，有 E4M3 / E5M2 两族 |
| MXFP4 / MXFP8 | 微缩放 4/8 位 | OCP 规范：一块元素共享一个缩放系数，块内元素用 4 或 8 bit |
| block scale | 块 scale | 每个块共享的缩放系数，用来把小块内的低位宽数值拉回正确量级 |
| UE8M0 | — | 无符号 8 位纯指数格式，用来存块 scale（1 字节/个） |
--kv-cache-dtype fp8 |
KV 缓存精度 | 把 KV cache 以 FP8 存储（本模型全局 KV 则是 FP4，890 字节/token） |
| MFMA | 矩阵乘加指令 | AMD GPU 上的矩阵运算指令；gfx942 没有 FP4 版本 |
小结
- MXFP4 = 每参数 0.5 字节；按参数规模分配精度：最胖的专家用最狠的格式，最敏感的 embedding 保持 BF16。
- 块 scale 本身要占 21.9 GiB——量化不是白省，账要算全。
- 格式决定硬件与内核：没有 FP4 MFMA 的卡只能走 Triton 路径；权重格式是发布时定死的，你选不了。
下一篇：《猜 5 个再验一遍：投机解码与 DSpark 草稿头》——讲清 decode 阶段唯一的提速手段，以及它为什么在 AMD 上要关掉一个开关。
讨论
这里是静态站点，没有内嵌评论区。如果这篇文章对你有用，欢迎通过 RSS 订阅后续更新。