Composer 2.5 अब Cursor में उपलब्ध है।

यह Composer 2 की तुलना में इंटेलिजेंस और व्यवहार के मामले में एक बड़ा सुधार है। यह लंबे समय तक चलने वाले टास्क पर लगातार काम करने में बेहतर है, जटिल निर्देशों का अधिक भरोसेमंद तरीके से पालन करता है, और इसके साथ सहयोग करना अधिक सहज है।

हमने प्रशिक्षण को स्केल करके, अधिक जटिल RL परिवेश जनरेट करके, और नई लर्निंग मेथड्स पेश करके Composer को बेहतर बनाया है।

Composer 2.5 को अधिक कठिन कार्यों पर प्रशिक्षित करने के अलावा, हमने मॉडल के व्यवहार से जुड़े पहलुओं—जैसे संचार शैली और प्रयास कैलिब्रेशन—में भी सुधार किया। मौजूदा बेंचमार्क इन डाइमेंशन को अच्छी तरह नहीं पकड़ते, लेकिन हमारे अनुभव में वास्तविक दुनिया में उपयोगिता के लिए ये बहुत मायने रखते हैं।

Composer 2.5, Composer 2 की तरह, उसी ओपन-सोर्स चेकपॉइंट Moonshot's Kimi K2.5 पर बनाया गया है।

SpaceXAI के साथ, हम कुल 10x अधिक compute का उपयोग करते हुए, शुरुआत से एक काफ़ी बड़ा मॉडल प्रशिक्षित कर रहे हैं। Colossus 2 के दस लाख H100-समतुल्यों और हमारी संयुक्त डेटा व प्रशिक्षण तकनीकों के साथ, हमें उम्मीद है कि यह मॉडल क्षमता में एक बड़ी छलांग होगी।

#Composer 2.5 आज़माएँ

Composer 2.5 की कीमत $0.50/Mइनपुटटोकनऔर$2.50/M आउटपुट टोकन है।

इसी इंटेलिजेंस के साथ एक तेज़ रूपांतर भी $3.00/Mइनपुटटोकनऔर$15.00/M आउटपुट टोकन में उपलब्ध है, जिसकी लागत अन्य फ्रंटियर मॉडल्स के तेज़ स्तरों की तुलना में कम है। Composer 2 की तरह, तेज़ डिफ़ॉल्ट विकल्प है। पूरा विवरण देखने के लिए हमारे मॉडल दस्तावेज़ देखें।

Composer 2.5 में पहले सप्ताह के लिए दोगुना उपयोग शामिल है।

#Composer 2.5 का प्रशिक्षण

Composer 2.5 में हमारे प्रशिक्षण स्टैक में कई नए सुधार शामिल हैं। ये परिवर्तन मॉडल की इंटेलिजेंस और उपयोगिता, दोनों पर केंद्रित हैं।

#पाठ्य फ़ीडबैक के साथ लक्षित RL

RL के दौरान credit assignment एक लगातार कठिन चुनौती बनता जा रहा है, क्योंकि रोलआउट सैकड़ों हज़ार token तक फैल सकते हैं। जब पूरे रोलआउट पर reward compute किया जाता है, तो मॉडल के लिए यह समझना मुश्किल हो सकता है कि किस विशिष्ट निर्णय ने नतीजे में मदद की या उसे खराब किया। यह खास तौर पर तब सीमित करता है जब हम किसी स्थानीय व्यवहार को हतोत्साहित करना चाहते हैं, जैसे गलत उपकरण कॉल, उलझाने वाला स्पष्टीकरण, या शैली का उल्लंघन। अंतिम reward हमें बता सकता है कि कुछ गलत हुआ, लेकिन कहाँ गलत हुआ, इसके लिए वह एक शोरयुक्त संकेत होता है।

इसे संबोधित करने के लिए, हमने Composer 2.5 को लक्षित पाठ्य फ़ीडबैक के साथ प्रशिक्षित किया।¹ विचार यह है कि trajectory में ठीक उस बिंदु पर सीधे फ़ीडबैक दिया जाए जहाँ मॉडल बेहतर व्यवहार कर सकता था। किसी target model message के लिए, हम वांछित सुधार बताने वाला एक छोटा संकेत तैयार करते हैं, उस संकेत को स्थानीय संदर्भ में जोड़ते हैं, और उससे बनने वाले मॉडल वितरण को शिक्षक के रूप में उपयोग करते हैं। हम मूल संदर्भ वाली policy को छात्र के रूप में उपयोग करते हैं और एक on-policy distillation KL loss जोड़ते हैं, जो छात्र की token probabilities को शिक्षक की ओर ले जाता है। इससे हमें उस व्यवहार के लिए एक स्थानीयकृत प्रशिक्षण संकेत मिलता है जिसे हम बदलना चाहते हैं, जबकि पूरी trajectory पर व्यापक RL objective भी बना रहता है।

पाठ फ़ीडबैक प्रक्रिया के उदाहरण के तौर पर, एक लंबे रोलआउट पर विचार करें जिसमें उपकरण कॉल की एक त्रुटि शामिल है, जहाँ मॉडल ऐसे उपकरण को कॉल करने की कोशिश करता है जो उपलब्ध नहीं है। रोलआउट के दौरान, मॉडल को “Tool not found” त्रुटि मिलेगी और वह आगे भी अतिरिक्त वैध उपकरण कॉल्स करता रहेगा। सैकड़ों उपकरण कॉल्स की प्रक्रिया में एक बार त्रुटि हो जाने का उसके अंतिम reward पर बहुत कम प्रभाव पड़ेगा।

पाठ फ़ीडबैक के साथ, हम इस विशिष्ट गलती को लक्षित कर सकते हैं। इसके लिए हम problematic turn के संदर्भ में एक संकेत जोड़ते हैं, जैसे “Reminder: Available उपकरण…” और उसके साथ उपलब्ध उपकरणों की सूची। यह संकेत शिक्षक के लिए probabilities बदल देता है, गलत उपकरण की probabilities को कम करता है और किसी वैध replacement की probabilities को बढ़ाता है। केवल उसी turn के लिए, फिर हम छात्र के weights को नई probabilities की ओर अपडेट करते हैं।

Composer 2.5 के चलाए जाने के दौरान, हमने इस विधि को कोडिंग शैली से लेकर मॉडल संचार तक, मॉडल के विभिन्न व्यवहारों पर लागू किया।

#सिंथेटिक डेटा

RL प्रशिक्षण के दौरान, Composer की कोडिंग क्षमता में काफ़ी सुधार होता है, यहाँ तक कि वह अधिकांश प्रशिक्षण समस्याओं को सही हल करने लगता है। इंटेलिजेंस को लगातार बढ़ाने के लिए, हम पूरे चलाए जाने के दौरान गतिशील रूप से अधिक कठिन कार्य चुनते भी हैं और बनाते भी हैं। Composer 2.5 को Composer 2 की तुलना में 25x अधिक सिंथेटिक कार्यों पर प्रशिक्षित किया गया है।

हम सिंथेटिक कार्य बनाने के लिए कई तरह के तरीकों का उपयोग करते हैं, जो वास्तविक कोडबेस पर आधारित होते हैं। उदाहरण के लिए, एक सिंथेटिक तरीका सुविधा हटाना है। इन कार्यों में एजेंट को एक ऐसा कोडबेस दिया जाता है, जिसमें टेस्ट का बड़ा सेट होता है, और उससे कहा जाता है कि वह कोड और फ़ाइलों को इस तरह हटाए कि कोडबेस काम करता रहे, जबकि कुछ विशिष्ट, परीक्षण-योग्य सुविधाएँ हटा दी जाएँ। सिंथेटिक कार्य फिर उस सुविधा को दोबारा implement करना होता है, और टेस्ट को सत्यापित किए जा सकने वाले reward के रूप में उपयोग किया जाता है।

बड़े पैमाने पर सिंथेटिक कार्य बनाने का एक परिणाम यह है कि इससे अप्रत्याशित reward हैकिंग व्यवहार उभर सकता है। जैसे-जैसे मॉडल अधिक सक्षम होता गया, Composer 2.5 दिए गए कार्य को हल करने के लिए लगातार अधिक परिष्कृत वैकल्पिक उपाय खोजने लगा। एक उदाहरण में, मॉडल को Python type-checking का बचा हुआ cache मिला, और उसने हटाए गए function signature को खोजने के लिए उसके प्रारूप को reverse-engineer कर लिया। एक अन्य उदाहरण में, वह किसी तृतीय-पक्ष API को फिर से बनाने के लिए Java bytecode खोजकर उसे decompile करने में सक्षम था। हम एजेंटिक निगरानी उपकरणों का इस्तेमाल करके इन समस्याओं की पहचान कर सके और उनका diagnosis कर सके, लेकिन ये बड़े पैमाने के RL के लिए आवश्यक बढ़ती सावधानी को दर्शाती हैं।

#Sharded Muon and dual mesh HSDP

सतत प्रीट्रेनिंग के लिए, हम distributed orthogonalization के साथ Muon का उपयोग करते हैं। momentum update बनने के बाद, we मॉडल की स्वाभाविक granularity पर Newton-Schulz चलाते हैं: attention projections के लिए हर attention head पर, और stacked MoE weights के लिए हर expert पर।

मुख्य लागत expert weights को orthogonalize करने में आती है। sharded parameters के लिए, हम एक ही आकार वाले tensors को batch करते हैं, all-to-all shards को पूरी matrices में इकट्ठा करते हैं, Newton-Schulz चलाते हैं, और फिर परिणाम को all-to-all के ज़रिए वापस मूल sharded लेआउट में भेज देते हैं। ये transfers asynchronous होते हैं: जब एक कार्य संचार का इंतज़ार कर रहा होता है, तब optimizer runtime दूसरे Muon कार्यों को आगे बढ़ाता रहता है, जिससे network और compute overlap हो जाते हैं। यह full-matrix Muon के बराबर है, लेकिन shard group को व्यस्त रखता है; 1T मॉडल पर optimizer step time 0.2s है।

यह इस बात से काफ़ी गहराई से जुड़ा है कि हम MoE मॉडल्स के लिए HSDP का उपयोग कैसे करते हैं। HSDP कई FSDP replicas बनाता है और corresponding shards में gradients का all-reduce करता है। हम non-expert और expert weights के लिए अलग-अलग HSDP लेआउट का उपयोग करते हैं: non-expert weights तुलनात्मक रूप से छोटे होते हैं, इसलिए उनके FSDP groups संकरे रह सकते हैं, अक्सर किसी node या rack के भीतर, जबकि expert weights में अधिकांश पैरामीटर और अधिकांश Muon compute होता है, इसलिए वे एक wider expert sharding mesh का उपयोग करते हैं।

इन लेआउट्स को अलग रखने से independent समानांतरता डाइमेंशंस को overlap करने की सुविधा भी मिलती है: CP=2 और EP=8, एक shared mesh में 16 GPUs की आवश्यकता होने के बजाय, 8 GPUs पर चल सकते हैं। इससे छोटे non-expert state के लिए wide communication से बचा जाता है, जबकि expert optimizer work को कई GPUs में फैलाया जाता है।