Miles v0.1: Production-Level Post-Training

논문 링크

Miles v0.1: 프론티어 RL 사후학습을 위한 “검증·청결·확장 가능"한 풀스택 시스템

TL;DR : Miles는 rolluout 생성과 트레이닝이 서로 다른 엔진·커널·정밀도로 돌아가며 발생하는 train-rollout mismatch를 시스템 차원에서 해결하는 풀스택 RL 사후학습 프레임워크다. SGLang 기반 롤아웃, Megatron-LM/FSDP 트레이너, 세 가지 가중치 동기화 수송(broadcast/P2P/disk-delta)을 하나로 묶고, 토큰 정확성(TITO)과 전문가 라우팅 재현(R3)까지 보장한다. 종단 사례 연구로 GLM-5.2 744B-A40B 를 64개 GB300 GPU에서 완전 비동기 에이전틱 RL로 학습시켜 중앙값 스텝 263초 를 달성했다(근거: §9.2, Fig. 5).

핵심 아이디어

Miles의 모든 설계는 “컴포넌트는 검증(verified)되고, 깨끗(clean)하고, 커스터마이즈 가능(customizable) 해야 한다"는 단일 원칙으로 귀결된다(근거: §1). 이 원칙이 구체화된 곳이 바로 RL 훈련 루프의 세 단계다(근거: §1.1, Fig. 1).

1. Rollout: SGLang 엔진이 궤적(trajectory)을 생성한다. 에이전틱 RL에서는 여러 턴에 걸쳐 도구를 쓰고 외부 환경과 상호작용한다.
2. Training: 트레이너(Megatron-LM 또는 FSDP)가 완성된 궤적 그룹을 소비해 RL 손실을 계산하고 정책을 갱신한다.
3. Weight update: 새 가중치를 롤아웃 엔진에 동기화한다.

핵심 통찰은 이 세 단계가 반드시 lockstep으로 돌 필요가 없다는 점이다. 동기식으로 번갈아 돌리면 트레이너는 배치에서 가장 느린 궤적을 기다리고, 엔진은 옵티마이저가 끝나기를 기다린다. Miles는 완전 비동기 모드를 제공해 생성과 학습을 동시에 진행시킨다(근거: §2.2). 그리고 이 “동시 진행"을 가능하게 하는 것이 바로 수치적 정합성(fidelity)이다 — 롤아웃이 샘플링한 토큰을 트레이너가 정확히 재현하지 못하면 그래디언트가 조용히 오염된다(근거: §2).

배경: 그들이 해결한 문제

사후학습(post-training)은 사전학습된 언어 모델을 유용한 모델로 바꾸는 단계다. 그런데 프론티어 규모의 사후학습은 더 이상 “짧은 completion에 대한 generate-then-update"가 아니다(근거: §1). 세 가지 구조적 난제가 겹친다.

1. 롤아웃이 다중 턴·도구 사용·외부 환경 행동으로 확장됐다. 한 궤적이 에이전트의 전체 에피소드(메시지 + 도구 호출 + 환경 응답)가 되어버렸다(근거: §2).
2. 모델이 조 단위 파라미터의 MoE로 커졌다. 지연에 민감한 롤아웃과 처리량 중심의 학습을 동시에 돌리려다 보면 필연적으로 버블(bubble)과 유휴 시간이 생긴다(근거: §1).
3. 롤아웃 엔진과 트레이너 사이의 수치 간극(gap)이 커지면 목적함수 자체가 무효화된다. SGLang과 Megatron은 서로 다른 커널·정밀도·배치를 쓰므로, 동일 가중치·동일 궤적에서도 서로 다른 확률을 부여한다. 이 중요도 비율(importance ratio)이 1에서 멀어지면 정책을 개선해야 할 업데이트가 오히려 정책을 망가뜨린다(근거: §2.4, §3.4).

특히 MoE의 전문가 라우팅 불일치는 치명적이다. 롤아웃이 토큰에 대해 전문가 $\{2, 7\}$ 을 선택했는데 트레이너가 다른 커널·정밀도로 다시 라우팅해 $\{2, 8\}$ 을 고르면, 샘플에 실제로 기여한 전문가는 업데이트를 받지 못하고 기여하지 않은 전문가가 받는다. 레이어 수 × 시퀀스 수만 토큰 × 수천 스텝에 걸쳐 누적되면, Ma et al.이 보고한 대로 MoE RL이 급격히 불안정해지고 재앙적 붕괴(catastrophic collapse) 로 이어질 수 있다(근거: §2.5, [19]).

새로운 접근법: Miles — 검증 가능한 풀스택 RL 루프

Miles의 독창성은 개별 알고리즘 하나가 아니라, 수치 정합성을 보존한 채 생성·학습·동기화를 동시에 돌리는 시스템 설계에 있다. 핵심 메커니즘을 셋으로 나눠 보자.

1) TITO: 토큰 정확성을 지키는 세션 서버

기존 멀티턴 파이프라인은 모델 출력이 메시지 파싱 → 도구 실행 → 채팅 템플릿 렌더링을 거치며 토크나이제이션이 바뀌거나 과거 추론이 잘려나간다. 이러면 “샘플링된 토큰"과 “트레이너가 보는 토큰"이 어긋나고, 트레이너는 실제로 발생한 적 없는 궤적에 대해 업데이트하게 된다(근거: §2.4).

Token-In-Token-Out(TITO) 세션 서버는 토큰화 제어권을 하네스가 아니라 서버가 갖게 해 이 간극을 닫는다. 첫 턴에 템플릿을 토큰 ID로 렌더링하고, 매 턴 성공 시 그 프롬프트 ID와 출력 토큰 ID·로그 확률·라우팅된 전문가까지 체크포인트로 저장한다. 이후 턴에는 가장 깊은 적용 가능 체크포인트를 재사용해 새로 추가된 접미사만 토큰화한다(근거: §2.4, Fig. 3). 서버는 트랜잭션을 선형(linear)과 분기(branching) 규칙으로 확장하며, 클로드 코드처럼 자체 컨텍스트를 압축·분기하는 하네스까지 수용한다(근거: §2.4.1).

2) R3: MoE 전문가 라우팅 재현

토큰 정확성만으론 MoE의 로그 확률을 재현할 수 없다. Rollout Routing Replay(R3) 는 각 토큰의 전문가 할당을 롤아웃 데이터의 일부로 취급해, 트레이너가 라우팅을 다시 계산하지 않고 롤아웃 당시의 할당을 그대로 재생(replay)하게 한다(근거: §2.5). --use-rollout-routing-replay를 켜면 SGLang이 라우팅된 전문가를 토큰과 함께 반환하고, 순전파에서 각 토큰이 롤아웃 때와 정확히 같은 전문가를 거친다. TITO가 라우팅 전문가까지 기록하므로 이 재현은 멀티턴 에피소드 전체를 덮는다(근거: §2.4, §2.5).

3) 세 가지 가중치 수송

프론티어 규모에선 가중치 동기화 자체가 병목이 된다. Kimi K2 1T-A32B의 전체 NCCL broadcast는 거의 1분(58.30초)이 걸린다(근거: §4, Tab. 8). Miles는 연결 토폴로지에 따라 세 수송을 제공한다.

P2P의 효과는 극적이다. Kimi K2 1T-A32B에서 53.28초 → 7.23초(-86.4%), GLM-5 744B-A40B에서 58.30초 → 8.48초(-85.5%) 다(근거: §4.2, Tab. 8). 다만 단일 노드에선 P2P가 broadcast보다 최대 약 70% 느리므로, 기본은 broadcast다(근거: §4.2).

이 외에도 Miles는 저정밀도 훈련(FP8 blockwise·MXFP8·NVFP4), 메모리 오프로드(정지한 액터 퇴거 + 옵티마이저 상태 스트리밍), 그리고 LoRA RL·On-policy Distillation·True-on-policy alignment·Diffusion이라는 확장 레시피까지 얹는다(근거: §3.1, §3.2, §5, §6).

작동 원리: 구체적인 예시로 살펴보기

전문가 라우팅 불일치를 아주 작은 사례로 축약해 보자(근거: §2.5). 어떤 토큰에 대해 MoE 라우터가 상위 $k=2$ 개 전문가를 고른다고 하자.

• 롤아웃(SGLang, FP8)이 전문가 $\{2, 7\}$ 을 선택했다.
• 트레이너(Megatron, BF16)가 같은 가중치로 다시 라우팅하면, 수치 차이 때문에 $\{2, 8\}$ 을 선택한다.
• 결과: 전문가 7은 샘플에 기여했는데도 업데이트를 받지 못하고, 전문가 8은 기여하지 않았는데도 업데이트를 받는다.

R3는 이 문제를 “다시 계산"이 아니라 “기록된 할당 재생"으로 풀어, 트레이너가 전문가 $\{2, 7\}$ 을 그대로 사용하게 만든다(근거: §2.5).

비용을 따져 보면 재생은 저렴하지만 운반이 비싸다. 라우팅 텐서는 토큰 수 $N$, 레이어 수 $L$, top-k $k$ 에 대해

의 32비트 정수로 늘어난다. 32K 토큰 × 60 레이어 × $k=8$ 이면 궤적당 약 60MB 다(근거: §2.5). 그래서 R3는 기본이 아니라 레시피별 선택이며, GLM-5.2 레퍼런스 런은 이를 꺼둔다(근거: §2.5).

옵티마이저 상태 스트리밍도 직관적이다. 대형 런에서 옵티마이저 상태는 HBM을 가장 많이 잡아먹는다 — FP32 마스터 가중치와 두 Adam 모멘트를 합쳐 파라미터당 12바이트다(근거: §3.2.2). Miles는 파라미터를 버킷으로 나눠, 버킷을 갱신할 때만 해당 파일을 HBM에 올리고 갱신 후 퇴거한다. Qwen3-30B-A3B에서 액터 오프로드가 24초 → 5.2초, 재로드가 8.9초 → 1.3초로 줄었다(근거: §3.2.2).

On-policy Distillation의 신호는 어디서 오는가? 학생이 스스로 샘플링한 토큰 $x_t$ 에 대해, 학생과 교사의 로그 확률 차이

가 그 위치에서의 역(reverse) KL 발산의 1-샘플 추정치다. 이 값이 양수면 학생이 그 토큰을 과도하게 선호한 것이고, 음수면 교사가 더 선호한 것이다(근거: §5.2, Fig. 4). Miles는 이 신호를 손실이 아니라 어드밴티지에 접어넣어 GRPO·PPO와 조합 가능하게 한다(근거: §5.2).

성능 검증: 주요 결과

종단 사례 연구: GLM-5.2 744B-A40B on 64×GB300

가장 주목할 결과는 §9의 종단 런이다. GLM-5.2 744B-A40B(총 744B / 활성 A40B 파라미터)를 64개 GB300 GPU에서 터미널 사용 코딩 태스크(terminal-bench-2)로 완전 비동기 RL 학습시켰다(근거: §9, Tab. 9).

세 가지 관찰이 이어진다(근거: §9.2, Fig. 5).

1. 744B 모델을 32개 GPU로 학습한다. 병렬 레이아웃(TP2/PP4/CP4/EP8)이 64개 중 절반만 쓰고 나머지 절반을 생성에 남긴다. 이때 랭크당 옵티마이저 상태가 약 279GB 로 GPU 메모리를 초과해, 디스크 스트리밍이 “최적화"가 아니라 필수다(근거: §9.1).
2. 중앙값 스텝 시간 263초 (처음 측정된 30스텝 기준; 0번째 스텝의 1,042초 워밍업은 제외)(근거: §9.2, Fig. 5a).
3. 생성과 학습이 가중치 갱신 사이에 겹친다. 샘플 단위 보충(sample granularity)이 궤적이 끝나는 즉시 슬롯을 채워, fleet에서 동시에 약 90~100개 요청이 생성된다. 어피니티(affinity) 라우팅 덕에 프리픽스 캐시 적중률 96% 를 유지한다(근거: §9.2, §2.1).

수치 건전성도 확인했다. 롤아웃 엔진과 트레이너의 로그 확률 발산(divergence)은 100스텝 평균 0.0369 로 시작값 근처에서 끝나고, 잘린 중요도 샘플링(TIS)이 이를 보정한다(근거: §9.2, Fig. 5b). 원시 태스크 보상은 9스텝 이동평균 기준 0.438 → 0.556 로 상승했지만, 단일 런이라 이는 “측정된 개선"이 아닌 “관찰"로만 보고된다(근거: §9.2, Fig. 5c).

P2P 가중치 수송: fleet 폭이 넓을수록 유리

이득은 모델 크기가 아니라 fleet 폭에 비례한다(근거: §4.2, Tab. 8).

On-policy Distillation: 응답 길이 56% 단축

Qwen3.5-35B-A3B 문서화 런에서, 교사(동일 모델을 검증 가능 보상으로 5스텝 RL 개선한 버전)가 신호를 주고 태스크 보상은 0으로 둔 채 5스텝 학습했다. 응답 길이는 14,070 → 6,132 토큰으로 줄었고 정확도는 84.0% → 85.2%로 움직였으나, 평가 표준오차(약 1.6포인트) 안이라 “신뢰할 만한 변화 없이 길이 56% 감소"가 정확한 결론이다(근거: §5.2).

Miles-Diffusion: 스트리밍 보상

LTX-2.3 레시피에서 마이크로그룹 단위 스트리밍 보상이 롤아웃 시간을 157.4초 → 87.6초, 총 스텝 시간을 321.9초 → 252.1초로 줄였다(근거: §6).

우리의 관점: 강점, 한계, 그리고 이 연구가 중요한 이유

강점 은 시스템 논문으로서의 정직함이다. 첫째, “지원한다"는 말의 의미를 증거 수준(evidence level) 으로 명시해, 모델·하드웨어·레시피 각각이 어느 정도로 검증됐는지 구분한다(근거: §6, §7.1). 둘째, Day-0 모델 지원이라는 가장 가혹한 기준을 실제로 통과했다 — Kimi K3, DeepSeek-V4, GLM-5.2, Qwen3.8, Inkling, Nemotron 3 Ultra 여섯 모델을 가중치 공개 당일에 지원했다(근거: §7.1). 셋째, 수치 정합성을 1순위 목표로 격상시켰다. R3, TITO, true-on-policy alignment가 모두 “조용한 그래디언트 오염"을 막는 데 집중한다는 점은, RL 스케일링에서 시스템이 성능의 숨은 변수임을 보여준다(근거: §2.4, §2.5, §5.3).

한계 도 명확하다. 첫째, 커버리지가 고르지 않다. true-on-policy alignment는 밀집 Qwen3 0.6B/4B만, P2P 수송은 일부 모델 패밀리만, 비전-언어 세션 서버는 아직 미지원이다(근거: §5.3, §4.2, §2.4.3). 둘째, 저정밀도 포맷이 아직 Beta 단계로, MXFP8·NVFP4는 모델에 따라 다르게 동작할 수 있다고 스스로 인정한다(근거: §3.1, Tab. 5). 셋째, 정량적 검증이 얕다. 단일 런·단일 태스크 분포의 사례 연구(§9)는 보상 상승을 “관찰"로만 보고하며, “정확도·효율·신뢰성·확장성"이라는 네 가지 목표 중 정량적으로 직접 비교된 것은 효율(스텝 시간·수송 시간)뿐이다(근거: §9.2). 넷째, 시스템의 성능 자체보다 시스템의 존재에 무게가 실려 있어, 벤치마크 정확도로 경쟁하는 연구 논문과는 성격이 다르다.

그럼에도 이 연구가 중요한 이유는, “RL 사후학습이 실무에서 진짜 병목이 되는 지점"을 끝까지 추적했다는 점이다. 롤아웃과 트레이닝이 갈라지는 수치 간극, MoE 라우팅 불일치, 가중치 동기화의 1분 병목 — 이런 문제들은 벤치마크 점수에는 나타나지 않지만, 프론티어 규모의 훈련을 실제로 가능하게 만드는지 여부를 결정한다.

다음 단계는?: 앞으로의 길

저자들이 밝힌 현재 한계는 곧 로드맵이다: 비전-언어 세션 지원, 초기 단계의 정밀도 포맷, 일부 모델 패밀리에만 한정된 가중치 전송 경로다(근거: §10). 여기에 더해 합리적인 다음 단계를 제안해 보면:

• 검증의 정량화: “정확도” 목표를 reward·발산 지표의 다중 런 통계(분산, seed 평균)로 보강해, §9의 단일 런 관찰을 재현 가능한 측정으로 격상.
• R3의 오버헤드 최적화: 라우팅 텐서(궤적당 약 60MB)를 압축하거나, 비동기 RL에서 R3의 제한적 효과를 극복할 결합 보정 기법 탐색(근거: §2.5).
• true-on-policy의 커버리지 확장: 밀집 Qwen3 0.6B/4B를 넘어 MoE·저정밀도 레시피로 bit-exact 보장을 넓히기(근거: §5.3).
• disk-delta의 엔드포인트 통합: 외부 롤아웃 서비스 단일 엔드포인트 경로(문서상 “forthcoming”)를 실제로 구현해 하이브리드 배포 지원(근거: §4.3).

결국 Miles의 의의는 “하나의 새 알고리즘"이 아니라, 검증 가능하고 확장 가능한 사후학습 인프라의 레퍼런스 구현을 제시했다는 데 있다. 수치 정합성과 시스템 효율을 같은 무게로 다루는 이 설계가, RL 스케일링이 “점수 경쟁"에서 “엔지니어링 경쟁"으로 넘어가는 전환점을 보여준다.

논문 원문의 표

arXiv e-print 의 LaTeX 원본에서 기계적으로 옮긴 표입니다. 숫자는 논문의 값이며 모델을 거치지 않았습니다.

표 1. The three reasons the buffer drops a finished group. The first two are properties of the group, so they are checked as soon as it arrives; staleness depends on how long the group waited, so it is checked only when the trainer collects it. The run supplies the filter and the staleness limit and chooses whether dropped prompts are retried or discarded, except that filter-rejected groups are always discarded because they carry no gradient signal.

표 2. Buffer metrics reported on every training step, under the rollout/fully_async/ prefix. Staleness appears twice: once for the groups a step drew, and once for the groups still waiting.

표 3. The three evaluation modes under fully asynchronous rollout. Shared engines measure whichever weights the fleet most recently received, and new generation stops while they do so, although in-flight requests finish. The snapshot-based modes measure the exact weights in the snapshot they receive; an external backend sees only a checkpoint directory, so it can be any service, with or without SGLang.

표 4. Three nested rollout plug-in layers. The agent function is innermost, and each column to its right wraps the one before it; a ✓ means the external framework assumes that responsibility, and $\circ$ means Miles retains it. Group rewards are scores that need the whole group at once, such as ranking the trajectories against one another, as distinct from GRPO’s group-relative centering, which Miles always applies itself.

표 5. Low-precision formats with an end-to-end Miles recipe, against the BF16 baseline. NVFP4 nests an E4M3 scale per block inside one FP32 scale per tensor. FP8 blockwise runs on NVIDIA Hopper and Blackwell and on AMD MI350X and MI355X; MXFP8 and NVFP4 need Blackwell; A100 has no FP8 arithmetic and runs BF16 only.

표 6. The two training backends. Megatron-LM exposes model-parallel axes, while the current FSDP backend uses data-parallel sharding; a $\times$ marks what that backend does not yet implement, not a limit of FSDP itself.

표 7. The three weight-synchronization transports. All deliver the same converted weights but differ in the connectivity they assume and in how transfer volume scales with the fleet. When training and rollout are colocated on the same GPUs, the handoff is local and no transport is involved.

표 8. Time per weight update, P2P against NCCL broadcast, on H100 clusters with a 1 GB transfer bucket, averaged over steady-state steps and timed from the end of the generation pause to the return of the update call. Node counts are per side, with trainer and rollout fleets of equal size. The Kimi K2 times include about 884 ms of on-GPU requantization that its checkpoint requires after every transfer. The advantage grows with fleet width rather than model size, and appears already at two nodes per side.