ZeRO-Inference: GPU에 weights를 0개 올리고
초거대 모델을 GPU 1장으로 추론하기

문제: 좋은 모델일수록 살 수 없는 GPU가 필요해진다

한 줄 요약 — SOTA 모델(예: Megatron-Turing-530B)은 fp16 추론만 해도 A100-40GB가 최소 40장 필요해서, 학생·연구자·소기업은 공개된 모델조차 돌려볼 수 없다. 4년도 안 되어 SOTA가 0.3B(BERT-Large) → 530B로 커지면서, 모델 크기의 성장이 곧 접근성의 붕괴가 됐다 §Introduction.

핵심 관찰: 정작 보통 컴퓨터에도 CPU DRAM + NVMe SSD를 합치면 수 TB의 메모리가 이미 있다. 비싼 건 GPU HBM뿐이다. 그렇다면 모델을 꼭 GPU에 담아야 하나? §Introduction

"hosting no (zero) weights in GPU" — §Introduction (기술명 ZeRO의 유래)

기존 접근법: 모델을 GPU에 "다 넣거나, 반쯤 넣거나"

어떻게 동작하나: layer streaming + "GPU 메모리는 batch에 몰빵"

① 기본 메커니즘: layer-by-layer streaming §Offload all model weights

모델 전체(수백 GB)를 CPU DRAM 또는 NVMe에 고정(pin)해 두고, 추론 시 layer 1개씩만 PCIe로 GPU에 가져와 계산한다. 계산이 끝나면 그 layer의 weights는 즉시 버리고(메모리 해제) 다음 layer를 받는다. layer의 출력(activation)만 GPU에 남아 다음 layer의 입력이 된다. GPT3-175B는 96 layer이므로, GPU에는 항상 전체의 ~1%만 존재 — 530B 모델의 GPU 메모리 요구가 1TB → 10GB로 두 자릿수 감소한다.

② 핵심 통찰: 비운 GPU 메모리를 batch에 쓴다 §Offload all model weights

모델을 안 올렸으니 GPU 메모리 대부분이 빈다. 이걸 긴 시퀀스·큰 batch의 입력 토큰으로 채운다. layer 1개의 계산량은 처리하는 토큰 수에 비례해 커지므로(예: GPT3-175B layer 1개, batch 1 · 2048 토큰에 약 7 TFlops), 토큰을 많이 실을수록 계산 시간이 길어져 전송 시간을 완전히 덮는다. 즉 이 시스템에서 큰 batch는 사치가 아니라 PCIe를 숨기기 위한 필수 연료다.

숫자로 손으로 돌려보기 [블로그에 없음: 블로그의 7 TFlops·GPT3-175B 96 layer 수치로 직접 계산한 근사]

GPT3-175B → layer당 weights ≈ 175B/96 ≈ 1.8B 파라미터 ≈ fp16 3.6GB. PCIe 3.0 x16 ≈ 16GB/s 가정 → layer 전송 ≈ 0.23초. V100 fp16 실효 ~60 TFLOPS 가정:

batch 1과 batch 8의 총 소요는 4배 차이지만 처리량은 8배 차이 — batch를 키울수록 "전송비는 고정, 일은 늘어나는" 구조라 throughput이 계속 좋아진다. 반대로 batch를 못 키우면(붕괴 케이스, s₈) GPU는 PCIe를 기다리며 논다.

③ 최적화 2가지 §Optimizations

(a) Prefetching — 위 timeline처럼 다음 layer를 미리 당겨온다. 특이점: CPU offload에서는 효과가 없었고(짧은 생성 시퀀스라 계산 시간이 너무 짧아 숨길 틈이 없음), NVMe offload에서만 1.13~1.21× 개선 — NVMe→CPU 전송과 CPU→GPU 전송이 2단 파이프라인을 이루기 때문 §Prefetching layer weights.

(b) 다중 GPU 병렬 fetch — GPU가 여러 장이면 각 GPU가 layer의 서로 다른 조각을 자기 PCIe로 동시에 받고(1단계), 그 뒤 GPU끼리 NVLink(PCIe보다 수십 배 빠름)로 all-gather 해 전체 layer를 조립한다(2단계). PCIe 대역폭이 GPU 수만큼 합산되는 효과 → GPU당 throughput이 오히려 증가하는 super-linear scaling §Parallelizing layer fetching.

④ 사용법 §How to use

DeepSpeed 설정에서 ZeRO stage 3 + 파라미터 offload 대상만 지정하면 Hugging Face generate 파이프라인에 그대로 얹힌다:

"zero_optimization": {
  "stage": 3,
  "offload_param": { "device": "cpu" }        // 또는
  "offload_param": { "device": "nvme", "nvme_path": "/local_nvme" }
}

블로그의 각 Figure/Table이 파는 주장

※ 블로그 원문 figure는 이미지 형태의 표/차트이며, 본 문서에서는 본문 수치를 기반으로 s₅에 재구성했다.

결과: 어떤 설계가 어떤 숫자를 만들었나

Fig. 1 재구성 — V100 32GB 1장으로 감당 가능한 모델 크기 §Model Scaling on 1 GPU

Table 2 재구성 — Full vs Partial offload (OPT-30B, V100 1장) §Full Offload vs. Partial Offload

Table 3·4 재구성 — Prefetch와 다중 GPU §Prefetching, §Parallelizing

Table 5~7 재구성 — 출력이 길어지면? §Impact of generation output length

결론

§Conclusion 블로그 명시 결론: 모델 초대형화가 AI 접근성을 위협하는 상황에서, ZeRO-Inference는 모델을 CPU/NVMe에 두고 layer를 스트리밍함으로써 GPU 1장 수준의 예산으로 SOTA 모델 추론을 가능하게 하며, 공개 모델 배포(BigScience, Meta 등)와 함께 AI 민주화를 완성하는 조각이 되고자 한다. 별도의 future work 절은 없고, 다중 GPU 결과에서 "미래 PCIe 세대의 대역폭 향상이 성능을 더 끌어올릴 것"이라는 전망만 덧붙인다 §Parallelizing.

본문 구석과 각주에서 놓치기 쉬운 것들

각주 1 — baseline이 16B에서 끊기는 이유: 16B 모델(fp16 32GB)은 V100-32GB에 "들어가긴" 하지만 입력·중간 결과를 둘 공간이 없어 실질 추론 불가.

각주 2 — partial offload에서 GPU 고정량을 더 늘리면 작은 batch에서도 OOM. "GPU에 더 넣기"의 한계를 실험적으로 확인.

각주 3 — 다중 GPU 실험은 독립 PCIe 링크를 가진 GPU만 골라 수행 — PCIe를 공유하는 슬롯 구성이면 병렬 fetch 이득이 줄어든다는 뜻이다.

실험 조건의 소박함 §Token Generation Performance — 성능 수치는 입력 4토큰 / 출력 10토큰, greedy search, HF pipeline + KV cache 기준. 오늘날의 장문맥·장출력 워크로드와는 거리가 있다.

Limitations 정리 [블로그에 없음: 명시적 한계 절이 없어 직접 정리]

FAQ

비판적으로 읽기: 이 시스템의 손익분기점은 "batch"다

ZeRO-Inference의 모든 효율은 "계산 시간 ≥ 전송 시간"이라는 한 가지 부등식 위에 서 있고, 그 부등식을 성립시키는 유일한 수단이 대량 batch다. batch를 못 키우는 상황 — 대화형 서비스(batch 1), 긴 출력으로 KV cache가 커진 상황 — 에서는 부등식이 깨지고 GPU는 PCIe를 기다리는 기계가 된다.

논문/블로그가 다루지 않은 층위

① 알고리즘 층위 — ZeRO-Inference는 "무엇을 어디에 두고 어떻게 나르나"만 다루고, 비싼 실행의 횟수 자체를 줄이는 발상(speculative decoding)은 범위 밖이다. 2년 뒤 TriForce가 정확히 이 직교 축을 공략해 같은 offloading 환경에서 4.86×를 얻는다. ② KV cache 층위 — 2022년 시점이라 KV cache는 "batch를 줄이는 성가신 존재"로만 등장하고, KV cache 자체의 offload·압축·선택적 로드는 다루지 않는다. ③ 정밀도 층위 — fp16 고정. 이후 표준이 된 4/8bit quantization과 결합하면 전송량이 2~4배 줄어 손익분기 batch가 낮아질 텐데, 미평가다 [블로그에 없음: 해석].

유효 적용 범위