OpenAI تشرح كيف أعادت هيكلة WebRTC من أجل AI صوتي منخفض زمن الاستجابة

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

لماذا لم يكن الأسلوب السابق مناسباً

بالنسبة لذكاء صوتي، لا يكفي ببساطة التعرف على الكلام وإنشاء استجابة سريعة. يجب أن تسير المحادثة بسرعة الكلام البشري: بدون فترات صمت محرجة، ولا انقطاعات متقطعة، ولا تأخير بعدة ثوان قبل رد فعل النموذج.

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

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

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

Relay بالإضافة إلى Transceiver

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

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

الحيلة الأكثر إثارة للاهتمام تتعلق بالحزمة الأولى. تستخدم OpenAI شرح اسم المستخدم ICE، أو ufrag، وتضمن فيه معلومات التوجيه الكافية فقط للـ relay لتحديد الكتلة و transceiver المحددة. أثناء الإشارة، يتلقى العميل VIP relay مشترك وميناء UDP ثابت، والحزمة STUN الأولى تزود النظام ببيانات كافية لإرسال التيار على المسار الصحيح على الفور، دون استدعاء منفصل لخدمة بحث خارجية. بعد إنشاء المسار، يتم تخزين تعيين العناوين بشكل إضافي في Redis للاسترجاع السريع بعد إعادة تشغيل relay.

كيف قللوا الكمون

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

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

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

ماذا يعني هذا

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