استخدمت الإصدارات الأولى من Brethof Voice Pro محرك ONNX Runtime مع ملفات التصدير الرسمية لتقنية Qwen ASR بصيغة ONNX. كان ذلك فعالاً، لكن نشر التطبيق كان صعباً للغاية. فيما يلي المشاكل التي واجهناها وسبب تشغيل التطبيق الآن على llama.cpp مع نماذج مكيفة باستخدام GGUF.
المشكلة 1: حجم التثبيت
تم إصدار نسخة من Voice Pro لنظام ويندوز تحتوي على ONNX Runtime بالإضافة إلى مزود DirectML ومزود CUDA وأوزان النموذج. 430 ميجابايتكان لينكس مشابهًا. إنه طلب كبير من أحد أن يقوم بتنزيل أداة نطق لم يجربها بعد.
إصدار GGUF هو 83 ميجابايت على ويندوزإن ملف llama.cpp المجمع صغير الحجم للغاية، أما النموذج الأساسي المكيف فهو يبلغ حوالي 60 ميجابايت (مقارنة بحوالي 200 ميجابايت في صيغة ONNX بدقة fp16)، ولا نقدم ملفات DLL منفصلة لتنفيذ البرنامج على وحدات المعالجة المركزية أو CUDA أو DirectML أو Vulkan؛ فـ llama.cpp يتولى التعامل مع جميع هذه الأنظمة باستخدام ملف واحد فقط.
المشكلة 2: البدء من حالة باردة
استغرق تشغيل ONNX Runtime مع DirectML على نظام ويندوز غير مُثبت عليه التطبيقات بعد منحه الإعدادات الأساسية من 3 إلى 5 ثوانٍ لتهيئة جلسة المعالجة. وفي كل مرة يضغط فيها المستخدم على المفتاح السريع لأول مرة بعد إعادة التشغيل، يواجه نفس التأخير. وهذا أمر غير مقبول في أداة التدوين الصوتي حيث المطلوب هو “التحدث فورًا”.
يقوم llama.cpp بتحميل نموذج GGUF في حوالي 400 مللي ثانية على نفس الأجهزة. تُستخدم أوزان مرتبطة بالذاكرة، ولا يوجد خطوة لتجميع الرسوم البيانية، كما لا يوجد برنامج تهيئة يجب تشغيله أثناء التنفيذ.
المشكلة 3: جحيم التغليف
يأتي ONNX Runtime كملف Python wheel، وهذا يعني عجلات مختلفة حسب إصدار Python ونظام التشغيل وهندسة المعالج.أضف تسريع GPU، وسيتم ضرب النتيجة في إصدار CUDA وإصدار DirectML. كانت أداة Nuitka (أداة التعبئة الخاصة بنا) تقوم دائمًا بتضمين النسخة الخاطئة. كان لدينا سكريبتات بناء تحتوي على ستة فروع شرطية.
llama.cpp عبارة عن ملف تنفيذي واحد مكتوب بلغة C++. نقوم بتجميعه مرة واحدة لكل منصة (Windows x64، Linux x64) ونقدمه كبرنامج تنفيذي أصلي يستخدمه Brethof Voice Pro. لا يوجد أي اعتماد على بيئة تشغيل Python أثناء عملية التنبؤ — فـ Python مجرد أداة ربط.
المشكلة 4: الجودة عند الأحجام المنخفضة
المشكلة المتعلقة بالتكميم تكمن في فقدان الدقة. في التطبيق العملي، يُظهر نموذج Q5_K_M المكمم لنموذج Qwen3-ASR 0.6B (النموذج الأساسي لدينا) دقة تقارب 99.7% مقارنة بالنسخة الكاملة بتنسيق fp16 ONNX على مجموعة التقييم الداخلية لدينا. أما نموذج Q4_0 فهو أسوأ بشكل ملحوظ، لذلك نستخدم نموذج Q5_K_M كإعداد افتراضي. يمكن للمستخدمين الذين يرغبون في أقصى دقة تحميل النسخة بتنسيق fp16 من مدير النماذج.
ما التخلينا عنه
إن دعم التعرف على الكلام في llama.cpp أحدث من دعم ONNX Runtime. بعض أنواع هياكل النماذج المتخصصة لا تزال تفتقر إلى محولات GGUF. في الوقت الحالي، هذا لا يشكل مشكلة — فـ Qwen3-ASR يقوم بعملية التحويل بشكل جيد — لكن إذا أردنا تجربة نموذج تعرف على كلام مختلف تمامًا في المستقبل، قد نحتاج إلى الاحتفاظ بخيار ONNX كبديل.
النتيجة النهائية: حجم التثبيت أصغر بخمس مرات، ووقت البدء من الحالة الساكنة أسرع بحوالي عشر مرات، بالإضافة إلى ضرورة بناء ملف تنفيذي واحد فقط بدلاً من اثني عشر. كان يجب علينا القيام بذلك منذ اليوم الأول.