Οι πρώιμες εκδόσεις του Voice Pro χρησιμοποιούσαν το ONNX Runtime με τις επίσημες εξαγωγές Qwen ASR σε ONNX. Λειτουργούσε, αλλά η διανομή του ήταν επίπονη. Να τι αντιμετωπίσαμε και γιατί η εφαρμογή τρέχει τώρα σε llama.cpp με μοντέλα κβαντισμένα σε μορφή GGUF.
Πρόβλημα 1: μέγεθος εγκατάστασης
Ένα build του Voice Pro για Windows με ONNX Runtime + τον πάροχο DirectML + τον πάροχο CUDA + τα βάρη του μοντέλου ανέρχονται σε 430 MB. Το Linux ήταν παρόμοιο. Αυτό είναι πολύ να ζητάς από κάποιον να κατεβάσει για ένα εργαλείο υπαγόρευσης που δεν έχει δοκιμάσει ακόμη.
Η έκδοση GGUF είναι 83 MB στα Windows. Το μεταγλωττισμένο δυαδικό αρχείο llama.cpp είναι μικρό, το κβαντισμένο βασικό μοντέλο είναι ~60 MB (σε σύγκριση με ~200 MB ως fp16 ONNX), και δεν παρέχουμε ξεχωριστά DLL εκτελεστικού παρόχου για CPU, CUDA, DirectML και Vulkan — το llama.cpp διαχειρίζεται και τα τέσσερα με ένα μόνο δυαδικό αρχείο.
Πρόβλημα 2: εκκίνηση εν ψυχρώ
Το ONNX Runtime με DirectML σε μια καθαρή εγκατάσταση των Windows χρειαζόταν 3–5 δευτερόλεπτα για να αρχίσει τη συνεδρία inference. Κάθε φορά που ο χρήστης πατούσε το hotkey για πρώτη φορά μετά από επανεκκίνηση, αντιμετώπιζε αυτή την καθυστέρηση. Απολύτως απαράδεκτο για ένα εργαλείο υπαγόρευσης, όπου το κύριο σημείο είναι «μιλάτε αμέσως».
Το llama.cpp φορτώνει το μοντέλο GGUF σε ~400 ms εν ψυχρώ στο ίδιο υλικό. Βάρη με memory-mapping, χωρίς βήμα μεταγλώττισης γραφήματος, χωρίς wheel runtime για αρχικοποίηση.
Πρόβλημα 3: το χάος της συσκευασίας
Το ONNX Runtime παρέχεται ως Python wheel, που σημαίνει διαφορετικά wheels ανά έκδοση Python, λειτουργικό σύστημα και αρχιτεκτονική CPU. Προσθέστε επιτάχυνση GPU και πολλαπλασιάζετε με την έκδοση CUDA και την έκδοση DirectML. Το Nuitka (ο πακετοποιητής μας) συνέχιζε να συμπεριλαμβάνει τη λανθασμένη παραλλαγή. Είχαμε σενάρια κατασκευής με έξι συνθηκικούς κλάδους.
Το llama.cpp είναι ένα μόνο δυαδικό αρχείο C++. Το μεταγλωττούμε μία φορά ανά πλατφόρμα (Windows x64, Linux x64) και το διανέμουμε ως εγγενές εκτελέσιμο που καλεί το Voice Pro. Δεν υπάρχει καμία εξάρτηση από το runtime του Python για την εξαγωγή συμπερασμάτων — το Python είναι απλώς η κόλλα.
Πρόβλημα 4: ποιότητα σε μικρά μεγέθη
Το πρόβλημα με την κβάντωση είναι η απώλεια ακρίβειας. Στην πράξη, η κβάντωση Q5_K_M του Qwen3-ASR 0.6B (το βασικό μας μοντέλο) μετράει εντός 0,3% WER σε σχέση με την πλήρη έκδοση fp16 ONNX στο εσωτερικό μας σύνολο αξιολόγησης. Η Q4_0 είναι αισθητά χειρότερη, γι' αυτό παρέχουμε την Q5_K_M ως προεπιλογή. Οι χρήστες που θέλουν μέγιστη ακρίβεια μπορούν να κατεβάσουν την έκδοση fp16 από τον διαχειριστή μοντέλων.
Τι θυσιάσαμε
Η υποστήριξη ASR του llama.cpp είναι νεότερη από αυτή του ONNX Runtime. Ορισμένες εξωτικές αρχιτεκτονικές μοντέλων δεν διαθέτουν ακόμη μετατροπείς GGUF. Προς το παρόν αυτό δεν έχει σημασία — το Qwen3-ASR μετατρέπεται καθαρά — αλλά αν θελήσουμε να δοκιμάσουμε ένα ριζικά διαφορετικό μοντέλο ASR στο μέλλον, ίσως χρειαστεί να διατηρήσουμε τη διαδρομή ONNX ως εναλλακτική.
Καθαρό αποτέλεσμα: εγκατάσταση 5 φορές μικρότερη, εκκίνηση από κρύα κατάσταση περίπου 10 φορές γρηγορότερη, ένα δυαδικό αρχείο για δημιουργία αντί για δώδεκα. Θα έπρεπε να το είχαμε κάνει από την πρώτη μέρα.