Wczesne wersje Voice Pro korzystały z ONNX Runtime z oficjalnymi eksportami Qwen ASR w formacie ONNX. Działało to, ale wdrożenie było bolesne. Oto, z czym się zetknęliśmy i dlaczego aplikacja teraz działa na llama.cpp z modelami skwantyzowanymi w formacie GGUF.
Problem 1: rozmiar instalacji
Kompilacja Windows Voice Pro z ONNX Runtime + dostawcą DirectML + dostawcą CUDA + wagami modelu wyniosła 430 MB. Wersja dla systemu Linux była podobna. To zbyt wiele, by prosić kogoś o pobranie takiego pliku dla narzędzia do dyktowania, którego jeszcze nie wypróbował.
Wersja GGUF to 83 MB na Windows. Skompilowany plik binarny llama.cpp jest malutki, skwantowany model bazowy ma ~60 MB (w porównaniu z ~200 MB w formacie fp16 ONNX), a my nie dostarczamy osobnych bibliotek DLL dla CPU, CUDA, DirectML i Vulkan — llama.cpp obsługuje wszystkie cztery jednym plikiem binarnym.
Problem 2: zimny start
ONNX Runtime z DirectML na czystej instalacji Windows potrzebował 3–5 sekund na inicjalizację sesji wnioskowania. Za każdym razem, gdy użytkownik po ponownym uruchomieniu naciskał skrót po raz pierwszy, napotykał to opóźnienie. Nie do zaakceptowania w narzędziu do dyktowania, którego całym sensem jest „mów natychmiast”.
llama.cpp ładuje model GGUF w ~400 ms przy zimnym starcie na tym samym sprzęcie. Wagi mapowane do pamięci, brak kroku kompilacji grafu, brak koła runtime do zainicjowania.
Problem 3: koszmar pakowania
ONNX Runtime jest dostarczany jako wheel Pythona, co oznacza różne wersje pakietów (wheels) dla każdej wersji Pythona, systemu operacyjnego i architektury CPU. Dodanie przyspieszenia GPU mnoży liczbę kombinacji przez wersję CUDA i wersję DirectML. Nuitka (nasze narzędzie do pakowania) nadal pakowało niewłaściwą wersję. Mieliśmy skrypty kompilacji z sześcioma warunkowymi gałęziami.
llama.cpp to pojedynczy plik binarny C++. Kompilujemy go raz dla każdej platformy (Windows x64, Linux x64) i dostarczamy jako natywny plik wykonywalny, który wywołuje Voice Pro. Wnioskowanie w ogóle nie wymaga środowiska wykonawczego Pythona — Python jest tylko klejem.
Problem 4: jakość przy małych rozmiarach
Obawą związaną z kwantyzacją jest utrata dokładności. W praktyce skwantowany Qwen3-ASR 0.6B (nasz model bazowy) w wariancie Q5_K_M osiąga WER w granicach 0,3% pełnej wersji fp16 ONNX w naszym wewnętrznym zbiorze ewaluacyjnym. Q4_0 jest wyraźnie gorszy, więc domyślnie dostarczamy Q5_K_M. Użytkownicy, którzy chcą maksymalnej dokładności, mogą pobrać wariant fp16 z menedżera modeli.
To, na co zrezygnowaliśmy
Obsługa ASR w llama.cpp jest nowsza niż w ONNX Runtime. Niektóre egzotyczne architektury modeli nie mają jeszcze konwerterów GGUF. Na razie nie ma to znaczenia — Qwen3-ASR konwertuje czysto — ale jeśli w przyszłości chcemy wypróbować radykalnie inny model ASR, może będziemy musieli utrzymać ścieżkę ONNX jako rozwiązanie zapasowe.
Efekt końcowy: instalacja 5 razy mniejsza, ~10 razy szybsze uruchomienie, jeden plik binarny do zbudowania zamiast dwunastu. Powinniśmy to zrobić od pierwszego dnia.