पहली बार जब मैंने इसका समय नापा, तो मुझे उस संख्या पर यकीन नहीं हुआ। मैंने हॉटकी दबाए रखी, एक वाक्य बोला, छोड़ा, और अपने दिमाग में एक स्टॉपवॉच चालू कर दी उस पल के सामने जब टेक्स्ट कर्सर पर उतरता है। फिर मैंने वही चीज़ एक क्लाउड डिक्टेशन टूल के साथ की। क्लाउड का राउंड-ट्रिप दोगुना धीमा नहीं था। एक खराब-कॉफी-शॉप-वाई-फाई वाली सुबह में यह एक ऑर्डर ऑफ मैग्नीट्यूड धीमा था, और इससे भी बुरा, यह अप्रत्याशित था — कभी 300 ms, कभी दो सेकंड, कभी-कभी एक स्पिनर जो कुछ नहीं में बदल जाता।
वही वैरिएंस पूरी कहानी है। डिक्टेशन एक रियल-टाइम UI सतह है, और रियल-टाइम UI सतहें टेल लेटेंसी से मरती हैं, औसत लेटेंसी से नहीं। तो जब हमने Vext बनाया — हमारा क्लोज़्ड-सोर्स macOS वॉइस-टू-टेक्स्ट ऐप — सब कुछ डिवाइस पर चलाने का निर्णय प्राइवेसी के बारे में कोई वैचारिक निर्णय नहीं था। यह एक लेटेंसी निर्णय के रूप में शुरू हुआ। प्राइवेसी का तर्क उसमें से मुफ्त में निकल आया।
यह पोस्ट उस निर्णय के पीछे का गणित और आर्किटेक्चर है। यह उस इंजीनियर के लिए लिखा गया है जो उसी दोराहे पर खड़ा है: आपके पास एक ऑडियो या AI फीचर है, आप एक फ्रेंडली SDK वाली क्लाउड STT API को घूर रहे हैं, और आपके दिमाग में एक आवाज़ पूछ रही है कि क्या आपको बस मॉडल को स्थानीय रूप से चला देना चाहिए। मैं आपको उस सवाल का जवाब अहसासों के बजाय संख्याओं से देने का एक तरीका देना चाहता हूँ।
शुरू में एक स्पष्टीकरण। Vext स्वयं क्लोज़्ड सोर्स है। Muvon के डेवलपर टूलिंग — Octomind, Octocode, और बाकी एजेंट स्टैक — परमिसिव लाइसेंस के तहत ओपन सोर्स हैं, और हम उनकी अंदरूनी बातों के बारे में खुलकर लिखते हैं। Vext वह व्यावसायिक ऐप है जो खुले काम का खर्च उठाता है, इसलिए आगे जो है वह दृष्टिकोण और समझौतों के बारे में है, उस तरह का जिस पर कोई भी इंजीनियर तर्क कर सकता है, न कि हमारे सोर्स ट्री का निर्देशित दौरा।
डिक्टेशन एक लेटेंसी-शत्रु वर्कलोड है
ज़्यादातर ऑडियो फीचर सहनशील होते हैं। रात भर में एक पॉडकास्ट ट्रांसक्राइब करना? कोई घड़ी नहीं देख रहा। कॉल खत्म होने के बाद मीटिंग के नोट्स बनाना? कुछ सेकंड की प्रोसेसिंग अदृश्य है। ये बैच वर्कलोड हैं, और बैच वर्कलोड के लिए क्लाउड अक्सर सही जवाब होता है — आपको किसी और के GPU, किसी और की ऑप्स टीम मिलती है, और लेटेंसी का बस कोई मतलब नहीं रहता क्योंकि कोई इंसान क्रिटिकल पाथ पर इंतज़ार नहीं कर रहा।
डिक्टेशन इसका उल्टा है। एक इंसान कर्सर को घूर रहा है, बीच-विचार में, शब्दों के प्रकट होने का इंतज़ार करते हुए। इंटरैक्शन लूप है: बोलो, छोड़ो, अब टेक्स्ट की उम्मीद करो। "छोड़ो" और "टेक्स्ट प्रकट हो" के बीच का हर मिलीसेकंड वह मृत हवा है जिसे उपयोगकर्ता अपने हाथों में महसूस करता है। और एक पेज लोड के विपरीत, कोई स्पिनर नहीं है जो इसे स्वीकार्य बनाए — मानसिक मॉडल है "मैं अपनी आवाज़ से टाइप कर रहा हूँ", और टाइपिंग बफर नहीं होती।
क्रूर हिस्सा यह है कि यह प्रति-उच्चारण लागत है। आप इसे एक बार नहीं चुकाते। आप इसे हर एक डिक्टेशन पर चुकाते हैं, एक भारी उपयोगकर्ता के लिए दिन में पचास या सौ बार। 700 ms का जुर्माना जिसे आप पेज लोड पर कभी नोटिस नहीं करते, एक कार्यदिवस भर में, एक ऐसे टूल — जो प्रवाह में गायब हो जाता है — और एक ऐसे टूल — जिससे आप लड़ते हैं — के बीच का अंतर बन जाता है।
तो बजट तंग है, और बजट ही वह चीज़ है जिस पर पहले तर्क करना है।
राउंड-ट्रिप का गणित
आइए क्लाउड लेटेंसी बजट को ईमानदारी से बनाएँ, उन हिस्सों से जिन्हें आप टाल नहीं सकते।
एक क्लाउड STT अनुरोध को, कम से कम, यह सब करना पड़ता है इससे पहले कि एक भी शब्द वापस आए:
- डिवाइस पर ऑडियो को कैप्चर और एनकोड करना।
- एक कनेक्शन स्थापित या पुनः-उपयोग करना — ठंडा होने पर TLS हैंडशेक, या कम से कम एक जीवित रखे गए सॉकेट की लागत।
- ऑडियो बाइट्स को नेटवर्क पर अपलोड करना।
- प्रोवाइडर की ओर कतार में लगाना जब तक कोई वर्कर उसे न उठाए।
- उनके हार्डवेयर पर इन्फरेंस चलाना।
- परिणाम को सीरियलाइज़ और डाउनलोड करके आप तक वापस लाना।
यहाँ वह हिस्सा है जिसे लोग कम आँकते हैं: चरण 2, 3, 4, और 6 शुद्ध ओवरहेड हैं जिनका मॉडल कितना अच्छा है इससे कोई लेना-देना नहीं। ये कर हैं। और ये सबसे खराब वैरिएंस वाले चरण हैं।
नेटवर्क राउंड-ट्रिप समय अकेले शायद ही आपका दोस्त होता है। वही रीजन, गर्म कनेक्शन, अच्छा नेटवर्क, आप शायद कुछ-दस मिलीसेकंड में RTT देखें। पर "वही रीजन" वहाँ भारी काम कर रहा है। बैंकॉक में बैठा एक उपयोगकर्ता जो us-east एंडपॉइंट पर पहुँच रहा है, कुछ भी उपयोगी होने से पहले कुछ सौ मिलीसेकंड RTT चुकाता है, एक ही राउंड-ट्रिप पर — और एक ठंडा TLS हैंडशेक कई राउंड-ट्रिप है। भीड़भाड़ जोड़ें, एक डगमगाते होटल नेटवर्क को जोड़ें, पीक घंटों में प्रोवाइडर की कतार की गहराई जोड़ें, और आपका p99 आपके p50 से पूरी तरह अलग हो जाता है।
यहाँ वैचारिक बजट है। मैं जानबूझकर कठोर संख्याएँ ऐसे नहीं उद्धृत कर रहा जैसे वे आपके वातावरण में मापी गई हों — वे आपके नेटवर्क और आपके प्रोवाइडर पर निर्भर करती हैं — पर जो मायने रखता है वह आकार है:
Cloud STT latency = encode
+ connection_setup # 0 if warm, 1-3 RTT if cold
+ upload_time # audio_bytes / uplink_bandwidth
+ provider_queue_wait # the variance killer
+ inference_time
+ download_time
+ deserialize
On-device STT latency = capture_to_buffer
+ inference_time # on local Neural Engine / GPU
देखिए डिवाइस-पर वाले पथ में क्या नहीं है। कोई कनेक्शन सेटअप नहीं। कोई अपलोड नहीं। कोई कतार नहीं। कोई डाउनलोड नहीं। पूरा नेटवर्किंग कॉलम शून्य पर ढह जाता है। जो बचता है वह है कैप्चर प्लस इन्फरेंस, और Apple Silicon पर इन्फरेंस इतना तेज़ है कि वह पद जो क्लाउड बजट पर हावी होता है — नेटवर्क — समीकरण में होता ही नहीं।
इसीलिए तुलना "क्लाउड थोड़ा धीमा है" नहीं है। एक इंटरैक्टिव डिक्टेशन वर्कलोड के लिए यह संरचनात्मक रूप से अलग है। क्लाउड बजट पर उच्च-वैरिएंस वाले पद हावी हैं जिन्हें आप नियंत्रित नहीं करते। डिवाइस-पर बजट पर एक पद हावी है जिसे आप नियंत्रित करते हैं, उस हार्डवेयर पर चलता हुआ जिसे आप माप सकते हैं।
और मॉडल स्वयं कोई कमज़ोर नहीं है। जिस स्पीच मॉडल को हम डिफ़ॉल्ट रखते हैं — NVIDIA का Parakeet, NeMo परिवार से — M-सीरीज़ चिप्स पर रियल टाइम से कहीं ज़्यादा तेज़ चलता है, Neural Engine पर मैप होने पर रियल टाइम से लगभग दो ऑर्डर ऑफ मैग्नीट्यूड तेज़। जब ट्रांसक्रिप्शन उस भाषण से इतना तेज़ है जिसने उसे पैदा किया, तो आपके बजट में इन्फरेंस पद उस ऑडियो के सापेक्ष छोटा हो जाता है जिसके बोले जाने का आपको वैसे भी इंतज़ार करना ही पड़ा। बॉटलनेक मॉडल नहीं रहता और भौतिकी बन जाता है: आप एक वाक्य को उस व्यक्ति के उसे कहना खत्म करने से पहले ट्रांसक्राइब नहीं कर सकते।
प्राइवेसी एक साइड इफेक्ट थी, फिर वही मुख्य बात बन गई
हमने लेटेंसी के लिए डिवाइस चुना। फिर हमने गौर किया कि हमने अनजाने में क्या खरीद लिया।
अगर ऑडियो मशीन से कभी बाहर नहीं जाता, तो लीक करने, सम्मन करने, सेंध लगाने, रखे रहने, या ट्रेन करने के लिए कोई ऑडियो ही नहीं है। यह कोई प्राइवेसी पॉलिसी नहीं है — एक पॉलिसी यह वादा है कि एक सर्वर कुछ और कर सकता है। यह एक प्राइवेसी आर्किटेक्चर है: डेटा के पास भौतिक रूप से जाने को कोई और जगह ही नहीं है। किसी के इंफ्रास्ट्रक्चर पर आपकी आवाज़ की रिकॉर्डिंग की कोई बाल्टी नहीं है क्योंकि रिकॉर्डिंग माइक्रोफ़ोन से कुछ सेंटीमीटर दूर प्रोसेस होकर फेंक दी गई।
एक डिक्टेशन टूल के लिए यह पहली नज़र में दिखने से ज़्यादा मायने रखता है, क्योंकि लोग क्या डिक्टेट करते हैं। एक दिन अपने उपयोग को देखिए। आप वे पासवर्ड डिक्टेट करते हैं जिन्हें आप रीसेट कर रहे हैं। आप NDA के तहत सिस्टम का आर्किटेक्चर डिक्टेट करते हैं। आप एक वकील, एक डॉक्टर, अधिग्रहण के बीच एक सह-संस्थापक को भेजे जाने वाले संदेश की सामग्री डिक्टेट करते हैं। एक डेवलपर की मशीन का माइक्रोफ़ोन उनके जीवन की कुछ सबसे संवेदनशील कच्ची सामग्री की ओर इशारा कर रहा है, और ज़्यादातर वॉइस टूल का डिफ़ॉल्ट रुख यह सब किसी तीसरे पक्ष को प्रोसेसिंग के लिए स्ट्रीम करना है।
एक कम्प्लायंस आयाम भी है, और यह अमूर्त नहीं है। "ऑडियो कभी डिवाइस से बाहर नहीं जाता" एक ऐसा वाक्य है जो बहुत सारे सुरक्षा-समीक्षा टिकट बंद कर देता है। बातचीत करने के लिए कोई डेटा-प्रोसेसिंग समझौता नहीं, ऑडिट करने के लिए कोई सब-प्रोसेसर सूची नहीं, कोई सीमा-पार डेटा-ट्रांसफर का सवाल नहीं, वॉइस डेटा के लिए कोई ब्रीच-नोटिफिकेशन सतह नहीं क्योंकि किसी भी सर्वर पर सेंध लगाने के लिए कोई वॉइस डेटा है ही नहीं। एक नियंत्रित वातावरण में टूल भेजने की कोशिश कर रही टीम के लिए, "यह स्थानीय रूप से चलता है" अक्सर मंज़ूर और अनिश्चितकाल-समीक्षाधीन के बीच का अंतर होता है।
ईमानदार संस्करण: हमने प्राइवेसी को हेडलाइन नहीं बनाया होता अगर लेटेंसी का गणित उसी दिशा में इशारा न करता। पर इसने किया, और एक बार जब आप तय कर लेते हैं कि ऑडियो प्रदर्शन कारणों से घर में रहता है, तो एक क्लाउड फॉलबैक भेजने से इनकार करना जो उसे चुपके से पलट दे, आसान, सही निर्णय है।
दो मॉडल, एक पाइपलाइन, दोनों स्थानीय
स्पीच-टू-टेक्स्ट आपको शब्द देता है। शब्द वह नहीं हैं जो उपयोगकर्ता चाहता है।
उसने जो कहा वह था "अं तो बेसिकली हमें जैसे, रीट्राई लॉजिक को उस उस वर्कर में मूव करना है, पता है ना, वही जो अं वेबहुक्स हैंडल करता है"। वह जो पेस्ट होते देखना चाहता है वह है "रीट्राई लॉजिक को उस वर्कर में मूव करो जो वेबहुक्स हैंडल करता है"। भराव शब्द हटाना, फॉल्स स्टार्ट ठीक करना, और परिणाम को आकार देना ट्रांसक्रिप्शन से अलग काम है, और यह एक भाषा का काम है, भाषण का नहीं। तो पाइपलाइन के दो चरण हैं, और दिलचस्प आर्किटेक्चरल निर्णय दोनों को डिवाइस पर रखना था।
वैचारिक रूप से यह एक हैंड-ऑफ है:
audio ──▶ [ speech model ] ──▶ raw transcript
(Parakeet) "uh so basically we need to..."
│
▼
[ small local LLM ] ──▶ clean text
(Gemma 3 4B, MLX) "Move the retry logic..."
│
┌─────────────┼─────────────┐
▼ ▼ ▼
cleanup translation summary
चरण एक एक विशेषीकृत स्पीच मॉडल है: छोटा, तेज़, एकल-उद्देश्यीय, एक ही चीज़ के लिए ऑप्टिमाइज़्ड। चरण दो एक छोटा सामान्य-उद्देश्यीय LLM है — हम डिफ़ॉल्ट रूप से Gemma 3 4B का उपयोग करते हैं (Qwen 3, LLaMA 3.2 और Phi-3.5 भी चुने जा सकते हैं), जो Apple के MLX फ्रेमवर्क के ज़रिए GPU पर चलता है — भाषाई सफाई करता हुआ, और वही मॉडल, एक अलग निर्देश के साथ, लाइव अनुवाद और मीटिंग सारांश संभालता है। एक मॉडल, तीन काम, तीन अलग बाइनरी भेजने के बजाय प्रॉम्प्ट से बदले गए।
इस दो-मॉडल विभाजन के सही आकार होने का कारण: हर चरण अपने काम में अच्छा हो सकता है। आप नहीं चाहते कि आपका स्पीच मॉडल गद्य फिर से लिखने की भी कोशिश करे, और आप नहीं चाहते कि एक सामान्य LLM ध्वनिक मॉडलिंग करने की कोशिश करे। विशेषीकृत-फिर-सामान्य एक साफ़ विभाजन है, और यह हर मॉडल को इतना छोटा रखता है कि वह मेमोरी में फिट हो और तेज़ चले। एक विशाल एंड-टू-एंड मॉडल जो दोनों करे, धीमा, ज़्यादा भूखा और तर्क करने में कठिन होगा — और आप क्लीनअप मॉडल को रिकग्नाइज़र से स्वतंत्र रूप से बदलने की क्षमता खो देंगे।
चरण दो को स्थानीय रखना वह हिस्सा है जिसे छोड़ देने का प्रलोभन होता है। स्पीच मॉडल को लेटेंसी के लिए स्थानीय होना ही है; निश्चित रूप से क्लीनअप तो एक बड़े क्लाउड मॉडल को एक त्वरित API कॉल हो सकती है? हो सकती है — और तब आपने उस चरण के लिए पूरी प्राइवेसी संपत्ति फेंक दी जो उपयोगकर्ता के शब्दों का सबसे सुपाठ्य संस्करण संभालता है। कच्चा ट्रांसक्रिप्ट गंदा है; साफ़ किया हुआ टेक्स्ट स्पष्ट, उद्धरणीय, पूरी तरह बना हुआ विचार है। वही ठीक वह चीज़ है जिसे आप सबसे कम सर्वर पर भेजना चाहते हैं। अगर चरण दो क्लाउड में जाता है, तो चरण एक का स्थानीय होना आपको कुछ नहीं देता। तो दोनों घर में रहते हैं।
जहाँ डिवाइस-पर चलाना दुखने लगता है
मैं झूठ बोलूँगा अगर इसे मुफ्त के रूप में बेचूँ। डिवाइस-पर इन्फरेंस की असली लागतें हैं, और इसके विपरीत दिखावा करना ही वह तरीका है जिससे आप कुछ ऐसा भेजते हैं जो डेमो में सुंदर और मैदान में दयनीय हो। यहाँ यह काटता है।
मॉडल का आकार और डाउनलोड। स्थानीय मॉडल फ़ाइलें हैं, और अच्छे स्थानीय मॉडल बड़ी फ़ाइलें हैं। पहले लॉन्च को उन्हें लाना पड़ता है — स्पीच मॉडल के कंपाइल किए गए वेट्स के लिए कई-गीगाबाइट डाउनलोड, और LLM के लिए लगभग उतना ही बड़ा डाउनलोड — और वह एक पहले-रन का अनुभव है जिसके इर्द-गिर्द आपको डिज़ाइन करना पड़ता है, क्योंकि "अपना पहला शब्द कह पाने से पहले 3 GB डाउनलोड करना" एक क्रूर ऑनबोर्डिंग है अगर आप इसे बुरी तरह संभालें। क्लाउड की ओर कोई समकक्ष नहीं है; उनका मॉडल उनके हार्डवेयर पर पहले से गर्म है।
मेमोरी का दबाव। दोनों मॉडल, लोड और रेज़िडेंट, RAM खर्च करते हैं। 64 GB मशीन पर, किसे परवाह। एक बेस-मॉडल लैपटॉप पर जो नब्बे टैब वाला एक ब्राउज़र, एक IDE, और तीन Electron ऐप भी चला रहा है, अब आप उस सब चीज़ के साथ मेमोरी के लिए प्रतिस्पर्धा कर रहे हैं जिसके लिए उपयोगकर्ता ने असल में लैपटॉप खोला था। आपको इस बारे में सावधान रहना होगा कि मॉडल कब लोड होते हैं, कब रिलीज़ होते हैं, और आप डिफ़ॉल्ट रूप से कितना बड़ा मॉडल रखने को तैयार हैं।
आप हार्डवेयर की निचली सीमा विरासत में पाते हैं। क्लाउड STT एक फ्लैगशिप फ़ोन और एक पाँच साल पुराने लैपटॉप के लिए उन्हीं डेटासेंटर GPU पर चलता है। डिवाइस पर, आपका प्रदर्शन ही उपयोगकर्ता का सिलिकॉन है। हम Apple Silicon की माँग करते हैं ठीक इसलिए क्योंकि Neural Engine और यूनिफाइड मेमोरी ही वह हैं जो लेटेंसी के गणित को काम करवाते हैं; पुराने या कमज़ोर हार्डवेयर पर पूरा तर्क नरम पड़ जाता है। आप हार्डवेयर की एक निचली सीमा पर दाँव लगा रहे हैं, और आप उसके नीचे वाले हर किसी को काट रहे हैं।
क्वांटाइज़ेशन दाँतों वाला एक नॉब है। मॉडल को फिट करने और तेज़ चलाने के लिए आप उन्हें क्वांटाइज़ करते हैं — वेट्स को कम बिट्स में दर्शाते हैं, थोड़ी सटीकता को बहुत सारी गति और मेमोरी से बदलते हैं। अच्छे से किया जाए तो लगभग मुफ्त है। बहुत दूर तक धकेला जाए तो हज़ार छोटी ग़लतियों से मौत है: यहाँ ज़रा-सा ग़लत ट्रांसक्रिप्शन, वहाँ सूक्ष्म रूप से बिगड़ा क्लीनअप। क्वांटाइज़ेशन स्तर चुनना सटीकता-बनाम-संसाधन वक्र पर एक बिंदु चुनना है, और यह एक असली इंजीनियरिंग निर्णय है, न कि एक चेकबॉक्स।
आप मॉडल भेजते हैं, इसलिए अपडेट आपके अधीन हैं। क्लाउड प्रोवाइडर अपना मॉडल बेहतर करता है और हर उपयोगकर्ता को यह चुपचाप मिल जाता है। आपका स्थानीय मॉडल तब बेहतर होता है जब आप एक ऐप अपडेट भेजते हैं और उपयोगकर्ता नए वेट्स डाउनलोड करता है। आपने "किसी और के निरंतर सुधार" को "नियंत्रण और पूर्वानुमेयता" से बदल दिया है, जो एक ऐसे टूल के लिए सही सौदा है जिसे हवाई जहाज़ में ऑफ़लाइन समान रूप से व्यवहार करना है — पर यह एक सौदा है।
इनमें से कोई भी एक इंटरैक्टिव डिक्टेशन टूल के लिए डिवाइस-पर वाले दृष्टिकोण को नहीं डुबोता। लेटेंसी और प्राइवेसी के फायदे बहुत बड़े हैं। पर इनमें से हर एक एक कारण है कि एक अलग फीचर सही ढंग से क्लाउड चुन सकता है।
एक निर्णय ढाँचा जिसे आप असल में उपयोग कर सकते हैं
तो यह है जो अपने ऑडियो फीचर तक ले जाना है। सवाल कभी "क्या डिवाइस बेहतर है" नहीं होता। यह है "मेरे वर्कलोड को लागतों का कौन-सा कॉलम परवाह करता है"। अपने फीचर को इसके सामने मैप करें:
| संकेत | डिवाइस की ओर झुकें | क्लाउड की ओर झुकें |
|---|---|---|
| इंटरैक्शन मॉडल | रियल-टाइम, इंसान परिणाम का इंतज़ार कर रहा | बैच, बैकग्राउंड में प्रोसेस |
| लेटेंसी सहनशीलता | टेल लेटेंसी महसूस होती है; p99 मायने रखता है | सेकंड ठीक हैं; कोई नहीं देख रहा |
| डेटा संवेदनशीलता | ऑडियो निजी, नियंत्रित, या NDA के तहत | सार्वजनिक या पहले से साझा सामग्री |
| ऑफ़लाइन आवश्यकता | हवाई जहाज़ / खराब नेटवर्क में चलना चाहिए | हमेशा-ऑनलाइन एक सुरक्षित धारणा है |
| प्रति-उपयोग बारंबारता | दिन में कई बार, प्रति उपयोगकर्ता | कभी-कभार |
| लक्ष्य हार्डवेयर | आप एक आधुनिक हार्डवेयर निचली सीमा माँग सकते हैं | हर जगह चलना चाहिए, कमज़ोर डिवाइस सहित |
| मॉडल ताज़गी | पूर्वानुमेय, समान, ऑफ़लाइन व्यवहार जीतता है | निरंतर मौन सुधार जीतता है |
तालिका को ऊपर से नीचे पढ़ें। अगर आपके जवाब बाएँ कॉलम में गुच्छित होते हैं — इंटरैक्टिव, लेटेंसी-संवेदनशील, निजी, बारंबार, सक्षम हार्डवेयर पर — तो आपके पास डिक्टेशन-आकार की समस्या है, और डिवाइस बहुत संभवतः सही आर्किटेक्चर है भले ही यह ज़्यादा काम हो। अगर वे दाएँ गुच्छित होते हैं — बैच, लेटेंसी-सहनशील, गैर-संवेदनशील, कभी-कभार, हर-जगह-चलना-चाहिए — तो क्लाउड आप पर एहसान कर रहा है और स्थानीय जाना स्व-आरोपित दर्द है।
जो ग़लती मैं सबसे अधिक देखता हूँ वह है इसे पूरे उत्पाद के लिए एक-बारगी वैश्विक निर्णय मानना। यह नहीं है। यह प्रति-फीचर है। एक टूल बिल्कुल लेटेंसी के लिए इंटरैक्टिव डिक्टेशन डिवाइस पर चला सकता है और फिर भी एक दो-घंटे की संग्रहीत रिकॉर्डिंग रात भर एक क्लाउड बैच जॉब को सौंप सकता है, क्योंकि वे दो वर्कलोड विपरीत कॉलम में बैठते हैं। हम Vext में सब कुछ डिफ़ॉल्ट रूप से स्थानीय रखते हैं क्योंकि हमारे वर्कलोड संयोग से बाईं ओर रहते हैं — पर ढाँचा, निष्कर्ष नहीं, वही हिस्सा है जो चुराने लायक है।
जो मैं एक साल पहले अपने आप से कहता
अगर मैं एक नोट उस अपने संस्करण को वापस भेज पाता जो फ्रेंडली क्लाउड STT SDK को घूर रहा था: फ्रेंडली SDK आपको इन्फरेंस बेच रहा है और कर छिपा रहा है। मॉडल की गुणवत्ता शायद ही कभी समस्या होती है। नेटवर्क कॉलम — सेटअप, अपलोड, कतार, डाउनलोड, और वैरिएंस जो चारों में रहती है — वही समस्या है, और यह एक ऐसी समस्या है जिसे आप हर एक उच्चारण पर, हमेशा के लिए, ठीक उस पल चुकाते हैं जब एक इंसान अपने हाथों के साथ आपके सॉफ़्टवेयर का इंतज़ार कर रहा होता है।
डिवाइस उस कॉलम को थोक में हटा देता है और साइड इफेक्ट के रूप में आपको एक प्राइवेसी आर्किटेक्चर सौंप देता है। यह आपको एक बड़े डाउनलोड, कुछ मेमोरी अनुशासन, एक हार्डवेयर निचली सीमा, और एक क्वांटाइज़ेशन निर्णय की लागत देता है। एक इंटरैक्टिव, संवेदनशील, उच्च-बारंबारता वर्कलोड के लिए, यह एक ऐसा सौदा है जो मैं हर बार करूँगा — और किया।
SDK की ओर हाथ बढ़ाने से पहले अपने फीचर का गणित कर लें। टिशू पेपर पुनर्लेखन से सस्ता है।
— Don
Vext Muvon का क्लोज़्ड-सोर्स, डिवाइस-पर चलने वाला वॉइस-टू-टेक्स्ट ऐप है Apple Silicon के लिए — स्पीच रिकग्निशन और क्लीनअप LLM दोनों स्थानीय रूप से चलते हैं, और आपका ऑडियो कभी Mac से बाहर नहीं जाता। Muvon की डेवलपर टूलिंग, जिसमें Octomind शामिल है, ओपन सोर्स है। यहाँ वर्णित आर्किटेक्चर और समझौते सामान्य इंजीनियरिंग पैटर्न हैं, Vext की अंदरूनी बातों का दौरा नहीं।
