用密码学证明API实际运行的模型

调用 AI API 时，你能指定模型名，却很难独立确认后台实际运行的模型。FlashProve 想补上这个缺口：服务商先承诺使用某个模型，再为每次回答提供密码学证明，让调用方检查返回内容是否确实由这个模型生成。

原文给出的结论是：这条路已有研究原型，但距离日常 API 服务还很远。它最有价值的地方，是把「相信服务商的声明」推进到「检查一份证明」；最现实的障碍，则是证明成本和推理限制。

模型名只是声明，FlashProve 想让回答带上证据

FlashProve 是 Anthropic 的研究原型，采用 Apache 2.0 开源许可证。它的流程分成三步：

1. Commit：服务商发布模型权重的短「指纹」，也就是密码学承诺。权重仍然保密，但后续证明要与这份承诺对应。
2. Prove：每次生成回答时，服务商的 GPU 创建证明，说明承诺过的模型产生了这组确切的 token。
3. Verify：调用方在普通 CPU 上检查证明，不需要 GPU，也不需要拿到模型权重。

这里的关键是，证明绑定了模型和具体输出。只公布一份模型指纹，还不足以说明某次请求真的使用了它；每次回答附带的证明，才把两者连接起来。

原文列出了三个用途：发现路由器或服务商偷偷替换模型、发现回答被篡改，以及向审计人员和监管机构提供可检查的证据。

它验证的是回答的计算来源，不是回答内容是否正确。

即使证明通过，模型仍然可能生成错误事实或有缺陷的代码。密码学证明解决的是「谁算出了这些 token」，没有替模型做事实核查。

能在 CPU 上验，为什么还不能直接用于生产？

原文以 Llama 4 Maverick、400B 参数规模给出了一组数字：

• 在一张 H100 上约为 110 tokens/sec。
• 每份证明约 19 MB，检查耗时约 17 秒。
• 生成证明所需的 GPU 时间，是普通推理服务的 70–95 倍。

这些数字需要一起看。调用方不必准备 GPU，确实降低了验证端的硬件要求；但约 19 MB 的证明和约 17 秒的检查时间，对交互式请求仍然是一笔明显开销。更重的负担在服务端，证明生成会消耗远多于普通推理的 GPU 时间。

原文没有交代 110 tokens/sec 的完整测量口径，也没有清楚说明它与证明生成耗时的关系，不能据此推导出整个流程也有同样的吞吐量。

适用范围同样有限：上下文只有 1,024 tokens，证明针对的是整数版本模型，并且使用贪心解码（greedy decoding）。贪心解码每一步选择当前得分最高的 token，不能直接覆盖常见的随机采样配置。

它还只隐藏权重，不隐藏模型架构。原文明确说，这个原型不再维护，也没有部署计划。

我的判断

我认可它选择的问题。对于依赖第三方 AI API 的团队，模型名、响应字段和服务商声明，通常都是由服务商自己提供的。能够独立检查的计算证明，确实比再增加一个声明字段更有说服力。

但证明能保证什么，必须划清边界。首先，调用方仍要知道那份权重承诺对应哪个可信的模型版本。原文没有讲清这层身份绑定如何建立。其次，证明覆盖的是特定整数版本及贪心解码流程，不能直接当成所有线上推理配置的保证。

与调用日志、合同约定或抽样检查相比，FlashProve 提供了更直接的计算证据，代价也明显更高。原文没有给出这些方案之间的对照数据，暂时不足以证明它在一般团队中更划算。

它更适合作为可验证推理的研究进展来理解，而不是现成的 API 接入方案。

能拿来做什么

• 评估 AI 网关或模型路由服务时，把「声明使用哪个模型」和「能否独立验证」分开记录，避免把响应中的模型名当成充分证据。
• 为 Node 服务设计 AI 调用审计记录时，记录请求配置、返回内容和服务商声明的模型版本；同时明确，这些日志本身不能证明后台运行了哪个模型。
• 如果业务需要可验证推理，先核对上下文长度、解码方式和模型表示是否落在证明范围内，再评估 19 MB 证明、17 秒验证和 70–95 倍 GPU 时间的成本。