اوٹیمان نے پوڈکاسٹ میں بتایا کہ OpenAI کیوں Codex کو Sora کے بجائے زیادہ وسائل فراہم کر رہا ہے۔ Sora کے ویڈیو جنریشن کے لیے بہت زیادہ مسلسل کمپوٹیشن کی ضرورت ہوتی ہے، جس سے ایک منفرد ٹاسک GPU کے وقت کو دوبارہ استعمال نہیں کیا جا سکتا؛ جبکہ Codex KV cache، continuous batching، اور ٹول کالز جیسے مکینزمز کے ذریعے کمپوٹیشن کو متعدد قابل ترتیب مراحل میں تقسیم کرتا ہے، جس سے ایک ہی GPU متعدد متوازی ورکفلوز کو سپورٹ کر سکتا ہے۔ GPU کے وقت کو دوبارہ استعمال کرنے کی صلاحیت اب AI پروڈکٹس کی توسیع کی رفتار کا تعین کر رہی ہے۔

مضمون کے مصنف، ذریعہ: Leifengwang

سورا کیوں کوڈیکس سے ہار گیا؟

23 اگست کو، اوٹیمان نے ڈیوڈ سینرا کے پاڈکس میں OpenAI کے اندر وسائل کے ترجیحات کے بارے میں بات کرتے ہوئے سورا کا ذکر خود کیا۔

اس نے براہ راست کہا: سورا ایک اچھا پروڈکٹ ہے، اسے جاری رکھنا ایک اچھا کاروبار بن سکتا ہے، لیکن یہ بہت زیادہ کمپیوٹ کا استعمال کرتا ہے، اسی دوران کوڈیکس کو ترجیح دی گئی، اس لیے کمپیوٹنگ طاقت اور ٹیم کا توجہ کوڈیکس کی طرف مائل ہونے لگا۔

لیکن دلچسپ بات یہ ہے کہ Codex GPU بھی بہت زیادہ استعمال کرتا ہے۔ Sora ایک ویڈیو بنانے کے لیے بڑے时空 latent کو کئی راؤنڈ Transformer کی حسابگری سے گزارتا ہے؛ جبکہ Codex کو "اس بگ کو ٹھیک کر دو" کا حکم ملتا ہے، تو پیچھے کئی راؤنڈ انفرنس، کوڈ پڑھنا، ٹولز کا استعمال، ٹیسٹ چلانا، اور نئے لاگ اور سیاق و سباق کے ساتھ واپس آ کر مزید انفرنس کرتا رہتا ہے۔

ایک کمپیوٹنگ طاقت کو صرف ایک ویڈیو جنریشن میں مرکوز کرتا ہے، جبکہ دوسرا کمپیوٹنگ طاقت کو ایک ایسے ایجنٹ ورک فلو میں تقسیم کرتا ہے جو کئی دہائیوں تک یا اس سے زیادہ جاری رہ سکتا ہے۔ اس طرح، Sora اور Codex کے درمیان اصل فرق کمپیوٹر روم کے اندر ظاہر ہونا شروع ہوتا ہے۔

ایک ہی سیٹ کے GPU کے ساتھ، ویڈیو جنریشن کے لیے کمپیوٹ کو زیادہ مشکل سے تقسیم کیا جا سکتا ہے، جبکہ کوڈنگ ایجنٹ KV کیش، مسلسل بیچنگ، پریفِل / ڈیکوڈ شیڈولنگ اور ٹول کے انتظار کے ذریعے کمپیوٹنگ طاقت کو زیادہ متوازی کاموں میں دوبارہ ڈال سکتا ہے؟

در حقیقت، سورا کی شکست مطلق حسابی طاقت کے استعمال میں نہیں بلکہ اس کے ورک لوڈ آرکیٹیکچر میں ہے: سورا کی حسابی طاقت مسلسل اور منفرد ہے، جبکہ کوڈیکس کی حسابی طاقت ٹکڑوں میں اور دوبارہ استعمال کے قابل ہے۔ یہ اسکیڈولنگ میکنزم کا فرق دونوں کی توسیع کی رفتار کو الگ کرتا ہے۔

اس لائن کے نیچے دیکھنے سے معلوم ہوتا ہے کہ سورا جو وسائل کھو رہا ہے، اس کے پیچھے شاید GPU کے وقت کو کیسے استعمال کیا جائے اس پر ایک انتخاب ہے۔

سورا کی لاگت شاید ویڈیو کو ماڈل میں داخل ہوتے ہی بڑھنا شروع ہو جاتی ہے۔ یہ اصل ویڈیو کو لیٹنٹ اسپیس میں دبائے گا، پھر اسے اسپیس ٹائم پیچز میں کاٹ دے گا، تاکہ ٹرانسفارمر ان پیچز پر حساب لگا سکے۔

ٹیکسٹ ٹوکنز بنیادی طور پر ترتیب کی سمت میں بڑھتے ہیں، جبکہ ویڈیو پیچس وقت، اونچائی اور چوڑائی پر ایک ساتھ پھیل جاتے ہیں، جس کی وجہ سے ویڈیو ماڈل کے اندر قدرتی طور پر ایک حجم والی حالت بن جاتی ہے۔

عام طور پر، ویژول ٹوکن کی تعداد کو سمجھا جا سکتا ہے N_video ≈ T × H × W۔ یہاں T،H اور W کو کمپریس اور پیچ کیا جا چکا ہے، لیکن تین ابعادی ضرب کا تعلق موجود ہے۔

ویڈیو کی لمبائی بڑھانے سے وقت کی سمت میں پیچ بڑھ جاتا ہے، اور اسکرین کے سائز میں اضافہ فضا کے پیچ کو بڑھا دیتا ہے۔ یعنی، ویڈیو کی لمبائی اور فضائی سائز الگ الگ لاگت نہیں بڑھاتے، بلکہ وہ مل کر لیٹنٹ گرڈ کو پھیلاتے ہیں۔

اس گرڈ کو ٹرانس فارمر میں داخل ہونے کے بعد، ڈیفیوژن کے ذریعے دوسری سطح کی حسابگری کا سامنا کرنا پڑتا ہے۔ سورا اندھیرے لیٹنٹ سے شروع ہوتا ہے، اور ہر راؤنڈ میں موجودہ حالت کے مطابق ویڈیو کی نمائندگی کو اپڈیٹ کرتا ہے، پھر نیا لیٹنٹ اگلے راؤنڈ میں بھیج دیا جاتا ہے۔

ایک ویڈیو کی حساب کتاب کو تقریباً سمجھا جا سکتا ہے C_video ≈ D × C_transformer(N_video)، جہاں D نمونہ لینے کے تکرار کی تعداد ہے۔ ویڈیو لیٹنٹ جتنا بڑا ہوگا، ہر ایک راؤنڈ اتنا ہی زیادہ بھاری ہوگا؛ نمونہ لینے کے راؤنڈز بڑھنے سے، ایک ہی ویڈیو کے لیے نیٹ ورک کو کئی اور راؤنڈز چلانے پڑیں گے۔

یہاں ویڈیو ڈیفیوژن اور LLM کے درمیان بنیادی فرق واضح ہے۔ زبانی ماڈل اگلے ٹوکن کو جنریٹ کرتے وقت، پچھلے Key اور Value کو KV کیش میں محفوظ رکھا جا سکتا ہے، جس سے ماڈل کو ہر مرحلے پر پورے تاریخی حالات کو دوبارہ تعمیر کرنے کی ضرورت نہیں پڑتی۔

ہر اپڈیٹ کے بعد ویڈیو ڈیفیوژن میں بنیادی لیٹنٹ تبدیل ہو جاتا ہے، اگلے دور میں ایک نئی سپیس ٹائم حالت کا سامنا ہوتا ہے، اس لیے ویڈیو کے بنیادی عنصر کے لیے بہت سارے کمپوٹیشن جاری رکھنے پڑتے ہیں۔

اس لیے Sora کی لاگت کو "قدیم استعمال" کے ذریعے زیادہ تر کم نہیں کیا جا سکتا۔ یہ ایک ویژوئل ایفکٹ شاٹ کی طرح ہے جو کئی مرحلوں میں پروسیس ہوتی ہے، جہاں ہر مرحلہ مکمل طور پر تبدیل ہو چکی تصویر کو پروسیس کرتا ہے۔ ویڈیو جتنا لمبا، جتنا بڑا اور جتنا زیادہ نمونہ لیا جائے، اتنی ہی زیادہ یہ تولید کا راستہ بھاری ہوتا جائے گا۔

چونکہ ہر ایک ٹاسک کافی بھاری ہے، اس لیے سورا کا جی پی یو استعمال کا فیصد اچھا دکھائی دے سکتا ہے۔ بڑے سائز کے میٹرکس کی حساب کتاب سے ٹینسر کور لمبے وقت تک مصروف رہتے ہیں، اور مانیٹرنگ گراف میں جی پی یو تقریباً کبھی آرام نہیں کرتی۔

بالا استعمال صرف اس بات کی نشاندہی کرتا ہے کہ چپ مستقل کام کر رہی ہے، لیکن اس کا مطلب یہ نہیں کہ ایک اوقات میں بہت سارے کام مکمل ہو رہے ہیں۔ اگر ایک ویڈیو لمبے عرصے تک ایک گروپ GPU کو قبضہ کر لے، تو استعمال کا شکلی خوبصورت ہونا بھی اس بات کو تبدیل نہیں کرتا کہ ایک الگ درخواست پر GPU-seconds کا خرچ زیادہ ہے۔

ویڈیو سروس کو شیپ کے فرق کی وجہ سے اب بھی روکا جا رہا ہے۔ مختلف لمبائیاں، ریزولوشن اور ایسپیکٹ ریشو کی وجہ سے مختلف ٹینسر شیپس بن جاتی ہیں۔ سرور کو بیچ کی کارکردگی بڑھانے کے لیے، اسے ایک جیسے سائز والے درخواستوں کو ایک ہی بکیٹ میں ڈالنا ہوتا ہے۔ تھوڑا اور انتظار کرنے سے زیادہ موثر بیچ حاصل ہو سکتی ہے، لیکن اس سے قطار میں تاخیر بڑھ جاتی ہے؛ فوری انجام دینے سے انتظار کم ہوتا ہے، لیکن بیچ ممکنہ طور پر پوری نہیں ہوتی۔

اس لیے، سورا کی زیادہ تر کمپوٹیشنل لاگت ایک ویڈیو کے اپنے جنریشن پاتھ میں بند ہو چکی ہے۔ نمونہ لپوں کو کم کیا جا سکتا ہے، لیٹنٹ کو مزید کمپریس کیا جا سکتا ہے، ماڈل کو ڈسٹل کیا جا سکتا ہے، اور کرنل کو مزید آپٹیمائز کیا جا سکتا ہے، لیکن شیڈولر صرف "ان وزن کاموں کو کیسے ترتیب دیا جائے" میں تبدیلی کر سکتا ہے، "ایک ویڈیو خود میں بہت زیادہ مسلسل کمپوٹیشن کی ضرورت ہوتی ہے" اس حقیقت میں تبدیلی نہیں کر سکتا۔

یہ کوڈیک کو سمجھنے کا ایک دروازہ بھی ہے۔ کوڈیک بھی مہنگا ہے، لیکن یہ تمام لاگت کو ایک مسلسل کمپیوٹیشنل بلاک پر نہیں ڈالتا، بلکہ اس کام کو کئی ایسے مراحل میں تقسیم کرتا ہے جنہیں روکا، دوبارہ شروع کیا اور دوبارہ جوڑا جا سکتا ہے۔

صارف نے کوڈیکس کو "اس بگ کو ٹھیک کریں" کہا، اور یہ کام ایک منفرد ماڈل کال کے ساتھ ختم نہیں ہوتا۔ ایجنٹ پہلے ریپوزٹری کو پڑھ سکتا ہے، ماڈل کو اگلے قدم کا فیصلہ کرنے کے لیے متحرک کرتا ہے، اور پھر شیل کو نفاذ کرتا ہے؛ خطا کے بعد، وہ لاگز کو حوالہ میں شامل کرتا ہے، ماڈل کو دوبارہ بلاتا ہے؛ اس کے بعد کوڈ میں تبدیلی کرتا ہے، ٹیسٹ چلاتا ہے، اور نئے نتائج کے مطابق مزید استدلال جاری رکھتا ہے۔

تو ایک Codex کا کام بہت سارے راؤنڈز کے جمع ہونے کے قریب ہے Prefill + Decode + Tool۔ اہم بات یہ ہے کہ ہر ٹول کال کے بعد، اگلے راؤنڈ میں ماڈل کو عام طور پر زیادہ موثر ماحول دکھائی دیتا ہے۔

شروع میں، ماڈل صرف صارف کی درخواست اور کچھ کوڈ رکھتا ہے۔ کچھ دیر چلنے کے بعد، مزید فائلیں، ڈیف، ٹرمینل آؤٹ پٹ، ٹیسٹ لاگز اور ٹولز کے نتائج پرومپٹ میں داخل ہوتے رہتے ہیں۔

صارف کا آخری دیکھا گیا شاید صرف کچھ سو الفاظ کا مکمل تفصیل ہو، لیکن GPU کے درمیان پردازش کیے گئے مواد کا حجم بہت بڑا ہو سکتا ہے۔ ایجنٹ ٹوکن استعمال کا دباؤ، اس لگاتار بڑھتی ہوئی کام کی راہ میں چھپا ہوا ہے۔

اگر ہر انفرنس راؤنڈ میں پوری تاریخ دوبارہ پروسیس کی جائے، تو لمبے کام جلد ہی دوبارہ پریفِل کی وجہ سے روک دیے جائیں گے، اس لیے پرامپٹ کیشِنگ کوڈیکس کے لیے انتہائی اہم ہے۔

فرض کریں کہ ایک ایجینٹ کے پاس 100K ٹوکن کا کنٹیکس ہے، اور ٹول کے انجام کے بعد صرف 3K ٹوکن کے لاگز شامل ہوتے ہیں؛ اگر پچھلے مستحکم پریفکس کی کیش میں مطابقت ہو جائے، تو اس دور میں نئی حسابگاری صرف اس آخری حصے پر مرکوز ہوگی؛ اگر پرومپٹ کے شروع میں تبدیلی کی وجہ سے کیش میچ نہ ہو، تو سسٹم دوبارہ ایک بڑی پریفِل کا سامنا کر سکتا ہے۔

یہاں ایک اہم تبدیلی آئی ہے: منطقی ٹوکن کی تعداد اب حقیقی GPU لاگت کو ب без سیدھا ظاہر نہیں کر سکتی۔ دونوں درخواستوں میں 100K ان پٹ ٹوکن دکھائی دے رہے ہیں، جن میں سے ایک کا زیادہ تر مواد پہلے سے کیش ہے، جبکہ دوسرا دوبارہ کمپیوٹ کرنے کی ضرورت رکھتا ہے، اور ان دونوں کا GPU پر مکمل طور پر مختلف اثر ہوتا ہے۔ اس لیے ایجنٹ کا لوڈ متعلقہ ترقی کی شرح، کیش ہٹ، اور ایک ٹاسک کتنی بار مدل میں دوبارہ داخل ہوتا ہے، اس پر منحصر ہے۔

ایک انفریس کے بعد، پریفیل اور ڈیکوڈ کے لیے الگ الگ ہارڈویئر کی ضرورتیں ہوتی ہیں۔ پریفیل ایک بار میں بہت سارے انپٹ ٹوکنز کو پروسیس کرتا ہے، جس کا میٹرکس سائز بڑا ہوتا ہے اور یہ زیادہ تر کمپیوٹیشنل طاقت کی ضرورت رکھتا ہے؛ جبکہ ڈیکوڈ ہر سیکوئنس کے لیے ہر راؤنڈ میں صرف کچھ ٹوکنز پیدا کرتا ہے، لیکن مدل وزن اور KV کیش کو دوبارہ دوبارہ ایکسیس کرتا ہے، اس لیے یہ HBM بینڈ وڈتھ اور کانکرنس سائز پر زیادہ انحصار کرتا ہے۔

ایسے میں اگر الگ الگ سیکوئنس چلائی جائیں تو بہت زیادہ وسائل ضائع ہوں گے۔ ماڈل کے وزن اب بھی اتنے ہی بڑے رہیں گے، اور ایک ٹوکن بنانے کے لیے بھی مکمل فارورڈ کمپوٹیشن میں شرکت کرنی پڑے گی۔ سرور صرف اسی صورت میں کئی سیکوئنسز کو ایک ہی بیچڈ فارورڈ میں ڈال کر ایک وزن ایکسیس کے ذریعے زیادہ سے زیادہ درخواستوں کو آگے بڑھا سکتا ہے۔

اور بیچ کو مزید بڑھایا جا سکتا ہے، لیکن یہ KV کیش کی حدود سے متاثر ہوگا۔ ہر سیکوئنس کا کنٹیکس جتنا لمبا ہوگا، اتنا ہی زیادہ HBM استعمال ہوگا۔ ایجنٹس کی تعداد بڑھنے کے بعد، GPU پر شاید ریاضیاتی رسد باقی رہے، لیکن گھریلو میموری میں مزید فعال حالتیں نہیں ڈالی جا سکتیں۔

پیجڈ اٹینشن کی ایک قسم KV کیش کو صفحات کے طور پر منظم کرنے کے ذریعے گرافکس میموری کے ٹکڑوں کو کم کرتی ہے، جو بنیادی طور پر ایک GPU کے ساتھ одно وقت میں قابلِ برقرار رکھنے والی سیکوئنس کی تعداد بڑھانے کا طریقہ ہے۔

ٹول کال نے کوڈیک کے لوڈ کو مزید تقسیم کر دیا۔ جب ایجینٹ ٹیسٹ چلاتا ہے، کوڈ کو کمپائل کرتا ہے یا I/O کا انتظار کرتا ہے، تو GPU کو اس کے لیے مزید کام نہیں کرنا پڑتا، بلکہ CPU، کنٹینر اور فائل سسٹم ان کاموں کو سنبھال لیتے ہیں۔ جب نتائج واپس آتے ہیں، تو یہ ایجینٹ اگلے انفرنس چکر میں داخل ہوتا ہے۔

اس لیے 60 منٹ تک چلنے والا ایجنٹ کا مطلب یہ نہیں کہ وہ 60 منٹ تک GPU کو مسلسل قبضہ کرے گا۔ اس کا کام مدل کی حساب کتاب اور باہری اجراء میں تقسیم ہو جاتا ہے، جس سے اسکیولر کو ایک ایسا جگہ ملتی ہے جو سورا فراہم نہیں کر سکتا: جب کوئی ایجنٹ ٹول چلائے، تو GPU فوراً دوسرے سیکوئنس کی خدمت کرنے لگتا ہے۔

بے شک، یہ نئے ویڈیو میموری کے مسائل بھی پیدا کرے گا۔ ٹول کا ایجینٹ KV کیش کو برقرار رکھے یا نہ رکھے؟ برقرار رکھنے سے تجدید تیز ہوگی، لیکن یہ HBM کو طویل عرصے تک قبضہ کرے گا؛ نکالنے سے جگہ خالی ہو جائے گی، لیکن جب کام واپس آئے گا تو اسے تجدید کا اخراج اٹھانا پڑے گا۔ جتنے زیادہ ایجینٹ ہوں گے، اتنے ہی زیادہ یہ انتخاب آپریٹنگ سسٹم کی طرح ہوگا جو بہت سارے سلپ اور جاگنے والے پروسیسز کو مینج کر رہا ہوتا ہے۔

یہاں تک، کوڈیکس اور سورا کے درمیان فرق صرف “کون زیادہ بھاری ہے” نہیں، بلکہ لاگت کو کیسے تقسیم کیا گیا ہے اس پر ہے۔ سورا کی کمپوٹیشن ایک مسلسل جنریشن پاتھ میں مرکوز ہے، جبکہ کوڈیکس کی کمپوٹیشن متعدد مراحل میں تقسیم ہے۔ اسی لیے کہ یہ تقسیم ہو گئی، کوڈیکس اگلے سطح کے بہترین عمل میں داخل ہو سکتا ہے: جہاں اسکیڈولر فیصلہ کرتا ہے کہ ان مراحل کس طرح ایک ہی GPU کے ساتھ شیئر ہوں۔

بڑے ماڈلز کو آن لائن چلانے کے دوران، وزن عام طور پر GPU پر لمبے عرصے تک رہتے ہیں، اور ٹینسر پیرلیل، نوڈ کمیونیکیشن اور کیش حالت کو برقرار رکھنا پڑتا ہے۔ اس لیے Sora اور Codex کے درمیان وسائل کی لڑائی زیادہ تر فلیٹ لیول پر ہوتی ہے: ایک حصہ GPU لمبے عرصے تک ویڈیو سروسنگ پول میں داخل ہو جاتا ہے، جبکہ دوسرا حصہ لمبے عرصے تک LLM پول میں رہتا ہے، اور اوپری کیپسٹی سسٹم فیصلہ کرتا ہے کہ کس طرف توسیع کی جائے اور کس طرف ریڈکشن کی جائے۔

حقیقی پیچیدگی Codex پول کے اندر پیدا ہوتی ہے۔ فرض کریں کہ سسٹم میں ایک ساتھ 200 ایجنٹ سیکوئنس موجود ہیں، جن میں سے کچھ ڈیکوڈ کر رہے ہیں، کچھ ٹولز کا انتظار کر رہے ہیں، اور کئی دہائیاں ٹولز کے ماحول سے واپس آ چکی ہیں اور نئے لمبے کانٹیکسٹ کو معالجہ کرنے کی ضرورت ہے۔ سکیڈولر کے سامنے صرف FLOPs ہی نہیں بلکہ HBM کی صلاحیت، میموری بینڈ وڈتھ، KV کیش ریزیدنسی اور لیٹنسی بجٹ جیسے پابندیاں بھی ہیں۔

لگاتار بیچنگ سب سے پہلے ڈیکوڈ کی استعمال کی صلاحیت کا مسئلہ حل کرتی ہے۔ روایتی سٹیٹک بیچ ایک درخواست گروپ کو ایک ساتھ باندھ دیتی ہے، جب مختصر سیکوئنس ختم ہو جاتے ہیں، تو باقی لمبی درخواستیں اب بھی بیچ پر قبضہ کیے رکھتی ہیں۔

کنٹینیوس بیچنگ token ایٹریشن کے لیول پر ڈائنامک طور پر صارفین کو تبدیل کرتی ہے، ایک سیکوئنس مکمل ہونے پر اسے باہر نکال دیا جاتا ہے اور نئے درخواست فوراً داخل ہو جاتی ہے۔ بیچ جتنا موٹا ہوگا، ایک دور میں مدل کی حساب کتاب کو آگے بڑھانے والی سیکوئنسز کی تعداد اتنا ہی زیادہ ہوگی، جس سے مدل وزن کی رسائی اور میموری بینڈ وڈتھ کے اخراجات زیادہ آسانی سے تقسیم ہو جاتے ہیں۔

لیکن یہاں جلد ہی گرافکس میموری کی دیوار کو چھو لیں گے۔ بڑی تعداد میں لمبے ایجنٹ کے KV کیش کا HBM پر مستقل قبضہ ہوگا، ایک GPU کے ٹینسر کورز کو ابھی تک مکمل طور پر استعمال نہیں کیا گیا ہوگا، لیکن میموری میں مزید سیکوئنس کے لیے جگہ نہیں ہوگی۔ اس صورت میں مزید کمپوٹنگ پاور جمع کرنا بے معنی ہے، اصل طور پر کانکرنس کو محدود کرنے والی چیز کیش کی صلاحیت اور گرافکس میموری کا انتظام ہے۔

prefill اور decode کے درمیان ایک اور تنازع موجود ہے۔ فرض کریں کہ دہائیوں کی سیکوئنسز مستقل طور پر decode ہو رہی ہیں، اور ایک Agent 100K ٹوکن کے نئے کنٹیکس کے ساتھ واپس آ جاتا ہے جسے بڑا prefill کرنے کی ضرورت ہے۔ اگر یہ prefill ایک لمبے ایکزیکشن ونڈو کو قبضہ کر لے، تو پاس کے درخواستوں کا TPOT واضح طور پر بری طرح بگڑ جائے گا۔

چنکڈ پریفیل لمبے ان پٹ کو متعدد چھوٹے ٹکڑوں میں تقسیم کرتا ہے تاکہ پریفیل اور ڈیکوڈ کو متبادل طور پر انجام دیا جا سکے؛ اس سے مزید آگے بڑھ کر، پریفیل اور ڈیکوڈ کو الگ الگ جی پی یو پول میں تقسیم کیا جا سکتا ہے۔

اس کا سبب یہ ہے کہ دونوں مراحل خود بخود مختلف ہارڈویئر کی حدود پر منحصر ہیں: پریفِل زیادہ تر کمپیوٹیشنل تھروٹل پر منحصر ہے، جبکہ ڈیکوڈ HBM بینڈ ویتھ، KV کیش اور مستقل ٹوکن کی تاخیر پر انحصار کرتا ہے۔ انہیں الگ کرنے سے، آپ اپنی اپنی ضروریات کے مطابق وسائل کو ترتیب دے سکتے ہیں۔

یہ ظاہر کرتا ہے کہ ایجنٹ سروسنگ کا مرکزی حصہ صرف "ماڈل کرنل کو تیز تر لکھنا" سے زیادہ ہے۔ زیادہ کیپسیٹی میں اضافہ اس بات پر منحصر ہے کہ کام کب اور کہاں چلائے جائیں، کن حالتیں گرافکس میموری میں برقرار رکھی جائیں، اور موجودہ بیچ میں کون شامل کیا جائے۔

اس لیے، GPU استعمال اب یہاں کافی نہیں ہے۔ کیپسیٹی ٹیم کو GPU-seconds per task، TTFT (پہلا حرف کی تاخیر، جو صارف کو لگتا ہے کہ ڈیوائس اٹک رہی ہے)، TPOT (ایک حرف بنانے میں لگنے والا وقت، جو ماڈل کی بولنے کی رفتار تعین کرتا ہے)، queueing latency، prefix cache hit، KV cache occupancy اور SLO goodput (موثر ٹھروٹل، جو اصل میں پیسہ کمانے والی کمپوٹنگ پاور کو ظاہر کرتا ہے) کو ایک ساتھ دیکھنا ہوگا۔

یہ اشارے ایک ساتھ اس سوال کا جواب دیتے ہیں: صارف کے قابل قبول تاخیر کے تحت، ایک گھنٹے میں GPU کتنے موثر کاموں کو برقرار رکھ سکتا ہے۔

کوڈیک کی قابلیت یہاں ظاہر ہوتی ہے۔ اسٹیبل پریفکس دہرائے جانے والے پریفِل کو کم کرتا ہے، ڈیکوڈ کنٹینوئس بیچنگ کے لیے استعمال ہو سکتا ہے، KV کیش کو صفحات میں تقسیم اور نکالا جا سکتا ہے، اور ایجنٹ ٹولز کا انتظار کرتے وقت GPU کو چھوڑ سکتا ہے۔ اس کا ورک لوڈ بہت چھوٹا ہے، لیکن ان چھوٹوں کو سکیڈیولر دوبارہ ترتیب دے سکتا ہے۔

یہ مسئلہ قدرتی طور پر وسائل کی سطح تک منتقل ہو جاتا ہے: اگر ایک ہی سیٹ GPU زیادہ لمبے عرصے تک Agent کی خدمات فراہم کر سکتی ہے، تو ایک گھنٹے کے GPU کی حقیقی طور پر سپورٹ کرنے کی صلاحیت ایک گھنٹے سے زیادہ ہو سکتی ہے۔

فرض کریں کہ ایک Codex Agent کو مقررہ کام مکمل کرنے میں 60 منٹ لگتے ہیں، جس میں صرف کچھ وقت ہی مدل کے prefill اور decode کے لیے استعمال ہوتا ہے، باقی وقت کمپائل، ٹیسٹ، فائلز پڑھنا/لکھنا یا ٹولز کا انتظار کرنے میں صرف ہوتا ہے۔ یہ تناسب کام کے مطابق تبدیل ہو سکتا ہے، لیکن ساخت اہم ہے: Agent کا wall-clock time اور GPU compute time ایک سے ایک نہیں ہوتا۔

اگر سسٹم میں بہت سارے ایجنٹز ہوں، تو وہ ایک ہی سیکنڈ میں ایک ساتھ GPU کی ضرورت نہیں رکھیں گے۔ کوئی prefill کر رہا ہے، کوئی decode کر رہا ہے، کوئی ٹیسٹ چلا رہا ہے، اور کوئی فائل سسٹم کا انتظار کر رہا ہے۔ جب تک scheduler ان مراحل کو ایک دوسرے کے ساتھ ملا سکے، محدود GPU سے GPU کی تعداد سے کہیں زیادہ فعال ورکفلوز کو برقرار رکھا جا سکتا ہے۔

اس تعلق کو اس طرح سمجھا جا سکتا ہے: Agent-hours، GPU-hours، ماڈل انفرنس کا ڈیوٹی سائیکل، اور شیڈولنگ کی کارکردگی پر منحصر ہے۔ جتنا زیادہ ٹولز کا انجام دینے کا وقت ہوگا، batch زیادہ موٹا ہوگا، اور کیش میں ہٹ میں زیادہ کامیابی ہوگی، اتنا ہی زیادہ ایک گھنٹے کے GPU کو Agent کے وول-کلاک کام کو لازمی طور پر سہارا دینے کا موقع ملے گا۔

یہ نئے GPU کے معنی کو براہ راست تبدیل کر دے گا۔ Codex میں GPU کا ایک گروپ شامل کرنا صرف ایک ہی کام کو تیز کرنے تک محدود نہیں ہے، بلکہ نظام کو одноں ساتھ زیادہ Agent کو برقرار رکھنے کی اجازت بھی دے سکتا ہے۔ ایک انجینئر متعدد کاموں کو одноں ساتھ شروع کر سکتا ہے — ایک بیک اینڈ میں تبدیلی، ایک ٹیسٹ میں تکمیل، اور ایک دوسرے ریپوزٹری کو سنبھالنا — جب تک ان کاموں کے درمیان مضبوط وابستگی نہ ہو، مشین کا کام کا وقت одноں ساتھ بڑھ سکتا ہے۔

سورا کی کیپیسٹی کریو زیادہ مستقیم ہے۔ ایک ویڈیو کا لمبا وال-کلاک وقت خود ہی GPU پر ڈیفیوژن کو آگے بڑھاتا ہے، اور ایک منفرد کام اور GPU استعمال کے درمیان تعلق زیادہ قریب ہوتا ہے۔ نئے GPU شامل کرنے سے ویڈیو ٹھروپٹ بڑھایا جا سکتا ہے، لیکن ایک گھنٹہ کے GPU اور ویڈیو کے کمپوٹیشن کے وقت کے درمیان تعلق کو زیادہ فرق نہیں دیا جا سکتا۔

کوڈیکس کا ایک سافٹ ویئر ٹاسک GPU، CPU، کنٹینرز، فائل سسٹم اور ٹول ایونٹس کے درمیان منتقل ہوتا ہے۔ GPU ماڈل انفرنس کے لیے ذمہ دار ہے، جبکہ دیگر سسٹمز اجراء کے لیے ذمہ دار ہیں، اور کئی ایجینٹس scheduler کے ذریعے انفرنس کی صلاحیت کو متبادل طور پر شیئر کرتے ہیں۔ اس طرح GPU صرف ایک جنریٹنگ ڈیوائس نہیں رہا، بلکہ پورے ایجینٹ سسٹم میں ایک نایاب "سوچنے کا وسائل" بن گیا۔

اسی لیے کوڈیکس جبکہ اتنے ہی کمپیوٹ کو جذب کر سکتا ہے، نئے کمپیوٹ کو حاصل کرنا زیادہ آسان ہے۔ اوپن اے آئی کو صرف ایک بار کی انفرینس لاگت نہیں، بلکہ نئی صلاحیت کو تیزی سے زیادہ متوازی کام میں تبدیل کیا جا سکتا ہے یا نہیں، دیکھنا ہوگا۔

جب ایک سیریز GPU زیادہ لمبے عرصے تک Agent کو سپورٹ کر سکتی ہے، اور ان Agent کو نئے سافٹ ویئر کے کامز مسلسل مل رہے ہوں، تو وسائل آسانی سے اس سمت کی طرف بہہ جاتے ہیں۔

الٹمن کے اس جملے کا ٹیکنیکل مطلب اب واضح ہو گیا۔ سورا کی بڑی حسابی طاقت ایک منفرد پیداواری راستے میں بند ہے، جبکہ کوڈیک کی حسابی طاقت کئی قابل ترتیب مراحل میں تقسیم ہے۔ دونوں کی قیمت ایک جیسی ہے، لیکن وسائل کی واپسی کا منحنی مختلف ہے۔

سورا اور کوڈیک کے وسائل کے منتقل ہونے کی وضاحت، AI پروڈکٹس میں ایک ایسا نیا متغیر شروع ہو رہا ہے جو براہ راست توسیع کی رفتار کو متاثر کرے گا: workload architecture۔

اکھی جانے والی مہنگی GPU کا استعمال کرتے ہوئے، ایک قسم کا کام بہت زیادہ کمپوٹیشنل طاقت کو ایک منفرد جنریشن پاتھ میں قفل کر دیتا ہے، جبکہ دوسری قسم کا کام کیش، بیچنگ، ٹول ایکزیکشن اور شیڈولنگ کے ذریعے ایک ہی انفرینس کی صلاحیت کو زیادہ ورک فلو میں تبدیل کر سکتا ہے، اس لیے ان کی وسائل کی منحنی قدرتی طور پر الگ ہو جائے گی۔

اس لیے مستقبل میں کچھ ایسے بنیادی مسائل جو صرف ٹیکنیکل لگتے ہیں، پروڈکٹ مسائل کے قریب آتے جائیں گے۔ KV کیش کہاں رکھی جائے، پریفِل کو کیسے تقسیم کیا جائے، ڈیکوڈ بیچ کتنی موٹی ہو سکتی ہے، اور انتظار کرنے والے ایجینٹ کو کیش کو نکالنا چاہیے یا نہیں — ان انتخابات کے نتیجے میں ایک ساتھ کتنے ٹاسکس GPU کو برقرار رکھے جا سکتے ہیں، یہ فیصلہ ہوگا۔

سورا اور کوڈیکس کا فرق صرف ویڈیو اور کوڈ کا فرق نہیں ہے۔

وہ ایک ہی گھنٹے کے GPU کے لیے مقابلہ کر رہے ہیں، جو کتنے کام کو برداشت کر سکتا ہے۔