FlashProve 尝试核验模型身份

用户向中转平台购买指定模型的服务，收到一段回答，究竟能确认什么？回答流畅、解题正确，可以说明这次使用体验不错，却不足以确认后台运行了哪套权重。从用户、中转平台到上游服务商，模型身份的可信程度，取决于这条链路能提供什么证据。

爱范儿介绍的 FlashProve，正在尝试改变核验的依据。这一由 Anthropic 发布的开源研究原型，通过模型权重承诺与零知识证明，让用户无需取得权重，也不必重新运行大模型，就能检查给定输入、输出与指定权重之间的计算关系。核验对象由回答的表现，转向了回答是否符合约定的模型计算。

这种需求有现实依据。原文援引的 Model Equality Testing 研究，测试了 2024 年四款 Llama 模型的 31 个商业 API 端点，发现其中 11 个端点的输出分布与参考分布存在统计差异。但统计差异不能直接证明模型遭到替换。参数设置、上下文是否完整等因素，也可能影响表现。仅凭几道题判断模型身份，很难把这些情况区分开。

FlashProve 的办法，是先为权重生成一个密码学“承诺”。它能够锁定特定权重，而不公开权重本身。服务商随后针对给定输入和待检查输出生成证明，用户拿到承诺、输入、回答及证明文件后，可以自行验证计算关系。如果换了另一套模型，或输出被修改，证明便无法与原来的承诺对应。零知识技术则让核验不必以披露权重和中间计算值为代价。

不过，一份有效证明还不能独自回答“这是不是我买的模型”。假设用户购买的是模型 A，中转平台却选择模型 B，为它生成承诺，再提供与之匹配的证明：这套材料即使验证通过，也只说明输出符合模型 B 的计算。用户仍然需要知道，购买模型 A 时应该核对哪个承诺。

因此，可信的承诺来源是整个服务成立的条件。模型厂商、可信机构或公开透明的登记系统，需要发布可供核对的模型承诺；用户验证时，则应固定检查预期承诺，而非接受平台随回答附上的任意承诺。上游负责建立可信承诺并生成证明，中转平台负责传递相关材料。本文的判断是，只有把这两步连接起来，证明计算成立，才有机会进一步成为购买身份得到确认的依据。

距离实际普及，成本仍是一道门槛。爱范儿列出的实验数据来自公开 4-bit 权重的 Llama 4 Maverick：单张 H100 生成证明的吞吐量约为每秒 110 个 token，但这不是聊天输出速度。在 Anthropic 的对比条件下，证明消耗的 GPU 时间约为普通 vLLM 推理的 70～95 倍。验证端不需要 GPU，也不意味着整套服务已经足够便宜。

核验范围同样需要明确。即使权重身份得到确认，系统提示词、安全策略、上下文截断、检索内容和解码参数仍可能影响体验。除非这些条件也被证明覆盖，否则不能用一份绑定权重的证明，推导出服务配置完全一致，更不能据此排除所有体验下降的原因。

FlashProve 展示了一条可验证服务的路径，但它仍是研究原型。要让用户真正据此确认购买的模型，除了降低成本、支持更长上下文和真实推理配置，还需要可信的承诺发布机制。届时，用户能够核对的将不只是回答像不像某个模型，而是这次回答是否符合那个预先确认的模型计算；结论也应止于证明实际覆盖的范围。