[Paper] STELLAR: 고성능 병렬 파일 시스템을 위한 LLM 자율 추론 활용 스토리지 튜닝 엔진

발행: (2026년 2월 27일 오전 02:01 GMT+9)
9 분 소요
원문: arXiv

Source: arXiv - 2602.23220v1

Overview

이 논문은 STELLAR를 소개한다. STELLAR는 대형 언어 모델(LLM)을 활용하여 고성능 병렬 파일 시스템의 구성을 최적화하는 자율 튜닝 엔진이다. 전통적으로 수동적이고 시행착오가 필요한 I/O 튜닝 과정을 빠른 데이터 기반 루프로 전환함으로써, STELLAR는 몇 번의 실행만으로도 거의 최적에 가까운 설정을 찾아낼 수 있다. 이를 통해 시스템에 대한 깊은 전문 지식이 부족한 과학자와 엔지니어도 스토리지 성능 튜닝을 실용적으로 수행할 수 있다.

주요 기여

  • LLM‑driven end‑to‑end tuning pipeline: 문서에서 튜닝 가능한 파라미터를 추출하고, I/O 트레이스를 해석하며, 구성값을 반복적으로 개선합니다.
  • Retrieval‑augmented generation (RAG) + tool‑use 아키텍처: 실제 시스템 데이터를 기반으로 LLM 추론을 정착시켜 환상을 크게 감소시킵니다.
  • Multi‑agent design: 추출, 분석, 전략 선택을 각각 전문화한 별도 에이전트를 두어 의사결정의 안정성을 높입니다.
  • Empirical evidence: STELLAR가 보지 못한 워크로드에 대해 최초 5번의 튜닝 시도만으로도 거의 최적에 가까운 성능을 달성함을 입증했습니다. 이는 수천 번의 반복이 필요할 수 있는 기존 자동 튜너와 대비됩니다.
  • Knowledge‑base feedback loop: 성공적인 튜닝 패턴을 캡처해 향후 애플리케이션에 재사용함으로써 각 실행을 시스템의 학습 경험으로 전환합니다.

방법론

  1. Parameter Extraction – LLM은 병렬 파일 시스템 매뉴얼(예: Lustre, GPFS)을 읽고 모든 설정 가능한 파라미터(스트라이프 크기, I/O 스케줄러, 캐시 정책 등)의 구조화된 목록을 작성합니다.
  2. Trace Analysis – 애플리케이션의 I/O 트레이스 로그를 LLM에 입력하면, 워크로드 특성(읽기/쓰기 비율, 접근 패턴, 동시성 수준)을 식별합니다.
  3. Initial Strategy Selection – 추출된 파라미터와 트레이스 인사이트를 활용하여 LLM은 소수의 유망한 구성(보통 하나 또는 두 개)을 제안합니다.
  4. Execution & Feedback – 시스템은 선택된 설정으로 실제 클러스터에서 애플리케이션을 실행하고, 처리량/지연 시간을 측정하여 결과를 기록합니다.
  5. Iterative Refinement – LLM은 성능 피드백을 기반으로 논리적 추론을 수행하고 구성을 조정한 뒤, 3‑4단계를 반복합니다.
  6. Knowledge Consolidation – 수렴 후, 시스템은 튜닝 과정을 재사용 가능한 지식 항목으로 요약합니다(예: “쓰기‑중심, 소형 파일 워크로드에서는 스트라이프 크기 = 64 KB가 최적”).

파이프라인은 멀티‑에이전트 프레임워크에 의해 조정됩니다:

  • Extractor Agent는 문서 파싱을 담당합니다.
  • Analyzer Agent는 트레이스를 해석합니다.
  • Planner Agent는 구성을 제안합니다.
  • Executor Agent는 워크로드를 실행하고 메트릭을 보고합니다.

RAG는 매뉴얼이나 기존 튜닝 로그에서 관련 스니펫을 끌어오는 데 지속적으로 사용되어, LLM의 추론이 사실 데이터에 기반하도록 합니다.

결과 및 발견

  • 수렴 속도: 30개의 벤치마크 애플리케이션 중 90 %에서 STELLAR는 전역 최적 처리량(전체 탐색으로 결정)과 ± 3 % 이내인 구성을 5번의 반복 안에 식별했습니다.
  • 탐색 공간 감소: LLM‑기반 접근법은 단순 그리드 또는 무작위 탐색에 비해 효과적인 탐색 공간을 > 99 % 줄였습니다.
  • 보이지 않는 워크로드에 대한 견고성: 학습 데이터에 포함되지 않은 애플리케이션에도 시스템이 트레이스 패턴을 기반으로 추론함으로써 잘 일반화되었습니다.
  • 절제 연구: RAG 또는 다중‑에이전트 협조를 제거하면 평균 반복 횟수가 5에서 27으로 증가했으며, 이는 기반 및 전문화의 중요성을 확인시켜 줍니다.

Practical Implications

  • 시스템 관리자용: STELLAR는 새로운 작업이 들어올 때마다 저장소 설정을 지속적으로 최적화하는 “플러그‑앤‑플레이” 서비스로 배포될 수 있어, 수동 튜닝 전문 지식이 필요할 경우를 줄인다.
  • 데이터 집약 파이프라인 개발자용: 팀은 저수준 I/O 조정보다 알고리즘 작업에 집중할 수 있으며, 튜너가 데이터 크기나 접근 패턴 변화에 자동으로 적응한다.
  • 클라우드 및 HPC 제공업체용: 작업 제출 포털에 STELLAR를 내장하면 전체 클러스터 활용도가 향상되고, 하드웨어 업그레이드 없이 추가 I/O 성능을 끌어내어 컴퓨팅 시간당 비용을 낮출 수 있다.
  • 다른 최적화 분야용: 논문의 아키텍처(LLM + RAG + 멀티‑에이전트 루프)는 컴파일러, 네트워크 스택, 혹은 각 평가가 비용이 큰 머신러닝 파이프라인의 하이퍼파라미터 선택 등 튜닝에 재사용 가능하다.

제한 사항 및 향후 작업

  • 고품질 문서에 대한 의존성: 매뉴얼이 부족하거나 오래된 경우, 파라미터 추출이 중요한 조정을 놓칠 수 있습니다.
  • 실제 시스템 실행의 확장성: 반복 횟수가 적더라도 각 반복마다 전체 애플리케이션 실행이 필요하므로, 매우 긴 작업에서는 비용이 많이 들 수 있습니다.
  • 환각 위험: RAG와 다중 에이전트 검증으로 완화되지만, 특히 드문 파라미터에 대해 가끔 부정확한 LLM 제안이 관찰되었습니다.
  • 향후 방향에는:
    1. 시뮬레이션 기반 프록시를 통합하여 구성 평가 속도를 높이기.
    2. 지식 베이스를 크로스‑클러스터 환경으로 확장하기.
    3. 환각을 더욱 줄이기 위해 도메인 특화 파인‑튜닝 LLM 탐색하기.

저자

  • Chris Egersdoerfer
  • Philip Carns
  • Shane Snyder
  • Robert Ross
  • Dong Dai

논문 정보

  • arXiv ID: 2602.23220v1
  • Categories: cs.DC
  • Published: 2026년 2월 26일
  • PDF: PDF 다운로드
0 조회
Back to Blog

관련 글

더 보기 »