🔢 mathematics

An 84-Format Numeric Catalog with Bit-Exact Conformance Vectors: A Vendor-Neutral Reference for FP8, BF16, MXFP4, and Microscaling Formats

本文提出了一个包含 84 种数值格式和六个位精确（bit-exact）一致性测试包的厂商中立目录，并附带经过交叉验证的 JSON wayfarer 构件和 IEEE P3109 交叉对照表，旨在为诊断机器学习硬件实现中的隐性差异提供统一的参考标准。

原作者： Dmitrii Vasilev

发布于 2026-06-09

📖 1 分钟阅读🧠 深度阅读

CC BY 4.0

原作者： Dmitrii Vasilev

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你是一位正在制作一把椅子的顶级木匠。你的蓝图上写着：“将这条腿切割成 24 英寸。”但当你去五金店时，发现有三把不同的尺子：一把标着“24 英寸”，另一把标着“24.1 英寸”，第三把标着“24 英寸，但如果切过 24 英寸，木头就会变成粉末。”

如果你用错了尺子，你的椅子起初看起来可能没问题，但当有人坐上去时，它会摇晃或断裂。

这篇论文讨论的是人工智能（AI）芯片领域中类似的难题。工程师们正在制造更快、更小的“尺子”（数值格式）来衡量数字。他们已经创造了数十种新的类型，例如 FP8、BF16 和 MXFP4。问题在于，虽然大家都对“尺子的名字”（例如“FP8 E4M3”）达成了一致，但并不总是在刻度是如何放置的这一点上达成共识。一个芯片可能会处理一个巨大的数字，将其限制在一个最大值；而另一个芯片在遇到这个数字过大时，可能会直接抛出一个错误（NaN）。

这篇论文引入了一个 “共享主尺”（Shared Master Ruler） 来解决这种混乱。

这篇论文是关于什么的？

作者 Dmitrii Vasilev 创建了两个主要工具，帮助工程师使用同一种语言进行交流：

“84 格式目录”（百科全书）：
你可以把它看作一本庞大的字典或图书馆卡片目录。它列出了计算机存储数字的 84 种不同方式，并分为 13 个家族。对于每种格式，它都列出了确切的规则：使用了多少位（bits）、数字能有多大，以及当数字过大时会发生什么（是停留在极限值，还是变成“非数字/NaN”？）。
- 类比： 这就像是一份包含现存所有类型螺钉、螺栓和螺母的主列表，并附带图表显示每种螺母的具体螺纹数。
“六个一致性包”（测试套件）：
论文不仅列出了规则，还提供了 六个特定的测试套件，用于目前 AI 硬件中使用的最流行的格式（GF16、MXFP4、BF16、FP8 E4M3、FP8 E5M2 和 E8M0）。
- 每个套件都是一个包含“测试数字”列表的数字文件。
- 它明确告诉你，计算机芯片对于每个数字应该输出什么结果。
- 它包含一个特殊的“锚点数字”（数值为 3.0），作为一项合理性检查。如果你的芯片无法正确处理这个特定数字，你就知道出问题了。
- 类比： 这些就像是放在秤上的“校准砝码”。如果当你放上 3.0 磅的砝码时，秤显示的不是正好 3.0 磅，你就知道秤坏了。

重大发现：“解释差异”（The Interpretation Gap）

这篇论文最重要的部分不仅仅是这些“尺子”的存在，而是作者发现即使官方规则说两种方式都是允许的，但尺子在两个特定地方存在分歧。

差异 1（溢出问题）： 想象一个数字非常巨大，以至于无法放入该格式中。
- 芯片 A 说：“我会直接把它限制在我能容纳的最大值。”（饱和处理/Saturation）
- 芯片 B 说：“我装不下这个，所以我会把它变成一个错误信息（NaN）。”
- 两款芯片都在遵循官方规则手册，但它们的操作方式不同。这篇论文揭示了这种差异，这样工程师就不会在模型在一款芯片上运行正常但在另一款芯片上失败时感到困惑。
差异 2（块结构问题）： 一些格式将数字分组在“块”中（就像一盒 32 颗螺钉）。
- 格式 A 使用一个装有 32 颗螺钉的盒子，并配有一个简单的标签。
- 格式 B 使用一个装有 16 颗螺钉的盒子，并配有一个更详细的标签。
- 即使单个螺钉（数字）看起来一样，但它们打包在一起的方式改变了整个系统的运作方式。论文强调，在不检查“盒子大小”的情况下，你不能直接更换这些格式。

这篇论文不是关于什么的

作者非常明确地说明了这篇论文不做的事情：

它没有说明哪种格式“更好”或“更快”。
它没有测试 AI 模型表现如何（例如聊天机器人的准确度）。
它没有发明新的格式。
它纯粹是一个参考工具，旨在确保每个人衡量的方式是一致的。

为什么这很重要？

在这篇论文出现之前，如果工程师将一个 AI 模型从一家公司的芯片转移到另一家公司的芯片，可能会得到不同的结果却不知道原因。这就像试图建造一座桥梁，其中一个团队使用英寸，而另一个团队使用厘米，但双方都没有承认这一点。

这篇论文提供了 共享的尺子 和 测试砝码。它允许工程师说：“好的，我的芯片通过了 3.0 锚点测试，并且处理溢出的方式与参考文件完全一致。” 如果没有通过，他们就知道有一个 Bug 需要修复。

简而言之，这篇论文是混乱的 AI 数值格式世界中的 标准化测量带，确保当不同的公司制造 AI 硬件时，他们都在使用相同的数学语言进行交流。

技术摘要：具有位精确一致性的 84 种格式数值目录

问题陈述

机器学习硬件中低精度数值格式（包括 FP8 变体、BF16、MXFP4 和微缩放块格式）的激增，已经超过了厂商中立且位精确（bit-exact）的参考资料的可用性。在不同加速器之间移植模型的工程师经常遇到“隐性分歧”：不同的硬件实现声称支持同一种格式（例如 FP8 E4M3），但在处理边缘情况（如输入为 1000.0 的溢出）时处理方式不同。一种实现可能饱和至最大有限值，而另一种则可能产生 NaN。如果没有一个共享的、位精确的“标尺”，这些分歧将难以诊断，导致跨厂商部署时产生数值上的差异。

方法论

本文引入了一种结构化的注册表方法来填补这一空白，该方法由两个主要人工制品组成：

t27 目录： 一个包含 84 种数值格式的全面枚举，分为 13 个家族（例如 IEEE754 二进制、OCP MX、GoldenFloat、Posit/Unum III）。每个条目遵循统一的模式，包括位布局、偏移量（bias）、无穷大/NaN 策略、饱和规则以及“声明状态”标签（已验证、经验拟合、开放猜想、风险或撤回）。该目录作为单一事实来源（SSOT）维护在 JSON 中，并通过模板工具跨编译为 Markdown、Python、Rust、C 和 TypeScript。
位精确一致性包： 一套包含六个自包含 JSON 文档的工具包，为当前生产中最关键的格式提供参考向量：
- GoldenFloat 16 (GF16)
- MXFP4 元素
- BF16
- FP8 E4M3
- FP8 E5M2
- E8M0 块缩放（block scale）

验证与锚定：

交叉验证： 一致性包针对 ml_dtypes 0.5.4 (Google/JAX) 进行交叉验证。任何分歧都会被明确记录而非隐藏。
锚点向量： 每个包都包含一个特定的向量，用于编码数值 3.0，该数值源自恒等式 $\phi^2 + 1/\phi^2 = 3$ （其中 $\phi$ 是黄金比例）。这作为一个完整性检查；如果一个格式无法精确表示 3.0，则会标记出根本性的实现错误。
完整性： 每个包都带有 SHA-256 指纹，并遵循 15 项目录不变性（例如 84 种格式的总数、无名称冲突、一致的位宽）。
标准映射： 通过 IEEE P3109 v3.2.0 交叉对照表，将六个包映射到其对应的标准追踪配置格式。

核心贡献

1. 84 种格式目录

该目录提供了跨 13 个集群的 84 种格式的统一模式。它通过对格式进行验证状态分类，区分了由已发布标准支持的格式（已验证）和由硬件观察得出的格式（经验拟合）。

2. 六个一致性包

本文交付了六个特定的包，具有以下特征：

BF16： 21 个向量，与 ml_dtypes 100% 匹配。
FP8 E5M2： 17 个向量，与 ml_dtypes 100% 匹配。
FP8 E4M3： 16 个向量。值得注意的是，16 个向量中有 15 个与 ml_dtypes 匹配，但其中一个向量（输入 1000.0）记录了一个允许规范的分歧：该包采用了“饱和至最大有限值”策略（由 tt-metal/AMD 使用），而 ml_dtypes 则使用“溢出至 NaN”（JAX/TPU）。两者均符合 OCP MX v1.0。
MXFP4 元素： 覆盖 S1E2M1 布局的 12 个向量。
E8M0 块缩放： 用于 OCP MX 块的仅缩放格式的 11 个向量。
GF16： 21 个基于 $\phi$ 锚定的格式向量，通过轮回自检进行验证，因为不存在 ml_dtypes 的等效物。

3. 识别解释差距

本文将“分歧”定义为设计特性而非错误，这些特性揭示了规范允许的选择。文中强调了两个具体的差距：

差距 A (FP8 E4M3 溢出)： 在溢出输入时，选择饱和至最大有限值还是产生 NaN 之间的抉择。
差距 B (块结构)： OCP MX MXFP4（32 元素块配合 E8M0 缩放）与 NVIDIA NVFP4（16 元素块配合 FP8 E4M3 缩放）之间的结构差异。虽然元素的位模式可能相同，但不同的块结构和缩放分辨率会导致解码后的张量值不同。

结果与发现

验证： BF16、FP8 E5M2 和 E8M0 包实现了与 ml_dtypes 参考值的完美对齐。
分歧记录： FP8 E4M3 包成功隔离了溢出策略的分歧，证明了在 OCP MX v1.0 下，“饱和”和“NaN”行为都是有效的，但会产生不同的结果。
标准对齐： 与 IEEE P3109 v3.2.0 的交叉对照表明，虽然某些格式（Binary8p3se, Binary4p1sf）与标准密切相关，但其他格式（GF16, BF16, E8M0）超出了 P3109 当前 4/8 位关注范围，或代表了正交的概念（仅缩放）。
可复现性： 所有人工制品均在 github.com/gHashTag/t27 下以开源许可形式公开，并提供 SHA-256 指纹以进行完整性验证。

意义与主张

本文明确将其贡献界定为注册表填充，而非性能基准测试或格式提案。其意义在于：

提供共享标尺： 提供一个厂商中立、位精确的参考，使工程师能够诊断机器学习加速器固件中的隐性分歧。
分歧透明化： 建立一种“诚实规范”，即绝对误差永远不会被抑制。分歧被视为必须由编译器和测试工具作者明确声明的、符合规范的解释差距。
为未来工作奠定基础： 该目录和包为未来的“第二阶段（Track 2）”工作提供了基准，该工作旨在将覆盖范围扩展到所有 84 种格式，并增加与 P3109 对齐的操作层一致性（算术运算）。

作者强调，这项工作并不声称某种格式具有优越性，也不对模型准确性或吞吐量做出任何主张。相反，它提供了必要的基础设施，以确保当不同厂商声称支持某种格式时，其位级行为是已知、可比较且可复现的。