先划清本文的分工，免得和站内其他几篇串线。怎么在 Linux 机器上编译验证器、跑通示例证明、读懂退出码，是本批 FlashProve 验证 SOP 的活，那里有逐条命令与预期输出；本批 Kimi K3.1 Pro 开源热点 聊的是另一条开源线上的模型权重本身；API 价格横评 关心的是每百万 token 的报价；本地部署显存 SOP 解决的是算力在自己手里时怎么排布。本文只回答一件事：当你把算力交到别人手里，有没有办法让对方证明「跑的就是你付钱买的那个模型」。做出肯定回答的项目，就是 anthropics/FlashProve。
一个模型能不能在不交出权重的前提下自证清白？听上去像悖论：权重保密，别人怎么知道你真的在跑它？FlashProve 用密码学协议给出了回答。项目主页在 FlashProve 仓库，下载或引用时认准这一个地址：https://github.com/anthropics/FlashProve。按 2026 年 11 月 5 日的 GitHub API 实抓数据，仓库 843 星，创建于 2026 年 10 月 30 日，主仓库语言是 Lean，许可证为 Apache-2.0，LICENSE 是一份标准 Apache 文本。README 首行给出版本 0.16.0，随后是一句必须原样引用的定位：A research artifact: not maintained, not accepting contributions。研究产物，不维护，不接受贡献——这是官方自己盖的章，本文照单全收，不把它美化成可用产品。官方博客发布于 2026 年 11 月 2 日，开源后的发酵与媒体报道集中在 11 月 4 日前后。
它要解决的问题：API 背后是不是你付钱买的那个模型
这个问题的现实版本每天都在发生。第三方 API 中转与聚合路由是常见的省钱手段：前端按旗舰模型的报价收费，后台把请求转给便宜的小模型，用户拿到的答案风格相近、肉眼难辨，这就是常说的套壳。独立评测机构可能遇到调包：基准测试跑的是 A 模型，线上服务悄悄换成了 B。推理服务器可能被篡改，监管审计需要证据链。这些场景过去只有弱手段：对比输出风格、做盲测、看响应延迟，没有一样算得上证据。
FlashProve 要把「猜测」变成「证明」。它的官方描述只有一句：让 AI 服务商证明是哪个模型回答了请求，同时不泄露这个模型的权重。前半句指向行业的信任缺口，后半句是密码学上的硬约束，两句话放在一起，就是这份仓库存在的全部理由。
顺手把一条容易混淆的路线排开。业界此前讨论过的替代方案多数绕着硬件走：可信执行环境让芯片保证「这段计算没被改」，但用户仍然要信任芯片厂商与部署方，得到的保证是间接的。FlashProve 选择的是密码学路线：不依赖硬件背书，直接让计算本身产出一份任何人都能独立核对的证明。两条路线的目标一致，可信的来源不同，这也是它值得单独成篇的原因。
三步协议：承诺、出证、验证
协议分三步，以下均按 README 原文口径转述。
第一步是承诺（Commit）。服务商离线对一套权重生成一个承诺 ID（commitment ID）并公开，这一步把服务商绑定到唯一一组权重上；权重本身保密，所有依赖权重的公开值都被掩码，只有一份声明过的公开清单例外。「看得到证明、看不到权重」的性质带着零知识式的色彩。官方口径称，单卡 H100 上完成这一步约需 39 分钟。
第二步是出证（Prove）。每次回复，服务商的 GPU 生成一份证明，声明这条回复确实是被承诺的那套权重的输出。每 1024 token 请求的证明约 19MB，README 另一处给出的精确值是 18.78MB，两个数字都来自官方口径。
第三步是验证（Verify）。任何人用普通 CPU 跑 cp_verify，几秒内出结果，全程不需要权重。三步里藏着这套设计最反直觉的一点：重活全在服务商一侧，轻活留给验证者。承诺阶段权重不离开服务商的机器，出证阶段烧的是服务商的 GPU，到了验证阶段，用户手里只有一个几十 MB 的证明文件和一个公开的承诺 ID，却足以对几千亿参数的模型出处下判决。信任的重心第一次从「服务商的口碑」挪到了「协议的数学」上。
被演示的模型是 Llama 4 Maverick 全尺寸，一个 400B 参数的 MoE 模型，使用公开的 4-bit 转换权重，上下文窗口 1024 token，单卡 NVIDIA H100。换句话说，证明的对象不是玩具，是当前一线规模的模型，只是窗口被压得很窄。还有两处细节值得留意：权重选的是公开的 4-bit 转换版，说明承诺的是一套公开可核对的转换产物，而不是藏着掖着的私有权重；单卡演示则意味着这套流程在硬件上没有堆卡的门槛，卡住它的不是硬件，而是出证的开销，这一点下一节展开。
数字读法：快在哪，贵在哪
把官方口径的数字摆开。出证速度约 110 tokens/秒 prefill，批 24 请求；验证在 CPU 上约 17 秒，24 线程。这组不对称正是设计意图：出证端烧 GPU，验证端轻到一台普通机器就行，任何人都可以验。
但代价必须直说。证明开销约为标准 vLLM 推理 70 至 95 倍 GPU 时间，这是它当前最大的短板，也是理解它为什么还停留在研究阶段的关键：同一个答案，出证要烧掉几十倍的算力，没有服务商能在商业上承受每条回复都附带证明。数字要读全，只看「CPU 17 秒」不看「70 至 95 倍」，会得出完全错误的结论。
安全性这一侧，协议的可靠性在 Lean 4 中做了形式化证明，主仓库语言是 Lean 的原因就在这里。作弊者想用假输出冒充被承诺的模型，被抓住的概率约为 q/2^124 + 2^-101，其中 q 是 hash 查询次数。用形式化方法把「作弊会被抓」写成定理，而不是写成一篇安全分析，是这个项目区别于一般开源工具的地方。
同类对照也值得摆出来。此前该方向的 VerInf 工作，在 DGX Spark 上为 1000 token 出证明需约 14.3 小时、证明体积 93.6GB，这是第三方对比口径。FlashProve 把验证压到秒级、证明压到几十 MB，量级上的差距正是它受到关注的原因。
它证明了什么，证明不了什么
第一层边界最重要：只证「来源」，不证「正确性」。cp_verify 回答的问题是这条回复是否出自被承诺的那套权重，它管不了答案对不对。模型幻觉了、知识过期了、提示词被服务商动了手脚，证明照样通过。YES 是对出处的判决，不是对质量的背书。
第二层边界是现实进度。目前没有主流服务商在生产环境附带此类证明，FlashProve 是研究原型，不存在「现在就能拿去验证任何厂商 API」这回事。验证要有意义，前提是有人发布了承诺、有人在持续出证明，这两个条件目前都不成立。
第三层是技术边界。上下文窗口只有 1024 token，长对话装不进去；协议要求整数化算术与贪心 MoE 路由这类便于证明的计算形态，不是任何推理实现都能直接接入；模型架构不在隐藏之列，README 明确列有一份公开声明清单。再叠加 not maintained、不接受贡献的自标，读它要按读论文的方式读，而不是按读开源软件的方式用。
谁需要它，以及一个容易忽略的安全细节
应用场景按 README 与媒体口径有四类：第三方 API 中转与路由验证，直接打套壳问题；独立评测防调包，让基准分数对应真实模型；推理服务器防篡改；监管合规审计，把「我们用的是宣称的模型」变成可验证的陈述。四类场景的共同点是都卡在同一个位置：拿不出证据。中转平台可以说自己没换模型，评测机构可以说自己没被糊弄，服务商可以说服务器没被动过，但口头声明在争议面前一文不值，可验证证明的价值就在于把口头声明换成数学对象。
安全细节是：commitment ID 必须从可信第三方获取，不能从被验证的服务器本身拿，也不能从随证明一起发来的文件里拿，否则验证就退化成「被验者自己给自己开介绍信」。README 还专门写了一节 Built to be run by an agent，把构建、跑通、核对输出的工作设计给编码智能体完成；仓库自带的示例证明放在 examples/accepted-proof 目录，供验证器自检，跑通后期望最后一行是 YES、退出码为 0。README 甚至把报告格式都规定好了：要报出精确命令、退出码和完整最后一行，禁止用提权或改源码的方式绕过报错。这种把「怎么验证我」写成操作手册的做法，本身就是研究产物自觉的一部分。具体怎么跑，本批验证 SOP 会一步步带着做。
时效与热度：为什么现在写它
时间线很短：仓库 2026 年 10 月 30 日创建，官方博客 11 月 2 日上线，843 星是 11 月 5 日的实抓读数，媒体发酵集中在 11 月 4 日前后。一个上线不到一周的仓库就有这个热度，因为它把一个悬而未决的行业问题变成了可以跑的代码。
放在更大的开源图景里看，乌镇开源成绩单 记录的是开源模型权重的密集发布，而 FlashProve 代表开源的另一个方向：不是把模型开出来，而是给闭源服务配上可验证的审计工具。本地部署和可验证推理针对的是同一种不信任，也就是不想黑箱，但方向相反：前者把算力搬回自己家里，后者让远方的算力自证清白。两条路线将来可能在「本地跑不动大模型、又想确认云端没动手脚」的场景里会合。
常见问题
Q1：它现在能拿来验证各厂商的 API 吗？ A1：不能。FlashProve 是研究原型，官方自标 not maintained、不接受贡献，目前没有主流服务商在生产环境附带此类证明，也没有可信第三方发布现成的承诺 ID。验证要有意义，前提是服务商愿意为每条回复烧掉 70 至 95 倍的 GPU 算力出证明，这个前提目前不存在。
Q2：验证结果显示 YES，是不是说明答案是对的？ A2：不是。它只证「来源」，不证「正确性」：YES 只说明这条回复出自被承诺的那套权重，答案本身可能幻觉、可能过时、可能被提示词操控。把它当成出处证明，不要当成质量背书。
Q3：70 至 95 倍的开销意味着什么？ A3：按官方口径，出证约需标准 vLLM 推理 70 至 95 倍的 GPU 时间。这是它当前最大的短板，也是它停留在研究阶段的根因：商业服务商不可能为每条回复付出几十倍的推理成本，短期内看不到生产实装。
Q4：验证一条证明需要什么硬件？ A4：普通 CPU 就够。官方口径下验证约 17 秒（24 线程），验证器在内存小于 2GB 的机器上即可构建，不需要 GPU，也不需要权重文件。想亲手跑一遍示例证明，看本批的验证 SOP 即可。
Q5：commitment ID 该从哪里拿，为什么不能问被验的服务器？ A5：必须从你信任的第三方获取，README 明确不能从被验证的服务器本身拿，也不能从随证明附带的文件里拿。承诺 ID 是「这份证明对应哪套权重」的锚点，锚点若由被验方提供，对方可以随时换一套权重重发承诺，验证就失去了意义。这也是它走向实用前要解决的生态问题：谁来充当可信的承诺登记方。
延伸阅读
- FlashProve 验证 SOP：亲手编译验证器、跑通示例证明的逐条命令。
- API 价格横评：中转与官方渠道的价差背景，套壳问题背后的经济动机。
- 乌镇开源成绩单：开源模型权重这半年的发布节奏。
- 本地部署显存 SOP：不信任云端时的另一条路线，把算力搬回家。