GPU 수천 장이 스토리지를 기다린다: OSDI 2026 최우수 논문이 찾아낸 LLM 학습의 세 병목

대규모 모델 학습 이야기는 대부분 GPU에서 끝난다. 몇 장을 붙였는지, 인터커넥트가 몇 Gbps인지, MFU가 몇 퍼센트인지. 그런데 그 GPU들이 실제로 무엇을 기다리며 노는지를 운영 데이터로 파고든 논문이 2026년 7월 시애틀에서 열린 OSDI 2026(제20회 USENIX 운영체제 설계·구현 심포지엄)에서 최우수 논문상을 받았다.

제목은 「Teaching The Old Dog New Tricks: Building Efficient Data Pipelines for Large-Scale LLM Pre-training」. 옛날 개에게 새 재주를 가르친다는 제목의 ‘옛날 개’는 HDFS다. 2006년에 나온 하둡 분산 파일시스템으로 엑사바이트급 LLM 학습을 떠받치면서, 시스템을 갈아엎지 않고 어디까지 갈 수 있는지를 보여주는 것이 이 논문의 논지다.

저자는 중국과학기술대학교(USTC)와 바이트댄스 Seed 팀이 중심이고 칭화대와 허페이 종합국가과학센터 인공지능연구원이 함께 참여했다. 바이트댄스의 실제 사전학습 클러스터에서 90일간 수집한 3만 건의 학습 작업 트레이스가 분석 대상이다. 논문이 특별한 이유는 기법이 화려해서가 아니라, 논문에 나오는 숫자가 전부 벤치마크가 아니라 운영 중인 프로덕션 환경의 측정치라는 데 있다.

무대 설정 — 사전학습은 세 단계로 나뉜다

병목을 이해하려면 학습 작업이 스토리지를 어떻게 건드리는지부터 봐야 한다. 논문은 사전학습 실행을 세 단계로 나눈다.

• 초기화(initialization): 최신 체크포인트에서 파라미터와 옵티마이저 상태를 읽어 수천 개 랭크에 올린다. 전부가 끝나야 학습이 시작되는 동기 장벽이다.
• 반복 학습(iterative training): 데이터로더가 다음 스텝 데이터를 미리 읽고 변환하며, 프레임워크는 주기적으로 체크포인트를, 필요하면 매 스텝 로짓을 쓴다.
• 동반 평가(companion evaluation): 학습과 병렬로 도는 별도 파이프라인이다. 최근 체크포인트를 가져와 벤치마크를 돌려 모델이 망가지고 있지는 않은지 외부에서 확인한다.

세 번째가 낯설 수 있는데, 이 논문의 첫 번째 병목이 정확히 여기서 나온다. 학습 손실(loss)만 보면 모델이 무너지는 것을 못 잡는다는 것이 운영 경험이라는 것이다. 손실 곡선은 멀쩡한데 다운스트림 과제에서는 이미 망각과 붕괴가 진행 중인 상태가 실제로 존재한다. 그래서 별도 클러스터에서 계속 벤치마크를 돌린다.

병목 ①. 크로스 DC 지연의 함정 — 대역폭이 아니라 왕복 시간이 문제였다

동반 평가 클러스터는 대개 다른 데이터센터에 있다. 이유는 두 가지다. 사전학습은 수천 GPU가 갱 스케줄링으로 한 몸처럼 움직여야 해서 평가 작업을 같은 클러스터에 끼워 넣으면 학습 처리량이 깎인다. 그리고 평가는 최신 가속기가 필요 없는 처리량 위주 작업이라 전력과 공간이 남는 곳에 두면 된다. 합리적인 배치다. 문제는 그 결정이 만드는 I/O다.

30일 관측 구간에서 19개 사전학습 작업이 3,589회의 동반 평가를 돌렸고, 그 결과 156건의 심각한 모델 회귀를 잡아냈다. 평가는 확실히 값어치를 한다. 그런데 대표적인 멀티모달 대형 모델(MM-L) 기준으로 평가 한 사이클이 네 시간을 넘고, 그중 약 56.6%가 데이터 I/O다. 그리고 그 I/O 시간의 84.8%가 체크포인트 머지 단계에 몰려 있다. 평가 클러스터가 원격 스토리지에서 약 2.6TB를 광역망으로 끌어와야 하기 때문이다.

여기서 흥미로운 대목이 나온다. 문제는 대역폭이 아니었다.

• 트랜스포머 체크포인트는 수천 개의 조각난 텐서로 되어 있고, MM-L 체크포인트에서는 텐서의 60% 이상이 16KB 미만이다(LayerNorm 파라미터, 편향 같은 것들).
• 머지는 모달리티별로 필요한 텐서만 골라 읽기 때문에, 요청이 텐서 단위로 잘게 나간다. 128MB 블록에 최적화된 HDFS와는 최악의 궁합이라 약 1.5배 읽기 증폭이 생긴다.
• 여기에 왕복 시간 100ms짜리 WAN이 붙는다. 그러면 처리량은 대역폭이 아니라 지연에 묶인다. 논문의 그래프에서 60Gbps 링크가 톱니 모양으로 놀고 있는 이유다.
• 게다가 크로스 DC 대역폭은 평균 208개의 동시 작업(데이터 이관, 로그 수집, 다른 평가)이 나눠 쓴다. 선착순 정책은 긴급한 평가와 밤새 도는 아카이빙을 구분하지 못한다.

비용은 이렇게 계산된다. 회귀 156건에 대해 I/O 지연으로 낭비된 GPU 시간이 약 260만 시간. 평가 시스템이 조기 발견으로 아껴준 것이 약 550만 GPU 시간이니, 평가가 벌어준 시간의 절반 가까이를 평가 자체의 I/O가 도로 까먹고 있었다.

해법은 두 가지이고, 둘 다 새 하드웨어를 사지 않는다.

예측 체크포인트 복제. 동반 평가는 보통 1,000 스텝마다 도는 예측 가능한 일정이다. 그러면 학습 쪽이 체크포인트를 쓰기 시작하는 순간 복제를 같이 시작하면 된다. 스토리지가 필요한 샤드를 큰 연속 전송으로 묶어 평가 클러스터의 스토리지 계층에 미리 캐싱해두고, NNProxy라는 가벼운 네임스페이스 서비스가 평가 작업을 로컬 사본으로 유도한다. 광역 읽기가 로컬 읽기로 바뀌면 RTT도 작은 읽기 파편화도 함께 사라진다.

신호 기반 우선순위. 모든 평가가 급한 것은 아니다. 정기 평가와 달리 손실 급등이나 그래디언트 이상으로 촉발된 평가는 빨리 답을 줘야 한다. 모델 규모·작업 중요도·이상 심각도를 묶은 우선순위 신호를 만들어, 스토리지 스케줄러가 배경 트래픽을 밀어내고 대역폭을 몰아준다.

결과는 머지 지연 평균 76.1% 감소(작은 텍스트 모델 T-S에서는 89.3%, MM-L에서도 70.8%). 회귀 한 건당 낭비되던 계산이 16,800 GPU 시간에서 4,000 GPU 시간으로 줄었고, 관측 구간 전체로 보면 200만 GPU 시간 가까이를 회수했다.

병목 ②. 초기화 I/O 폭풍 — 중복 제거가 만든 역설

대규모 학습은 끊김 없이 몇 달을 도는 그림이 아니다. 하드웨어 고장, 자동 유지보수, 그리고 무엇보다 개발 중의 디버깅 사이클 때문에 자주 멈추고 다시 뜬다. 그리고 재시작할 때마다 수천 랭크가 동시에 체크포인트를 읽는다.

MM-S 트레이스에서 재시작 한 번의 시작 지연을 뜯어보면 이렇다.

블로킹 다운로드 하나가 전체 시작 시간의 39.95%다. 여기에 재시작의 밀집성이 곱해진다. 논문은 111분짜리 디버깅 구간에서 같은 작업이 네 번 연속 재시작한 사례를 든다. 다운로드 평균 5분이면 그 구간 벽시계 시간의 18.02%가 I/O다. 클러스터 전체로 외삽하면 연간 100만 GPU 시간 이상이 시작 지연으로 사라진다.

원인을 찾으려고 2,048 GPU 규모의 통제 실험을 돌렸는데, 여기서 통념이 하나 깨진다. 분산 파일시스템의 병목은 보통 메타데이터 연산(open, getattr)이라고들 하는데, 측정해보니 open 지연은 낮고 안정적이었다. 튀는 것은 read였고, QPS 급등과 정확히 겹쳤다. 즉 메타데이터가 아니라 데이터 경합이다. 다운로드 지연 분포는 꼬리가 길었고, 소수의 낙오(straggler) 읽기가 전체 대기의 67.97%를 차지했다. 0.5초 창으로 파일별 최대 QPS를 재보니 상위 5% 파일이 전체 압력의 38.8%를 만들었다.

핫스팟의 정체는 두 가지다. 하나는 모든 랭크가 읽는 전역 메타데이터(.metadata, common_states), 다른 하나가 더 흥미롭다. 중복 제거가 만든 접근 편향이다.

체크포인트 시스템은 쓰기 처리량과 저장 효율을 위해 병렬 저장과 중복 제거를 쓴다. 임베딩처럼 여러 랭크에 복제되어 있는 파라미터는 한 부만 저장한다. 쓸 때는 훌륭한 선택이다. 그런데 읽을 때는 수백 개 랭크가 그 파일 하나로 몰린다. 기본 3복제 정책으로는 감당이 안 되고, 지연이 수직으로 튄다. 반대로 MoE 전문가처럼 샤딩된 파라미터는 병렬 그룹별로 다른 파일에 저장돼 있어서 부하가 알아서 흩어진다. 쓰기 최적화가 읽기 비대칭을 만든 것이고, 이것이 이 논문에서 가장 재사용 가치가 큰 관찰이다.

전통적인 해법은 반응형 복제다. 열기(heat)를 감지하면 복제를 늘린다. 그런데 여기서는 두 번 실패한다. 경합 구간이 수십 초라 감지하고 복제를 만들 때쯤이면 로딩은 이미 끝나 있고, 폭풍 한가운데서 복제 트래픽을 밀어 넣으면 포화된 네트워크를 더 밀어붙여 상황을 악화시킨다.

그래서 논문은 방향을 뒤집는다. 핫스팟을 미리 알려주면 된다. 병렬화 전략과 월드 사이즈는 작업 제출 시점에 이미 확정돼 있으므로 어떤 파일이 뜨거워질지는 결정론적으로 계산된다. 프레임워크가 SetReplicationHints 인터페이스로 전역 메타데이터와 복제 텐서 목록을 넘기면, 스토리지가 파일별 예상 동시성을 복제 하나가 감당할 안전 부하로 나눠 목표 복제 수를 정하고 미리 늘려둔다. 저장 공간이 부풀지 않도록 이 임시 복제본에는 TTL을 달아 시작 단계가 끝나면 회수한다.

2,048 GPU 실험에서 핫 파일 복제를 128개로 미리 늘린 결과, 체크포인트 로딩이 38.48초에서 22.78초로 40.8% 단축됐다. 절대값으로는 십몇 초지만, 이 숫자의 의미는 규모에 있다. 랭크가 늘수록 경합은 심해지고, 사전 확장은 규모에 따라 예측 불가능하게 나빠지던 구간을 상수 시간에 가깝게 만든다. 논문은 아예 운영 가이드라인으로 못을 박았다 — 1만 GPU 클러스터는 64복제, 2만 GPU 클러스터는 128복제.

병목 ③. 변환의 벽 — 스토리지가 아니라 CPU가 막는다

텍스트 전용 모델에서는 데이터 로딩이 GPU 계산 뒤에 숨는다. 읽고 토크나이즈하는 정도는 스텝 시간보다 훨씬 짧다. 멀티모달로 넘어가면 이 전제가 깨진다.

MM-L 트레이스에서 데이터 로딩 5.35초를 뜯어보면 이렇다.

변환이 전체의 94.4%다. 정작 스토리지에서 바이트를 읽는 시간은 평균 13.6ms로 무시할 수준이다. 이 워크로드는 I/O 바운드가 아니라 CPU 바운드다.

더 고약한 것은 편차다. 멀티모달 배치에는 짧은 텍스트와 10분짜리 고해상도 영상이 섞여 있고, 변환 비용은 길이·코덱·샘플링 프레임 수에 비례한다. 어떤 호스트가 161.9MB 샘플 하나를 처리하느라 41.5초를 쓰는 동안 다른 호스트들은 평균 20MB를 5.05초에 끝낸다. 500MB짜리 10분 H.264 영상은 하드웨어 디코딩과 4스레드를 써도 2.18분이 걸린다. 동기 학습에서 이런 낙오자 하나는 나머지 수천 GPU를 세운다. 스텝 간 호스트 편차가 최대 5초까지 벌어졌고, 이 시간 편차만으로 하루 1만 GPU 시간 이상이 증발한다.

가장 먼저 떠오르는 해법은 미리 변환해두는 것인데, 논문은 두 가지 이유로 잘라낸다. 첫째 저장 증폭이다. JPEG·H.265로 압축돼 있는 것을 float 텐서로 풀면 영상은 40배 이상, 이미지도 수십 배로 부푼다. 페타바이트 데이터셋이 엑사바이트가 되면 병목만 CPU에서 저장 용량으로 옮긴 셈이다. 둘째 경직성이다. 크롭 크기, 프레임 수, 해상도는 실험마다 바뀌는 하이퍼파라미터다. 하나 바꿀 때마다 전처리 데이터셋을 통째로 다시 만들어야 한다면 모델 개발 속도가 죽는다.

대신 논문은 이미 돈을 낸 자원을 찾아낸다. 스토리지 노드의 CPU는 20~30%만 쓰이고 있었다. 학습 노드가 계산과 미디어 처리로 포화될 때, 스토리지 노드는 디스크 탐색과 NIC 한계에 묶여 코어를 놀리고 있다.

그래서 스토리지 계층을 분산 전처리 엔진으로 다시 설계한다. 이게 가능한 전제는 이들의 데이터로더가 결정적(deterministic)이라는 점이다. 오프라인에서 만든 전역 실행 계획이 어떤 샘플을 몇 번째 스텝에서 읽을지 이미 정해두기 때문에, 스토리지가 미래의 접근 순서를 정확히 안다. 셔플은 물리 데이터를 건드리지 않고 인덱스만 뒤섞어 처리한다.

• 일정 동기화: 학습 시작 시 데이터셋 식별자와 스텝 진행 상황만 넘기면, 스토리지 노드가 스텝별 정보 파일을 읽고 다음에 필요한 블록을 스스로 알아낸다. 수백만 건의 RPC가 임계 경로에서 사라진다.
• JIT 변환: 스토리지 노드가 소비자 큐를 유지하며 원본을 미리 읽고 디코딩·크롭·정규화를 백그라운드로 돌린다. GPU가 N 스텝을 계산하는 동안 스토리지는 N+1 스텝의 텐서를 만든다. 영상은 프레임 샘플링까지 스토리지에서 끝내고 보내서 디코딩으로 부푼 페이로드가 네트워크를 때리지 않게 한다.
• 부하 인지 폴백: 스토리지 노드 CPU가 80%를 넘으면 변환을 포기하고 원본 바이트를 그대로 돌려준다. 학습 클라이언트는 받은 것이 텐서인지 바이너리인지 보고 로컬 처리로 되돌아간다. 공용 스토리지를 죽이지 않는다는 하드 제약을 지키는 장치다.

결과는 P99 데이터 로딩 지연 85.7% 감소, 변환 낙오로 인한 스톨 63.2% 감소, MFU 상대 10.8% 개선, 그리고 학습 호스트의 데이터 로딩 CPU 사용량 94% 감소다.

세 병목을 한 장으로

하지 않은 선택들이 더 흥미롭다

논문에는 “What if?”라는 절이 있다. 검토했다가 접은 대안을 이유와 함께 적어둔 부분인데, 실무자에게는 여기가 본론일 수 있다.

P2P로 체크포인트를 뿌리면 안 되나? 이론상 클러스터 크기에 선형으로 확장되지만 접었다. 큰 GPU 클러스터에는 여러 학습 작업이 동시에 돌고, P2P의 전방위 트래픽은 다른 작업의 NCCL 집합 통신을 방해한다. 그리고 초기화는 가장 느린 노드에 묶인 동기 장벽인데 P2P 성능은 확률적이라, 느린 피어 하나가 갱 전체의 시작을 늦춘다. 계층적 클라이언트-서버 구조는 대신 결정적인 SLA를 준다.

전처리 전용 클러스터를 두면 안 되나? tf.data service나 Ray Data가 택한 구조다. 역시 접었다. 디코딩된 텐서는 원본보다 50~100배 크고, 그것을 데이터센터 네트워크로 실어 나르면 병목이 CPU에서 대역폭으로 옮겨갈 뿐이다. 게다가 전용 클러스터는 멀티모달 피크에 맞춰 사두고 텍스트 작업 기간에는 놀린다.

3FS나 AIStore 같은 AI 전용 스토리지로 옮기면 안 되나? 여기서 나오는 답이 이 논문의 제목과 직결된다. HDFS는 AI 학습만 쓰는 창고가 아니라 여러 사업 부문이 함께 쓰는 엑사바이트급 데이터 레이크다. 이 정도 데이터를 옮기는 것은 비용 이전에 운영상 불가능하고, AI 전용 시스템은 올-NVMe 같은 하드웨어 전제나 커스텀 클라이언트를 요구해서 스파크 기반 정제 파이프라인 같은 기존 생태계와의 호환을 깬다. 데이터 중력은 벤더 선택뿐 아니라 파일시스템 선택에서도 가장 무거운 힘이다.

그래서 우리 조직에 무엇이 남나

수만 GPU를 굴리지 않더라도 가져갈 것이 세 가지 있다.

첫째, 결정적인 것을 스토리지에 말해줘라. 이 논문의 세 해법은 전부 같은 문장의 변형이다 — 학습 작업은 무엇을 언제 읽을지 이미 알고 있는데, 스토리지는 그걸 모른 채 반응만 한다. 평가 주기, 월드 사이즈, 샘플 순서처럼 미리 아는 정보를 인터페이스로 넘기는 것만으로 반응형 캐시가 절대 못 잡는 구간이 풀린다. 이는 사내 파일서버든 관리형 서비스든 똑같이 적용되는 설계 원칙이다.

둘째, 쓰기 최적화가 읽기 병목을 만든다는 것을 의심해라. 중복 제거·압축·병렬 저장은 쓰기 시점에는 전부 미덕이다. 그런데 복구는 쓰기와 정반대 형태의 접근을 만든다. 백업·체크포인트·아티팩트 저장소를 설계할 때 복구 시점의 팬아웃을 같이 그려보지 않으면 같은 함정을 밟는다.

셋째, 계산을 데이터 쪽으로 밀 수 있는지 보라. 다만 이 대목은 조건부다. 논문 스스로 밝히듯 스토리지 사이드 오프로드는 스토리지 노드에 여유 CPU가 있다는 전제에 기대고, S3나 애저 블롭 같은 오브젝트 스토리지, 혹은 얇은 스토리지 어플라이언스에서는 그 전제가 성립하지 않는다. 그 경우 논문이 제시하는 대안은 전처리 결과 캐싱(단, 전역 셔플이 도는 사전학습에서는 히트율이 낮아 강화학습이나 반복 파인튜닝 쪽이 어울린다)과, 샘플 메타데이터로 변환 비용을 예측해 무거운 샘플과 가벼운 샘플을 섞어 배치를 구성하는 방식이다.

읽을 때 조심할 것

이 논문의 숫자는 강력하지만 한 회사의 한 환경에서 나온 값이다. 스토리지가 HDFS이고, 데이터로더가 결정적이며, 스토리지 노드에 남는 CPU가 있고, 평가가 다른 데이터센터에서 도는 조건이 겹친 결과다. 조건이 하나만 달라져도 개선 폭은 달라진다. 40.8%가 나온 체크포인트 로딩 실험은 2,048 GPU라는 통제 환경에서 38.48초를 22.78초로 줄인 것이고, 절대값보다 규모 확장에서의 안정성이 핵심이다.

그럼에도 이 논문이 최우수 논문을 받은 이유는 분명해 보인다. 새 스토리지를 만들지 않고, 마이그레이션도 하지 않고, 20년 된 시스템에 애플리케이션의 결정성을 알려주는 인터페이스 몇 개를 얹어서 프로덕션 규모의 병목을 걷어냈기 때문이다. 인프라를 다루는 사람 입장에서 이보다 실용적인 결론은 드물다. 연구진은 익명화 후 트레이스를 공개할 계획이라고 밝혔는데, 공개되면 후속 연구뿐 아니라 자기 클러스터를 재보려는 팀에게도 기준선이 될 것이다.

⚠️ 이 글의 수치는 「Teaching The Old Dog New Tricks: Building Efficient Data Pipelines for Large-Scale LLM Pre-training」(OSDI 2026, USENIX) 본문에 보고된 값이다. 바이트댄스의 특정 프로덕션 환경(HDFS 기반, 결정적 데이터로더)에서 측정된 것이므로 다른 환경에 그대로 옮겨 적용되지 않는다. 최우수 논문 수상은 USENIX 공식 페이지의 표기를 따랐고, 수상의 의의에 관한 일부 서술은 참여 기관 측 발표에 근거한다.

자주 묻는 질문

OSDI가 어떤 학회인가요?

USENIX가 주최하는 운영체제·시스템 분야의 최상위 학회입니다. 2026년이 20회째이고 7월 13~15일 미국 시애틀에서 열렸습니다. SOSP와 함께 시스템 소프트웨어 분야에서 가장 인용이 많이 되는 학회로 꼽히며, 채택률이 낮고 대규모 실제 시스템에 대한 논문이 강세라는 특징이 있습니다. 발표 논문은 USENIX 사이트에서 무료로 공개됩니다.

동반 평가(companion evaluation)가 정확히 무엇인가요?

학습을 멈추지 않고, 별도 클러스터에서 최근 체크포인트를 가져와 벤치마크를 돌리는 상시 검증 파이프라인입니다. 학습 손실만 보면 모델이 특정 과제에서 이미 망가지고 있는 것을 놓칠 수 있기 때문에 외부 지표로 확인하는 장치입니다. 논문의 환경에서는 30일 동안 3,589회의 평가가 156건의 심각한 회귀를 잡아냈고, 결과가 나쁘면 학습 제어 시스템이 롤백을 트리거합니다.

체크포인트 로딩이 느린 것이 왜 메타데이터 문제가 아닌가요?

분산 파일시스템에서는 open이나 getattr 같은 메타데이터 연산이 병목이라는 통념이 있는데, 이 논문이 2,048 GPU 규모에서 측정해보니 open 지연은 낮고 안정적이었습니다. 튀는 것은 read 지연이었고 QPS 급등과 정확히 겹쳤습니다. 원인은 소수의 인기 파일에 수백 개 랭크가 동시에 몰리는 데이터 경합이었고, 특히 중복 제거로 한 부만 저장된 임베딩 파일이 대표적인 핫스팟이었습니다.

스토리지 노드에서 데이터를 변환한다는 것이 안전한가요?

논문은 두 가지 안전장치를 둡니다. 하나는 부하 인지 폴백으로, 스토리지 노드 CPU가 임계치(예: 80%)를 넘으면 변환을 중단하고 원본 바이트를 그대로 돌려줍니다. 학습 쪽 데이터로더는 받은 데이터의 형식을 보고 알아서 로컬 처리로 되돌아갑니다. 다른 하나는 영상의 경우 프레임 샘플링까지 스토리지에서 끝내 네트워크로 나가는 데이터가 부풀지 않게 하는 것입니다. 공용 스토리지의 안정성을 깨지 않는 것이 전제 조건이었습니다.

우리 회사는 S3를 쓰는데 같은 기법을 적용할 수 있나요?

세 가지 중 앞의 두 가지, 즉 예측 기반 사전 복제·캐싱과 시작 시점의 접근 쏠림 완화는 개념적으로 옮길 수 있습니다. 반면 스토리지 사이드 변환 오프로드는 스토리지 노드에 남는 CPU가 있다는 전제에 기대므로 오브젝트 스토리지에서는 그대로 적용되지 않습니다. 논문도 이 한계를 명시하며 대안으로 전처리 결과 캐싱과 변환 비용을 고려한 배치 구성을 제시합니다. 후자는 샘플 크기·코덱·길이 같은 메타데이터만 있으면 데이터로더 쪽에서 바로 시도해볼 수 있습니다.