Rané verze Brethof Voice Pro využívaly ONNX Runtime spolu s oficiálními exporty Qwen ASR ve formátu ONNX. Fungovalo to, ale jejich nasazení bylo komplikované. Zde je výčet problémů, se kterými jsme se setkali, a důvod, proč aplikace nyní běží na llama.cpp s modely kvantovanými v formátu GGUF.
Problém 1: velikost instalace
Vyšla verze Voice Pro pro Windows s ONNX Runtime + poskytovatelem DirectML + poskytovatelem CUDA + váhami modelu. 430 MBLinux byl podobný. Je to příliš mnoho požadavků na někoho, aby stáhl nástroj pro dikci, který ještě nevyzkoušel.
Verze GGUF 83 MB v systému WindowsKompilovaný binář llama.cpp je velmi malý, kvantizovaný základní model má velikost přibližně 60 MB (oproti přibližně 200 MB u verze v formátu fp16 ONNX), a my neposkytujeme samostatné DLL sady pro provádění na CPU, CUDA, DirectML a Vulkan – llama.cpp zvládá všechny čtyři platformy pomocí jediného bináře.
Problém 2: chladný start
ONNX Runtime s DirectML na čerstvě nainstalovaném systému Windows potřeboval 3–5 sekund na inicializaci sesionu inference. Pokaždé, když uživatel po restartu poprvé stiskl klávesu s předvolenou funkcí, setkal se s tímto zpožděním. To je nepřijatelné pro nástroj na dikci, jehož hlavním cílem je „okamžité mluvení“.
llama.cpp na stejném hardwaru načte model GGUF během přibližně 400 ms. Váhy jsou mapovány do paměti, neexistuje krok kompilace grafu a není potřeba žádné inicializační činnosti během provozu.
Problém 3: peklo balení
ONNX Runtime je distribuován jako Python wheel, což znamená různá kola podle verze Pythonu, operačního systému a architektury CPUPřidáním akcelerace GPU se výsledek vynásobí verzí CUDA a verzí DirectML. Nuitka (náš balovač) neustále balil špatnou verzi. Měli jsme skripty na sestavení s šesti podmínkovými větvemi.
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ý používá Brethof Voice Pro. Pro provádění predikcí vůbec nejsou potřeba žádné závislosti na prostředí Python – 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í metody Q5_K_M hodnoty WER v rozmezí 0,3 % oproti plné verzi v formátu fp16 ONNX na naší vnitřní sadě pro hodnocení. Verze Q4_0 je výrazně horší, a proto jako výchozí verzi poskytujeme právě Q5_K_M. Uživatelé, kteří chtějí maximální přesnost, si mohou z manažera modelů stáhnout verzi ve formátu fp16.
Co jsme se vzdali
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 není problém – Qwen3-ASR provádí čistou konverzi – ale pokud v budoucnu chceme vyzkoušet zcela odlišný model ASR, možná budeme muset ponechat cestu přes ONNX jako náhradu.
Konečný výsledek: instalace o 5× menší, zahájení provozu přibližně 10× rychlejší, jeden binární soubor k sestavení místo dvanácti. Měli jsme to udělat hned od začátku.