Binaan awal Voice Pro menggunakan ONNX Runtime dengan eksport rasmi Qwen ASR ONNX. Ia berfungsi, tetapi pengedarannya agak menyakitkan. Inilah cabaran yang kami hadapi dan sebab mengapa aplikasi kini berjalan pada llama.cpp dengan model yang dikuantisasi GGUF.
Masalah 1: saiz pemasangan
Binaan Windows bagi Voice Pro dengan ONNX Runtime + penyedia DirectML + penyedia CUDA + berat model berjumlah 430 MB. Linux juga serupa. Itu adalah permintaan yang banyak untuk seseorang memuat turun alat diktasi yang belum pernah mereka cuba.
Binaan GGUF ialah 83 MB pada Windows. Binari llama.cpp yang dikompilasi adalah kecil, model asas yang dikuantisasi berukuran ~60 MB (berbanding ~200 MB sebagai ONNX fp16), dan kami tidak menghantar DLL penyedia pelaksanaan berasingan untuk CPU, CUDA, DirectML, dan Vulkan — llama.cpp mengendalikan keempat-empatnya dengan satu binari.
Masalah 2: permulaan sejuk
ONNX Runtime dengan DirectML pada pemasangan Windows sejuk mengambil masa 3–5 saat untuk memulakan sesi inferens. Setiap kali pengguna menekan kekunci panas buat pertama kali selepas dihidupkan semula, mereka menghadapi kelewatan itu. Ia tidak boleh diterima untuk alat diktasi di mana intipatinya ialah "bercakap serta-merta".
llama.cpp memuatkan model GGUF dalam ~400 ms sejuk pada perkakasan yang sama. Berat peta memori, tiada langkah kompilasi graf, tiada roda runtime untuk diinisialisasi.
Masalah 3: kesesakan pembungkusan
ONNX Runtime dihantar sebagai roda Python, yang bermaksud roda berbeza bagi setiap versi Python, OS, dan arkitektur CPU. Tambahkan pecutan GPU dan anda mendarabkan dengan versi CUDA dan versi DirectML. Nuitka (pengemaskini kami) terus membundel varian yang salah. Kami mempunyai skrip pembinaan dengan enam cabang bersyarat.
llama.cpp ialah binari tunggal C++. Kami mengompilnya sekali bagi setiap platform (Windows x64, Linux x64) dan menghantarnya sebagai fail eksekutif asli yang dipanggil oleh Voice Pro. Tiada kebergantungan runtime Python untuk inferens sama sekali — Python hanyalah pengikat.
Masalah 4: kualiti pada saiz kecil
Kebimbangan berkaitan pengkuantisan ialah kehilangan ketepatan. Dalam praktiknya, versi Q5_K_M yang mengkuantisasi Qwen3-ASR 0.6B (model asas kami) menunjukkan nilai WER sekitar 0.3% berbanding versi penuh dalam format fp16 ONNX pada set penilaian dalaman kami. Versi Q4_0 pula jauh lebih buruk, oleh itu kami menyediakan Q5_K_M sebagai pilihan lalai. Pengguna yang ingin mendapatkan ketepatan maksimum boleh memuat turun versi fp16 daripada pengurus model.
Apa yang kami lepaskan
sokongan ASR llama.cpp lebih baharu daripada ONNX Runtime. Beberapa seni bina model eksotik belum mempunyai penukar GGUF. Buat masa ini ia tidak penting — Qwen3-ASR menukar dengan bersih — tetapi jika kami ingin mencuba model ASR yang sangat berbeza pada masa hadapan, kami mungkin perlu mengekalkan laluan ONNX sebagai sandaran.
Hasil keseluruhan: pemasangan 5× lebih kecil, permulaan sejuk ~10× lebih pantas, satu binari untuk dibina berbanding dua belas. Kami sepatutnya melakukan ini sejak hari pertama.