Frühe Versionen von Voice Pro nutzten ONNX Runtime mit den offiziellen Qwen-ASR-ONNX-Exporten. Es funktionierte, doch die Veröffentlichung war mühsam. Hier sind die Probleme, auf die wir gestoßen sind, und warum die App jetzt auf llama.cpp mit GGUF-quantisierten Modellen.
Problem 1: Installationsgröße
Eine Windows-Version von Voice Pro mit ONNX Runtime sowie den Anbietern DirectML und CUDA zusammen mit den Modellgewichten kam auf 430 MB. Linux war ähnlich. Das ist viel verlangt von jemandem, der ein Tool zum Diktieren herunterlädt, das er noch nicht ausprobiert hat.
Der GGUF-Build ist 83 MB unter Windows. Die kompilierte llama.cpp-Binärdatei ist winzig, das quantisierte Basismodell ist ~60 MB groß (vs. ~200 MB als fp16 ONNX), und wir liefern keine separaten Execution-Provider-DLLs für CPU, CUDA, DirectML und Vulkan aus – llama.cpp handhabt alle vier mit einer einzigen Binärdatei.
Problem 2: Kaltstart
ONNX Runtime mit DirectML auf einer frischen Windows-Installation benötigte 3–5 Sekunden, um die Inferenzsession zu initialisieren. Jedes Mal, wenn der Benutzer nach einem Neustart zum ersten Mal die Tastenkombination drückte, trat diese Verzögerung auf. Inakzeptabel für ein Diktierwerkzeug, bei dem es darum geht, „sofort sprechen“ zu können.
llama.cpp lädt das GGUF-Modell in ~400 ms Kaltstart auf derselben Hardware. Memory-mapped weights, kein Graph-Kompilierungsschritt, kein Runtime-Wheel zur Initialisierung.
Problem 3: Packaging-Hölle
ONNX Runtime wird als Python-Wheel bereitgestellt, was bedeutet, dass verschiedene Wheels pro Python-Version, Betriebssystem und CPU-Architektur. Fügen Sie GPU-Beschleunigung hinzu, und Sie multiplizieren mit der CUDA-Version und der DirectML-Version. Nuitka (unser Paketierer) hat weiterhin die falsche Variante gebündelt. Wir hatten Build-Skripte mit sechs bedingten Verzweigungen.
llama.cpp ist eine einzelne C++-Binärdatei. Wir kompilieren sie einmal pro Plattform (Windows x64, Linux x64) und liefern sie als native ausführbare Datei, die Voice Pro aufruft. Keine Python-Laufzeitabhängigkeit für die Inferenz – Python ist nur der Kleber.
Problem 4: Qualität bei kleinen Modellen
Das Problem bei der Quantisierung ist der Verlust an Genauigkeit. In der Praxis weist die mit Q5_K_M quantisierte Version von Qwen3-ASR 0,6B (unser Basismodell) auf unserem internen Bewertungssatz einen WER-Wert von 0,3 % im Vergleich zur vollständigen fp16 ONNX-Version auf. Q4_0 ist deutlich schlechter, weshalb wir Q5_K_M als Standard bereitstellen. Nutzer, die maximale Genauigkeit wünschen, können die fp16-Variante über den Modellmanager herunterladen.
Was wir aufgegeben haben
Die ASR-Unterstützung von llama.cpp ist neuer als die von ONNX Runtime. Einige exotische Modellarchitekturen haben noch keine GGUF-Konverter. Für jetzt spielt das keine Rolle – Qwen3-ASR konvertiert sauber – aber wenn wir in Zukunft ein radikal anderes ASR-Modell ausprobieren wollen, müssen wir möglicherweise den ONNX-Pfad als Fallback behalten.
Gesamtergebnis: eine 5-mal kleinere Installation, ein etwa 10-mal schnellerer Kaltstart, nur ein Binärpaket statt zwölf. Das hätten wir von Anfang an tun sollen.