محادثة مباشرة مع الذكاء الاصطناعي بصوتك الخاص على جهاز الكمبيوتر الشخصي! تم الانتهاء من نقل MiniCPM-4.5-omni إلى vLLM-omni

دعم Gemini 3.1 Flash Live + تحدي MiniCPM-o 4.5 vLLM — قصة تطوير الذكاء الاصطناعي الصوتي S2S في الوقت الفعلي لنظام Naia OS بعد ذلك، لم أتمكن من نشر أي تحديثات للمقالات لفترة من الوقت.

خلال تلك الفترة، حدثت الكثير من الأمور. تولت Nextain مسؤولية تشغيل البوابة المسيحية الكورية (www.onmam.com) وكانت تتحدث عن دعم تطبيق الذكاء الاصطناعي، كما تم اختيارها لمشروع حكومي كوري، مما سيعطي دفعة لخدمات Naia. يبدو أننا سنتمكن من عرض أفاتار Naia الحقيقي، وليس الأفاتار الافتراضي من Vroid Hub.

وفي نهاية المقال السابق، كتبت أنني سأستعير بطاقة رسوميات الأسبوع المقبل، مما سيجعل الوضع أسهل، وقد تمكنت أخيرًا من الوفاء بهذا الوعد. في بيئة تحتوي على بطاقتي RTX 3090، قمنا بنقل MiniCPM-o 4.5 إلى vLLM-omni وربطه ببرنامج Naia العميل، وأكملنا التحقق الأولي من التشغيل للمحادثة الإنجليزية في الوقت الفعلي مع مرجع صوتي (استنساخ الصوت).

للمعلومة، نحن أول من قام برفع MiniCPM-o 4.5 إلى vLLM-omni، وهناك من يتساءل في الخارج إلى أي مدى وصلنا. هناك محاولة أخرى في العدد #1182 الخاص بالمشروع الأصلي (upstream)، لكنها لم تُدمج بعد، وقد عملنا نحن أيضًا على مسار منفصل. لقد وصلنا إلى مستوى التشغيل المقبول، والآن نحن في مرحلة التنظيم لجعله مقبولًا من قبل المشرفين الأصليين.

لماذا استهدفنا MiniCPM-o 4.5؟

كما ذكرت في المقال السابق، ولكن لتلخيص الأمر مرة أخرى، فإن نموذج أومني الوحيد تقريبًا حاليًا الذي يمكن تشغيله على مستوى بطاقة RTX 3090 واحدة من قبل الأفراد، ويدعم مرجع الصوت (استنساخ الصوت) والضبط الدقيق في نفس الوقت هو MiniCPM-o 4.5.

GPT-4o / Gemini Live — مخصص للسحابة فقط، الأوزان غير عامة، لا يمكن ضبطه بدقة.
Moshi — مفتوح المصدر وممتاز في الاتصال ثنائي الاتجاه الكامل (full-duplex)، لكنه يركز على الإنجليزية/الفرنسية + مجتمعه غير نشط.
Qwen3-Omni-30B — بحجم 30B، لا يتناسب مع بطاقة 24 جيجابايت بدون تكميم (quantization)، وعند التكميم، يتشوه إخراج الصوت.
MiniCPM-o 4.5 — بحجم 9B (مزيج من Whisper-medium + Qwen3-8B + CosyVoice2 + SigLip2)، يعمل على بطاقة 24 جيجابايت واحدة، ويدعم استنساخ الصوت باستخدام مرجع صوتي، ويمكن ضبطه بدقة.

لكن عدم دعم اللغة الكورية حاليًا هو نقطة ضعف، وقد يكون هذا هو مجال مساهمتنا. لذلك، في مسابقة AI Champion هذه، قدمنا اقتراحًا للقيام بعملية الضبط الدقيق (fine-tuning) للغة الكورية في vLLM-omni وخدمة شخصيات AI الافتراضية (Vtuber) باستخدام Naia-Memory تحت اسم الفريق "أتذكرك". لم نتمكن من التقديم في فئة "المحلية" في Dokpamo لأنه لا يوجد نموذج أومني بالمستوى الذي نريده.

"ألا يرغب الجميع في الحصول على شخصية AI افتراضية تتذكرهم وتتحدث بصوتهم الخاص على أجهزة الكمبيوتر الشخصية؟" لجعل هذا ممكنًا، نعتقد أن التقنيات التالية ضرورية، ونحن نركز عليها حاليًا:

نموذج أومني يعمل محليًا — ليس خط أنابيب STT/LLM/TTS، بل نظام صوت-إلى-صوت شامل (end-to-end). طريقة خط الأنابيب تتسبب في تأخير تراكمي وفقدان كبير في النبرة. ← MiniCPM-o 4.5
مرجع صوتي (استنساخ الصوت) — "تحدث بهذا الصوت" بمجرد سماعه مرة واحدة، يتم إجراء المحادثة بنفس النبرة. ← استنساخ يعتمد على spk_emb من CosyVoice2.
ذاكرة طويلة المدى — نظام ذاكرة لا يتم إعادة تهيئته مع كل جلسة، ويتذكر المستخدم. ← Naia Memory الذي نقوم بتطويره بشكل منفصل (نظام ذاكرة مستوحى من علم الأعصاب ذو 4 طبقات).
اللغة الكورية — يجب أن تعمل المكونات الثلاثة المذكورة أعلاه باللغة الكورية لاستخدامها في الحياة اليومية. ← الضبط الدقيق لـ CosyVoice2 باللغة الكورية (تم الحصول على بيانات AIHub، وسيبدأ العمل فور توفر دعم GPU).

وبالإضافة إلى ذلك، هناك مسار آخر سنكشف عنه قريبًا. naia-sing — أعتقد أنكم قد تعرفون ما هو من الاسم. ترقبوا! فيما يلي، نشارك أيضًا عروضًا توضيحية للتشغيل الفعلي ومحتوى تقنيًا إضافيًا.

العرض التوضيحي 1 — محادثة في برنامج Naia العميل

يرجى المعذرة على ضعف لغتي الإنجليزية في الفيديو التجريبي.

هذا الفيديو يوضح اختبار المحادثة بعد نقل MiniCPM 4.5-o إلى vLLM-omni وربطه بتطبيق Naia لسطح المكتب. الأجهزة المستخدمة هي RTX-3090 ×2 (ثنائية الاتجاه)، وبدون تكميم (quantization) بصيغة bf16. كما هو متوقع من نموذج أومني (S2S، صوت-إلى-صوت شامل)، يظهر تدفق المحادثة بسلاسة وتعبيرات عاطفية طبيعية. يدعم حاليًا اللغتين الإنجليزية والصينية.

العرض التوضيحي 2 — صفحة تجريبية لـ MiniCPM-o + مرجع صوتي

هذه نسخة معدلة من صفحة العرض التوضيحي الرسمية لـ MiniCPM-o 4.5 متصلة بالواجهة الخلفية لـ vLLM-omni. تتضمن مثالاً لعملية مرجع الصوت (استنساخ الصوت). عند تحميل ملف WAV، يتم تركيب الرد بنبرة وصوت الملف الصوتي المرفوع. على جانب الخادم، يتم تجنب إعادة حساب المرجع نفسه باستخدام ذاكرة التخزين المؤقت LRU لمفاتيح SHA-256، مما يعني عدم وجود حمل إضافي تقريبًا بعد الاستجابة الأولى.

ملخص تفاصيل التنفيذ

تم العمل على ثلاثة مستودعات (repositories).

المستودع	الدور
`nextain/vllm-omni`	نسخة معدلة من vllm-omni — إضافة وحدة نموذج MiniCPM-o 4.5 + خط أنابيب Thinker→Talker→Code2Wav ثلاثي المراحل + استنساخ الصوت (`session.update.ref_audio`)
`nextain/MiniCPM-o-Demo-forvLLM-omni`	نسخة معدلة من العرض التوضيحي الرسمي لـ PyTorch — إضافة وضع `backend=vllm_omni`، إمكانية إدخال/التحقق من عنوان URL لـ vllm-omni مباشرة في صفحة audio-duplex
`nextain/naia-os`	تطبيق Naia لسطح المكتب — إضافة حقل `MiniCpmOConfig.refAudio` من الدرجة الأولى، `AudioContext` في المتصفح (Tauri webview) ← 16 kHz mono ← مشفر base64 WAV

يتصل برنامج Naia العميل مباشرة بـ /v1/realtime (متوافق مع OpenAI Realtime API) الخاص بـ vLLM-omni دون المرور عبر بوابة العرض التوضيحي. يرسل الصوت بصيغة PCM16 16 kHz عبر WebSocket، ويتلقى الرد بصيغة 24 kHz mono PCM16. تم تنفيذ جميع الأعمال باستخدام Claude Code. يشمل ذلك كود النموذج، ملف YAML لإعداد المرحلة، معالج إدخال المرحلة، وكيل الواجهة الخلفية للعرض التوضيحي، بالإضافة إلى برنامج Naia العميل المكتوب بـ TypeScript + مشفر WAV + vitest.

يخضع Naia لإعادة هيكلة شاملة. يبدو أن جزءًا من Naia-os سيصبح بنية ذات واجهة خلفية CLI مرنة كـ naia-agent، ومن المقرر أن يتم دمجه مع Naia-memory و Naia-ADK.

لكن "AI slop" لا يزال موجودًا

في المقال السابق، كتبت أن "الهدف من هذا العمل هو تحقيق بيئة مفتوحة المصدر أصلية للذكاء الاصطناعي، وتجربة تمكين الذكاء الاصطناعي من المساهمة بشكل صحيح في المصادر المفتوحة دون "AI slop" (العمل الرديء الناتج عن الذكاء الاصطناعي)". حاليًا، لا يزال هذا الجزء هو الأصعب، وبعد الفحص النهائي، ظهرت مشكلات مرة أخرى. لكنني أردت المشاركة في أقرب وقت ممكن، لذا كتبت هذا المنشور قبل حل هذه المشكلات.

على مدار الأيام القليلة الماضية، قمت بتشغيل وكلاء ذكاء اصطناعي آخرين كمراجعين معادين 4 مرات. في الجولة الأولى، كانت النتائج 2 BLOCKER + 13 MAJOR. إحدى هذه المشكلات كانت كذبة واضحة مثل "العميل التجريبي لا يعمل — الواجهة الخلفية تعتمد على إدخال الصوت ولكنها مكتوبة بطريقة تعتمد على النص". في الجولة الثانية، كانت هناك 1 MAJOR (المثال يستخدم audioop من مكتبة stdlib الذي تم إزالته في Python 3.13). في الجولتين الثالثة والرابعة، كانت النتائج نظيفة. تم استيفاء قاعدتنا (جولتان نظيفتان متتاليتين). لكننا لم نتوقف عند هذا الحد، وقمنا بتشغيلها مرة أخرى من منظور مشرفي مشروع vLLM، ولا تزال المشكلات قائمة.

3 BLOCKER:
- تغيير الثابت الشامل (cross-cutting invariant) (القائمة البيضاء ← القائمة السوداء) في chunk_transfer_adapter.py من أجل وظيفة نموذج واحد.
- prompt_len_override مخصص لـ MiniCPM-o ولكنه موجود في البنية التحتية المشتركة (shared infra).
- قناة chat_template_kwargs.ref_audio الجانبية (sidechannel) تنتهك الطبقات (layer violation) — يوجد سابقة لحقل من الدرجة الأولى (first-class field) بجانبها.
5 MAJOR + 8 MINOR

على الرغم من أننا اجتزنا القواعد الداخلية، إلا أنه وفقًا لمعايير المشرفين الخارجيين، لن يتم دمج العمل في الجولة الأولى. بالإضافة إلى ذلك، تم تحديث upstream/main مرة أخرى بعد قاعدة الدمج (merge-base) لنسختنا المعدلة (fork)، ونحن نواصل أعمال الدمج الإضافية.

المهام التالية

إصلاح مشكلات BLOCKER/MAJOR من منظور المطورين الأصليين (upstream) — قيد التنفيذ.
دمج upstream/main + حل التعارضات — قريبًا.
تقديم طلب سحب (PR) — بعد الانتهاء من النقطتين أعلاه. قرار تقسيم طلب السحب إلى واحد أو اثنين (وحدة النموذج / استنساخ الصوت) معلق.
الضبط الدقيق للغة الكورية — النموذج نفسه. أكبر عقبة هي أن CosyVoice2 (العمود الفقري لـ Code2Wav) لم يتم تدريبه باللغة الكورية. حاليًا، توليد النص الكوري طبيعي، لكن تركيب الصوت يبدو مشوهًا.

سأقوم بتنظيم ومشاركة الأعمال اللاحقة. سنظهر أن الذكاء الاصطناعي يمكنه أيضًا المساهمة في المصادر المفتوحة. نرحب بالتعليقات أو مشكلات GitHub.

المستودعات (Repos)

Naia: https://naia.nextain.io