کرسر نے MoK کو اوپن سورس کیا ہے، جس میں ٹوکن اسکیڈولنگ، کراس جی پی یو کمیونیکیشن اور ایکسپرٹ کمپیوٹیشن کو ایک ہی جی پی یو کرنل میں ادھار لیا گیا ہے۔ اس منصوبے نے GB300 NVL72 پر MXFP8 فاروارڈ کے لیے اعلیٰ 2.37 گنا اور ریورس کے لیے 1.78 گنا کارکردگی میں اضافہ حاصل کیا، جس سے 512 GB300 جی پی یو کے ساتھ ٹریننگ ذخیرہ 41 فیصد بڑھ کر 1070.2 ٹوکنز/سیکنڈ ہو گیا۔ سگنلنگ لیٹنسی 103 مائیکرو سیکنڈ سے گھٹ کر 18 مائیکرو سیکنڈ ہو گئی۔ تجزیہ سے پتہ چلتا ہے کہ آج جب NVLink بینڈ ویدتھ 130 TB/s تک پہنچ چکی ہے، تو جی پی یو پر ڈیٹا کا انتظار نئی کارکردگی کی پابند بن چکا ہے۔ یہ کامیابی AI مقابلے کے "پورے اسٹیک سوورینٹی" مرحلے کا آغاز ظاہر کرتی ہے، جہاں جو کمپنیاں کوڈ کو گرافکس میموری اور رجسٹرز کے قریب رکھتی ہیں، انہیں زیادہ قیمت طے کرنے کا اختیار حاصل ہوتا ہے۔مضمون کا مصنف، ذریعہ: Leifengwang
21 جولائی، NVIDIA نے DeepSeek-V3 کی تربیت کے لیے GB300 NVL72 کی تازہ ترین کارکردگی کا اعلان کیا: 256 گرافکس پروسیسرز پر، ہر کارڈ کی کارکردگی 1,648 TFLOPS تک پہنچ گئی۔
کم سے کم دو ہفتے کے اندر، کرسر نے Mixture-of-Kittens، جسے MoK کہا جاتا ہے، کو اوپن سورس کر دیا۔ اس نے مزید تیز میٹرکس ضرب کے لیے کوشش نہیں کی، بلکہ MoE کے انجام کے ایک لیئر کو دوبارہ لکھ دیا، جس میں ٹوکن اسکیڈولنگ، گیو ٹرانسمیشن اور ایکسپرٹ کمپوٹیشن کو ایک ہی GPU کرنل میں ڈال دیا گیا۔
یہ بات تھوڑی سی بے ترتیب ہے۔ کیونکہ GB300 NVL72 نے 72 گرافکس پروسیسرز کو ایک ہی NVLink ڈومین میں ڈال دیا ہے، جس سے پورے ریک کا NVLink کل بینڈ ویتھ 130 TB/s تک پہنچ گیا۔ اس سپیسیفکیشن کے مطابق، GPU کے درمیان ڈیٹا منتقل کرنا پہلے ہی کافی تیز ہونا چاہئے۔
بڑے پیمانے پر MoE ٹریننگ میں، کمیونیکیشن اب بھی ماہرین کی کمپوٹیشن کو ڈریگ کرتی رہتی ہے۔
مسئلہ MoE کے ڈیٹا فلو میں ہے۔ روتر ہر مرحلے پر ٹوکن کو کس ایکسپرٹ پر بھیجا جائے، اس کا فیصلہ دوبارہ کرتا ہے، جبکہ ایکسپرٹس مختلف GPU پر بکھرے ہوئے ہیں۔ ٹوکن کو پہلے کارڈ کے درمیان بھیجا جانا چاہیے، حساب لگانے کے بعد واپس بھیجا جانا چاہیے؛ بھیجے جانے سے پہلے پوزیشن کو ترتیب دینا پڑتا ہے اور پہنچنے کے بعد ڈیٹا کے مکمل ہونے کا انتظار کرنا پڑتا ہے۔ جبکہ MXFP8 اور Blackwell Tensor Core ایکسپرٹ کمپوٹیشن کو لگاتار کم کر رہے ہیں، وہ انتظام جو پہلے کمپوٹیشن کے پیچھے چھپ جاتے تھے، اب زیادہ واضح ہو رہے ہیں۔
کرسر MoK کرتا ہے، اور یہیں سے شروع کیا جاتا ہے۔ یہ صرف ایک Dispatch کو کتنی جلدی بھیجا جا سکتا ہے، اس پر توجہ نہیں دیتا، بلکہ یہ یہ طے کرتا ہے کہ ٹوکن کس طرح ماہرین تک پہنچیں، کب حساب شروع کیا جائے، اور مواصلات اور حساب کو کیسے GPU پر ایک ساتھ استعمال کیا جائے۔
آج، جب کمپوٹیشنل ریسورسز کو بلاک ویل اور NVLink کے ذریعے انتہائی حد تک بڑھا دیا گیا ہے، ڈویلپرز کو احساس ہوا ہے: جتنی ہی تیز ہارڈویئر چلے، کم کارآمد سافٹ ویئر اورڈینیشن کو نہیں بچا سکتی۔
MoK کا اوپن سورس صرف ایک کرنل کی کامیابی نہیں ہے، بلکہ اس سے "اپلیکیشن لیول ڈیفائن آپریٹرز" کے دور کا آغاز ہوتا ہے: آخری 30% کی کمپوٹیشنل طاقت نکالنے کے لیے AI کے اسٹارٹ اپس زیریں س sovereignty کی جنگ شروع کر رہے ہیں۔
تاہم، یہ سمجھنے کے لیے کہ Cursor کا یہ ڈیزائن کیوں کام کرتا ہے، پہلے یہ دیکھنا ضروری ہے کہ MoE دراصل کہاں "کمیونیکیشن ٹیکس" ادا کر رہا ہے۔
01
MoE کا "کمیونیکیشن ٹیکس"
صرف ٹوکن بھیجنا نہیں
عام گھنے FFN میں، ٹوکن کو تقریباً ثابت وزن سے گزرنے کی ضرورت ہوتی ہے۔ MoE میں روتر شامل ہونے کے بعد، ہر ٹوکن عارضی طور پر کچھ ماہرین کا انتخاب کرتا ہے۔ جب ایکسپرٹ پیرلیل استعمال کیا جاتا ہے، تو ماہرین کو کئی GPU پر تقسیم کر دیا جاتا ہے، اس لیے ایک فارورڈ پاس میں کم از کم دو بار کراس-ڈیوائس کمیونیکیشن ہوتی ہے۔
پہلا مرحلہ Dispatch کہلاتا ہے، جس میں ٹوکن کو ماہر کے موجودہ GPU تک بھیجا جاتا ہے؛ ماہر کے حساب کتاب کے بعد، نتیجہ Combine کے ذریعے ٹوکن کے اصل مقام پر واپس بھیجا جاتا ہے۔ تربیت میں بیک پروپیگیشن بھی شامل ہے، جس کے لیے دو اور مخالف سمت کے مواصلات کے مرحلے انجام دیے جاتے ہیں۔
اگر صرف ایک بڑا مسلسل ڈیٹا A سے B تک منتقل کیا جائے، تو NVLink پہلے سے کافی تیز ہے۔ MoE کی پیچیدگی اس بات میں ہے کہ روتر ہر قدم پر مختلف ڈیٹا کا تقسیم دیتا ہے۔
کسی ماہر کے اگلے مرحلے میں بہت سارے ٹوکن مل سکتے ہیں جبکہ اگلے مرحلے میں بہت کم۔ سسٹم کو پہلے یہ گنتی کرنی ہوگی کہ ہر ماہر کے پاس کتنے ٹوکن ہیں، پھر فیصلہ کرنا ہوگا کہ ان ٹوکن کو ٹارگٹ GPU پر کہاں رکھا جائے، اور ایک ہی ماہر کے ڈیٹا کو ایک ساتھ رکھنا چاہیے۔ Grouped GEMM کو منظم ان پٹ حاصل ہونا چاہیے تاکہ یہ Tensor Core کو موثر طریقے سے فیڈ کیا جا سکے۔
مکالمہ ختم ہونے کے بعد فوری طور پر شروع نہیں کیا جا سکتا۔ ہدف والی GPU کو یہ تصدیق کرنی ہوگی کہ دور کی طرف سے لکھا گیا ڈیٹا مکمل طور پر مکمل ہو چکا ہے اور ڈیٹا واقعی دکھائی دے رہا ہے۔ ماہر بار نہیں ہوتا، کچھ GPU جلد ختم ہو جاتے ہیں، لیکن سب سے زیادہ مشغول ماہر کے ختم ہونے تک انتظار کرنا پڑتا ہے۔
تو ایک "رابطہ" مرحلے میں، ڈیٹا منتقل کرنا، لے آؤٹ جنریٹ کرنا، سنکرونائزیشن اور لوڈ ایکسیمیلیشن جیسے کئی کاموں کا مجموعہ ہوتا ہے۔ 130 ٹی بی/سیکنڈ وہ پیک بینڈ ویتھ ہے جو پورے ریک کو فراہم کر سکتا ہے، لیکن یہ ضروری نہیں کہ ہر ایک متحرک، ٹکڑوں والی MoE رابطہ اس طرح کے لینکس کو ایک ساتھ مکمل طور پر استعمال کرے۔
DeepEP نے اس کے ڈیٹا میگریشن کو بہت تیز بن دیا ہے۔ یہ خود Expert Parallel کے لیے ایک پرفارمنس اونچی مواصلاتی لائبریری ہے جو مخصوص Dispatch اور Combine کرنل فراہم کرتی ہے، FP8 کو سپورٹ کرتی ہے اور مواصلات کے لیے استعمال ہونے والے SM کی تعداد کو کنٹرول کرنے کی اجازت دیتی ہے۔ نئی ترین ورژن میں مواصلاتی ٹھروپٹ کو بہت کم SM کے ساتھ بھی برقرار رکھا جا سکتا ہے۔
ایک لیyer MoE کو ڈسپیچ، گروپڈ GEMM اور کمبائن کے درمیان مستقل طور پر ہینڈ آف کرنا پڑتا ہے۔
اس وقت ایک بہت عملی تضاد پیدا ہوتا ہے: اگر آپ کافی زیادہ ٹوکن اکٹھے ہونے کا انتظار کرتے ہیں تاکہ حساب لگائیں، تو میٹرکس بڑی ہوتی ہے، جس سے ٹینسر کورز آرام سے کام کرتے ہیں، لیکن حساب لگانے کا آغاز دیر سے ہوتا ہے؛ اگر آپ ایک ٹوکن آتے ہی اس کا حساب لگانے لگ جائیں، تو مواصلات اور حساب لگانے کا عمل جلد تر ڈھل جاتا ہے، لیکن میٹرکس بہت چھوٹی ہو جاتی ہے، جس سے GPU کے بہت سے SMs کے لیے کافی کام نہیں ہوتا۔
کئی CUDA اسٹریمز کے ذریعے مواصلات اور کمپیوٹنگ کو одно وقت میں کیا جا سکتا ہے، لیکن دونوں طرف کو درست GPU وسائل فراہم کرنا مشکل ہوتا ہے۔
MoK کے بعد کا ڈیزائن، بنیادی طور پر اس "ریتم" کے مسئلے کو حل کرنے پر مرکوز ہے۔
02
ٹوکن کو ایک ساتھ بھیجتے ہوئے کیسے گنتی کی جائے؟
MoK کا ایک سب سے دلچسپ تبدیلی یہ ہے کہ فارورڈ ڈسپیچ کو Push سے Pull پر تبدیل کر دیا گیا ہے۔
پارمیٹر کا روایتی پوش بہت واضح ہے: جب ذریعہ GPU کے پاس ٹوکن ہوتا ہے، تو وہ اسے مقصدی GPU میں فوراً لکھ دیتا ہے۔ مشکل مقصدی پتے سے نکلتی ہے۔ ایک GPU ایک ساتھ کئی دوسرے GPU سے آنے والے ٹوکنز حاصل کرتی ہے۔
ہر بھیجنے والے کو پہلے سے معلوم ہونا چاہیے کہ وہ کس سیکشن میں لکھنا ہے، نہیں تو وہ آپس میں اوورلیپ ہو جائیں گے؛ ایک ہی ماہر کے ٹوکنز کو بھی لگاتار ترتیب دیا جانا چاہیے، ورنہ بعد کا GEMM دوبارہ ترتیب دینا پڑے گا۔
جب زیادہ GPU شامل ہوتی ہیں، تو یہ شیڈولنگ عمل بھی زیادہ بھاری ہوتا جاتا ہے۔ پل نے ایک نئی طریقہ اپنایا: ماہرین کے مقصد کے GPU خود وہ ٹوکن پڑھتے ہیں جن کی ضرورت ہوتی ہے۔ انہیں صرف یہ معلوم ہونا چاہیے کہ ٹوکن کس سورس GPU پر ہے اور سورس ڈیٹا کے کس حصے میں ہے، جبکہ اپنی مقامی جگہ کا انتظام خود کرتے ہیں۔
اس سے مقصد کے پتے کے لیے کئی بھیجنے والوں کے درمیان تنظیم کی ضرورت ختم ہو گئی۔ حاصل کی گئی ڈیٹا کو براہ راست مقامی ماہرین کے مطابق ترتیب دیا جا سکتا ہے۔
د цیل، پل نے کم ڈیٹا نہیں بھیجا۔ کرسر کے مائکرو بینچ مارک میں، ایک ہی 256×256 BF16 ڈیٹا بلاک، پش NVLink پر تقریباً 159.6 KB منتقل کرتا ہے، جبکہ پل 172.0 KB تک پہنچ جاتا ہے کیونکہ پڑھنے کے لیے اضافی درخواست بھیجی جاتی ہے۔
پول کی فتح ایک اور بات میں ہے: MoE کا کمیونیکیشن ٹوٹا ہوا ہے اور لوڈ نا موازن ہے۔ NVLink کے دونوں طرف الگ الگ چینل ہوتے ہیں، جس سے پول دونوں طرف کے درخواست اور ڈیٹا واپسی کا فائدہ اٹھا سکتا ہے۔ ماہرین کے لوڈ نا موازن ٹیسٹ میں، کرسر نے NVLink کی استعمال کی شرح میں اضافہ 29% تک درج کیا۔
مطابقت کا فرق زیادہ واضح ہے۔ پش کے بعد، ہدف والی جی پی یو کو دیگر جی پی یو کے مکمل ہونے کا سگنل منتظر رہنا پڑتا ہے، ایکسپرٹ پیرلل کے بڑے سائز پر، ایک رینک زیادہ سے زیادہ 71 دوسرے پیئرز سے متعلق ہو سکتا ہے۔ پول میں، مقامی جی پی یو خود ہی ریڈنگ شروع کرتی ہے، اور جب ڈیٹا واپس آ جائے تو اسے فوراً استعمال کیا جا سکتا ہے۔
کرسر کے متعدد نوڈ مائیکرو بینچ مارک میں، یہ سگنلنگ لیٹنسی پش کے تقریباً 103 مائیکرو سیکنڈ سے پول کے 18 مائیکرو سیکنڈ تک کم ہو گئی۔
MoK نے تمام جگہوں پر Pull کا استعمال نہیں کیا۔ فورward میں Pull Dispatch اور Push Combine استعمال ہوتا ہے؛ ریورس میں Pull Reverse-Combine اور Push Reverse-Dispatch استعمال ہوتا ہے۔ Dispatch مرحلے میں کئی ذرائع سے ٹوکنز کو دوبارہ ماہر ان پٹ کے طور پر ترتیب دینا ضروری ہوتا ہے، جس میں Pull زیادہ کوآرڈینیشن بچاتا ہے؛ Combine کے دوران یہ واضح ہوتا ہے کہ ہر نتیجہ کس ٹوکن پر واپس جانا چاہیے، اس لیے اسے براہ راست Push کرنا زیادہ آسان ہوتا ہے۔
کمیونیکیشن کی سمت بدلنے کے بعد، MoK نے کمیونیکیشن اور ایکسپرٹ کمپوٹیشن کو ایک ہی میگاکرنل میں رکھا۔
یہ GPU کے SM کو دو حصوں میں تقسیم کرتا ہے۔ ایک حصہ Dispatch، Combine اور حالت کے انتظام کے لیے ذمہ دار ہے، جبکہ دوسرا حصہ صرف Expert FFN کو انجام دیتا ہے۔ مواصلاتی جانب مکمل ٹوکن کا ایک بیچ حاصل کرنے کے بعد، GPU کے مقامی گنتی کے ذریعہ حساب کی جانب کو اطلاع دیتا ہے؛ حساب مکمل ہونے کے بعد، مواصلاتی جانب کو نتائج واپس بھیجنے کے لیے اطلاع دی جاتی ہے۔
اس طرح آپ براہ راست یہ فیصلہ کر سکتے ہیں کہ کمیونیکیشن کے لیے کتنے SM اور کلکولیشن کے لیے کتنے SM استعمال کیے جائیں، جس سے کئی CUDA Stream کو آپس میں مقابلہ کرنے پر مکمل طور پر انحصار نہیں کرنا پڑتا۔ یہاں سب سے اہم پیرامیٹر "minibatch" ہے، جو ایک بار میں ماہر کو کتنے ٹوکن دیے جاتے ہیں۔
یہ بہت بڑا نہیں ہونا چاہیے۔ بہت بڑا ہونے کا مطلب ہے کہ پہلے کیلکولیشنز کے لیے لمبا انتظار کرنا پڑے گا۔ اور نہ ہی بہت چھوٹا۔ ماہرین کی GEMM کو آخرکار بہت سارے کیلکولیشن ٹاسکس میں تقسیم کیا جاتا ہے جو SMs کو دیے جاتے ہیں، اگر ٹوکنز کم ہوں تو ٹاسکس کی تعداد کم ہوگی اور بہت سارے SMs بےکار رہیں گے۔
کرسر ویو کا استعمال کرکے اس حد کا جائزہ لیتا ہے۔ ایک مکمل ویو کو سمجھا جا سکتا ہے کہ تمام SMs کو کام مل گیا ہے۔ MoK چاہتا ہے کہ ایک مینی بیچ کم از کم دو مکمل ویوز تشکیل دے تاکہ ٹینسر کور کے لیے کافی کام موجود رہے۔
عملی نتائج بہت کچھ بتاتے ہیں۔ Kimi 2.5 کے 7168 کے پوشیدہ سائز اور 2048 کے ماہر وسطی ابعاد پر، Cursor کا اندازہ ہے کہ minbatch کے لیے کم از کم تقریباً 2368 ٹوکن درکار ہوں گے۔ 512 ٹوکن پر، MoK فارورڈ کا وقت 5.981 ملی سیکنڈ ہے؛ جب اسے بڑھا کر 2560 ٹوکن کیا جاتا ہے، تو یہ 3.425 ملی سیکنڈ ہو جاتا ہے۔ مزید بڑھانے پر، رفتار میں واضح بہتری نہیں آتی۔
دوسرے الفاظ میں، مواصلات کو زیادہ چھوٹے ٹکڑوں میں تقسیم کرنا ہمیشہ تیز نہیں ہوتا۔ حقیقی طور پر موثر اوورلیپنگ کے لیے، مواصلات کو جلد از جلد ڈیٹا فراہم کرنا چاہیے، جبکہ GEMM کو بہت چھوٹا نہیں کرنا چاہیے۔
لیکن MoE کا ایک اور مسئلہ یہ ہے کہ راؤٹر ختم ہونے سے پہلے، یہ نہیں جانتا کہ ہر GPU کو آخرکار کتنے ٹوکن ملیں گے۔
اگر بدترین صورت کے لیے بفر تیار کیا جائے، تو بہت سارا GPU میموری ضائع ہو جائے گی۔ اگر پہلے GPU کو ٹوکن گننے دیا جائے اور پھر CPU کو متعلقہ جگہ تقسیم کرنے کے لیے اطلاع دی جائے، تو GPU کو CPU کا انتظار کرنا پڑے گا۔
MoK ایک ثابت سائز کا Ring Token Buffer استعمال کرتا ہے۔ ایک جگہ پہلے Dispatch ہونے والے token کو بھر دیا جاتا ہے، جب ماہرین کام مکمل کر لیتے ہیں اور Combine نتائج کو منتقل کر دیتا ہے، تو وہ جگہ فوراً اگلے token کے لیے دوبارہ استعمال کی جاتی ہے۔ ایک macrobatch کا Combine، اگلے macrobatch کے Dispatch کے ساتھ ایک ساتھ ہو سکتا ہے۔
رِنگ بفر یہاں ایک بفر لیئر کی طرح ہے: جب مواصلات تیزی سے چل رہی ہوتی ہیں، تو ڈیٹا اس میں جمع ہو جاتا ہے؛ جب کمپوٹیشن تیزی سے استعمال ہوتی ہے، تو اگلے ٹوکن کے آنے کا انتظار کیا جاتا ہے۔ پوری پروسیس GPU پر موجود حالت کے ذریعے آگے بڑھتی ہے، جس سے CPU کو ہر ایک راؤنڈ میں اگلے قدم کا فیصلہ کرنے کی ضرورت نہیں پڑتی۔
کرسر نے MXFP8 ایکٹیویشن کو ڈسپچ، گروپڈ جی ایم ایم اور سوی جی ایل یو کے ڈیٹا پاتھ میں بھی شامل کر دیا ہے، جس سے الگ کوئنٹائز کرنے والے کرنل کی ضرورت ختم ہو گئی اور HBM میں درمیانی نتائج کی ایک بار پھر ریڈ اور رائٹ کرنے کی ضرورت بھی ختم ہو گئی۔
پول، مینی بیچ، ایس ایم پارٹیشن اور رنگ بفر کو ایک ساتھ رکھنے کے بعد، MoK اصل میں ایک مسلسل MoE پائپ لائن بن جاتا ہے۔
03
ایک مکمل سیٹ بلند خصوصیات والے انجام دینے کے طریقے
کرسر کا بینچ مارک مکمل MoE لیئر کو ٹیسٹ کرتا ہے، جس میں شیڈول، ڈسپیچ، ایکسپرٹ FFN، کمبائن اور آخری وزنی ادغام شامل ہیں، جس کا موازنہ NCCL + PyTorch، DeepEP، TransformerEngine اور HybridEP + Megatron کے ساتھ کیا گیا ہے۔
GB300 NVL72 پر، MoK کے MXFP8 کا فارورڈ میں سب سے تیز عوامی بیس لائن کے مقابلے میں اعلیٰ 2.37 گنا اور ریورس میں اعلیٰ 1.78 گنا بہتری ہے؛ BF16 کا فارورڈ میں اعلیٰ 1.92 گنا اور ریورس میں اعلیٰ 1.58 گنا بہتری ہے۔
مزید اہم بات یہ ہے کہ اینڈ تو اینڈ ٹریننگ۔ کرسر کا اصل پروڈکشن سسٹم پہلے سے ہی DeepEP استعمال کر رہا تھا۔ 512 GB300 GPU پر MoK میں تبدیلی کے بعد، فرد کارڈ کی ٹھیک گنجائش 760.9 ٹوکن فی سیکنڈ سے بڑھ کر 1070.2 ٹوکن فی سیکنڈ ہو گئی، جس میں تقریباً 41% کا اضافہ ہوا۔
اس نتائج کے گروپ کو بھی حدود کے ساتھ دیکھنا چاہیے۔ کرسر نے مکمل ایلیمنیشن کو عوامی طور پر شائع نہیں کیا ہے، اس لیے 2.37 گنا میں سے کتنی رقم پول، کتنی میگاکرنل، اور کتنی رنگ بفر سے آئی ہے، اس کا درست طور پر کہنا ممکن نہیں۔
صرف پول کے NVLink کے استعمال اور سائنلنگ لیٹنسی میں بہتری کی تصدیق کی جا سکتی ہے، باقی فوائد زیادہ تر مجموعی اجرائی طریقہ کار کے نتیجے میں حاصل ہوئے ہیں۔
MoK کو ہارڈویئر پر بھی زیادہ انحصار ہے۔ یہ Blackwell اور NVL72 جیسے ہائی اسپیڈ NVLink ڈومین پر مبنی ہے۔ دور کی ریڈنگ، کمیونیکیشن اور کمپوٹیشن کی باریک باریک ترتیب، GPU کے درمیان کم تاخیر والے میموری تک رسائی کے اصول پر قائم ہے۔ ماڈل کا Hidden Size، Top-k، اور اسپیشلسٹ سائز بدل جانے پر، مناسب minibatch اور کمیونیکیشن SM کی تعداد بھی بدل جاتی ہے۔
یہی MoK کا سب سے زیادہ دیکھنے کے قابل پہلو ہے۔ گزشتہ MoE کے بہتر بنانے پر بحث کرتے وقت، لوگ آسانی سے دو اعداد پر توجہ دیتے تھے: GEMM کے کتنے TFLOPS ہیں، All-to-All کے کتنے GB/s ہیں۔ GB300 کی نسل تک پہنچ کر، صرف ان دو اعداد کو مزید بڑھانا، تمام کارکردگی کی وضاحت نہیں کر سکتا۔
ٹوکن کب پہنچیں گے، ایک ماہر کی ضرورت کے مطابق کیسے ترتیب دی جائے، کتنے جمع کرنے کے بعد گنتی شروع ہوگی، کومونیکیشن سے کتنے SM حاصل ہوں گے، اور بفر کب ریلیز ہوگا — یہ تمام اجرائی تفصیلات فوری طور پر تربیت کی رفتار کو تعین کرتی ہیں۔
130 TB/s NVLink بینڈ ویتھ والے ریک کو آخر میں MoE کے لیے GPU کرنل دوبارہ لکھنا پڑا، کیونکہ لنک پہلے ہی بہت تیز ہے، اب بچانے کی ضرورت صرف GPU اور دیگر ڈیٹا کے درمیان کے وقت کی ہے۔
کرسر کی GPU کور کو دوبارہ لکھنے کا عمل، AI 2.0 کے دور کی مقابلہ کو "پورے اسٹیک کی حاکمیت" کے نئے مرحلے میں لے جاتا ہے۔
پہلے، ہمیں یقین تھا کہ "ہر فن میں ماہر ہونا چاہیے"، ایپلیکیشن بنانے والا ایپلیکیشن بنائے (Cursor)، اور بنیادی چیزوں کا کام کرنے والا بنیادی چیز کرے (NVIDIA)۔ لیکن آج کے AI مقابلے میں "درمیانی طرفداروں کو ختم کرنے" کا نیا مرحلہ آ چکا ہے، Cursor نے اس لیے اپنے اندرونی ہستی کو بنایا کیونکہ وہ "چاہتا تھا" بلکہ اس لیے کہ وہ "ضرورت پڑی"۔
ڈیپسیک نے انجینئرنگ ایکسٹریکشن کے نئے دور کا آغاز کر دیا ہے، جبکہ کرسر نے اس آگ کو ایپلیکیشن لیول تک پہنچا دیا ہے۔ یہ "بیچوں کو ختم کرنے" کا رجحان AI کی قیمت تعین کو دوبارہ شکل دے رہا ہے: مستقبل میں، AI کمپنیوں کی قیمت کا فیصلہ نہیں ہوگا کہ ان کے پاس کتنے ٹوکن ہیں، بلکہ یہ ہوگا کہ ان کا کوڈ کتنے قریب ہے ویڈیو میموری اور رجسٹرز سے۔
جس کمپنیاں بنیادی بلیک باکس کو نہیں توڑ سکتیں، وہ آخرکار "عامیانہ ٹیکس" کے بھنور میں ہی رہ جائیں گی۔