【FHE 同态加密】我们如何实现同态加密推理十四为什么RESULTPASS不是判据纯 C11 · 零依赖关键词同态加密 FHE 验证 可复现性 RESULTPASS max|err| SHA256 密文验收 大模型推理导读在同态加密推理这条链上驱动打出的 RESULTPASS 只表示流程走完不表示数值是对的。我们真的被它骗过一次一个 8 字节文件缺失引擎静默换了计算路径照样打 PASS而实际 max|err| 已超出验收容差。本篇讲正确的两层判据以及如何做到不信任打包者。项目仓库Gitee 主仓https://gitee.com/pei-xiaoguang/kestrel-llmGitHub 镜像https://github.com/m13253246268-ship-it/kestrel-llm相关文档术语与数据口径 性能与基准 构建与复现 快速上手 架构总览0. 一句话结论在我们这套密文链里驱动打出的RESULTPASS只表示流程走完了它不表示数值是对的。这不是理论担忧。我们真的被它骗过一次一个 8 字节的文件缺失驱动静默换了计算路径仍然打出RESULTPASS (0)——而实际的max|err|已经是4.2e-2 ~ 8.5e-2超出验收容差。所以在这条链上判据和数值是两把不同的尺子必须分别量。1. 事故复盘8 个字节如何制造一次假通过1.1 事件的经过我们重跑层 0lay0做闭环验证。驱动正常退出、正常输出RESULTPASS (0)按当时文档的口径这就是通过。但同一批密文用独立复核工具一量[U2 t3 h0] max|err|4.460e-02 FAIL [E2E:ref-deviate-ok] verify_layer: FAIL 0/88 项全挂而且产出的u0与归档版本逐字节不同。1.2 根因引擎用一个 8 字节的f64文件来决定非线性激活走哪条拟合路径文件内容走的路径适用场景1.0直接拟合gate0.0或文件缺失÷21 折叠把动态范围压进逼近窗口M3b 深层而tools/drivers/t23_m3p.c里这两个分支直接读文件、不设缺失即报错。原文含作者当时写的理由/* silu 模式: silu{lay}.bin1 → 直接拟合(|gate|8, 锚定0, M1c 路径; ÷21 拟合有 ~0.0127 * DC 偏移 → 浅层小 gate 相对误差 12-35%); 0/缺省 → ÷21 折叠(M3b 深层) */g_silu_direct0;snprintf(sp,sizeofsp,.tmp_tok/tail/silu%d.bin,lay);fpfopen(sp,rb);if(fp){doublesm0;if(fread(sm,8,1,fp)1sm1.0)g_silu_direct1;fclose(fp);}if(g_silu_direct)printf( [silu] lay%d direct\n,lay);这段注释顺带解释了为什么必须有两条路径÷21 折叠的拟合带一个~0.0127的直流偏移在浅层小 gate 上会造成12–35% 的相对误差。所以浅层必须走直接拟合。于是文件没生成这件事被静默解释成请用折叠路径——而折叠路径恰恰是浅层的错误选择。1.3 为什么第二道防线也没拦住严格说驱动的输出里确实有异常信号——段级误差项是FAIL。但我们的判据设计里有两条规则把这两个信号都过滤掉了段级A/B/C/D的FAIL不作为结论。这是有道理的分段误差是参考口径产物中间层误差大不等于最终结果错。端到端模式会降级偏差在T23_E2EMODE模式下C/D/U2这类项只报告误差不计入fails。两条规则各自都合理叠加起来就形成了一个盲区一个错误路径产出的、8 项全挂的结果可以一路绿灯走到RESULTPASS。修好路径补上那个 8 字节文件之后同一层的日志头变成[silu] lay0 direct段级误差立刻回到正常量级[A:xnorm t3] max|err|5.642e-04 PASS [B:q0 t3] max|err|1.167e-03 PASS [C:attn t0] max|err|2.858e-04 PASS2. 为什么会这样判据的设计意图与它的边界把话说公道RESULTPASS的原始设计意图是流程验收不是数值验收。它回答的是这一步跑完了吗、有没有崩、有没有缺文件它知道的那几种。在流水线调度里这很有用——接力者需要的是我这跳交付了没有。但对结论级的正确性它必须让位给独立复核。我们后来把这条写进了文档并且明确要求判据日志只能用来排障验收必须看verify_layer的max|err|。3. 正确的判据是两层层工具它回答什么通过标准第一层流程跳内不崩驱动t23lay/t23boot这一跳跑完了吗lay看RESULTPASSboot看BOOTPASS且out np2083出现 8 次第二层数值算对了吗verify_layer独立于驱动解密后对明文参考的误差是多少max|err|逐项 ≤ 容差退出码 失败层/项数第二层的实现刻意不信任任何人读 sk.bin 密文 → 解密 → 解码 → 与明文参考逐项比 → max|err| → PASS/FAIL它不读驱动的判据只读密文和私钥。默认容差-Tol 3e-2也可显式覆盖# 复核层 0 的产出.tmp_tok/verify_layer.exe-L0-Ctu0# 复核刷新后的密文前缀 u0r112.tmp_tok/verify_layer.exe-L0-Ctu0r112# 位级比对两个密文是不是逐字节相同.tmp_tok/verify_layer.exe-BitAu5-BitBu5b-L53.1 实测输出本机复核非引用对象链长结果max|err|u0np16VERIFY_PASS (8/8)1.2712e-03u0r112自举刷新后np112VERIFY_PASS (8/8)1.2706e-03u26/u26r112链尾—PASS 8/84.4707e-03~2.2993e-02u27链尾—⚠️6/8t1h13.8216e-02、t3h17.9687e-02超3e-2一个细节值得注意自举刷新boot几乎不改变数值——u0是1.2712e-03刷新成u0r112后是1.2706e-03。刷新的作用是重置模数链不是提高精度。4. 让第三方复核真正成立的四块砖如果复核逻辑还是打包者自己写的那只是把信任问题往后挪了一层。所以交付物层做了四件事逐文件 SHA256 自校验 manifest归档实测主包104/104、链尾45/45、工具包6/6。复核工具独立于驱动verify_layer.c与t23_m3p.c/t23_chain.c是不同程序只共享底层的 NTT/CKKS 与那把私钥。参考值可自助生成复核要对的明文参考不是只有我们才有。约 7 GB 的数据包可以用tools/preproc/从模型自助生成——我们核对过生成物与分发物逐字节相同权重 9/9、26 个逐层模式文件 26/26、embed4.bin、参考值、sk.bin全部一致。产物位级可复现这是最强的一块见下节。5. 最强的一块砖产物位级复现复核只能证明数值在容差内。真正让不信任变得没必要的是——你能算出和我一模一样的东西。我们用两份独立工作区一份含既有.tmp_tok一份全新克隆从自助生成的数据出发重跑了lay0与boot0比对对象结果u0_{t}_{h}.ct× 8identical 8diff 0u0r112_{t}_{h}.ct× 8identical 8diff 0lay0.out日志213 / 213 行差异 4 处全部是耗时行lay0.err日志1 / 1 行完全相同boot0.out日志19 / 19 行差异 1 处[boot profile]总耗时boot0.err日志65 / 65 行62 处差异全是cts: u0N done (X.Xs)进度耗时也就是说所有数值、判据、分阶段链长逐行相同唯一的差异是时间。前提条件必须一起说位级复现要求线程数一致。T23_NT4与T23_NT8的结果在位级上不同——根因是线程局部 RNG 用固定常量播种见本系列第 13 篇。所以位级一致这句话永远要带上线程数一起说。6. 安全边界务请读完本文所述参数为机制验证级n2048、112 素数内层链、2100 素数自举链 远低于 HE 参数标准的 128-bit 水平不得用于保护真实数据。 本文主张的是验证方法与可复现性。 本文不主张安全强度、性能优越性。特别说明本文讨论的可复现可验证都是正确性层面的与密码学安全无关。一个能被第三方完全复现的系统和一个安全的系统是两件事——在本项目里前者是我们的目标后者我们明确不主张。7. 这一篇的未解问题u27那两项超阈怎么定性——它们是这一段确实算坏了还是容差3e-2定得不合理我们没有定论。目前的处理是照实记账并公开而不是调容差把它变成通过。-Tol 3e-2是一个选择不是定理。它从哪来、对哪一层的哪一类值合适我们只有经验值没有推导。逐层容差应该是多少是本项目最缺的一块理论。验证还停留在产出对不对没管输入有没有被换掉。如果上一棒交来的密文被替换成另一个合法密文当前的复核发现不了。要堵这个口子需要额外的机制比如对输入的承诺我们还没做。缺失即默认这个设计模式我们没清理干净。这次是silu{L}.bin同类的读不到就用默认值的文件读取值得全树扫一遍——沉默的默认值比崩溃更危险。下一篇我们讲工程侧的另一条线为什么我们把 OpenMP 换成了自研线程池——以及它和位级可复现这件事的隐秘关联。