Voice Pron varhaiset esiversiot käyttivät ONNX Runtimea virallisten Qwen ASR ONNX -vientien kanssa. Se toimi, mutta sen julkaiseminen oli kivuliasta. Tässä kerromme, mihin törmäsimme ja miksi sovellus toimii nyt llama.cpp GGUF-kvantisoitujen mallien kanssa.
Ongelma 1: asennuskoko
Windows-versio Voice Pro:sta, jossa ONNX Runtime + DirectML-toimittaja + CUDA-toimittaja + mallipainot, maksoi yhteensä 430 MB. Linux oli samanlainen. Se on paljon pyydettävää ladattavaksi sanelutyökalusta, jota käyttäjä ei ole vielä kokeillut.
GGUF-rakennelma on 83 MB Windowsissa. Käännetty llama.cpp-binääri on pieni, kvantisoitu perusmalli on noin 60 Mt (vs. noin 200 Mt fp16 ONNX -muodossa), emmekä toimita erillisiä suorituspalvelun DLL-tiedostoja CPU:lle, CUDA:lle, DirectML:lle ja Vulkanille – llama.cpp käsittelee kaikki neljä yhdellä binääritiedostolla.
Ongelma 2: kylmäkäynnistys
ONNX Runtime DirectML:n kanssa kylmässä Windows-asennuksessa kesti 3–5 sekuntia alustaa päättelysessio. Joka kerta, kun käyttäjä painoi pikanäppäintä ensimmäisen kerran uudelleenkäynnistyksen jälkeen, hän kohtasi tämän viiveen. Tämä on mahdotonta hyväksyä sanelutyökalussa, jonka koko tarkoitus on "puhu heti".
llama.cpp lataa GGUF-mallin noin 400 ms:ssa kylmänä samalla laitteistolla. Muistiosoitetut painot, ei graafin käännösvaihetta, ei ajonaikaista wheel-tiedostoa alustettavaksi.
Ongelma 3: pakkaushelvetti
ONNX Runtime toimitetaan Python-wheelinä, mikä tarkoittaa eri wheel-tiedostot kullekin Python-versiolle, käyttöjärjestelmälle ja CPU-arkkitehtuurille. Lisää GPU-kiihdytys, ja kerroin riippuu CUDA- ja DirectML-versiosta. Nuitka (pakkausohjelmamme) paketoi jatkuvasti väärän variantin. Meillä oli rakennusskriptejä, joissa oli kuusi ehtohaaraa.
llama.cpp on yksi C++-binääri. Käännämme sen kerran alustaa kohti (Windows x64, Linux x64) ja toimitamme sen natiivina suoritettavana tiedostona, jota Voice Pro kutsuu. Päätelmässä ei ole lainkaan Python-ajonaikariippuvuutta – Python on vain liimaa.
Ongelma 4: laatu pienillä kokoluokilla
Kvantisoinnin huolenaihe on tarkkuuden menettäminen. Käytännössä Q5_K_M-kvantisoitu Qwen3-ASR 0,6B (perusmallimme) saavuttaa sisäisessä arviointijoukossamme 0,3 prosentin WER-erotuksen täyteen fp16 ONNX -versioon verrattuna. Q4_0 on huomattavasti huonompi, joten toimitamme Q5_K_M:n oletusarvoisesti. Käyttäjät, jotka haluavat maksimaalisen tarkkuuden, voivat ladata fp16-tason mallinhallinnasta.
Mistä luovuimme
llama.cpp:n ASR-tuki on uudempaa kuin ONNX Runtimein. Joillakin eksoottisilla malliarkkitehtuureilla ei ole vielä GGUF-muuntimia. Tällä hetkellä sillä ei ole väliä – Qwen3-ASR muuntuu puhtaasti – mutta jos haluamme tulevaisuudessa kokeilla radikaalisti erilaista ASR-mallia, saatamme joutua pitämään ONNX-polun varajärjestelmänä.
Nettotulos: 5× pienempi asennus, noin 10× nopeampi kylmäkäynnistys, yksi binääri rakennettavaksi kahdentoista sijaan. Tämä olisi pitänyt tehdä ensimmäisestä päivästä lähtien.