FlashProve开源原型用零知识证明核验模型

你调用的是某个模型，收到的回答却未必来自它。FlashProve 想补上这层验证：服务商为回答附带密码学证明，让用户检查输出是否来自事先承诺的模型权重，同时不公开权重。

据原文介绍，Anthropic 的研究原型已经能在单张 H100 上，为 400B 模型达到约 110 tokens/second 的证明吞吐。但代价仍是普通推理约 70 到 95 倍的 GPU 时间。理解它的价值，要把「能证明模型身份」和「适合接入日常 API」分开看。

它证明的是模型来源，不是答案正确

今天检查 AI 服务是否偷偷换模型，常见办法是跑评测、观察回答风格，或者比较输出质量。这些方法只能提供线索。较小模型可能答对，较大模型也可能答错，单次回答很难成为可靠证据。

FlashProve 把问题改成：这些输出 token，是否确实由事先承诺的那组权重生成？

它采用零知识简洁非交互式知识论证，也就是 zkSNARK。服务商提交证明，用户验证证明，过程中无需看到模型权重。原文列出的应用包括检测推理服务器遭篡改、验证文本来源，以及帮助监管方检查硬件是否用于推理、服务是否只运行获批模型。这些是潜在用途，原文没有给出落地案例。

证明回答来自某组权重，不等于证明回答真实、可靠或符合业务要求。

还有一个信任起点：权重承诺必须与用户认可的模型身份建立联系。否则，你只能确认服务商前后用了同一组权重。原文没有展开这层身份绑定如何完成。

为什么 400B 模型能用一张 H100 生成证明

FlashProve 将工作分成离线和在线两个阶段。

离线阶段，服务商为一组确定的权重发布承诺，可以把它理解为绑定权重的短指纹。这个过程约需 39 分钟，可覆盖约 1,600 万次请求。在线阶段，再针对每次请求生成证明，证明对应 token 来自已承诺的模型。

测试对象是 Llama 4 Maverick，一个总参数量 400B 的混合专家模型（MoE），每个 token 实际激活约 17B 参数。FlashProve 的证明工作量跟随激活参数，而非全部 400B 参数，这是它能跑起来的重要前提。

另外两项工程选择也很关键：请求生成后再批量证明，计算组织方式类似 prefill；权重从主机内存流入 GPU，降低显存需求。

单卡不代表硬件门槛低。证明端需要 1 张 H100 80 GB、24 个 CPU 核，以及约 290 GB 主机内存。验证端则只需要 CPU，无需 GPU。

协议通过哈希函数，将交互式预言机证明编译成密码学证明。原文称其具备后量子安全性，并将它与 Starknet 等有效性证明 L2 使用的证明技术归为同一家族。这是密码学构造上的联系，不代表它需要上链运行。

110 tokens/second 为什么仍然昂贵

作者转述的测试使用公开的 4-bit Maverick 权重，结果如下：

测试项目	原文结果
batch 24	111.23 tokens/second，每批约 221 至 226 秒
batch 1	17.41 tokens/second
batch 64	123.31 tokens/second，但在 80 GB 显卡上被标为不可靠
单份证明	18.78 MB
每次承诺的客户端一次性下载	约 6.5 MB
CPU 验证	24 线程约 17 秒，单线程约 21 秒

这里的吞吐是生成证明的速度，不能当成聊天接口的实时输出速度。尤其在 batch 24 下，一批仍要等待数分钟。

与使用 8 张 H100、运行 FP8 Maverick 的 vLLM 相比，证明每批消耗的 GPU 时间约为其 72 倍；在 vLLM 测试的最高负载下，差距约为 94 倍。两边的权重精度、硬件数量和任务都不同，不能只拿单卡吞吐判断成本。

原文对照表也显示，各方案的取舍差别很大。VerInf 同样证明 400B Maverick，但在 1 台 DGX Spark 上，1,000 tokens 需 14.3 小时，约 0.02 tokens/second，证明达 93.6 GB。Attestable 证明的是稠密 Gemma 4 31B，吞吐为 53 至 77 tokens/second，验证只需 157 至 648 毫秒，却未开源。

这些结果支持 FlashProve 在大规模 MoE 证明上取得进展，但不是严格控制变量的横向排名。

我的判断

我认可它把「相信 API 服务商」推进到了「检查计算证据」。与依靠提示词试探模型身份相比，这条路线能提供更明确的验证目标。研究原型采用 Apache 2.0 开源，也方便外部检查。

但当前边界很窄：上下文上限为 1,024 tokens，只支持 greedy decoding，并且暂时限于 MoE 模型。长上下文编程助手、带随机采样的聊天体验，都不能直接套用原文成绩。

安全保证也要看具体实现。团队用 Lean 形式化了完备性、可靠性和零知识性，README 给出的作弊漏检概率约为 q/2^124 + 2^-101，但这篇报道没有解释 q 的定义。

系统提供两个验证器：日常使用的快速 C++ 验证器没有形式化保证；较慢的 Lean 验证器，则被证明只接受可靠性定理允许接受的证明。协议经过形式化，不代表每条实际执行路径都自动获得同等保证。

它更适合被看作可验证推理的研究进展，距离通用 API 的低成本标配仍有距离。

能拿来做什么

• 做 Node AI 网关时，可以先区分模型名称、服务商声明和可验证证据。原文没有提供现成的 API 接入方式，不能把一个模型字段当成来源证明。
• 评估模型来源审计方案时，把证明生成时间、18.78 MB 的传输量和 CPU 验证时间一起计入预算，并优先判断业务能否接受事后批量验证。
• 尝试复现时，先确认 1,024 tokens、greedy decoding 和 MoE 限制符合任务，再准备 H100 80 GB 与约 290 GB 主机内存；不要用 batch 64 的不可靠成绩估算容量。