허깅페이스, TRL에 Delta Weight Sync 도입해 RL 가중치 전송 99% 압축

허깅페이스가 비동기 강화학습(async RL) 가중치 동기화 비용을 두 자릿수 배수로 줄이는 'Delta Weight Sync' 기능을 TRL에 추가하는 PR을 공개했다. 두 번의 RL 옵티마이저 스텝 사이에서 bf16 가중치의 99% 이상이 비트 단위로 동일하다는 사실에 착안해, 바뀐 원소만 sparse safetensors로 인코딩해 허깅페이스 허브의 Bucket에 올리고 vLLM이 받아 가게 만든 것이 핵심이다.

효과는 작은 모델에서도 분명하다. Qwen3-0.6B 기준 스텝당 전송량이 1.2GB에서 20~35MB로 줄었다. 7B 모델을 bf16로 그대로 보내면 14GB, 1T 프런티어 모델 체크포인트는 약 1테라바이트가 매 스텝 오가야 하는데, 델타 인코딩을 쓰면 대역폭 부담이 한꺼번에 두 자릿수 배수로 무너진다는 설명이다.

비교 가능한 결과는 업계에도 있다. 허깅페이스는 Fireworks의 'Frontier RL Is Cheaper Than You Think' 글이 1T fp8 모델 한 스냅샷을 1024GiB로 잡았고, 인접 체크포인트 평균 델타가 20.3GiB로 모델의 1.98%에 그친다고 보고한 점을 인용했다. 같은 글은 'bf16 가중치의 98% 이상이 연속 체크포인트 사이에서 비트 동등을 유지한다'고 밝혔다.

Cursor의 Composer 2 보고서도 비슷한 그림을 그린다. 트레이닝과 추론을 다른 리전에서 돌리면서 공유 S3 버킷을 통해 압축된 가중치 디프만 매 스텝 올리고, 각 클러스터가 독립적으로 델타 체인을 다운로드해 재구성하는 식이다. 두 클러스터가 파라미터에 대해 직접 통신할 필요가 없다는 점이 핵심이다.

99% 희소성의 근거는 bf16 산술 자체에서 나온다. bf16은 가수부가 7비트로, 두 인접 표현값 사이 간격이 |w|·2^-7 수준이고, |Δw|가 |w|/256보다 작으면 업데이트가 반올림으로 사라진다. 학습률이 3×10^-6 정도인 RL 설정에서 Adam의 정규화된 스텝이 대략 1 수준이라 |Δw|는 약 3×10^-6, 대부분 가중치 |w|는 10^-2에서 10^-1 수준이라 임계치 4×10^-5에서 4×10^-4를 밑돈다. 옵티마이저가 속삭이지만 bf16이 듣지 못한다는 비유로 정리된다.

이 주장은 PULSE 논문(Mihai & Belilovsky, 2026)에서 정형화돼 있다. 흡수 한계 10η와 실효 한계 η, bf16 가시 한계 |w|/256을 정의하고, η=3×10^-6에서 흡수 한계 자체가 거의 모든 가중치의 가시 한계보다 작음을 보였다. Qwen2.5(0.5B·1.5B·7B), Llama-3.2-3B, Gemma-3-4B에서 400 학습 스텝에 걸쳐 평균 스텝당 희소성 약 99%, 표준편차 0.2~0.4%를 실측했고 최악의 스텝도 98% 위로 유지됐다.

구현부에서는 허브의 Bucket이라는 신형 레포 타입이 등장한다. 커밋·PR·LFS 절차 없이 파일을 추가·조회·다운로드만 하는 고빈도 객체 저장용 레포이며, 파이썬 API는 batch_bucket_files와 download_bucket_files 두 함수로 정리된다. 트레이너가 sparse safetensors 한 조각을 올리면 추론 측은 같은 키로 받아 간다.

저장 계층은 Xet으로 받쳐진다. 콘텐츠 기반 청크 분할과 중복 제거를 하기 때문에, 게으르게 전체 가중치 앵커를 매 스텝 통째로 올려도 사실상 바뀐 청크만 실제로 전송된다. sparse 인코딩과 Xet이 겹치면서 압축 효과가 또 한 번 늘어난다는 것이다.

마지막 시연은 분리형 아키텍처다. 허깅페이스 팀은 트레이너를 한 박스에, vLLM 추론을 허깅페이스 Space에, Wordle 환경을 또 다른 Space에 두고 가중치는 공용 허브 Bucket으로만 흐르게 한 풀 디스어그리게이티드 학습을 돌려 보였다. 공유 클러스터, RDMA, VPN 없이 비동기 RL이 굴러간다는 것이 결론이다.