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