نسخههای اولیه Voice Pro از ONNX Runtime همراه با فایلهای خروجی رسمی Qwen ASR در قالب ONNX استفاده میکردند. این روش کارساز بود، اما پیادهسازی آن دشوار بود. در ادامه مشکلاتی که با آنها روبرو شدیم و دلایلی که باعث شده اکنون این اپلیکیشن روی… کار کند، آمده است. llama.cpp با مدلهای کوانتیزهشده GGUF.
مشکل ۱: حجم نصب
یک بیلد Windows از Voice Pro با ONNX Runtime + ارائهدهنده DirectML + ارائهدهنده CUDA + وزنهای مدل به 430 MB. Linux نیز مشابه بود. این درخواست زیادی است که از کسی خواسته شود برای یک ابزار دیکتهبرداری که هنوز امتحان نکرده، آن را دانلود کند.
نسخه GGUF است ۸۳ مگابایت در Windows. فایل اجرایی کامپایلشدهی llama.cpp بسیار کوچک است؛ مدل پایهی کوانتیزهشده حدود ۶۰ مگابایت اندازه دارد (در حالی که نسخهی FP16 ONNX حدود ۲۰۰ مگابایت است)، و ما فایلهای DLL جداگانهای برای پلتفرمهای CPU، CUDA، DirectML و Vulkan ارائه نمیدهیم — llama.cpp تمام این چهار پلتفرم را با یک فایل اجرایی مدیریت میکند.
مشکل ۲: شروع سرد
استفاده از ONNX Runtime با DirectML روی یک نصب Windows تازه، ۳ تا ۵ ثانیه زمان برای راهاندازی جلسه استنتاج (inference session) میبرد. هر بار که کاربر برای اولین بار پس از راهاندازی مجدد، از کلید میانبر استفاده میکرد، با این تأخیر مواجه میشد. این موضوع برای یک ابزار دیکته که هدف اصلی آن «صحبت کردن بلافاصله» است، غیرقابل قبول است.
llama.cpp مدل GGUF را در حدود ۴۰۰ میلیثانیه cold روی همان سختافزار بارگذاری میکند. وزنهای ممپشده در حافظه، بدون مرحله کامپایل گراف، بدون ویل رانتایم برای راهاندازی.
مشکل ۳: کابوس بستهبندی
ONNX Runtime به صورت یک فایل Python wheel ارائه میشود، که به این معناست: ویلهای (wheels) متفاوت برای هر نسخه پایتون، سیستم عامل و معماری CPU. افزودن شتابدهی GPU و ضرب کردن آن در نسخه CUDA و نسخه DirectML. Nuitka (ابزار بستهبندی ما) همواره نسخه نادرست را بستهبندی میکرد. ما اسکریپتهای ساخت با شش شاخه شرطی داشتیم.
llama.cpp یک باینری تکی C++ است. ما آن را یک بار برای هر پلتفرم (Windows x64، Linux x64) کامپایل میکنیم و آن را بهعنوان یک فایل اجرایی بومی ارسال میکنیم که Voice Pro آن را فراخوانی میکند. هیچ وابستگی به محیط اجرایی پایتون برای استنتاج وجود ندارد — پایتون فقط چسب است.
مشکل ۴: کیفیت در حجمهای کم
نگرانی درباره کوانتیزاسیون، از دست رفتن دقت است. در عمل، نسخه کوانتیزهشده Q5_K_M از Qwen3-ASR 0.6B (مدل پایه ما) در مجموعه ارزیابی داخلی ما، با خطای WER حدود ۰.۳٪ نسبت به نسخه کامل fp16 ONNX عمل میکند. نسخه Q4_0 بهطور محسوسی بدتر است، بنابراین ما Q5_K_M را بهعنوان پیشفرض عرضه میکنیم. کاربرانی که حداکثر دقت را میخواهند، میتوانند نسخه fp16 را از مدیر مدلها دانلود کنند.
آنچه را که واگذار کردیم
پشتیبانی ASR در llama.cpp جدیدتر از ONNX Runtime است. برخی معماریهای مدل عجیبوغریب هنوز مبدل GGUF ندارند. برای الان این مهم نیست — Qwen3-ASR تمیز تبدیل میکند — اما اگر بخواهیم در آینده یک مدل ASR کاملاً متفاوت را امتحان کنیم، ممکن است نیاز داشته باشیم مسیر ONNX را بهعنوان جایگزین نگه داریم.
نتیجه نهایی: نصب ۵ برابر کوچکتر، شروع سرد ~۱۰ برابر سریعتر، یک فایل باینری برای ساخت به جای دوازده تا. باید از روز اول این کار را میکردیم.