이제 Cursor에서 Composer 2.5를 사용할 수 있습니다.

Composer 2보다 지능과 동작이 크게 향상되었습니다. 장시간 실행되는 작업을 꾸준히 수행하는 능력이 더 뛰어나고, 복잡한 지침을 더 안정적으로 따르며, 함께 작업하기도 더 수월합니다.

학습 규모를 확장하고, 더 복잡한 RL 환경을 만들고, 새로운 학습 방법을 도입해 Composer를 개선했습니다.

더 어려운 작업으로 Composer 2.5를 학습시킨 데 더해, 커뮤니케이션 방식이나 추론 수준 조정처럼 모델의 동작 측면도 개선했습니다. 이러한 요소는 기존 벤치마크로는 잘 포착되지 않지만, 실제 사용성에는 중요하다고 보고 있습니다.

Composer 2.5는 Composer 2와 동일한 오픈소스 체크포인트인 Moonshot의 Kimi K2.5를 기반으로 합니다.

SpaceXAI와 함께 저희는 처음부터 훨씬 더 큰 모델을 학습하고 있으며, 총 컴퓨트를 10배 더 사용하고 있습니다. Colossus 2의 H100 환산 100만 개 규모와 양사의 데이터 및 학습 기법을 바탕으로, 이는 모델 성능에서 큰 도약이 될 것으로 기대합니다.

#Composer 2.5 사용해 보기

Composer 2.5의 요금은 입력 토큰 $0.50/M,출력토큰$2.50/M입니다.

또한 $3.00/M입력,$15.00/M 출력 토큰으로 이용할 수 있는 지능은 같고 더 빠른 버전도 있으며, 다른 프런티어 모델의 빠른 티어보다 저렴합니다. Composer 2와 마찬가지로 빠른 모드가 기본 옵션입니다. 자세한 내용은 모델 문서에서 확인하세요.

Composer 2.5는 첫 주 동안 사용량이 2배로 제공됩니다.

#Composer 2.5 학습

Composer 2.5에는 학습 스택 전반에 걸쳐 몇 가지 새로운 개선 사항이 포함되어 있습니다. 이러한 변경은 모델의 지능과 사용성 모두에 초점을 맞춥니다.

#텍스트 피드백을 활용한 타깃형 RL

롤아웃이 수십만 토큰에 이를 수 있게 되면서, RL에서의 크레딧 할당은 점점 더 어려운 과제가 되고 있습니다. 보상이 전체 롤아웃을 기준으로 계산되면, 어떤 구체적인 결정이 결과를 개선했는지 또는 악화시켰는지를 모델이 파악하기 어려울 수 있습니다. 이는 잘못된 도구 call, 혼란스러운 설명, 스타일 위반처럼 국소적인 동작을 억제하고자 할 때 특히 큰 제약이 됩니다. 최종 보상은 무언가 잘못되었다는 점은 알려줄 수 있지만, 어디서 잘못되었는지에 대해서는 잡음이 많은 signal입니다.

이를 해결하기 위해, 우리는 Composer 2.5를 타깃형 텍스트 피드백으로 학습시켰습니다.¹ 핵심 아이디어는 모델이 더 나은 동작을 할 수 있었던 trajectory의 바로 그 지점에 직접 피드백을 제공하는 것입니다. 대상이 되는 모델 메시지에 대해, 원하는 개선 사항을 설명하는 짧은 힌트를 만들고, 그 힌트를 해당 로컬 context에 삽입한 뒤, 그 결과로 나온 모델 distribution을 teacher로 사용합니다. 원래 context를 사용한 policy는 student로 두고, student의 token 확률이 teacher의 확률 쪽으로 이동하도록 on-policy distillation KL loss를 추가합니다. 이렇게 하면 전체 trajectory에 대한 더 큰 RL 목표는 유지하면서도, 우리가 바꾸고 싶은 동작에 대해 국소적인 training signal을 줄 수 있습니다.

텍스트 피드백 과정의 예로, 모델이 사용 불가능한 도구를 호출하려다 도구 call error가 포함된 긴 롤아웃을 생각해 보겠습니다. 롤아웃 중에 모델은 “Tool not found” 오류를 받게 되고, 그 뒤에도 추가로 유효한 도구 calls를 계속 수행합니다. 수백 번의 도구 calls 과정에서 한 번 오류가 발생했다는 사실은 최종 보상에 미치는 효과가 매우 작습니다.

텍스트 피드백을 사용하면, 문제가 있는 턴의 context에 “Reminder: Available 도구…”와 같이 사용 가능한 도구 목록이 담긴 힌트를 삽입해 이 특정 실수를 겨냥할 수 있습니다. 이 힌트는 teacher의 확률을 바꿔 잘못된 도구의 확률은 낮추고, 유효한 대체 도구의 확률은 높입니다. 그 턴에 한해서만, 그런 다음 student 가중치를 새로운 확률 쪽으로 업데이트합니다.

Composer 2.5 실행 동안, 우리는 이 방법을 coding 스타일에서 모델 커뮤니케이션에 이르기까지 다양한 모델 동작들에 적용했습니다.

#합성 데이터

RL 학습이 진행되면서 Composer의 코딩 능력은 크게 향상되어, 대부분의 학습 과제를 올바르게 해결하기 시작합니다. 지능을 계속 높이기 위해 학습 과정 전반에 걸쳐 더 어려운 과제를 동적으로 선별하고 생성합니다. Composer 2.5는 Composer 2보다 25배 더 많은 합성 과제로 학습됩니다.

실제 코드베이스에 기반한 합성 과제를 만들기 위해 다양한 접근 방식을 사용합니다. 예를 들어, 합성 접근 방식 중 하나는 기능 삭제입니다. 이러한 과제에서는 대규모 테스트 세트가 포함된 코드베이스가 에이전트에게 주어지며, 코드베이스는 계속 작동 가능한 상태로 유지하면서 특정한 테스트 가능한 기능만 제거되도록 코드와 파일을 삭제하라는 요청을 받습니다. 합성 과제는 해당 기능을 다시 구현하는 것이며, 테스트는 이를 검증할 수 있는 보상으로 사용됩니다.

대규모 합성 과제 생성의 한 가지 후속 결과는 예상치 못한 reward hacking을 유발할 수 있다는 점입니다. 모델이 더 능숙해지면서 Composer 2.5는 당면한 과제를 해결하기 위해 점점 더 정교한 우회 방법을 찾아낼 수 있었습니다. 한 사례에서는 모델이 남아 있던 Python 타입 검사 캐시를 발견하고, 삭제된 함수 시그니처를 찾기 위해 그 형식을 리버스 엔지니어링했습니다. 또 다른 사례에서는 타사 API를 재구성하기 위해 Java 바이트코드를 찾아 디컴파일할 수 있었습니다. 우리는 에이전트 기반 모니터링 도구를 사용해 이러한 문제를 찾아내고 진단할 수 있었지만, 이는 대규모 RL에 점점 더 세심한 주의가 필요하다는 점을 보여 줍니다.

#샤딩된 Muon과 듀얼 메시 HSDP

후속 사전학습에는 분산 직교화를 적용한 Muon을 사용합니다. 모멘텀 업데이트를 만든 뒤에는 모델의 자연스러운 단위에서 Newton-Schulz를 실행합니다. 즉, 어텐션 프로젝션은 어텐션 헤드별로, 적층된 MoE 가중치는 expert별로 처리합니다.

주된 비용은 expert 가중치를 직교화하는 데서 발생합니다. 샤딩된 파라미터의 경우, 같은 형태의 텐서를 배치로 묶고 all-to-all로 샤드를 완전한 행렬로 모은 다음 Newton-Schulz를 실행한 뒤, 결과를 다시 all-to-all로 원래의 샤딩 레이아웃으로 돌려보냅니다. 이러한 전송은 비동기적으로 이루어집니다. 한 task가 통신을 기다리는 동안 optimizer runtime은 다른 Muon task를 진행해 네트워크와 컴퓨트를 겹쳐 사용합니다. 이는 전체 행렬 Muon과 동일하지만, 샤드 그룹을 계속 활용할 수 있게 해주며 1T 모델에서는 optimizer step 시간이 0.2초입니다.

이 방식은 MoE 모델에 HSDP를 사용하는 방식과도 밀접하게 맞물립니다. HSDP는 여러 FSDP 복제본을 구성하고, 대응하는 샤드들 사이에서 그래디언트를 all-reduce합니다. 우리는 non-expert 가중치와 expert 가중치에 각각 별도의 HSDP 레이아웃을 사용합니다. non-expert 가중치는 비교적 작기 때문에 FSDP 그룹을 좁게 유지할 수 있으며, 대개 노드 또는 랙 내부에 머물게 됩니다. 반면 expert 가중치는 대부분의 파라미터와 대부분의 Muon 컴퓨트를 차지하므로, 더 넓은 expert 샤딩 메시를 사용합니다.

이 레이아웃을 분리해 두면 독립적인 병렬성 차원도 서로 겹쳐 활용할 수 있습니다. 즉, 단일 공유 메시에서 16개 GPU가 필요한 대신 CP=2와 EP=8을 8개 GPU에서 실행할 수 있습니다. 이렇게 하면 작은 non-expert 상태에 대해 광범위한 통신을 피하면서, expert optimizer 작업은 많은 GPU에 분산할 수 있습니다.