Rané sestavy Voice Pro používaly ONNX Runtime s oficiálními exporty Qwen ASR ONNX. Fungovalo to, ale nasazení bylo bolestivé. Zde je, s čím jsme se setkali, a proč aplikace nyní běží na llama.cpp s modely kvantizovanými ve formátu GGUF.
Problém 1: velikost instalace
Verze Voice Pro pro Windows s ONNX Runtime, poskytovatelem DirectML, poskytovatelem CUDA a váhami modelu vyšla na 430 MB. Linux byl podobný. Je to hodně požadovat od někoho, aby si stáhl nástroj pro diktování, který ještě nevyzkoušel.
Build GGUF je 83 MB ve Windows. Sestavený binární soubor llama.cpp je velmi malý, kvantizovaný základní model má velikost přibližně 60 MB (oproti přibližně 200 MB u formátu ONNX ve formátu fp16) a neposkytujeme samostatné DLL s ovladači pro CPU, CUDA, DirectML a Vulkan – llama.cpp zvládá všechny čtyři platformy pomocí jediného binárního souboru.
Problém 2: studený start
ONNX Runtime s DirectML na čerstvě nainstalovaném systému Windows potřeboval 3–5 sekund na inicializaci inference session. Pokaždé, když uživatel po restartu stiskl klávesovou zkratku poprvé, setkal se s tímto zpožděním. To je nepřijatelné pro diktační nástroj, kde je hlavním cílem „mluvit okamžitě“.
llama.cpp načte model GGUF na stejném hardwaru za přibližně 400 ms při studeném startu. Váhy jsou mapovány do paměti, neexistuje krok kompilace grafu a není potřeba inicializace runtime balíčku.
Problém 3: peklo balení
ONNX Runtime je dodáván jako Python wheel, což znamená Různá kola podle verze Pythonu, operačního systému a architektury CPU. Přidání akcelerace GPU násobí počet variant podle verze CUDA a verze DirectML. Nuitka (nástroj pro balení) neustále balil špatnou variantu. Měli jsme skripty pro sestavení se šesti podmínkovými větveními.
llama.cpp je jediný binární soubor v jazyce C++. Kompilujeme ho jednou pro každou platformu (Windows x64, Linux x64) a dodáváme ho jako nativní spustitelný soubor, který Voice Pro volá. Pro inferenci vůbec nezávisí na Pythonu – Python slouží pouze jako spojovací prvek.
Problém 4: kvalita při nízkých velikostech
Problémem kvantizace je ztráta přesnosti. V praxi dosahuje kvantizovaná verze Qwen3-ASR 0.6B (náš základní model) pomocí Q5_K_M hodnoty WER v rozmezí 0,3 % oproti plné verzi ve formátu fp16 ONNX na naší interní sadě pro hodnocení. Verze Q4_0 je výrazně horší, proto jako výchozí volbu poskytujeme právě Q5_K_M. Uživatelé, kteří chtějí maximální přesnost, si mohou ze správce modelů stáhnout verzi ve formátu fp16.
Na co jsme se rozhodli rezignovat
Podpora ASR v llama.cpp je novější než ta v ONNX Runtime. Některé exotické architektury modelů zatím nemají konvertory GGUF. Prozatím to nevadí – Qwen3-ASR se konvertuje čistě – ale pokud bychom v budoucnu chtěli vyzkoušet radikálně odlišný model ASR, možná budeme muset ponechat cestu ONNX jako záložní řešení.
Konečný výsledek: instalace o 5× menší, studený start zhruba 10× rychlejší, místo dvanácti binárek se sestavuje jedna. Měli jsme to udělat od prvního dne.