14 분 소요

0. Introduction

Paper link

HTML link

Code link

한 줄 요약: Molt는 agent environment, vLLM rollout, Ray asynchronous runtime, NVIDIA AutoModel and FSDP2 trainer를 token-first contract로 연결하고, partial rollout과 policy staleness correction, MoE routing replay까지 명시적으로 다루는 compact PyTorch-native agentic RL framework다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

  • Agentic RL의 어려움이 GRPO or PPO 수식보다 environment loop, rollout transport, token alignment, weight synchronization에서 생기는 경우가 많다는 점을 정면으로 다룬다.
  • Agent를 framework callback이 아니라 plain Python program으로 두고 trainer와 environment logic를 분리한다.
  • Fully asynchronous rollout에서 behavior logprob와 learner logprob가 달라지는 문제를 correctness invariant로 취급한다.
  • Dense model, multimodal model, MoE model을 같은 PyTorch and FSDP2 path로 확장하려 한다.
  • Framework 성능을 과장하지 않고, head-to-head benchmark에서 policy update가 실제로 거부된 중요한 caveat까지 공개한다.

Molt는 새로운 reinforcement learning objective를 제안하는 논문이 아니다. Framework design paper에 가깝다. 핵심 질문은 다음과 같다.

Multi-turn agent trajectory를 대규모로 생성하고, asynchronous learner가 이를 소비하며, rollout 중간에 policy weight가 바뀌어도 token-level training semantics를 보존하려면 어떤 contract가 필요한가?

기존 RLHF framework는 actor, critic, reward model, reference model, generator, trainer, scheduler를 넓게 지원한다. 그만큼 abstraction surface도 커진다. Molt는 범용 기능 수를 늘리기보다 agentic RL research에서 gradient가 어디서 왔는지 읽을 수 있는 작은 stack을 목표로 한다.

1. Problem Setting

1-1. Problem definition

Agentic RL은 single-turn response RL보다 data path가 복잡하다.

  1. Environment is a program
    • Model은 answer token만 생성하지 않는다.
    • Tool call, observation, multi-turn state, external grader, image input이 trajectory에 들어간다.
  2. Rollout latency is irregular
    • 어떤 episode는 즉시 끝나고, 어떤 episode는 browser, code sandbox, simulator를 오래 사용한다.
    • Synchronous batch는 가장 느린 trajectory를 기다리게 된다.
  3. Policy changes during data generation
    • Trainer가 update하는 동안 rollout engine은 이전 weight로 request를 처리할 수 있다.
    • Partial rollout에서는 한 request의 앞 token과 뒤 token이 다른 policy version에서 생성될 수 있다.
  4. Token ownership is ambiguous
    • Prompt token, tool observation, assistant action, environment message가 한 sequence에 섞인다.
    • Loss를 어느 token에 적용할지 잘못 정하면 model이 생성하지 않은 token까지 policy gradient가 흐른다.
  5. Large MoE adds routing mismatch
    • vLLM rollout과 PyTorch trainer가 같은 token을 서로 다른 expert로 routing하면 recomputed logprob가 달라진다.
    • Async off-policy correction 이전에 forward semantics 자체가 불일치할 수 있다.
  6. Framework complexity hides gradients
    • 여러 backend and config layer가 겹치면 reward, advantage, normalization, mask가 어디서 적용되는지 추적하기 어렵다.

Molt는 이 문제를 algorithm catalog가 아니라 data and execution contract 문제로 본다.

1-2. Why previous approaches are insufficient

Large-scale RL framework는 서로 다른 목표를 가진다.

  • Broad algorithm coverage
  • Multiple training backends
  • Multiple rollout engines
  • Production fault tolerance
  • Large-scale Megatron parallelism
  • Multimodal and agent support

이 breadth는 강점이지만 research iteration에서는 다음 cost가 생길 수 있다.

  • Model-specific adapter와 backend-specific config가 많아진다.
  • Rollout object가 text, token, logprob, reward를 서로 다른 representation으로 이동한다.
  • New environment를 추가할 때 trainer code까지 수정하게 된다.
  • Async behavior-policy mismatch가 implicit하게 처리되거나 logging에서 사라진다.
  • Framework 내부의 averaging convention이 paper objective와 달라질 수 있다.

Molt가 선택한 방향은 narrower stack이다.

  • Training backend: NVIDIA AutoModel with FSDP2
  • Rollout engine: vLLM
  • Runtime and placement: Ray
  • Agent interface: Gymnasium-style Env or user-owned ChatAgent
  • Core language: plain PyTorch and Python

이 선택은 compatibility를 줄이는 대신 code path를 짧게 만든다. Paper snapshot은 RL path를 약 8.6K lines of code로 보고한다. 이후 repository README는 약 9.2K lines로 갱신되어 있으므로 code-size 숫자는 snapshot-dependent하다.

2. Core Idea

2-1. Main contribution

Molt의 contribution은 네 가지로 정리할 수 있다.

  1. Agentic-first programming model
    • Agent가 reward와 interaction loop를 plain Python으로 정의한다.
    • Trainer는 environment detail을 알 필요가 없다.
  2. Token-first transport contract
    • Token IDs, per-token behavior logprobs, action ranges, rewards, multimodal tensors를 aligned representation으로 유지한다.
    • Assistant-generated token만 loss mask에 포함한다.
  3. Fully asynchronous execution
    • Ray queue를 통해 rollout, training, weight sync를 overlap한다.
    • Partial rollout and in-flight refit를 지원한다.
    • Behavior-policy mismatch를 importance correction and sequence gate로 다룬다.
  4. PyTorch-native scale path
    • FSDP2, tensor parallelism, expert parallelism, context parallelism을 NVIDIA AutoModel path에 연결한다.
    • MoE routing replay로 rollout and training expert selection을 맞추려 한다.

2-2. Design intuition

Molt의 중심 invariant는 다음 문장이다.

Never train on a token the policy did not generate.

Agent trajectory를 sequence로 펴면 다음 token type이 섞인다.

  • User or system prompt
  • Environment observation
  • Tool result
  • Assistant reasoning or action
  • Compacted context summary
  • Final answer

Policy gradient는 assistant가 sampling한 action token에만 적용되어야 한다. 이를 action mask $m_t$로 쓰면 policy loss의 generic form은 다음과 같다.

\[L_{\mathrm{policy}} = - \frac{ \sum_t m_t w_t A_t \log \pi_{\theta}(a_t|s_t) }{ \sum_t m_t }\]
  • $m_t=1$: policy가 생성한 action token
  • $m_t=0$: prompt, observation, padding, external content
  • $w_t$: asynchronous mismatch를 보정하는 importance weight
  • $A_t$: sequence or token advantage

이 식에서 중요한 것은 exact estimator보다 mask and normalization이다. Agent environment가 길어질수록 observation token 수가 action token 수보다 많아질 수 있다. Denominator를 full sequence length로 잡으면 trajectory format에 따라 gradient scale이 달라진다. Molt는 whole-batch generated-token mean을 명시적으로 사용한다.

3. Architecture / Method

3-1. Overview

Component Role
Agent Environment interaction, tool loop, reward computation
Generator vLLM rollout and behavior logprob collection
Runtime Ray placement, asynchronous queues, worker lifecycle
Trainer NVIDIA AutoModel plus FSDP2 PyTorch update
Estimator Return, advantage, KL, importance correction
Weight sync Direct actor-to-vLLM parameter transfer
Transport contract Token IDs, logprobs, action spans, rewards, multimodal payloads
Scale path FSDP2 plus TP, EP, CP and optimizer offload

3-2. Module breakdown

1) Agent abstraction

Molt는 두 agent interface를 제공한다.

Env

Framework가 interaction loop를 소유한다.

  • reset() or initial prompt를 만든다.
  • Model action을 environment에 전달한다.
  • step()이 observation, termination, reward를 반환한다.
  • Gymnasium-style task에 적합하다.

ChatAgent

User code가 loop를 소유한다.

  • Agent는 OpenAI or Anthropic-compatible loopback server를 호출한다.
  • Tool orchestration, sub-agent, external grader를 자유롭게 구성한다.
  • Final Result object에 reward and trajectory information을 반환한다.

두 interface의 공통점은 reward가 plain Python이라는 점이다. Unit test, symbolic verifier, simulator state, LLM-as-a-judge call, multimodal grader를 environment 안에서 조합할 수 있다.

2) Token-first experience object

Experience는 rendered text만 전달하지 않는다. 최소한 다음 field를 aligned하게 유지한다.

  • Prompt and generated token IDs
  • Per-token rollout logprobs
  • Action span or action mask
  • Reward and optional per-turn metadata
  • Model version or refit boundary
  • Image and multimodal tensors
  • Termination and compaction boundary

이 design은 trainer가 chat template string을 다시 tokenize하면서 token boundary가 달라지는 문제를 줄인다. Chat template의 assistant span은 model-native template에서 파생되고 hard-coded marker에 의존하지 않는다.

3) Context compaction handling

Long-horizon agent는 context limit 때문에 old turns를 summary or compressed state로 바꿀 수 있다. 문제는 compacted context가 model이 직접 생성한 action token과 동일하지 않다는 점이다.

Molt는 compaction event를 감지해 trajectory segment를 분리한다. Compacted prefix는 next rollout의 prompt가 될 수 있지만, original action으로 간주해 loss를 다시 적용하지 않는다.

이 처리 없이는 다음 오류가 생길 수 있다.

  • Summary token에 policy loss를 적용한다.
  • Same action token을 pre-compaction and post-compaction sequence에서 중복 학습한다.
  • Behavior logprob와 reconstructed token sequence가 맞지 않는다.

4) Fully asynchronous loop

Architecture는 세 box로 단순화된다.

  1. Agent and rollout workers
  2. vLLM generation engines
  3. PyTorch trainer actor

Ray가 placement and queue를 관리한다. Rollout worker는 experience를 queue에 넣고, trainer는 준비된 batch를 즉시 소비한다. Trainer update and rollout generation이 overlap되므로 synchronous generation barrier를 줄인다.

이때 throughput gain은 free가 아니다. Queue가 길어질수록 experience가 old policy에서 왔을 가능성이 커진다. Molt는 behavior logprob를 보존하고 train-time logprob와 비교한다.

5) Partial rollout and in-flight refit

Long request가 끝날 때까지 weight update를 미루면 fresh policy deployment가 느려진다. Molt는 in-flight request를 pause하고 new weight로 engine을 refit한 뒤 resume할 수 있다.

한 trajectory 안에서도 token generation policy가 바뀔 수 있으므로 각 token의 behavior logprob가 필요하다. Molt는 partial rollout을 correction 없이 허용하지 않는 invariant를 둔다.

Per-token importance ratio는 다음과 같다.

\[\rho_t = \frac{ \pi_{\mathrm{train}}(a_t|s_t) }{ \pi_{\mathrm{rollout}}(a_t|s_t) }\]
  • $\pi_{\mathrm{rollout}}$: token을 실제 생성한 behavior policy
  • $\pi_{\mathrm{train}}$: learner가 update할 current policy

Molt는 token-level mask, clip, truncation과 sequence-level rejection gate를 제공한다. Ratio가 지정 band 밖이면 gradient를 버리거나 제한한다.

6) Sequence-level gate

Token ratio가 individually 작아 보여도 긴 sequence 전체의 mismatch는 클 수 있다. Sequence-level score는 product ratio or geometric mean으로 만들 수 있다.

Geometric mean form은 다음과 같다.

\[\bar\rho_{\mathrm{geo}} = \exp \left( \frac{1}{T} \sum_{t=1}^{T} \log \rho_t \right)\]

Sequence score가 threshold band를 벗어나면 whole sequence를 reject한다. Accepted sequence에는 token-level importance weight를 유지할 수 있다.

이 gate는 asynchronous system의 correctness guard다. 다만 너무 tight하면 모든 batch를 버릴 수 있고 effective learning이 0이 된다. Molt의 head-to-head evaluation에서 실제로 이런 case가 보고된다.

7) Direct weight synchronization

Trainer와 rollout engine 사이의 weight sync는 checkpoint file round trip보다 direct communication을 사용한다. Actor process에서 vLLM engine으로 parameter를 전달하고 engine refit를 수행한다.

목표는 다음 세 가지다.

  • Disk I/O 제거
  • Weight version transition latency 감소
  • Partial rollout에서 refit boundary를 명시적으로 기록

Large sharded model에서는 TP and EP layout이 다를 수 있어 weight mapping이 중요하다. Molt는 NVIDIA AutoModel parallel layout과 vLLM serving layout을 연결한다.

8) MoE routing replay

MoE model에서 same hidden state라도 rollout and training backend의 numerical difference로 top-k expert 선택이 달라질 수 있다. Expert routing이 바뀌면 output logprob gap이 크게 발생한다.

Routing replay, R3는 rollout에서 선택된 per-token top-k expert route를 trainer forward에 재사용한다. 목적은 learner가 behavior logprob를 재계산할 때 같은 computation path를 따르게 하는 것이다.

Alternative로 router weight를 freeze할 수도 있다. Router drift를 줄이면 policy update가 expert assignment를 급격히 바꾸는 문제를 완화한다.

9) PyTorch-native trainer

Training path는 NVIDIA AutoModel and FSDP2를 중심으로 한다.

  • FSDP2 parameter sharding
  • Tensor parallelism, TP
  • Expert parallelism, EP
  • Context parallelism, CP
  • Adam optimizer state CPU offload
  • Transformer Engine fused attention

Repository의 Hugging Face fallback은 text and flash attention 중심의 제한된 path이며 native TP, EP, CP를 제공하는 primary route는 아니다. 따라서 PyTorch-native가 모든 Hugging Face model을 동일하게 자동 scale한다는 의미는 아니다.

4. Training / Data / Recipe

4-1. Data

Molt는 특정 dataset paper가 아니다. Agent program이 training data를 online으로 만든다.

Experience source는 다음을 포함할 수 있다.

  • Verifiable reasoning tasks
  • Multi-turn tool-use environments
  • Code execution and unit-test graders
  • VLM tasks with image payloads
  • LLM-as-a-judge environments
  • OpenAI-compatible external agent harness

Framework는 dataset schema보다 tokenized experience contract를 고정한다. Environment가 무엇이든 trainer가 받는 것은 generated-token span, behavior logprob, reward, optional multimodal payload다.

4-2. Training strategy

Supported estimators

Paper and repository가 제공하는 estimator family는 다음과 같다.

Estimator Core baseline or target
REINFORCE Raw return policy gradient
REINFORCE with baseline Value or mean baseline
RLOO Leave-one-out group baseline
GRPO Group-relative normalized advantage
Dr.GRPO Length-bias-reduced group objective
GAE / PPO Critic-based generalized advantage estimation
On-policy distillation Reverse KL to frozen teacher on student rollout

Molt의 설계 center는 algorithm novelty가 아니라 estimator를 plain function으로 만들고 masking, normalization, logprob source를 읽을 수 있게 하는 것이다.

Whole-batch token normalization

Variable-length agent trajectory에서는 sequence별 mean과 global token mean이 다르다. Molt는 generated action token 전체를 denominator로 사용하는 convention을 강조한다.

\[L = \frac{ \sum_{i=1}^{B} \sum_{t=1}^{T_i} m_{i,t} L_{i,t} }{ \sum_{i=1}^{B} \sum_{t=1}^{T_i} m_{i,t} }\]

이 방식은 짧은 sequence와 긴 sequence가 각각 1표를 갖는 sequence mean과 다르다. Objective choice에 따라 length bias가 달라질 수 있으므로 paper reproduction에서는 normalization convention을 반드시 확인해야 한다.

Optional KL and reference worker

Reference policy는 optional하다. KL coefficient가 0보다 크면 frozen reference worker를 사용한다. On-policy distillation에서는 같은 reference가 teacher 역할을 한다.

Critic path

GAE를 선택하면 별도 value model actor가 추가된다. Critic은 scalar value head, optimizer, checkpoint를 가지며 actor GPU와 colocate하거나 분리할 수 있다. Molt가 항상 single-model GRPO framework인 것은 아니다.

4-3. Engineering notes

1) Behavior logprob must be generated at rollout time

Learner가 current model로 old token logprob를 재계산한 값은 behavior logprob가 아니다. Async correction에는 token이 실제 sampling될 때의 logprob가 필요하다.

2) Action mask should be unit-tested

  • Tool observation에 mask 0
  • Assistant action에 mask 1
  • Context-compacted summary에 mask 0
  • Padding에 mask 0
  • Multi-turn assistant span이 모두 포함되는지 확인

Loss scalar가 정상이어도 mask가 틀리면 objective가 바뀐다.

3) Queue age is a training metric

Throughput dashboard에 다음을 추가해야 한다.

  • Experience age in learner steps
  • Policy version gap
  • Token ratio distribution
  • Rejected sequence fraction
  • Refit boundary count

4) Router agreement is separate from importance sampling

Importance sampling은 behavior and learner policy difference를 보정한다. Backend mismatch로 같은 weight에서도 routing이 다르면 먼저 forward equivalence를 해결해야 한다.

5) Repository is evolving

Paper snapshot의 code size and supported flags와 current main branch가 다를 수 있다. Blog 발행 시 exact commit, config, model support를 pinning하는 것이 좋다.

5. Evaluation

5-1. Main results

Molt evaluation은 model quality benchmark보다 system property에 집중한다.

1) Code footprint

Paper는 import graph 기준 RL path를 약 8.6K lines of code로 보고하고, 비교 대상으로 verl 약 62K, slime 약 25K를 제시한다. 이후 repository README는 Molt 자체를 약 9.2K lines로 갱신한다.

이 비교는 동일 기능 수의 framework size comparison이 아니다. Exclusion rule, backend breadth, model zoo, test and script 포함 여부에 따라 숫자가 달라진다. 의미는 Molt가 narrower design surface를 의도했다는 데 있다.

2) 35B multimodal MoE workload

Paper는 2-node configuration에서 8 GPU를 training, 8 GPU를 rollout에 사용하는 35B multimodal MoE workload를 분석한다.

Prefix cache

Cache hit 상태의 re-prefill이 약 0.05 second로 보고된다. 그러나 no-cache baseline을 같은 table에서 제공하지 않으므로 end-to-end speedup ratio로 해석하면 안 된다.

Multi-token prediction

MTP를 사용했을 때 measured generation phase가 329 second에서 64 second로 줄어든 setting이 보고된다. 이는 해당 workload and generation configuration의 result이며 모든 agent environment에서 같은 배율을 보장하지 않는다.

Optimizer offload

Adam optimizer state를 CPU로 offload하면 reported GPU memory가 64.7 GB에서 46.4 GB로 줄어든다. 반면 training phase time은 213 second에서 251 second로 약 18% 증가한다.

이 결과는 offload가 free memory optimization이 아니라 capacity-throughput trade-off임을 명확히 보여준다.

3) Qwen3-30B-A3B head-to-head

Molt와 slime의 controlled throughput comparison은 다음과 같다.

Framework Step time Throughput
Molt $119.4 \pm 2.3$ sec 461 token/GPU/sec
slime $109.5 \pm 10.3$ sec 502 token/GPU/sec

Slime의 point estimate가 더 빠르지만 uncertainty band가 겹치며, 저자들은 superiority claim을 하지 않는다.

더 중요한 caveat가 있다. 이 checkpoint의 distributed MoE forward mismatch 때문에 Molt의 sequence-level gate가 every batch를 reject했다. 즉 system은 rollout and training path를 실행했지만 effective policy update는 일어나지 않았다.

따라서 이 comparison은 다음을 보여준다.

  • End-to-end path throughput
  • Queue, generation, forward, synchronization overhead

하지만 다음은 보여주지 않는다.

  • Stable policy learning
  • Convergence parity
  • Final reward quality
  • Sample efficiency

35B workload에서는 같은 rejection issue가 나타나지 않았다고 보고되지만, head-to-head model에 대한 convergence claim은 upstream correction 이후로 남는다.

4) Frontier-scale path

Paper는 700B MoE model을 EP256 configuration으로 end-to-end loop에서 실행한 system path를 보고한다. Repository는 1T-class MoE scale path를 목표로 설명한다.

이 result는 framework가 model을 load, shard, rollout, synchronize할 수 있다는 scale-path demonstration이다. 700B or 1T-class actor의 RL convergence or task quality를 입증하는 결과는 아니다.

5-2. What really matters in the experiments

Molt 평가에서 중요한 것은 fastest number가 아니다.

  1. Effective update rate
    • Generated batch 수가 아니라 rejection 후 실제 gradient에 사용된 token 수를 봐야 한다.
  2. Policy-version mismatch
    • Async throughput이 높아져도 ratio gate가 대부분 data를 버리면 학습 효율은 낮다.
  3. Memory-throughput trade-off
    • Offload가 enable하는 model scale과 time penalty를 함께 보고해야 한다.
  4. Forward semantic agreement
    • Rollout and trainer가 same model이라고 가정하기 전에 logprob and routing parity를 검증해야 한다.
  5. Convergence, not only infrastructure reach
    • Large model을 한 step 통과시키는 것과 stable RL curve를 얻는 것은 다르다.

paper의 신뢰도를 높이는 부분이 바로 failed-update caveat다. Framework benchmark에서 가장 위험한 것은 높은 token throughput 뒤에 loss mask, rejected batch, stale trajectory가 숨는 것이다. Molt는 이 failure를 correctness gate가 잡았다는 점까지 evaluation result로 제시한다.

6. Limitations

  1. Single primary backend and rollout engine에 의존한다.
    • AutoModel and vLLM 조합은 code path를 줄이지만 SGLang, Megatron, alternative accelerator를 바로 지원하지 않는다.
  2. New RL algorithm contribution은 없다.
    • Estimator family는 알려진 method를 구현한다.
    • Scientific novelty는 framework contract and systems integration에 있다.
  3. Head-to-head benchmark가 convergence comparison이 아니다.
    • MoE forward mismatch로 every batch가 rejected되어 policy quality parity를 판단할 수 없다.
  4. Throughput comparison에 residual asymmetry가 남을 수 있다.
    • Kernel, caching, model config, engine version, batching detail이 framework별로 완전히 같기 어렵다.
  5. 700B path는 scale reach를 보여주지만 end-to-end learning result는 아니다.
    • Stable reward improvement와 cost curve가 추가로 필요하다.
  6. Fully async correction은 threshold-sensitive하다.
    • Tight gate는 data를 과도하게 버리고 loose gate는 biased update를 허용할 수 있다.
  7. Routing replay는 rollout metadata and trainer integration cost를 늘린다.
    • Custom MoE architecture마다 route representation을 맞춰야 할 수 있다.
  8. Enterprise concerns는 scope 밖이다.
    • Multi-tenant security, data governance, fault-domain isolation, audit policy, scheduler fairness가 충분히 다뤄지지 않는다.
  9. Framework usability에 대한 independent study가 없다.
    • Small codebase가 실제 researcher onboarding, debugging, extension speed를 얼마나 개선하는지 정량화되지 않았다.
  10. Repository main branch가 빠르게 변한다.
    • Paper number, API, config flag, supported model을 reproduction commit과 함께 pinning해야 한다.

7. My Take

7-1. Why this matters for my work

Agentic RL implementation에서 가장 먼저 검증할 것은 advantage formula가 아니라 data lineage일 수 있다.

  • 이 token은 어느 policy version이 생성했는가?
  • Model이 직접 생성한 token인가, environment가 넣은 observation인가?
  • Context compaction 뒤에 같은 action이 중복 학습되지 않는가?
  • Rollout and trainer logprob가 같은 forward semantics를 사용하는가?
  • Queue delay 때문에 effective batch가 지나치게 off-policy가 되지 않았는가?
  • Rejection gate 이후 실제 update token은 얼마나 남는가?

Molt는 이 질문을 framework-level invariant로 끌어올린다. 특정 estimator를 선택하기 전에 transport contract와 observability를 만드는 방향은 소규모 연구 system에도 재사용 가치가 크다.

7-2. Reuse potential

1) Token lineage schema

각 token에 다음 metadata를 둔다.

  • Source type
  • Assistant action mask
  • Behavior logprob
  • Policy version
  • Turn ID
  • Compaction segment ID
  • Tool or environment origin

2) Async health dashboard

  • Queue depth
  • Experience age
  • Ratio quantile
  • Sequence rejection rate
  • Effective generated-token batch size
  • Weight refit latency

이 dashboard가 reward curve보다 먼저 필요할 수 있다.

3) Forward parity test

Fixed prompt and token sequence에 대해 rollout engine and trainer의 per-token logprob difference를 측정한다. Dense model, MoE router, quantized engine을 각각 분리해 threshold를 둔다.

4) Minimal estimator interface

Estimator를 experience input and loss output의 pure function으로 유지한다. Reward normalization, advantage normalization, KL, clipping을 hidden trainer state에 넣지 않는다.

5) Partial rollout safety

In-flight weight swap을 지원한다면 token별 behavior logprob and version boundary를 저장한다. Correction이 꺼진 상태에서는 partial rollout을 금지하는 fail-closed design이 안전하다.

6) Scale claim hierarchy

System report를 다음으로 분리한다.

  1. Model loads
  2. Forward and generation run
  3. Gradient update accepted
  4. Reward improves
  5. Convergence is reproducible

각 단계가 서로 다른 evidence를 요구한다.

7-3. Follow-up papers

  • verl: Volcano Engine Reinforcement Learning for LLMs
  • OpenRLHF: An Easy-to-Use, Scalable and High-Performance RLHF Framework
  • slime: An LLM Post-Training Framework for RL Scaling
  • vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention
  • IMPALA: Scalable Distributed Deep-RL with Importance Weighted Actor-Learner Architectures
  • DeepSeek-V3 Technical Report
  • On-Policy Distillation of Language Models

8. Summary

  • Molt는 agent program, vLLM rollout, Ray queue, PyTorch FSDP2 trainer를 token-first contract로 연결하는 agentic RL framework다.
  • 핵심 invariant는 policy가 생성하지 않은 token에 loss를 적용하지 않고, behavior logprob and action span을 rollout부터 training까지 보존하는 것이다.
  • Fully async and partial rollout은 throughput을 높이지만 policy mismatch를 만들며, Molt는 importance correction and sequence rejection gate로 이를 다룬다.
  • MoE scale에서는 routing replay, router freeze, TP, EP, CP, optimizer offload를 같은 training path에 결합한다.
  • Evaluation은 useful system result를 제공하지만 head-to-head run의 every-batch rejection 때문에 convergence superiority를 주장할 수 없으며, 이 caveat 자체가 correctness-first framework의 중요성을 보여준다.

댓글남기기

참고