本周为什么讨论它
当大模型通过平台、路由器和代理进入工作流，用户看到的通常只有一段文字和一个模型名。回答写得好，不等于确实来自所购买的模型；日志完整，也不等于日志中的每一步都真实发生。推理服务需要回答一个比“模型聪不聪明”更基础的问题：这一次计算，是否符合事先约定的模型和规则？
11月2日，Anthropic 发布 FlashProve，展示用零知识简洁证明验证大规模混合专家模型推理的研究原型，并公开代码和 Lean 形式化材料。这使“让服务方交付可检查的计算凭据”成为本周值得深研的技术主题。发布说明
本文不是性能复现或安全审计。事实依据截至北京时间11月9日凌晨已访问的公开材料；源码固定于提交 9e2bdd8ff5bf9c62f18263d7dac189b0400b260c，README 标注版本为 0.16.0。提交时间为10月30日，文章公开发布日为11月2日，两者不应混用。项目自述为不维护、不接受贡献的研究产物，不能据此推定有生产支持。项目快照
核心判断是：进展值得重视，但必须分开看身份锚点、数学声明、程序实现和实际服务。把四层合并成一句“AI 输出已经能证明是真的”，会误解这项工作的价值，也会放大它没有提供的保证。
背景：重跑模型不是人人都负担得起的验收方式
最直接的检查办法，是拿到模型权重、在同样输入上重新运行，再比较输出。问题是权重可能不公开，模型也可能太大；要求每位客户配置一套推理集群，会失去云服务的意义。
可验证推理改换了分工：昂贵的证明由服务端生成，客户端检查相对较小的证明。零知识性质希望保护未公开的权重，简洁性则使验证比重做原计算便宜。这里的“零知识”有明确对象，不是说输入、输出、模型架构和所有运行侧信道都消失。技术报告，第1—3节
我们的分析：可以把它理解成“计算过程的收据”，而不是“答案内容的真理证书”。即使准确执行了指定模型，模型仍可能算错、引用错误资料，或者忠实执行一个不合理的请求。证明执行与评价答案，是两条需要同时建设的路线。
技术原理：先承诺，再证明，再检查
FlashProve 把工作分成三个环节。
- 承诺。 服务方对一组权重建立承诺并发布承诺标识和相关公开配置。后续证明围绕这个锚点展开，而不是每次任意换一组权重。
- 证明。 证明方针对请求及指定输出位置，给出计算满足接受规则的证明。这个规则可以严格，也可以容许一定偏差。
- 验证。 客户端用约定的承诺、配置、输入和输出检查证明，无需持有原权重。
协议使用哈希、Merkle 树和 Fiat–Shamir 变换，把交互式预言机证明转为非交互证明；sumcheck 与 lookup 等工具把庞大的执行关系压缩成可检查的约束。它不是让另一个语言模型阅读答案并投票判断真假。实现原理指南
这一方案适配 MoE 的一个关键原因，是每个 token 只激活部分专家。技术报告还讨论了按层流式载入权重及批量处理等工程设计。因此“单 GPU 证明大模型”不能理解成“全部权重都装进一张显卡”，更不能理解成只有一张普通显卡就能低成本提供完整服务。技术报告，第5—6节
第一层边界：证明绑定到权重，不自动绑定到品牌
假设一个服务商承诺了一组权重，并且给出有效证明。验证通过首先说明的是：针对这组承诺所定义的模型，所检查的声明满足相应规则。
但“这组承诺就是官方某个模型版本”来自哪里？如果承诺标识和证明都由被检查的服务端临时给出，服务端可以先选择别的模型，再诚实证明自己运行了它。密码学没有替用户完成身份登记。
项目明确要求从可信的一方取得承诺标识，并同样保管公开配置。证明也只覆盖指定 token 位置，不自动证明回复完整，更不自带客户端身份或时间含义。已知限制
我们的分析：一个真正有用的验收系统，还需要模型发布者或独立审计方维护可验证的“版本—配置—承诺”对应关系，并处理更新与撤销。证明可以削弱对服务端诚实执行的依赖，但身份锚点不能凭空产生。
同理，审计方若只检查部分请求，就需要另行定义抽样方式和覆盖范围。被证明的请求合格，不足以推出所有流量都合格。
第二层边界：YES 与 WITHIN LIMITS 不是同一句话
这是读项目原文时最容易错过、也最值得关注的细节。
精确匹配策略要求所检查的 token 是承诺的整数模型在该位置的首选。clipped-gap 策略则根据候选 token 与首选 token 的 logit 差距计算成本，并限制截断后的平均成本及越界 token 数量。后一种接受的是“偏差落在约定范围内”，不是“回复逐 token 等于模型首选”。两种结果都可能以进程退出码0结束，但末行分别是 YES 或 WITHIN LIMITS。工作原理
为什么需要较宽松的规则？证明采用精确整数计算，而常规服务使用浮点计算，还可能采用采样。两条计算链即使都诚实，也未必逐 token 一致。项目把两者接近程度视为测量问题，而不是由密码学证明自动保证的问题。
宽松规则带来兼容性，也改变了保证的语义：阈值过宽，或者模型的分数过于接近，就可能允许很多不同输出。项目没有推荐一套通用阈值；不能评估这些阈值时，它建议仅接受精确匹配。已知限制
我们的分析：接入方不应把“验签成功”做成一个没有上下文的绿色对勾。界面至少要说明验证的是哪套配置、哪些位置、哪种接受策略。容错范围是一项产品与安全决策，不能由服务端悄悄代选。
第三层边界：110 tokens/s 到底在数什么
性能指南给出：在一张 H100 80GB、指定 CPU 配置和公开4位权重转换下，24个请求一批时，稳态 prefill 速率约为 111.23 ± 0.92 tokens/s。每个请求的1024个上下文位置都进入这个分母；测量过程不生成新文本，且对应的证明声明检查下一个 token。它不是“每秒生成并完整证明110个回答 token”。性能指南
批处理还会改变等待体验：该配置下，一批证明从批次开始到产出约需221—226秒，不能把摊销后的单请求时间当成实时响应延迟。启动、建立承诺以及前端验证等成本也要单独计算。证明平均约18.78 MB，这又增加了存储和网络负担。
项目与 vLLM 的对比是特定条件下按 GPU 折算的计算成本对比，基线采用不同精度和多 GPU 配置；不能直接拿这个比值推算所有线上负载的账单。仓库还说明，原始运行记录和部分测量材料未一并公开，读者最多重做同类测量，不能仅靠仓库逐项重放原实验。性能条件与复现说明
我们的分析：近期更自然的场景可能是事后审计、重要请求的凭据留存，或经过明确设计的抽样检查。是否适合每条聊天请求实时附带证明，必须连同排队、上下文长度、验证时间和网络开销评估。这里提出的是部署判断，不是已经被线上实验确认的收益。
第四层边界：Lean 证明不等于整套服务已经安全
形式化验证的价值在于：把保证写成明确命题，并让机器检查推导。项目对 Lean 验证器及协议给出特定范围的健全性、完备性和零知识结果，同时详列假设和范围。
但面向用户运行的 C++ 验证器、CUDA 证明器和提交权重的程序，并没有因此全部变成形式化验证过的软件。它们与形式化协议的联系主要依靠测试，而不是已经证明的端到端等价关系。精确匹配与宽松策略的命题也不能互换。What is proved
还有两个需要保留的区别：
- 协议中的零知识性质与运行服务的保密性不同。 随机掩码、公开文件、错误处理、侧信道和前端行为都会影响真实部署。数学命题有其请求次数、配置和协议模型范围，不能直接扩成“任何部署都不泄露权重”。
- 测试没有发现反例与完成独立安全审计不同。 项目明示尚无独立安全审计，部分实验还使用了不同于已发布源码的程序。它公开这些边界，是读者评估证据强弱的重要依据。范围说明
我们的分析：可信的工程流程不是把“有形式化证明”当作终点，而是逐步缩短数学声明、实现代码、构建产物和服务配置之间的距离。尤其当代码与证明主要由 AI 辅助完成时，独立检查声明本身是否对应预期，仍有不可替代的价值。
影响与争议：信任可以被拆解，却不会全部消失
对模型消费者，这条路线有望让“模型版本没有被替换”变成可验证要求。对评测机构，它可能帮助连接被评测模型与被部署模型。对服务商，则提供在不直接公开权重的前提下交付执行证据的方式。
但这些是能力方向，并非 FlashProve 已经完成的通用服务承诺。最主要的争议不是零知识证明是否有用，而是付出多大成本、在什么覆盖范围内、换来了多强的声明。
即使某个模型的输出通过检查，也不能据此证明它安全、正确、完成了全部工作，或服务商没有在别处运行另一套系统。尤其不要把“证明某段推理存在”误读为“证明没有发生其他计算”。
我们更看重这次工作的研究意义：它同时交付可检查的原型与相当细的限制说明，让讨论从笼统的“可信 AI”转向可以逐项追问的契约。能清楚说出没有证明什么，往往比一个更宽泛的宣传结论更有工程价值。
接下来最值得验证的五个问题
- 独立复现。 固定源码、编译器、配置与权重来源后，第三方能否复现主要速度、验证结果和资源消耗？
- 真实服务。 更长上下文、混合请求长度、持续排队与故障恢复加入后，端到端延迟和成本如何变化？
- 容错策略。 面向具体用途，阈值能否兼顾诚实实现差异与对恶意替换的识别？不能只看正常样本的接受率。
- 可信身份。 谁发布承诺标识，如何核对模型版本，更新后如何向客户解释保证的连续性？
- 实现与证明的一致性。 能否获得独立审计及更强的程序等价证据，特别是生产中实际使用的快速验证器和证明器？
截至本文核验，我们没有进行 GPU 性能实验，没有重建 Lean 库，也没有独立验证项目全部安全声明。这些是明确的未验证项，不是已证实的缺陷。
本周的结论因此可以很具体：FlashProve 值得作为可验证推理的研究进展认真读；使用它时，应先读保证对象和限制，再读吞吐数字。 一张证明的价值，取决于它确切承诺了什么，以及系统有没有把这个承诺完整地交到用户手里。
公开来源
本文仅供信息参考，详情请见免责声明。
← 继续阅读更多内容