Skip to content
AI Primer
breaking

LMSYS reports Vera CPUs cut agentic RL episode time by 11%

LMSYS reports that Vera CPU sandboxes reduced average agentic RL episode time by 11% in Miles tests under load. Command latency rose 5–22% as concurrency increased from one to 176 sandboxes per socket.

4 min read
LMSYS reports Vera CPUs cut agentic RL episode time by 11%
LMSYS reports Vera CPUs cut agentic RL episode time by 11%

TL;DR

  • Vera sandboxes cut average episode time by 11% versus AMD EPYC Turin under load, according to LMSYS's announcement. The comparison covered four SWE-bench Verified tasks.
  • Command latency rose just 5–22% from one to 176 concurrent sandboxes per Vera socket in LMSYS's concurrency tests.
  • The broader Miles project completed more than 2,400 episodes with every sandbox on Vera, across synchronous and fully asynchronous RL, LMSYS reported.

The arm64 port covered 530 task environments and support for Vera's 64K memory pages. On one gRPC-service task, pass rate rose from 40% to 82% between the first and second halves of training, based on 40 attempts in each half.

Firecracker sandboxes

RadixArk's Miles trained GLM-4.7-Flash for 68 steps across Terminal-Bench and SWE-bench tasks, according to the write-up LMSYS shared. Moving the sandboxes to Vera required environment-side changes, with no changes to the training code.

The execution stack separates three jobs:

  • Inference and training: remain on the GPU cluster, with SGLang serving inference.
  • Tool execution: each episode gets a fresh AgentENV Firecracker VM, restored from a snapshot in under 0.1 seconds.
  • Verification: task tests run inside that same sandbox, and their reward returns to training.

The AgentENV integration documentation describes OpenEnv handling task interaction and evaluation, with AgentENV providing per-episode isolation.

Episode timing

The head-to-head experiment held the model, eight H200 GPUs, tasks and settings constant. Each CPU configuration ran five GRPO steps and 160 episodes, while its socket also handled 176 continuously replaced background SWE-bench evaluations.

Mean episode time fell from 482 seconds on Turin to 429 seconds on Vera. An 11% reduction using Turin as the denominator is equivalent to Turin taking about 12% longer than Vera.

The 53-second difference broke down as:

  • Agent commands: 26 seconds, with Turin taking 60% longer.
  • Verifier tests: 11 seconds, with Turin taking 24% longer.
  • Agent execution and sandbox startup: 12 seconds.
  • Waiting for the model: 4 seconds.

The authors report a 90% confidence interval of 1.04–1.22 for the Turin-to-Vera episode-time ratio. They compared episode means because five training steps could not reliably resolve differences in step time, which depends heavily on the slowest attempts.

176 sandboxes per socket

At 176 concurrent sandboxes, Vera's Python and compilation commands slowed just 5–22% relative to running alone, the standout result in LMSYS's tests. Turin's corresponding slowdown was 40–70%.

The socket configurations differed:

  • Vera: 88 cores, 176 hardware threads.
  • AMD EPYC Turin: 96 cores, 96 threads.
  • Intel Xeon 6: 96 cores, 192 threads.

The 176-background-job training comparison therefore exceeded Turin's thread count. With 96 background jobs instead, Turin's command-time penalty narrowed to 44%, versus 60% at 176.

Vera used NVIDIA-tuned boot parameters. The x86 servers used AWS defaults, except that Xeon 6's C6 sleep state was disabled after it caused large file-read slowdowns.

With p95 command latency capped at 1.5 times the single-command latency on a reference AWS m7i machine, one Vera socket carried:

  • 1.4–2.1 times Turin's load.
  • 1.3–1.5 times Xeon 6's load.

KV cache and sample lag

Asynchronous training continues updating weights while agents execute commands. The team quantified three consequences of tool waits in its training analysis:

  • Sample lag: episodes lasting over 20 minutes reached training with starting weights more than three updates behind; episodes under five minutes were less than two updates behind.
  • Occupied KV cache: command-wait cache accounted for an estimated 12.1% of KV cache in use on Vera, versus 17.9% on Turin. The estimate weights command-wait duration by context length.
  • GRPO group waits: completed episodes waited for 38–52% of the time their groups held slots. Even fully asynchronous training waits for a group's slowest episode before training on that group.

Training-speed projections

Using the reported episode-time reduction, the team estimates up to 12% faster training at unchanged sample staleness. That estimate assumes the GPUs keep up; the experiment measured episode timing rather than an equivalent-quality training-speed improvement.

Separate faster-inference scenarios shrink only model-wait time while holding measured sandbox work constant:

  • 8 times faster inference: Turin episodes are projected to take 33% longer than Vera episodes.
  • 32 times faster inference: Turin episodes are projected to take 41% longer.

Those percentages describe projected episode-time gaps, not measured training-throughput gains.

Further reading

Discussion across the web

Where this story is being discussed, in original context.

On X· 3 threads
TL;DR1 post
Firecracker sandboxes1 post
176 sandboxes per socket1 post
Share on X