Sable：让大模型生成结果可被逐位验证的单 GPU 证明系统

导语

大模型服务通常要求用户相信两件事：服务方运行的是承诺的模型，返回的文本确实由该模型按照既定输入生成。Sable 试图把这种“相信”改造成可验证的密码学声明：给定一组已承诺的整数化权重、一个 prompt 和一段回复，验证者可以检查模型是否逐位计算出了这段 token 序列，包括最终停止的位置，而不必重新运行 GPU 推理。

核心方法

Sable 的关键并不是直接为常见的 BF16 推理套上一层证明，而是先定义一个固定的整数函数 F_O。该函数不包含浮点操作，量化模型中的舍入、归一化、Softmax 和采样决策都由输入确定。这样，证明对象成为一条明确、可复现的离散执行轨迹，也避免了不同硬件对浮点计算处理差异带来的歧义。

系统使用 31 位 KoalaBear 素数域，并对约束关系进行设计，确保中间结果不会发生模数回绕。证明阶段将 zerocheck 与 LogUp-GKR 查表操作批量合并，在每个域上使用一次 sumcheck，从而减少证明系统的开销。模型权重和中间 witness tensor 则通过一种结合 Reed-Solomon 编码、BLAKE3 Merkle 树和混合长度 BaseFold opening 的多线性承诺统一提交。

工程上，证明器可以在单张 GPU 上按层流式运行，而不是要求把全部中间状态同时保存在显存中。论文给出的实测结果包括：RTX PRO 6000 Blackwell 为 Qwen2.5-32B 的 4096 token 输入生成证明需要 92.5 秒，16384 token 需要 398 秒；Qwen3-32B 和 MoE 模型 Qwen3-30B-A3B 在 4096 token 下分别需要 121.8 秒和 84.7 秒。验证器在单个 CPU 核心上检查证明约需 19 至 56 秒。

性能与准确性如何理解

Sable 的证明成本仍然很高：论文报告其约为普通服务时间的 41 至 50 倍，按公开 GPU 价格估算，4096 token 请求的证明成本约为 6.4 美分。与 zkLLM 的对比中，作者称其单位参数、单位 token 的耗时减少了 40 至 64 倍，但这并不意味着证明已经等同于常规在线推理的成本。

更重要的是，F_O 是为“可证明的整数执行”定义的模型函数，不应直接视为 BF16 模型的逐位复制。在 WikiText-2 上，其贪心 token 与 BF16 模型在 86.3% 的位置一致；在 Qwen3 的 MMLU 和 GSM8K 测试中，结果分别距 BF16 版本 1.6 和 1.7 个百分点。也就是说，系统同时面对两个问题：证明计算是否足够快，以及整数化执行是否保留了目标模型的行为。

意义与局限

Sable 展示了可验证推理从“小型演示”走向大语言模型层级实现的一条路线。它尤其适合需要审计模型版本、核验外包推理或降低服务方作假空间的场景。不过，证明针对的是已承诺的整数化模型，而不是任意运行环境下的原始浮点模型；长上下文还会显著增加证明负担。未来能否通过更快的证明器、硬件加速和更高效的量化方案，把数十倍的额外成本压缩到在线服务可接受的范围，将决定这类技术能否真正普及。

来源：Hugging Face Daily Papers