4,096개 GPU에서 만든 체크포인트가 같은 환경에서 다시 읽히리라는 보장은 없습니다. 장애가 난 서버를 제외하면 작업자 수가 바뀌고, 평가는 더 적은 GPU를 사용할 수 있습니다. 지도 미세조정과 강화학습은 사전학습과 다른 텐서·파이프라인·데이터 병렬 구성을 선택합니다. 저장 형식이 당시의 물리적 배치에 묶여 있으면 복구 전에 대규모 상태 변환 작업부터 수행해야 합니다.
ByteCheckpoint는 이 변환을 모델 개발 전 과정의 기본 동작으로 다룹니다. NSDI 2025 논문은 Megatron-LM과 PyTorch FSDP, 로컬 디스크와 HDFS, 네트워크 스토리지를 함께 지원한 운영 시스템을 설명합니다. 논리적인 모델 상태와 특정 학습 작업이 만든 조각의 위치를 분리하고, 목표 병렬 구성으로 불러오는 중에 다시 나눕니다. 빠른 저장 함수보다 여러 학습 단계와 자원 구성 사이를 이동하는 상태 형식에 가깝습니다.
오래 보존하기 어려운 작업자별 조각
병렬 학습은 텐서 차원을 나누고, 레이어를 파이프라인 단계에 배치하며, 옵티마이저 상태를 데이터 병렬 작업자 사이에 복제하거나 분할합니다. 같은 매개변수도 이 조합에 따라 전혀 다른 파일 집합으로 저장됩니다. rank 37이라는 파일명만으로는 자원 구성이 달라진 뒤 그 작업자가 논리 텐서의 어느 범위를 맡아야 하는지 알 수 없습니다.
기존 방식은 저장 당시의 구성을 요구하거나 별도의 오프라인 재분할 작업을 수행합니다. 첫 번째 방식은 사라진 GPU 구성이 복구의 전제라는 모순을 만듭니다. 두 번째 방식은 이전 체크포인트를 읽고, 전체 상태를 재구성하거나 재배열한 뒤 변환본을 다시 저장하고 또 읽습니다. 수천억 개 매개변수에서는 이 과정이 학습과 스토리지 대역폭을 다투고 평가와 후속 학습의 시작을 늦춥니다.
ByteCheckpoint는 각 수치 조각을 논리 텐서의 이름, 모양과 범위에 연결하는 메타데이터를 둡니다. 저장 형식은 미래의 병렬 구성을 예상하지 않습니다. 불러올 때 목표 프레임워크가 필요한 조각 범위를 제시하면, 저장된 범위와의 교집합을 계산해 데이터를 보냅니다. 하나의 호스트에 전체 텐서를 만든 뒤 다시 나누지 않아도 됩니다.
불러오는 동안 수행하는 재분할
핵심 연산은 두 범위의 교집합을 찾는 일입니다. 저장 조각은 논리 텐서의 일정 범위를 포함하고, 목표 작업자도 자신이 받을 범위를 가집니다. ByteCheckpoint는 겹치는 범위를 계산하고 읽기 작업을 배정해 목표 작업자로 바로 전송합니다. 별도의 변환 체크포인트가 필요하지 않으므로 GPU 수와 병렬화 조합을 바꿀 수 있습니다. 모델 가중치와 같은 방식으로 나뉘지 않는 옵티마이저와 데이터 로더 상태에는 각각 맞는 메타데이터가 필요합니다.
수천 개 작업자가 큰 메타데이터를 모두 교환하면 계획 단계도 병목이 됩니다. ByteCheckpoint는 중복 계획을 줄이고 목표 배치에 필요한 정보만 조정합니다. 장치 메모리에서 호스트 메모리로 복사하고, 직렬화하고, 스토리지에 올리는 단계도 비동기 파이프라인으로 겹칩니다. 파일시스템이 빨라도 Python 직렬화나 장치 복사, 가장 느린 작업자가 남아 있으면 전체 저장은 늦어집니다.
프레임워크 차이는 어댑터로 흡수합니다. Megatron-LM과 FSDP는 분산 상태를 표현하는 방식이 다르고, 스토리지도 API와 일관성 보장이 다릅니다. ByteCheckpoint는 공통 저장·불러오기 흐름을 두되 각 어댑터가 텐서의 정체성과 분할, 입출력 방식을 정확히 설명하도록 합니다. 프레임워크 독립성은 임의의 코드를 자동 지원한다는 뜻이 아니라, 새 구현이 따라야 할 인터페이스를 정했다는 의미입니다.
저장 시간과 학습 중단 시간의 차이
체크포인트 성능은 전체 저장 완료 시간으로 자주 표시됩니다. 학습 효율에는 순전파와 역전파가 실제로 멈춘 시간이 더 직접적입니다. ByteCheckpoint는 장치 복사와 직렬화, 업로드 일부를 재개된 학습과 겹칩니다. 저자들은 비교한 오픈소스 시스템보다 학습 중단 시간을 12.13배에서 161.50배 줄였으며 평균은 54.20배라고 보고합니다.
전체 저장과 불러오기 개선폭은 이보다 작지만 여전히 큽니다. 평균 저장은 6.05배, 불러오기는 3.88배 빨랐고 최대값은 각각 9.96배와 8.80배였습니다. 학습 중단 감소는 연산이 막힌 시간을 뜻하고, 저장·불러오기 배율은 체크포인트 작업의 완료를 뜻합니다. 사용자에게 보이는 멈춤이 거의 사라져도 배경 전송은 훨씬 오래 이어질 수 있습니다.
이 차이는 장애 위험과 연결됩니다. 학습이 먼저 재개된 뒤 영속 저장이 끝나기 전에 두 번째 장애가 나면 새 체크포인트를 쓰지 못할 수 있습니다. 운영자는 API 반환 시각과 학습 중단뿐 아니라 실제 내구성이 확보되는 시각을 측정해야 합니다. 체크포인트 요청 주기가 배경 파이프라인의 처리 시간보다 짧으면 스토리지 압력이 계속 쌓이는지도 확인해야 합니다.
운영 규모와 평가 조건
ByteCheckpoint는 수만 개 GPU를 운영하는 산업용 AI 플랫폼에 배포됐고, 논문은 8,960개 GPU에서 4,050억 개 매개변수 모델을 지원했다고 설명합니다. 세부 실험에는 A100 80 GB와 FSDP를 사용한 비디오 확산 트랜스포머, H800 80 GB와 Megatron-LM을 사용한 GPT 계열 모델이 포함됩니다. 주 시험 환경의 호스트는 InfiniBand로 연결되고 체크포인트는 HDFS에 저장됩니다.
여러 환경을 포괄했다는 점은 호환성 근거를 강화하지만, 최대 배율이 모든 스토리지에서 유지된다는 뜻은 아닙니다. 텐서 크기, 옵티마이저, 네트워크 과가입, 파일시스템 부하, CPU 직렬화 성능, 체크포인트 주기와 원본·목표 배치가 결과를 바꿉니다. 비교 대상은 저자들이 시험한 PyTorch Distributed Checkpoint와 Megatron Distributed Checkpoint 버전이므로 이후 구현과는 다시 측정해야 합니다.
운영 도구는 성능만큼 중요합니다. ByteCheckpoint는 계획, 장치에서 호스트로의 복사, 직렬화, 덤프와 업로드에 걸린 시간과 바이트 수를 작업자별로 기록합니다. 병렬 토폴로지를 따라 보는 히트맵은 데이터 로더 상태를 추가로 가진 작업자나 느린 스토리지 경로를 찾는 데 도움이 됩니다. 공통 API만 제공하고 단계별 근거가 없으면 특정 모델의 병목이 다시 숨겨집니다.
상태 일관성이 남기는 책임
저장 형식만으로 모델, 옵티마이저, 스케줄러, 난수와 입력 파이프라인 상태가 같은 복구 시점에 속하는지 결정할 수 없습니다. 학습 프레임워크가 일관된 시점을 만들어야 합니다. 비동기 저장에서는 체크포인트 호출 뒤 학습이 버퍼를 다시 수정할 수 있으므로 소유권 규칙이 더 중요합니다. 텐서 이름과 범위를 정확히 기록해도 서로 다른 단계의 값을 잡으면 이동 가능한 잘못된 체크포인트가 됩니다.
후속 학습에서도 같은 문제가 있습니다. 수치 상태를 불러올 수 있어도 토크나이저 버전, 데이터 혼합 식별자, 옵티마이저 설정과 실행 코드가 빠지면 작업을 재현할 수 없습니다. ByteCheckpoint는 분산 수치 상태와 추가 상태의 공통 흐름에 집중합니다. 운영 레지스트리는 소프트웨어와 데이터, 정책을 고정한 별도의 매니페스트를 함께 관리해야 합니다.
보안 기준도 작업자 파일이 아니라 논리 모델 단위로 바뀌어야 합니다. 메타데이터는 모델 구조를 드러내고 공유 스토리지에는 같은 모델 계열의 여러 분기가 남습니다. 암호화, 접근 권한, 삭제와 감사는 논리 상태의 정체성을 따라야 합니다. 블록 중복 제거는 용량을 줄이지만 서로 다른 사용자가 데이터를 공유해도 되는 신뢰 범위에서만 적용할 수 있습니다.
복구 환경을 바꾸는 인수 시험
도입 시험은 일부러 저장과 복구 구성을 다르게 만들어야 합니다. 한 텐서·파이프라인 병렬 구성으로 저장하고 작업자를 제거한 뒤 다른 구성으로 불러와 모델, 옵티마이저, 데이터 로더와 난수 상태를 비교합니다. 실제 스토리지 계층마다 동시에 여러 체크포인트를 만들며 학습 중단, 영속 저장 완료, 재시작, 임시 호스트 메모리, 메타데이터 계획과 중복 읽기 바이트를 따로 측정해야 합니다.
배경 저장 중 장애도 포함해야 합니다. 이전 체크포인트 중 무엇이 유효하게 남는지, 미완성 객체를 어떻게 찾는지, 정리 작업이 읽기와 충돌하지 않는지 확인해야 합니다. 무결성과 장애 주입 없이 수행한 불러오기 벤치마크는 대역폭을 검증할 뿐 복구를 보장하지 않습니다.
새 프레임워크 상태 유형을 추가하는 비용도 계산해야 하며, 각각 안정적인 논리 이름과 분할 설명이 필요합니다. 이 대응표가 개별 학습 스크립트에 흩어지면 형식이 달라질 수 있습니다. 스키마 버전, 호환성 시험과 오래된 체크포인트를 읽는 독자가 빠른 데이터 경로만큼 중요합니다.
모델 개발 전 과정의 상태 형식
ByteCheckpoint는 체크포인트가 가끔 실행되는 파일 쓰기가 아니라는 점을 보여 줍니다. 사전학습, 평가, 장애 복구, 지도 미세조정과 강화학습을 연결하는 상태 교환 계층입니다. 저장 작업자별 물리 조각은 쓰기에는 편하지만 이 역할을 맡기에는 범위가 좁습니다.
실제 선택 기준은 구성이 바뀌었을 때의 이동 가능성입니다. 최고 대역폭으로 저장해도 같은 GPU 수와 병렬 배치를 요구하면 복구 순간에 실패할 수 있습니다. 논리 표현과 불러오기 중 재분할은 메타데이터와 계획 비용을 사용해 이 종속성을 없앱니다. 오래 이어지는 기반 모델 개발에서 가장 가치 있는 체크포인트는 가장 빨리 만들어진 작업자 파일이 아니라, 클러스터와 학습 단계가 바뀐 뒤에도 읽을 수 있는 상태입니다.
출처와 저작권 안내
이 글은 NSDI 2025 논문[1]을 우리 표현으로 다시 분석한 편집 다이제스트입니다. 논문의 문장·도판·표를 옮기지 않았으며, 본문 도판은 Silicon & Systems가 새로 제작했습니다. 개선 수치는 저자들이 사용한 작업부하, 비교 시스템과 스토리지 조건을 유지해 인용했습니다. 원 논문의 저작권은 저자와 USENIX 프로시딩(2025)에 있습니다.