كيف تقدم OpenAI الذكاء الاصطناعي الصوتي منخفض الكمون على نطاق واسع

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

وعلى نطاق OpenAI، يترجم ذلك إلى ثلاثة متطلبات ملموسة:

• وصول عالمي لأكثر من 900 مليون مستخدم نشط أسبوعيًا
• إعداد سريع للاتصال بحيث يمكن للمستخدم البدء في التحدث بمجرد بدء الجلسة
• زمن انتقال منخفض ومستقر للوسائط ذهابًا وإيابًا، مع انخفاض التذبذب وفقدان الحزم، بحيث يبدو تبادل الأدوار سلسًا

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

WebRTC معيار مفتوح لإرسال الصوت والفيديو والبيانات منخفضة الكمون بين المتصفحات وتطبيقات الأجهزة المحمولة والخوادم. وغالبًا ما يرتبط بالمكالمات من نظير إلى نظير، لكنه أيضًا أساس عملي للأنظمة الفورية بين العميل والخادم لأنه يوحّد الأجزاء الصعبة من الوسائط التفاعلية: ICE لإنشاء الاتصال واجتياز NAT (ترجمة عناوين الشبكة)، وDTLS وSRTP (بروتوكول النقل الآمن في الزمن الحقيقي) للنقل المشفر، والتفاوض على برامج الترميز لضغط الصوت وفك ترميزه، وRTCP (بروتوكول التحكم في النقل في الزمن الحقيقي) للتحكم في الجودة، وميزات جهة العميل مثل إلغاء الصدى وتخزين التذبذب المؤقت.

هذا التوحيد مهم لمنتجات الذكاء الاصطناعي. فمن دون WebRTC، سيحتاج كل عميل إلى حل مختلف لكيفية إنشاء الاتصال عبر NATات، وتشفير الوسائط، والتفاوض على برامج الترميز (المُرمِّزات ومُفكِّكات الترميز المختارة للإرسال وفك الضغط)، والتكيف مع ظروف الشبكة المتغيرة. ومع WebRTC، يمكننا البناء على حزمة بروتوكولات مطبقة بالفعل عبر المتصفحات والمنصات المحمولة، مع تركيز عملنا الخاص على البنية التحتية التي تربط الوسائط الفورية بالنماذج.

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

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

بعد أن اخترنا WebRTC، كان السؤال التالي هو أين ننهيه (أي أين نقبل اتصال WebRTC ونمتلكه، مثلًا عند الطرف) وكيف نربط تلك الجلسات بواجهة الاستدلال الخلفية. وتكمن أهمية الإنهاء في أنه يحدد كيفية تعاملنا مع حالة الجلسة الفورية، ونقل الوسائط، والتوجيه، والكمون، وعزل الأعطال.

إن SFU، أو وحدة إعادة التوجيه الانتقائي، هو خادم وسائط يستقبل دفق WebRTC واحدًا من كل مشارك ويعيد توجيه التدفقات بشكل انتقائي إلى الآخرين. وفي هذا النموذج، ينهي SFU اتصال WebRTC منفصلًا لكل مشارك، وينضم الذكاء الاصطناعي بوصفه مشاركًا آخر في الجلسة. وقد يكون هذا مناسبًا للمنتجات متعددة الأطراف بطبيعتها، مثل المكالمات الجماعية أو الفصول الدراسية أو الاجتماعات التعاونية. فهو يجمع برامج ترميز الصوت ورسائل RTCP وقنوات البيانات والتسجيل وسياسات كل دفق في مكان واحد.¹

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

لكن عبء العمل لدينا مختلف. فمعظم الجلسات هي 1:1 — مستخدم واحد يتحدث إلى نموذج واحد، أو تطبيق واحد يتحدث إلى وكيل فوري واحد — مع حساسية للكمون في كل دور. ولهذا النمط من الحركة، اخترنا نموذج جهاز الإرسال والاستقبال: خدمة WebRTC طرفية تنهي اتصال العميل ثم تحوّل الوسائط والأحداث إلى بروتوكولات داخلية أبسط للاستدلال بالنموذج، والنسخ، وتوليد الكلام، واستخدام الأدوات، والتنسيق.

في هذا التصميم، يكون جهاز الإرسال والاستقبال هو الخدمة الوحيدة التي تمتلك حالة جلسة WebRTC، بما في ذلك فحوص الاتصال الخاصة بـ ICE، ومصافحة DTLS، ومفاتيح تشفير SRTP، ودورة حياة الجلسة. ويعني «الإنهاء» هنا أن جهاز الإرسال والاستقبال هو نقطة النهاية التي تُكمل تلك المصافحات وتشفّر الوسائط أو تفك تشفيرها. وقد جعل الاحتفاظ بهذه الحالة في مكان واحد ملكية الجلسة أسهل في الفهم، كما أتاح لخدمات الواجهة الخلفية أن تتوسع مثل الخدمات العادية بدلًا من أن تتصرف هي نفسها كنظراء WebRTC.

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

من الناحية التشغيلية، تؤدي خدمة جهاز الإرسال والاستقبال وظيفتين:

• الإشارات: تفاوض SDP، واختيار برامج الترميز، وبيانات اعتماد ICE، وإعداد الجلسة
• الوسائط: إنهاء اتصالات WebRTC الهابطة والحفاظ على الاتصالات الصاعدة مع خدمات الواجهة الخلفية للاستدلال والتنسيق

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

كانت المشكلة الأولى هي نموذج المنفذ الواحد لكل جلسة نفسه. فعند التوازي العالي، يعني ذلك كشف وإدارة نطاقات كبيرة جدًا من منافذ UDP.

• لم تُصمَّم موازنات التحميل السحابية وخدمات Kubernetes للتعامل مع عشرات الآلاف من منافذ UDP العامة لكل خدمة. وكل نطاق إضافي يزيد التعقيد التشغيلي في إعدادات موازن التحميل، والتحقق من السلامة، وسياسات الجدار الناري، وأمان النشر.³
• ومن الصعب تأمين نطاقات UDP الكبيرة لأنها توسع مساحة السطح التي يمكن الوصول إليها خارجيًا وتجعل تدقيق سياسات الشبكة أصعب.
• كما أنها لا تناسب التوسع التلقائي جيدًا. فالحاويات تُضاف وتُزال وتُعاد جدولتها باستمرار في Kubernetes. واشتراط أن تحجز كل حاوية نطاقًا كبيرًا وثابتًا من المنافذ وتعلن عنه يجعل هذه المرونة هشة.⁴

ولهذا تتجه كثير من أنظمة WebRTC إلى استخدام منفذ UDP واحد لكل خادم، مع إزالة تعدد الإرسال على مستوى التطبيق خلف ذلك المنفذ.⁵

تحل التصاميم القائمة على منفذ واحد لكل خادم مشكلة عدد المنافذ، لكنها تقدم مشكلة ثانية: الحفاظ على ملكية كل جلسة عبر مجموعة من الخوادم.

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

وقد أعطانا ذلك هدفًا محددًا: كشف سطح UDP صغير وثابت للإنترنت العام، مع الاستمرار في توجيه كل حزمة إلى جهاز الإرسال والاستقبال الذي يملك جلسة WebRTC المقابلة.

قيّمنا عدة طرق للوصول إلى ذلك، بما في ذلك TURN ‏(الاجتياز باستخدام المرحّلات حول NAT)، حيث ينهي مرحّل طرفي تخصيصات العميل ويعيد توجيه الحركة نيابةً عنه.²

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

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

يُعد توجيه الحزمة الأولى الخطوة الأساسية في هذا الإعداد. إذ يجب على المرحّل أن يوجّه أول حزمة من العميل قبل وجود أي جلسة على مسار الحزمة نفسه، بدلًا من التوقف لإجراء بحث خارجي في خدمة أخرى.

تحمل كل جلسة WebRTC بالفعل خطاف توجيه أصيلًا في البروتوكول: جزء اسم مستخدم ICE، أو ufrag، وهو معرّف قصير يُتبادل أثناء إعداد الجلسة ويُعاد إرساله في فحوص اتصال STUN. ونحن نولّد ufrag من جهة الخادم بحيث يحتوي على قدر كافٍ من بيانات التوجيه الوصفية لتمكين المرحّل من استنتاج المجموعة الوجهة وجهاز الإرسال والاستقبال المالك.

أثناء الإشارات، يخصص جهاز الإرسال والاستقبال حالة الجلسة ويعيد عنوان VIP مرحّلًا مشتركًا ومنفذ UDP في إجابة SDP. وVIP هو عنوان IP افتراضي أمام مجموعة المرحّلات؛ وعند دمجه مع المنفذ، يمنح العميل وجهة واحدة مستقرة، مثل 203.0.113.10:3478، حتى وإن كانت وراءه عدة نُسخ من المرحّل. وعادةً ما تكون أول حزمة على مسار الوسائط من العميل طلب ربط STUN ‏(أدوات اجتياز الجلسة حول NAT)، الذي يستخدمه ICE للتحقق من أن الحزم يمكنها الوصول إلى العنوان المُعلن.

يحلّل المرحّل من أول حزمة STUN ما يكفي فقط لقراءة ufrag من جهة الخادم، وفك تلميح التوجيه، وإعادة توجيه الحزمة إلى جهاز الإرسال والاستقبال المالك. ويستمع كل جهاز إرسال واستقبال على مقبس UDP مشترك، أي نقطة نهاية واحدة في نظام التشغيل مرتبطة بعنوان IP:منفذ داخلي، وليس مقبسًا واحدًا لكل جلسة. وبعد أن ينشئ المرحّل جلسة من عنوان IP:المنفذ الخاص بمصدر العميل إلى وجهة جهاز الإرسال والاستقبال تلك، تتدفق لاحقًا حزم DTLS وRTP وRTCP داخل الجلسة من دون إعادة فك ترميز ufrag.

وجلسة المرحّل مصممة لتكون في حدها الأدنى عمدًا، إذ تتألف فقط من جلسة في الذاكرة لإعلام إعادة توجيه الحزم، إلى جانب العدادات اللازمة للمراقبة والمؤقتات لانتهاء صلاحية الجلسة وتنظيفها. ويحافظ هذا الخيار التصميمي على توجيه الحزم مباشرة على مسار الحزمة. وإذا أُعيد تشغيل مرحّل وفقد الجلسة، فإن حزمة STUN التالية تعيد بناء الجلسة من تلميح التوجيه في ufrag. ولزيادة الموثوقية، يُستخدم مخزن Redis مؤقت للاحتفاظ بربط <IP العميل + المنفذ، IP جهاز الإرسال والاستقبال + المنفذ> بمجرد إنشاء المسار حتى يمكن استعادته بسرعة أكبر، قبل وصول حزمة STUN التالية.

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

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

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

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

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

خيارات التصميم الأساسية:

• عدم إنهاء البروتوكول: يحلل المرحّل رؤوس STUN/‏ufrag فقط؛ ويستخدم حالة مخزنة مؤقتًا لحزم DTLS وRTP وRTCP اللاحقة، مع إبقاء الحزم معتمة.
• حالة مؤقتة: يحتفظ بخريطة صغيرة داخل الذاكرة ذات مهلة قصيرة تربط عنوان العميل بوجهة جهاز الإرسال والاستقبال من أجل حالة التدفق وقابلية الملاحظة.
• قابلية التوسع الأفقي: تعمل عدة نُسخ من المرحّل بالتوازي خلف موازن تحميل. والحالة ليست حالة WebRTC صلبة، لذا لا تسبب إعادة التشغيل إلا انخفاضات طفيفة في الحركة واستعادة سريعة للتدفقات.

إجراءات الكفاءة:

• SO_REUSEPORT هو خيار لمقبس Linux يسمح لعدة عمال مرحّلين على الجهاز نفسه بربط منفذ UDP نفسه. ثم توزّع النواة الحزم الواردة على هؤلاء العمال، وهو ما يتجنب اختناق حلقة قراءة واحدة.
• runtime.LockOSThread يثبت كل goroutine قارئة لـ UDP على خيط محدد في نظام التشغيل. ومع SO_REUSEPORT، يميل ذلك إلى إبقاء الحزم من التدفق نفسه (عنوان ومنافذ IP للمصدر والوجهة بالإضافة إلى البروتوكول) على نواة CPU نفسها، ما يحسن تموضع الذاكرة المخبئية ويقلل تبديل السياق.
• تساعد المخازن المؤقتة المخصصة مسبقًا والنسخ الأدنى على إبقاء عبء التحليل والتخصيص منخفضًا لتجنب جمع القمامة في Go.

تعامل هذا التنفيذ مع حركة الوسائط الفورية العالمية لدينا ببصمة مرحّل صغيرة نسبيًا، لذلك أبقينا التصميم الأبسط بدلًا من سلوك مسار تجاوز النواة.

تتيح لنا هذه البنية تشغيل وسائط WebRTC على Kubernetes من دون كشف آلاف منافذ UDP. وهذا مهم لأن سطح UDP الأصغر والثابت أسهل في التأمين وموازنة التحميل، كما يتيح للبنية التحتية التوسع من دون حجز نطاقات كبيرة من المنافذ العامة. ومع دعم أفضل للبنية التحتية من Kubernetes ومزيد من الأمان بفضل صغر مساحة السطح، يحافظ هذا التصميم أيضًا على سلوك WebRTC القياسي للعملاء ويؤكد أن التصميم الخالي من SFU كان الخيار الافتراضي الصحيح لعبء عملنا. فمعظم جلساتنا من نقطة إلى نقطة، وحساسة للكمون، وأسهل في التوسع عندما لا تحتاج خدمات الاستدلال إلى التصرف كنظراء WebRTC.

أما الدرس الأوسع فهو أن أفضل مكان لإضافة التعقيد هو طبقة توجيه رقيقة، وليس في كل خدمة خلفية، ولا في سلوك عميل مخصص. لقد منحنا ترميز بيانات التوجيه الوصفية داخل حقل أصيل في البروتوكول توجيهًا حتميًا للحزمة الأولى، وسطح UDP عامًا صغيرًا، ومرونة كافية لوضع نقاط الإدخال قريبًا من المستخدمين حول العالم.

وكانت بعض الخيارات مهمة على نحو خاص:

• الحفاظ على دلالات البروتوكول عند الطرف. فما يزال العملاء يتحدثون WebRTC القياسي، وهو ما يُبقي قابلية التشغيل البيني بين المتصفحات والأجهزة المحمولة سليمة.
• إبقاء حالات الجلسات الصعبة في مكان واحد. فجهاز الإرسال والاستقبال يمتلك ICE وDTLS وSRTP ودورة حياة الجلسة؛ والمرحّل يكتفي بإعادة توجيه الحزم.
• التوجيه استنادًا إلى معلومات موجودة بالفعل في الإعداد. فقد منحنا ufrag الخاص بـ ICE خطافًا لتوجيه الحزمة الأولى من دون إضافة اعتماد على بحث في المسار السريع.
• التحسين للحالة الشائعة قبل اللجوء إلى تجاوز النواة. فقد كان تنفيذ Go ضيق النطاق مع استخدام مدروس لـ SO_REUSEPORT، وتثبيت الخيوط، وتحليل قليل التخصيص كافيًا لعبء عملنا.

لا ينجح الذكاء الاصطناعي الصوتي الفوري إلا عندما تجعل البنية التحتية الكمون غير محسوس. وبالنسبة إلينا، كان ذلك يعني تغيير شكل نشر WebRTC لدينا من دون تغيير ما يتوقعه العملاء من WebRTC نفسه.