Research Engineer / Performance Engineer, RL Distributed Systems

Anthropic•San Francisco, NY

15h•Hybrid

About The Position

Reinforcement learning is how Claude learns to reason, write code, and act autonomously over long horizons. At frontier scale, an RL run is an unusually demanding distributed system. Training, sampling, and environment execution run concurrently across a large fleet of accelerators and hosts, exchange data continuously, and have to keep making progress while hardware fails, load shifts, and the research changes underneath them. How well that system holds together determines how much of our compute turns into learning, and how quickly the team can try the next idea. As a Research Engineer on the Distributed Systems team within RL Engineering, you'll work on whatever part of that system is the current limit. That might be scheduling and placement, data movement between components, running large numbers of sandboxed environments, storage and checkpointing, networking, fault tolerance, autoscaling, or the observability that tells us what a run is actually doing. We're looking for generalists: engineers who can move between these layers, reason from first principles about a system they haven't seen before, and pick the problem that matters most rather than the one closest to their prior experience. Our system changes as fast as the research does, correctness under failure matters as much as throughput, and the best solutions often come from understanding the ML workload well enough to know which guarantees it actually needs. Strong candidates have built and run large distributed systems, care about getting the details right, and want to apply that experience to a workload that is very large, very heterogeneous, and changing quickly.

Requirements

Strong software engineering skills in Python and at least one systems language such as Rust, C++, or Go
Experience designing, building, and operating large-scale distributed systems in production
Deep understanding of distributed systems fundamentals, including consistency, coordination, consensus, failure modes, and recovery
Ability to reason quantitatively about throughput, latency, and resource costs across compute, memory, storage, and network
Experience debugging complex failures across many hosts and services, including failures you can't reproduce locally
Strong written communication, including design documents and incident writeups

Nice To Haves

Experience running ML training or inference infrastructure at scale
Experience across several layers of the stack, such as scheduling, storage, networking, and orchestration
Experience building schedulers, autoscalers, or resource management systems
Experience with container orchestration such as Kubernetes, and with sandboxed or virtualized code execution at scale
Experience with high-performance networking, RDMA, or collective communication libraries
Experience building observability or automated remediation for large fleets
Experience with async Python frameworks such as Trio or asyncio
Familiarity with reinforcement learning or large language model training workloads

Responsibilities

Design, build, and operate the distributed systems that run RL at scale, across training, sampling, and environment execution
Find and remove whatever currently limits the system, whether it's scheduling, data movement, storage, networking, or coordination
Build fault tolerance into every layer: failure detection, isolation, and recovery that keep long-running jobs making progress without human intervention
Design resource management and autoscaling so that compute follows demand as a run's needs shift
Build observability that makes it possible to understand what a run is doing and why it slowed down, stalled, or produced unexpected results
Build automation that detects and remediates common problems, and design interfaces that let engineers and automated tools operate runs safely
Work with researchers and performance engineers to make sure systems changes preserve training correctness and don't introduce subtle nondeterminism
Remove classes of failure at their source through incident review, testing, and redesign, and write clear design documents for what you build