[Paper] 通过主动存储系统在计算连续体上卸载人工智能工作负载

发布: (2025年12月2日 GMT+8 19:04)
6 min read
原文: arXiv

Source: arXiv - 2512.02646v1

概览

本文研究了 active storage systems——能够运行代码的存储设备——如何用于在整个 computing continuum(边缘、雾层和云)上分布 AI 训练和推理任务。通过将工作负载的部分直接移动到数据所在的位置,作者展示了在内存使用、训练速度和整体资源效率方面的可衡量提升,同时保持了对数据科学家的低门槛。

关键贡献

  • Continuum‑aware 软件架构,能够在异构设备(边缘、雾层、云)之间调度 AI 工作负载的放置。
  • 将 active storage(dataClay)与流行的 Python AI 库(如 PyTorch、TensorFlow)集成,实现“compute‑in‑storage”,无需重写模型。
  • 全面评估了内存占用、存储开销、训练时间和准确率,使用了一组代表性的 AI 任务(图像分类、时间序列预测)。
  • 开源原型,展示了开发者将流水线部分卸载到存储节点的实用、低成本路径。
  • 权衡分析,量化了何时 active‑storage 卸载有利,何时传统云执行仍更可取。

方法论

  1. 中间件层设计——一个轻量的 Python 包装器,拦截数据访问调用,并根据策略(如数据大小、设备能力)决定在本地、邻近存储节点或云端执行计算。
  2. Active storage 平台(dataClay)——作者在 dataClay 上扩展了自定义 “service objects”,将 AI 原语(张量操作、mini‑batch 训练循环)公开为远程可调用方法。
  3. 基准套件——选取三种常见 AI 工作负载(CIFAR‑10 上的 ResNet‑18、合成传感器流上的 LSTM、以及一个小型 GNN),在三种配置下运行:(a) 纯云,(b) 仅边缘,(c) 带有 active‑storage 的连续体。
  4. 指标收集——记录每次运行的内存消耗(计算节点峰值 RAM)、存储 I/O 量、实际训练时间以及最终模型准确率。
  5. 策略评估——将简单启发式(如 “如果输入批次 > 64 MiB 则卸载”)与更复杂的成本模型(考虑网络延迟和存储 CPU 负载)进行比较。

结果与发现

ConfigurationPeak RAM (MiB)Training Time (min)Storage I/O (GB)Accuracy
Cloud only3,2004512.892.1 %
Edge only1,800689.591.8 %
Active‑Storage Continuum1,200328.392.0 %
  • 内存降低:将数据预处理和早期卷积层卸载到存储,可将计算节点所需的 RAM 减少约 60 %。
  • 训练速度提升:整体壁钟时间提升约 30 %,因为存储节点在原位处理数据,消除了重复的网络传输。
  • 准确率影响:几乎没有下降(<0.3 %),证明迁移计算不会削弱模型质量。
  • 可扩展性:增加存储节点数量可线性降低训练时间,但在超过 4 台节点后,网络争用抵消了收益。

实际意义

  • 对 ML 工程师:只需使用提供的 Python SDK 包装数据加载器,即可在保持现有 PyTorch/TensorFlow 代码库的前提下获得 active‑storage 效益,无需重写模型。
  • 面向边缘的部署:内存受限的设备(如 IoT 网关)现在可以通过将重型张量操作委托给附近的 NVMe‑based 存储设备(这些设备公开计算内核)来运行更大的模型。
  • 成本优化:减少数据移动可降低带宽费用,并减轻云计算实例的压力,使 “按需付费” 的 AI 流水线更具经济性。
  • 快速原型:由于架构基于主流 Python 库,数据科学家可以在不担心底层硬件拓扑的情况下尝试新算法。
  • 供应商相关性:嵌入 GPU/TPU 或 FPGA 加速器的存储供应商可以通过提供 “AI‑ready” API 层来实现产品差异化,开辟新的收入渠道。

局限性与未来工作

  • 硬件依赖:收益依赖于能够提供足够计算资源的存储节点(如具备 SIMD 的 CPU、可选的 GPU)。低端 SATA 硬盘无法获得相同的优势。
  • 调度简易性:当前策略引擎使用启发式方法;更复杂的调度器(基于强化学习或 QoS 感知)可能更好地处理动态工作负载。
  • 安全与隔离:在存储内部执行用户代码会引发沙箱和多租户隔离的担忧,原型并未完全解决此问题。
  • 更广泛的工作负载:实验聚焦于相对较小的模型;扩展到大规模 transformer 类网络可能会暴露新的瓶颈(如存储 CPU 的内存带宽)。
  • 标准化:作者建议扩展新兴标准(如 OpenCAPI、NVMe‑OF)以正式化 compute‑in‑storage API,这是他们计划进一步探索的方向。

作者

  • Alex Barceló
  • Sebastián A. Cajas Ordoñez
  • Jaydeep Samanta
  • Andrés L. Suárez-Cetrulo
  • Romila Ghosh
  • Ricardo Simón Carbajo
  • Anna Queralt

论文信息

  • arXiv ID: 2512.02646v1
  • Categories: cs.DC
  • Published: December 2, 2025
  • PDF: Download PDF
Back to Blog

相关文章

阅读更多 »