Federico와 Dima가 말하는 Cursor Composer 2의 분산 RL 인프라

개요

Cursor의 에이전틱 코딩 모델 Composer 2 트레이닝 전 과정을 리서치 리드 Federico와 인프라를 함께 만든 Fireworks의 Dima가 해부
핵심 축은 두 가지: 앱 회사가 왜 자체 파운데이션 모델로 가는가(특화의 경제학), 그리고 대규모 RL을 돌리는 분산 인프라의 실제 난제(비동기 파이프라인·가중치 배송·수치 불일치·환경 구축)
Dima는 수개월간 Cursor에 사실상 상주하며 인프라 지원, 두 회사 공동 설계 사례로서의 밀도가 높음

핵심 내용

왜 자체 모델인가 - 특화의 경제학

모델 = 저장 드라이브 비유: 가중치에 담을 수 있는 정보 비트가 유한 - 그 비트 전부를 단 하나의 태스크에 할당하자는 발상
Cursor 목표는 일반 코딩 아닌 자사 내 SWE: 그 외 전부는 가중치 낭비
결과: Composer는 Opus 등 범용 코딩 모델 대비 한 자릿수(order of magnitude) 저렴 - 특화 덕에 더 작은 모델로 서빙 가능
Dima: 앱 회사 진화의 일반 패턴 - 오프더쉘프 모델로 프로토타입 → 프롬프트 엔지니어링 → 결국 자기 환경에 맞춘 모델 크래프팅
유저데이터·하네스 특성을 모델에 직접 학습: 프롬프트로는 일부만 담기고 모델에 구워 넣는 게 정공법
Federico: 툴 동작을 프롬프트로 정확히 기술하기 어려운 경우 다수 - 포스트트레이닝으로 최적 사용법을 베이크인
Composer는 프롬프트 없이도 작동하게 행동 내재화: Composer는 프롬프트 없이도 작동할 수준으로 행동 자체를 트레이닝에 내재화
프롬프트 엔지니어링에는 상한선 존재: 진짜 좋은 AI 제품은 파인튜닝으로 모델 행동에 개입해야
Fireworks 관점: 품질·속도·비용 3차원 트레이드오프 - 인프라 최적화만으로도 꽤 가지만, 모델 트레이닝까지 가면 훨씬 더 밀어붙일 수 있음
비터 레슨 반박 질문에 대한 답: 빅랩 모델도 코드에 이미 상당히 특화돼 있음 - 순수 일반화가 아님
Cursor는 오히려 비터 레슨의 데이터 축을 극단으로 미는 것: 유한한 모델 용량을 포화시키려면 데이터를 스케일해야 하고, 그러려면 가중치에서 잡념(distraction)을 비워야

트레이닝 레시피 - 미드트레이닝 + 대규모 RL

베이스: Kimi 2.5 - 1조 파라미터 MoE, 활성 30B의 초희소 구조
Composer2는 미드트레이닝과 RL 동시 추진: 컨티뉴얼 프리트레이닝(미드트레이닝) + 강화학습
미드트레이닝은 코드 토큰 중심으로 거의 프리트레이닝 스케일: Cursor가 코딩 토큰 흐름의 한가운데 있어 데이터 접근성이 독보적
왜 처음부터 프리트레이닝 안 하나: 톱다운 접근 - 유저에게 유용한 모델을 최단 시간에 내는 게 우선, 바텀업(프리트레이닝부터 구축)은 너무 느림
차기 Composer는 완전 자체 모델이 목표: 차기 Composer 버전은 오픈소스 베이스 없이 완전 자체 모델이 목표
미드트레이닝에서 배우는 것: 라이브러리, 흔한 코드 패턴, 세계 지식(웹 데이터 포함) - RL이 날카롭게 깎을 넓은 분포를 형성
RL에서 배우는 것: Cursor 하네스와 직접 상호작용 - 툴 호출법, 환경 탐색, 그리고 올바른 코드 작성
미드트레이닝은 정오 구분 못해 RL이 보완: RL이 항상 올바르게 쓰라는 특성을 튜닝
미드트레이닝 모델은 Tab 자동완성과 성격 유사: 차이는 크기: Tab은 초저지연용 소형, Composer는 대형

비동기 RL 파이프라인과 GPU 경제성

롤아웃은 에이전트 세션 전체 시뮬레이션, 약 50턴: 약 50턴, 초기 프롬프트 → 툴 호출 → 코드 생성 반복 후 최종 보상
보상은 LLM 심사 또는 컴파일 등 검증가능 신호: 보상은 LLM-as-judge 또는 검증 가능 신호(컴파일 여부 등)로 부여
필요한 것: 수만 GPU의 트레이닝 오케스트레이션 + 환경 오케스트레이션 + 모델 인퍼런스 - 극도로 이질적(heterogeneous)인 업데이트 루프
나이브한 동기 방식: 트레이너 멈추고 5-10분(장호라이즌이면 그 이상) 롤아웃 → 다시 트레이닝 - 알고리즘적으론 정확하나 용량 절반이 항상 유휴
해법은 파이프라인화: 거대한 공장 비유 - 트레이너 동과 롤아웃 동이 항상 동시 가동, 롤아웃은 최신 가중치로 새 세션, 트레이너는 도착하는 결과로 즉시 업데이트
대가는 staleness: 롤아웃 완료 시점에 가중치가 이미 몇 스텝 앞서 있음 - 흥미로운 트레이닝 다이내믹스 유발, 해결 기법 존재
비동기로 몇 퍼센트 손실이 있어도 용량 절반을 놀리지 않는 이득이 압도: 컴퓨트 효율로 더 빨리 더 좋은 모델
Cursor의 현실: 빅랩처럼 수백만이 아니라 수만 GPU - 그래서 극단적 효율 추구, 프로덕션에서 FP4 트레이닝까지 사용
RL은 인퍼런스 플롭스가 트레이닝보다 훨씬 크다는 통념은 신화: 오픈소스 인퍼런스 엔진이 미최적화된 탓이지 RL의 본질이 아님
인퍼런스 GPU는 트레이닝의 3분의 1이면 충분: 이론상 트레이닝은 forward·데이터 그래디언트·가중치 그래디언트의 3회 forward pass 상당, 인퍼런스는 크리티컬 배치 사이즈 도달 시 1회 - 인퍼런스 GPU는 트레이닝의 3분의 1이면 충분
그래서 Fireworks 사용: 자체 인퍼런스 엔진 구축 대신 유한한 엔지니어를 트레이닝 효율화에 집중

글로벌 분산 인퍼런스와 1TB 가중치 배송

대형 연속(contiguous) 클러스터는 시장에서 구하기 어려움: Composer 스케일에서 2배 큰 클러스터 찾기는 현저히 더 어려움
구조: 트레이닝은 단일 클러스터, RL 인퍼런스는 전 세계 4개 클러스터에 분산
프로덕션 트래픽 GPU까지 활용: Composer 1.5 서빙 GPU를 한산한 시간대에 끌어와 트레이닝 가속 - 인퍼런스 풀 전체를 프로덕션·RL 겸용 단일 풀로 운용
인퍼런스는 광대역 인터커넥트 불필요: 소규모 GPU 그룹, 이기종·구세대 GPU 혼용 가능, 스케일 업다운 용이
난제: 1TB 모델, 트레이닝 스텝당 5-15분 - 즉 5-10분마다 1TB 스냅샷을 지구 반대편 클러스터로 배송해야 staleness가 폭주하지 않음
핵심 발견: RL은 정밀 조정이라 스텝당 실제 변하는 가중치 서브셋에 규칙적 패턴 존재 - 스텝 간 델타가 작음
델타 압축 알고리즘 구축: 풀 모델 대비 약 20배 작은 델타만 전송 - 사실상 데이터베이스 시스템 문제(풀 스냅샷·델타·복구·정합 기계 장치)
무손실 설계: 수신 측 모델이 비트 단위 동일 - 수학적 걱정 불필요
속도: 최악 조건에서도 몇 분 이내, 보통 1분 미만 - 인퍼런스 중단은 가중치 스왑 약 30초뿐
업로드·다운로드 샤딩으로 이그레스 대역폭 완전 포화: 업로드·다운로드 샤딩으로 클러스터 이그레스 대역폭 완전 포화
클러스터 분해로 인퍼런스 비용 대폭 절감: 분해(disaggregation)하면 더 싼 하드웨어·다른 리전 활용으로 비용 대폭 절감

MoE 수치 불일치와 커널 레벨 해법

비동기 트레이닝, forward pass 재현 필요: 비동기 트레이닝 탓에 인퍼런스가 만든 생성물의 로그 확률을 트레이너가 forward pass 재실행으로 재현해야 함
문제: 같은 모델 버전인데도 같은 토큰의 로그 확률이 미묘하게, 때론 크게 다름 - 이른바 수치 불일치(numerical mismatch)
근본 원인: 부동소수점 연산의 비결정성 - A+B+C와 C+B+A가 다른 결과, 누적 순서가 수백만·수십억 연산을 거치며 증폭
약한 RL 신호 특성상 수치 노이즈가 성패 좌우: 프리트레인 모델 인퍼런스에선 무시 가능하지만 RL은 극히 약한 신호로 학습하므로 이 노이즈가 트레이닝 성패를 좌우
MoE에서 특히 치명적: 게이팅 레이어가 384개 엑스퍼트 중 톱8 선택 - 히든 스테이트의 소수점 5자리 차이가 컷오프에서 7번 대신 9번 엑스퍼트를 활성화
결과: 인퍼런스는 7번 엑스퍼트를 썼는데 트레이닝은 기여하지도 않은 9번을 업데이트하는 참사
완전 결정론 커널은 가능하나 시스템이 2-3배 느려짐: 몇 퍼센트 감속으로 차이의 90%를 잡는 지점을 반복 실험으로 공동 탐색
라우터 리플레이 트릭: 인퍼런스가 활성화한 엑스퍼트 번호(정수 1개)를 트레이너에 전달해 정렬
양자화·커널 매칭으로 트레이닝-인퍼런스 발산 최소화: 그 외 양자화 레벨 매칭, 커널 매칭 등으로 트레이닝-인퍼런스 구현 간 발산 최소화
수치 불일치 방치 시 발산 컴퓨트 효율 급락: 이걸 안 하면 발산하거나 미스매치 보정에 데이터가 몇 배 더 필요해 컴퓨트 효율 급락
보상 신호 세부 내용은 영업비밀로 비공개: 보상 신호의 구체 내용은 기업 비밀로 함구

실시간 RL·롱호라이즌·자기요약

시뮬레이션 RL과 별도로 실시간 RL 병행: 유저의 만족·불만 신호로 라이브 업데이트, 몇 시간마다 새 모델 버전 배포
배포주기 축소 중이나 롱호라이즌 대응 재확장 필요: 하이퍼파라미터 안정화 후 재확장 계획
실시간 RL 단독으론 불가한 이유 1: 현재 비효율적 - GPU 유휴 시간 길음
이유 2: 시뮬레이션은 같은 프롬프트에서 16회, 128회 롤아웃 병렬 실행 가능 - GRPO류 그룹 정책 그래디언트로 훨씬 정밀한 신호
이유 3: 실유저 대상은 사실상 AB 테스트 - 이상한 출력이 곧 나쁜 유저 경험, 오프폴리시 실험 불가
시뮬레이션 RL로 기초역량 확보 후 실시간 RL 투입: 나쁜 모델은 유저가 안 쓰니 피드백도 못 받는 역설
실시간 RL은 케이크 위 체리: 언젠가 아주 큰 체리가 되길 기대(르쿤 비유 재활용: 작은 케이크, 큰 체리)
롱호라이즌 난제 1: 크레딧 어사인먼트: 궤적이 길수록 마지막 보상에서 어디가 잘·잘못이었는지 역추적이 어려움
난제 2: 컨텍스트 고갈: 해법으로 RL 루프 안에 컴팩션 내장 = 자기요약(self-summarization)
200K 컨텍스트 모델이 실제론 수백만 토큰 작업 지속: 작업 요약 후 컨텍스트 재시작하며 태스크 계속
RL이 목표 달성·좋은 요약 생성·그 요약 준수를 동시 공동 학습: 하네스 기능이던 컨텍스트 관리를 최적화 루프 안으로 흡수
컴퓨트 증가가 엔드투엔드 해결 문제 확대 재확인: 컴퓨트를 더 던질수록 엔드투엔드로 풀리는 문제가 늘어난다는 패턴의 재확인

RL 방법론 - 언제 필요하고 무엇이 환경인가

RL이 필요한 곳: Federico는 사실상 어디에나 - Tab 자동완성에도 RL 사용
Federico의 가설: 프리트레인 모델은 인류 지식 전체를 삼킨 상태라 수학 문제 앞에서 자기가 전문가인지 학생인지 모름 - RL 초기는 너는 전문가다라는 노브를 돌려 분포를 샤프닝하는 과정
RL 커브 2단계: 초반 급성장(노브 튜닝) → 이후 대량 컴퓨트로 추론 패턴이 자라는 구간 - 소규모 컴퓨트 RL도 올바름 강제만으로 유용
Dima 정리: SFT = 새 지식 전이, RL = 행동·품질 샤프닝 - 대개 둘 다 필요
기술가능 태스크엔 LLM심판 루브릭 유효: 요약 스타일처럼 좋은 예시를 만들긴 어렵지만 평가 기준은 기술 가능한 태스크에 LLM-as-judge 루브릭 RL이 유효
전문가가 롤아웃을 직접 채점하는 방식은 비추천: 검증 가능한 보상일수록 컴퓨트 스케일링이 잘 됨
LLM-as-judge가 작동하는 이유: 생성보다 판정이 쉬움(생성자-판별자 비대칭) - 다면 평가는 루브릭을 측면별로 분해
전문가의 역할은 태스크 설계와 제품 경험의 인코딩으로 이동: 소프트웨어 1.0(코드) → 2.0(데이터) → 3.0에선 평가 규칙을 크래프팅
RL 환경 벤더: Cursor는 전혀 사용 안 함 - 코딩엔 GitHub 자체가 방대한 무료 환경(의존성 설치하면 작동 환경)
벤더 가치는 인프라 제공과 자체 데이터 부재 기업 지원: 벤더 가치는 인프라 측면(DB 마이그레이션 테스트엔 DB가 떠 있어야 하는 류)과 자체 데이터 없는 회사용
최강의 RL 환경은 자기 제품 그 자체: 프로덕션을 격리·클론해서 최대한 실제와 가깝게, 장난감 Docker 컨테이너 방식은 프로덕션 전환 불가
Fireworks 트레이너는 자사, 환경은 고객측 실행: 래핑·컴포넌트화가 만드는 차이를 회피
RL 환경의 3요소: 하네스(툴 제출·실행), 오퍼레이팅 시스템(모델이 상호작용하는 실제 세계), 보상(완료 검증) - 하네스는 이식 가능, 관건은 OS
Cursor는 자체 가상머신 스택 구축: 지금 당장 VM 10만 대 달라는 초버스티 요구를 소화
환경 리얼리즘이 중요한 이유: 모델이 가짜 환경임을 감지하면 RL과 프로덕션에서 다르게 행동 - 가짜 환경 전용 보상 편법을 시도

투자자 관점 시사점

앱 레이어의 수직 특화 모델 전환이 실증됨: Composer가 Opus 대비 한 자릿수 낮은 추론 비용으로 자기 도메인을 커버 - 프런티어 랩의 API 매출 중 코딩처럼 데이터가 앱사에 축적되는 버티컬은 잠식 리스크, 반대로 Fireworks류 트레이닝·인퍼런스 플랫폼과 오픈웨이트 베이스(Kimi 2.5 채택 주목 - 중국 오픈소스가 미국 상용 제품의 기반)는 수혜
분산·이기종 RL 인프라의 성립은 초대형 단일 클러스터 프리미엄 논리를 일부 약화: 델타 압축으로 1TB 모델을 1분 내 글로벌 배송 가능하면 구세대 GPU·소형 클러스터·오프피크 용량의 경제 가치가 재평가 - 네오클라우드와 리전 분산 데이터센터에 우호적
RL 환경 벤더 매출 급증 내러티브에 체크포인트: 최대 고객이 될 법한 Cursor가 벤더를 전혀 안 쓰고 자기 제품+GitHub+자체 VM 스택으로 해결 - 환경 벤더의 지속 가능 TAM은 자체 데이터·인프라 없는 후발 주자로 한정될 소지
RL 인퍼런스가 트레이닝 플롭스를 압도한다는 통념이 미최적화 엔진의 산물이라는 지적은 RL 시대 GPU 수요 추정 모델에 하방 변수: 인퍼런스 최적화가 진행될수록 동일 트레이닝당 GPU 소요가 통념 대비 줄어들 수 있음

기억할 발언

(00:21) "가짜 환경인 걸 의식하고 다르게 행동한다는 건가? >> 그렇다. 이 환경에서 보상을 더 받는 요령을 익혔으니 써먹어 보자는 식. 모델은 치팅을 사랑하고, RL은 치팅을 부추기는 데 정말 능하다" - Federico, 환경 리얼리즘이 RL 인프라의 핵심 요건인 이유
(35:15) "프리트레인만 된 모델은 수학 문제 앞에서 자기가 전문가인지 배우는 학생인지부터 고민한다. RL이 하는 일 중 하나는 너는 전문가다, 올바르게 해야 한다는 노브를 돌려 분포를 샤프닝하는 것" - Federico, 소규모 컴퓨트 RL도 유용한 이유