[Paper] 인공지능 워크로드를 액티브 스토리지 시스템을 통해 컴퓨팅 연속체에 오프로드

Source: arXiv - 2512.02646v1

Overview

이 논문은 액티브 스토리지 시스템—코드를 실행할 수 있는 스토리지 장치—을 활용해 AI 학습 및 추론 작업을 전체 컴퓨팅 연속체(엣지, 포그, 클라우드)에 분산시키는 방법을 조사한다. 데이터를 보관하고 있는 위치에서 직접 워크로드의 일부를 수행함으로써, 저자들은 메모리 사용량, 학습 속도, 전체 자원 효율성에서 측정 가능한 이점을 보여주며, 데이터 과학자들의 진입 장벽을 낮게 유지한다.

Key Contributions

• 연속체 인식 소프트웨어 아키텍처: 이기종 장치(엣지, 포그, 클라우드) 전반에 걸쳐 AI 워크로드 배치를 조정한다.
• 액티브 스토리지(dataClay)와 인기 Python AI 라이브러리(PyTorch, TensorFlow 등)의 통합: 모델을 다시 작성하지 않고도 “스토리지 내 컴퓨팅”을 가능하게 한다.
• 포괄적인 평가: 메모리 발자국, 스토리지 오버헤드, 학습 시간, 정확도를 대표적인 AI 작업(이미지 분류, 시계열 예측) 세트에 대해 측정한다.
• 오픈소스 프로토타입: 개발자가 파이프라인의 일부를 스토리지 노드에 오프로드할 수 있는 실용적이고 낮은 진입 장벽의 경로를 시연한다.
• 트레이드오프 분석: 액티브 스토리지 오프로드가 유리한 경우와 전통적인 클라우드 실행이 여전히 선호되는 경우를 정량화한다.

Methodology

1. 미들웨어 레이어 설계 – 데이터 접근 호출을 가로채고 정책(예: 데이터 크기, 장치 성능)에 따라 로컬, 인근 스토리지 노드, 혹은 클라우드에서 연산을 실행할지 결정하는 얇은 Python 래퍼.
2. 액티브 스토리지 플랫폼(dataClay) – 저자들은 dataClay를 확장하여 AI 기본 연산(텐서 연산, 미니배치 학습 루프)을 원격 호출 가능한 메서드로 노출하는 맞춤형 “서비스 객체”를 제공한다.
3. 벤치마크 스위트 – 세 가지 일반적인 AI 워크로드(ResNet‑18 on CIFAR‑10, 합성 센서 스트림에 대한 LSTM, 작은 GNN)를 선택하고 세 가지 구성(a) 순수 클라우드, (b) 엣지 전용, (c) 액티브 스토리지‑보강 연속체)에서 실행한다.
4. 메트릭 수집 – 각 실행에 대해 메모리 사용량(컴퓨트 노드의 피크 RAM), 스토리지 I/O 양, 실제 학습 시간, 최종 모델 정확도를 기록한다.
5. 정책 평가 – 간단한 휴리스틱(예: “입력 배치 > 64 MiB이면 오프로드”)을 네트워크 지연 및 스토리지 CPU 부하를 고려한 보다 정교한 비용 모델과 비교한다.

Results & Findings

• 메모리 감소: 데이터 전처리와 초기 레이어 컨볼루션을 스토리지에 오프로드함으로써 컴퓨트 노드에서 필요한 RAM이 약 60 % 감소한다.
• 학습 속도: 스토리지 노드가 데이터를 제자리에서 처리해 반복적인 네트워크 전송을 없애므로 전체 실시간이 약 30 % 개선된다.
• 정확도 영향: 감소폭이 0.3 % 미만으로 미미해, 연산 위치 이동이 모델 품질을 저하시키지 않음을 확인한다.
• 확장성: 스토리지 노드를 추가하면 학습 시간이 선형적으로 감소하지만, 4대 이상에서는 네트워크 혼잡이 이득을 상쇄한다.

Practical Implications

• ML 엔지니어를 위해: 기존 PyTorch/TensorFlow 코드베이스를 그대로 유지하면서 제공된 Python SDK로 데이터 로더만 래핑하면 액티브 스토리지의 이점을 얻을 수 있다. 모델을 다시 작성할 필요가 없다.
• 엣지 중심 배포: 제한된 RAM을 가진 장치(예: IoT 게이트웨이)도 인근 NVMe 기반 스토리지 어플라이언스에 컴퓨트 커널을 노출시켜 무거운 텐서 연산을 위임함으로써 더 큰 모델을 실행할 수 있다.
• 비용 최적화: 데이터 이동 감소는 대역폭 비용을 낮추고 클라우드 컴퓨트 인스턴스에 대한 압력을 완화해 “pay‑as‑you‑go” AI 파이프라인을 보다 경제적으로 만든다.
• 빠른 프로토타이핑: 아키텍처가 주류 Python 라이브러리를 기반으로 하므로 데이터 과학자는 하드웨어 토폴로지를 신경 쓰지 않고 새로운 알고리즘을 실험할 수 있다.
• 벤더 관련성: GPU/TPU 또는 FPGA 가속기를 내장한 스토리지 벤더는 “AI‑ready” API 레이어를 제공함으로써 제품 차별화와 새로운 수익원을 창출할 수 있다.

Limitations & Future Work

• 하드웨어 의존성: 이득은 충분한 컴퓨트 자원을 제공하는 스토리지 노드(예: SIMD 지원 CPU, 선택적 GPU)에 의존한다. 저가 SATA 드라이브는 동일한 효과를 기대하기 어렵다.
• 스케줄링 단순성: 현재 정책 엔진은 휴리스틱에 기반하므로, 강화 학습 기반 혹은 QoS‑aware와 같은 보다 정교한 스케줄러가 동적 워크로드를 더 잘 처리할 수 있다.
• 보안 및 격리: 스토리지 내부에서 사용자 코드를 실행하면 샌드박싱 및 멀티‑테넌트 격리에 대한 우려가 발생하는데, 프로토타입은 이를 완전히 해결하지 못한다.
• 다양한 워크로드: 실험은 비교적 작은 모델에 초점을 맞추었으며, 대규모 트랜스포머와 같은 모델으로 확장하면 새로운 병목(예: 스토리지 CPU의 메모리 대역폭) 현상이 드러날 수 있다.
• 표준화: 저자들은 떠오르는 표준(OpenCAPI, NVMe‑OF 등)을 확장해 컴퓨트‑인‑스토리지 API를 공식화할 것을 제안하며, 이를 향후 연구 방향으로 삼고 있다.

Authors

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

Paper Information

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