- 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
अभी कोई टिप्पणी नहीं है.