إطلاق Gemini 3.1 Flash Live — وما كانت Nextain تستعد له
تم إطلاق Gemini 3.1 Flash Live اليوم. بتزامن غريب، قررنا الكشف عن التقنية التي كنا نجهزها، وإن كانت غير مكتملة بعد. كانت naia-os تدعم Gemini Live عبر حساب Naia ومزود Google، وقد قمنا بتطبيق Gemini 3.1 Flash Live على الفور. يمكنك التحقق من ذلك في الفيديو أدناه.
تُعرف هذه النماذج في الواقع بنماذج S2S، أو نماذج Omni، وهي تدعم محادثات أسرع وأكثر طبيعية مقارنة بمسارات STT وLLM وTTS التقليدية.
نماذج المحادثة الصوتية الفورية (S2S، نموذج Omni) المشابهة لعملية تعلم الإنسان للكلام
يُعد وضع الصوت في GPT-4o، وGemini Live، وMiniCPM-o أمثلة بارزة على هذه النماذج التي تتحدث بالصوت، في الوقت الفعلي، وحتى مع التعبير عن المشاعر، بدلاً من النص. تُعرف باللغة الإنجليزية عادةً باسم Speech to Speech (S2S) أو Omni Model. لقد اعتقدت أنها تشبه البشر أكثر بكثير من نماذج STT أحادية الاتجاه (التي تحول الصوت إلى نص) أو TTS (التي تحول النص إلى صوت). السبب في صعوبة تعلم الصم والبكم الكلام هو أنهم لا يستطيعون سماع نطقهم الخاص، مما يعيق عملية تعلمهم.
لذلك، حكمت بأن هذا هو مستقبل نماذج المحادثة الصوتية وسيكون الاتجاه السائد، فقمت بإزالة خيارات الإعدادات الفردية لـ STT/TTS ودمجتها في 'نموذج المحادثة المباشرة'، وأضفت واجهة برمجة تطبيقات Gemini Live و gpt-4o-realtime-preview. ومع ذلك، نظرًا لأن كلتا واجهتي برمجة التطبيقات مدفوعتان، فقد قمت بتسميتهما 'TTS Only' للمستخدمين المجانيين وأدرجت Edge في خيار نموذج المحادثة، وهكذا صدر الإصدار 0.1.2 مؤخرًا (أمس). لقد قمت بدمج واجهة برمجة تطبيقات Gemini Live مع حساب Naia وأجريت اختبارات حقيقية، وكنت راضيًا جدًا عن استجابة المحادثة من حيث ردود الفعل العاطفية وسرعة الاستجابة.
سوء فهم حول نماذج المحادثة الصوتية الفورية التي اعتقدت أنها مجرد نماذج STT/TTS
ولكن كان هناك سوء فهم كبير هنا. كنت أعتقد أن واجهة برمجة تطبيقات Gemini Live هي نموذج STT/TTS متكامل من الجيل التالي، لكنني اكتشفت لاحقًا أنها تحتوي على نموذج LLM معين مدمج، وهو Gemini 2.5 Flash، وأنه لا يمكن تغيير نموذج LLM.
نموذج المحادثة الصوتية الفورية MiniCPM-o-4.5 الذي يمكن استخدامه محليًا
السبب وراء إدراكي لهذا سوء الفهم هو أن Naia تهدف إلى دعم النماذج المحلية ضمن نطاق استخدام المستخدم، وقد اكتشفت ذلك أثناء البحث عن نموذج محادثة صوتية فورية يمكن تشغيله على مستوى RTX-3090 وتطبيقه. كانت النماذج المستهدفة في البداية هي Moshi وQwen3-Omni-30b وMiniCPM-o-4.5. Moshi هو رائد في هذا المجال في المصادر المفتوحة، لكن لغاته المدعومة هي الإنجليزية/الفرنسية بشكل أساسي، والمجتمع غير نشط، لذا لم يتم اختياره. Qwen3-omni-30b يتمتع بأداء ممتاز حديثًا، لكن 24 جيجابايت من ذاكرة VRAM في بطاقة RTX 3090 واحدة لا تكفي، ولم يتم التحقق منه، لذا تم استبعاده. أخيرًا، تم اختيار MiniCPM-o. على الرغم من أنه لا يدعم اللغة الكورية حاليًا، إلا أنني حكمت أنه إذا كان هناك استثمار رأسمالي كافٍ، فيمكن إجراء ضبط دقيق إضافي للغة، وبما أن الصوت يدعم الصوت المرجعي، فمن الممكن تحقيق TTS الذي يريده المستخدم.
بالإضافة إلى ذلك، اعتقدت أنه نظرًا لصغر حجمه، إذا تم تشغيله مع Qwen3-omni-30b-a3b باستخدام ذاكرة VRAM المتبقية من 24 جيجابايت، فيمكن زيادة أداء LLM بشكل كبير حتى على مستوى RTX-3090. Qwen3-omni هو نموذج محادثة صوتية فورية (نموذج Omni) كما ذكرت سابقًا، لكن السبب وراء عدم اعتماده هو أن إخراج الصوت يتشوه عند التكميم، مما يجعله غير قابل للتشغيل على 24 جيجابايت من ذاكرة GPU للمستهلك، ولكن يقال إن النموذج المكمم يُظهر أداءً جيدًا كنموذج LLM.
لذلك، قمت بتحميل MiniCPM-o على وحدة معالجة الرسومات المحلية (RunPod RTX 3090) وأنشأت خادم جسر Websocket لربطه بتطبيق Naia. ما اكتشفته أثناء ذلك هو أن النموذج لا يعيد ما سمعه. ولكن هنا، كان الاكتشاف الحاسم هو أن نموذج Qwen3-8B المدمج هو الذي يستجيب، وأن نموذج Omni يتم تدريبه من البداية إلى النهاية (end-to-end) ولا يمكن استبداله. لذا، ربما يكون من الأنسب تسمية MiniCPM-o بـ Qwen3-8b-omni. على وجه الدقة، يقال إنه يستخدم Whisper-medium للاستماع، وQwen3-8b للدماغ، وCosyVoice2 لتوليف الكلام، وSigLip2 للرؤية. ويقال إن هذه النماذج المختلفة يتم ربطها وإعادة تدريبها ببيانات متعددة الوسائط. بشكل عام، هذا يعتبر ضبطًا دقيقًا (fine-tuning)، ولكن نظرًا لحجم البيانات متعددة الوسائط الهائل، يمكن أن تتراوح التكلفة من عشرات إلى مئات المليارات من الوون الكوري. كان هناك الكثير من الحديث مؤخرًا في Dokpamo بكوريا حول ما إذا كان 'من الصفر' أم لا، ويبدو أن هذا يشير إلى أن الجبل الحقيقي الذي يجب الوصول إليه ليس مجرد 'من الصفر'.
تحدي كود Claude لدعم MiniCPM-o-4.5 و vllm-omni
لكن حتى Qwen3-8b المدمج، يقال إنه بمستوى GPT-4o، لذا لم أستطع تجاهله. علاوة على ذلك، بما أنه يمتلك مرجعًا صوتيًا وإمكانية الضبط الدقيق لـ LLM، فقد حكمت أنه نموذج يجب على Nextain، التي تسعى إلى الذكاء الاصطناعي السيادي، أن تتبعه. قمت بعمل fork لـ vllm ورفعته على RunPod، لكنه تطلب 48 جيجابايت من ذاكرة VRAM. استغرق الأمر يومين تقريبًا لتشغيله. ثم اكتشفت متأخرًا أن هناك مشروعًا منفصلاً يسمى vllm-omni، وأن شخصًا ما كان يعمل بالفعل على MiniCPM-o-4.5. لذلك، علقنا بأننا سندعم اختبار l3. (→ vllm-omni #1182) لم يكن هناك رد بعد، وبينما كنا ننتظر، واصلنا المحاولات داخليًا بناءً على vllm-omni.
هذه المرة، تعاملنا مع الأمر بحذر خاص. ففي السابق، قمت برفع طلب سحب (PR) تم إنشاؤه بواسطة كود Claude إلى مشروع آخر مفتوح المصدر مع تحليل ذكاء اصطناعي غير مكتمل التحقق، وتلقيت انتقادات لاذعة. كان تحليل الكود غير مكتمل، ولم ألتزم بقواعد المجتمع، بل وأنشأت شيئًا خارج نطاق المشروع، لذا كان ذلك أمرًا طبيعيًا. لذلك، هذه المرة، قمت بجمع السياق من منظور المصدر الأصلي (upstream) للمستودع، وكررت عملية المراجعة العدائية. بعد ذلك، أعلنت عن 'المسار النظيف' (clean pass)، وتأكدت من أن المحادثة تعمل بالفعل عند ربطها بـ naia-os، وأنشأت وثائق للمساهمة في المصدر الأصلي وقمت بمراجعتها.
ولكن RunPod تعطل، وعندما حاولت تشغيله مرة أخرى اليوم، لم ينجح. لقد أعاقتني السجلات غير المكتملة التي احتفظت بها أثناء العمل. لم أتمكن من التحقق من وقت التشغيل، لذا لم يكن من الممكن إعادة الإنتاج. بحثت في جميع سجلات الجلسات السابقة للعثور عليها، وكنت أعيد الإنتاج وأعدل السجلات مرة أخرى، لكنني اكتشفت مشكلة حرجة أخرى وتوقفت في النهاية. لقد استخدمت نمطًا معينًا لأنه كان جديدًا، وليس نمطًا لنموذج آخر في vllm-omni، ومع تحديث vllm-omni، تعطل كل شيء. دفعت نتائج التحليل إلى كتابة تقرير مرحلي آخر عن فشل في التحكم في السياق والربط، وبناءً على ذلك، قمت بتعديل السياق والربط مرة أخرى، وأجريت تحليلًا متكررًا للكود بدلاً من RunPod باهظ الثمن. ㅜㅜ
https://github.com/nextain/vllm-omni/blob/main/.agents/docs/minicpm-o-midterm-review.md
بالتزامن مع إطلاق Gemini 3.1 Flash Live اليوم، كنت أرغب في الكشف عن فيديو تشغيل MiniCPM-o 4.5. لكن يبدو أن الأمر صعب للغاية في محاولة واحدة. الوقت الآن يقترب من الثالثة والنصف صباحًا. والأهم من ذلك، أن الهدف من هذا العمل هو تحقيق نظام بيئي مفتوح المصدر مدعوم بالذكاء الاصطناعي (AI-native Opensource)، وتجربة تمكن الذكاء الاصطناعي من المساهمة بشكل صحيح في المصادر المفتوحة دون 'slop' الذكاء الاصطناعي. لقد قررنا استعارة بعض بطاقات الرسوميات الأسبوع المقبل، لذا أعتقد أن الوضع سيصبح أسهل قليلاً.
سأشارككم أيضًا ما إذا كان مرجع الصوت أو الضبط الدقيق لـ LLM ممكنًا عند الانتهاء من العمل الإضافي.
المراجع
- Gemini 3.1 Flash Live — بطاقة النموذج (Google DeepMind)
- نماذج الكلام إلى الكلام في عام 2026: ثلاث رهانات معمارية — مقارنة بين معماريات نماذج الصوت المتكاملة
- تقديم gpt-realtime — سيمون ويليسون — تحليل نموذج gpt-realtime
- GPT-4o مقابل GPT-4.1: جميع الاختلافات — اختلافات الأدوار بين النماذج
- نتائج تجربة MiniCPM-o (مشكلة GitHub)
- إعادة تصميم واجهة المستخدم للإعدادات (مشكلة GitHub)
- تصميم مسار STT/TTS (مشكلة GitHub)
