Anthropic 开源 FlashProve：模型回答可验证，但证明成本高昂

先给结论：Anthropic 在 2026 年 11 月 3 日公开 FlashProve，一套尝试证明“这条回答确实由某组已承诺权重生成”的零知识推理系统。它解决的是模型身份与推理来源的可验证性，不是回答质量、事实正确性或模型安全。代码、技术报告和 Lean 证明都已开放，然而全尺寸实验需要 H100、数百 GB 主机内存和大量磁盘，仓库还明确标注为“不再维护”的研究制品。现在更适合研究推理审计，不适合直接当作生产服务部署。

它要证明什么

普通 API 用户只能看到输入与输出，无法从答案本身确认服务商实际运行的是哪一版模型。FlashProve 的流程分三步：服务方先为一组权重生成 commitment；收到请求后，由 GPU 生成回答及其证明；验证者用公开参数在 CPU 上检查证明。若验证通过，结论是输出符合该 commitment 对应的推理计算。权重可以保持隐藏，但模型身份需要先通过可信渠道确认。项目明确提醒，不能把 commitment ID 只从正在被检查的服务端或随证明附带的文件中取得，否则验证者并没有独立确认承诺对象。

Anthropic 同日列出的交付物包括研究说明、技术报告、协议草案、可执行代码、两个验证器及 Lean 形式化证明。C++ 验证器面向速度，Lean 验证器把顶层数学陈述交给可检查的证明环境。这个组合提高了外部研究者审查实现的机会，但它不等于独立安全审计，也不自动证明生产端提交的权重、配置文件和服务行为与用户期望一致。部署方仍要管理 commitment 的来源、版本和轮换记录。

性能数字要连测试条件一起看

项目方的全尺寸实验使用 Llama 4 Maverick 的第三方 4-bit 转换、单张 H100 80GB、1,024 个提示 token 和批量请求。性能文档报告，在每批 24 个请求时，预填充阶段平均约 111 token/秒；每份证明平均约 18.78 MB。这里统计的是输入 token 的证明生成速率，不是完整生成回答的端到端吞吐；证明检查时间另计。C++ 验证器在该文档指定的环境下，单线程约需 21 秒。把证明计算与普通 vLLM 预填充相比，项目方测算 GPU 时间大约高 65 至 95 倍，数字受批大小、服务配置与基准选择影响。

内存门槛是更直接的部署限制：公开权重服务实验的容器主机内存峰值约 270GB，提交权重约 300GB；示例脚本建议至少准备 330GB 可用内存和 245GB 磁盘。H100 的 80GB 显存几乎被占满。证明本身也会产生网络与存储负担。小规模 CPU 验证、合成模型实验和真实 Llama 权重证明是不同路线，前两者通过不能推出真实模型服务已可用。

适用范围与尚未解决的问题

这项技术适用于“模型服务商是否按声明的权重推理”比延迟和成本更重要的场景，例如合规研究、模型托管审计或供应链验证。它不能证明训练数据来源、模型能力、回答无偏或符合安全政策，也不防止用户拿到可信 commitment 后仍遭遇模型版本管理失误。验证器接受的是协议规定范围内的计算结果，系统周边的输入处理、量化参数、请求路由和日志仍需另外审计。

尤其要注意项目成熟度：GitHub 仓库的描述和 README 都标注“research artifact, not maintained, not accepting contributions”，当前版本标记 0.16.0，采用 Apache-2.0。对于工程团队，合理步骤是先读已发布的 known limits 和性能方法，使用存储的示例证明跑通 CPU verifier，再单独评估目标硬件与可信 commitment 管理。不要将论文指标当作服务 SLA，也不要在没有明确威胁模型时假设零知识证明覆盖了整条推理供应链。

结论

FlashProve 展示了“让模型回答自带可验证来源”的一种密码学路径，价值在研究与审计方向；当前成本和维护状态决定了它更像可复核的实验基础，而不是可直接上线的推理平台。评估者应把证明正确性、commitment 信任、端到端性能和运维资源分开验收，只有在这四项都符合目标后，才讨论规模化部署。

参考资料

1. Anthropic 研究发布
2. FlashProve 技术报告
3. FlashProve 仓库与 README
4. 性能测试方法与资源数据
5. 已知限制
6. Lean 定理说明