用逐算子对照验证定点 Transformer

用整数运算跑 transformer，误差能有多小？MsrfTM 团队给出的结果是：一个 GPT-2 风格模型的前向计算与损失计算，相比 fp64 NumPy 参考实现，loss 相差 0.51%。他们想证明的，是小型运行时也能把计算做对。

这篇值得看的地方，是他们如何逐层定位误差，以及如何区分定点量化带来的偏差与实现错误。但这项验证覆盖了多大范围，还需要把实验结果和产品能力分开看。

0.51% 的误差，究竟验证了什么

MsrfTM 是一门小型、严格的编程语言，编译器能够自举，也就是用这门语言编译自身。作者称，它不依赖 LLVM、Rust runtime 或 C runtime，整个工具链约 1.4 MB，并内置 AI 库。

他们给 AI 运行时设置了一道门槛：纯 MsrfTM 实现的 GPT-2 风格 transformer，使用 Q16 定点数和整数运算，其 loss 与 fp64 NumPy 参考实现的差异必须远低于 1%。

实测结果是：

• 定点实现的 loss 为 5.6489。
• fp64 参考实现的 loss 为 5.6201。
• 两者相对差异为 0.51%。

这证明了一次真实前向计算与损失计算的接近程度，不能直接推导出训练效果或生成质量相同。

原文没有交代这次实验的模型规模、输入长度、样本数量，也没有给出多组输入下的误差分布。「GPT-2 风格」同样不能直接理解为完整 GPT-2 模型已经通过验证。

定点数能否算对，关键在中间结果

Q16 定点数用带缩放比例的整数表示数值。问题不只在小数精度：累加可能溢出，softmax 归一化可能产生偏移，GELU 的近似计算也会引入误差。

作者列出的处理办法很具体：

• 为每个算子设置数值范围预算，在缩放前约束中间结果。
• attention 分数在 softmax 内始终保持 Q16 表示，并预先缩放指数查找表。
• layer norm 计算统计量时使用更宽的中间类型，防止方差计算发生整数回绕。

这里最有参考价值的是误差定位工具。他们对参考实现中的单个元素施加 ±1 LSB 扰动，再通过二分定位检查偏差从哪个阶段出现。LSB 是最低有效位，对应定点表示能区分的最小步长。

作者报告，剩余偏差集中在已知量化噪声上：embedding 为 ±1 LSB，layer norm 为 0.3%–0.4%，attention 为 0.3%，GELU 为 0.15%。这些数字描述不同环节，不能直接相加得到最终 loss 差异。

他们据此判断没有结构性错误。这个判断来自作者的测试；原文没有展示足够的测试细节，让读者独立核实其覆盖范围。

1.4 MB 包含什么，又不代表什么

作者报告，整个自举测试套件为 175/175 通过，数值对齐验证可以通过一条命令重复运行，网站上的每个基准数字都有已提交到仓库的产物可追溯。不过，原文没有贴出具体命令。

AI 库的覆盖面也不窄：包括带反向传播的 MLP、conv1d/conv2d、maxpool、attention、LSTM/GRU、layer norm、softmax 和 GELU；还包括自带 protobuf 解析器的 ONNX 导入、面向 Vulkan 的 SPIR-V compute shader 输出，以及 AVX2 SIMD 内核。

应用演示包括两组结果：MNIST 使用 784→64→10 网络，测试准确率达到 74.5%，不依赖 Python 或框架；导出的 TinyStories-33M 模型能够自回归生成 20 个 token，并带有防重复处理。此外还有面向小模型的 int8 量化，以及在线提供服务的 classify/story API。

作者选择做语言，是希望同一份源码能以零依赖运行在 Windows 的 PE32+、Linux 的 ELF64 和浏览器的 WASM 上，Code Studio 也能在浏览器里运行真实 MsrfTM。

这里的约 1.4 MB 指整个工具链，原文没有说它包含模型权重。跨平台输出能力，也不能自动证明所有 AI 路径在三个平台上都具有相同表现。

我的判断

我更认可他们的验证方式：先建立高精度参考，再定位误差来源，最后把验证做成可重复执行的流程。对于自己实现算子、量化推理或移植运行时的团队，这比单独展示生成文本更有说服力。

但「数值接近」和「值得迁移」是两件事。原文没有给出与现有推理库的速度、内存、包体积或维护成本对照，因此还不能判断自建语言优于复用现有库。175/175 通过也只说明现有测试通过，不能替代对输入范围和极端值的说明。

MNIST 的 74.5% 和 TinyStories-33M 的 20 token 演示，可以证明链路能够运行，距离评估实际任务质量仍有缺口。对一般团队而言，这更像一份值得研究的工程实验，而不是已经充分论证的技术选型答案。

能拿来做什么

• 如果你在实现 Node 原生扩展或 WASM 数值模块，可以先建立 NumPy 高精度参考，同时比较算子输出和最终指标，避免只凭生成结果判断正确性。
• 如果你在做定点或 int8 推理，应逐个记录算子的输入范围、累加范围与缩放方式，优先检查 softmax、layer norm 和非线性函数。
• 如果你想评估浏览器里的 MsrfTM，可以从 Code Studio 验证实际模型的加载、运行和输出，再决定是否深入；不要把约 1.4 MB 工具链当成完整应用的下载体积。