Tunix로 agentic RL 병목 줄이기: 비동기 rollout과 TPU 활용률 운영법

Agentic RL을 실제로 돌려본 팀은 같은 문제를 만난다. 모델은 TPU나 GPU 위에서 빠르게 토큰을 만들 수 있는데, 에이전트가 코드 실행, 웹 검색, DB 조회, 환경 step을 기다리는 동안 가속기는 놀게 된다. Google이 공개한 Tunix 업데이트는 이 병목을 정면으로 다룬다. 핵심은 비동기 rollout, producer-consumer 파이프라인, RL 전용 경량 프로파일링이다.

이 글의 검색 키워드는 “Tunix agentic RL 비동기 rollout”이다. 관심 독자는 모델 연구자보다 실험 인프라를 맡은 개발자다. “툴 쓰는 에이전트를 RL로 학습시키는데 왜 장비 활용률이 안 나오지?”라는 질문에 답하는 글이다.

출처: Google Developers Blog, Scaling Agentic RL: High-Throughput Agentic Training with Tunix(2026-07-21).

문제: agentic RL은 일반 SFT보다 훨씬 많이 기다린다

일반 supervised fine-tuning은 입력과 정답이 이미 있다. 배치를 만들고, forward/backward를 반복하면 된다. 반면 agentic RL은 매 샘플이 작은 실행 에피소드다. 모델이 행동을 만들고, 도구를 호출하고, 환경이 관측값과 보상을 반환하고, 그 결과로 다음 행동을 만든다.

여기서 세 가지 병목이 생긴다.

• 환경 초기화 시간이 제각각이다.
• 웹 검색, 코드 실행, API 호출이 네트워크 I/O를 기다린다.
• trajectory 길이가 달라서 가장 느린 샘플이 전체 배치를 붙잡는다.

동기식 rollout에서는 한 trajectory가 늦으면 나머지도 기다린다. 이것이 Google 글에서 말한 execution bubble과 straggler effect다. 비싼 TPU를 쓰고 있는데 실제로는 Python 프로세스와 외부 API 응답 시간을 기다리는 구조가 된다.

Tunix의 해결 방식: rollout과 training을 분리한다

Tunix는 trajectory 생성과 학습 루프를 느슨하게 분리한다. RolloutOrchestrator는 Python asyncio를 이용해 많은 agent-environment 상호작용을 동시에 관리한다. 한 에이전트가 도구 응답을 기다리는 동안 inference engine은 다른 trajectory의 토큰을 생성한다.

또한 vLLM-TPU와 SGLang-Jax 같은 inference engine과 비동기 요청 처리를 통합해 non-blocking sampling을 지원한다. 결과적으로 모델 추론, 도구 실행, 보상 계산이 겹쳐진다.

여기서 중요한 관점은 “빠른 모델”이 아니라 “빈 시간을 줄이는 스케줄러”다. agentic RL의 병목은 모델 FLOPS만으로 해결되지 않는다. 도구와 환경 대기 시간을 감추는 orchestration이 필요하다.

producer-consumer 파이프라인을 어떻게 이해하면 되나

Tunix는 rollout producer와 trainer consumer를 둔다.

• Producer는 완료된 trajectory를 큐에 계속 넣는다.
• Consumer는 큐에서 trajectory를 가져와 후처리, scoring, 학습 배치 구성을 한다.
• GRPO처럼 prompt당 여러 reasoning path가 필요한 알고리즘은 완료된 trajectory를 동적으로 그룹화한다.

이 구조의 장점은 전체 배치가 완성될 때까지 기다리지 않는다는 것이다. trajectory 길이가 달라도 완료되는 즉시 trainer 쪽으로 흘러간다. 동기식 barrier를 줄이면 trainer TPU가 굶는 시간이 줄어든다.

간단한 운영 지표로 보면 다음을 봐야 한다.

환경 추상화: SWE-bench, WebArena, 사내 도구를 같은 방식으로 붙인다

Tunix의 또 다른 포인트는 agent와 environment를 분리한 API다. 모델이 무엇인지, 환경이 Gymnasium인지, bash terminal인지, 사내 API인지가 학습 루프 전체를 바꾸지 않도록 한다.

Google 예시는 ConversationAgentBase를 상속해 agent의 응답 처리 로직을 커스터마이즈하고, BaseTaskEnv를 상속해 환경 step만 구현하는 방식이다. 개발자는 환경 초기 관측값, action 처리, reward, done, cleanup에 집중하면 된다.

이 구조는 사내 에이전트 학습에도 중요하다. 예를 들어 CS 자동화 에이전트, SRE triage 에이전트, 코드 수정 에이전트를 각각 학습시키려면 환경은 다르지만 공통 루프는 재사용되어야 한다. 매번 RL 코드 전체를 고치면 실험 속도가 느려지고 버그가 섞인다.

경량 프로파일링: XProf만으로는 운영 병목을 못 본다

Tunix는 XProf 같은 op-level profiler를 부정하지 않는다. 다만 agentic RL에서는 너무 낮은 레벨만 보면 원인을 놓친다. “TPU kernel이 느린가?”보다 “도구 호출 때문에 rollout이 말라붙었나?”가 더 중요한 순간이 많다.

그래서 Google은 RL 단계별 macro metric을 계속 수집하는 방식을 제시한다. rollout, training, weight sync, environment step, model call 같은 단계가 시간축에서 어떻게 겹치는지 봐야 한다.

실무에서는 대시보드를 이렇게 나누면 좋다.

• 하드웨어: TPU/GPU utilization, HBM 사용량.
• rollout: 초당 completed trajectory, 평균 episode length.
• 환경: step latency p50/p95/p99, timeout 비율.
• 학습: trainer step time, queue starvation 횟수.
• 품질: reward 평균, pass rate, regression case.

성능 튜닝은 이 순서로 한다. 먼저 trainer가 굶는지 보고, 그다음 rollout 큐와 환경 latency를 본다. 그 후에야 kernel profiler를 켠다.

작은 팀이 적용할 현실적인 시작점

Tunix 전체를 바로 도입하지 않더라도 패턴은 가져올 수 있다.

첫째, rollout worker를 동기 함수 루프에서 async queue 기반으로 바꾼다. 둘째, trajectory를 고정 batch 단위가 아니라 완료 이벤트 단위로 기록한다. 셋째, 환경 step과 도구 호출에는 timeout, retry, circuit breaker를 둔다. 넷째, reward 계산을 모델 추론 경로와 분리한다.

특히 사내 API를 환경으로 쓰는 경우 timeout 정책이 중요하다. 외부 서비스가 느려졌을 때 학습 전체가 멈추면 안 된다. 실패한 trajectory도 실패로 기록하고 다음 샘플로 넘어가야 한다.

실행 체크리스트

• rollout, environment step, reward 계산 시간을 각각 로그로 분리한다.
• trajectory 완료 이벤트를 큐에 넣고 trainer가 큐에서 소비하게 만든다.
• 환경 step에는 p95/p99 latency와 timeout 비율을 기록한다.
• 도구 호출 대기 중에도 다른 trajectory 추론이 진행되는지 확인한다.
• GRPO처럼 그룹이 필요한 알고리즘은 완료된 trajectory를 동적으로 묶는다.
• profiler는 처음부터 kernel 단위로 보지 말고 RL 단계별 timeline부터 본다.
• SWE-bench, WebArena, 사내 API 환경을 같은 interface로 감싼다.

Agentic RL의 비용은 모델 학습 비용만이 아니다. 대기 시간도 비용이다. Tunix가 보여주는 방향은 명확하다. 에이전트를 학습시킬수록 인프라의 핵심은 “더 큰 장비”가 아니라 “장비가 기다리지 않게 만드는 루프”가 된다.