Sable以单GPU生成大模型位级推理证明，代价降至每次约6.4美分

摘要：Sable为整数量化Transformer构建位级可验证推理系统，将舍入、归一化、Softmax与采样决策纳入约束，并以Sumcheck、LogUp-GKR和基于Reed-Solomon的多线性承诺生成证明。系统可逐层流式处理模型，在单张RTX PRO 6000 Blackwell上证明Qwen2.5-32B全部64层，4096 Token耗时92.5秒。它把大模型推理证明成本降至每次约6.4美分，但证明开销仍相当于服务耗时的41至50倍，且因不具备零知识性质，目前只适用于开放权重模型。

---

Sable把大模型推理变成可验证的位级声明

Sable证明的是一条严格命题：对于已承诺的整数量化Transformer，给定提示词，模型是否逐位产生指定Token序列。其目标不是证明模型“行为相近”，也不是重新执行若干基准题，而是将前向推理中的每一步舍入、归一化、Softmax计算和采样决策纳入约束系统，证明整条执行轨迹符合指定计算语义。

这一定义尤其重要，因为浮点运算的舍入顺序、并行归约顺序和硬件实现都可能造成结果差异。Sable选择整数函数 F_O，整个证明轨迹不包含浮点步骤，以此消除跨设备执行不一致的问题。系统同时证明约束关系不会在31位KoalaBear素数模下发生回绕，避免有限域归约掩盖整数溢出。

核心证明机制

Sable将模型约束拆分为多个计算域，并针对每个域批量合并zerocheck与LogUp-GKR查找，将原本多次独立sumcheck压缩为一次统一sumcheck。其目标是降低证明协议中的通信轮次、线性化中间量和GPU同步开销。

所有见证张量与模型权重被纳入同一个多线性承诺。底层组合使用Reed-Solomon码处理张量扩展，使用BLAKE3 Merkle树认证承诺数据，并以混合长度BaseFold打开减少不同形状张量带来的协议开销。证明器不要求一次性把完整模型和中间激活常驻显存，而是按Transformer层流式执行，因此能够处理32B稠密模型和MoE模型。

从工程角度看，真正困难的是线性代数算子与有限域算子的持续切换：矩阵乘法、归一化与Softmax需要处理完整激活，而sumcheck和承诺计算要求高频写入大体积有限域数据。Sable的工程价值在于用分层流式证明控制显存，而不是单纯压缩证明长度。

单GPU实测表现与证明成本

在单张NVIDIA RTX PRO 6000 Blackwell上，Sable证明Qwen2.5-32B的64个层：

• 4,096 Token耗时92.5秒；
• 16,384 Token耗时398秒；
• Qwen3-32B处理4,096 Token耗时121.8秒；
• Qwen3-30B-A3B处理4,096 Token耗时84.7秒。

从4,096扩展到16,384 Token时，耗时约增长4.3倍，略高于Token数的4倍，表明长序列证明在当前实现中仍近似线性扩展，但公开摘要不足以判断其中多少来自网络通信、层间证明和显存带宽。

论文估算每次4,096 Token证明约需6.4美分，但这并不是完整生产服务的总成本：证明过程消耗额外GPU时间，且验证者还需要19至56秒的单核CPU检查时间。相对zkLLM，Sable按“每参数、每Token”计算的时间降低40至64倍；不过总体验证时延、证明大小和跨网络传输开销仍需结合完整实验报告评估。

量化语义带来的能力差异

Sable使用整数函数 F_O 取代BF16模型，因此证明验证的是整数执行语义，而不是原始BF16模型逐位复现。WikiText-2上，F_O 的贪心Token与BF16模型在86.3%的位置一致；Qwen3上，MMLU与BF16相差1.6个百分点，GSM8K相差1.7个百分点。

这些结果表明整数实现存在可测的数值漂移。差异可能来自激活量化、Softmax近似、算子实现及舍入策略，而不只是权重量化。基准结果只能说明部分常见任务性能接近，尚不能证明其与BF16模型在长链推理、代码生成、安全行为及分布外输入上等价。

在随机预言机模型下，该交互式证明逐轮错误概率为 2^-103。不过，安全性结论依赖哈希与承诺方案在随机预言机模型下的假设；部署环境仍需评估协议实现、侧信道、输入编码规范以及验证器实现缺陷。

工程权衡：可验证性换取了哪些代价

Sable并未把证明开销降到可忽略水平。其证明耗时仍相当于服务耗时的41至50倍，意味着每个请求若都执行完整证明，GPU成本会远高于普通推理。6.4美分的估算之所以具有吸引力，是因为它对应特定公开GPU价格和4,096 Token负载，不能直接外推到H100、集群GPU或低利用率场景。

更关键的限制是证明不具备零知识性质。证明可能泄露与私有权重或私有推理轨迹相关的信息，因此系统只适合开放权重模型。对于闭源API模型，验证方无法获得完整权重承诺和可复现执行环境，也就无法使用同一证明流程进行端到端审计。

交互式证明还意味着证明者与验证者通常需要多轮通信。论文给出了单核验证时间，但摘要未披露总通信量、证明对象大小、网络往返次数和断点恢复机制。这些指标决定该系统更适合低频审计、可信执行环境，还是能够进入在线请求路径。

开发者落地建议

Sable更适合作为模型发布、权重托管和高价值请求的审计层，而不是默认开启的在线推理功能。对开放权重模型，可在部署前对固定权重、固定提示词和固定解码配置生成证明，再由独立验证方检查；对动态采样请求，则需要明确随机种子、采样算法与量化配置，否则证明命题本身无法稳定复现。

工程团队采用前应重点验证四项指标：GPU型号与驱动下的证明吞吐、证明对象和通信量、量化模型相对BF16的任务级回归，以及生产系统的密钥和承诺管理。代码已经公开，优先复现Qwen2.5-32B与Qwen3-30B-A3B的4,096 Token实验，可更快判断单GPU流式证明在自有硬件上的实际收益。

---

消息来源：Hugging Face Daily Papers (2026-11-10)

—— 完 ——

主题标签： #零知识证明 关注 #大模型可验证推理 关注 #整数量化 关注 #Sumcheck 关注 #Qwen 关注