वॉइस प्रो के शुरुआती बिल्ड्स में आधिकारिक Qwen ASR ONNX निर्यात के साथ ONNX Runtime का उपयोग किया गया था। यह काम करता था, लेकिन इसे शिप करना कठिन था। यहाँ बताया गया है कि हमें क्या समस्याओं का सामना करना पड़ा, और अब यह ऐप क्यों चल रहा है llama.cpp GGUF-क्वांटाइज्ड मॉडलों के साथ।
समस्या 1: इंस्टॉलेशन आकार
ONNX Runtime + DirectML प्रोवाइडर + CUDA प्रोवाइडर + मॉडल वेट्स के साथ Voice Pro का Windows संस्करण जारी किया गया। 430 MB. Linux भी ऐसा ही था। किसी ऐसे डिक्टेशन टूल के लिए, जिसे उन्होंने अभी तक आज़माया ही नहीं है, इतना कुछ डाउनलोड करने के लिए कहना बहुत ज़्यादा है।
GGUF बिल्ड है Windows पर 83 MB. कंपाइल किया गया llama.cpp बाइनरी बहुत ही छोटा है; क्वॉन्टाइज्ड बेस मॉडल लगभग 60 MB है (जबकि FP16 ONNX में यह लगभग 200 MB है), और हम CPU, CUDA, DirectML, और Vulkan के लिए अलग-अलग एक्जीक्यूशन-प्रोवाइडर DLL नहीं देते — llama.cpp एक ही बाइनरी के द्वारा इन चारों को संभाल लेता है।
समस्या 2: कोल्ड-स्टार्ट
Cold Windows Installation पर DirectML के साथ ONNX Runtime में Inference Session को शुरू करने में 3–5 सेकंड लगते थे। रीबूट के बाद जब भी उपयोगकर्ता पहली बार Hotkey दबाता था, तो उसे यही देरी झेलनी पड़ती थी। "तुरंत बोलना" ही ऐसे Dictation Tool का मुख्य उद्देश्य होने के कारण यह स्थिति स्वीकार्य नहीं थी।
llama.cpp उसी हार्डवेयर पर लगभग 400 मिलीसेकंड में GGUF मॉडल को लोड करता है। इसमें मेमोरी-मैप्ड वेट्स का उपयोग होता है; ग्राफ कंपाइलेशन की कोई आवश्यकता नहीं है, और इनिशियलाइज करने के लिए किसी रनटाइम व्हील की भी आवश्यकता नहीं है।
समस्या 3: पैकेजिंग की समस्याएँ
ONNX Runtime एक Python Wheel के रूप में उपलब्ध है, जिसका अर्थ है Python संस्करण, OS, और CPU आर्किटेक्चर के लिए अलग-अलग wheels. GPU एक्सेलरेशन जोड़ने पर, इसे CUDA संस्करण और DirectML संस्करण से गुणा किया जाता है। Nuitka (हमारा पैकेजर) गलत वेरिएंट को ही बंडल करता रहता था। हमारे पास छह शर्तों वाली शाखाओं वाले बिल्ड स्क्रिप्ट थे।
llama.cpp एक single C++ binary है। हम इसे प्रति प्लेटफॉर्म (Windows x64, Linux x64) एक बार compile करते हैं और इसे एक native executable के रूप में ship करते हैं जिसे Voice Pro कॉल करता है। Inference के लिए Python runtime dependency बिल्कुल नहीं — Python बस glue है।
समस्या 4: कम आकारों पर गुणवत्ता
क्वान्टीज़ेशन की चिंता सटीकता की हानि है। व्यावहारिक रूप से, हमारे आंतरिक मूल्यांकन सेट पर Q5_K_M क्वान्टाइज्ड Qwen3-ASR 0.6B (हमारा बेस मॉडल) पूर्ण fp16 ONNX संस्करण की तुलना में 0.3% WER के भीतर प्रदर्शन करता है। Q4_0 का प्रदर्शन काफी खराब है, इसलिए हम डीफ़ॉल्ट रूप से Q5_K_M शिप करते हैं। अधिकतम सटीकता चाहने वाले उपयोगकर्ता मॉडल मैनेजर से fp16 टियर डाउनलोड कर सकते हैं।
हमने क्या त्याग किया
llama.cpp का ASR समर्थन ONNX Runtime की तुलना में नया है। कुछ विशेष प्रकार की मॉडल संरचनाओं के लिए अभी तक GGUF कनवर्टर उपलब्ध नहीं हैं। फिलहाल इससे कोई समस्या नहीं है — Qwen3-ASR ठीक से कनवर्ट करता है — लेकिन यदि हम भविष्य में कोई बिल्कुल अलग ASR मॉडल आजमाना चाहें, तो हमें बैकअप के रूप में ONNX पथ को बनाए रखने की आवश्यकता हो सकती है।
नेट परिणाम: 5 गुना छोटा इंस्टॉल, ~10 गुना तेज़ कॉल्ड स्टार्ट, बारह के बजाय केवल एक बाइनरी बनाना। हमें इसे पहले दिन से ही करना चाहिए था।