文章核心观点 - Anthropic 发文宣称大型语言模型的可验证推理取得新进展并开源 FlashProve 系统 该系统基于零知识密码学证明技术让模型提供商能在不公开模型权重的情况下证明某个回答确实由指定模型生成 [1] - 该技术旨在解决 AI 服务中用户无法确认返回回答究竟来自哪个模型的信任问题 例如第三方服务商可能为降低成本将高性能模型替换为更便宜的模型 推理服务器也可能遭攻击导致模型权重或输出 Token 被篡改 [4] - 技术核心思路是服务商先通过密码学方式为一组确定的模型权重生成承诺 相当于给模型版本建立加密指纹 之后每次请求可附上零知识证明 zkSNARK 证明回答确由此前承诺的模型根据对应输入生成 [4] - 用户无需获得模型权重也无需重新运行模型 即可通过模型承诺 输入 回答和证明文件独立验证模型身份 证明过程不泄露模型权重 但证明的是回答来源而非回答内容是否正确 [5] 技术测试与性能数据 - 该技术已在总参数量达 400B 的混合专家模型上进行测试 单张 NVIDIA H100 GPU 每秒可生成约 110 个 Token 对应的推理证明 每 1024 Token 请求的证明文件约为 19 MB [2] - Anthropic 选择 Meta 的 Llama 4 Maverick 进行测试 该模型拥有 4000 亿参数 每个 Token 实际激活约 170 亿参数 [6] - 在单张 NVIDIA H100 GPU 上 FlashProve 证明生成吞吐量达约 110 Token/s 每份证明文件约 18.78 MB 验证端不需 GPU 使用 24 线程 CPU 验证一份证明约需 17 秒 [8] - 当前测试采用 1024 Token 的请求窗口 每份证明实际检查其中一个输出 Token [8] - 效率提升与 FlashProve 针对 MoE 架构的优化有关 证明计算主要围绕实际激活的专家展开而非每次处理全部参数 同时系统采用批量事后证明 在推理完成后再统一生成证明以降低重复计算开销 [8] - 生成证明所需 GPU 时间约为普通 vLLM 推理的 70—95 倍 [8] - 目前系统主要支持 1024 Token 的上下文窗口 并针对整数模型和 Greedy Decoding 进行验证 尚不能直接覆盖所有模型和推理方式 [8] 开源与形式化验证 - 过去零知识机器学习研究大多集中在规模较小的模型上 FlashProve 进一步将可验证推理推进到大型语言模型场景 [3] - Anthropic 已开源 FlashProve 的证明生成器 C++ 和 Lean 验证器 以及相关技术文档和形式化证明 [3] - Anthropic 使用 Lean 形式化验证语言对协议的完整性 可靠性和零知识等核心安全性质进行机器可检查的证明 并将代码 协议说明和相关证明以 Apache 2.0 许可证开源 [9] - 形式化验证并不意味着所有实际运行的代码都获得同等保证 快速 C++ 验证器与形式化协议之间仍需进一步审计 [9] 应用场景与行业需求 - 不少用户通过第三方 API 中转站或模型聚合平台调用不同厂商的模型 这类服务降低调用门槛但带来信息不对称 用户能选择模型名称却未必能独立确认后台实际运行的模型 [10] - 在多层转发调用链路中 服务商理论上可能出于成本考虑将原本应交给高性能模型处理的请求转发给调用价格更低的模型 用户即使发现回答质量变化也难以判断是模型随机性 服务状态变化还是实际调用模型发生改变 [10] - 在缺少独立验证手段的情况下 用户很难仅凭返回结果确认究竟调用了什么模型 [11] - 若模型服务商提前公布特定版本的权重承诺 服务返回回答时可提供相应密码学证明 用户不必完全依赖服务商口头承诺 而可通过验证证明确认请求是否确由指定权重的模型完成 [11] - 随着合规监管 模型供应链安全以及高价值场景如医疗诊断 金融决策 法律分析对模型身份确认要求不断提高 不可篡改的模型身份证从纯学术设想步入工程实操阶段 [13] - 未来模型服务商交付给用户的或许不再只有回答和 Token 还会多出一份能证明这确实是指定模型生成的密码学凭证 [13] 当前局限与工程约束 - FlashProve 目前仍是一个研究原型 存在若干工程与理论约束 [12] - 证明成本依然较高 虽然比前代系统快几个数量级 但生成证明所需 GPU 时间仍比普通推理 vLLM 高出约 72 至 94 倍 意味着若每个请求都需实时生成证明 服务成本将明显增加 [12] - 目前支持的计算形式有限 当前实验针对整数运算版本的模型和 Greedy Decoding 贪婪解码 对于浮点计算 随机采样等其他推理方式还需进一步扩展 [12] - 上下文长度有限 目前实验展示的是最多 1024 Token 的上下文证明规模 对于长上下文 大规模 Agent 工作流和复杂多轮交互 如何高效生成和验证证明仍是需要解决的问题 [12] - FlashProve 证明的是回答确实来自指定模型 并不证明回答本身正确 若指定模型产生幻觉 FlashProve 仍可能成功验证该回答 其解决的是模型身份和推理完整性问题 而非模型能力和事实准确性问题 [13]

文章核心观点 - Anthropic 开源 FlashProve 系统，基于零知识密码学证明技术实现大型语言模型的可验证推理，让模型提供商能在不公开模型权重的情况下证明某个回答确实由指定模型生成 [1] - 该技术旨在解决 AI 服务中的信任问题，使用户无需依赖服务商口头承诺即可独立验证模型身份 [2][7] - FlashProve 将零知识机器学习从规模较小的模型推进到大型语言模型场景，并在 400B 参数混合专家模型上完成测试 [3][9] 行业信任痛点 - 用户调用 AI 服务时无法确认返回回答究竟来自哪个模型，第三方服务商可能为降低成本将高性能模型替换为更便宜的模型 [2][7] - 推理服务器可能遭到攻击，导致模型权重或输出 Token 被篡改 [7] - 安全评估研究人员若无法确认测试对象与实际部署模型一致，评估结果将失去可靠性 [7] - 第三方 API 中转站或模型聚合平台降低了调用门槛，但带来信息不对称，用户能选择模型名称却未必能独立确认后台实际运行的模型 [12] - 在多层转发调用链路中，服务商理论上可能将高性能模型请求转发给调用价格更低的模型，用户难以判断回答质量变化是模型随机性、服务状态变化还是实际调用模型发生改变 [12][13] 技术原理 - 模型服务商先通过密码学方式为一组确定的模型权重生成承诺（Commitment），相当于给模型版本建立加密指纹 [7] - 用户每次发起请求，服务商可附上一份零知识证明（zkSNARK），证明回答确实由此前承诺的模型根据对应输入生成 [7] - 用户无需获得模型权重或重新运行模型，即可通过模型承诺、输入、回答和证明文件独立验证模型身份 [7] - 证明过程不泄露模型权重，但可确认输出是否来自指定模型；证明的是回答来源而非回答内容是否正确 [7] 性能测试数据 - 测试对象为 Meta 的 Llama 4 Maverick，拥有 4000 亿参数（400B）的 MoE 模型，每个 Token 实际激活约 170 亿参数 [9] - 单张 NVIDIA H100 GPU 上证明生成吞吐量达到约 110 Token/s，每份证明文件约 18.78 MB [9] - 每 1024 Token 请求的证明文件约为 19 MB [2] - 验证端不需要 GPU，使用 24 线程 CPU 验证一份证明约需 17 秒 [9] - 当前测试采用 1024 Token 的请求窗口，每份证明实际检查其中一个输出 Token [9] 效率优化手段 - 证明计算主要围绕实际激活的专家展开，而非每次处理模型全部参数，与 FlashProve 针对 MoE 架构的优化有关 [9] - 系统采用批量事后证明，在推理完成后再统一生成证明，降低重复计算带来的开销 [9] 开源内容 - Anthropic 已开源 FlashProve 的证明生成器、C++ 和 Lean 验证器，以及相关技术文档和形式化证明 [4] - 代码、协议说明和相关证明以 Apache 2.0 许可证开源 [10] - 使用 Lean 形式化验证语言对协议的完整性、可靠性和零知识等核心安全性质进行了机器可检查的证明 [10] 当前局限与工程约束 - 生成证明所需的 GPU 时间约为普通 vLLM 推理的 70—95 倍，若每个请求都实时生成证明，服务成本将明显增加 [10][16] - 目前主要支持 1024 Token 的上下文窗口，针对整数模型和 Greedy Decoding 进行验证，尚不能直接覆盖所有模型和推理方式 [10] - 对浮点计算、随机采样等其他推理方式还需进一步扩展 [16] - 长上下文、大规模 Agent 工作流和复杂多轮交互场景下如何高效生成和验证证明仍是待解决问题 [16] - 形式化验证并不意味着所有实际运行代码都获得同等保证，快速 C++ 验证器与形式化协议之间仍需进一步审计 [10] - FlashProve 证明的是回答来自指定模型，并不证明回答本身正确，若指定模型产生幻觉仍可能成功验证该回答 [16] 行业应用前景 - FlashProve 的开源为 AI 产业链可信治理带来新可能 [17] - 随着合规监管、模型供应链安全以及医疗诊断、金融决策、法律分析等高价值场景对模型身份确认要求不断提高，不可篡改的模型身份证正从纯学术设想步入工程实操阶段 [17] - 未来模型服务商交付给用户的内容可能不再只有回答和 Token，还会多出一份证明回答由指定模型生成的密码学凭证 [18]