日常与大语言模型交互时，人们通常只能通过回答质量判断服务是否可靠。但输出质量本身无法证明模型身份：服务商可能在路由过程中替换模型，攻击者也可能篡改令牌流，而用户仅凭最终文本很难发现。

可证明推理试图解决这一信任缺口。模型服务商先对所使用的模型作出承诺，再针对每次推理生成密码学证明。如果回答并非来自承诺的模型，验证应当失败；如果验证通过，用户便能确认生成来源。模型权重不向验证者公开，验证者也不需要重新运行整个模型。

这类机制尤其适合三类场景：

独立评测：评测者确认受测模型与发布方实际提供的是同一个模型。
第三方路由：用户确认令牌确实来自购买的服务，而不是被替换后的其他模型。
内部或监管审计：机构验证服务商是否履行了特定承诺。

FlashProve 使用的核心工具是零知识简洁论证，即 zkSNARK。其特点与需求高度契合：证明相对简洁，验证效率较高，同时不会泄露模型权重。不过，FlashProve 并不隐藏模型架构，隐藏的只是权重。

论文、技术报告和代码入口：

400B 模型上的性能突破

FlashProve 的实验对象是 Llama 4 Maverick，一个 4000 亿参数的混合专家模型，并采用 4 位量化权重。在单张 H100 GPU 上，系统生成证明的速度约为每秒 110 个令牌；每次处理 1024 个令牌的请求，生成约 19 MB 的证明。

这一结果意味着，生成证明所需的 GPU 时间约为通过开源推理库 vLLM 运行同一模型进行预填充耗时的 70 至 95 倍。换言之，证明成本已经显著下降，但距离普通推理仍有明显差距。FlashProve 的价值不只是展示理论可行性，而是将大型模型的证明生成推进到可以实际测试和优化的区间。

Anthropic 表示，此前开源的可证明推理系统要慢得多。此次系统结合了密码学与安全领域的既有工具，以及 Claude 在复杂系统优化方面的能力。Anthropic 还为所声称的安全保证提供了 Lean 形式化证明，使关键数学结论能够被审计。

复现实验与操作步骤

复现实验的目标不是替代生产推理，而是验证三件事：证明能否生成、验证能否通过，以及在指定硬件上能否达到接近实验报告的吞吐量。建议按以下顺序进行：

准备环境
根据代码仓库中的依赖说明准备 CUDA、Python、Lean 和相关密码学组件。实验硬件使用单张 H100 GPU；如果没有 H100，可以先运行小规模功能测试，但不要将结果与原文中的吞吐数据直接比较。
获取代码与文档
bash git clone https://github.com/anthropics/flashprove.git cd flashprove 然后按照仓库 README 安装依赖、编译原生组件，并下载或准备实验所需的模型权重与配置。
运行功能验证
先使用仓库提供的示例请求或测试数据生成证明，再调用验证器检查证明是否有效。重点记录以下输出：
请求是否成功完成；
证明是否被验证器接受；
验证失败时是否得到明确错误；
日志中使用的模型、量化和请求配置是否与实验设置一致。
复现批量性能测试
在单张 H100 GPU 上运行 1024 个令牌的请求，记录证明生成耗时、每秒令牌数和证明文件大小。测试结果应与原文中的参考值进行对照：生成证明的速度约为每秒 110 个令牌，每次处理 1024 个令牌的请求，生成约 19 MB 的证明。
比较推理与证明开销
使用 vLLM 对同一模型进行预填充测试，再与 FlashProve 的证明生成耗时比较。原文给出的参考关系是：证明生成所需的 GPU 时间约为通过开源推理库 vLLM 运行同一模型进行预填充耗时的 70 至 95 倍。该比例是复现实验的观察值，不应预先改写为固定硬件上的保证。

仓库提供的测试、构建和验证命令，应以对应版本的 README 和脚本名称为准。常见验证流程包括：

```bash

运行仓库测试

pytest

或执行 README 中提供的项目测试脚本

./scripts/test.sh

对生成的证明文件运行验证器

./build/verifier --proof <proof-file>

使用快速验证器检查

./build/fast-verifier --proof <proof-file> ```

如果仓库脚本名称、参数形式或二进制路径不同，应以仓库当前版本为准，不能仅凭示例命令推断结果。

实际使用案例

模型服务路由：服务商在返回令牌流的同时附带证明，客户端或第三方路由工具验证令牌是否来自用户购买并承诺的模型。
独立模型评测：评测者对发布方提供的模型服务发起请求，并使用验证器确认回答来源，而不是仅凭答案质量判断模型身份。
内部合规审计：机构将证明作为服务记录的一部分，验证服务商是否履行了“使用指定模型生成”的承诺。
Agent 关键步骤留痕：在 Agent 调用模型执行关键操作时，对重要输出保存并验证证明，用于记录“哪个模型产生了什么输出”。这并不自动证明回答事实正确，也不能替代业务审计。

开源的不只是代码

此次发布包含五类成果：介绍系统的研究文章、解释技术细节的技术报告、由 Claude 编写的协议规范、可执行代码，以及配套的 Lean 证明与交互式可视化工具。

可执行部分包括证明器、两个验证器，以及一个使用 C++ 编写的快速验证器和一个可证明正确的 Lean 验证器。代码、Lean 证明与文档均以 Apache 2.0 许可证发布。这种发布方式的意义在于，它不仅允许开发者复现实验，也让密码学研究者、形式化验证人员和 AI 工程师分别检查协议、证明和推理实现。

Anthropic 也明确把 FlashProve 定义为阶段性成果，而不是已经完成的完整研究议程。它解决的是“回答是否由承诺的模型生成”这一类可验证性问题，与确保回答事实正确、推理过程符合人类直觉并不是同一件事。

部署流程与硬件需求

FlashProve 的部署对象至少包括证明器、验证器和相应的证明数据。验证者不需要模型权重，也不需要重新运行整个模型；证明器则需要运行实验中的模型推理和证明生成流程。

基础部署可以分为三个环节：

证明端
加载指定模型及其配置，运行生成请求，将回答与对应证明一并保存或返回。实验使用 Llama 4 Maverick、4000 亿参数、4 位量化权重，并采用单张 H100 GPU。
验证端
使用普通验证器或快速验证器检查证明。快速验证器使用 C++ 编写；Lean 验证器用于检查可证明正确的验证逻辑。二者的用途不同，不能将“快速验证”与“形式化验证”混为一谈。
审计与测试端
使用仓库中的测试、构建和示例脚本复现结果，并结合 Lean 证明和文档检查协议实现。部署时应固定代码版本、依赖版本和模型配置，避免将不同版本的证明混用。

硬件方面，原文给出的可复现实验配置是单张 H100 GPU。其他 GPU、CPU 或云环境可以用于功能和验证测试，但证明生成速度、显存占用和总耗时会受到具体环境影响，因此不能直接套用每秒 110 个令牌这一参考结果。验证端通常不需要模型推理算力，但仍需要与所选验证器兼容的软件环境、内存和存储空间。

验证命令与结果记录

部署验收至少应覆盖以下检查：

```bash

构建项目

make build

运行测试

make test

生成示例证明

./build/prover --help

使用标准验证器

./build/verifier --proof <proof-file>

使用快速验证器

./build/fast-verifier --proof <proof-file>

检查 Lean 相关证明或验证目标

lake build ```

实际命令需要以代码仓库当前 README 为准。每轮验收建议保存：代码提交版本、模型名称、量化方式、GPU 型号、请求长度、证明大小、证明生成时间、验证时间，以及验证成功或失败的结果。性能比较时，应明确区分“生成证明耗时”和“验证证明耗时”。

避坑清单

不要把证明通过等同于回答正确：FlashProve 证明的是生成来源，不是事实准确性、逻辑质量或推理过程符合人类直觉。
不要混淆验证器类型：普通验证器、两个验证器、C++ 快速验证器和 Lean 验证器承担不同检查任务；形式化证明也不等于每一次业务请求都自动完成了审计。
不要混用模型或量化配置：原文实验使用 Llama 4 Maverick、4000 亿参数和 4 位量化权重，配置变化可能影响复现结果。
不要忽略证明开销：生成证明所需的 GPU 时间约为通过开源推理库 vLLM 运行同一模型进行预填充耗时的 70 至 95 倍，不能只按普通推理成本估算资源。
不要把单卡结果泛化为所有硬件：每秒 110 个令牌是单张 H100 GPU、1024 个令牌请求和约 19 MB 证明等条件下的参考结果，不是所有部署环境的保证。
不要把阶段性成果当成完整产品保证：Anthropic 将 FlashProve 定义为阶段性成果，仍需结合协议审计、外部复现和具体部署环境评估成熟度。
不要仅保存最终回答：实际审计场景应同时保存请求配置、模型承诺、证明文件和验证日志。

从概率生成到可验证生成

大语言模型本质上仍是概率生成系统。即使回答流畅、逻辑完整，也可能包含错误；即使两次输出质量接近，也无法据此确认背后模型的身份。FlashProve 所代表的路线，是给生成过程附加可机器验证的凭证，让可靠性不再只依赖主观评价或输出采样。

这一思路与 Agent 系统的演进尤其相关。当 Agent 自主调用工具、执行多步任务或代表机构作出决策时，仅检查最终结果往往更加困难。可验证推理可以为关键执行环节提供来源证明，使“谁调用了哪个模型、产生了什么输出”成为可审计对象。

它还可能影响芯片与算力产业。证明生成需要额外的计算资源，当前约 70 至 95 倍于模型预填充的 GPU 时间，意味着推理基础设施不能只围绕模型前向计算设计，还需要考虑证明系统、验证器及其调度方式。不过，素材并未给出 FlashProve 对具体芯片架构或市场规模的判断，因此现阶段更适合将其视为算力需求的新变量，而非已经确定的产业结论。

从部署决策看，FlashProve 更适合以下条件同时成立的场景：用户或机构确实需要确认模型来源；服务商能够承担额外的证明生成开销；使用方愿意保存并检查证明数据；如果不需要证明回答的事实正确，也不把形式化验证结果直接当作业务正确性结论。

写在最后

FlashProve 的核心突破，是把“模型是否真的生成了这段回答”从信任问题转化为可验证问题。它与 OpenAI、DeepSeek 等模型路线所关注的生成能力不同，也不同于 Sora 一类生成式产品的内容效果评价；它关注的是 AI 供应链最底层的一项基础设施——模型身份与推理来源能否被证明。

对于大语言模型、Agent 和算力体系而言，可靠性正在成为独立能力。Anthropic 此次开源的 FlashProve 表明，模型服务除了比拼参数、效果与速度，还可以提供针对生成过程的密码学承诺。证明成本是否继续下降、协议和形式化验证能否得到更多外部审计，仍需要通过实际复现和独立评估加以判断。现阶段更稳妥的结论是：FlashProve 展示了将概率生成与可验证生成结合起来的原型路径，但其具体部署收益、硬件适配和产业影响仍取决于后续实验与应用验证。