---
title: 核查清单：评估可验证推理声明
dek: 服务商或协议称其模型输出可验证时，可以做这十项检查。每项检查都附有核查表，用来记录证据涵盖了什么、你还需要信任什么。
needs: 书面声明及其所依据的论文或规范，以及验证工具
disclosure: 本指南引用了 Hollow-LLM 论文，本站编辑是该论文的合著者之一。
---

服务商说自己的模型输出可以验证，这一说法有多大用处，取决于它背后的具体声明。原因在于，归在可验证推理名下的各种机制，核查的对象各不相同。零知识证明除了所确立的命题之外，不泄露任何信息。它可以表明，某个输出与服务商已承诺的权重一致。[^1]抽样审计只核查部分请求，其设计目标是以高概率发现大规模作弊。[^6]这份核查清单把笼统的声明拆解为十个问题，每个问题都附有核查表。

## 何时使用这份核查清单

如果你准备依据服务商或协议“输出可验证”的声明行事，应先使用这份清单。例如，你可能要依据这类声明为某个特定模型付费，或让智能体根据这些输出采取行动。需要准备的材料有：书面声明及其所依据的论文或规范、验证工具，以及你自己的要求，其中要包括单个错误输出会让你付出多大代价。

## 1. 准确写下声明的内容

把声明完整地写下来，写明模型、输入、输出、解码设置以及运行发生的时间。解码设置决定模型如何选出每个词元（token）。每种机制只覆盖上述要素中的一部分。zkLLM 的零知识证明表明，对于给定的提示词和服务商已承诺的保密模型，返回的结果是正确的。[^1] Gong、Liu 和 Li 认为，这类证明并不约束实际投入的计算量。在他们提出的 Hollow-LLM 攻击中，服务商保留所声明的架构和参数量，使用的权重却把计算量降到一个小得多的模型的水平。这些证明依然能通过验证。[^3] TOPLOC 核查的是模型内部激活值的哈希。其作者指出，它无法发现推测解码（speculative decoding），即由一个更便宜的模型生成词元的做法。不过在作者的测试中，模型、提示词或数值精度的每一次改动，它都识别了出来。[^4]

- [ ] 用一句话写下声明，点明模型、输入、输出、解码设置和时间
- [ ] 标出哪些部分有证据覆盖，哪些只是服务商的断言
- [ ] 确认“模型”指的是某个具名的发布版本，还是仅指服务商承诺过的权重

## 2. 确定采用的机制

写明声明所依赖的机制。每类机制依据的证据和假设各不相同。

| 机制 | 示例 | 核查通过表明 | 主要假设 |
| --- | --- | --- | --- |
| 零知识证明 | zkLLM、DeepProve[^1, 2] | 输出与公开架构在已承诺权重上的运行结果相符[^3] | 承诺对应的正是预期的那组权重 |
| 硬件远程证明 | 在可信执行环境（TEE）中提供推理服务[^7, 9] | 真实的硬件加载了哪些软件 | 硬件厂商和经过度量的软件 |
| 激活指纹 | TOPLOC[^4] | 重算的激活值与服务商提供的哈希在设定阈值内相符 | 有能力重新运行模型的验证者 |
| 仲裁式委托 | Verde[^5] | 结果正确，前提是至少有一家服务商诚实 | 模型算子在不同硬件上给出逐位相同的结果 |
| 乐观重新执行 | EigenAI[^8] | 争议窗口期内无人挑战，或重新执行的结果一致 | 有人发起挑战；验证者使用相同的硬件 |
| 抽样审计 | IMMACULATE[^6] | 受审计的请求与所声称的模型一致 | 审计请求与普通请求无法区分 |

- [ ] 写明采用的机制，以及规定该机制的文档

## 3. 查明谁能执行验证

查明验证程序需要哪些数据和硬件，因为这决定了你或你信任的人能否运行它。零知识证明原则上可以公开验证。[^3] DeepProve 报告的验证时间为 1 至 3.7 秒。[^2] TOPLOC 的验证者要在已生成的词元上重新运行模型，以重算激活值。[^4]因此，它需要模型权重和合适的硬件。EigenAI 要求验证者与运营方（即运行推理的一方）使用相同型号的图形处理器（GPU），因为 A100 和 H100 GPU 执行相同的运算会得出不同的结果。[^8]

- [ ] 弄清你能否自行验证，还是必须依赖服务商、某个委员会或审计方
- [ ] 确认验证程序的代码已经公开，而且你能够运行
- [ ] 记下验证程序所需的权重、硬件或数据

## 4. 列出你仍需信任的对象

逐一列出这样的参与方或组件：其中任何一个出问题，错误的输出就能通过核查。每种机制都至少依赖一个，上表最后一列列出了最主要的那个。外部测试也无法消除这种依赖。Cai 等人的结论是，不经服务商配合的测试无法可靠地发现模型替换。针对文本输出的统计检验需要大量查询，而且会漏掉细微的替换；针对对数概率的检验则会失效，因为生产环境中的推理是非确定性的。[^7] Cai 等人转而提议使用 TEE。TEE 把信任转移到硬件厂商和经过度量的软件上。我们的[远程证明报告解读指南](/articles/how-to-read-a-remote-attestation-report/)介绍了这些检查。

- [ ] 逐一列出这样的参与方或组件：其中任何一个出问题，错误输出都能通过核查
- [ ] 标出哪些假设是服务商明确说明的、哪些是你推断出来的，并判断每项假设能否接受

## 5. 确认核查是否覆盖每一个输出

查明方案核查的是每个输出、抽取的一部分输出，还是只有存在争议的结果。IMMACULATE 的审计方会发送少量随机请求，这些请求看起来与普通流量无异。审计方随后要求服务商证明自己是如何响应这些请求的。作者的推理是，服务商只有在不可忽略的一部分请求上偏离声明，作弊才划算。他们据此认为，这种抽样能以压倒性概率发现大规模偏离。[^6]在 EigenAI 的乐观设计中，结果只要在争议窗口期内无人挑战，就维持有效。[^8]两种设计针对的都是系统性作弊。它们都不能保证你收到的某个具体输出经过了核查。

- [ ] 写明核查的是每个输出、随机抽取的输出，还是只有受到挑战的输出
- [ ] 如果采用抽样，查明审计比例，以及审计请求是否与普通请求无法区分
- [ ] 判断在你的用途中，单个未经核查的输出是否可能造成损害

## 6. 检查证据如何与你的请求绑定

检查证据是否指向你的请求，这样它才无法挪用到别的请求上。证据还必须涵盖决定输出的每一项输入。EigenAI 把它的输出描述为模型、提示词、随机种子和解码设置的纯函数，即输出只取决于这四项输入。因此，这四项都必须记录下来，重新执行的结果才能一致。[^8]会话绑定同样重要。在 WhatsApp 基于 TEE 的系统中，证明报告起初不含任何由客户端提供的值，因而本可能遭到重放。Meta 的修复把每份报告绑定到一个传输层安全（TLS）连接上。[^9]如果智能体根据输出采取了行动，就把证据与该行动的记录保存在一起。这样就能把这一行动追溯到经过验证的结果。

- [ ] 证据直接或通过哈希标明了你的输入、输出和解码设置
- [ ] 证据与你的请求、会话或随机数（nonce）绑定，因此无法重放到别的请求上
- [ ] 你可以把证据与输出，以及基于输出采取的任何行动一起保存

## 7. 检查模型承诺的方式

检查模型承诺。模型承诺是公开发布的权重密码学指纹，后续的数学证明都以它为参照。在 zkLLM 中，服务商为一个模型生成承诺最多需要 20 分钟，公布的承诺约为 10 MB。[^1]承诺固定了一组权重，却不说明这是哪一组权重。除非服务商把承诺与一个你能检查或评测的发布版本关联起来，否则数学证明只能表明输出与某组固定的权重一致。Hollow-LLM 的研究结果还表明，权重即使符合所声明的大型架构，实际完成的也可以只是一个小得多的模型的计算。[^3]

- [ ] 找到已公布的承诺及其公布日期
- [ ] 检查承诺如何与你能识别的权重关联，例如公开发布的权重或经过评测的模型
- [ ] 问清楚承诺一旦改变，你会如何得知

## 8. 弄清核查失败的后果

查明核查失败会带来什么后果。没有明确的后果，发现错误也改变不了什么。在 EigenAI 中，重新执行时发现结果不一致会导致罚没，即从运营方的质押中扣除资金。[^8]在 Verde 中，争议会缩小到模型计算中的单个算子。仲裁方重新执行这个算子，找出出错的服务商。[^5]如果依靠密码学证明或远程证明，后果由你自己的客户端决定，因此要确认客户端会拒绝未通过核查的输出。

- [ ] 查明文档规定的核查失败后果，例如拒收、退款、处罚或公开披露
- [ ] 确认谁会收到通知，以及失败情况是否公开
- [ ] 决定你的系统如何处理未通过验证或跳过了验证的输出

## 9. 权衡成本与延迟

记录验证的成本，因为成本决定了服务商负担得起验证多少流量。zkLLM 报告，为一个 130 亿参数模型的一次推理生成零知识证明，用时不到 15 分钟。[^1] DeepProve 报告，GPT-2 每分钟约可证明 174 个词元，Gemma 3 约为 86 个。[^2] IMMACULATE 只对受审计的请求运行可验证计算，报告的吞吐量开销不到 1%。[^6] EigenAI 报告，在其自身测试中开销低于 2%。[^8] Verde 让每项任务至少在两家服务商上运行，因此总成本至少翻倍。此外，它的可复现算子相对 PyTorch 还有额外开销：作者报告，在 A100 GPU 上，10 亿参数 Llama 模型的推理开销为 58%，80 亿参数模型为 98%。[^5]

- [ ] 记录每个输出的证明成本和验证成本，以及由谁承担
- [ ] 确认这些数字来自服务商，还是来自独立测量
- [ ] 确认成本与第 5 个问题中所声称的覆盖范围相称

## 10. 寻找独立审查

寻找针对机制本身及其部署的外部审查。zkLLM 获 2024 年 ACM Conference on Computer and Communications Security（CCS）录用；DeepProve 的 ePrint 条目则标注为 CCS 2026 小修（minor revision）。[^1, 2]学术分析还可能揭示一整类声明的缺口，Hollow-LLM 论文针对零知识推理提出的正是这样的论点。[^3]具体部署也需要单独审查。Trail of Bits 在 WhatsApp 基于 TEE 的系统上线前做了审计，发现 28 个问题，其中 8 个被评为高危。[^9]仅由服务商自己测量的数字，例如 EigenAI 的可复现性结果，在其他人复现之前都应视为声明。[^8]

- [ ] 查找针对该机制以及具体部署的外部审查
- [ ] 确认针对该机制的已知攻击是否已有应对

## 示例

:::example 示例（假设情形）：两项虚构的声明
一个研究团队只想为自己请求的模型付费。服务商 A 称，每个回答都附有零知识证明，表明回答由它的 700 亿参数模型生成。服务商 B 称，所有输出都可验证，因为推理是确定性的，输出会公开，而且任何人都可以在 24 小时内对结果提出挑战。团队对这些问题的答案如下：

| 问题 | 服务商 A | 服务商 B |
| --- | --- | --- |
| 声明的内容 | 输出与已承诺的权重一致 | 输出可由模型、提示词、随机种子和设置复现 |
| 覆盖范围 | 每个回答 | 仅限受到挑战的回答 |
| 谁来验证 | 任何拥有验证程序的人 | 拥有相同 GPU 的挑战者 |
| 模型承诺 | 已公布，但没有文档说明它与哪个具名版本关联 | 说明了模型名称，未公布承诺 |
| 核查失败时 | 客户端拒绝该回答 | 运营方的质押遭罚没 |
| 成本 | 未说明证明延迟 | 挑战者承担重新执行的成本 |

两项声明都不能解答团队的问题。A 的零知识证明无法表明，已承诺的权重就是其宣传的模型。Hollow-LLM 的研究把这一缺口具体地呈现了出来。[^3]就 B 而言，只有在有人发起挑战时，才能发现模型遭到替换，因此团队需要安排自己的挑战者，抽查一部分输出。团队要求 A 把承诺与公开且经过评测的权重关联起来，并询问 B 结果受到挑战的频率。
:::

:::limits 这份核查清单不能说明什么
- 完整的答案能表明一项声明涵盖了什么。它们不能表明机制的实现是正确的；要确认这一点，需要审查部署的代码和配置。
- 验证是对照一份规范来核查计算，规范可以是已承诺的权重和解码设置等。它不能表明输出准确、安全或适合你的任务。
- 抽样方案和乐观方案旨在发现系统性偏离，因此单个回答即使遭到改动，也可能逃过核查。
:::