基于 FSS 的 GPU 安全训练与推理 Orca
内哈·贾瓦勒卡 印度科学研究所，印度 jawalkarp@iisc.ac.in 尼尚特·钱德兰 微软研究院,印度 nichandr@microsoft.com
卡纳夫·古普塔* 微软研究院,印度 kanav0610@gmail.com
迪维亚·古普塔 微软研究院,印度 divya.gupta@microsoft.com
阿尔卡帕拉·巴苏 印度科学研究所，印度 arkapravab@iisc.ac.in 拉胡尔·夏尔马 微软研究院,印度 rahsha@microsoft.com
摘要 安全的两方计算(2PC)允许两方在不透露输入的情况下计算任何函数。在 2PC 的离线/在线模型中,独立于计算输入的相关随机性在预处理(离线)阶段生成,然后在输入可用时在在线阶段使用。大多数 2PC 工作都集中在优化在线时间,因为这个开销位于关键路径上。基于功能秘密共享(FSS)密码技术的高效 2PC 协议是一个新的范式。我们构建了一个端到端的系统 Orca,以加速使用 GPU 的 FSS 为基础的 2PC 协议的计算。接下来,我们观察到这种加速协议的主要性能瓶颈在于存储(由于大量的相关随机性),我们设计了新的基于 FSS 的 2PC 协议,用于机器学习中的几个关键功能,减少了高达
的存储。与先前在相同计算模型下使用 GPU 加速安全训练的最先进技术(Piranha, Usenix Security 2022)相比,Orca 的准确度
更高,通信量
更少,在 CIFAR-10 上的速度
更快。此外,在使用定点运算的同时保持训练准确度需要随机截断,之前所有关于安全定点训练的工作(包括 Piranha)都使用了不安全的协议。我们提供了第一个安全的随机截断协议,并基于此提供了第一个端到端安全训练的评估。对于安全的 ImageNet 推理,Orca 在 VGG-16 和 ResNet-50 上实现了亚秒级的延迟,并优于当前最先进技术
。
1. 介绍 机器学习训练已经成为一个极其重要且需要大量数据的应用程序。尽管训练
模型通过更多和更多样的数据而变得更好,但这些数据往往高度敏感,例如财务、医疗保健或浏览数据。使用诸如安全多方计算(MPC)等隐私保护技术[29]、[68]可以对这些敏感数据进行安全训练[40]、[48]、[49]、[60]、[62]、[64]、[66]。使用 MPC 进行安全训练允许多个不互信的各方训练他们的联合数据模型,而不会泄露任何一方的数据,只有最终训练好的模型会被公开。然而,基于 MPC 的安全训练存在较高的性能开销。通过最近一系列的工作,在 CIFAR10 数据集上进行安全训练所需的端到端时间已经从数年[49]缩短到数月[64]、数周[60]、并最终达到一天[66]。Piranha 是目前加速安全训练使用 GPU 的最新成果。我们的目标是将这一时间缩短到不到一小时。
基于离线/在线模型,数据无关的相关随机性在离线预处理阶段生成,各方在数据相关的在线阶段使用这种相关随机性。包括 PiranhA 和我们在内的这一模型的工作都关注于降低在线复杂性。为实现高效的安全训练,PIRANHA 对 ML 做了多项 MPC 友好的近似,如用平均池替代最大池[60]、局部截断份额[49]、[60]和用分段线性函数近似指数运算。此外,仿效 Falcon[64]的做法,它也在安全性和效率之间做了权衡,在 softmax 运算中泄露了中间值,这是标准 MPC 安全要求不允许的。PiranhA 观察到它的特设近似导致了相对 PyTorch 训练的显著模型精度下降。例如,PiranhA 报告在 CIFAR-10 数据集上,VGG16 在 PyTorch 中的精度为
,而在安全训练中降至
[66]。最后,所有依赖随机截断的之前的安全训练和推理工作[24]、[32]、[40]、[43]、[47]-[49]、[60]、[62]、[64]、[66],都使用便宜但不安全的协议来实现截断(如局部截断份额),这一点已被 45]指出。 1.1. 我们的贡献 与[49]、[60]、[62]、[64]、[66]不同,我们的安全训练仍然忠实于机器学习文献[31]中已知模拟浮点 PyTorch 训练的量化训练算法。我们发现,对小型模型(参数为数千个)进行忠实的安全训练,其产生的模型精度更高,而使用 Piranha 对大型模型(参数为数百万个)进行安全训练则相反。Piranha 近似在小型模型上失效 - 使用这些近似(本地截断股份或指数函数的分段线性近似)训练我们的小型模型,会将训练模型的准确性降低到随机分类器的水平。在 CIFAR-10 数据集上,我们的安全训练在所有指标上都优于 PIRANHa。我们的方法既安全又产生
更高准确度的模型,同时
更快,
通信开销更低。ORCA 在 45 分钟内达到了 CIFAR-10
的准确率,而 Piranha 则在一天内只达到了
的准确率。 在技术方面,我们的起点是在预处理模型中最近在基于函数保密共享(FSS)的安全二方计算(2PC)协议方面的进展[16]、[19]、[30]。这些协议的一个关键特点是,它们在减少在线通信的同时,增加了计算和存储。FSS 的在线阶段需要大量 AES 计算,并需要读取在预处理期间生成的大量 FSS 密钥。因此,FSS 将性能瓶颈从外部网络转移到单台机器的计算和内存。在这项工作中,我们通过有效加速基于 GPU 的 FSS 2PC,大幅降低了安全训练的开销。然而,我们在系统和密码学方面都面临着几个挑战,我们将在下文中讨论。
1.1.1. 系统优化(详见第 3 节)。为了加速计算,我们创建了 FSS 协议的高效 GPU 实现,速度比基于 CPU 的协议快一个数量级。这个结果让人感到意外,因为之前试图用 GPU 加速 FSS 的工作只获得了边际改进[58]。我们加速实现的关键在于,结合 GPU 微架构进行的一系列独特的系统优化。我们利用了几种 GPU 微架构特性,例如使用 GPU 的 scratchpad 内存进行更快的 AES 计算、优化数据布局以提高 GPU 缓存命中率,以及利用 GPU 的锁步执行来将密码学计算的中间结果最优地打包到内存中。有趣的是,我们发现一旦 GPU 上的计算得到良好优化,从 SSD 读取 GB 级别 FSS 密钥到 GPU 内存就成为了瓶颈。为了解决这个问题,我们依赖于新的密码学协议(下一节讨论)来减小常见训练节点的 FSS 密钥大小。
1.1.2. 加密改进。忠实于量化训练,例如 Gupta 等人[31]中描述的那种,需要有效的协议来处理固定点值、ReLU、最大池化和浮点 softmax 的随机截断。随机截断、ReLU 和最大池化代价高昂,并导致密钥较大。Gupta 等人[31]表明,确定性截断无法在训练过程中维持准确性,因此提出使用随机截断。然而,所有先前用于安全训练的随机截断协议都是不安全的[45]。为了维持端到端安全性,我们提供了第一个安全的随机截断协议。这种更强的安全性是以巨大成本换取的。我们创造了新的协议,将密钥大小减少了高达
(第 5 节),这对于获得低端到端延迟至关重要。量化训练执行几乎所有操作都是在固定点上,但在 softmax 计算中使用浮点算术来维持准确性[31]。在安全训练文献中,有三种方法来计算 softmax 中出现的指数运算:第一,使用非常便宜的分段线性近似[41],[66];第二,使用更昂贵的固定点近似[39],[40];第三,使用更昂贵但更精确的浮点计算[54]。为了忠实于 Gupta 等人[31]的计算,我们选择了第三种选择。为此,我们创建了新的 FSS 协议,以有效地将固定点协议与浮点协议结合起来(第 6 节)。 1.1.3. 虎鲸。我们在 Orca 中实现了我们的技术,这是一个用于安全训练的按钮式工具,将公开发布
。ORCA 拥有一个 GPU 加速的 FSS 块库,未来该领域的研究可以在此基础上构建(第 77 节)。我们发现,使用 Orca 训练小模型同时保持忠实(见图 5)于量化训练[31],在精度(最高
)、时间(
)和通信(
)方面都优于 Piranha 的近似大模型训练(第 8.1 节)。在更公平的比较中,OrCA 在近似训练大模型方面优于 Piranha
(第 8.2.1 节)。Orca 还在不使用 PIRANHA 近似的先前工作中表现优于
(第 8.2.2 节)。OrCA 的协议需要更小的 FSS 密钥(第 84 表),而且 ORCA 的基于 GPU 的协议比其 CPU 对应物快一个数量级(第 77 表)。最后,Orca 实现了有史以来首次亚秒级的 ImageNet 规模 VGG-16 和 ResNet-50 推理,并优于最先进的[30]、[41]
(表 9)。 2.准备工作 2.1. 符號 令
表示计算安全参数。
表示输出 1 时谓词
为真,否则为 0 的指示函数。数组用粗体表示,其元素用同样的符号加上下标表示,从 0 开始。例如
。 脚注内容
https://github.com/mpc-msri/EzPC.git
数据类型。对于
代表
位无符号整数的集合。我们使用符号
表示实数集。对于
,uint
和
分别表示
中相应的无符号和有符号数(采用 2 的补码表示)。 定点表示法。定点表示法由位宽
和标度
参数化,将实数
编码为
,使得
。对于无符号(分别)定点数
的标度为
(分别为
),其潜在的实值为
(分别为
)。 运算符。算术运算在
中,如加法和乘法,后跟
,我们在上下文明确的情况下省略这一点。对于
和
,我们使用表示
(分别,SignExt
来表示一个数
使得
(分别,
)。我们使用
(分别,
)来表示
向右(分别,向左)移位
位,使得输入和输出具有相同的位宽。对于一个
位数
和
,截断-缩减操作,表示为
,定义为丢弃输入的较低
位并将输出返回为一个
位数。对于一个数组
和
,我们使用符号
和
分别表示该数组向右和向左旋转
步。 秘密共享。对于
，我们将
的（加法）秘密共享定义为抽取两个随机数
，使得
，并将其表示为 share
。对于数组变量和元组，此操作逐元素应用。当秘密共享由两个方持有时，例如
持有
而
持有
，我们将交换共享并将其相加的操作表示为
重建
，对于
。 2.2. 威胁模型 我们在预处理模型[30]、[41]、[58]、[66]中考虑 2 方安全计算(2PC)。在预处理阶段,生成独立于计算所有输入的相关随机数。这可以通过多种方式生成——通过可信交易商[16]、[19]、[30]、[41]、[58]、[66]、2PC 协议[29]、[68]或更高效的专门 2PC 协议[26]。在这项工作中,我们采用第一种方法。我们在标准模拟范式[20]、[29]、[46]中证明了我们协议的安全性,面对一个腐蚀其中一方的半诚实静态概率多项式时间(PPT)对手。为了完整性,我们在附录 K 中描述了详细的威胁模型。
我们的协议可以简单地扩展到"客户端-服务器"模型,其中
客户端对输入进行机密共享,将计算委托给这两个服务器
和
。在这种情况下,可以类似地定义安全性,并且我们可以获得对抗最多
个客户端与其中一个服务器勾结的半诚实安全性。 2.3. 功能机密共享和 DCFs 函数共享方案 (FSS) [17]、[18] 是一对算法 (Gen, Eval)。Gen 将函数
:
分割为两个函数
，Eval 以当事人标识符
、函数份额
为输入，对输入
评估
。FSS 方案的正确性要求
。安全性要求每个函数
隐藏
。 定义 1 (FSS:语法[17]、[18])。一个(2 方)FSS 方案是一对算法(Gen, Eval),满足:
Gen
是一个 PPT 密钥生成算法,给定
和
(函数
的描述)输出一对密钥
。我们假设
明确包含输入和输出组的描述
。
评估
是一种多项式时间评估算法,给定
(参与方索引)、
(定义
的密钥:
)和
(输入
),输出
(的值
)。
由 Gen 输出的密钥
称为 FSS 密钥。
或
的大小就是密钥大小,对应每个计算者需要存储的相关随机性。我们在附录 J 中正式定义了 FSS 方案的正确性和安全性属性。 分布式比较函数(DCFs)由 Boyle 等人[18]引入,并为特殊区间函数提供了一种 FSS 方案。
定义 2（DCF [16]、[18]）。一个特殊的间隔函数
，也称为比较函数，将
作为输入并输出
如果
为真，否则输出 0。这个函数
的相应 FSS 方案称为分布式比较函数。 我们所有的协议都使用 DCF 对于当
某些
的情况。下面,我们总结了使用[16]中优化构造的这种 DCF 的成本。 定理 1（DCF[16]的成本）。给定伪随机生成器
、
，存在
的 DCF，其密钥大小为
。在
中的
调用次数为
，在
中的
调用次数为
。 我们使用
和关键尺寸
来分别表示这种方案及其密钥大小。与前期工作 [16]、[30] 类似,我们设置
并使用 AES 的 4 次 128 位 CTR 模式输出实现所需的 PRG。接下来,正如在 [30] 中观察到的那样,在评估过程中只需进行 2 次 AES 调用,因为 [16] 中的评估算法只需要使用 4 个块中的 2 个,而 CTR 模式允许我们只生成所需的块。当我们需要一个输出长度较小的 DCF 时,我们使用 [18] 中的提前终止优化(移植到 DCF 上下文)并得到以下成本。 定理 2（小负载 DCF）。对于
、
和
，
的密钥大小为
。
中的 AES 调用次数为
， 评估
是
。当
时,
的密钥大小为
,
和评估
中的 AES 调用次数为 0。 2.4. 使用 FSS 的预处理安全双方计算 [16], 19]提出了一种使用 FSS 的半诚实静态安全 2PC 协议。考虑两个评估者想评估包含
门和
线的计算电路。该协议通过离线和在线两个阶段安全地评估该电路。 2.4.1. 离线阶段。对于计算电路中的每条线
，随机采样一个掩码
。对于每个门
，输入线
和输出线
，生成偏移函数的 FSS 密钥
，
，并向第
方提供
。对于第
方拥有的输入和输出线
，第
方学习相应的掩码
。
的值为
，由
方拥有。
方计算出遮蔽的线路值
，并将其发送给另一方。现在,从输入门开始,两方按拓扑顺序处理门,以接收遮蔽的输出线路值。要处理门
,其输入线路为
,输出线路为
,遮蔽的输入线路值为
,
方使用 Eval 与
和
来获得遮蔽输出线路值
的份额
,他们通过一轮通信重构以获得
。对于输出线路,他们从预处理阶段减去相应的遮蔽,以获得明文输出。 2.5. GPU 加速计算 图形处理单元(GPU)最初是为加速图形处理而设计的,但现已成为加速并行计算的关键平台,包括深度神经网络训练、数据分析和图处理。即使是中档的 NVIDIA A6000 GPU,也可以同时执行超过五千个线程。此外,GPU 中还有超过十万个线程随时准备就绪,以便快速替换执行停滞的线程。像 CUDA 这样的 GPU 编程语言[2]要求程序员将线程排列成层次结构,以保持 GPU 的大规模并行性可控。通常由 32 个 GPU 线程组成的"线程束"(warp)以锁步方式执行,是最小的可调度工作单元。一个线程块(threadblock)最多由 32 个线程束组成。GPU 内核通常会启动数百个线程块,形成数十万个线程的网格。
图形处理器(GPU)的体系结构反映了其编程层次。线程束在单指令多数据(SIMD)单元上同步执行。多个这样的 SIMD 单元被放置在流式多处理器(SM)上。GPU 会有数十个这样的 SM;例如 A6000 有 84 个 SM。一个线程块的所有线程都被调度在同一个 SM 上;来自不同线程块的线程可以在不同的 SM 上运行。 GPU 的内存子系统呈现类似的层次结构。GPU 上的内存通常支持超过
的带宽,但容量仅限于几十 GB。这些内存内容被缓存在两级硬件缓存中。GPU 还具有几个专门的软件管理的硬件缓存。例如,每个 SM 都有一个刮板(也称为共享内存),用于同一个线程块中的线程之间轻松共享数据。这是可能的,因为同一个线程块的所有线程都保证在同一个 SM 上执行。同样,SM 中的常量缓存是专门用于存储频繁使用的只读数据的。CUDA 中的每个线程也有数十个快速寄存器。由于同一个 warp 的线程总是作为一个组执行,CUDA 可以使用这些寄存器在 warp 的线程之间进行集体操作,以交换和/或减少数据。 最后,我们注意到 GPU 总是伴随 CPU 而存在。它通过 PCIe 互连连接到主机 CPU [10]。 GPU 加速程序首先在 CPU 上运行。在 CPU 上运行的程序部分会在 GPU 上分配/释放内存,并通过 PCIe 总线在 GPU 内存和 CPU 内存之间传输数据。 CPU 还负责在网格中启动所需数量的线程,从而使 GPU"内核"(用 CUDA/OpenCL 编写的 GPU 加速函数)在 GPU 上进行计算。
在 GPU 上加速 FSS 加速基于 FSS 的安全计算在 GPU 上是 Orca 的重要目标。为此,我们在两个关键方面取得了进展。(1)我们展示了如何利用 GPU 架构来实现合理的 FFS 基础计算加速。(2)我们发现从存储读取 FSS 密钥的时间可能会掩盖 GPU 加速带来的好处。我们提出了一种新的加密技术和系统改进的组合方法来限制密钥读取时间。接下来,我们将详细阐述 Orca 设计中的这两个方面。
3.1. 加速基于 FSS 的 GPU 计算 之前试图在 GPU 上加速基于 FSS 的协议[58]的工作仅在没有全面策略利用 GPU 架构特点的情况下观察到了适度的加速效果。在 Orca 中,我们采用以下三种关键技术来利用 GPU 的运算能力。
(1) 更快的 AES 计算 (AES)FSS 基础计算的一个关键原语是分布式比较函数或 DCF(第 4 节)。我们经验性地发现,计算 DCF 可能占用整体计算时间的大部分,例如,在 CNN3 的正向传播中,DCF 占据了大约
的整体计算时间。对
进行 DCF 评估需要
次 AES 调用(第 2.3 节)。 考虑执行 1000 万个 DCF 评估作为微基准测试,以量化我们在本小节讨论的不同优化的加速潜力。这个选择是由于几个模型每层需要执行数百万次 DCF。
表 1 经验性地捕捉了微基准的计算时间,从下面讨论的基线开始。
为了在 GPU 上加速 AES,我们首先使用 PyTorch 的 csprng 扩展[11],遵循之前的研究[58]、[60]。AES 需要反复查找预先计算的查找表[61]。通过分析使用 NVIDIA 的 Nsight 工具[8]进行 PyTorch 的 csprng 性能分析,我们发现它在访问查找表时经常会停顿。它将查找表保存在 GPU 每个 SM 的常量缓存中。虽然对常量缓存的访问很快,但只有当 GPU 线程在任何给定周期访问相同的地址时才适合[3]。否则,访问将被串行化,从而导致计算停滞。不幸的是,不同的线程访问不同的索引(因此,不同的地址)。
为了减少这种停顿,我们按照先前工作[61]中提出的策略,为 SM 中的每个 warp(这里是 32 个)复制一次查找表。此外,复制的表格被放置在 GPU 中每个 SM 的 scratchpad(共享内存)上。这是因为 scratchpad 是有独立 bank 的,与常量缓存不同。不同 bank 中的数据可以同时访问,不会造成停顿。因此,AES 查找表的副本被放置在 scratchpad 的不同 bank 中,缓解了由于访问 AES 查找表而导致的停顿。
表 1 中的第一个条目显示,PyTorch 的 csprng 扩展[11]的 AES 实现需要 3305 毫秒。当我们使用优化的 AES 实现("表中的 AES")时,它减少到 840 毫秒,给出了
的加速比。 (2) 针对高速缓存局部性优化数据布局(LAYOUT)
计算 DCF 需要评估者执行
链式伪随机生成器(2n AES)[16]、[30]。然而,评估者在将输出馈送到
伪随机生成器调用之前,会稍微修改
伪随机生成器调用的输出,并使用纠正字
[16]。因此,每个 DCF 密钥都有
个纠正字。我们注意到,内存中这些纠正字的布局会影响性能。 在并行化的 CPU 实现中,每个线程都会独立在一个 CPU 内核上计算一个 DCF。因此,将 DCF 计算的校正词连续地布置在内存中更有利于缓存局部性。然而,在 GPU 实现中,一个包含 32 个线程的线程束以同步的方式执行,每个线程都在计算一个 DCF。在同步执行中,线程束中的线程只有在完成 PRG 计算后才能继续计算。因此,与 CPU 实现不同,将给定 DCF 的所有校正词连续存放会导致缓存命中率较低。相反,对于 GPU 实现,必须考虑线程束中所有线程的缓存局部性。因此,我们将线程束中每个线程给定轮次的 PRG 校正词连续存放。换句话说,就是将线程束中所有线程(DCF 计算)给定(比如第四)轮次的 PRG 校正词连续存放在内存中,然后是下一轮次的 PRG 校正词,以此类推。
我们发现优化的校正词布局将 L1 缓存命中率从
提高到
。如图所示
天真的 AES
AES+布局 高级加密标准+布局+内存
时间
3305
840
716
523
加速
表 1：我们的优化处理 10M 个 DCFs 的加速效果
在表 1 中，这种优化(LAYOUT)进一步将计算 1000 万个 DCFs 的时间从 840 毫秒减少到 716 毫秒。(3)优化内存占用空间(MEM):基于 FSS 的协议降低了通信开销,但需要更大的密钥大小。包含密钥的文件通常存储在存储设备(如 SSD)上,在在线计算期间必须读取到内存中。从 SSD 读取大密钥可能会非常缓慢(参见第 3.2 节)。我们通过新的加密协议解决了这一挑战,大大减小了训练和推理中常见节点的密钥大小,详见第 4、5 和 6 节。密钥大小的减小不仅降低了 CPU 和 GPU 之间通过缓慢的 PCIe 互联网络移动数据的开销,也减少了对有限 GPU 内存的占用。减小密钥大小的一个关键技术是使用较小负载的 DCF(如 1 位而不是 64 位),并尽可能在较短的输入(如 40 位而不是 64 位)上进行比较。
然而,充分利用较小的 DCF 有效负载的全部优势并非易事。保持 1 位输出到标准数据类型(如字节)的简单实现会导致
内存膨胀。相反,在 Orca 中,一个 warp 的 32 个线程以同步的方式将它们的 1 位 DCF 输出写入到一个 32 位整数中。这避免了内存膨胀,但要求 warp 中的线程在不需要锁的情况下写入单个整数。在 GPU 上,锁的速度极慢[65]。OrcA 利用 CUDA 的 warp 同步原语来确保每个线程都可以写入输出而不会干扰 warp 中其他线程的写入。具体来说,它使用 CUDA 的__ballot_sync()和 _shfl_down_sync()用于在没有锁的情况下进行线程级同步数据交换的内置方法[13]。表 1 显示了由于此优化(MEM)而进一步加快了速度。执行一千万次 DCF 所需的时间降至 523 毫秒(
加速)，这是相比原始实现有
的改善。 3.2. 缩短阅读 FSS 密钥的时间 基于 FSS 的安全计算协议的一个关键优势是它限制了各方之间的通信。但是,它需要在执行在线计算时读取大量预生成的密钥。我们发现,一旦通过上述策略在 GPU 上加速计算,从存储(这里是 SSD)到 GPU 内存读取 FSS 密钥的时间成为瓶颈。我们采取了三管齐下的方法来解决这个瓶颈。
绕过操作系统页缓存:默认情况下,操作系统会在 CPU 的 DRAM 上缓存文件内容,希望文件数据可以在一段时间内被重复访问。但是,页缓存会在访问文件内容的关键路径上增加开销。由于 FSS 密钥只使用一次,没有重复利用的情况。因此,包含 FSS 密钥的文件无法从页缓存中获益。 页面缓存但支付开销。例如,我们训练的一个模型,来自[31]的 CNN3,在加密改进之前每次迭代需要 34.7 GB 的密钥。绕过操作系统的页面缓存,可将读取此密钥的时间从 13.4 秒缩短至 6.2 秒。
(2) 重叠关键读取与计算：为进一步减少关键读取时间的影响,我们将
训练迭代的计算与
迭代的关键读取重叠进行。这确保了整个关键读取时间不在关键路径上。 (3) 新型密码术来限制密钥大小:即使在上述优化措施之后,从 SSD 读取密钥的时间仍可能超过 GPU 计算时间,对于更大的网络而言更是如此。我们发现,仅当计算在 GPU 上得到良好加速(如在 Orca 中)时,密钥读取时间才成为瓶颈。对于 CPU 单独实现的 FSS 协议或第 3.1 节中没有进行优化的 GPU 实现,情况并非如此。
我们构建新的 FSS 协议来减少流行的非线性激活函数(如 ReLU 和最大池化)中的密钥大小,同时在量化训练时与截断相结合时也可以减少在线通信(第 45 节)。例如,我们针对截断后的 ReLU 实现了
的密钥大小减少。总的来说,在训练过程中,我们实现了高达
的密钥大小减少(表 8)。对于 CNN3,我们将每次迭代读取密钥的时间从 6.2 秒减少到 1.9 秒,并且现在可以完全重叠 2.4 秒的 GPU 计算时间(表 12)。 4.基础建筑块协议