스토리지와 데이터 파이프라인

학습 측 — 데이터를 대는 일과 상태를 남기는 일

① 데이터 로딩

GPU가 초당 처리할 수 있는 샘플 수를 스토리지가 못 따라오면 GPU는 굶는다. 특히 이미지·비디오가 섞인 멀티모달 학습에서는 디코딩 부하까지 겹쳐 CPU가 먼저 막힌다(3장).

• 미리 읽기(prefetch) — 다음 배치를 현재 스텝 계산 중에 미리 가져온다. 가장 기본이고 효과가 크다.
• 병렬 파일시스템 — Lustre, VAST, WEKA 등. 수천 노드가 동시에 읽어도 버티게 한다.
• GPUDirect Storage — 스토리지에서 CPU 메모리를 거치지 않고 GPU 메모리로 직접 DMA. 3장에서 본 PCIe 왕복을 한 번 없앤다.
• DPU 오프로드 — 파일시스템 클라이언트와 네트워크 처리를 DPU가 대신한다. 호스트 CPU가 데이터 준비에 집중할 수 있게 된다.

② 체크포인트 — 주기적으로 찾아오는 폭주

체크포인트가 중요한 진짜 이유는 장애 때문이다. 수만 GPU가 몇 주 도는 잡에서는 어딘가 반드시 고장 난다. 체크포인트 간격이 길면 장애 시 되돌아가는 시간이 길어지고, 짧으면 쓰기 오버헤드가 커진다. 이 균형이 12장 Goodput의 큰 몫이다.

추론 측 — KV 캐시라는 새로운 스토리지 문제

추론에서 스토리지는 전통적인 「파일을 읽고 쓰는」 문제가 아니다. KV 캐시를 어디에 둘 것인가의 문제다.

KV 캐시가 커지는 속도

컨텍스트가 길어질수록 KV 캐시는 선형으로 커진다. 동시 사용자가 많으면 사용자 수만큼 또 곱해진다. 그래서 긴 컨텍스트 · 다수 동시접속 서비스에서는 모델 가중치보다 KV 캐시가 HBM을 더 많이 잡아먹는 상황이 흔하다.

여기서 4장의 질문으로 돌아가 보자. 왜 스토리지 랙이 따로 서는가? 체크포인트 폭주와 KV 캐시 계층화는 둘 다 「대량의 데이터를 빠르게 옮기는 일」이고, GPU 노드에 맡기면 GPU가 그 일에 발목을 잡힌다. 떼어내는 것이 이득이다.

스토리지 계층을 실제로 어떻게 구성하는가

「병렬 파일시스템을 쓴다」는 한 줄로 끝나지 않는다. 학습 데이터, 체크포인트, 로그, 모델 산출물은 요구가 전부 다르고, 각각을 어느 계층에 둘지가 설계다.

그리고 가장 아래 계층 — 테이프는 아직 살아 있다

학습 데이터 원본과 오래된 체크포인트는 자주 읽지 않지만 버릴 수도 없다. 이런 데이터는 여전히 테이프에 보관하는 것이 압도적으로 싸다.

체크포인트 전략 — 얼마나 자주, 어떻게

체크포인트는 보험이다. 보험료(쓰기 오버헤드)와 보장 범위(장애 시 잃는 시간)의 균형을 잡는 일이다.

최적 간격을 구하는 방법

잃는 시간의 기댓값 = 체크포인트 쓰기 비용 + 장애 시 되감기 비용

  쓰기 비용     = (전체 시간 ÷ 간격) × 1회 쓰기 시간
  되감기 비용   = (전체 시간 ÷ 평균무고장시간) × (간격 ÷ 2)
                   ↑ 장애는 간격 중간쯤에서 난다고 보면 평균 절반을 잃는다

  → 두 항의 합을 최소로 하는 간격 ≈ √(2 × 1회쓰기시간 × 평균무고장시간)

예를 들어 1회 쓰기가 2분이고 클러스터의 평균 무고장 시간이 6시간이라면, 최적 간격은 대략 √(2×2×360) ≈ 38분 이 된다. 클러스터가 커질수록 평균 무고장 시간이 짧아지므로 체크포인트를 더 자주 해야 한다 — 수만 GPU 규모에서 이 항목이 Goodput의 큰 몫을 차지하는 이유다.

쓰기 비용을 줄이는 방법들

실습 — KV 캐시 오프로딩의 대가 재기

# vLLM 예시 — 오프로딩 없이
vllm serve <model> --max-model-len 8192

# 컨텍스트 길이를 늘려 가며 측정
#   2K / 8K / 32K / 128K (장비가 허용하는 범위에서)
# 기록: TTFT, TPOT, 최대 동시 요청 수, GPU 메모리 사용량

참고 자료

• NVIDIA GPUDirect Storage 문서
• NVIDIA Dynamo 문서 — NIXL 전송 계층
• vLLM · SGLang 문서 — prefix caching, CPU offloading
• Lustre · VAST · WEKA 기술 백서