第三方 API 调用的真是你选的模型吗？Anthropic FlashProve 用 19MB 密码学证明给推理结果验明正身

作者注：通过第三方 API 调用大模型时，仅凭回答质量无法确认实际运行的是哪个模型。本文解读 Anthropic 开源的 FlashProve：它如何用 zkSNARK 把推理结果绑定到指定权重，成本有多高，能证明什么、不能证明什么，以及距离日常 API 调用还有多远。

2026 年 11 月 2 日，Anthropic Frontier Red Team 联合 EPFL、MIT 等机构的研究者发布了 FlashProve：一个面向大语言模型的开源可证明推理原型。在 400B 参数的 Llama 4 Maverick 上，它用单张 H100 生成证明，单份证明约 19 MB，普通 CPU 十几秒即可验证。

这不是概念演示或 PPT 产品。Anthropic 同步发布了技术报告、协议规范文档、可执行的证明端与两套验证端代码，以及 Lean 形式化证明，全部以 Apache 2.0 协议开源。不过它也明确表示，这只是阶段性研究进展，距离完整的研究目标还有不少路要走。

核心价值：读完本文，你将弄清楚第三方 API 调用中“模型身份”为什么难以确认，FlashProve 用什么机制解决它，它的真实成本与边界在哪里，以及作为 API 使用者现在能做些什么。

第三方 API 调用为什么存在模型身份信任问题

当你通过任意一个 API 发送请求时，返回的只有一段文本和一个模型名称字段。Anthropic 在研究博客中直言，今天的用户无法确认回答真的来自开发者声称的那个模型。它可能被路由服务出于成本考虑悄悄替换，也可能被攻击者在 Token 流上做了篡改。

更关键的是，输出质量高不等于模型身份真实。一个便宜的模型也可能在某些问题上答得很好，一个被降级的版本也未必能被肉眼识别出来。即使把完整聊天记录公开，理论上也可以用更便宜的模型伪造出来，这类证据并不具备绝对的证明力。

要从根本上验证也很难。前沿模型的权重大多不公开，就算拿到了权重，复算一遍推理所需的算力也远超普通用户甚至评测机构的承受范围。Anthropic 梳理了这类信任问题的几种典型场景：

• 第三方路由服务：客户希望确认收到的 Token 来自自己付费选择的模型。
• 独立评测：评测机构需要确认发布前后测试的就是线上实际提供服务的模型。
• 防篡改检测：推理服务器被攻破后，攻击者可能夹杂恶意回答，甚至把恶意软件投递到用户电脑上。
• 监管与合规：监管方可能要求只能部署经过安全审批的模型，或确认硬件确实在跑推理而非偷偷训练。

可证明推理（Provable Inference）的目标，就是让一个算力有限、也不了解权重的用户，能够验证某条回答确实来自所请求的模型。

FlashProve 核心信息速览

值得一提的是，Anthropic 表示系统中的大量优化工作由 Claude 完成。为了应对 AI 在大型复杂系统中做出“难以评估的决策”，团队用 Lean 写下了可审计的顶层安全声明，作为对冲手段。

FlashProve 如何证明推理来自指定模型

FlashProve 只有两个角色：模型提供方作为证明者（Prover），用户作为验证者（Verifier）。整个流程分为离线和在线两个阶段，再加上验证端的检查。

FlashProve 的三步机制

1. 离线模型承诺（Model Commitment）：证明者发布一个对模型权重的承诺，可以理解为一枚很短的“指纹”。它锁定了一组确切的权重，但权重本身保持隐藏。在测试中这一步每个模型只需执行一次，耗时约 39 分钟，生成的承诺大约可支撑 1600 万次请求，之后需要重新承诺。
2. 在线生成证明：收到验证者的请求（Prompt 与对应输出 Token）后，证明者生成一份证明文件，证明的命题是“被承诺的模型在运行时会产生这些输出 Token”。
3. 验证端检查：任何持有承诺、Prompt 和回答的人都能检查证明，无需权重，也只需有限算力，就能确信被承诺的权重在这个 Prompt 上恰好产生了这些 Token。

FlashProve 的四项安全性质

前两项性质（完整性与可靠性）其实一个知道权重、算力充足的验证者自己复算就能做到。让系统真正有意义的是后两项：

• 完整性（Completeness）：诚实证明者生成的证明一定能被接受。
• 可靠性（Soundness）：伪造虚假命题的有效证明，难度相当于攻破被广泛信任的密码学假设，验证者因此不必信任证明者。
• 零知识（Zero Knowledge）：验证者无法获知权重、中间计算值，也无法知道每一层激活了哪些专家，但模型架构本身不隐藏。
• 简洁性（Succinctness）：被证明的是约 232 GB 量化模型的一次运行，验证者拿到的却只是约 19 MB 文件，在 24 核 CPU 上几秒级即可检查。

MoE 架构如何降低 FlashProve 证明开销

FlashProve 的提速很大程度上利用了 MoE（混合专家模型）的结构。在 Llama 4 Maverick 中，每个 Token 只用到 400B 参数里的约 17B，证明者的工作量也只和这约 17B 成正比，同时证明依然隐藏了具体选择了哪些专家。

另外两项工程设计同样关键。一是事后批量证明：证明者像 Prefill 一样一次并行读取已完成的文本，每批只打开一次权重承诺。二是单卡适配：权重按层切段、逐段证明，放在普通内存中流式加载，一张 80 GB GPU 搭配约 290 GB 主机内存即可运行。

FlashProve 证明成本实测数据

成本是判断可证明推理能否落地的核心指标。Anthropic 的测试环境为：证明端是单张 H100 加 24 个 CPU 核心，验证端只用 CPU，每个请求是一个 1024 Token 的窗口。

对比基线是在 8 张 H100 上用 vLLM 运行同一模型的 FP8 版本。换句话说，证明一批请求所花的 GPU 时间，大约是正常推理处理同批请求的 70-95 倍，也就是约两个数量级的额外开销。

110 tokens/s 不等于实时证明完整回答

这是解读 FlashProve 时最容易被误读的地方。技术报告明确限定：每份证明实际检查的只是 Prompt 后面的一个 Token，110 tokens/s 是证明端处理请求窗口的吞吐量，而不是逐 Token 验证完整回答的速度。

因此，“FlashProve 已经可以实时证明完整回答”的说法并不准确。更严谨的表述是：在批处理、短上下文、事后证明的条件下，它把可证明推理的成本压到了此前难以想象的水平。

FlashProve 与既有可证明推理方案对比

可证明推理在学术界通常被称为 zkML。Anthropic 在博客中回顾了相关进展，数字对比相当直观。

VerInf 对标分析：VerInf 是此前已知唯一证明过同一模型的方案，但其证明体积高达 93.6 GB，验证需要近一天，基本无法实际使用。相比之下，FlashProve 把证明体积压到约 19 MB，验证缩短到十几秒，让普通 CPU 上的第三方审计第一次具备可行性。

Attestable 对标分析：Attestable 在稠密模型上取得了亮眼的商业化数字，但截至博客撰写时尚未发布对应开源库。FlashProve 的优势在于代码、Lean 证明和文档完全开放，任何人都可以复现与改进，代价是目前强依赖 MoE 架构。

FlashProve 能证明什么，又不能证明什么

对第三方 API 用户来说，理解边界和理解能力同样重要。下表汇总了研究博客与技术报告中的关键限定：

FlashProve 事后证明的检测局限

FlashProve 采用的是事后证明（Post-hoc Proving）：用户先收到响应，独立证明服务器再重新计算并生成证明，最后由验证者检查。这种方式允许证明慢一些，换取不必在安全与效率之间妥协。代价是保障存在延迟，证明失败只能揭示问题，无法让用户在收到回答前就得到保护。

技术报告还提醒，如果日志系统本身被攻击者控制，攻击者可能一边向用户发送被篡改的内容，一边让日志只记录正确结果。所以 FlashProve 必须与可信日志、访问控制等安全措施配合使用。

FlashProve 形式化验证的未完成部分

“用 Lean 做了形式化证明”很容易被理解为“整个系统都被证明正确”，但事实并非如此。技术报告列出的边界包括：

• Lean 对零知识性质的证明目前只覆盖单请求证明，尚未覆盖批量证明。
• GPU 证明端代码由 AI 依据 Lean 表示生成，尚未证明与 Lean 表示等价。
• 日常使用的 C++ 快速验证端同样由 AI 生成，没有形式化保证，只是在测试中与 Lean 验证端的结论全部一致。
• 较长的协议规范文档由 AI 生成，作者并未详细审核，应与作者撰写的技术报告区分看待。

这些限制不代表研究无效，而是说明形式化验证目前锁定的是协议层的数学性质，可执行代码与协议之间仍需人工或智能体审计来弥合。

影响分析：FlashProve 距离第三方 API 日常调用还有多远

对开发者与 API 使用者的影响

• 短期内不会出现在日常调用链路中：约两个数量级的 GPU 开销、每请求约 19 MB 的证明文件、1024 Token 的上下文上限，都让它难以直接用于高频对话类 API。
• 适用面受限：系统假设 MoE 架构、整数化模型与贪心解码，大多数生产调用使用随机采样和浮点推理，不能直接套用。
• 认知层面的价值更大：它第一次让“验证模型身份”从不可能变成工程问题。开发者应当意识到，返回的模型名称字段、模型 ID 或普通请求日志，都不等同于密码学证明。

💡 选择建议：在可证明推理成熟之前，选择第三方服务时更值得关注的是计费透明度、调用日志可追溯性和自测一致性。通过 API易 apiyi.com 这类聚合平台调用时，可以同时请求多个模型并保留完整调用记录，便于自行做交叉对比与审计。

对行业与监管的影响

• 评测与合规工具箱多了一个选项：监管方可以要求提供方为一段时期的推理请求附上证明，确认硬件确实在服务指定模型，同时不获知专有权重。但 Anthropic 也承认，这无法证明硬件没有在旁路做训练。
• 软件方案与可信硬件互补：可信执行环境依赖厂商的防篡改硬件，zkSNARK 依赖计算难题的困难性，即使硬件和操作系统被攻破也无法伪造证明，两者会在不同场景各自发挥作用。
• Anthropic 的生产验证走的是另一条路：Anthropic 在 2026 年 10 月 19 日更新的 Frontier Safety Roadmap 中提到，其推理验证项目已在生产推理流量上建立原型，通过签名覆盖内部 Token 流量并在可信服务器上复算推理，还捕获过一次极其罕见、非恶意的完整性异常。该项目名称已改为 inference verification，与 FlashProve 是相关但独立的两个项目，不能混为一谈。

第三方 API 调用者现在能做什么：自建调用审计记录

既然密码学证明暂时还用不上，开发者能做的是先把“可追溯”做好。下面的示例在调用时固定 temperature=0，并把请求时间、请求 ID、返回的模型字段与回答哈希写入本地日志，方便后续做一致性复测。需要强调的是，这只是工程层面的审计记录，不是对模型身份的密码学证明。

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "用一句话解释零知识证明"}],
    temperature=0
)
print(resp.model, resp.id)
print(resp.choices[0].message.content)

import hashlib
import json
import time
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # 一个 Key 调用多家模型
)

def audited_call(prompt: str, model: str, log_path: str = "audit.jsonl") -> str:
    """调用模型并记录可追溯信息(非密码学证明)"""
    start = time.time()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=0,
        max_tokens=512,
    )
    content = resp.choices[0].message.content or ""
    record = {
        "ts": int(start),
        "latency_s": round(time.time() - start, 3),
        "requested_model": model,
        "returned_model": resp.model,   # 仅为服务端返回的声明字段
        "request_id": resp.id,
        "prompt_sha256": hashlib.sha256(prompt.encode()).hexdigest(),
        "output_sha256": hashlib.sha256(content.encode()).hexdigest(),
        "usage": resp.usage.model_dump() if resp.usage else None,
    }
    with open(log_path, "a", encoding="utf-8") as f:
        f.write(json.dumps(record, ensure_ascii=False) + "\n")
    return content

# 固定一组探针 Prompt,定期复测并对比输出哈希与延迟分布
probes = ["计算 37*43 并只输出结果", "列出三种排序算法的时间复杂度"]
for p in probes:
    for m in ["gpt-4o-mini", "claude-sonnet-4-5"]:
        print(m, audited_call(p, m)[:60])

🚀 快速开始：可以通过 API易 apiyi.com 获取免费测试额度，用上面的探针脚本对多个模型做定期复测。需要说明的是，这类方法只能提升可追溯性，无法替代 FlashProve 这类权重级证明。

在此基础上，还可以搭配几条实用做法：固定模型 ID 而非使用模糊别名；保留一组探针 Prompt 长期跟踪输出与延迟变化；对关键业务同时请求多个模型交叉校验；关注服务商是否公开权重承诺或可验证机制的进展。

常见问题 FAQ

FlashProve 核心要点 Key Takeaways

• 信任缺口真实存在：第三方 API 调用中，回答质量高不能证明模型身份真实。
• 核心机制：离线权重承诺加在线 zkSNARK 证明，用户用 CPU 即可验证。
• 成本大幅下降：单 H100 窗口吞吐约 110 tokens/s，证明约 19 MB，验证约 17 秒。
• 口径要分清：逐 Token 检查吞吐为 39.1 tokens/s，单请求仅 17.6 tokens/s。
• 边界明确：仅限 MoE、整数化贪心解码、1024 Token 上下文和事后检测。
• 上手方式：现阶段可借助 API易 apiyi.com 多模型统一接口做自主复测与审计。

总结

FlashProve 的核心意义可以归纳为三点：

1. 把模型身份验证变成工程问题：此前证明同一模型需要十几个小时和近百 GB 证明，如今压缩到批处理百 tokens/s 级别与 19 MB 证明。
2. 离生产可用仍有距离：两个数量级的开销、短上下文、架构与解码方式限制，加上形式化验证覆盖不完整，决定了它目前仍是研究原型。
3. 需要与其他安全机制配合：事后证明只能检测、不能拦截，必须搭配可信日志和访问控制。

对于今天的第三方 API 使用者，最务实的态度是：既不要把模型名称字段当作证明，也不必因此过度焦虑，先把调用记录、探针复测和多模型交叉校验做扎实，同时持续关注可证明推理的成熟进度。推荐通过 API易 apiyi.com 用一个 Key 对比多家模型，在自己的业务数据上建立可追溯的质量基线。

📚 参考资料

1. Anthropic 研究博客 – Progress on provable inference for large language models：FlashProve 原始发布文章
2. 链接： anthropic.com/research/provable-inference

3. 说明： 包含系统设计、实测数据、既有方案对比与局限说明

4. FlashProve 技术报告：研究博客附带的完整技术细节

5. 链接： anthropic.com/research/provable-inference（页面内 Read the technical report 入口）

6. 说明： 包含吞吐量口径、事后证明局限、形式化验证边界等关键限定

7. Anthropic Frontier Safety Roadmap：推理验证项目的进展说明

8. 链接： anthropic.com
9. 说明： 了解 inference verification 与 FlashProve 的区别

作者: APIYI 技术团队
技术交流: 欢迎在 API易 官网首页联系我们，更多接入资料可访问 docs.apiyi.com 文档中心

延伸阅读

• 模型“变笨了”不一定是被换了：调用 API 时效果异常的 6 类常见原因与 3 步排查顺序:Anthropic 发布 FlashProve 推理证明研究，但权重身份确认后，“降智”仍可能来自系统提示词、上下文截断、解码参数等环节。本文整理模型变笨了的常见原因和可执行的排查顺序。