不交出权重也能验证：大模型可证明推理解析

当模型能力成为商业核心竞争力，“这条回复到底出自哪个模型”正在从一个技术问题变成一个信任问题。可证明推理（provable inference）给出了一种密码学答案：让模型来源从“需要相信服务商”变成“可以数学验证”。本文梳理这一技术的动因、协议设计、安全性质、性能挑战与落地边界。

一、信任缺口：为什么“相信服务商”不够

当前大模型服务普遍建立在单向信任之上，而这种信任在至少三类场景下是脆弱的：

1. 模型偷换风险。服务商在高负载或成本压力下，可能悄悄用更便宜的小模型顶替旗舰模型，用户从回复文本上几乎无法分辨；
2. 安全声明无从核实。开发者宣称代码库“经过某个前沿安全模型审查过”，使用方没有任何手段验证这类声明；
3. 算力监管需求。若监管方案试图通过约束算力来控制 AI 发展节奏，监管方需要确认一批硬件确实在执行既定推理任务，而不是被挪去训练新模型。

现有替代手段各有明显短板：

• 公开权重：可以自证，但权重是服务商最核心的资产，商业上不可行；
• 输出比对与统计指纹：靠文本特征判断“像不像某个模型”，易被对抗手段绕过，证据力弱；
• 第三方审计：只能时点抽查，覆盖不了每一次调用；
• 可信执行环境：把信任从软件转移到硬件与厂商，仍需信任链支撑，且存在侧信道隐患。

密码学提供了根本不同的路径：不依赖对任何一方的信任，让“声称为真”变成“可被验证为真”。

二、技术底座：zkSNARK 与四个理想性质

零知识证明是密码学中的经典构造：证明者向验证者证明某个计算命题为真，同时不泄露命题之外的任何信息。理想的证明系统追求四个性质——完备性（命题为真时，诚实生成的证明必被接受）、可靠性（命题为假时，伪造证明在计算上不可行）、零知识性（验证者学不到额外信息）、简洁性（证明小、验证便宜）。

zkSNARK（零知识简洁非交互式知识论证）同时满足这四点：证明通常只有 KB 到 MB 量级，验证只需毫秒到秒级，且生成后是一个独立文件，可随 API 响应下发、可存档、可事后复验——这对审计与监管场景尤其有价值。它还有一个关键的不对称性：证明生成的代价远高于验证。这恰好匹配“服务商重、用户轻”的推理验证场景：重活由提供方承担，用户只需轻量校验。

把模型推理建模为可证明的命题，即：已知权重承诺 C、输入序列 x、输出序列 y，证明“存在一组权重 w，使得 Commit(w)=C，且以 w 为参数的模型在输入 x 上产生输出 y”。

三、协议全流程：先承诺、再证明、后验证

系统涉及两方角色：模型提供方负责出证明，用户负责验证。流程分两个阶段。

离线阶段：权重承诺。 提供方对模型权重生成一个密码学承诺，可理解为一串极短的“校验值”，与这版权重唯一绑定：由权重可随时重算出承诺，但从承诺反推权重在计算上不可行。承诺发布到公开的透明日志中供任何人核对，此后每次服务都使用同一版权重，承诺保持不变。

在线阶段：证明生成。 用户拿到回复后请求证明，提供方生成一个证明文件，命题是“承诺对应的这版模型，在这段输入上确实会输出这些 token”。生成证明需要提供方把推理全过程纳入电路约束重算一遍，因此开销显著高于一次普通推理。

验证阶段：轻量校验。 任何人拿到承诺、提示词、回复与证明文件，即可在普通设备上完成验证，全程不需要接触权重。

示意性流程如下（伪代码，仅表达协议逻辑）：

# 离线：权重承诺
C = Commit(weights, randomness)          # 短校验值，公开；权重保持隐藏
# 在线：证明生成（提供方）
proof = Prove(C, prompt, output_tokens, witness=weights)
# 验证（任何人、任意设备）
result = Verify(C, prompt, output_tokens, proof)    # accept / reject

四、四大性质逐条拆解：价值在后两条

• 完备性：诚实提供方生成的证明一定通过验证，保证正常服务不受影响；
• 可靠性：任何伪造可通过验证之假证明的尝试，都被归结为攻破一组业界公认的密码学困难假设——这在计算上被认为不可行。换言之，验证方不必信任提供方的商业承诺，只需相信现代密码学；
• 零知识性：证明内容不暴露权重参数、推理的中间激活，也不暴露稀疏结构中每个 token 实际路由到了哪个专家；但模型的公开设计（层数、隐藏维度、架构类型等）不在保护范围内；
• 简洁性：证明文件小、验证便宜，笔记本电脑甚至手机即可完成校验。

值得强调：前两条性质其实“有权重 + 有算力”就能实现——自己把模型重跑一遍核对即可。真正让这套系统具备工程意义的，是后两条：提供方不必交出权重，验证方不必准备一套数据中心。这正是零知识证明“知识不外泄、验证不沉重”的核心价值。

五、性能鸿沟：从“跑一遍”到“证一遍”

最大的工程障碍是开销。证明相当于把一次推理在密码学电路中完整重做并附加大量域运算。公开研究显示，早期方案证明 1,000 个 token 的生成需要十小时以上，证明文件达数十 GB，验证耗时接近一天，显然无法进入生产环境。瓶颈主要来自五个方面：

1. 数值表示不匹配：主流模型使用 bf16/fp16 浮点运算，而电路工作在素数有限域上，浮点值需转换为定点/域元素，带来额外量化与范围检查成本；
2. 非线性算子昂贵：softmax、GELU 等激活在电路中缺乏天然算术表达，通常依赖查找表论证或分段逼近；
3. 注意力的大规模矩阵乘：随序列长度增长的密集矩阵运算，是电路规模的主要来源；
4. 稀疏路由难统一：混合专家模型中“每个 token 选哪个专家”是数据依赖分支，电路需用统一结构覆盖所有路径；
5. 自回归串行依赖：token 逐个生成、缓存层层传递，计算图深度大，难以并行摊薄证明时间。

近期的系统性优化沿几条主线推进：对矩阵乘等热点算子做专门算术化与求和检查协议；用查找表论证压缩非线性算子；将长序列拆分后递归证明、分而治之；让证明系统的核心运算与 GPU 深度协同、与推理内核共享优化。公开报告显示，相较早期方案，新系统已把证明速度与证明体积改善约两个数量级——距离“零开销”仍远，但已开始触及可用的门槛。

六、与其他可信方案对比

方案	是否需公开权重	验证成本	信任基础	主要短板
公开权重	是	需自行复算	自身算力	泄露核心资产
统计指纹/输出比对	否	低	模式识别	可被对抗、证据弱
第三方审计	部分	中	审计方	时点抽样、滞后
可信执行环境	否	低	硬件与厂商	信任链、侧信道
zkSNARK 可证明推理	否	极低	密码学假设	证明生成开销大

七、落地边界与工程考量

1. 隐私边界：证明覆盖的是“输入-输出对”的正确性，验证者能看到提示词与回复本身。若提示词涉及商业机密，需与可信执行环境或安全多方计算等技术组合，这是公开方案尚未完全解决的问题；
2. 采样随机性：若使用温度采样等随机解码，“会输出这些 token”的命题必须处理随机源——或将随机数种子纳入承诺与证明，或改用确定性解码，否则命题本身不严谨；
3. 承诺治理：用户还需确认两点——电路正确实现了声称的模型计算；线上实际使用的权重与承诺一致。这通常依靠公开电路审计、透明日志与定期抽查证明来保障；
4. 成本分摊：证明开销最终摊入服务成本，可行模式包括对高价值调用按需出证、对批量调用抽检验证、把证明生成放入离线批处理等；
5. 适用前提：零知识隐藏的是权重与中间状态，模型架构需公开；验证者必须拿到与请求一致的提示词与输出，因此更适合 API 服务、网关代理等调用链路清晰的场景。

八、结语

可证明推理的意义在于把“信任服务商”改写为“验证密码学”：权重留在提供方手里，用户用一次轻量校验换取对每一次回复来源的确定性。随着证明开销以数量级的速度下降，这类能力有望从研究走向基础设施——无论对开源社区还是百度智能云这类提供模型服务的平台而言，模型来源可验证都可能成为与低延迟、高并发并列的服务质量维度；对需要对外出具安全声明的开发者、以及对算力进行监管的机构而言，它也提供了一种无需信任第三方的核实手段。对计划构建可信 AI 调用链路的团队来说，当下值得做的是理解协议边界、评估调用模式，为未来接入可验证推理预留架构空间。