500ms से कम लेटेंसी वाला voice agent खुद कैसे बनाया गया

• voice-आधारित AI सिस्टम में लेटेंसी को 400ms स्तर तक घटाने वाले self-built voice agent के विकास का परिचय
• STT, LLM, TTS को real-time pipeline से जोड़कर मौजूदा commercial platform (Vapi आदि) की तुलना में 2 गुना तेज response speed हासिल की गई
• Deepgram Flux से utterance detection और turn-taking संभाला गया, और Groq ke llama-3.3-70b मॉडल का उपयोग करके first token generation time को काफी कम किया गया
• geographic deployment और network optimization के जरिए EU region deployment में लेटेंसी को आधे से भी कम किया गया
• voice agent का मूल real-time orchestration और pipeline design है, और इसे सीधे implement करने पर performance bottleneck को स्पष्ट रूप से समझा जा सकता है

---

voice agent बनाने की पृष्ठभूमि

• consumer goods की एक बड़ी कंपनी के लिए voice agent prototype development के अनुभव के आधार पर, commercial platform की complexity को सीधे संभालने के लिए self-build का प्रयास किया गया
• ElevenLabs और Vapi जैसे platform सुविधाजनक हैं, लेकिन इनके internal working को समझना कठिन है और सूक्ष्म लेटेंसी control संभव नहीं है
• लक्ष्य था Vapi स्तर का performance खुद implement करना, और इसे एक दिन तथा लगभग 100 डॉलर के API credit में हासिल किया गया

voice agent की complexity

• text-based chatbot के विपरीत, voice में real-time turn-taking की ज़रूरत होती है
• जैसे ही user बोलना शुरू करे, सिस्टम को तुरंत अपनी आवाज़ रोकनी चाहिए, और user के रुकते ही तेज़ी से response शुरू करना चाहिए
• केवल simple voice detection (VAD) से utterance end को सटीक रूप से पहचानना कठिन होता है, और लेटेंसी, overlapping speech, और अनावश्यक silence पैदा होते हैं

पहला implementation: VAD-आधारित test

• FastAPI server और Twilio WebSocket का उपयोग करके μ-law audio stream receive की गई
• Silero VAD से speech presence का पता लगाया गया, और utterance समाप्त होने पर पहले से रिकॉर्ड की गई WAV file चलाई गई
• यह simple था, लेकिन तुरंत responsiveness और natural conversation flow की पुष्टि हुई
• इसी चरण में लेटेंसी की निचली सीमा मापने का आधार मिला

दूसरा implementation: Deepgram Flux और real-time pipeline

• Deepgram Flux को अपनाकर streaming transcription और turn detection को एकीकृत किया गया
• Flux जब utterance end detect करता है, तब अगला क्रम चलता है
  • transcription result और conversation history को LLM में भेजना
  • first token बनते ही उसे TTS(WebSocket) में stream करना
  • generated audio को Twilio पर real time में भेजना
• TTS connection को पहले से warm pool में बनाए रखकर लगभग 300ms की लेटेंसी बचाई गई
• user के बोलना शुरू करते ही LLM·TTS·audio transmission को तुरंत cancel करके natural interruption handling लागू की गई

लेटेंसी मापन और regional deployment

• तुर्की में local execution के दौरान औसतन 1.6~1.7 सेकंड लेटेंसी हुई
• Railway EU region में deploy करके Twilio·Deepgram·ElevenLabs को भी EU region से match किया गया, तो
  • औसत 690ms (कुल 790ms) तक घट गया, जो Vapi की तुलना में लगभग 50ms तेज़ था
• लेटेंसी कम होने से conversation responsiveness में बड़ा सुधार हुआ और interruption handling भी अधिक smooth हो गई

मॉडल चयन और performance improvement

• शुरुआत में gpt-4o-mini का उपयोग किया गया, बाद में Groq llama-3.3-70b से बदला गया
• test result में Groq मॉडल का first token generation time (TTFT) OpenAI की तुलना में अधिकतम 3 गुना तेज़ था
• औसतन 400ms से कम end-to-end लेटेंसी हासिल हुई, और पहला audio 500ms के भीतर पहुँच गया
• इस स्तर पर agent इंसान से भी तेज़ respond करता हुआ महसूस होता है

मुख्य तकनीकी सीख

• लेटेंसी optimization में utterance end से first voice output तक पूरे path को manage करना सबसे महत्वपूर्ण है
• TTFT कुल लेटेंसी का आधे से अधिक हिस्सा लेता है, इसलिए low-latency मॉडल चुनना महत्वपूर्ण है
• STT→LLM→TTS को sequentially process करने के बजाय streaming pipeline बनानी चाहिए
• speech interruption पर सभी components को तुरंत cancel करना natural conversation बनाए रखने के लिए ज़रूरी है
• services के बीच geographic proximity का लेटेंसी पर निर्णायक प्रभाव पड़ता है

commercial platform से तुलना

• Vapi·ElevenLabs अब भी अधिकांश teams के लिए उपयोगी हैं, क्योंकि वे API, stability, observability जैसी अतिरिक्त सुविधाएँ देते हैं
• लेकिन खुद बनाने से वास्तविक bottleneck और parameters का अर्थ समझा जा सकता है, और
  specific requirements के अनुसार custom orchestration संभव हो जाता है
• voice system आखिरकार orchestration की समस्या है, और इसकी संरचना स्पष्ट हो तो यह हल की जा सकने वाली engineering problem है

source code

• पूरा implementation GitHub पर उपलब्ध: github.com/NickTikhonov/shuo

[GN⁺]

Hacker News की राय

• यह लेख वाकई दिलचस्प है। पहले Amazon Alexa टीम ने इस समस्या पर शोध किया था और इससे जुड़े पेटेंट भी हैं
  बातचीत के दौरान इंसानों के बीच औसत देरी 0ms होती है, यानी सामने वाले के बोलना खत्म करने से पहले ही अगला व्यक्ति बोलना शुरू कर देता है। ऐसा इसलिए क्योंकि दिमाग सामने वाले की बात का अनुमान लगाते हुए साथ-साथ जवाब भी तैयार करता है
  इसके उलट, लोग voice assistant से देरी की उम्मीद करते हैं। इसके दो कारण हैं — यह धारणा कि कंप्यूटर को ‘सोचना’ पड़ता है, और मोबाइल कॉल की latency
  Alexa के जवाबों में 500ms से कम latency लगभग कभी नहीं होती। पहले 300ms की चुप्पी को ही ‘turn समाप्त’ मान लिया जाता था, लेकिन असली कुंजी semantic end-of-turn है
  अब compute resources काफी हैं, इसलिए यह जानने की उत्सुकता है कि यह हिस्सा कितना आगे बढ़ा होगा। भौगोलिक नज़दीकी में processing (edge computing) एक बड़ा turning point था

  • मोबाइल कॉल की latency खासकर ज़्यादा उम्र के लोगों के लिए तनावपूर्ण होती है। landline के ज़माने में लगभग कोई delay नहीं होता था, इसलिए उन्हें बस असहजता महसूस होती है, भले यह समझ न आए कि क्यों
  • मैं दूसरी बात से सहमत नहीं हूँ। voice assistant की latency अब भी बहुत धीमी है। इंतज़ार करना पड़ता है कि “क्या यह चला भी?”। मुझे नहीं लगता कि मोबाइल का delay दूसरे devices के लिए भी अपेक्षित माना जाता है
  • turn खत्म होने का संकेत 300ms की चुप्पी से लेना बहुत असुविधाजनक था। इसलिए जानबूझकर “उम्…” जैसे filler डालने पड़ते थे, और अंत में मैंने voice chat ही छोड़ दी
  • यह दिलचस्प जानकारी साझा करने के लिए धन्यवाद। लेकिन यह जानने की उत्सुकता है कि Amazon/Google/Apple ने पिछले कुछ वर्षों में voice assistant innovation क्यों रोक दी। वे अपने मौजूदा user base के सहारे भी बाज़ार को फिर से परिभाषित कर सकते थे
  • लगता है बात उस संरचना की हो रही है जिसमें LLM उपयोगकर्ता की बात को predictively आगे बढ़ाकर पकड़ता है। अगर असल समाप्ति अनुमान से मेल खा जाए, तो बिना delay के तुरंत जवाब दिया जा सकता है। कई candidate threads को साथ-साथ predict करके pruning करना भी संभव लगता है

• मेरे हिसाब से speech आखिरकार turn-taking की समस्या है। इसमें एक आसान सुधार है जिस पर किसी ने हाथ नहीं लगाया — filler और tempo control
  अगर LLM थोड़ी चुप्पी महसूस करे, तो असली जवाब बनते समय “उम्”, “हाँ सही” जैसे context वाले fillers डाल सकता है। इससे बातचीत कहीं ज़्यादा natural लगती है

  • पूरी तरह सहमत। एक छोटा low-latency model पहले छोटा जवाब बना दे, और TTS output cache करके रखा जाए, तो delay को बेहद कम किया जा सकता है। “एक क्षण, मैं सोच रहा हूँ” जैसे वाक्य millisecond स्तर पर जवाब दे सकते हैं
  • लेकिन यह ‘आसान सुधार’ न भी हो सकता है। robot जैसे सिस्टम को मानवीय बनाना मुश्किल है, और सिर्फ sentence structure बदलने से वह उल्टा और mechanical लगने लगता है। मैंने खुद कोशिश की थी, लेकिन असफल रहा
  • इस संदर्भ में LiveKit का “Prompting Voice Agents to Sound More Realistic” ब्लॉग दिलचस्प है
  • अगर सिस्टम उपयोगकर्ता के बोलना खत्म करने से पहले ही जवाब का अनुमान लगा सके, तो वह कहीं ज़्यादा natural होगा
  • जब turn समाप्ति का गलत पता चले, तब phoneme-स्तर filler के साथ स्वाभाविक रूप से जोड़ते हुए आगे बढ़ना भी संभव है। उल्टा अगर बहुत देर से पता चले, तो पहला syllable पहले से तय करके prompt में डाल सकते हैं ताकि जवाब उसी से शुरू हो

• शानदार लेख। OpenAI Responses client ने हाल ही में websocket अपनाया है, जिससे latency कम हुई है।
  एक और तरीका है बहुत छोटे LLM को लोकल मशीन पर सीधे चलाना। मैंने ova project के ज़रिये पूरी तरह local pipeline बनाई, और streaming के बिना भी 1 सेकंड से कम round-trip time हासिल किया

  • बढ़िया project है, मैंने इसे bookmark कर लिया। बाद में अनुभव साझा करते हुए इस पर बात करना चाहूँगा

• लेख की streaming pipeline structure और हर चरण की latency analysis बहुत उपयोगी थी। turn-taking loop को खुद implement करना खास तौर पर प्रभावशाली लगा
  हालाँकि “Vapi से 2x तेज़” वाली तुलना थोड़ी भ्रामक है। Vapi tool calling, webhook, multi-tenant routing जैसी कई अतिरिक्त चीज़ें भी करता है
  इस लेख की असली अहमियत ‘खुद बनाए orchestration loop से मिली insights’ में है। अगर इसे बस “खुद बनाकर सीखी गई बातें” के रूप में समेटा जाता, तो यह एकदम परफेक्ट होता

• मैं भी Twilio + Deepgram + ElevenLabs + LLM API के संयोजन से commercial voice agent बना रहा हूँ
  मुख्य मुद्दा STT accuracy नहीं, बल्कि turn-taking UX था। fixed silence threshold की जगह semantic end-of-turn अपनाते ही अनुभव पूरी तरह बदल गया
  inter-region latency भी महत्वपूर्ण है। भारत से US server तक connect करने पर केवल Twilio edge hop से ही 150~250ms अतिरिक्त जुड़ जाते हैं। मैंने regional routing से इसमें सुधार किया
  Barge-in (बीच में टोकना) को संभालना भी जटिल है। सिर्फ LLM और TTS रोकना काफी नहीं, पहले से चल चुके automation workflow को rollback भी करना पड़ता है। पहले एक bug था जिसमें booking confirmation के बीच में टोकने पर booking सचमुच पूरी हो जाती थी

• Soniox Real-time (60 भाषाओं का समर्थन) endpoint detection को model स्तर पर संभालता है। यह VAD से कहीं ज़्यादा सटीक है
  तकनीकी दस्तावेज़, Daily का benchmark, demo page देखे जा सकते हैं
  मैं पहले Soniox में काम करता था। यह real-time endpoint detection लागू करने वाली पहली services में से एक थी

  • मूल लेख में Deepgram Flux इस्तेमाल होने की बात है। यह भी endpointing को support करता है और VAD से ऊपर की abstraction layer है
  • मैं अभी Soniox इस्तेमाल कर रहा हूँ, इसलिए जानना चाहता हूँ कि अंदर काम करने का अनुभव कैसा था। competitors की तुलना में कम कीमत पर SoTA performance देने का राज़ क्या है

• व्यक्तिगत रूप से मुझे लगता है कि STT → LLM → TTS संरचना की सीमाएँ हैं। भविष्य end-to-end speech model का है
  मैंने 2 साल पहले Chirpy demo बनाया था, लेकिन उसे वास्तव में उपयोगी स्तर तक ले जाने के लिए dedicated training चाहिए थी। side project के तौर पर यह संभव नहीं था

  • उस नज़रिए से NVIDIA का PersonaPlex research दिलचस्प लगेगा: https://research.nvidia.com/labs/adlr/personaplex/
  • मैं पिछले कुछ वर्षों से सिर्फ voice agents पर काम कर रहा हूँ। cascading model अभी कुछ समय तक गायब नहीं होने वाला।
    enterprise ग्राहक auditability और reliability को प्राथमिकता देते हैं। healthcare और finance जैसे regulated industries में STT और LLM output को अलग-अलग validate करना पड़ता है
    इसके विपरीत end-to-end speech model interviews या surveys जैसे narrative उपयोग के लिए ज़्यादा उपयुक्त हैं। असली ग्राहक cutting-edge model से ज़्यादा engineering maturity चाहते हैं
  • बुनियादी तौर पर मॉडल में “कब मेरी बारी है यह अनुमान लगाने की क्षमता” अंतर्निहित होनी चाहिए। Moshi का full-duplex mode उस दिशा को अच्छी तरह दिखाता है: https://arxiv.org/abs/2410.00037
  • cascading structure का फायदा यह है कि हर चरण पर नया model बदला जा सकता है। STT, TTS और LLM की प्रगति की गति अलग-अलग है, इसलिए इसमें लचीलापन बहुत है
  • नवीनतम speech tokenizer अब लगभग 12Hz प्रति सेकंड तक पहुँच चुके हैं। ये सामान्य LLM की तुलना में कहीं अधिक tokens इस्तेमाल करते हैं

• यह तरीका game engine netcode के शुरुआती विकास की याद दिलाता है। latency model की नहीं, बल्कि orchestration की समस्या है
  Carmack के 2013 VR paper में भी यही तर्क था — millisecond स्तर की bottleneck ढूँढने के लिए पूरी pipeline को trace करना पड़ता है
  Latency Mitigation Strategies देखने लायक है। TTS websocket pool पहले से खोलकर 300ms बचाने वाला उदाहरण इसका परफेक्ट case है

• मैं open source speech recognition app Handy का ज़िक्र करना चाहूँगा। यह पूरी तरह offline काम करता है और विस्तार योग्य है
  मैं इसे रोज़ Claude के साथ इस्तेमाल करता हूँ, और यह macOS की default dictation से कहीं बेहतर काम करता है

• लेख अच्छा है, लेकिन सिर्फ turn-taking से बातचीत को समझाना बहुत सरलीकृत है
  वास्तविक बातचीत में overlapping speech, acknowledgement signals, सुनते रहने का संकेत देने वाले phatic messages, और यहाँ तक कि सामने वाले की बात को पूरा कर देने वाला सहयोगी व्यवहार भी होता है
  इन तत्वों को साधारण turn-taking model से ठीक तरह व्यक्त नहीं किया जा सकता, और model को इन्हें उत्पन्न और समझना आना चाहिए