🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

TRL의 델타 가중치 동기화는 연속된 강화학습 단계에서 실제로 바뀐 극소수의 bf16 원소만 희소 세이프텐서로 저장해 허깅페이스 버킷으로 전달함으로써, 대규모 모델의 반복적인 전체 체크포인트 전송 비용과 추론 중단 시간을 크게 줄이는 방식이다.

📌 핵심 요약

• 비동기 강화학습에서는 훈련기가 갱신한 정책을 추론 엔진에 계속 전달해야 하는데, 전체 체크포인트를 단계마다 복사하면 70억 매개변수 bf16 모델은 약 14기가바이트, 1조 매개변수급 모델은 약 1테라바이트를 전송해야 한다.
• 강화학습에서 사용하는 낮은 학습률과 bf16의 제한된 정밀도 때문에 연속된 최적화 단계 사이에는 가중치의 약 99%가 비트 단위로 동일하며, 관측된 최악의 단계에서도 동일한 비율이 98%를 넘는다.
• TRL 구현은 최적화 단계 전후를 비교해 실제로 변경된 원소만 희소 세이프텐서 파일로 인코딩하고, 이를 허깅페이스 버킷에 올린 뒤 브이엘엘엠이 독립적으로 내려받아 반영하게 한다.
• 큐웬3 6억 매개변수 모델에서는 단계별 전송량이 전체 모델 기준 1.2기가바이트에서 약 20∼35메가바이트로 감소했으며, 훈련기와 추론 서버가 직접 가중치를 주고받을 필요도 없어졌다.
• 훈련기, 브이엘엘엠 추론 서버, 워들 환경을 서로 다른 장비와 스페이스에 배치한 실험에서도 하나의 허깅페이스 버킷을 통해 가중치를 전달했으며, 공유 클러스터나 원격 직접 메모리 접근, 가상 사설망 없이 분리형 훈련을 수행했다.

🧩 주요 포인트

1. 비동기 강화학습에서는 훈련기가 갱신한 정책을 추론 엔진에 계속 전달해야 하는데, 전체 체크포인트를 단계마다 복사하면 70억 매개변수 bf16 모델은 약 14기가바이트, 1조 매개변수급 모델은 약 1테라바이트를 전송해야 한다.
2. 강화학습에서 사용하는 낮은 학습률과 bf16의 제한된 정밀도 때문에 연속된 최적화 단계 사이에는 가중치의 약 99%가 비트 단위로 동일하며, 관측된 최악의 단계에서도 동일한 비율이 98%를 넘는다.
3. TRL 구현은 최적화 단계 전후를 비교해 실제로 변경된 원소만 희소 세이프텐서 파일로 인코딩하고, 이를 허깅페이스 버킷에 올린 뒤 브이엘엘엠이 독립적으로 내려받아 반영하게 한다.
4. 큐웬3 6억 매개변수 모델에서는 단계별 전송량이 전체 모델 기준 1.2기가바이트에서 약 20∼35메가바이트로 감소했으며, 훈련기와 추론 서버가 직접 가중치를 주고받을 필요도 없어졌다.
5. 훈련기, 브이엘엘엠 추론 서버, 워들 환경을 서로 다른 장비와 스페이스에 배치한 실험에서도 하나의 허깅페이스 버킷을 통해 가중치를 전달했으며, 공유 클러스터나 원격 직접 메모리 접근, 가상 사설망 없이 분리형 훈련을 수행했다.

🧠 상세 정리

1. 전체 체크포인트 동기화가 만드는 병목

비동기 강화학습에서 추론 엔진은 현재 정책으로 롤아웃을 생성하고, 훈련기는 그 결과를 이용해 다음 정책을 계산한다. 훈련기가 단계 N+1의 가중치를 완성한 뒤에도 추론 엔진이 단계 N의 정책을 계속 사용하면 데이터가 점차 현재 정책에서 벗어나므로, 새 가중치의 동기화는 피할 수 없다. 문제는 기존 방식이 갱신된 일부가 아니라 전체 모델을 매 단계 전송한다는 점으로, 70억 매개변수 bf16 모델만 해도 약 14기가바이트이며 1조 매개변수급 체크포인트는 테라바이트 규모가 된다. 이 전송이 막혀 있는 동안 추론용 그래픽 처리 장치는 토큰을 생성하지 못하므로, 통신 시간은 그대로 유휴 연산 비용이 된다. 희소 델타 방식은 훈련기가 최적화 직후 변경분을 게시하고 추론 엔진이 준비되는 시점에 독립적으로 가져가도록 해, 동기화가 차지하던 임계 경로와 대기 시간을 크게 줄인다.

2. 인접 체크포인트의 실제 변화량

원문이 인용한 선행 사례들은 거대한 전체 체크포인트와 달리 인접한 강화학습 단계의 실제 변화량이 매우 작다는 데 일치한다. 파이어웍스가 제시한 1조 매개변수 fp8 체크포인트는 전체 크기가 1024기비바이트였지만, 인접 체크포인트 사이의 평균 델타는 20.3기비바이트로 전체의 1.98%에 불과했다. 또한 bf16 표현을 기준으로 연속 단계 사이에서 98%가 넘는 가중치가 비트 단위로 같았다고 보고했다. 커서의 사례도 훈련과 추론을 서로 다른 지역에 두고, 훈련기가 매 단계 압축된 가중치 차이를 공유 객체 저장소에 올리면 각 추론 클러스터가 이를 내려받아 독립적으로 복원하는 구조를 사용했다. 두 사례가 공유하는 결론은 대부분의 가중치는 바뀌지 않으며, 변경분만 보내면 대역폭을 약 두 자릿수 배율로 줄일 수 있고, 객체 저장소를 중간 매체로 쓰면 양쪽이 같은 데이터센터에 있을 필요가 없다는 것이다.

3. bf16에서 변화가 희소해지는 수치적 이유

bf16 수는 가수부가 7비트이므로 두 인접한 2의 거듭제곱 사이에 표현 가능한 값이 128개뿐이며, 가중치 절댓값 주변의 값 간격은 대략 그 절댓값에 2의 마이너스 7승을 곱한 크기다. 따라서 가중치 변화량의 절댓값이 기존 가중치 절댓값을 256으로 나눈 값보다 작으면, bf16로 다시 변환하는 과정에서 변화가 반올림에 흡수될 수 있다. 강화학습에서 예로 든 학습률 3×10의 마이너스 6승에서는 아담의 정규화된 갱신 크기가 대체로 1 정도이므로 개별 가중치의 변화량도 비슷한 수준이 된다. 반면 대표적인 언어 모델 가중치 절댓값은 주로 10의 마이너스 2승에서 10의 마이너스 1승 범위에 있고, 이에 따른 bf16 가시성 임계값은 약 4×10의 마이너스 5승에서 4×10의 마이너스 4승이다. 최적화 갱신이 이 임계값보다 작기 때문에 많은 가중치의 바이트 표현이 그대로 유지되며, 이는 근사 압축을 적용한 결과가 아니라 bf16 반올림 자체에서 생기는 정확한 동일성이다.

4. 희소성에 대한 실험적 검증과 검출 방식

원문은 펄스 연구가 이러한 수치적 설명을 흡수 한계와 유효 한계, bf16 가시성 임계값으로 정식화했다고 소개한다. 보수적인 아담 갱신의 흡수 한계는 학습률의 10배, 실제로 주로 나타나는 유효 한계는 학습률과 같은 수준이며, 가시성 임계값은 가중치 절댓값을 256으로 나눈 값이다. 학습률이 3×10의 마이너스 6승일 때는 보수적인 흡수 한계조차 모델의 거의 모든 대표 가중치에서 가시성 임계값 아래에 놓였다. 큐웬2.5의 5억·15억·70억 매개변수 모델과 라마3.2 30억, 젬마3 40억 모델을 400단계 동안 측정한 결과 평균 단계별 희소성은 약 99%였고 표준편차는 0.2∼0.4%였으며, 최악의 단계도 98%를 넘었다. 구현은 아담의 내부 통계로 변경 위치를 예측하지 않고 최적화 단계 전후에 실제로 뒤집힌 바이트를 관찰하는데, 내부 통계 기반 마스크 예측은 재현율이 약 30%에 그쳤기 때문이다.

5. 허깅페이스 버킷과 젯 저장 계층

허깅페이스 버킷은 빈번한 객체 저장을 위해 설계된 허브 저장소 유형으로, 커밋이나 풀 리퀘스트 절차와 대용량 파일 저장 방식의 복잡성을 거치지 않고 파일 추가, 목록 조회, 다운로드를 수행할 수 있다. 훈련기는 배치 파일 추가 함수로 델타를 올리고, 추론 측은 버킷 파일 다운로드 함수로 지정된 델타를 로컬 경로에 받아오므로 가중치 전달에 필요한 인터페이스도 단순하다. 버킷의 기반인 젯은 파일을 고정된 위치가 아니라 실제 내용에 따라 청크로 나누고, 이미 버킷에 저장된 내용과 비교해 중복 데이터를 제거한다. 따라서 희소 인코딩을 쓰면 변경된 원소만 담은 작은 파일을 전송하고, 전체 앵커 파일을 다시 올리는 경우에도 저장 계층이 동일한 청크의 재전송을 줄일 수 있다. 희소 델타와 내용 기반 중복 제거를 함께 사용함으로써 실제로 움직인 데이터에 대해서만 비용을 지불하고, 같은 내용은 반복 저장하지 않는 구조가 된다.

6. 훈련기와 추론 서버를 분리하는 구성

전체 구성은 가중치를 소유하고 최적화를 수행하는 훈련기, 파일을 중계하는 허깅페이스 버킷, 델타를 적용하고 롤아웃을 제공하는 브이엘엘엠 서버, 그리고 롤아웃 서버와 통신하는 환경으로 이루어진다. 버킷에는 주기적인 전체 스냅샷을 위한 앵커 경로와 그 사이의 희소 패치를 위한 델타 경로가 있으며, 양쪽이 공통으로 의존하는 것은 이 저장소뿐이다. 훈련기와 추론 서버는 매개변수 바이트를 서로 직접 보내지 않고, 저장소 식별자와 파일 이름을 담은 작은 요청만 제어 정보로 교환한다. 실제 데이터는 훈련기에서 버킷으로 올라가고 각 추론 서버가 버킷에서 내려받으므로, 훈련기와 추론 서버 사이에 공유 네트워크 패브릭이나 직접 연결이 필요하지 않다. 훈련기는 추론 복제본의 수와 위치, 장애 여부를 알 필요 없이 파일을 쓰고, 각 복제본은 자신의 일정에 맞춰 같은 델타를 읽는 방식으로 역할이 분리된다.

7. 분리형 훈련 실험과 운영상의 효과

원문은 이 구조를 설명하는 데 그치지 않고 훈련기, 추론 엔진, 환경을 물리적으로 분리한 전체 강화학습 실행으로 검증했다. 훈련기는 한 장비에서 실행하고, 브이엘엘엠은 허깅페이스 스페이스에 배치했으며, 워들 환경은 또 다른 스페이스에서 구동했다. 가중치는 하나의 허브 버킷을 통해 흘렀고 세 구성 요소를 하나의 공유 클러스터에 묶지 않았으며, 원격 직접 메모리 접근이나 가상 사설망도 사용하지 않았다. 이 방식에서는 추론 서버가 다른 지역이나 다른 기반 환경에 있거나 네트워크 주소 변환 뒤에 있어도 버킷에 접근할 수 있으면 델타를 받을 수 있다. 또한 여러 추론 복제본이 같은 델타를 독립적으로 가져올 수 있어, 훈련기를 복제본별 연결과 배포 상태를 관리하는 중앙 전송 서버로 만들지 않아도 된다.

8. 세이프텐서 기반 동기화 프로토콜

구현 프로토콜은 파일 형식, 버킷의 경로 구조, 브이엘엘엠 확장, 훈련기 측 변경 검출기로 구성되며, 전송 파일 형식으로 세이프텐서를 사용한다. 세이프텐서는 허브에서 널리 쓰이는 체크포인트 형식이고 여러 프레임워크가 읽을 수 있으며, 헤더에 문자열 메타데이터를 넣을 수 있어 희소 여부와 모델 버전 같은 프로토콜 정보를 함께 기록할 수 있다. 앵커 파일은 일반 체크포인트처럼 매개변수별 전체 bf16 텐서를 담고 일정한 동기화 간격마다 기록되며, 기본 간격은 10회로 제시된다. 예시 앵커의 메타데이터에는 희소 파일이 아니라는 표시, 모델 버전, 희소도 0이 포함되고 버킷의 앵커 경로 아래에 단계 번호를 붙여 저장된다. 델타 파일은 실제로 변경된 매개변수 원소만 다루는 별도의 희소 패치이지만, 제공된 원문은 세부 저장 구조를 설명하기 시작한 지점에서 끝나므로 그 이후의 인코딩과 적용 절차는 확인 가능한 범위에 포함되지 않는다.

🧾 핵심 주장 / 시사점

• 단계별 희소성은 손실을 감수한 근사화가 아니라, 낮은 강화학습 학습률에서 발생한 갱신이 bf16 표현 간격보다 작아 바이트가 실제로 변하지 않는 현상에 기반한다.
• 가중치 전송의 핵심 개선점은 단순한 파일 압축보다 제어 경로와 데이터 경로의 분리에 있으며, 훈련기는 변경분을 게시하고 추론 복제본은 공유 버킷에서 이를 독립적으로 가져간다.
• 큐웬3 6억 매개변수 모델에서 단계별 전송량이 1.2기가바이트에서 20∼35메가바이트로 줄어든 결과는, 약 99%의 비트 동일성을 직접 활용하면 소규모 모델에서도 통신 비용을 크게 낮출 수 있음을 보여준다.

✅ 액션 아이템

• TRL의 델타 가중치 동기화 방식으로 전환해 전체 체크포인트 복사 대신 변경 원소만 허깅페이스 버킷 업로드를 수행하고, 단계별 전송량과 추론 중단시간을 함께 정량 비교한다.
• 가중치의 연속 최적화 단계 불변률이 98~99% 범위를 벗어나는 구간을 추적해 델타 전송 임계조건을 정의하고 희소 세이프텐서 산출 품질을 점검한다.
• 훈련기·VLLM 추론 서버·W&B를 분리된 장비/스페이스에 배치해 단일 허깅페이스 버킷으로 전달하는 아키텍처로 큐웬3의 1.2GB 대비 20~35MB 수준 감축 정량을 재현 가능성 관점에서 검증한다.

❓ 열린 질문

• 70억·1조급 모델 외 중간 규모 모델에서는 델타 동기화가 전체 전송량 절감에서 어떤 스케일링 패턴을 보이는가?
• 학습률이나 bf16 정밀도 조건이 바뀌면 연속 단계 간 가중치 비트 불변률은 여전히 98% 이상을 유지하는가?
• 단일 허깅페이스 버킷으로 분리형 훈련을 돌릴 때 정책 반영 지연이 실제 서비스 허용 범위를 넘어서는 지점은 어디인가?