Asynchronous RL: CUA 스케일링과 Policy Lag

개요

• Luke J. Huang의 2026년 5월 31일 글 “Is Frontier Asynchronous RL Solved?”와 CUA(computer-use agent) rollout 인프라 관점 정리임. 글의 결론은 async RL이 속도 문제는 많이 풀었지만, high policy lag 안정성은 아직 open problem이라는 쪽임.
• Asynchronous RL(비동기 강화학습)은 여러 worker가 각자 환경을 돌며 trajectory를 만들고, learner가 들어오는 데이터를 기다리지 않고 계속 학습하는 구조임.
• CUA에서는 100개 브라우저 VM이 서로 다른 task를 돌고, screenshot, action, reward, verifier 결과를 서버로 보내는 그림에 가까움.
• 장점은 throughput임. 느린 task 하나 때문에 전체 학습이 멈추지 않음. 특히 웹/OS task처럼 실행 시간이 들쭉날쭉한 환경에서 유리함.
• 핵심 위험은 stale trajectory임. worker가 오래된 policy로 만든 데이터를 learner가 현재 policy 기준으로 학습하면서 off-policy instability가 생길 수 있음.

동기식 RL과 비동기 RL은 어떻게 다른가?

• 동기식 RL은 반 전체가 시험지를 다 제출할 때까지 기다리는 방식임. 가장 느린 worker가 끝나야 learner가 다음 update를 시작함.
• 비동기 RL은 먼저 끝낸 worker가 바로 데이터를 보내는 방식임. 다른 worker가 아직 브라우저 task를 수행 중이어도 learner는 이미 들어온 trajectory로 학습할 수 있음.
• 이 구조는 rollout/generation loop와 training loop를 분리함. 한쪽은 환경에서 경험을 만들고, 다른 한쪽은 policy를 업데이트함.
• A3C는 여러 actor가 비동기로 환경을 돌며 중앙 네트워크를 업데이트한 초기 대표 방식임. IMPALA는 많은 actor가 trajectory를 보내고 learner가 따로 학습하는 대규모 구조임.
• APPO나 distributed PPO는 PPO 계열을 여러 worker로 병렬화한 형태로 볼 수 있음. 이름은 달라도 핵심 병목은 비슷함.

방식	worker가 하는 일	learner가 하는 일	주요 장점	주요 위험
동기식 RL	rollout을 끝낸 뒤 대기	모든 rollout이 모이면 update	on-policy에 가까워 안정적임	느린 rollout 때문에 GPU가 놀 수 있음
비동기 RL	끝나는 즉시 trajectory 전송	들어오는 데이터로 계속 update	throughput이 높고 scale하기 쉬움	stale policy 문제가 커질 수 있음

policy lag는 왜 생기나?

• policy lag K는 worker가 trajectory를 만든 policy보다 learner의 현재 policy가 몇 optimization step 앞서 있는지를 뜻함.
• K = 0이면 거의 on-policy임. worker가 만든 데이터와 learner가 학습하는 policy가 거의 같은 버전이라는 뜻임.
• K가 커지면 rollout을 만든 policy는 점점 옛날 model이 됨. learner 입장에서는 현재 policy가 잘 만들지 않을 행동을 학습 데이터로 받게 됨.
• CUA에서는 이 문제가 더 커짐. 웹 로그인, 검색, 다운로드, 시트 붙여넣기 같은 task는 trajectory 하나가 길고 환경 interaction도 많기 때문임.
• 긴 rollout일수록 데이터가 learner에게 도착할 때 이미 낡아 있을 가능성이 높음.

Ksteady 식은 무엇을 말하나?

• 직관은 간단함. trajectory 하나가 오래 걸리고 rollout worker가 많을수록, trainer는 더 오래된 policy가 만든 데이터를 보게 됨.

$$K_{\text{steady}} \approx \frac{\text{rollout latency per trajectory}}{\text{training step time}} \times \frac{N_{\text{rollout}}}{N_{\text{train}}}$$

• rollout latency per trajectory가 커지면 K_{\text{steady}}가 커짐. CUA처럼 long-horizon task에서는 이 항이 자연스럽게 커짐.
• N_{\text{rollout}}을 늘리면 data throughput은 좋아짐. 하지만 training 쪽이 그 속도를 못 따라가면 buffer에는 더 오래된 trajectory가 쌓임.
• N_{\text{train}}을 늘리거나 training step time을 줄이면 lag 압력을 낮출 수 있음. 다만 compute 비용과 시스템 복잡도가 같이 올라감.
• K_{\text{max}}를 작게 제한하면 안정성은 좋아짐. 대신 rollout buffer가 비어서 trainer가 기다릴 수 있고 async speedup이 줄어듦.
• K_{\text{max}}를 크게 허용하면 속도는 좋아짐. 대신 stale trajectory가 많아져 학습 collapse 위험이 커짐.

importance sampling은 왜 필요한가?

• worker policy와 learner policy가 다르면, 같은 trajectory라도 두 policy가 보는 확률이 다름. importance sampling(IS)은 이 차이를 보정하려는 장치임.
• sequence 전체를 보정하려면 현재 policy가 그 trajectory를 낼 확률을, rollout 당시 policy가 낼 확률로 나누면 됨.

$$w(\tau) = \frac{\pi_\theta(\tau \mid x)}{\mu(\tau \mid x)} = \prod_{i=1}^{|\tau|} \frac{\pi_\theta(\tau_i \mid x, \tau_{<i})} {\mu(\tau_i \mid x, \tau_{<i})}$$

• 여기서 $\mu$는 trajectory를 만든 오래된 inference policy이고, $\pi_\theta$는 지금 학습 중인 policy임.
• sequence-level IS는 이론적으로 더 맞는 보정에 가까움. trajectory 전체가 stale해졌으니 trajectory 전체 확률을 보정하기 때문임.
• 문제는 variance임. 긴 sequence에서는 작은 token ratio 차이가 곱으로 누적돼 w(τ)가 너무 커지거나 작아질 수 있음.
• 그래서 PPO/GRPO류는 token-level ratio를 많이 씀. 하지만 high policy lag에서는 token 단위 보정만으로 state distribution mismatch를 충분히 못 잡을 수 있음.

frontier lab들은 어떻게 안정화하나?

• 첫째는 algorithmic control임. importance sampling ratio가 너무 튀면 clip하거나, 아예 sample을 mask/drop해서 gradient 폭주를 막음.
• TIS/CISPO는 ratio를 위아래 범위 안으로 자름. MIS/IcePop은 범위를 벗어난 sample을 0으로 만들어 학습에서 빼는 방식임.
• DeepSeek-style masking이나 M2PO도 비슷하게 extreme ratio를 다룸. 이런 방법은 collapse를 늦출 수 있지만 bias를 넣는 대가가 있음.
• 둘째는 systems-level mismatch를 줄이는 것임. rollout engine과 training engine이 다르면 같은 weight여도 logprob이 다르게 계산될 수 있음.
• MoE routing replay, TITO, batch-invariant kernel, FP32 LM head, quantized rollout, efficient weight sync 같은 fix가 여기에 들어감.
• 다만 system fix는 train/inference mismatch를 줄일 뿐임. 오래된 policy가 만든 데이터라는 policy lag 자체를 없애지는 못함.

CUA에서는 어떻게 시작하는 게 현실적인가?

• 바로 full async online RL training부터 붙이는 건 위험함. CUA는 math reasoning보다 환경 상호작용이 길고, bad action 하나가 이후 state를 완전히 바꿔버릴 수 있음.
• 먼저 async rollout/eval/data pipeline을 만드는 게 맞음. 여러 VM이나 브라우저 worker가 task를 병렬 실행하고 trajectory를 안정적으로 저장하는 단계임.
• 각 trajectory에는 policy_version, model_hash, prompt_version, action_logprobs, screenshot, before/after state, reward, verifier result를 저장해야 함.
• 초반 학습은 batch 단위로 하는 편이 안전함. verifier가 안정화되기 전에는 실시간 policy update보다 data quality와 replay 가능성이 더 중요함.
• 나중에 PPO, GRPO, RLVR로 넘어가더라도 K_max를 두고 너무 오래된 trajectory는 버리거나 offline data로만 쓰는 게 현실적임.
• CUA에서 진짜 금광은 async RL이라는 이름 자체보다 async rollout infrastructure, verifier, trajectory store 쪽에 가까움.

FAQ

asynchronous RL은 그냥 parallel data collection인가?

처음에는 그렇게 시작해도 됨. 하지만 엄밀히는 learner가 worker 데이터 흐름과 동시에 policy를 업데이트할 때 async RL training 문제가 본격적으로 생김.

CUA에서 policy lag가 왜 더 위험한가?

CUA는 action 하나가 다음 화면 상태를 바꿔버림. 오래된 policy가 만든 trajectory는 현재 policy 기준으로 이상할 뿐 아니라, 완전히 다른 UI state를 통과했을 수 있음.

Kmax를 작게 두면 문제가 해결되나?

안정성은 좋아지지만 속도 이득이 줄어듦. long-horizon task에서는 rollout이 오래 걸려서 작은 K_max가 trainer stall을 자주 만들 수 있음.

token-level IS와 sequence-level IS 중 뭐가 맞나?

이론적으로는 sequence-level IS가 trajectory stale 문제에 더 직접적임. 다만 긴 sequence에서는 variance가 커져서 큰 batch나 추가 variance control이 필요함.

지금 CUA 프로젝트에서는 무엇을 먼저 만들어야 하나?

먼저 async rollout/eval/data pipeline을 만드는 게 현실적임. policy update는 batch/on-policy에 가깝게 시작하고, verifier와 logprob 기록이 안정된 뒤 RL로 연결하는 편이 좋음.

stale trajectory는 전부 버려야 하나?

항상 버릴 필요는 없음. K_max 밖의 trajectory는 online RL update에서 제외하고, offline 분석, verifier 개선, failure mining 데이터로 따로 쓰는 방식이 가능함.