The Future of Fully Homomorphic Encryption System: from a Storage I/O Perspective

基本信息

• 论文ID: 2511.04946
• 标题: The Future of Fully Homomorphic Encryption System: from a Storage I/O Perspective
• 作者: Lei Chen, Erci Xu, Yiming Sun, Shengyu Fan, Xianglong Deng, Guiming Shi, Guang Fan, Liang Kong, Yilan Zhu, Shoumeng Yan, Mingzhe Zhang (来自蚂蚁集团、上海交通大学、中国科学院大学、清华大学)
• 分类: cs.CR (密码学与安全), cs.DC (分布式计算)
• 发表时间: 2025年11月7日提交至arXiv
• 论文链接: https://arxiv.org/abs/2511.04946

摘要

全同态加密(FHE)允许在加密数据上直接执行计算，显著增强用户隐私保护。然而，部署FHE应用时面临的I/O挑战仍未得到充分研究。本文分析了存储I/O对FHE应用性能的影响，并总结了当前状态的关键经验教训。核心结果显示：存储I/O可使ASIC性能降低高达357×，GPU性能降低高达22×。

研究背景与动机

要解决的问题

本文聚焦于FHE系统部署中被严重忽视的存储I/O瓶颈问题。尽管现有研究在计算加速方面取得了显著进展（从CPU的10^5×慢降低到仅3×差距），但存储I/O的影响却鲜有研究。

问题的重要性

1. 云计算场景的现实需求：在多用户云环境中，每个用户拥有独立的密文和评估密钥(evaluation keys)，这些数据可能超出设备内存容量
2. 数据规模爆炸：FHE工作流会显著放大数据规模（如3KB图像→8MB明文多项式→16MB密文→5GB评估密钥）
3. 多用户并发：服务器需同时为多个用户提供服务，无法将所有用户数据保存在高带宽内存(HBM)中

现有方法的局限性

现有FHE加速器研究基于两个不切实际的假设：

1. 假设1：所有数据存储在HBM中
2. 假设2：从HBM到片上缓存的数据获取开销可通过静态最优预取策略、数据复用算法优化和大容量片上缓存(200-500 MiB)完全消除

这些假设在实际云计算部署中难以成立，因为：

• HBM容量有限（约数十GB）
• 多用户环境下无法为所有用户数据预留空间
• 大型模型（如13B参数LLM需26GB权重+1.6GB KV缓存）占用大量HBM
• 静态预取策略在多应用竞争资源时效果有限

研究动机

本文通过系统性实验量化评估I/O对FHE性能的实际影响，为FHE系统的实际部署提供指导。

核心贡献

1. 首次系统性研究：首次深入分析存储I/O对FHE加速器性能的影响，填补了该领域的研究空白
2. 全面的实验评估：使用SimGrid模拟器，在多种存储设备（HBM、DDR5、PCIe、RDMA）和网络配置下测试代表性FHE应用
3. 三个关键发现：
   • I/O访问显著降低FHE应用性能（ASIC最高357×，GPU最高22×）
   • 分布式计算不总能解决问题，某些情况下反而降低性能
   • I/O开销的影响因应用和FHE参数设置而异
4. 未来研究方向：提出locality-first调度、近数据处理、I/O友好应用实现等解决方案
5. 开放资源承诺：承诺公开traces和软件以促进后续研究

方法详解

任务定义

本研究旨在量化评估存储I/O对FHE应用端到端性能的影响，具体包括：

• 输入：不同存储层级（HBM、DDR、PCIe、RDMA）、不同网络配置（Ethernet、FastFabric）、不同应用（ResNet-20、HELR）
• 输出：归一化性能指标、执行时间分解（计算/I/O/通信）
• 约束：模拟真实云环境的冷启动和多用户场景

FHE工作流详解

1. Encode（编码）

• 将输入（如长度为n的向量）编码为N个系数的多项式（N/2 ≥ n）
• 使用中国剩余定理(CRT)将大整数分解为多个小整数（称为limb）
• 模数Q通常超过1000位
• 数据膨胀：3KB图像→8MB多项式（N=2^16个系数）

2. Encrypt（加密）

• 使用公钥将明文多项式加密为密文（包含两个多项式）
• 引入随机错误多项式保证RLWE安全性
• 数据膨胀：8MB明文→16MB密文

3. Compute（计算）

支持5种基本操作（见表1）：

• PAdd/HAdd：明文-密文/密文-密文加法，复杂度O(N)
• PMult/HMult：明文-密文/密文-密文乘法，使用NTT加速至O(N logN)
• HRot：循环移位操作，用于实现累积运算
• 关键特性：HMult和HRot需要访问评估密钥（ResNet-20需超过100个不同评估密钥，总计>5GB）

4. Decrypt & Decode（解密与解码）

加密和编码的逆过程

实验架构设计

加速器选择

1. Sharp：最先进的ASIC加速器（ISCA 2023）
   • 使用原论文的模拟器
   • 基线：理想性能（假设HBM足够大，启用所有优化）
2. TensorFHE：最先进的GPU加速方案（HPCA 2023）
   • 使用公开代码在NVIDIA A100 40GB GPU上运行
   • 基线：所有数据位于GPU内存的最优性能

存储层级

• HBM：1 TiB/s带宽
• DDR5-5600：358.4 GiB/s（8通道）
• PCIe5 ×16：64 GiB/s
• RDMA Disk：12.5 GiB/s

实验配置

• 冷启动：绕过设备缓存，模拟多用户云环境
• 仅评估吞吐量：FHE数据访问通常为数十至数百MB
• 分布式模拟：使用SimGrid模拟器，星型拓扑，支持Ethernet(400Gb/s)和FastFabric(300GiB/s)

应用负载

1. HELR：逻辑回归训练（MNIST数据集，1024图像/批次，训练32次迭代）
2. ResNet-20：CNN推理（CIFAR-10数据集，使用CKKS实现）

并行模型

采用residue-polynomial-level parallelism (rPLP)模型：

• 将大系数多项式表示为一系列小系数残差多项式
• 每个服务器计算独立的残差多项式
• 大部分操作可本地计算，减少通信

技术创新点

1. 首次量化I/O影响：打破了现有研究忽视I/O的局限，系统性评估真实部署场景
2. 多维度评估框架：结合存储层级、网络配置、加速器类型、应用特性的全面分析
3. 缓存命中率分析：揭示不同存储带宽下达到目标性能所需的缓存命中率（如80%性能需90.2%-99.9%命中率）
4. 分布式计算悖论：发现分布式计算在某些配置下反而降低性能，挑战了传统认知

实验设置

数据集

1. MNIST：用于HELR逻辑回归训练
   • 批次大小：1024图像
   • 训练迭代：32次
2. CIFAR-10：用于ResNet-20推理
   • 单张图像推理
   • 图像尺寸：32×32×3

评价指标

1. 归一化性能：相对于理想基线的性能比率
2. 执行时间：绝对执行时间（秒）
3. 时间分解：计算/I/O/通信开销占比
4. 加速比：分布式计算相对于单机的性能提升
5. I/O压力：每周期平均访问字节数

对比方法

• 基线1（Sharp）：假设HBM容量无限，启用预取、调度、数据复用优化
• 基线2（TensorFHE）：所有数据位于GPU内存的最优配置
• 对比维度：不同存储层级、不同网络、不同服务器数量（1/2/4/8/16/32）

实现细节

1. Sharp模拟器：
   • 多项式系数：1555位整数
   • 片上缓存：数百MB
   • I/O压力：平均3381字节/周期
2. TensorFHE配置：
   • ResNet-20：840位整数
   • HELR：1092位整数
   • I/O压力：平均101字节/周期
   • 评估密钥大小：Sharp的5.5×
3. SimGrid配置：
   • 拓扑：星型网络
   • 离线profiling所有GPU内核
   • 导入profiling结果模拟分布式执行

实验结果

主要结果

观察1：存储I/O显著降低性能（图4）

ASIC (Sharp)性能下降：

• HBM：ResNet-20降低2.63×，HELR降低5.5×（平均4.0×）
• DDR5：ResNet-20降低5.56×，HELR降低13.4×
• PCIe：ResNet-20降低26.5×，HELR降低70.6×
• RDMA：ResNet-20降低131.7×，HELR降低357.2×（最大降幅）

GPU (TensorFHE)性能下降：

• HBM：轻微下降1.2×
• DDR5：下降1.5×
• PCIe：下降3.8×
• RDMA：ResNet-20下降15.2×，HELR下降22×

根本原因：

• Sharp的I/O压力极高（3381字节/周期）vs. TensorFHE（101字节/周期）
• GPU处理能力相对较低，I/O压力相对缓和

观察2：缓存命中率要求（图5）

要达到80%基线性能，所需缓存命中率：

• ResNet-20：HBM 90.2%，DDR 96.2%，PCIe 99.3%，RDMA 99.9%
• HELR：要求更高，RDMA需接近100%命中率

启示：低带宽存储需要极高的缓存命中率，实际难以实现

分布式计算结果

观察3：分布式计算的双面性（图6）

TensorFHE表现：

• 32台服务器加速比：
  • Ethernet：6.6×（有效）
  • FastFabric：9.7×（更有效）

Sharp表现（复杂情况）： 使用Ethernet时32台服务器：

• HBM：性能下降6.08×（负优化！）
• DDR：性能下降2.74×（负优化！）
• PCIe：加速1.72×
• RDMA：加速5.78×

使用FastFabric时32台服务器：

• HBM：几乎无提升（0.94×）
• DDR：加速1.99×
• PCIe：加速6.42×
• RDMA：加速11.96×

根本原因（图7时间分解）： Sharp使用32台服务器（PCIe+Ethernet）：

• 计算开销：3.8%→0.3%（显著降低）
• I/O开销：96.2%→7.2%（显著降低）
• 通信开销：0%→92.5%（成为新瓶颈！）

TensorFHE使用32台服务器：

• 计算开销：40.1%（仍然显著，GPU批处理特性）
• I/O开销：18.1%
• 通信开销：41.8%

应用差异分析

观察4：不同应用的I/O敏感性

HELR vs. ResNet-20：

• HELR包含大量旋转操作（实现向量内积），需频繁访问评估密钥
• Sharp中HELR的I/O需求：5130字节/周期 vs. ResNet-20的1633字节/周期（3.1×）
• HELR性能下降更严重（如RDMA上357×）

不同FHE参数的影响：

• Sharp多项式大小：TensorFHE的1.85×（ResNet-20）和1.43×（HELR）
• 但TensorFHE评估密钥大小：Sharp的5.5×
• TensorFHE总I/O数据量：Sharp的2.8×（ResNet-20）和4.5×（HELR）

消融实验

虽然论文未进行传统意义的消融实验，但通过多维度对比实现了类似效果：

1. 存储层级消融：HBM→DDR→PCIe→RDMA，逐步降低带宽，观察性能变化
2. 网络配置消融：Ethernet vs. FastFabric，验证通信带宽影响
3. 服务器数量消融：1/2/4/8/16/32台，分析扩展性
4. 加速器类型对比：ASIC vs. GPU，揭示不同架构的I/O敏感性

案例分析

ResNet-20在Sharp上的典型场景（PCIe存储+Ethernet网络）：

• 单机：执行时间约3.8秒，I/O占96.2%
• 32台服务器：执行时间约2.2秒，通信占92.5%
• 性能提升有限：仅1.72×加速，远低于理论32×

HELR在RDMA存储上的极端情况：

• Sharp性能下降357×，几乎不可用
• 根本原因：低带宽(12.5 GiB/s) + 高I/O需求(5130字节/周期)

实验发现

1. I/O瓶颈普遍存在：即使HBM也会导致4×性能下降
2. ASIC更敏感：由于极高的处理能力，I/O成为严重瓶颈
3. 分布式非万能药：在高带宽存储+低带宽网络时，分布式反而降低性能
4. 应用特性关键：旋转密集型应用（如HELR）受I/O影响更大
5. 参数选择重要：不同FHE参数导致不同的I/O模式和性能表现

相关工作

FHE计算加速

论文回顾了FHE加速器的发展历程（图1）：

• CPU基线：比明文计算慢10^5×
• 早期加速器（2021-2022）：
  • F1+ (MICRO'21)
  • BTS (ISCA'22)
  • CraterLake (ISCA'22)
  • ARK (MICRO'22)
• 近期进展（2023-2024）：
  • Sharp (ISCA'23)：仅3×差距
  • TensorFHE (HPCA'23)
  • Trinity (MICRO'24)
  • HEAP (HPCA'24)

现有工作的假设

大多数加速器研究假设：

1. 数据位置：所有数据在HBM中
2. 优化技术：
   • 静态最优预取策略
   • 数据复用算法优化（如ARK的旋转优化）
   • 大容量片上缓存（200-500 MiB）

本文与相关工作的关系

• ARK 30：算法优化仅适用于特定计算模式（如ResNet-20的相同步长旋转），不适用于HELR和排序
• Sharp 29：报告理想性能，未考虑实际I/O约束
• TensorFHE 21：GPU实现，相对I/O压力较小但仍受影响

本文优势

1. 填补空白：首次系统研究I/O影响
2. 真实场景：考虑多用户云环境
3. 量化分析：提供具体性能数据
4. 全面评估：覆盖多种配置和应用

结论与讨论

主要结论

1. I/O是FHE部署的关键瓶颈：存储I/O可使ASIC性能降低高达357×，GPU降低22×，远超计算优化带来的收益
2. 现有假设不切实际：假设所有数据在HBM且开销可消除的假设在云环境中难以成立
3. 分布式计算非银弹：在某些配置下（高带宽存储+低带宽网络），分布式反而降低性能
4. 应用和参数敏感：不同应用和FHE参数选择导致显著不同的I/O行为

局限性

1. 模拟实验：使用SimGrid模拟器而非真实硬件，可能存在精度差异
2. 应用覆盖有限：仅测试ResNet-20和HELR两个应用
3. 单一FHE方案：仅评估CKKS方案，未涵盖BGV、BFV、TFHE等
4. 静态工作负载：未考虑动态多用户负载变化
5. 网络模型简化：使用星型拓扑，未考虑更复杂的网络拓扑
6. 缺乏真实部署验证：未在实际云环境中验证发现

未来方向

论文提出三个研究方向：

1. Locality-first调度

• 问题：分布式计算并非总是有益
• 方案：
  • 为用户分配专用服务器以减少I/O访问
  • 研究用户访问模式
  • 流水线化访问以隐藏上下文切换开销
• 挑战：平衡资源效率与性能

2. 近数据处理（最有前景）

• 动机：评估密钥仅在特定操作（HRot、HMult）中访问
• 方案：
  • 将FHE计算组件集成到存储设备
  • 设计专用计算单元处理特定操作
  • 在存储端执行I/O密集型计算
• 优势：显著减少主机与存储间的I/O开销

3. I/O友好应用实现

• 观察：FHE加法不需要访问评估密钥
• 方案：
  • 重构程序以利用I/O特性
  • 可能增加计算开销但减少I/O
  • 结合快速增长的FHE加速器处理能力
• 示例：用多次加法替代部分乘法/旋转操作

深度评价

优点

1. 研究视角独特且重要

• 填补关键空白：首次系统性研究FHE的I/O瓶颈，打破了计算加速研究的单一视角
• 实际意义重大：针对云部署的真实场景，而非理想化实验室环境
• 时机恰当：在FHE计算加速取得显著进展后，及时指出下一个关键挑战

2. 实验设计全面严谨

• 多维度评估：存储层级×网络配置×加速器类型×应用×服务器数量
• 真实配置：冷启动、绕过缓存，模拟多用户云环境
• 对比充分：覆盖从HBM到RDMA的完整存储层次
• 量化精确：提供具体性能数据（如357×、22×）而非模糊描述

3. 发现具有洞察力

• 反直觉结论：分布式计算可能降低性能，挑战传统认知
• 缓存命中率分析：揭示99.9%命中率要求的不现实性
• 时间分解：清晰展示瓶颈从I/O转移到通信的过程
• 应用差异：深入分析不同应用和参数的影响机制

4. 写作清晰结构完整

• 背景介绍充分：详细解释FHE工作流和数据膨胀
• 图表丰富：11个图表有效支撑论点
• 逻辑严密：从问题→实验→发现→方向，层次分明
• 可复现承诺：承诺公开traces和软件

不足

1. 实验局限性

• 模拟而非实测：SimGrid模拟可能无法完全捕捉真实硬件行为（如缓存一致性、调度延迟）
• 应用覆盖窄：仅两个应用，难以全面代表FHE应用生态
• 单一FHE方案：CKKS针对浮点数，未评估整数方案（BGV、BFV）或二进制方案（TFHE、FHEW）
• 静态负载：未考虑用户请求的动态到达、负载波动、优先级等

2. 分析深度可提升

• 缺乏理论模型：未建立I/O开销与系统参数的数学模型
• 预取策略未深入：未详细分析不同预取策略的效果
• 缓存管理简化：未考虑复杂的缓存替换策略和多级缓存
• 功耗分析缺失：I/O开销对能耗的影响未涉及

3. 解决方案初步

• 未来方向缺乏细节：三个方向仅概念性描述，缺乏具体设计
• 无原型验证：近数据处理等方案未实现原型验证可行性
• trade-off分析不足：各方案的成本、复杂度、适用场景未充分讨论

4. 实验设置问题

• Sharp模拟器依赖：依赖原论文模拟器，无法验证其准确性
• 网络模型简化：星型拓扑不代表真实数据中心网络（如Clos、Fat-tree）
• 安全性未考虑：多用户间的隔离、侧信道攻击等安全问题未涉及

影响力

对领域的贡献

• 范式转变：将FHE研究焦点从纯计算扩展到系统层面
• 警示作用：提醒研究者注意I/O瓶颈，避免过度优化计算
• 基准数据：提供不同配置下的性能数据，可作为后续研究参考
• 激发研究：三个未来方向可能催生一系列后续工作

实用价值

• 部署指导：为云服务商部署FHE提供量化依据
• 架构设计：指导下一代FHE加速器的I/O子系统设计
• 参数选择：帮助应用开发者根据I/O特性选择FHE参数
• 成本评估：为FHE云服务定价提供性能预测

可复现性

• 承诺开源：traces和软件将公开，有利于验证和扩展
• 详细配置：实验设置描述充分，可重现
• 公开代码依赖：TensorFHE使用公开实现
• 但存在挑战：Sharp模拟器未公开，完全复现困难

适用场景

适合的场景

1. 云FHE服务规划：云服务商评估FHE服务可行性和资源需求
2. FHE加速器设计：硬件设计者平衡计算能力与I/O子系统
3. 应用优化：FHE应用开发者根据I/O特性优化算法
4. 系统研究：存储系统研究者探索FHE的特殊I/O模式

不太适合的场景

1. 单用户场景：本文关注多用户云环境，单用户可能不受I/O限制
2. 小规模数据：数据完全fit in HBM时，I/O影响较小
3. 非CKKS方案：其他FHE方案可能有不同I/O特性
4. 边缘计算：边缘设备的资源约束和使用模式与云不同

潜在扩展方向

1. 真实硬件验证：在真实云环境中部署并测量
2. 更多FHE方案：扩展到BGV、BFV、TFHE等
3. 更多应用：数据库查询、基因组分析、金融计算等
4. 动态负载：模拟真实用户请求到达模式
5. 安全性分析：I/O优化对侧信道攻击的影响
6. 原型实现：实现近数据处理的FHE存储设备原型
7. 理论建模：建立I/O开销的性能模型
8. 调度算法：设计locality-aware的FHE任务调度器

参考文献

论文引用了46篇参考文献，关键文献包括：

FHE加速器

• 29 Sharp (ISCA'23)：最先进ASIC加速器，本文主要对比对象
• 21 TensorFHE (HPCA'23)：GPU加速方案
• 30 ARK (MICRO'22)：提出数据复用优化
• 40 CraterLake (ISCA'22)：早期ASIC设计

FHE方案

• 15 CKKS：支持浮点数的FHE方案，本文采用
• 12 BGV：整数FHE方案
• 11,20 BFV：另一整数方案
• 16 TFHE：二进制FHE方案

应用

• 24 HELR：逻辑回归训练
• 34 ResNet-20：CNN推理

系统工具

• 13 SimGrid：分布式系统模拟器

总体评价：这是一篇视角独特、实验扎实、发现重要的系统研究论文。它填补了FHE研究中I/O瓶颈这一关键空白，为FHE的实际部署提供了重要警示和指导。尽管存在模拟实验、应用覆盖有限等局限，但其核心贡献——揭示I/O瓶颈的严重性——具有重要学术和实用价值。论文提出的三个未来方向，特别是近数据处理，可能引领FHE系统研究的新方向。对于云服务商、硬件设计者和FHE应用开发者而言，这是一篇必读文献。