先从一条启动警告说起

Strata 曾经在每次启动时打印一句警告，大意是：显卡上的专家计算路径“不正确”，它算出的任何输出都不可信。后来，issue #23 提出了一个很直接的问题：打开专家缓存，回答会不会变差？上游报告

作者做了一个实验：同一段文字，缓存开一次、关一次，逐个位置比较模型的预测。结果有点反直觉：在 2%–5% 的位置上，两边挑出的“最可能的下一个词”不一样；可整体上，谁也不比谁更准。不一样，却都对。这一章就从这里讲起：一个连“标准答案”都说不死的系统，该怎么测？

一句话：测推理引擎要分层：小函数对精确答案，单个算子对独立的参照实现，整个模型喂同一段文字逐位置比。浮点数的最后几位会随计算顺序变化，所以“相等”要先定义成带容差的比较；一个好测试还必须证明，故意放进去的 bug 它真的抓得到。

26.1 为什么“看起来对”最危险

程序出错有两种样子。一种是崩溃：报错、退出、输出一串乱码。这种错误很好找，第一次运行就暴露了。另一种更麻烦：程序照常运行，输出一个正常的数，生成的句子也通顺，只是内容已经错了。图 26-1 把两种错误放在一起。

图 26-1　崩溃的错误一跑就暴露；看起来正常的错误能骗过随手检查。推理引擎最怕的是右边这种。

推理引擎特别容易出右边那种错。原因很简单：模型输出的是一串概率，算错一点，挑出的词照样是个“像样的词”。Strata 的源码注释里，作者把这类陷阱一条条写了下来代码事实：

按地址缓存。每一层送给专家的输入，用的是同一块内存，地址永远不变，内容每层不同。如果按地址缓存它，就会把第 0 层的数据重复用到后面 47 层，得到“一个有限的、看起来合理的、完全错误的 token”。[S06]
权重乘两次。专家池不负责乘路由权重，合并步骤才乘。如果两边都乘了，单看一层几乎发现不了，叠加 48 层后误差会不断放大。[S06]
头的配对规则。GDN 层里 48 个值头要和 16 个键头配对，正确规则是取模（h % 16）。注释特意写明：另一种“按块分组”的规则也能产生格式完好的输出。[S17]
选错激活格式。一个量化矩阵该配哪种激活格式，取决于它的数据类型，而不是它的名字。选错了，矩阵乘法的结果偏差 0.6%–1.4%，注释原话是“一个看似合理的向量，而不是一个坏掉的向量”。[S14]

所以，测推理引擎需要一个东西：参照答案，也叫测试预言（test oracle），就是一个能告诉你“正确结果应该是什么”的独立来源。它可以是手算的数、另一个可信的实现，或者一条必须成立的规律。没有参照答案，测试只能检查“程序没崩”。

26.2 测试分几层：从一行算式到整段会话

一次就测完整个推理引擎是不现实的。工程上的做法是分层：底层测试小而快，出错时能精确指出哪一行；上层测试慢，却最接近用户真正看到的东西。图 26-2 是按 Strata 整理的一架“测试阶梯”。

图 26-2　测试阶梯。每一层抓不同的错误，谁也替代不了谁。下层全过，不等于上层一定过。

挑几层看看 Strata 实际怎么做。

最底层是纯函数。把一个 32 位浮点数转成 16 位的 BF16 格式，输入只有 2³² 种，大约 43 亿种。Strata 的测试干脆全部试一遍：每一种输入都和 ggml（llama.cpp 背后的计算库）的转换规则比，几秒钟跑完。这个测试抓到过一个真 bug：旧的舍入写法遇到 NaN（“不是一个数”）时会进位，把 NaN 变成了 −0 或无穷大，上游传来的 NaN 就这样被悄悄掩盖了。代码事实（bf16_bits_test.cpp）

第二层是单个算子。每个 GPU 内核都有一个对照测试，把它和一份可信的参照实现比。构建脚本里的注释说得很直白：参照实现本身先和 ggml 核对过；“拿一个内核去和它自己的另一份拷贝比，什么也证明不了”。代码事实（CMakeLists.txt）

第三层是组合与契约。layout.hpp 在加载模型时就检查每个张量的形状是否符合内核的假设，发现不符就报出张量名、实际形状和要求的形状。注释里的原话是：要在加载时报错，而不是在第 4000 个 token 时变成矩阵乘法里一个错误的数。[S04] 同一段注释还记了一个真实教训：有一轮开发把索引器的键缓存按“4 个头”算了大小，实际只有 1 个共享的头，大了 4 倍。这个错误在代码里活过了一轮，因为它让预算变得更保守，没人觉得哪里不对。[S04]

上面两层要跑整个模型。第 26.4 节专门讲。

阶梯的每一层都不能省。Strata 有一个现成的反面例子：模型里有一个叫 PLE 的模块（第 11 章讲过的查表模块），它的每个零件都写好了，也都单独通过了对照测试，可是没有任何一处模型代码真正调用它。结果整模型的一道验收关（代号 C1）没有通过。代码事实[S13] 零件全绿，系统照样是错的。

软件测试的层次

一个大系统的测试，通常分成几层。单元测试只测一个函数或一个类，给定输入，检查输出，跑起来以毫秒计。集成测试把几个模块接在一起，检查它们之间的“接口约定”是否被双方遵守。系统测试（也叫端到端测试）从用户的入口进去，看最终结果。还有一种贯穿各层的回归测试：每修一个 bug，就留下一个能重现它的测试，防止它以后再回来。

常见的经验是“测试金字塔”：底层的单元测试多而快，顶层的端到端测试少而慢。原因是成本：一个端到端测试失败了，你还得花时间去找是哪一层出了问题；一个单元测试失败，通常直接指向那几行代码。

另一个常用工具是测试替身：用一个假的、行为可控的对象，代替真实但昂贵的部件。Strata 的服务层就带了一个 MockEngine，它按剧本吐出 token，让所有 API 路径都能在没有 GPU 的机器上测试。代码事实[S15] 它能证明“HTTP 协议这一层没写错”，但证明不了真实引擎算得对。每一层测试，都只对它覆盖的那一层负责。

延伸阅读：维基百科：软件测试 · 维基百科：单元测试 · 维基百科：回归测试 · Python 文档：unittest 单元测试框架

学过计算机的同学：这就是《软件工程》里的测试金字塔和 V 模型。推理引擎的特别之处在于中间多了一层“对照参照实现”：因为大部分算子的正确答案没法手算，只能找一个独立的、可信的实现来比。

26.3 浮点数的“相等”，要先定义

回到开头那个实验。显卡和 CPU 算的是同一个量化专家，数据一字节不差，结果却在最后几位小数上不一样。作者的解释是：两边做浮点运算的顺序不同，两者都是对模型同样好的近似。上游报告（cache-parity 报告）

顺序为什么会影响结果？因为计算机里的浮点数位数有限，每做一次加法都要四舍五入一次。举个极端的例子：在 32 位浮点数（FP32）里，1 亿附近能表示的相邻两个数相差 8。所以 1 亿加 1，结果还是 1 亿，那个 1 被“吃掉”了。同样四个数，换个顺序加，答案就不同，见图 26-3。

图 26-3　加法的顺序会改变浮点结果。数学上的加法满足结合律，计算机里的浮点加法不满足。下面的实验台里，你可以换场景、换精度、调容差，亲手试一试。

这个例子是故意挑的极端情况。真实的推理里，差异通常只在最后一两位，叫作差了一两个 ULP（unit in the last place，最后一位上的一个单位）。可是这已经足以让 a == b 这样的测试失败。

工程上的办法是改用带容差的比较：两个数差得足够小，就算相等。“足够小”有两种量法。相对容差按数的大小打折扣，比如允许差万分之一；绝对容差是一个固定的门槛，比如差 10⁻⁶ 以内都算相等。两者通常一起用。下面的专栏讲清楚为什么。

浮点比较的容差

先说直觉。比较 1 亿和 1 亿零 8，差 8 已经是 FP32 能分辨的最小差别，应该算相等；比较 0.000001 和 0.000009，差不到 0.00001，可一个是另一个的 9 倍，显然不该算相等。所以“差多少算相等”必须和数本身的大小挂钩，这就是相对容差。

可相对容差在 0 附近会失灵。一个结果理论上是 0，算出来是 2×10⁻⁸，另一个算出来正好是 0。相对差是 100%，可它们在实际意义上没有区别。这时需要一个绝对容差兜底。Python 标准库的 math.isclose 把两者合在一起：

|a − b| ≤ max(rtol × max(|a|, |b|), atol)

它的默认值是 rtol = 10⁻⁹、atol = 0。文档专门提醒：和 0 比较时，默认设置永远判“不相等”，必须自己给一个正的 atol。另外，NaN 和任何数都不“接近”，包括它自己。专栏下方的图 26-4 画出了这条规则：横轴是数的大小，纵轴是允许的误差。

容差设多大？没有通用答案。它取决于数据类型（FP32 大约有 7 位有效数字，FP16 只有 3 位多）、计算链有多长、以及下游对误差有多敏感。一个可靠的做法是：先测量两个都正确的实现之间的典型差异，再把容差定在它之上、明显错误的差异之下。

还有一点常被忽略：容差只能放过“顺序不同”这类合法差异，救不了算法本身丢信息的问题。图 26-3 里两条路径都错了，把容差放宽到能让它们“相等”，测试就什么也不测了。

延伸阅读：Python 文档：math.isclose · MDN：Number.EPSILON（机器精度） · 维基百科：IEEE 754 · Wikipedia: Unit in the last place

图 26-4　允许误差 = max(rtol × |b|, atol)。数大时看相对容差，数接近 0 时看绝对容差。图中 rtol = 10⁻⁵、atol = 10⁻⁸，只是示意。

那什么时候应该坚持逐位相同？答案是：两边做的是完全相同的运算、完全相同的顺序时。比如把量化数据从一种存储格式换成另一种，只是重新排列字节，解码出来的值就必须一位不差。Strata 的 canonical_xcheck.py 正是这样要求的。代码事实（canonical_xcheck.py）反过来，连编译器的优化都可能改变顺序。Strata 在 AMD 显卡上特意关掉了两个文件的“乘加合并”（FMA）：把乘法和加法合成一条指令只舍入一次，会改变“正好在中间”时的取舍结果。代码事实（CMakeLists.txt）

学过计算机的同学：《数值分析》讲过：浮点加法满足交换律，但不满足结合律，(a + b) + c 和 a + (b + c) 可能不同。GPU 上成千上万个线程做归约，求和的分组方式由线程布局决定，所以“同一个公式”在 CPU 和 GPU 上本来就不该期望逐位相同。

26.4 差一点点，就换了一个词

数值上差一点点，会不会造成看得见的后果？会，而且就在“挑词”这一步。模型最后给每个候选词一个分数，叫 logit，分数最高的词被选中。如果第一名和第二名的分数几乎一样，一点点数值误差就能让它们交换位置。

看一个例子。参考引擎给两个候选词的分数是 [1.00000, 0.99999]，选第一个；测试引擎算出 [0.99998, 1.00001]，选第二个。两边的最大差只有 0.00002，选出的词却换了。反过来，如果分数是 [10, 0]，误差再大十倍也不会换词。所以“最大误差很小”和“选出的词相同”是两件事，要分开检查。

要比较两个引擎，还有一个麻烦。让它们各自自由生成，只要有一个词不同，后面的“上文”就不同了，再往后的每一步都没法比。解决办法叫 teacher forcing（固定历史）：不让引擎自己续写，而是喂给两边同一份标准文本，在每个位置上比较它们对“下一个词”的预测。图 26-5 对比了两种做法。

图 26-5　自由生成时，第一处分歧之后就没法逐位比了；teacher forcing 让每个位置都有相同的上文，分歧被锁定在它发生的位置。

Strata 回答“缓存会不会让输出变差”时用的就是这个办法：引擎有一个开关，按标准文本逐个 token 运行，把每个位置的 logits 全部写出来。缓存关闭时，所有专家都由 CPU 计算；缓存打开时，5,130 个最常用的专家放在显卡上。测试条件是 Q2_0 量化、RTX 5070，三段固定文本的前 512 或 1,024 个 token。上游报告

文本	首选词相同的位置	困惑度：缓存关	困惑度：缓存开
代码助手（512 个 token）	97.7%	2.672	2.630
长文档（1,024 个 token）	96.2%	29.844	29.843
聊天（1,024 个 token）	95.0%	18.380	18.301

表里的困惑度衡量模型对这段真实文字有多“意外”，越低说明预测得越准。报告的结论有三条：缓存会在 2%–5% 的位置上改变“两个几乎同分的候选谁赢”，大多数翻转发生在前两名分数差不到 0.5 的地方；两边的困惑度在 1 个标准误差之内相同，没有谁更准；显卡和 CPU 用不同的浮点顺序计算同一个专家，是同样好的近似。上游报告（cache-parity 报告）

这张表演示了一个好的比较该怎么做：既看离散的决策（首选词是否相同），也看连续的质量（困惑度），还要说明翻转发生在什么地方。只报告“96% 的词相同”，读者会以为 4% 的地方出了错；只报告“困惑度相同”，又可能掩盖一个只在少数位置出错的 bug。

26.5 让测试先失败一次：参照答案与负例

测试通过了，能说明什么？如果这个测试面对一个真有 bug 的程序也会通过，那它的“通过”就没有任何意义。检验测试本身的办法很朴素：故意往代码里放一个 bug，看测试能不能抓住它。这叫变异测试，被改坏的版本叫“变异体”。

下面的实验用一个 48 层的玩具模型演示这件事。它准备了 4 个版本的实现和 5 个测试。先猜一猜：“权重乘两次”这个 bug，哪几个测试抓得到？

图 26-6　变异测试的结果表。冒烟测试一个 bug 也没抓到；只有带容差的差分测试做到了“bug 全抓到，正确实现不误报”。

表里最值得琢磨的是两格。一是“弱单元测试”漏掉了“权重乘两次”：它恰好用了权重 1.0，而 1.0 的平方还是 1.0。一个测试选的输入太“规整”，就会对某类 bug 天然失明。二是“每层用旧输入”骗过了两个单元测试：bug 不在被测的那个函数里，而在把函数串起来的循环里。这正是第 26.2 节说的“零件全绿，系统照样是错的”。

表里抓 bug 最得力的是差分测试：拿同一批输入，分别喂给被测实现和一个独立的参照实现，比较输出。下面的专栏专门讲它。

差分测试与变形测试

很多计算没有能手算的标准答案：一个 2560 维的矩阵乘法，谁也没法在纸上验算。差分测试的思路是：找一个独立实现的版本当参照，两边吃同样的输入，比较输出。参照可以慢、可以笨，只要可信就行。Strata 的对照测试就是这样：GPU 内核对一条已经验证过的标量参照路径，而这条参照路径本身先和 ggml 核对过。

参照的关键是独立。Strata 的 layer.cpp 里记着一个教训：两个打包工具都按字段名 mins 去找某种量化数据的偏移量平面，可这个平面真正的名字是 offsets。两个工具“一致同意”，于是一起漏掉了 54 个张量的偏移量，共 136 MiB。注释的结论是：两个工具意见一致，只有在它们不共享那个错误假设时才算证据。代码事实[S14]

当连参照都不好找时，还可以用变形测试：不知道正确答案是多少，但知道“输入这样变，输出应该怎样变”。比如 Strata 的 KV 缓存按页存放，测试用同一份数据，分别按每页 1、4、512 个格子存放，并把页表打乱，要求注意力的输出完全相同。[S18] 再比如投机解码的验证窗口，设计上要求每个位置选出的词和逐个 token 生成时逐位相同。[S08] 这些“应该不变”的规律，就是不需要标准答案的参照。

延伸阅读：Wikipedia: Differential testing · Wikipedia: Metamorphic testing · Wikipedia: Test oracle · Wikipedia: Mutation testing

图 26-7　差分测试：两份独立的实现吃同样的输入，结果按事先定好的规则比较。规则可以是逐位相同，也可以是带容差。

差分测试也抓到过 Strata 的真 bug。Q2_0 量化格式里，2 位编码 0–3 解码时要先减 1，可表示的值是 {−d, 0, d, 2d}，而不是 {0, d, 2d, 3d}。漏掉这个减 1，大多数值看起来都对，其实每个都偏了一格。所以转换工具逐字照抄 ggml 的解码表达式，再逐位对照。代码事实（canonical_xcheck.py）同一个文件还记录了 Q8_0 格式的一次真实失误：编码曾被当成有符号数存放，自己和自己的解码器完全一致；直到用真实模型打包，才发现那两个张量解码后整体偏了 128 个编码，而其他 12 种类型都正常。

学过计算机的同学：编译器课上有一种经典做法，叫“对拍”：同一份程序交给两个编译器，比较运行结果。ACM 竞赛里写暴力解法去对拍优化解法，也是同一个思路。

26.6 动手：给微型引擎写测试

本书随附一个纯 Python 的微型推理引擎 labs/tiny_inference.py：4 层、8 维、每层 4 个专家挑 2 个，权重是固定的随机数，不需要显卡。它不是 Strata 的兼容实现，输出也没有语言意义，但整条“编码 → 逐层计算 → 选词 → 保存与恢复”的链路都是真的。配套的 10 个测试在本书的环境里全部通过。

先读测试。打开 labs/test_tiny_inference.py，找到“分段处理等于一次处理”的那一个。它用的是精确相等。想一想：为什么这里精确相等是对的？（提示：两条路径做的是完全相同顺序的运算。）
注入一个 bug。按 labs/README.md 的第 3 个任务，把递归层里“先衰减、再更新”的顺序对调。哪些测试会失败？如果一个都没失败，就补一个会失败的测试。
改写比较规则。假设你把逐个 token 的预填充换成整段一起算的矩阵乘法，运算顺序变了。把那个精确相等的测试改成带容差的比较，并说明容差是怎么定的。

本章的两个交互实验都在浏览器里真算，数字属于教学推演。实验台里的容差公式和 Python 的 math.isclose 一致；变异测试用的是一个玩具模型，不是 Strata 的内核。

记住这三点

推理引擎最危险的错误是“看起来正常”的错误。测试要有独立的参照答案，不能只检查程序没崩。
浮点结果会随计算顺序变化。同样的运算、同样的顺序，才要求逐位相同；否则用相对加绝对的容差比较，再单独检查选出的词。
测试本身也要被检验：故意注入 bug，看它会不会失败。参照实现必须独立，不能和被测代码共享同一个错误假设。

常见误解：“CPU 和显卡算出来的数不一样，说明其中一个有 bug。”

不一定。两边的浮点运算顺序不同，最后几位本来就会不同，Strata 的实测也显示两者同样准确。可也不能反过来一律放行：那条“显卡路径不正确”的启动警告，最早源自一个真实的故障，当时的输出从第 0 个 token 就开始分叉。后来故障修好了，由专家对照测试覆盖，从 0.1.8 版起警告才换成一句准确的说明。上游报告区分两者要看规律：合法差异只在接近平手的位置翻转，困惑度不变；真 bug 往往从一开始就分叉，或者让质量指标系统性变差。

深入一层：五层证据、指标的陷阱与“逐位相同”的边界

五层证据阶梯

第一层是纯函数：地址偏移、容量、top-k、期望长度。第二层是单个算子：同样的输入，比较输出和误差。第三层是组合：归一化、门控、专家加权和状态更新的先后顺序。第四层是固定历史下的整模型分布。第五层是真实任务和长会话行为。下层通过，推不出上层通过。“专家池不乘路由权重”、GDN 的 β 和状态轴的说明，都说明组合错误可以藏在各自通过测试的模块之间。[S06][S17]

teacher forcing 下记录哪些指标

可以记录最大绝对误差、相对误差、均方误差、KL 散度、首选词是否改变，以及路由选中的专家编号和索引器选中的位置是否改变。每个指标都有陷阱：相对误差在参考值接近 0 时会失真；KL 散度要说明概率怎样归一化、零概率怎样处理；首选词相同的比例要和“前两名分差”的分布一起看。Strata 的 QSA 索引器干脆规定选中的位置必须完全相同，不给容差，因为选中一个不同的格子，注意力的输入就变了。为此它把索引器的键存成 FP32 而不是 FP16：FP16 会让每个分数产生约 2⁻¹¹ 的相对扰动，恰好落在选择边界上。代价不大：32K 上下文时，这些 FP32 键一共约 50 MiB。[S18]

可以直接拿来用的变形关系

页表和数据一起做同样的置换，逻辑上的注意力结果应当不变；同一段输入切成不同的块，分块之间的状态交接应当等价；保存后恢复再继续，应当和从未离开一样；关掉草稿，应当和对应的目标路径语义一致。[S08][S18] 这些关系能生成大量强测试，但要写明容差和数值路径：跨 CPU / GPU、换矩阵乘法实现、换量化路径时，不保证逐位相同，既不能把所有差异直接放行，也不能无视已知的舍入边界。

“逐位相同”的承诺有边界

Strata 的验证窗口在头文件里承诺：每个位置的选词和逐个生成时逐位相同。[S08] 可上游文档同时记录：使用 IQ 系列量化时，CPU 计算一个 token 和计算多个 token 用的是两套舍入略有不同的内核，所以温度为 0 的同一个提示，可能因为草稿、缓存状态或会话恢复的不同，得出另一个同样好的答案（issue #152）。设置 STRATA_IQ_MT_MIN=1 后，所有情况都走多 token 内核，答案就不再依赖草稿。若要在服务里做到字节级可重复，还要加上 --prompt-cache 0 --adapt-swaps 0 --pcie-frac 0。作者实测（IQ3_XXS、3.6K token 的提示、重复 4 次）：三个开关都加，4 次只出现 1 种答案；不加 --pcie-frac 0，出现 2 种（第一次不同）；全用默认值，也是 2 种。上游报告[S03] 头文件写的是设计目标，文档写的是实测边界，两样都要读。

主动注入的负例清单

给测试故意注入这些错误：把头映射从取模改成整数除法；用 RMS 归一化代替 L2 归一化；每层的激活缓存只按指针判断；路由权重重复乘；位置计数被冻结；恢复会话时漏掉 PLE 的历史。测试应当稳定失败，并指出最早被违反的契约。如果注入后测试仍然通过，它多半只检查了“进程没崩溃”。参照实现不能和被测代码共享同一个错误假设，layer.cpp 里两个工具都找错字段名的案例适合在课堂上讨论。[S14]

公开仓库能跑哪些测试

Strata 的 CMakeLists.txt 注释写明：完整的测试套件和微基准放在 tests/ 和 bench/micro/，公开源码没有包含它们，所以构建测试的开关默认是关的。代码事实（CMakeLists.txt）同样，gdn.hpp 注释里提到的参照实现 ref/gdn.py，在公开仓库的 ref/ 目录里也找不到，那里只有 load.py。本章引用的对照测试和实测，来自公开的源码注释、测试文件和报告；本书没有在 GPU 上重跑它们。

本书随附测试证明的是什么

labs/tiny_inference.py 的测试检查分段处理、保存与恢复、参考重放和受控草稿接受。它们证明的是本书的教学代码，不是上游 Strata 的 GPU 实现。Strata 的分派、量化、异步执行和真实权重，需要在对应的环境里独立验证。