Responses API میں WebSockets کے ذریعے ایجنٹ پر مبنی عمل کو تیز بنانا

جب آپ Codex سے کسی بگ کو ٹھیک کرنے کے لیے کہتے ہیں، تو یہ متعلقہ فائلوں کے لیے آپ کے کوڈ بیس کو اسکین کرتا ہے، سیاق و سباق تیار کرنے کے لیے انہیں پڑھتا ہے، ترامیم کرتا ہے، اور یہ جانچنے کے لیے ٹیسٹ چلاتا ہے کہ اصلاح کارگر رہی. پس پردہ، اس کا مطلب یہ ہے کہ Responses API کو آگے پیچھے بھیجی جانے والی درجنوں ریکویسٹس ہوتی ہیں: ماڈل کی اگلی کارروائی کا تعین کرنا، اپنے کمپیوٹر پر کسی ٹول کو چلانا، ٹول کا آؤٹ پٹ واپس API کو بھیجنا، اور پھر یہی عمل دہرانا.

ان تمام ریکویسٹس کو ملا کر کئی منٹ لگ سکتے ہیں جو صارفین کو Codex کے پیچیدہ ٹاسک مکمل کرنے کے انتظار میں گزارنے پڑتے ہیں. تاخیر کے لحاظ سے، Codex ایجنٹ لوپ زیادہ وقت تین مراحل میں لیتا ہے : API سروسز میں کام (ریکویسٹس کی جانچ اور عمل)، ماڈل چلانا، اور کلائنٹ سائیڈ کام (ٹولز استعمال کرنا اور ماڈل کے لیے مواد تیار کرنا). استنباط (انفرنس) وہ مرحلہ ہے جہاں ماڈل نئے ٹوکن تیار کرنے کے لیے GPUs پر چلتا ہے. پہلے GPUs پر LLM چلانا لوپ کا سب سے سست مرحلہ تھا، اس لیے API سروس کی تاخیر آسانی سے نظر نہیں آتی تھی. جیسے جیسے انفرنس تیز ہوتا جا رہا ہے، ایجنٹ پر مبنی عمل میں API کی مجموعی تاخیر زیادہ نمایاں ہوتی جا رہی ہے.

اس پوسٹ میں ہم بتاتے ہیں کہ ہم نے API پر مبنی ایجنٹ لوپس کو مجموعی طور پر 40٪ تیز کیسے بنایا، جس سے صارفین انفرنس کی رفتار میں 65 سے تقریباً 1000 ٹوکن فی سیکنڈ تک کا اضافہ دیکھ سکتے ہیں. ہم نے یہ بہتری کیشنگ استعمال کر کے، غیر ضروری نیٹ ورک مراحل ہٹا کر، مسائل کو تیزی سے نشان زد کرنے کے لیے سیفٹی چیکس کو تیز بنا کر، اور —سب سے اہم، Responses API کے ساتھ مسلسل کنکشن بنا کر حاصل کی—تاکہ بار بار الگ الگ API کالز کرنے کی ضرورت نہ رہے.

Responses API میں، GPT‑5 اور GPT‑5.2 جیسے پچھلے فلیگ شپ ماڈل تقریباً 65 ٹوکن فی سیکنڈ (TPS) کی رفتار سے چلتے تھے. GPT‑5.3‑Codex‑Spark، جو ایک تیز کوڈنگ ماڈل ہے، کی لانچ کے لیے ہمارا ہدف اسے تقریباً دس گنا تیز بنانا تھا—یعنی 1000 سے زیادہ ٹوکن فی سیکنڈ—جو خاص Cerebras ہارڈویئر کے ذریعے ممکن ہوا جو LLM انفرنس کے لیے تیار کیا گیا ہے. اس نئے ماڈل کی اصل رفتار صارفین تک پہنچانے کے لیے ہمیں API کی تاخیر کو کم کرنا ضروری تھا. 

نومبر 2025 کے آس پاس ہم نے Responses API پر کارکردگی بہتر بنانے کی مہم شروع کی اور ایک ریکویسٹ میں بنیادی تاخیر کم کرنے کے لیے کئی اصلاحات کیں: 

• ہم نے تیار شدہ ٹوکنز اور ماڈل کی سیٹنگز کو میموری میں محفوظ کیا تاکہ بار بار ٹوکن پراسیسنگ اور اضافی نیٹ ورک کالز سے بچا جا سکے، خاص طور پر ملٹی ٹرن گفتگو میں
• ہم نے غیر ضروری درمیانی سروسز (مثلاً امیج پروسیسنگ) کو ہٹا کر اور سیدھا انفرنس سروس کو کال کر کے نیٹ ورک کی تاخیر کم کی
• ہم نے اپنے سیفٹی سسٹم کو بہتر بنایا تاکہ کچھ چیکس تیزی سے گفتگو کو پہچان کر فلیگ کر سکیں

ان بہتریوں کے ساتھ، ہم نے پہلے ٹوکن (TTFT) آنے کے وقت میں تقریباً 45٪ بہتری حاصل کی، —جو API کی رفتار کو ظاہر کرتا ہے—لیکن یہ بھی GPT‑5.3‑Codex‑Spark کے لیے کافی تیز نہیں تھا. ان بہتریوں کے باوجود، Responses API کی تاخیر ماڈل کی رفتار کے مقابلے میں اب بھی زیادہ تھی. سادہ الفاظ میں، صارفین کو پہلے API چلانے والے CPUs کا انتظار کرنا پڑتا تھا، پھر وہ ماڈل چلانے والے GPUs تک پہنچ پاتے تھے.

اصل مسئلہ ڈیزائن کا تھا: ہم ہر Codex ریکویسٹ کو الگ سمجھتے تھے، اس لیے ہر اگلی ریکویسٹ میں گفتگو کی ہسٹری اور دوبارہ استعمال ہونے والا ڈیٹا دوبارہ پروسیس کرنا پڑتا تھا. حتیٰ کہ جب گفتگو کا زیادہ حصہ ویسا ہی رہتا تھا، تب بھی ہمیں پوری ہسٹری پر کام کرنا پڑتا تھا. جیسے جیسے گفتگو لمبی ہوتی گئی، یہ بار بار کی پراسیسنگ زیادہ مہنگی ہوتی گئی.

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

ہم نے چند مختلف طریقوں پر غور کیا، جیسے WebSockets اور gRPC کی دو طرفہ اسٹریمنگ. ہم نے WebSockets کا انتخاب کیا کیونکہ پیغامات کی ترسیل کے ایک سادہ پروٹوکول کے طور پر، صارفین کو Responses API کے ان پُٹ اور آؤٹ پُٹ کی ساخت تبدیل نہیں کرنی پڑتی. یہ ڈویلپرز کے لیے آسان تھا اور ہمارے موجودہ سسٹم کے ساتھ بغیر زیادہ تبدیلی کے اچھی طرح فٹ ہو گیا.

پہلے WebSocket پروٹو ٹائپ نے ہمیں دکھایا کہ Responses API کی رفتار ہماری توقع سے کہیں زیادہ بہتر ہو سکتی ہے. Codex ٹیم کے ایک انجینئر نے، جسے پورے API سسٹم کی گہری سمجھ تھی، رات بھر Codex ایجنٹ چلا کر ایک پروٹو ٹائپ تیار کر لیا.

اس پروٹو ٹائپ میں ایجنٹ کے عمل کو ایک مسلسل، طویل عرصے تک چلنے والی ریسپانس کے طور پر دیکھا گیا. asyncio کے استعمال سے، Responses API ٹول کال کے بعد سیمپلنگ لوپ میں بیک گراؤنڈ میں رک جاتی تھی، اور پھر کلائنٹ کو response.done ایونٹ بھیجتی تھی. ٹول چلانے کے بعد، کلائنٹ نتیجہ کے ساتھ response.append ایونٹ واپس بھیجتا تھا، جس سے عمل دوبارہ شروع ہو جاتا تھا اور ماڈل آگے بڑھتا تھا.

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

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

تاہم اس کی وجہ سے API پہلے کے مقابلے میں کم مانوس اور زیادہ پیچیدہ ہو گئی. ہم چاہتے تھے کہ ڈویلپرز آسانی سے WebSocket سپورٹ شامل کر سکیں بغیر اس کے کہ انہیں اپنی API انٹیگریشن کو نئے طریقے سے دوبارہ بنانا پڑے.

جو ورژن ہم نے جاری کیا، اس میں ہم نے مانوس طریقہ اختیار کیا: response.create کو اسی ان پٹ کے ساتھ استعمال کریں، اور previous_response_id کے ذریعے پچھلے جواب سے گفتگو کو آگے جاری رکھیں.

WebSocket کنکشن پر، سرور اسی کنکشن کے لیے پچھلے ریسپانس کا ڈیٹا میموری میں محفوظ رکھتا ہے. جب نئی response.create ریکویسٹ میں previous_response_id شامل ہوتا ہے، تو ہم پوری گفتگو دوبارہ بنانے کے بجائے محفوظ شدہ اسٹیٹ کو میموری سے حاصل کر لیتے ہیں.

اس کیشیڈ اسٹیٹ میں شامل ہیں:

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

پچھلے ریسپانس کی میموری میں محفوظ حالت کو دوبارہ استعمال کر کے، ہم کئی بڑی کارکردگی کی بہتریاں حاصل کرنے میں کامیاب ہوئے:

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

مقصد یہ تھا کہ اسے کم بوجھ والے سادہ نمونے کے قریب بنایا جائے، مگر ایسے انداز میں جسے ڈویلپر پہلے سے سمجھتے اور استعمال کرتے ہیں.

دو ماہ تک WebSocket موڈ بنانے کے بعد، ہم نے اہم کوڈنگ اسٹارٹ اپس کے ساتھ ایک الفا ورژن جاری کیا تاکہ وہ اسے اپنے سسٹمز میں شامل کریں اور محفوظ طریقے سے اس کا استعمال آہستہ آہستہ بڑھا سکیں. الفا صارفین نے اسے بہت پسند کیا اور اپنے ایجنٹ پر مبنی ورک فلو میں 40٪ تک بہتری⁠(نئی ونڈو میں کھلتا ہے) کی رپورٹ دی. مثبت الفا فیڈبیک کو دیکھتے ہوئے، ہم لانچ کے لیے تیار تھے.

لانچ کے نتائج فوراً نظر آنے لگے. Codex نے تیزی سے اپنی زیادہ تر API ٹریفک کو WebSocket موڈ پر منتقل کر دیا اور رفتار میں واضح بہتری اور تاخیر میں کمی دیکھی. GPT‑5.3‑Codex‑Spark کے لیے ہم نے 1000 ٹوکن فی سیکنڈ کا ہدف حاصل کر لیا اور بعض اوقات یہ 4000 تک بھی پہنچا، جس سے ثابت ہوا کہ Responses API حقیقی استعمال میں زیادہ تیز ماڈل کے ساتھ بھی کام کر سکتی ہے. اس کا اثر ڈویلپر کمیونٹی میں بھی جلد ہی نظر آنے لگا.

• Codex نے تیزی سے اپنی زیادہ تر ٹریفک کو WebSockets پر منتقل کر دیا. Codex کے صارفین جو جدید ماڈلز جیسے GPT‑5.3‑Codex⁠(نئی ونڈو میں کھلتا ہے)، GPT‑5.4⁠(نئی ونڈو میں کھلتا ہے)، اور اس سے آگے کے ماڈلز استعمال کر رہے ہیں، سب کو WebSocket موڈ کی تیز رفتار کا فائدہ ملتا ہے.
• Vercel نے اپنے AI SDK میں WebSocket موڈ شامل کیا اور تاخیر میں 40٪ تک⁠(نئی ونڈو میں کھلتا ہے) کمی دیکھی.
• Cline کے ملٹی فائل ورک فلو 39٪ زیادہ تیز⁠(نئی ونڈو میں کھلتا ہے) ہو گئے ہیں.
• Cursor میں OpenAI ماڈلز 30٪ تک زیادہ⁠(نئی ونڈو میں کھلتا ہے) تیز ہو گئے.

WebSocket موڈ مارچ 2025 میں لانچ کے بعد Responses API میں شامل ہونے والی سب سے اہم نئی خصوصیات میں سے ایک ہے. ہم نے صرف چند ہفتوں میں آئیڈیا سے لے کر مکمل پروڈکشن سسٹم تک کا سفر طے کیا، جو OpenAI کی API اور Codex ٹیموں کے قریبی تعاون سے ممکن ہوا. یہ نہ صرف ایجنٹ ورک فلو میں تاخیر کو بہت کم کرتا ہے بلکہ ایک اہم ضرورت کو بھی پورا کرتا ہے: جیسے جیسے ماڈل انفرنس تیز ہوتے ہیں، ان کے ساتھ کام کرنے والے سسٹمز کو بھی تیز ہونا چاہیے تاکہ صارفین واقعی اس بہتری کو محسوس کر سکیں.