Skip to main content
rLLM’s training loop uses the same AgentFlow and Evaluator abstractions you use for evaluation. You pass your AgentFlow, Evaluator, and datasets into AgentTrainer — it handles episode generation, reward assignment, advantage computation, and policy updates. During eval, the pipeline is one-directional:
During training, the same pipeline runs in a loop, with rewards flowing back into the model:
Your AgentFlow and Evaluator code stays the same. The AgentTrainer handles the additional machinery — routing LLM calls through a gateway that captures token-level data (prompt IDs, response IDs, logprobs) needed for policy gradients.

Basic usage

Pass an agent_flow and evaluator to AgentTrainer, then call train():
You can also use custom AgentFlow and Evaluator classes directly:

The training loop

Each training iteration runs through these stages:
1

Generate episodes

For each task in the batch, the trainer calls agent_flow.run(task, config) to produce an Episode — just like during eval. The AgentConfig.base_url points to a gateway that transparently captures token-level traces (prompt IDs, response IDs, logprobs) from every LLM call.
2

Evaluate and assign rewards

The trainer calls evaluator.evaluate(task, episode) for each Episode, producing an EvalOutput with a reward and correctness flag. The reward is written back onto each Trajectory in the Episode.
3

Enrich with token data

The gateway’s captured traces are matched to Trajectories and converted into training-ready Steps with full token information. This is what makes the same AgentFlow work for both eval and training — your agent code doesn’t need to know about tokens or logprobs.
4

Compute advantages

Trajectories are grouped by {task_id}:{trajectory.name}. The RL algorithm (GRPO, REINFORCE, etc.) compares rewards within each group to compute advantages — determining which rollouts were better than average.
5

Update policy

The training backend uses the token-level data and advantages from each Step to compute policy gradients and update model weights.
6

Iterate

The updated model generates new Episodes on the next batch. The cycle repeats.

How the gateway works

Your AgentFlow makes LLM calls like normal — using an OpenAI-compatible client pointed at the base_url from AgentConfig. Behind the scenes, this URL routes through a gateway that:
  1. Forwards requests to the actual model server
  2. Records every request and response with token IDs and logprobs
  3. Associates traces with the correct Episode via the session_uid
After the AgentFlow completes, the trainer retrieves these traces and enriches the Episode’s Steps with the token-level data needed for training. Your agent code never needs to handle tokenization or logprob collection.

Training backends

AgentTrainer supports two backends:
Distributed RL training via Ray with vLLM/SGLang inference. Best for large-scale multi-GPU training.
See verl and tinker for backend-specific configuration.

Configuration

Training configs are OmegaConf/Hydra-based. The build_train_config helper covers common options:
For full control, you can also provide a YAML config file or override individual values:

Next steps

Cookbooks

Worked end-to-end training examples (math, deepcoder, frozenlake, finqa, …)

RL algorithms

Learn about GRPO, REINFORCE, and other algorithms

Distributed training

Scale to multiple GPUs and nodes

Solver-judge tutorial

Multi-agent training walkthrough