Roy Rinberg、Alex Allain 等 · Anthropic · 阅读原文
调用远程模型时，用户通常只能相信服务商报出的模型名称，无法查看实际用了哪组权重。Anthropic 的 FlashProve 尝试补上这一环：先为权重生成一份密码学承诺，相当于不可随意改换的指纹；服务端随后为指定输入和输出生成证明，验证者不必拿到权重，也不必配备 GPU，就能检查计算是否符合该承诺。它证明计算关系，并不证明答案内容正确。
研究原型把每次只激活部分子网络的混合专家模型 Llama 4 Maverick 的整数化计算分块处理，逐层把数据送入一张 H100 80GB，主机内存仍约需290GB。团队报告，24个请求、每个1024 token 窗口的一批证明耗时223秒，折合约110个预填充 token/秒（一次处理给定文本的速度）；每份证明实际检查一个指定 token，不能读成每秒验证110个新生成 token 或完整回答。证明约18.78MB，CPU验证约需17秒（24线程）或21秒（单线程）。
库还区分两种接受条件：严格符合整数模型的贪心输出，以及在配置容差内接近该输出。后一种是为了容纳常见浮点推理与整数模型的差异。Lean 中的形式化安全论证与快速 C++ 验证器也不能混称：后者尚未证明与形式化实现完全等价。当前发布的是不承诺维护的研究原型。
可信度 65 · 重要性 78 · 新颖度 78
技术与主题
编辑评读
这项能力改变了远程服务中一个过去难以检查的环节。过去，用户很难区分“模型本身答错”与“服务端换用了另一组权重”；承诺与证明让其中一个问题有机会被单独检验。它也保留了不公开商业权重的空间，因此可验证性与开放权重并非必须捆在一起。实际使用仍要先有可信渠道，把某个承诺值对应到声称的模型；如果标识和值都只由待检查的一方随手提供，证明没有替用户完成身份确认。
更容易被忽略的是接受策略。为了兼容浮点输出，系统会计算输出相对整数模型最高分 token 的差距，再按阈值决定是否接受。文档明确说明，阈值太宽或输出分数过于平坦时，检查的区分能力会很弱。因此“验证程序返回成功”至少要连同承诺、检查范围和容差一起解释。严格证明与工程近似可以共存，前提是读者知道自己拿到的是哪一种保证。
性能数字同样要顺着用途读。这里对已经得到的文本批量重算并生成证明，预填充吞吐不等于在线生成速度；每次仅检查一个位置，也不等于整个回答都已覆盖。下一步有价值的证据，是独立实现对同一承诺、同一输出范围和接受策略的交叉检查，以及完整服务链路的延迟与费用。目前不能据此宣称生产 API 已经提供这一能力。