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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#शार्डेड Muon और डुअल-मेश HSDP

सतत प्रीट्रेनिंग के लिए, हम वितरित ऑर्थोगोनलाइज़ेशन के साथ Muon का उपयोग करते हैं। momentum अपडेट बनने के बाद, हम मॉडल की स्वाभाविक ग्रैन्युलैरिटी पर Newton-Schulz चलाते हैं: attention projections के लिए हर attention head पर, और stacked MoE weights के लिए हर एक्सपर्ट पर।

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

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

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

#Composer 2.5 आज़माएँ

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

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

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