Versi awal Voice Pro menggunakan ONNX Runtime bersama ekspor format ONNX dari Qwen ASR resmi. Cara ini berfungsi, tetapi proses pengirimannya sangat merepotkan. Inilah masalah yang kami hadapi, dan alasan mengapa aplikasi ini kini berjalan di llama.cpp dengan model yang dikuantisasi GGUF.
Masalah 1: ukuran instalasi
Build Windows dari Voice Pro dengan ONNX Runtime + penyedia DirectML + penyedia CUDA + bobot model menghasilkan 430 MB. Linux juga serupa. Itu merupakan permintaan yang terlalu besar bagi seseorang untuk mengunduh alat dikte yang belum pernah mereka coba sebelumnya.
Build GGUF-nya adalah 83 MB di Windows. Binary llama.cpp yang telah dikompilasi berukuran sangat kecil, model dasar yang telah dikuantisasi berukuran sekitar 60 MB (dibandingkan dengan sekitar 200 MB sebagai ONNX fp16), dan kami tidak mengirimkan DLL execution-provider terpisah untuk CPU, CUDA, DirectML, dan Vulkan — llama.cpp menangani keempatnya dengan satu binary.
Masalah 2: cold-start
ONNX Runtime dengan DirectML pada instalasi Windows yang baru membutuhkan waktu 3–5 detik untuk menginisialisasi sesi inferensi. Setiap kali pengguna menekan tombol pintas untuk pertama kalinya setelah reboot, mereka mengalami penundaan tersebut. Hal ini tidak dapat diterima untuk alat dikte di mana tujuannya adalah "berbicara segera".
llama.cpp memuat model GGUF dalam ~400 ms cold pada perangkat keras yang sama. Bobot memory-mapped, tidak ada langkah kompilasi grafik, tidak ada wheel runtime untuk diinisialisasi.
Masalah 3: kekacauan pengemasan
ONNX Runtime dikirim sebagai Python wheel, yang berarti wheel berbeda per versi Python, OS, dan arsitektur CPU. Tambahkan akselerasi GPU dan Anda mengalikan dengan versi CUDA dan versi DirectML. Nuitka (alat pengemas kami) terus membundel varian yang salah. Kami memiliki skrip build dengan enam cabang kondisional.
llama.cpp adalah binary C++ tunggal. Kami mengompilasinya sekali per platform (Windows x64, Linux x64) dan mengirimkannya sebagai executable native yang dipanggil oleh Voice Pro. Tidak ada ketergantungan runtime Python sama sekali untuk inferensi — Python hanyalah penghubung.
Masalah 4: kualitas pada ukuran kecil
Kekhawatiran terkait kuantisasi adalah penurunan akurasi. Dalam praktiknya, Qwen3-ASR 0.6B yang dikuantisasi dengan Q5_K_M (model dasar kami) menunjukkan WER dalam selisih 0,3% dari versi ONNX fp16 penuh pada set evaluasi internal kami. Q4_0 jauh lebih buruk, sehingga kami mengirimkan Q5_K_M sebagai default. Pengguna yang menginginkan akurasi maksimal dapat mengunduh tier fp16 dari pengelola model.
Apa yang telah kami korbankan
dukungan ASR dari llama.cpp lebih baru daripada ONNX Runtime. Beberapa arsitektur model eksotis belum memiliki konverter GGUF. Untuk saat ini itu tidak masalah — Qwen3-ASR dikonversi dengan bersih — tetapi jika kami ingin mencoba model ASR yang sangat berbeda di masa depan kami mungkin perlu mempertahankan jalur ONNX sebagai fallback.
Hasil akhir: instalasi 5× lebih kecil, startup dingin ~10× lebih cepat, satu biner untuk dibangun alih-alih dua belas. Seharusnya kami melakukan ini sejak hari pertama.