Cursor ने Fireworks पर Composer कैसे ट्रेन किया: हाई-परफॉर्मेंस RL के लिए डिस्ट्रिब्यूटेड इन्फ्रास्ट्रक्चर

You need all the infrastructure to run these environments that have to mimic as closely as possible what a user's computer would look like. आपको ऐसे environments चलाने के लिए पूरा infrastructure चाहिए जो user के computer जैसा दिखे। And it's very important as closely as possible because sometimes the model can actually figure out when it's being run in like a fake environment or not a real one and it has like different behaviors during RL than in production. और यह जितना संभव हो उतना करीब होना ज़रूरी है क्योंकि model कभी-कभी यह पता लगा सकता है कि वह किसी fake environment में है या real में, और RL के दौरान उसका behavior production से अलग होता है। Are you saying it being conscious that it's being is in a fake environment and it starts being behaving differently? क्या आप कह रहे हैं कि यह सचेत है कि वह एक fake environment में है और इसलिए अलग तरह से व्यवहार करने लगता है? Yes. हां। Yes. हां। Interesting. दिलचस्प है। Like it's like oh I'm in a fake environment. जैसे कि ओह, मैं एक fake environment में हूं। I've learned a few tricks to like get the better reward in this environment and let me try them out. मैंने कुछ तरकीबें सीखी हैं इस environment में बेहतर reward पाने की, तो चलो उन्हें आज़माते हैं। Models love to cheat. Models को cheat करना बहुत पसंद है। RL is really good at encouraging cheating. RL cheating को बढ़ावा देने में बहुत अच्छा है। I'm delighted to welcome Federico from Cursor and Dima from Fireworks to the podcast today. मुझे आज podcast में Cursor से Federico और Fireworks से Dima का स्वागत करते हुए खुशी हो रही है। Federico, you are the research lead on Composer 2 at Cursor, Cursor's new agentic coding model. Federico, आप Cursor में Composer 2 के research lead हैं, Cursor का नया agentic coding model। And Dima, you spent how many of the last few months moonlighting at Cursor in order to support all of the infrastructure required to make this gargantuan training task happen. और Dima, आपने पिछले कितने महीनों से Cursor में moonlighting की इस विशाल training task के लिए आवश्यक सभी infrastructure को support करने के लिए। And so, I'm excited to talk to both of you today about how the training of Composer 2 came together, what hard problems you solved together, and what you think it means for the future of of AI and foundation model companies. तो मुझे आज आप दोनों से बात करने का बेसब्री से इंतज़ार है, Composer 2 की training कैसे आई, आपने मिलकर कौन-सी कठिन समस्याएं सुलझाईं, और इसका AI और foundation model companies के भविष्य के लिए क्या मतलब है। Exciting. रोमांचक। Yeah, exciting. हां, रोमांचक। Thank you for having us. हमें बुलाने के लिए शुक्रिया। Thanks for joining. शामिल होने के लिए धन्यवाद। Okay, let's dive right in. ठीक है, सीधे शुरू करते हैं। For those who haven't been following as closely, uh Cursor recently announced Composer 2, which is an agentic coding model uh meant for long horizon coding tasks. जो लोग इतनी बारीकी से नहीं देख रहे थे, Cursor ने हाल ही में Composer 2 announce किया है, जो एक agentic coding model है जो लंबे horizon के coding tasks के लिए बना है। Federico, uh up till now, um Cursor was mostly uh enabling uh other people's uh coding agents. Federico, अब तक Cursor ज़्यादातर दूसरों के coding agents को enable कर रहा था। Uh what was the impetus for Cursor to lean so heavily into Composer 2, and how existential is it for you to become not just an application company but also a foundation model company yourselves? Cursor के लिए Composer 2 पर इतना ज़ोर देने का क्या कारण था, और यह आपके लिए कितना existential है कि आप सिर्फ एक application company नहीं बल्कि खुद एक foundation model company भी बनें? The reason why we started looking into training our own models is you can sort of think about the model as sort of like like a storage drive. हम अपने खुद के models train करने की ओर क्यों देखने लगे, इसकी वजह यह है कि model को एक storage drive की तरह सोचें। It has certain amount of bits that it can store in its weights. उसके weights में कुछ निश्चित bits store हो सकते हैं। And the idea is very simple, you know, like we care about only one task. और idea बहुत simple है, हम सिर्फ एक task की परवाह करते हैं। We don't even care about coding or programming necessarily. हम coding या programming की भी ज़रूरी परवाह नहीं करते। We care about software engineering inside cursor and inside cursor only. हम Cursor के अंदर software engineering की परवाह करते हैं, और केवल Cursor के अंदर। And so, what if we were to allocate all of the bits of information that can be stored inside the model weights to that one particular task? तो क्या हो अगर हम model weights में store होने वाली सारी information को उसी एक task के लिए allocate कर दें? Also, as people may have noticed, composer is order of magnitude less expensive than Opus and other like coding models because we can just simply specialize all of the model weights to that particular task. और जैसा लोगों ने शायद notice किया होगा, Composer Opus और दूसरे coding models से कई गुना सस्ता है क्योंकि हम model के सभी weights को उस specific task पर specialize कर सकते हैं। And so, we can serve like a smaller model or something of that sort, yeah. और इसलिए हम एक छोटा model या ऐसा कुछ serve कर सकते हैं, हां। So, it's about let's make sure every single bit of weight or information we have is dedicated toward the specific problem that we have at hand. तो बात यह है कि हमारे पास जो भी weight या information है, वह सब उस specific problem के लिए dedicated हो। Exactly. बिल्कुल। Got it. समझ आया। Um that seems like it's an almost generalizable problem. यह लगभग एक generalizable समस्या लगती है। Uh Dima, I'm curious your perspective. Dima, मुझे आपका perspective जानने की उत्सुकता है। Do you think that every application company should be looking at cursor as a harbinger of what's to come? क्या आपको लगता है कि हर application company को Cursor को आने वाले समय का संकेत मानना चाहिए? Like should they all be looking to do the same thing? क्या उन सबको यही करना चाहिए? Yeah, absolutely. हां, बिल्कुल। I mean, we actually generally see it as a pattern of kind of evolution of the applications. मतलब, हम इसे applications के evolution का एक pattern मानते हैं। You maybe start prototyping, you might be using kind of off-the-shelf model to get something running, maybe do some prompt engineering, figure out how your harness works. शायद आप prot prototype करना शुरू करें, कोई off-the-shelf model use करें कुछ चलाने के लिए, थोड़ा prompt engineering करें, समझें कि आपकी harness कैसे काम करती है। But the most kind of leveraged attribute of your application is the actual usage of user data or particular specific aspects of how this application works, maybe some aspects of your harness, which tools do you provide, how the application works, kind of really important bits which are important for your application. लेकिन आपके application का सबसे leveraged पहलू है user data का actual use या इस application के काम करने के specific aspects, जैसे आपकी harness के कुछ पहलू, कौन-से tools आप provide करते हैं, application कैसे काम करती है, ये सब आपके application के लिए सबसे ज़रूरी बातें हैं। And the right way to capture that, you can do a little bit of that through prompting, but really the right way to do this is craft your model to act in your environment. और इसे capture करने का सही तरीका, prompting से थोड़ा हो सकता है, लेकिन असल में सही तरीका है अपने model को अपने environment में act करने के लिए तैयार करना। Yeah, absolutely. हां, बिल्कुल। Like there are certain tools the agent calls that it's very hard to succinctly describe exactly the behavior of that tool to the model. कुछ ऐसे tools हैं जिन्हें agent call करता है, जिनके behavior को model को संक्षेप में describe करना बहुत मुश्किल है। And you know, with just like post-training, we can bake in the optimal way to use those tools. और सिर्फ post-training से हम उन tools को use करने का optimal तरीका bake in कर सकते हैं। Like Composer, we do serve a prompt to Composer, but I I think the way we are training it, it would work even without a prompt and it would know what to do just because like we are intrinsically pushing the model to like the right direction of how it should act throughout our training. जैसे Composer, हम Composer को एक prompt serve करते हैं, लेकिन मुझे लगता है कि जिस तरह से हम इसे train कर रहे हैं, यह बिना prompt के भी काम करेगा और जानेगा क्या करना है, क्योंकि हम training के दौरान model को inherently सही दिशा में push कर रहे हैं। Basically, there's kind of like upper bound of like how far you can get with prompt engineering. असल में prompt engineering से आप कितना आगे जा सकते हैं, इसकी एक upper bound है। And if you want to uh craft really great AI products, you have to go through kind of fine-tuning and influence model behavior. और अगर आप सच में बेहतरीन AI products बनाना चाहते हैं, तो आपको fine-tuning करनी होगी और model behavior को प्रभावित करना होगा। That's kind of one reason. यह एक कारण है। I mean, reason number two is what Federico mentioned is kind of cost trade-off or XP trade-off. और दूसरा कारण, जो Federico ने बताया, वह है cost trade-off या XP trade-off। Like the way we kind of view it at Fireworks is that when you're trying to do optimization, you have this like three-dimensional trade-off between quality, speed, and cost. Fireworks में हम इसे तीन-आयामी trade-off की तरह देखते हैं: quality, speed, और cost के बीच। And uh you can go quite far and we're doing it with all of our customers initially. और हम सिर्फ infrastructure optimize करके काफी आगे जा सकते हैं, और हम अपने सभी customers के साथ शुरुआत में यही करते हैं। We can go quite far with just optimizing infrastructure, but when you start getting to model training, you can really push this trade-off much further and you can get better model at fraction of the cost running much faster. लेकिन जब आप model training पर आते हैं, तो आप इस trade-off को बहुत आगे push कर सकते हैं और fraction of the cost पर बेहतर और तेज़ model पा सकते हैं। And you know, Composer is a great example of और Composer इसका एक बेहतरीन उदाहरण है। Can I push on this a little bit? क्या मैं इस पर थोड़ा और push कर सकती हूं? I want to ask you if this approach is better lesson pills. मैं आपसे पूछना चाहती हूं कि क्या यह approach bitter lesson के खिलाफ जाती है। And we were we were actually all talking about TabNine on the walk-in. और हम सब walk-in पर TabNine के बारे में बात कर रहे थे। I'm remembering before the LLM era, there were these like small specialized coding models. LLM era से पहले, ये छोटे specialized coding models होते थे। And one of the things that was I think surprising to to a lot of people was as you've scaled up, you know, you scaled up just training on the internet and a lot of a bunch of English text and other languages, actually the models themselves got inherently better at coding as well. और एक चीज़ जो मुझे लगता है बहुत लोगों को हैरान करने वाली थी, वह यह कि जैसे-जैसे आपने scale up किया, internet और बहुत सारे English text पर training की, models खुद-ब-खुद coding में भी बेहतर हो गए। And so at least the trend line I've seen so far is just like bigger models perform better on everything including on coding. और अब तक मैंने जो trend line देखी है वह यही है कि बड़े models coding सहित सब चीज़ों में बेहतर perform करते हैं। Is what you guys are saying, does that go against the grain of the better lesson? क्या आप लोग जो कह रहे हैं वह bitter lesson के खिलाफ जाता है? I think no, but one one sort of like thing to point out is that the big models trained by the labs train on a lot of code as well. मुझे नहीं लगता, लेकिन एक बात यह है कि labs के बड़े models भी बहुत सारे code पर train होते हैं। Like code is one of the main tasks the labs are interested in pushing and so they don't just generalize to it. Code उन मुख्य tasks में से एक है जिन पर labs focus करती हैं, इसलिए वे सिर्फ generalize नहीं करते। They're a bit specialized as well. वे थोड़े specialized भी हैं। I think for our case, actually, you know, if we believe about the bitter lesson, we are just pushing very hard on the data dimension, and we know that the models inherently have finite capacity. हमारे case में, अगर हम bitter lesson को मानते हैं, तो हम बस data dimension पर बहुत hard push कर रहे हैं, और हम जानते हैं कि models की finite capacity होती है। And so, if we want to saturate all that capacity, we need to scale data. और अगर हम उस सारी capacity को saturate करना चाहते हैं, तो हमें data scale करना होगा। And in order to ingest more data, we we need to like free up the weights from distractions the model may have. और ज़्यादा data ingest करने के लिए, हमें model के weights को distractions से मुक्त करना होगा। Mhm, okay. हां, ठीक है। Got it. समझ आया। Super interesting. बहुत दिलचस्प। Okay, let's dig into the training of Composer 2. ठीक है, Composer 2 की training में deep dive करते हैं। You launched a couple weeks ago, immediately grabbed attention. आपने कुछ हफ्ते पहले launch किया, तुरंत ध्यान खींचा। Strong benchmark numbers, much lower cost to to run inference on. मज़बूत benchmark numbers, inference चलाने की काफी कम cost। What's the short version of how Composer 2 works, and and what you guys did to make it so performant? Composer 2 कैसे काम करता है और आपने इसे इतना performant बनाने के लिए क्या किया, इसका short version क्या है? We started from a very strong base, which is uh Kimmy 2.5. हमने एक बहुत मज़बूत base से शुरुआत की, जो है Kimi 2.5। It's like a 1 trillion and parameter MoE, that's 30 B active, so very very sparse, actually. यह एक 1 trillion parameter MoE है, जिसमें 30B active हैं, तो यह actually बहुत sparse है। We sort of like looked at the stock and realized there are like two axes. हमने situation को देखा और पाया कि दो axes हैं। So, mainly Composer 1 was just pushing on one of these axes, which is reinforcement learning, but Composer 2 pushes in two different axes. Composer 1 मुख्य रूप से इन axes में से एक पर push कर रहा था, जो है reinforcement learning, लेकिन Composer 2 दो अलग axes में push करता है। One is continual pre-training, and the other is reinforcement learning. एक है continual pre-training, और दूसरा है reinforcement learning। So, the thing that made Composer 2 very good is pushing in both of these directions. तो जिस चीज़ ने Composer 2 को बहुत अच्छा बनाया वह है इन दोनों दिशाओं में push करना। So, we started off the training run by doing lots of mid-training on code tokens, almost sort of pre-training scale, actually. हमने training run की शुरुआत code tokens पर बहुत सारी mid-training से की, लगभग pre-training scale पर। And then, coming out of that mid-training run, we took the checkpoints and we did very large-scale RL on lots of lots of tasks. और उस mid-training run से निकलने के बाद, हमने checkpoints लिए और बहुत सारे tasks पर बड़े पैमाने पर RL किया। Okay, and then the premise here would be because Cursor sits in the middle of so many interesting coding tokens, you actually pretty uniquely have access to data to be able to train at almost pre-training scale. ठीक है, और premise यह होगा कि चूंकि Cursor बहुत सारे interesting coding tokens के बीच में बैठता है, आपके पास लगभग pre-training scale पर train करने के लिए data तक अद्वितीय पहुंच है। Yeah. हां। Why not pre-train your own model, then? तो फिर अपना खुद का model pre-train क्यों नहीं करते? We just think about our approach from top-down instead of bottom-up. हम अपने approach को top-down से सोचते हैं, bottom-up नहीं। So, like, how do we get a model that's useful to users in the least time possible if we were to start from the bottom, sort of figure out how how we do pre-training and then scale it up to mid-training and then, okay, now we figured out mid-training, now we do reinforcement learning. जैसे, अगर हम सबसे कम समय में users के लिए useful model कैसे बनाएं, अगर हम नीचे से शुरू करते, पहले pre-training समझते, फिर उसे scale करते mid-training तक, और फिर reinforcement learning तक। That would take a very long time to get a model out to our users. इसमें users तक model पहुंचाने में बहुत लंबा समय लगता। By doing it the other way around, we were able to give our useful model to our users in very little time. दूसरे तरीके से करके, हम बहुत कम समय में users को useful model दे पाए। So, hopefully, you know, like next Composer versions are going to be our own model instead of basing it off an open-source base. तो उम्मीद है कि अगले Composer versions हमारा खुद का model होगा, किसी open-source base पर नहीं। And what is the model roughly learning in the kind of mid-training step? और model mid-training step में क्या सीखता है? And what is the model learning in the post-training step for you? और post-training step में model क्या सीखता है? Yeah, so in mid-training, it's sort of just kind of learning about libraries of code and learning about specific code patterns that are very common, like just world knowledge as well. हां, mid-training में यह code की libraries और specific code patterns के बारे में सीखता है जो बहुत common हैं, साथ ही world knowledge भी। There is like web data there as well. वहां web data भी है। And this is sort of just creating a wider distribution that then reinforcement learning can sharpen on. और यह एक wider distribution बनाता है जिसे reinforcement learning sharpen कर सके। And so, during reinforcement learning, you know, the model gets to play directly with the cursor harness. तो reinforcement learning के दौरान, model को directly Cursor harness के साथ खेलने का मौका मिलता है। And so, it gets to learn about the world the model is going to live in for the rest of its life, right? और इसलिए यह उस दुनिया के बारे में सीखता है जिसमें model अपनी बाकी ज़िंदगी जीने वाला है। In in some way. किसी तरह से। And and so, then during reinforcement learning, that's where it learns how to call tools properly, how to navigate its environment, how to write correct code. और reinforcement learning के दौरान ही model यह सीखता है कि tools को ठीक से कैसे call करें, environment में कैसे navigate करें, और correct code कैसे लिखें। Because during mid-training, it it learns how to write code. क्योंकि mid-training में यह code लिखना सीखता है।