أعادت OpenAI هيكلة WebRTC لمكدس الصوت: 900 مليون مستخدم نشط أسبوعياً، والـ Relay المكتوب بلغة Go هو المحور الأساسي

كشفت OpenAI في 4 مايو عن تفاصيل البنية التحتية للذكاء الاصطناعي الصوتي—لدعم خدمات الذكاء الاصطناعي الصوتي لمستخدمين نشطين أسبوعيًا (Weekly Active Users) يبلغ عددهم 900 مليون، وإعادة تصميم مكدس WebRTC من جديد، واستبدال طبقة اتصالات الوسائط من هيكل تقليدي “منفذ واحد لكل session واحدة” إلى بنية “relay” رقيقة مكتوبة بلغة Go، مع تجميع جميع حالات جلسات WebRTC في خدمة واحدة تُسمّى “transceiver”. يشرح منشور OpenAI الرسمي على المدونة هذه البنية، والتي تدعم في الوقت نفسه نمط الصوت في ChatGPT وRealtime API، إضافة إلى عدة مشاريع بحثية. بالنسبة لأي فريق يعمل على هندسة ذكاء اصطناعي صوتي، فإن هذا المشروع يُعد وثيقة تقنية نادرة حول “كيف يتم بناء دعامة للذكاء الاصطناعي الصوتي على مستوى عالمي”.

ثلاثة قيود تقنية: WebRTC التقليدي يصطدم بجدار تحت نطاق OpenAI

حدد فريق هندسة OpenAI بوضوح ثلاث قيود “تتعارض مع بعضها” بعد تضخيم الحجم:

1. طريقة إنهاء الوسائط عبر “session واحدة لكل منفذ” (per-session port termination) غير مناسبة لبنية OpenAI التحتية—فعند فتح جلسات صوتية متزامنة محتملة لما يصل إلى 900 مليون مستخدم أسبوعيًا، فإن تصميمًا يمنح كل جلسة منفذًا مستقلًا يستهلك موارد الشبكة بشكل ينفد

2. محادثات ICE ذات الحالة (Interactive Connectivity Establishment) وDTLS (Datagram Transport Layer Security) التي تحتاج إلى مالك مستقر—في الأنظمة الموزعة، إذا تم تقاسم حالة session بين عدة خدمات، تصبح آليات التحمل للعطل والانتقال شديدة التعقيد

3. يجب الحفاظ على زمن انتقال منخفض للغاية للقفزة الأولى (first-hop latency)—فالشعور “الطبيعي” في الذكاء الاصطناعي الصوتي يعتمد على سلاسة turn-taking (تبديل أدوار الحوار)، لذا فإن تجاوز القفزة الأولى لـ 100ms سيظهر كتلعثم واضح

قائمة متطلبات OpenAI كانت أيضًا محددة بوضوح: وصول عالمي (يغطي 900 مليون+ مستخدم)، إنشاء جلسة بسرعة (إتاحة البدء بالكلام بمجرد فتح المستخدم فمه)، وزمن انتقال للوسائط منخفض ومستقر (بما في ذلك تقليل التذبذب jitter وفقد الحزم).

الحل: relay رقيق مكتوب بـ Go + خدمة transceiver مركزية

تقسم بنية OpenAI إلى طبقتين:

طبقة Relay—مكتوبة بلغة Go وتُنفّذ مع الحفاظ عمدًا على البساطة. عملية Go عادية واحدة، تقرأ رؤوس الحزم من socket، وتحدّث مقدارًا صغيرًا من حالة تدفق الحركة، وتُعيد توجيه الحزم، ولا تنهي WebRTC. وهذه هي النقطة الأساسية لتمكين توسيع relay أفقيًا—فلا يلزم الاحتفاظ بالحالة الكاملة لـ WebRTC، ويمكن تبديل relay فيما بينها دون ألم، كما أن تعطل نقطة واحدة لن يوقف الجلسة بأكملها.

طبقة Transceiver—هي الخدمة الوحيدة التي تمتلك حالات جلسات WebRTC، وتشمل فحوصات التوصيل الخاصة بـ ICE، ومصافحة DTLS، ومفاتيح تشفير SRTP، وإدارة دورة حياة الجلسة. من خلال تركيز هذه الحالات في خدمة واحدة، يصبح من السهل تفسير “من يتبع له” كل session، كما يمكن لخدمات الخلفية التوسع كما لو كانت خدمات عادية، دون أن تتولى كل خدمة دور نظير WebRTC.

تكمن دقة هذا التصميم في أنه يفصل “الأجزاء التي تحتاج إلى حالة” عن “الأجزاء عديمة الحالة” بشكل صارم. Relay هي طبقة بيانات عديمة الحالة (قابلة للتكرار بكثرة)، بينما transceiver هي طبقة تحكم ذات حالة (قليلة في العدد لكن كاملة من ناحية الحالة). يتيح هذا التقسيم أيضًا لـ OpenAI التوسع أفقيًا وفق الحاجة دون القلق من انفجار عدد اتصالات WebRTC.

لماذا استخدام Go: منطق الاختيار في هندسة الذكاء الاصطناعي الصوتي

يوضح منشور OpenAI صراحة أن relay تُكتب بلغة Go، مع الحفاظ عمدًا على “نطاق ضيق” في التنفيذ. وتتمثل خلفية هذا الاختيار في منطق هندسي:

1. تدعم Go بشكل أصلي التعامل مع مهام IO-bound مثل “معالجة عشرات الآلاف من الاتصالات عبر منفذ واحد”، دون الحاجة إلى حلقة أحداث معقدة

2. يمكن لباقة net في المكتبة القياسية قراءة حزم UDP مباشرة دون الحاجة إلى ربط مكتبات C

3. بعد الترجمة تنتج ثنائية binary ثابتة واحدة (single static binary)، ما يسهل النشر والحوسبة داخل الحاويات، والتشغيل عبر البنى المختلفة (x86/ARM)

4. إدارة الذاكرة في Go ملائمة للتعامل مع “عدد كبير من الكائنات قصيرة العمر” (حيث يجب تحليل كل حزمة)، كما يمكن التحكم في توقفات GC

كما يشرح ذلك سبب استمرار صعود Go في طبقات البنية التحتية الحديثة (مثل Cloudflare وTailscale وHashiCorp وغيرها)—ليس لأن “Go أكثر قوة من لغة أخرى”، بل لأن Go تتم كتابتها بأبسط شكل في سيناريوهات البنية التحتية التي تعتمد على IO وتحتاج إلى توسيع أفقي.

محاذاة Cloudflare: ساحة Realtime Voice AI

بالتوازي (في أوائل مايو) نشر موقع Cloudflare أيضًا مدونة تقنية بعنوان〈Cloudflare هو المكان الأفضل لبناء وكيـل صوتي فوري〉، وقدّم مقاربته الخاصة مقابل OpenAI. وتختلف المسارات بينهما:

1. OpenAI: بناء مكدس WebRTC relay/transceiver الخاص بها دون الاعتماد على طرف ثالث، وإدخال طبقة الوسائط ضمن حزمة التكنولوجيا الخاصة بها

2. Cloudflare: اعتبار خدمات وسائط WebRTC امتدادًا لمنصة Workers الخاصة بها، وتقديم بنية تحتية “متكاملة من مكان واحد” للمطورين

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

ملاحظات لاحقة: هل سيتم فتح transceiver كمصدر مفتوح؟ وحجم Realtime API ورد فعل المنافسين؟

محاور الرصد في المرحلة التالية:

1. هل ستقوم OpenAI بفتح transceiver/relay كمصدر مفتوح—فالخصوم مثل Anthropic وGoogle وxAI يبنون مكدسات صوتية لأنفسهم، وإذا فتحت OpenAI الكود، فقد يصبح ذلك معيارًا صناعيًا

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

3. مقابلة Anthropic وGoogle—Claude وGemini تدعمان الصوت بالفعل، لكن لا يزال لدى OpenAI فجوة مقارنة بهما من حيث زمن التأخير والحجم، وهل سيؤدي الكشف التقني الحالي إلى تسريع متابعتهم الهندسية

بالنسبة لمطوري تطبيقات AI في تايوان، فإن الذكاء الاصطناعي الصوتي هو ساحة المعركة الرئيسية في النصف الثاني من 2026—فكل سيناريوهات خدمة العملاء والتعليم والسيارات والإنترنت للأشياء (IoT) تحتاج إلى حوار منخفض التأخير. إن الكشف الهندسي الذي قدمته OpenAI هذه المرة هو واحد من أهم المراجع لتحديد “هل ينبغي بناء مكدس صوتي ذاتيًا أم استخدام API طرف ثالث”.

ظهرت هذه المقالة لأول مرة في “鏈新聞 ABMedia”: إعادة بناء OpenAI لمكدس WebRTC الصوتي—900M مستخدم نشط أسبوعيًا، وrelay المكتوب بـ Go كونه الأساس.