لماذا تهم حلقات الوكلاء الأسرع
تقول OpenAI إنها أعادت بناء البنية التحتية خلف Responses API لجعل سير العمل بنمط الوكيل أسرع بشكل ملحوظ، في خطوة تهدف إلى تقليل الوقت الذي يقضيه المستخدمون في الانتظار بينما تتبادل الأدوات والنماذج وطلبات API الرسائل ذهاباً وإياباً أثناء المهام المعقدة.
في منشور تقني نُشر في 22 أبريل، وصفت الشركة كيف يمكن لأنظمة مثل Codex أن تحتاج إلى عشرات الطلبات المتسلسلة لإكمال مهمة واحدة: يقرر النموذج ما الذي يجب فعله بعد ذلك، وتعمل أداة على جانب العميل، ثم يُرسل الناتج إلى API، وتُكرَّر الدورة. هذا النمط يجعل حتى الكميات الصغيرة من الحمل الزائد تتراكم بسرعة.
وبحسب OpenAI، أصبح مشكلة الأداء أكثر وضوحاً مع تسارع الاستدلال نفسه. وقالت الشركة إن النماذج الرائدة السابقة في Responses API كانت تعمل بمعدل نحو 65 رمزاً في الثانية. أما بالنسبة إلى GPT-5.3-Codex-Spark، فقد استهدفت OpenAI أكثر من 1,000 رمز في الثانية باستخدام عتاد Cerebras. وبمجرد أن أصبحت عملية توليد النموذج بهذه السرعة، لم يعد من السهل إخفاء الأجزاء الأبطأ من الحلقة.
من عنق زجاجة الاستدلال إلى عنق زجاجة API
تقسّم OpenAI زمن استجابة الوكيل إلى ثلاث مراحل واسعة: عمل خدمة API، واستدلال النموذج، ووقت جانب العميل. ولا يزال جانب العميل مهماً لأن الأدوات تحتاج إلى التنفيذ ويجب تجميع السياق، لكن الشركة قالت إن طبقة API نفسها أصبحت عنق زجاجة ذا أثر ملموس.
هذا التحول فرض استراتيجية تحسين مختلفة. فبدلاً من التركيز فقط على إنتاجية GPU، تقول OpenAI إنها بدأت إزالة الاحتكاك عبر مسار الطلب. وحول نوفمبر 2025، أطلقت الشركة ما وصفته بسباق أداء على Responses API. وشمل العمل تخزين الرموز المولَّدة وإعدادات النموذج في الذاكرة المؤقتة، وتقليل القفزات الشبكية الإضافية عبر استدعاء خدمات الاستدلال بشكل أكثر مباشرة، وتسريع أجزاء من طبقة الأمان حتى يمكن تصنيف بعض المحادثات بسرعة أكبر.
ووفقاً للشركة، حسّنت تلك التغييرات زمن الوصول إلى أول رمز بنحو 45%. لكن OpenAI تقول إن ذلك لم يكن كافياً بعد لإظهار مكاسب السرعة التي توفرها بنية الاستدلال الأحدث بالكامل.
