ہم نے چھ ماہ میں فوری ردعمل والے وائس AI کے لیے ریئل ٹائم سسٹم کیسے بنایا

وائس AI کے لیے یہ جاننا کہ کب بولنا ہے, جتنا سننے میں آسان لگتا ہے اتنا ہے نہیں. انسانی اسپیکرز ایک سیکنڈ کے معمولی حصے میں بآسانی ایک دوسرے کو بولنے کا موقع دے دیتے ہیں, مگر پہلے کے وائس AI سسٹمز اس تال کے ساتھ برقرار نہیں رہ سکتے تھے. ان کا ٹرن بیسڈ آرکیٹیکچر چھوٹے ماڈلز پر منحصر تھا جنہیں ٹرن ڈیٹیکٹرز کہا جاتا ہے, اور ان کے سامنے ایک مشکل کام تھا: بہت جلد اندازہ لگائیں تو صارف کی بات کٹ جاتی ہے؛ بہت دیر سے اندازہ لگائیں تو جواب سست محسوس ہوتا ہے. صرف ڈیٹیکٹر کے فیصلہ کرنے کے بعد ہی بہت بڑا LLM کام شروع کر سکتا تھا.

ہمارا تھرڈ جنریشن کا وائس سسٹم GPT‑Live⁠ آڈیو پاتھ سے ٹرن ڈیٹیکٹر کو ہٹا دیتا ہے. اس کا وائس ماڈل فل ڈوپلیکس ہے, یعنی یہ ایک ہی وقت میں سن اور بول سکتا ہے. اس سے الگ ڈیٹیکٹر کی ضرورت ختم ہو جاتی ہے اور گفتگو زیادہ فوری اور قدرتی محسوس ہوتی ہے. جب گہری ریزننگ یا ٹول کے استعمال کی ضرورت ہو تو GPT‑Live گفتگو کے بہاؤ میں خلل ڈالے بغیر GPT‑5.5 جیسے ہمارے جدید ترین ماڈلز سے بھی رجوع کر سکتا ہے. یہ صلاحیتیں مل کر GPT‑Live کو گفتگو میں فوری ردعمل اور انٹیلیجنس کا ایک بے مثال امتزاج فراہم کرتی ہیں.

اس تجربے کو بڑے پیمانے پر فراہم کرنے کے لیے کم لیٹنسی کے لیے بہتر بنائے گئے نئے سسٹم آرکیٹیکچر کی ضرورت تھی. عام ریکویسٹ-رسپانس انفرنس کے برعکس, ہمارا سسٹم آنے والی آڈیو کو وائس ماڈل میں اسٹریم کرتا ہے اور آؤٹ باؤنڈ اسپیچ کو واپس صارف تک پہنچاتا ہے, جبکہ ڈیلیگیشن کو ایک الگ غیر ہم وقت پاتھ پر ہینڈل کرتا ہے. گزشتہ چھ ماہ کے دوران ہم نے ماڈل انفرنس, کانٹیکسٹ مینجمنٹ اور میڈیا ٹرانسپورٹ کو ازسرنو ترتیب دیا تاکہ آخر سے آخر تک اسپیچ کا بہاؤ ہموار برقرار رہے.

یہ آرکیٹیکچر بنیادی وائس پاتھ اور ایپلیکیشن لاجک کے درمیان ایک واضح باؤنڈری بھی قائم کرتا ہے. اس سے ردِعمل کی رفتار کو متاثر کیے بغیر ایپلیکیشن کے رویے کو حسبِ ضرورت ڈھالنا آسان ہو جاتا ہے. یہ بنیاد ChatGPT Voice میں بڑھتی ہوئی صلاحیتوں کو تقویت دیتی ہے, جن میں ChatGPT ڈیسک ٹاپ ایپ میں حال ہی میں شروع کی گئی کمپیوٹر کو کنٹرول کرنے اور اپنے ایجنٹس کو ہم آہنگ کرنے کی صلاحیت بھی شامل ہے.

اس تحریر میں ہم بتائیں گے کہ پہلے کے باری پر مبنی سسٹمز ہماری ضروریات کیوں پوری نہ کر سکے اور ہم نے ہر سطح پر فوری ردعمل کے لیے نیا سسٹم کیسے بنایا. ہم اسٹیٹ فُل انفیرنس, متحرک کانٹیکسٹ مینجمنٹ, غیر ہم وقت ڈیلیگیشن اور پروٹوکول سطح کی آپٹیمائزیشن کا احاطہ کریں گے, جو مل کر GPT‑Live کو واقعی لائیو محسوس کراتے ہیں.

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

اسپیچ-ٹو-اسپیچ ماڈلز نے آڈیو کو براہِ راست پروسیس کرکے اس طریقے کو بہتر کیا. ماڈل کو فطری طور پر گفتگو سمجھنے اور پیدا کرنے کی ٹریننگ دینے سے وہ ٹرانسکرپشن میں کھو جانے والی تفصیلات محفوظ رکھ سکا اور تیزی سے جواب دینے لگا. مگر انفرنس کب شروع ہو سکتا ہے, یہ طے کرنے کے لیے سسٹم اب بھی باری شناخت کنندہ پر منحصر تھا. ماڈل انٹریکشن کا زیادہ حصہ سنبھالتا تھا, مگر انٹریکشن بدستور باری پر مبنی تھا.

GPT‑Live وائس ماڈل کو گفتگو کا اختیار دیتا ہے: آڈیو ماڈل میں داخل ہوتی اور باہر آتی ہے, جبکہ گہری ریزننگ اور ٹولز کا استعمال غیر ہم وقت طور پر ہوتا ہے. سسٹم کا بنیادی کام میڈیا لوپ کو بلا تعطل برقرار رکھنا ہے. جدید ترین ماڈلز کو استعمال کرنے اور گفتگو کو مستقل محفوظ رکھنے جیسے دوسرے کام لائیو پاتھ سے باہر انجام پاتے ہیں.

اس میڈیا لوپ کو بلا تعطل برقرار رکھنا ہمیشہ آسان نہیں ہوتا. ٹرانسپورٹ, پروسیسنگ یا انفرنس میں ہونے والی کسی بھی تاخیر کے نتیجے میں سنائی دینے والا وقفہ یا آڈیو میں خرابی پیدا ہو سکتی ہے. پہلے استعمال ہونے والا ٹرن بیسڈ سسٹم اس بات میں کچھ لچک برداشت کر سکتا تھا کہ آڈیو بلاک کس وقت پہنچے, لیکن ایک لائیو میڈیا سسٹم میں ہر آڈیو فریم کو مقررہ وقت پر پہنچانا ضروری ہوتا ہے.

ChatGPT Voice اور Realtime API پر پہلے کیے گئے کام نے ہمیں ایک مضبوط بنیاد فراہم کی. ہم پہلے ہی اپنے وائس انفراسٹرکچر کو ازسرِنو تیار کر چکے تھے⁠ تاکہ آڈیو اور ویڈیو کو کم اور زیادہ قابلِ پیش گوئی لیٹنسی کے ساتھ براہِ راست ہمارے سسٹمز میں بھیجا اور وہاں سے وصول کیا جا سکے. GPT‑Live نے اس ڈیزائن کو مزید آگے بڑھایا, جہاں میڈیا کو مسلسل گفتگو کے لیے تیار کیے گئے ایک نئے اسٹیٹ فل انفرنس سسٹم کے ذریعے براہِ راست ماڈل تک اسٹریم کیا جاتا ہے.

تاہم, اسٹریمنگ انفرنس اکیلا ہی مکمل حل نہیں تھا. اسے پروڈکشن میں مؤثر طریقے سے چلانے کے لیے ہمیں یہ بھی یقینی بنانا پڑا کہ کلائنٹ سے انفرنس اسٹیک تک آڈیو قابلِ اعتماد طریقے سے پہنچے, اور اسٹیٹ فل ہونے سے پیدا ہونے والے چیلنجز سے بھی نمٹا جائے.

ہمارا ایک ابتدائی فیصلہ یہ تھا کہ میڈیا کے بہاؤ کو ایپلیکیشن اور بزنس لاجک سے واضح طور پر الگ رکھا جائے. آڈیو کلائنٹ اور وائس ماڈل کے درمیان ایک مخصوص تیز پاتھ سے گزرتی ہے. ڈیلیگیشن, ٹولز کا استعمال اور ایپلیکیشن کے دیگر کام ایک غیر ہم وقت RPC باؤنڈری کے پیچھے ہوتے ہیں. کسی سست ٹول کال یا بیک اینڈ سروس سے اس کے اپنے نتیجے میں تاخیر ہو سکتی ہے, مگر وہ میڈیا کا بہاؤ نہیں روک سکتی.

یہ علیحدگی سسٹم کو کسٹمائزیشن کے لیے ایک واضح باؤنڈری بھی فراہم کرتی ہے. ایپلیکیشنز آڈیو کو رواں رکھنے والے میڈیا فرنٹ اینڈ کو متاثر کیے بغیر اپنے ٹولز, پالیسیاں اور بیک اینڈ رویہ بدل سکتی ہیں. لائیو پاتھ مختصر, قابلِ پیش گوئی اور صرف اس کام پر مرکوز رہتا ہے جو ریئل ٹائم میں ہونا ضروری ہے.

ہم نے پہلے کے Python asyncio نفاذ کی جگہ میڈیا فرنٹ اینڈ اور انفرنس منطق Go میں لکھی. اس سے فریموں کی ترسیل کی روانی نمایاں طور پر بہتر ہوئی؛ نئے سسٹم کا p95 پچھلے سسٹم کے p50 کے برابر تھا.

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

پورے سسٹم میں بفرنگ اور رکاوٹ کم کرکے ہم ایک سیکنڈ سے کم کا وہ فوری ردعمل فراہم کر سکتے ہیں جس کی لوگ گفتگو سے توقع کرتے ہیں.

اسٹیٹ فل انفرنس کے ساتھ اپنی نوعیت کے عملی چیلنجز بھی وابستہ ہوتے ہیں. ایک وائس سیشن طویل عرصے تک فعال رہ سکتا ہے, لیکن اس کا سیاق و سباق مسلسل بڑھتا رہتا ہے, جبکہ طلب کے مطابق ماڈل انسٹینسز شروع اور بند ہوتے رہتے ہیں.

ان مسائل سے نمٹنے کے لیے ہم نے ماڈل انسٹینسز کے درمیان ایک ہموار ہینڈ آف میکانزم تیار کیا. جب منتقلی کی ضرورت پیش آتی ہے تو ہم موجودہ انسٹینس کے ساتھ ایک متبادل ماڈل انسٹینس کو پہلے سے وارم کر سکتے ہیں, اسے موجودہ سیشن کے سیاق و سباق سے پری فل کر سکتے ہیں, دونوں انسٹینسز پر متوازی طور پر انفرنس چلا سکتے ہیں, اور جب نیا انسٹینس مکمل طور پر تیار ہو جائے تو اسی پر منتقل ہو سکتے ہیں.

**یہی بنیادی میکانزم ڈائنامک کانٹیکسٹ کمپیکشن کو بھی سپورٹ کرتا ہے. جیسے جیسے گفتگو آگے بڑھتی ہے, اس کا جمع شدہ سیاق و سباق بالآخر ماڈل کی کانٹیکسٹ حد سے تجاوز کر سکتا ہے. کمپیکشن کانٹیکسٹ کے حجم کو کم کر کے اسے اس حد کے اندر لا سکتی ہے, لیکن اس عمل میں وقت لگتا ہے. مزید یہ کہ چونکہ یہ پہلے سے موجود کانٹیکسٹ میں تبدیلی کرتی ہے, اس لیے ماڈل کا کی-ویلیو (KV) کیش بھی غیر مؤثر ہو جاتا ہے, جو پہلے سے پراسیس کیے گئے ٹوکنز کی اٹینشن کیز اور ویلیوز کو محفوظ رکھتا ہے. اس اسٹیٹ کو دوبارہ تیار کرنے کے لیے ایک نئی پری فل درکار ہوتی ہے, جس سے مزید تاخیر پیدا ہوتی ہے.

اس کے بجائے, ہم کمپیکشن کو بھی ایک منیجڈ ٹرانزیشن کے طور پر انجام دیتے ہیں. جب تک اصل ماڈل انسٹینس گفتگو جاری رکھتا ہے, سسٹم کانٹیکسٹ کو کمپیکٹ کرتا ہے اور نئے کانٹیکسٹ کے ساتھ ایک متبادل ماڈل انسٹینس تیار کرتا ہے. جیسے ہی وہ انسٹینس مکمل طور پر تیار ہو جاتا ہے, ہم میڈیا میں کسی بھی تعطل کے بغیر اسی پر منتقل ہو سکتے ہیں. اس طرح سسٹم طویل دورانیے کی کالز کو سپورٹ کر سکتا ہے اور ضرورت پڑنے پر کانٹیکسٹ کمپیکشن انجام دیتا رہتا ہے.

زیادہ وسائل طلب کام لائیو پاتھ سے الگ رہتے ہیں, اس لیے ہینڈ آف کے دوران بھی گفتگو کی روانی میں کوئی تعطل نہیں آتا.

موجودہ جدید ترین ماڈلز کو انووک کرنے کی GPT‑Live کی صلاحیت اسے بہت زیادہ طاقت فراہم کرتی ہے اور مؤثر طور پر "بولنے" کو زیادہ گہری "سوچ" سے الگ کر دیتی ہے. لیکن اس دو ماڈلز پر مشتمل آرکیٹیکچر کو ایک ہی سسٹم کی طرح محسوس کرانے کے لیے ہمیں انجینئرنگ کے دو باہم متعلق مسائل حل کرنا پڑے.

پہلا مسئلہ یہ تھا کہ نتائج اتنی تیزی سے واپس آئیں کہ جاری گفتگو میں مفید ثابت ہوں, اس لیے ہمیں روٹنگ, پرومپٹ پروسیسنگ, انفرنس اور ٹول کالز سمیت پورے ڈیلیگیشن پاتھ میں لیٹنسی کو کم سے کم کرنا پڑا. اسی وقت, پروڈکٹ کے دیگر سسٹمز کو اب بھی الگ الگ میسجز درکار ہوتے ہیں, اس لیے ہمیں جاری گفتگو کو ایسی شکل میں پیش کرنا پڑا جسے وہ سمجھ سکیں.

جب کوئی ڈیلیگیشن بھیجی جاتی ہے تو ہماری ترجیح یہ ہوتی ہے کہ جدید ترین ماڈل گفتگو کے لیے مفید نتیجہ کم سے کم وقت میں فراہم کرے. وائس ماڈل مختصر وقت کے لیے گفتگو کا تسلسل برقرار رکھ سکتا ہے, جبکہ جدید ترین ماڈل استدلال کرتا ہے یا ٹولز استعمال کرتا ہے, لیکن وہ غیر معمولی طور پر سست جواب کو چھپا نہیں سکتا. اسی لیے ہم نے پورے ڈیلیگیشن لوپ—روٹنگ, پرومپٹ پروسیسنگ, انفرنس اور ٹول کالز—کو ردِعمل کی رفتار کے بجٹ کا حصہ سمجھا.

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

پھر ہم اس انفرنس سیشن کو پوری وائس کنورسیشنز کے دوران دستیاب رکھتے ہیں اور مسلسل درخواستوں کے لیے مستحکم سیشن وابستگی استعمال کرتے ہیں. پرومپٹ کیشنگ کے ساتھ یہ طریقے تاخیر بہتر کرتے ہیں, جبکہ کارکن کی خرابی سے بحالی آسان رہتی ہے.

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

اگرچہ وائس ماڈل مسلسل صوتی اسٹریمز پر کام کرتا ہے, مگر اس کے گرد بہت سے سسٹمز اب بھی صارف اور اسسٹنٹ کی باریوں پر چلتے ہیں, جن میں ChatGPT کا گفتگوئی UI اور ہماری اینالیٹکس اور سیفٹی انفراسٹرکچر کے کچھ حصے شامل ہیں. اس لیے ایپلیکیشن سرور ایک دوسرے سے اوورلیپ ہونے والی اور کبھی کبھار مبہم گفتگو کو الگ الگ میسجز میں تقسیم کرتا ہے.

آڈیو آتے ہی سرور جزوی ٹرانسکرپٹس اور وقت کے اشاروں سے اندازہ لگاتا ہے کہ اس وقت کون بول رہا ہے اور میسجز کی قطار بناتا ہے. تازہ ترین میسج عارضی رہتا ہے؛ مزید گفتگو آنے پر اس کا ٹیکسٹ, وقت اور اسپیکر کی شناخت سب تبدیل ہو سکتے ہیں. جب کوئی اسپیکر اتنی دیر تک گفتگو کا اختیار برقرار رکھتا ہے کہ اس کی شناخت قابلِ اعتماد ہو جائے, تو سرور متعلقہ میسج کو حتمی شکل دے دیتا ہے.

اسپیکرز کا بیک وقت بولنا اسے مزید پیچیدہ بنا دیتا ہے. صارف کے بولتے وقت اسسٹنٹ کی مختصر تائید, (مثلاً ”ہوں ہوں“ یا ”ٹھیک ہے“), ضروری نہیں کہ الگ میسج بنے. تاہم, اسسٹنٹ کی بامعنی مداخلت کو اکثر الگ میسج بننا چاہیے. اسی طرح, صارف کے درمیان میں بولنے کے باوجود ہم دکھائے جانے والے اسسٹنٹ کے جوابات میں تسلسل اور ہم آہنگی کو ترجیح دیتے ہیں.

ہر سیگمنٹیشن پالیسی تازگی اور یقین کے درمیان ایک توازن قائم کرتی ہے. بہت جلد حتمی فیصلہ کرنے سے بکھری ہوئی ہسٹری اور غیر مستحکم ترتیب پیدا ہوتی ہے, جبکہ بہت زیادہ انتظار کرنے سے ٹرانسکرپٹس اور ان پر منحصر خصوصیات میں تاخیر ہوتی ہے. اس لیے سسٹم گفتگو کے دو باہم متعلقہ ویوز برقرار رکھتا ہے: موجودہ حالت کا اسپیکولیٹو ویو اور جو کچھ کہا گیا اس کا ایک مستند ریکارڈ. ایپلیکیشن میں گفتگو کا ویو اپ ڈیٹس کو سنبھال سکتا ہے, اس لیے وہ اسپیکولیٹو ویو استعمال کرتا ہے. لیکن اینالیٹکس پائپ لائن میں لاگنگ کے لیے حتمی ٹرانسکرپٹ درکار ہوتا ہے.

اس طرح براہِ راست وائس راستے پر باری باری بولنے کی پابندی لگائے بغیر باقی ChatGPT کو تبادلے کا مستحکم منظر ملتا ہے.

فوری ردعمل صارف کے بٹن دباتے ہی شروع ہو جاتا ہے. GPT‑Live میں گفتگو شروع ہونے سے پہلے سسٹم کو میڈیا پاتھ قائم کرکے ماڈل کو آڈیو دینا شروع کرنا ہوتا ہے. اس سے آغاز کی ترتیب کا ہر حصہ اہم راستے میں آ جاتا ہے.

جیسا کہ اوپر بتایا گیا, WebRTC ریئل ٹائم کے لیے ایک مضبوط بنیاد فراہم کرتا ہے, مگر ایک عام WebRTC سیشن شروع کرنے کے لیے حیرت انگیز تعداد میں پروٹوکول ہینڈ شیکس اور نیٹ ورک راؤنڈ ٹرپس درکار ہوتے ہیں. WebRTC اس دور سے پہلے کا پروٹوکول ہے جب راؤنڈ ٹرپس کو کم سے کم کرنے پر توجہ دی جانے لگی تھی, جس نے QUIC جیسے بعد کے پروٹوکولز کو تشکیل دیا. نتیجتاً, اس کے بنیادی پروٹوکولز کو ایک ساتھ استعمال کرنے پر کبھی کبھی ایک ہی کام دہرانا پڑتا ہے. مثال کے طور پر, ہر پروٹوکول میں اپنا اینٹی-DoS میکانزم شامل تھا, حالانکہ مکمل WebRTC اسٹیک کے تناظر میں اس کی ضرورت نہیں تھی.

ہم نے مجموعے کا تجزیہ کرکے WebRTC Abridged Roundtrip Protocol, یعنی (WARP⁠(نئی ونڈو میں کھلتا ہے)), تیار کیا, جو میڈیا اور ڈیٹا کے آغاز کو چھ نیٹ ورک آمدورفت سے گھٹا کر صرف ایک کر دیتا ہے. WARP پچھلی مطابقت برقرار رکھنے والی پروٹوکول بہتریوں سے یہ ممکن بناتا ہے: ICE پر DTLS ہینڈ شیک شامل کرنا (SPED⁠(نئی ونڈو میں کھلتا ہے)), تیز DTLS 1.3⁠(نئی ونڈو میں کھلتا ہے) ہینڈ شیک استعمال کرنا, SCTP ہینڈ شیک کی پیشگی گفت و شنید کرنا (SNAP⁠(نئی ونڈو میں کھلتا ہے)), اور DCEP⁠(نئی ونڈو میں کھلتا ہے) کے بجائے ڈیٹا چینلز کی پیشگی گفت و شنید کرنا.

ہم نے WebRTC کمیونٹی کے شراکت داروں کے ساتھ مل کر WARP کو اوپن اسپیسفیکیشنز کے ایک مجموعے کے طور پر ڈیزائن کیا, تاکہ وسیع تر ایکوسسٹم بھی اس کام سے فائدہ اٹھا سکے. ہم IETF کے TSVWG ورکنگ گروپ کے ذریعے ان تجاویز کو آگے بڑھا رہے ہیں, اور WARP کی معاونت پہلے ہی libwebrtc اور Pion دونوں میں شامل کی جا چکی ہے, جبکہ دیگر WebRTC امپلیمنٹیشنز میں بھی اس کے لیے کام جاری ہے.

میڈیا ہینڈ شیک کو بہتر بنانے کے بعد ایک تاخیر نمایاں رہی: سگنلنگ ایکسچینج, جس کے ذریعے WebRTC کے کنیکٹ ہونے سے پہلے SDP پیرامیٹرز کا تبادلہ کیا جاتا ہے. اس تبادلے کو کریٹیکل پاتھ سے ہٹانے کے لیے ہم نے وہ طریقہ بنایا جسے ہم Instant Connect کہتے ہیں. یہ سرور کی گنجائش محفوظ کیے بغیر اور موجودہ WebRTC نفاذوں میں تبدیلی کیے بغیر ان پیرامیٹرز کو پیشگی نیگوشی ایٹ کرتا ہے.

Instant Connect معیاری سگنلنگ فلو کے ساتھ چلتا ہے. اگر پیشگی نیگوشی ایٹ کیے گئے پیرامیٹرز درست ہوں تو پہلا میڈیا پیکٹ پہنچتے ہی سرور سیشن قائم کر سکتا ہے. اگر وہ پرانے یا غلط ہوں تو سگنلنگ فلو پہلے ہی جاری ہوتا ہے, اس لیے کلائنٹ اضافی تاخیر کے بغیر متبادل طریقہ اپنا سکتا ہے.

Instant Connect اور WARP مل کر صارف کے ارادے سے لائیو میڈیا فلو تک کا وقت ڈرامائی طور پر کم کر دیتے ہیں. SDP ایکسچینج کو کریٹیکل پاتھ سے ہٹانے اور WARP کے ذریعے ٹرانسپورٹ ہینڈ شیک کو مختصر کرنے کے بعد, کلائنٹ اب صرف ایک UDP پیکٹ سے سیشن شروع کر سکتا ہے. سرور فوراً جواب دے سکتا ہے, جس سے باقی سسٹم وہ کام شروع کر دیتا ہے جس کی صارف کو واقعی ضرورت ہے: سننا اور جواب دینا.

کوئی سسٹم کاغذ پر تیز دکھائی دے سکتا ہے, مگر حقیقی وائس ٹریفک کے دوران پھر بھی سست پڑ سکتا ہے. GPT‑Live کو صارفین سے گفتگو کی اجازت دینے سے پہلے, ہم نے ایک خاموش ٹیسٹ کی جس میں پروڈکشن کی ChatGPT Voice نشستوں کا ایک چھوٹا اور بتدریج بڑھتا حصہ موجودہ ایڈوانسڈ وائس موڈ اور اپنے نئے سسٹم, دونوں کی طرف بھیجا. ایڈوانسڈ وائس موڈ معمول کے مطابق صارفین کو خدمات دیتا رہا, جبکہ شیڈو پاتھ نے صرف پڑھنے کے موڈ میں انفرنس چلایا. اس طرح صارفین کو سنائی دینے والی چیز بدلے بغیر سسٹم کو حقیقی کلائنٹس, نیٹ ورکس, سیشنز کے مختلف دورانیے اور جغرافیائی تقسیم پر آزمایا گیا.

ابتدائی اسباق میں سے ایک یہ تھا کہ گنجائش کو صرف GPU تھروپٹ تک مباؤنڈریود نہیں سمجھا جا سکتا. وائس سیشنز کھلی رہتی ہیں اور مسلسل فریم بھیجتی ہیں, اس لیے CPU کی طرف موجود اسٹریم ہینڈلرز, قطاروں اور نیٹ ورک پاتھز کو انفرنس کے ساتھ پیمانہ پذیر ہونا چاہیے. حقیقی بوجھ میں ایک معاون جزو ہماری لوڈ ٹیسٹ پیش گوئی سے پہلے اپنی باؤنڈری کو پہنچ گیا, جس سے انفرنس درخواستیں جمع ہونے لگیں اور تاخیر بڑھتی گئی. ہم نے گنجائش کا سوال ”ایک GPU کتنی درخواستیں سنبھال سکتا ہے؟“سے بدل کر ”ہر فریم کو مقررہ وقت پر رکھتے ہوئے سسٹم بیک وقت کتنی نشستیں برقرار رکھ سکتا ہے؟“کر دیا.

اس ٹیسٹ نے جغرافیائی محلِ وقوع کو بھی اولین ترجیح کا معاملہ بنا دیا. کسی سیشن کو دور موجود گنجائش کی طرف بھیجنے سے آغاز اور اسٹریمنگ کے دوران کئی مقامات پر تاخیر بڑھ سکتی ہے. ہم نے ماڈل رول آؤٹس کو علاقائی گنجائش اور ٹریفک اسٹیئرنگ کنفیگریشن کے ساتھ جانچنا شروع کیا, پھر ماخذ کے جغرافیے کے لحاظ سے تاخیر کا تجزیہ کیا. انفرنس کو صارفین کے قریب لانے سے مدد ملی, مگر اس سے ایک وسیع تر سبق بھی پختہ ہوا: ابتدا سے انتہا تک فوری ردعمل راستے کی ہر سروس پر منحصر ہے, صرف ماڈل سرور پر نہیں.

دیگر مسائل صرف حقیقی سیشن لائف سائیکلز کے دوران سامنے آئے. طویل دورانیے کے سیشنز نے میموری اور پرسسٹنس پر دباؤ کو ظاہر کیا. دوبارہ کنیکٹ ہونے کے عمل نے کمپیکشن اور اسٹیٹ ریسٹوریشن کو آزمایا, جبکہ عام کلائنٹ ڈس کنیکشنز نے شٹ ڈاؤن ہینڈ شیک میں ریس کنڈیشنز کو بے نقاب کیا. یہ مسائل مختصر لوڈ ٹیسٹس میں شاذ و نادر ہی سامنے آتے تھے, کیونکہ ان کا انحصار وقت, جمع شدہ اسٹیٹ, اور مختلف سروسز کے درمیان ہونے والے تعامل پر تھا.

آخر میں, پروڈکشن کی جانچ نے ہمیں آبزرویبلٹی اور رول آؤٹ کنٹرولز بہتر بنانے پر مجبور کیا. ہمیں ایسے میٹرکس ملے جو تاخیر کے مختلف اسباب کو خلط ملط کرتے تھے, ایسے ڈیش بورڈ ملے جن کے مجموعی اعداد انفرادی خراب انجن چھپا دیتے تھے, اور آزمودہ و تعینات سسٹمز کی ترتیبات میں فرق ملا. اس کے جواب میں ہم نے زیادہ باریک ٹیلی میٹری, معلوم درست ترتیبات کے مقابل توثیق, مرحلہ وار رول آؤٹس, اور انفرادی راستوں کو فوری الگ یا غیر فعال کرنے کی گنجائش شامل کی. سائلنٹ ٹیسٹ ایک ابتدائی لانچ ریہرسل بن گیا, جو صرف یہ جانچنے کے لیے نہیں تھی کہ سسٹم کتنا ٹریفک سنبھال سکتا ہے, بلکہ یہ بھی کہ ہم خرابی کا کتنی تیزی سے پتہ لگا سکتے ہیں, اسے مباؤنڈریود کر سکتے ہیں, اور اس سے بحال ہو سکتے ہیں.

GPT‑Live کو ChatGPT کے میٹرکس تک پہنچانے کے لیے ایک بنیادی اصول پر بنایا گیا بالکل نیا سسٹم درکار تھا: آواز کا بہاؤ بلا تعطل جاری رہنا چاہیے. اسٹریمنگ انفرنس فل ڈوپلیکس ماڈل کو مسلسل آڈیو فراہم کرتا ہے. مخصوص میڈیا پاتھ فریموں کی قابل اعتماد ترسیل یقینی بناتا ہے. غیر ہم وقت ڈیلیگیشن گہری سوچ کو متوازی طور پر چلنے دیتی ہے. آپٹمائزڈ ٹرانسپورٹ صارف تک پورے تجربے کو فوری ردعمل کا حامل رکھتا ہے.

GPT‑Live کے پسِ پشت فنِ تعمیر پہلے ہی ریئل ٹائم تعامل کے ایک وسیع تر پلیٹ فارم میں ڈھل رہا ہے. یہ ChatGPT Voice کو تقویت دیتا ہے جب وہ گفتگو سے آگے بڑھ کر ایجنٹک کوآرڈینیشن کی جانب وسعت اختیار کر رہا ہے, اور آئندہ GPT‑Live API کی بنیاد بھی یہی ہوگا. وقت کے ساتھ, یہ وائس تجربات کو مزید آلات, ایپس اور مختلف موڈالیٹیز تک پھیلانے کے قابل بنائے گا, اس فوری پن پر سمجھوتہ کیے بغیر جو وائس کنورسیشنز کو لائیو محسوس کراتا ہے.

اگر آپ ایسے ہی انجینئرنگ مسائل حل کرنا چاہتے ہیں تو ہمارے ساتھ کام کریں⁠.