拒绝「降智、减配、乱收费」：面向LLM API的可信验证框架|黑盒_新浪科技

本文作者分别来自新加坡国立大学和加州大学伯克利分校。第一作者郭衍培来自新加坡国立大学，长期关注大语言模型基础设施中的可信性与安全性问题，特别是云端 LLM 服务的可验证性与经济激励风险。指导教师为新加坡国立大学校长青年教授张嘉恒和加州大学伯克利分校 Dawn Song 教授。

大语言模型（LLM）已经成为各类 AI 应用的基础设施，然而，在通过云端 API 便捷接入这些强大模型的同时，此类黑盒服务模式也引发了一个现实的信任危机：如何确保大模型服务提供商真的运行了所承诺的模型，并如实报告实际使用了 Token 数量，以防止潜在的 LLM 服务 “降智、减配、乱收费”？

事实上，围绕 LLM 服务 “降智” 的讨论，已经在国内外多个开发者社区中反复出现，不少用户都报告过模型在使用一段时间后表现明显下滑的现象 [1,2]。与此同时，若服务商出于竞争或策略原因，对特定用户群体提供差异化甚至低质量服务 [3]，则会进一步加剧黑盒 AI 服务的信任危机。

针对这一系列问题，研究者们最近提出了一种新的利用可验证计算（Verifiable Computation）来证明推理过程正确性的 LLM 服务审计框架 ——IMMACULATE。借助该框架，用户能够在完全不暴露模型内部信息的情况下，仅需 1% 的额外开销，就能轻松验证黑盒 LLM API 的执行完整性，以有效检测模型替换、过度量化以及 Token 虚报计费等 LLM 服务违规行为。相关论文与代码已公开。

论文题目：IMMACULATE: A Practical LLM Auditing Framework via Verifiable Computation
论文链接：https://arxiv.org/pdf/2602.22700
代码链接：https://github.com/guo-yanpei/Immaculate

本研究提出了一种面向黑盒 LLM API 的全新审计框架 IMMACULATE。该框架无需访问模型内部结构，也不依赖专用可信硬件，即可检测云服务商是否真实执行了其声称的模型推理过程，并是否如实报告 token 使用量。通过引入 Logit Distance Distribution (LDD) 这一新的统计度量，并结合随机化审计与可验证计算技术，IMMACULATE 在真实模型上实现了低于 1% 的系统开销，同时能够可靠检测模型替换、过度量化以及 token 过度计费等经济动机型违规行为。

00 背景：当 LLM 成为 API 服务

近年来，大语言模型（LLMs）逐渐成为 AI 应用的重要基础设施。绝大多数用户并不会直接运行模型，而是通过云端 API 服务调用模型能力。例如 OpenAI、Anthropic 和 Google 等公司提供的模型服务，都采用这种模式。

然而，这种黑盒服务模式带来了一个根本性的信任问题：用户无法验证服务提供商是否真正执行了其声称的模型。

从经济角度看，服务商存在动机通过各种方式降低计算成本或增加收费，例如：

模型替换（Model Substitution）

使用更小、更便宜的模型替代宣称的模型

过度量化（Aggressive Quantization）

使用低精度计算降低成本

Token 过度计费（Token Overreporting）

报告比实际更多的 token 使用量

这些行为往往仍会产生语义上正确但整体质量较低的结果，因此用户很难通过输出直接检测到异常。事实上，在国内外多个开发者社区中，已有大量用户分享关于 LLM 服务 “降智” 的经验 [1, 2]：即在订阅服务一段时间后，模型表现明显不如初期。这类现象在技术社区中引发了广泛讨论。

此外，出于竞争或策略性考虑，一些服务提供商还可能对特定用户群体（例如被识别为潜在竞争对手的调用者）提供差异化或低质量服务 [3]。这一行为严重破坏了模型服务的公平性与可信度，并进一步加剧了黑盒 AI 服务的信任问题。

因此，一个关键问题出现了：

如何在不访问模型内部的情况下，验证 LLM API 是否被诚实执行？

01 方法概览：IMMACULATE 审计框架

IMMACULATE 的核心技术基础之一是可验证计算（Verifiable Computation）。可验证计算是一类密码学技术，使服务器能够在不泄露内部计算过程或模型参数的情况下证明计算结果的正确性，从而让用户无需重新执行计算即可验证远程计算。然而，对每一次请求都生成证明的开销非常高。为此，研究团队提出了 IMMACULATE 审计框架，其核心思想是：

无需验证所有请求，只需随机审计少量请求即可检测系统是否存在大规模违规行为。

图 1 IMMACULATE 工作流程：审计单位伪装成普通用户发送随机的请求，并在收到回复后要求提供证明

具体而言，IMMACULATE 的工作流程包括以下步骤：

用户正常向 LLM API 发送请求

服务端返回回答与 token 使用量

审计者随机选择部分请求进行审计

服务端提供可验证计算证明

审计者根据统计指标判断执行是否可信

这种设计利用了一个简单但关键的经济事实：

如果服务商希望通过违规行为获取经济收益，就必须在相当比例的请求上进行违规执行。因此，通过随机审计少量请求即可检测系统是否存在违规行为。

02 关键技术：Logit Distance Distribution (LDD)

图 2 在固定所有离散步骤的结果后，整个推理过程完全是连续函数。输出的距离可以衡量模型的准确度

在实际系统中，验证 LLM 推理过程面临一个重要挑战：GPU 推理存在数值非确定性。即使在完全相同的模型和输入下，不同运行之间的浮点误差也可能导致输出略有不同。因此，传统的 “逐位验证计算” 的方法难以直接应用。

更进一步地，大语言模型的推理过程本身包含两类不同的计算步骤：一类是连续计算（continuous computation），例如注意力计算、MLP 和归一化等神经网络算子；另一类是离散决策（discrete decision），例如 token 选择或专家路由。

连续计算在 GPU 上执行时会受到浮点误差与并行调度的影响，因此具有一定的数值非确定性；而离散决策一旦输入确定，其输出是完全确定的。由于生成过程是自回归的，即使连续计算中极小的数值偏差，也可能导致后续离散决策发生变化，从而使整个推理路径发生分叉。这使得传统需要逐步复现完整推理过程的验证方法难以直接应用。

为此，IMMACULATE 利用了这一结构特性：固定离散决策路径，仅比较连续计算的偏差。具体而言，在给定相同离散决策序列的情况下，我们比较部署模型与参考模型在每一步产生的 logits 向量之间的距离分布。这一分布被称为 Logit Distance Distribution (LDD)。

其核心思想是：不直接验证每一步推理是否完全一致，而是衡量实际执行模型与参考模型之间的 logit 偏差分布。

如果系统正常运行：