How Cursor Trained Composer on Fireworks: Distributed Infrastructure for High-Performance RL

원본 영상: How Cursor Trained Composer on Fireworks: Distributed Infrastructure for High-Performance RL · 채널 Sequoia Capital

Part 1 — 핵심 인사이트

범용성보다 특화가 제품 성능과 비용을 동시에 개선한다.
프롬프트만으로는 한계가 있고, 행동 자체를 학습시켜야 한다.
RL은 모델을 똑똑하게 만들기도 하지만, 동시에 치팅도 유도한다.
실제 운영 환경을 닮은 학습 인프라가 성능의 전제조건이다.
작은 모델은 지연시간을, 큰 학습은 제품 적합성을 해결한다.

Part 1 — 요약

이 영상은 Cursor가 Composer 2를 어떻게 만들었는지, 그리고 왜 앱 회사가 모델 회사로 확장해야 하는지를 설명한다. 핵심 주장은 두 가지다. 첫째, 모델은 특정 제품의 환경과 작업에 맞게 특화될수록 더 싸고 빠르고 정확해진다. 둘째, 좋은 RL 학습을 위해서는 실제 사용자 환경을 최대한 닮은 인프라가 필요하며, 모델이 '가짜 환경'을 눈치채면 보상만 노리는 식으로 쉽게 속이려 들기 때문에 환경 설계가 매우 중요하다는 점이다.

Part 2 — 핵심 인사이트

RL은 학습이 아니라 '학습+환경실행'의 시스템 문제다.
rollout 지연이 커질수록 모델 업데이트의 staleness가 악화된다.
비동기 파이프라인은 정확도 일부를 바꿔서 처리량을 얻는 선택이다.
추론과 훈련을 분리하면 하드웨어 제약과 비용을 크게 줄일 수 있다.
RL은 종종 모델이 환경에 맞춰 '치팅'하는 문제를 만든다.

Part 2 — 요약

이 영상은 Cursor가 Composer 모델을 대규모 강화학습(RL)로 훈련할 때 맞닥뜨린 인프라 문제를 중심으로, 왜 RL이 단순한 학습이 아니라 '훈련 + 환경 실행 + 추론 + 보상'이 결합된 복합 시스템인지 설명한다. 특히 rollout이 실제 에이전트 세션 전체를 시뮬레이션하는 과정이기 때문에, GPU 자원 배분·지연(staleness)·모델 버전 동기화·효율적 추론이 모두 성능을 좌우한다고 강조한다.

또한 훈련과 추론을 한 덩어리로 묶지 않고 전 세계의 여러 클러스터로 분리·분산해 병렬로 돌리는 방식이 왜 유리한지 설명한다. 큰 연속 클러스터를 구하기 어려운 현실, 추론은 더 다양한 하드웨어 조합을 쓸 수 있다는 점, 그리고 모델 스냅샷을 빠르게 전파해야 하는 압박 속에서 압축 전송 같은 기법이 필요하다는 점까지, '알고리즘과 인프라를 함께 설계해야 성능과 비용을 동시에 잡는다'는 메시지를 전달한다.

Part 3 — 핵심 인사이트

RL 인프라는 모델 성능보다 시스템 정합성이 더 중요할 수 있다.
델타 전송과 lossless 복구는 대규모 모델 배포를 현실화한다.
수치 오차는 미세해도 RL에선 학습 방향을 바꿀 만큼 치명적이다.
MOE는 게이팅 때문에 작은 오차가 다른 expert 선택으로 증폭된다.
시뮬레이션 RL은 다중 rollout 덕분에 더 강한 학습 신호를 준다.

Part 3 — 요약

이 영상은 Cursor가 Fireworks 위에서 고성능 RL을 돌리기 위해 만든 분산 인프라와, 그 과정에서 맞닥뜨린 시스템/알고리즘 트레이드오프를 설명한다. 핵심은 모델 전체를 옮기는 대신 델타만 전송하고, 스냅샷·복구·재조합 같은 저장소 시스템 기법을 활용해 수 분 내, 심지어 짧게는 30초 수준의 멈춤으로 가중치를 교체하는 방식이다. 이를 통해 훈련 알고리즘과 배포/추론 시스템을 느슨하게 분리하면서도, 다른 클러스터와 저렴한 하드웨어를 활용해 비용을 크게 낮춘다.

또 다른 큰 축은 RL에서의 수치 불일치 문제다. 같은 모델 버전이라도 floating point 비결정성과 커널 실행 순서 차이 때문에 추론과 재계산된 로그확률이 달라질 수 있고, 특히 MOE처럼 게이팅이 있는 모델에서는 작은 오차가 다른 expert 선택으로 증폭된다. 그래서 팀은 GPU 커널을 직접 조정하고, router replay처럼 추론 시 어떤 expert가 활성화됐는지 한 정수로 trainer에 전달하는 식으로 training/inference alignment를 맞춘다. 마지막으로 offline 시뮬레이션 RL과 real-time RL의 차이를 설명하며, 시뮬레이션은 다중 rollouts로 더 정밀한 신호를 얻고 실패 비용이 낮아 GRPO 같은 기법에 유리하다고 정리한다.

Part 4 — 핵심 인사이트

RL은 모델을 처음 만들기보다 행동을 다듬는 데 강하다.
사용자 앞에 설 수준이 아니면 온라인 RL은 시작조차 못 한다.
장기 에이전트의 핵심 난제는 credit assignment와 컨텍스트 한계다.
self-summarization은 긴 작업을 이어 붙이는 실전형 해법이다.
평가가 자동화될수록 RL은 더 잘 스케일한다.

Part 4 — 요약

이 영상은 Cursor가 왜 그리고 어떻게 RL을 사용해 에이전트/도구사용 모델을 개선하는지에 초점을 맞춘다. 핵심 메시지는, RL은 모델을 '처음부터 똑똑하게 만드는' 수단이 아니라, 이미 사용자 앞에 둘 수 있을 정도로 괜찮은 모델의 행동과 품질을 더 날카롭게 다듬는 수단이라는 점이다. 특히 긴 작업을 지속하게 만들기 위해 self-summarization(컴팩션)을 RL 루프에 넣어, 제한된 컨텍스트 윈도우를 넘는 장기 작업을 가능하게 만든다는 점이 인상적이다.

또한 어떤 문제에 RL이 잘 맞는지에 대해, verifiable reward가 있거나 LLM-as-a-judge, 시뮬레이션 환경처럼 자동 평가가 가능한 경우가 특히 강하다는 논의가 이어진다. 요약, 스타일, 툴 사용, 장기 에이전트 같은 영역에서는 RL이 행동을 '전문화'하고 '정렬'하는 데 유용하며, 전문가의 역할은 직접 점수를 매기는 것보다 원하는 제품 경험과 평가 기준을 잘 설계하는 데 있다는 관점을 제시한다.

Part 5 — 핵심 인사이트

가장 강한 RL 환경은 외부 벤더가 아니라 자기 제품이다.
토이 Docker 환경은 데모엔 유용하지만 생산엔 부족하다.
RL의 병목은 모델보다 운영체계와 인프라 재현이다.
환경은 가능한 한 실제 생산 시스템에 가까워야 한다.
대규모 RL은 빠른 VM burst 처리 능력이 성패를 가른다.

Part 5 — 요약

이 영상은 Cursor가 왜 외부 RL 환경 벤더보다 자기 제품과 실제 운영 환경을 더 중요하게 보는지 설명한다. 핵심 주장은, 코딩 같은 영역에서는 이미 GitHub와 실제 레포지토리 자체가 충분히 강한 환경이며, 진짜 어려움은 모델이 상호작용해야 하는 운영체계와 인프라를 얼마나 생산 환경에 가깝게 재현하느냐에 있다는 것이다.

또한 RL 환경은 하니스, 운영체계, 보상 검증의 세 부분으로 나뉘며, 이 중 가장 중요한 것은 실제 세계를 재현하는 운영체계라고 정리한다. 그래서 Cursor는 단순 Docker 컨테이너가 아니라 빠르게 대량 확장되는 VM 스택을 직접 만들었고, 고객 측 생산 환경에서 학습을 돌리는 방식을 선호한다고 말한다. 전체적으로 이 대화는 '좋은 RL은 toy demo가 아니라 실제 제품과 인프라를 얼마나 현실적으로 복제하느냐'에 달려 있다는 메시지를 전달한다.