OpenAI تشرح كيف أعادت بناء WebRTC للذكاء الاصطناعي الصوتي منخفض التأخير

كشفت OpenAI تفاصيل إعادة تصميم بنية WebRTC التحتية التي تقوم عليها الميزات الصوتية في ChatGPT وRealtime API. كان الهدف بسيطًا: ألّا ينهار الحوار مع الذكاء الاصطناعي بسبب تأخيرات الشبكة، حتى تحت الأحمال العالمية وبوجود مئات الملايين من المستخدمين.

لماذا لم يكن النهج القديم مناسبًا

لا يكفي في الذكاء الاصطناعي الصوتي أن يتعرّف النظام على الكلام ويولّد الرد بسرعة. فالحوار يجب أن يسير بوتيرة الكلام البشري: دون فترات صمت محرجة، ودون مقاطعات مبتورة، ودون انتظار لثانية كاملة قبل أن يتفاعل النموذج. وتشير OpenAI إلى أن هذا الأمر يصطدم على نطاقها بثلاثة متطلبات في آن واحد: تغطية عالمية لأكثر من 900 مليون مستخدم نشط أسبوعيًا، وإنشاء سريع للاتصال، وزمن ذهاب وإياب للصوت يكون منخفضًا ومستقرًا.

«لا يبدو الذكاء الاصطناعي الصوتي طبيعيًا إلا عندما يتحرك الحوار بسرعة الكلام».

تكمن المشكلة في أن نهج WebRTC التقليدي لا ينسجم جيدًا مع البنية السحابية لدى OpenAI. فإذا احتاجت كل جلسة إلى منفذ UDP عام مستقل، فعند ارتفاع عدد الجلسات المتزامنة يتعيّن فتح نطاقات ضخمة من المنافذ وتأمينها. وهذا غير ملائم لـ Kubernetes، ويعقّد موازنة الأحمال، ويجعل التوسع التلقائي أكثر هشاشة، ويزيد من سطح الهجوم. وفي الوقت نفسه تبقى جلسات ICE وDTLS نفسها stateful، أي إن من المهم أن تصل الحزم إلى العملية التي تملك الاتصال المعني تحديدًا.

Relay مع transceiver

بعد مقارنة عدة خيارات، تخلّت OpenAI عن المخطط الذي يشارك فيه النموذج بوصفه طرف WebRTC عاديًا عبر SFU. فالسيناريو النموذجي لأحمالها هو واحد لواحد: مستخدم واحد يتحدث مع نموذج واحد، أو عميل واحد يتواصل مع وكيل واحد يعمل في الزمن الحقيقي. لذلك اختارت الشركة نموذج transceiver: تنهي خدمة على الحافة (edge) اتصال WebRTC الخاص بالعميل، ثم تحوّل الوسائط والأحداث إلى بروتوكولات داخلية لأغراض الاستدلال، والتفريغ النصي، وتخليق الكلام، واستدعاء الأدوات، والتنسيق بين المكونات.

تقوم الفكرة المحورية للبنية الجديدة على الفصل بين توجيه الحزم وإنهاء البروتوكول. أصبح relay طبقة UDP خفيفة عند المدخل بأثر شبكي عام صغير، بينما بقي transceiver مكوّنًا stateful يحتفظ بـ ICE وDTLS ومفاتيح SRTP والدورة الكاملة لحياة الجلسة. لا يفك relay تشفير الوسائط، ولا يتفاوض على الترميزات، ولا يحاول انتحال دور نظير WebRTC. إنه يقرأ فقط الحد الأدنى من البيانات الوصفية في الحزمة ويعيد توجيه حركة المرور إلى حيث توجد الجلسة المطلوبة.

أما الحيلة الأكثر إثارة للاهتمام فتتعلق بالحزمة الأولى. تستخدم OpenAI ICE username fragment، أو ufrag، وتضمّن فيه من معلومات التوجيه ما يكفي تمامًا ليختار relay العنقود وtransceiver المحدد. أثناء الإشارة (signaling) يتلقى العميل عنوان relay VIP مشتركًا ومنفذ UDP ثابتًا، وتمنح أولى حزم STUN النظام بيانات كافية لإرسال التدفق فورًا عبر المسار الصحيح، دون الرجوع إلى خدمة بحث (lookup) خارجية. وبعد تحديد المسار، يُخزَّن تعيين العناوين أيضًا في Redis كي يتعافى النظام سريعًا بعد إعادة تشغيل relay.

كيف خُفّض زمن التأخير

بعد أن أمكن حصر سطح UDP العام في عدد صغير من العناوين والمنافذ المستقرة، وسّعت OpenAI المخطط نفسه على المستوى العالمي. هكذا نشأ Global Relay، وهو مجموعة موزعة من نقاط الدخول تستقبل الحزم على مقربة من المستخدم وتُدخلها إلى شبكة OpenAI دون قفزة أولى زائدة عبر منطقة بعيدة. وللإشارة تعتمد الشركة على التوجيه الجغرافي وتوجيه القرب من Cloudflare، ولذلك يصل كل من الطلب الأولي عبر HTTP/WebSocket وأول فحص ICE إلى أقرب عنقود مناسب.

• طبقة UDP عامة صغيرة وثابتة بدلًا من آلاف المنافذ المفتوحة
• توجيه الحزمة الأولى عبر بيانات مضمّنة أصلًا في ICE ufrag
• مقبس UDP مشترك على جانب transceiver بدلًا من مقبس لكل جلسة
• حالة قصيرة العمر في الذاكرة مع ذاكرة تخزين مؤقت في Redis لاستعادة المسار بسرعة
• `SO_REUSEPORT` وربط الخيوط بخيوط نظام التشغيل وتقليل عمليات تخصيص الذاكرة لتحقيق إنتاجية عالية

كتبت OpenAI الـ relay نفسه بلغة Go، وقصرت مسؤولياته عمدًا: فهو لا ينهي جلسة WebRTC، بل يحلل بسرعة الترويسات اللازمة فقط، ويحدّث الحد الأدنى من حالة التدفق، ويمرّر الحزم إلى وجهتها. وتؤكد الشركة بشكل خاص أنها لم تحتج إلى kernel bypass: فقد كفى تحسين دقيق على مستوى `SO_REUSEPORT` وربط الخيوط (thread pinning) وتقليل عمليات النسخ الزائدة لخدمة حركة وسائط عالمية في الزمن الحقيقي بطبقة relay صغيرة نسبيًا، ودون التخلي عن السلوك القياسي لـ WebRTC لدى العملاء.

ماذا يعني ذلك

يبدو الأمر للمستخدمين كأن «الوضع الصوتي أصبح أكثر استجابة»، لكن الأهم بالنسبة إلى السوق شيء آخر: فقد أظهرت OpenAI كيف يمكن بناء ذكاء اصطناعي صوتي واسع النطاق فوق WebRTC القياسي، دون عملاء مخصصين ودون تضخم مؤلم في البنية الشبكية. وهذا مرجع جيد لمطوري المساعدين العاملين في الزمن الحقيقي والوكلاء الصوتيين والمنتجات التي يكفي فيها تأخير بنصف ثانية ليُفسد تجربة المستخدم كلها.