토큰 흐름을 유지하기: 16개의 오픈소스 RL 라이브러리에서 얻은 교훈
TL;DR – Hugging Face는 16개의 오픈소스 강화학습(RL) 라이브러리를 조사했으며, 성공적인 모든 비동기 RL 시스템이 추론과 훈련을 서로 다른 GPU 풀로 분리하고, 롤아웃 버퍼를 사용하며, 모델 가중치를 비동기적으로 푸시한다는 것을 발견했습니다; Ray가 지배적인 오케스트레이션 프레임워크이며, NCCL 브로드캐스트가 일반적인 가중치 동기화 방법이고, LoRA와 Mixture‑of‑Experts(MoE) 훈련 지원은 아직 부족합니다.
1. 왜 비동기 RL이 중요한가
비동기 RL은 동기식 훈련 시 대형 언어 모델(LLM)이 최대 60 %의 실제 시간 동안 유휴 상태가 되게 하는 생성 병목 현상을 제거합니다.
동기식 파이프라인에서는 32 K 토큰 롤아웃 배치를 32 억 파라미터 모델에 대해 실행하면 몇 시간이 걸릴 수 있으며, 그 동안 그래디언트 업데이트에 할당된 GPU는 유휴 상태에 머뭅니다. 추론과 훈련을 별개의 GPU 풀로 분리하고 이를 롤아웃 버퍼로 연결함으로써, 생성은 이전에 생성된 데이터를 트레이너가 소비하는 동안 계속될 수 있어 GPU 활용도가 크게 향상됩니다.
2. 조사 개요
Hugging Face는 16개 오픈소스 비동기 RL 라이브러리(AReaL, ART, Atropos, MILES, NeMo‑RL, OAT, open‑instruct, PipelineRL, PRIME‑RL, ROLL, SkyRL, SLIME, TorchForge, Tunix, verl, verifiers‑rl)를 조사했습니다. 각 라이브러리는 7개의 직교 축에 걸쳐 평가되었습니다:
- 오케스트레이션 및 동시성 원시 요소 – 분산 구성 요소가 어떻게 조정되는지.
- 롤아웃 버퍼 설계 – 추론에서 훈련으로 생성된 샘플을 전달하는 데이터 구조.
- 가중치 동기화 프로토콜 – 업데이트된 파라미터가 추론 풀에 어떻게 푸시되는지.
- 구식 관리 – 오프‑폴리시 롤아웃을 처리하는 전략.
- 부분 롤아웃 처리 – 가중치가 변경될 때 진행 중인 생성에 어떤 일이 일어나는지.
- LoRA 훈련 지원 – 어댑터 전용 파라미터를 훈련하고 효율적으로 동기화하는 능력.
- 분산 훈련 백엔드 및 병렬성 – 병렬 전략(FSDP, Megatron, DeepSpeed, JAX 등)과 Mixture‑of‑Experts 지원 여부.
전체 비교 표는 원본 블로그 게시물에 제공되어 있으며, 아래 섹션에서는 각 축에 대한 주요 발견을 요약합니다.
3. 오케스트레이션 및 동시성 원시 요소
| 오케스트레이션 유형 | 설명 | 사용 라이브러리 |
|---|---|---|
| Distributed actor model (Ray) | 비동기 RPC, 객체 저장소, 내장된 내결함성을 갖춘 상태ful 액터. | AReaL, verl, SkyRL, NeMo‑RL, SLIME, MILES, ROLL, OAT, open‑instruct, 등 |
| Native Python concurrency | 스레드, asyncio, multiprocessing; 외부 런타임 없음. |
verifiers‑rl, PipelineRL (intra‑pool), ART, AReaL (asyncio‑based) |
| Pub/Sub message bus | Redis 스트림 또는 append‑only 파일을 통한 생산자/소비자 분리. | PipelineRL (inter‑pool), SLIME (async mode) |
| HTTP microservices | REST를 통해 통신하는 독립 서비스. | Atropos |
발견: Ray가 전체 환경을 장악하고 있으며, 8/16 라이브러리에서 사용됩니다. 그 액터 모델은 RL의 이질적인 구성 요소(추론 서버, 트레이너, 보상 모델, 환경 풀)와 일치하며 자동 스케줄링, 내결함성, Ray 객체 저장소를 통한 제로 복사 데이터 전송을 제공합니다. 그러나 Ray는 무거운 런타임을 추가하므로, 소규모 배포에서는 가벼운 대안(네이티브 Python, Pub/Sub)이 필요합니다.
4. 롤아웃 버퍼 설계
| 버퍼 패턴 | 깊이(최대 진행 중 배치 수) | 라이브러리 | 비고 |
|---|---|---|---|
| No buffer (synchronous) | 0 | TRL (current), ART (gather‑all‑then‑train) | 생성 및 훈련이 교대로 진행; 구식이 최대이지만 겹침이 없음 |
| Double‑buffer | 1 | verifiers‑rl, SLIME (async mode), MILES, OAT | 생성 배치 하나와 훈련 단계 하나가 정확히 겹침; 구식 최소 |
| Bounded async queue | 2–K | SkyRL, verl, NeMo‑RL, ROLL, PRIME‑RL, TorchForge, Tunix, open‑instruct, AReaL | 여러 배치가 진행 중; 구식은 큐 용량에 의해 제한됨 |
| Unbounded / stream | Unlimited | PipelineRL (Redis streams), SLIME (full async), Atropos | 연속 생성; 구식은 버전 태그 또는 중요도 샘플링으로 제어 필요 |
더 깊은 큐는 처리량을 개선하지만 명시적인 구식 관리가 필요합니다(축 4 참고).
5. 가중치 동기화 프로토콜 (축 3)
프로토콜은 트레이너에서 추론 풀로 새로운 가중치를 푸시할 때 지연 시간과 인터럽트 세분화를 결정합니다.
5.1 전송 메커니즘
| 메커니즘 | 일반적인 지연 시간 | 라이브러리 |
|---|---|---|
| NCCL broadcast | 100–500 ms | 대부분의 라이브러리 (PipelineRL, SkyRL, SLIME, MILES, ROLL, OAT, NeMo‑RL, PRIME‑RL, open‑instruct, AReaL) |
| NCCL + bucketing | ~20 ms | verl |
| Shared‑memory / CUDA IPC | Very low | NeMo‑RL, MILES |
| Filesystem + HTTP | Medium (seconds) | PRIME‑RL, AReaL, ART |
| HTTP PUT | High (seconds) | verifiers‑rl |
| JAX cross‑mesh | Low | Tunix |
5.2 인터럽트 세분화
| 세분화 수준 | 동작 | 라이브러리 |
|---|---|---|
| Never stop (per‑token swap) | 가중치는 포워드 패스 사이에 교체되며, 생성이 중단되지 않음. | PipelineRL, open‑instruct (opt‑in) |
| Per HTTP request abort | 진행 중인 HTTP 호출이 취소되고 프리픽스로 재시도됨. | SkyRL, SLIME |
| Soft pause (drain in‑flight) | 새 요청이 차단되고 기존 생성이 완료된 후 동기화. | PRIME‑RL, AReaL, open‑instruct (default), verl (async) |
| Per‑batch/blocking | 생성 및 훈련이 번갈아 진행; 동기화가 양쪽을 차단. | NeMo‑RL, ROLL, OAT, TorchForge, Tunix, verifiers‑rl, Atropos |
발견: PipelineRL만이 토큰 수준 포워드 패스 사이에 파라미터를 교체하는 진정한 중단 없음 가중치 업데이트를 구현합니다. 다른 모든 라이브러리는 더 거친 경계에서 일시 중지하므로, 추론이 구식 가중치로 실행되는 짧은 기간이 발생합니다.
6. 구식 관리 (축 4)
생성 및 훈련이 겹칠 때 롤아웃은 오프‑폴리시가 됩니다. 라이브러리들은 세 가지 직교 전략을 채택합니다:
- 샘플별 버전 거부 –
model_version이 설정 가능한 지연을 초과하는 샘플을 폐기. - 깊이 제한 – 진행 중인 배치 수를 제한하여 구조적으로 최대 버전 차이를 보장.
- 중요도 샘플링(IS) 보정 – 구식 샘플을 (\frac{\pi_{\theta}(a|s)}{\pi_{\text{old}}(a|s)}) 비율로 재가중(종종 클리핑).
| 라이브러리 | 버전 거부 | 깊이 제한 | IS 보정 |
|---|---|---|---|
| AReaL | ❌ | ✅ | ⚠️ (optional) |
| ART | — (synchronous) | — | — |
| Atropos | ❌ | ✅ | ❌ |
| MILES | ❌ | ❌ | ✅ |
| NeMo‑RL | ✅ | ❌ | ❌ |
| OAT | ❌ | ❌ | ✅ |
| open‑instruct | ❌ | ✅ | ⚠️ (optional) |
| PipelineRL | ✅ | ❌ | ❌ |
| PRIME‑RL | ✅ | ✅ | ✅ |
| ROLL | ❌ | ❌ | ✅ |
| SkyRL | ❌ | ✅ | ❌ |
| SLIME | ❌ | ❌ | ✅ |
| TorchForge | ✅ | ❌ | ❌ |
| Tunix | ❌ | ✅ | ❌ |
| verl | ❌ | ❌ | ✅ |
| verifiers‑rl | ❌ | ✅ | ❌ |
하이브리드 접근법(e.g., PRIME‑RL, open‑instruct)은 깊이 제한과 선택적 IS 가중치를 결합해 파이프라인을 단순화하면서도 견고성을 유지합니다.
7. 부분 롤아웃 처리 (축 5)
긴 컨텍스트 롤아웃(수만 토큰)은 가중치 업데이트가 도착했을 때도 아직 생성 중일 수 있습니다. 전략은 다음과 같습니다:
| 전략 | 라이브러리 | 설명 |
|---|---|---|
| Implicit continuation | PipelineRL | 중단 없음; 가중치 교체가 토큰 포워드 패스 사이에 발생 |
| Abort + retry with prefix | SkyRL, SLIME | 진행 중인 생성이 취소되고, 부분 프리픽스가 새로운 정책으로 재제출 |
| Explicit save/resume | verl (full async) | 부분 토큰 ID와 KV 캐시를 저장하고, 동기화 후 저장된 상태에서 생성 재개 |
| Group cancellation | PRIME‑RL | 구식 롤아웃 그룹을 폐기하고, 새로운 가중치 동기화가 HTTP 요청 사이에 발생 |
| Soft pause (drain) | AReaL | 새 작업이 중단되고, 기존 작업이 완료된 후 동기화 |
| No support | verifiers‑rl, OAT, Atropos, Tunix | 모든 진행 중인 생성이 끝난 후에만 동기화 |
Only PipelineRL and verl provide true never‑stop behaviour; the rest rely on abort‑or‑drain mechanisms.
8. LoRA 훈련 지원 (축 6)
LoRA는 학습 가능한 파라미터를 크게 줄여 어댑터 전용 가중치 동기화를 가능하게 하며, 작은 어댑터 델타만 추론 서버에 브로드캐스트합니다. 이는 7 B 이상 모델의 경우 NCCL 전송 시간을 수백 밀리초에서 서브 밀리초 수준으로 감소시킬 수 있습니다.
| 라이브러리 | LoRA 지원 여부 | 백엔드 | 어댑터 전용 동기화 |
|---|---|---|---|
| AReaL | ✅ | HF peft (FSDP2/Megatron) |
✅ |
| ART | ✅ | Unsloth / Megatron | ✅ |
| Atropos | ✅ | HF peft |
✅ |
| MILES | ✅ | Megatron‑Bridge | ✅ |
| NeMo‑RL | ✅ (custom) | DTensor / Megatron | ❌ (no evidence) |
| OAT | ✅ | HF peft |
✅ |
| open‑instruct | ❌ (code present but not wired) | — | ❌ |
| PipelineRL | ✅ | HF peft |
❌ (full broadcast) |
| PRIME‑RL | ✅ | Custom MultiLoRA | ✅ |
| ROLL | ✅ (DeepSpeed only) | DeepSpeed | ❌ |
| SkyRL | ✅ | HF peft / Megatron‑Bridge |
✅ |
| SLIME | ❌ | — | ❌ |
| TorchForge | ❌ | — | ❌ |
| Tunix | ✅ | qwix (JAX) | ✅ |
| verl | ✅ | HF peft / Megatron‑Bridge |
✅ |
| verifiers‑rl | ✅ | HF peft + FSDP2 |
✅ |
9. 분산 훈련 백엔드 및 병렬성 (축 7)
훈련 백엔드는 모델 크기 제한, 집합 통신 패턴, MoE와의 호환성을 결정합니다.
| 라이브러리 | 백엔드 | 병렬성 (DP/TP/PP/EP) | MoE 지원 |
|---|---|---|---|
| AReaL | FSDP2, Megatron, Archon | DP, SP, TP, PP, CP, EP | ✅ |
| ART | Unsloth, Megatron | DP, TP, EP | ✅ |
| Atropos | PyTorch native, TRL | DP | ❌ |
| MILES | Megatron, FSDP2 | DP, TP, PP | ✅ |
| NeMo‑RL | DTensor, Megatron | DP, SP, TP, PP, CP, EP | ✅ |
| OAT | DeepSpeed | DP, TP | ❌ |
| open‑instruct | DeepSpeed | DP, SP | ❌ |
| PipelineRL | DeepSpeed | DP, SP | ❌ |
| PRIME‑RL | FSDP2 | DP, TP, CP, EP | ✅ |
| ROLL | DeepSpeed, Megatron, FSDP2 | DP, SP, TP, PP, CP, EP | ✅ |
| SkyRL | FSDP, Megatron‑Bridge | DP, SP, TP, PP, EP | ✅ |
| SLIME | Megatron | DP, TP, PP, SP | ✅ |
| TorchForge | FSDP2 (Monarch) | DP, TP, CP | ❌ |
| Tunix | JAX/XLA | DP, TP | ❌ |
| verl | FSDP, Megatron | DP, SP, TP, PP, CP, EP | ✅ |
| verifiers‑rl | DeepSpeed | DP | ❌ |
핵심 함의: MoE 훈련(전문가 병렬성)은 EP를 명시적으로 처리하는 Megatron 또는 FSDP2 기반 라이브러리(AReaL, verl, PRIME‑RL, SkyRL, ROLL, NeMo‑RL)에서만 지원됩니다. ZeRO만 사용하는 라이브러리(DeepSpeed, PyTorch FSDP without EP)는 MoE 체크포인트를 로드할 수 있지만, 모든 전문가가 각 랭크에 샤드되어 있어 희소성 이점을 잃습니다.
10. 새로운 설계 압력
10.1 비평가‑없는 알고리즘
값 네트워크(예: GRPO, REINFORCE++)를 제거하면 메모리가 확보되어 더 큰 롤아웃 배치를 사용할 수 있지만, 가중치 업데이트 빈도가 증가합니다. 정책 드리프트가 G = 8‑32와 같은 큰 그룹 크기에서 가속되므로 구식 관리가 더욱 중요해집니다. 따라서 샘플별 버전 태깅과 IS 보정이 안정적인 훈련에 필수적입니다.
10.2 프로세스 보상
중간 추론 단계(프로세스 보상 모델)를 평가하면 생성과 훈련 사이에 비트리비얼하지 않은 계산 단계가 추가됩니다. 따라서 비동기 파이프라인은 PRIME‑RL 및 NeMo‑RL에서처럼 트레이너와 동시에 실행되는 reward‑actor를 포함해야 합니다. 이를 생략하면 보상 계산이 새로운 병목이 됩니다.
10.3 다중 에이전트 공동 진화
다중 에이전트 자체 플레이는 스트래글러 문제를 복합시킵니다: 유효 롤아웃 길이가 에이전트당 길이의 곱이 되며, 분산이 급격히 증가합니다. 버퍼 설계는 전체 다중 에이전트 에피소드를 단일 원자 단위로 취급해야 하며, 구식 전략은 샘플이 아닌 에피소드 수준의 버전 추적이 필요합니다.
10.4 MoE에 대한 훈련‑추론 불일치
DeepSeek‑v3.2에서 두 가지 구조적 불일치가 확인되었습니다:
- 전문가 라우팅 불일치 – 부동소수점 차이로 인해 추론과 훈련이 동일 토큰에 대해 다른 전문가를 선택할 수 있습니다. 해결책("Keep Routing")은 추론 서버가 라우팅 결정을 반환하고 트레이너가 이를 강제하도록 요구합니다.
- 샘플링‑마스크 불일치 – 생성 시 top‑p/top‑k 절단이 전체 vocab 훈련 포워드 패스와 다른 행동 공간을 만들게 됩니다. "Keep Sampling Mask"는 절단 마스크를 기록하고 훈련 시 재적용합니다. 현재 조사된 어떤 라이브러리도 이 두 기능을 구현하고 있지 않아, 향후 비동기 RL 시스템에 중요한 격차가 있음을 보여줍니다.
10.5 비동기 RL로서의 증류
온‑폴리시 증류(학생이 생성하고 교사가 점수)는 RL과 동일한 비동기 패턴을 따릅니다: 생성 → 점수 매기기 → 그래디언트 업데이트 → 가중치 동기화. 따라서 모든 설계 축이 그대로 적용됩니다. 완전한 범용 비동기 트레이너는 점수 매기기 단계를 하드코딩된 검증자가 아니라 플러그인 가능한 컴포넌트로 노출해 RL과 증류 워크로드 모두를 지원해야 합니다.
11. TRL 비동기 트레이너 설계 선택
조사 결과를 바탕으로 TRL 팀은 향후 비동기 트레이너에 대해 다음과 같은 구체적인 결정을 내릴 예정입니다:
- Lightweight orchestration – 가능한 한 무거운 런타임을 피하고, 네이티브 Python
asyncio와 최소한의 액터 추상화를 사용합니다. - Bounded queue with per‑token
model_version– 각 토큰이 생성한 정책 버전을 담아 세밀한 IS 보정을 가능하게 하고, 사후 보정 필요성을 없앱니다. - NCCL weight sync with packed transfers – vLLM의
NCCLWeightTransferEngine을 버킷화하여 ~20 ms 청크로 가중치를 브로드캐스트, 동기화 지연을 크게 감소시킵니다. - Partial‑rollout support – 에이전시 워크로드를 위해 프리픽스‑재개 메커니즘을 구현, 가중치 업데이트 후에도 진행 중인 생성이 새로운 정책 아래에서 계속될 수 있게 합니다.
이 선택들은 생태계 전반에서 관찰된 최선의 실천 방안을 결합하면서, 더 넓은 TRL 커뮤니티가 접근하기 쉬운 구현을 목표로 합니다.
핵심 요약: 비동기 RL 훈련은 이제 대규모 LLM 사후 훈련의 사실상 표준이 되었습니다. 조사 결과는 추론 분리, 롤아웃 버퍼, 비동기 가중치 푸시가 명확히 수렴하고 있음을 보여주며, Ray가 주요 오케스트레이션 레이어이고 NCCL 브로드캐스트가 기본 동기화 방법입니다. 향후 작업은 LoRA 전용 동기화, MoE 라우팅 일관성, 다중 에이전트 에피소드 처리를 다루어 차세대 최첨단 모델에 발맞춰야 합니다.