Verde与RepOps：机器学习可验证委托与硬件无关确定性

1. Verde与RepOps：机器学习程序的可验证委托与硬件无关确定性

在机器学习领域，委托计算（如模型训练和推理）到不受信任的计算提供商时，确保结果的正确性是一个关键挑战。传统的密码学证明系统虽然提供强保证，但计算开销巨大，难以实际应用。Verde通过引入仲裁委托（refereed delegation）机制，允许计算能力有限的客户端将程序委托给多个不受信任的计算提供商，并保证只要至少有一个提供商是诚实的，就能获得正确结果。这一机制的核心在于高效的争议解决协议和跨硬件设置的位级程序重现能力。RepOps库通过控制浮点运算的执行顺序，消除了硬件非确定性，确保了不同硬件环境下计算的一致性。这些技术为机器学习程序的可验证委托提供了实用且高效的解决方案，适用于分布式训练和推理等场景。

1.1 机器学习委托计算的挑战与现有方案

机器学习程序（如大型语言模型的训练、微调和推理）通常需要巨大的计算和内存资源，这使得许多用户不得不将这些任务委托给外部计算提供商。然而，这种委托通常没有任何正确性保证。不诚实或被入侵的服务器可能返回错误的输出，例如：

• 懒惰服务器：可能不会按照承诺的时间训练模型，而是返回近似结果
• 恶意训练者：可能执行数据投毒攻击或在训练模型中插入后门

目前主要有两类解决方案：

1. 密码学证明系统：提供最强的保证，但计算开销极高（比运行程序本身高4个数量级）
2. 启发式ML特定技术：如Proof-of-Learning或Proof-of-Training-Data，牺牲形式化保证换取效率，但缺乏严格的安全保证

Verde提出的仲裁委托模型在这两种极端之间找到了平衡点，既能提供具体保证，又只对计算提供商施加实际可接受的开销。

1.2 仲裁委托的基本原理

仲裁委托的核心思想是：客户端将相同的任务委托给多个计算提供商（称为"训练者"），并通过高效的争议解决机制确保只要至少有一个训练者是诚实的，就能获得正确结果。其安全保证是：

• 如果存在诚实训练者，其输出保证被接受
• 裁判将识别k-1个不诚实训练者，证明他们报告了不正确输出
• 如果所有训练者都不诚实，协议仍会识别k-1个不诚实提供商，但裁判也会接受一个不正确输出

这种机制的关键创新在于高效的争议解决协议，避免了裁判需要完全重新执行计算的高开销。

2. Verde：神经网络争议解决协议

2.1 协议概述与程序设置

Verde协议分为两个主要阶段：

1. 阶段1：识别训练者首次出现分歧的具体训练步骤
2. 阶段2：识别计算图中第一个出现分歧的操作符

程序设置包括：

• 客户端指定具有初始权重的神经网络、训练数据和训练元数据
• 模型表示为拓扑排序的计算图（使用ONNX等标准格式）
• 每个"训练步骤"包括前向传递、后向传递、参数更新和优化器状态更新

2.2 阶段1：识别分歧的训练步骤

2.2.1 基本方法

将训练过程抽象为状态机：

• "状态"：可学习参数和优化器状态的值
• "转换函数"：每个训练步骤执行前向传递、后向传递和优化器状态更新

训练程序可以视为一系列检查点C0→C1→...→Cn。如果两个训练者从C0开始但在n步后产生不同输出Cn和C'n，则必定存在一个训练步骤i，他们首次"分歧"。

2.2.2 优化：多级检查点

原始方法需要训练者在每个步骤哈希整个模型状态，对于大模型开销过高。Verde采用多级检查点技术：

1. 训练期间，训练者只在指定步骤记录检查点
2. 争议解决时，通过多轮交互逐步缩小分歧区间
3. 每轮在更小的区间内记录更细粒度的检查点
4. 最终定位到单个训练步骤的分歧

这种方法的通信和存储成本：

• 通信开销最小（只传输短哈希）
• 存储与检查点频率的权衡：
  • N=20时：重新执行<6%的训练程序，存储几百GB
  • N=100时：重新执行<1.1%，存储几TB

2.3 阶段2：识别分歧的操作符

2.3.1 扩展计算图表示

Verde将神经网络表示为有向无环计算图，并扩展该表示以捕获训练步骤中的所有工作：

• 前向传递
• 后向传递
• 优化器状态更新

每个节点增强为AugmentedCGNode，包含：

• 输入节点指针
• 输出节点指针
• 操作符和属性
• 输入张量哈希列表
• 输出张量哈希列表

2.3.2 争议解决算法

算法流程：

1. 训练者发送节点哈希序列给裁判
2. 裁判验证检查点状态的一致性
3. 找到第一个分歧的节点索引d
4. 训练者"打开"他们的第d个节点
5. 裁判运行决策算法

检查点哈希格式使用Merkle树，叶子节点是导致检查点的训练步骤中所有AugmentedCGNode节点的哈希。

2.4 裁判决策算法

根据节点差异类型，裁判采用不同策略：

1. 图结构差异（输入、输出、操作符）：裁判根据客户端指定的模型检查哪个结构正确
2. 输入张量哈希差异：
   • 如果来自起始检查点：请求Merkle成员资格证明
   • 如果来自图中另一个节点：请求源节点的"打开"
3. 输出张量哈希差异：裁判需要运行操作符决定哪个训练者正确

这种方法将裁判的计算需求减少了两个数量级，使其只需执行计算图中的单个操作符。

3. RepOps：可重现操作符库

3.1 硬件非确定性的来源

即使遵循IEEE-754标准，浮点运算也不具有结合性，导致不同硬件可能产生不同结果。主要原因包括：

• 并行程序中运算顺序不同
• 不同硬件架构（核心数、内存容量等）
• 内存中张量的不同排列（strides）

3.2 RepOps设计原理

RepOps通过控制浮点运算的顺序来消除硬件非确定性，具体方法：

1. 确定并行化维度：

   • 对结果顺序无关的维度：自由并行化
   • 对顺序关键的维度：串行执行或同步线程

2. 矩阵乘法示例：

# repops矩阵乘法 for i = 0 to M-1: # 任意顺序 for j = 0 to N-1: # 任意顺序 sum = 0 for k = 0 to K-1: # 固定顺序 a = A[i][k] b = B[k][j] sum = sum + a * b C[i][j] = sum

3. 性能特点：
   • 矩阵维度>210时，开销<30%
   • Llama-3.1-1B推理和训练在A100 GPU上约60%开销

3.3 当前局限性与未来工作

局限性：

1. 较小矩阵乘法开销较高（256位矩阵约200%）
2. DistilBERT训练在某些设置上开销达300%
3. 需要硬件符合IEEE-754标准（FP32广泛支持，FP16支持有限）

未来方向：

1. 模型并行性支持：扩展到多GPU环境
2. 特定硬件优化参数调优
3. 支持更多操作符和模型架构

4. 实现与评估

4.1 实现细节

• 使用PyTorch框架（v2.4）
• 神经网络模型定义为ONNX计算图
• RepOps使用CUDA框架（v12.1）实现
• 当前支持FP32精度

4.2 矩阵乘法基准测试

关键观察：

• 随着矩阵增大，RepOps开销显著改善
• 达到稳定状态后：
  • RTX 3090（24GB）：60-70%开销
  • T4（16GB）：约35%开销

4.3 模型推理与训练基准

测试模型：

1. DistilBERT（6600万参数）
2. Llama-3.1-1B
3. Llama-3.1-8B（仅推理和微调）

主要发现：

1. RepOps在较大Llama模型上表现相对更好
2. DistilBERT因包含更多未优化操作符（如LayerNorm、GeLU、ERF）而开销更高
3. 较大内存GPU（如A100 40GB）比小内存GPU（如T4 16GB）表现更好

具体数据：

• Llama-1B训练在A100上：67%开销
• Llama-8B微调在A100 80GB上：126%开销

5. 实际应用与未来方向

5.1 应用场景

1. 机会性审计：客户端作为裁判委托计算
2. 去中心化训练：链上智能合约作为裁判
3. 关键任务ML服务：需要强正确性保证的场景

5.2 实际部署挑战

1. 训练者生态系统：需要足够多不可能共谋的训练者
2. 激励机制设计：补偿训练者的原始计算和争议解决工作
3. 区块链集成：在EVM等环境中高效实现裁判功能

5.3 未来工作方向

1. 支持更低精度（如FP16）训练
2. 分布式训练的场景扩展
3. 更广泛的操作符支持
4. 特定硬件优化
5. 与现有ML框架更深度集成

Verde和RepOps的组合为机器学习程序的可验证委托提供了实用且高效的解决方案，填补了完全验证计算和纯启发式方法之间的空白。虽然存在一些性能和部署上的挑战，但其核心思想和技术路径为构建更安全、可靠的机器学习计算生态系统奠定了重要基础。