वॉइस एजेंट लेटेंसी ऑप्टिमाइज़ेशन: स्टेप-बाय-स्टेप गाइड

किसी वॉइस एजेंट की प्रतिक्रिया क्षमता इस कुल देरी से तय होती है कि यूज़र के बोलना खत्म करने और एजेंट के जवाब देना शुरू करने के बीच कितना समय लगता है। यह देरी शायद ही कभी किसी एक धीमे घटक की वजह से होती है। यह कई स्वतंत्र चरणों में जमा होती है, जिनमें से हर एक कुछ दर्जन या सैकड़ों मिलीसेकंड जोड़ता है। इसे कम करने के लिए यह जानना ज़रूरी है कि हर चरण कितना समय लेता है।

वॉइस एजेंट लेटेंसी ऑप्टिमाइज़ेशन का मतलब यह पता लगाना है कि समय कहाँ लग रहा है और उसे चरण-दर-चरण वापस पाना।

यह लेख लेटेंसी के वैचारिक अवलोकन का पूरक है। जहाँ वह पेज समझाता है कि लेटेंसी क्या है, यह लेख आर्किटेक्चर और मापन पर केंद्रित है। इससे आपको एक ऐसा लेटेंसी बजट मिलेगा जिसके आधार पर आप माप कर सकें, साथ ही करने योग्य ठोस कदम भी।

सारांश

• टाइम-टू-फर्स्ट-ऑडियो पूरे पाइपलाइन को दर्शाता है, किसी एक मॉडल के इन्फ़रेंस समय को नहीं।
• LLM का टाइम-टू-फर्स्ट-टोकन और एंडपॉइंटिंग, दो सबसे बड़े घटक हैं।
• चरणों को क्रम में चलाने के बजाय उन्हें ओवरलैप करने से बजट का बड़ा हिस्सा वापस मिलता है।
• स्ट्रीमिंग, कोडेक का चुनाव और प्लेयर बफर ट्यूनिंग—हर एक मापे जा सकने वाले मिलीसेकंड कम करता है।
• आपको अपने डिप्लॉयमेंट के आधार पर हर क्षेत्र में मापना चाहिए और P50 व P95 रिपोर्ट करने चाहिए।

वॉइस एजेंट लेटेंसी बजट तय करना

लेटेंसी बजट पूरे पाइपलाइन के लिए तय किया गया कुल टाइम-टू-फर्स्ट-ऑडियो लक्ष्य है। इसमें हर चरण को एक समय-सीमा दी जाती है और इनका कुल आपके लक्ष्य से कम होना चाहिए। इसे तय करना पहला कदम है और यहीं लेटेंसी से जुड़ा काम अक्सर गलत हो जाता है, क्योंकि इंजीनियर दो ऐसे आंकड़ों को एक समझ सकते हैं जो दिखने में समान लेकिन अर्थ में अलग होते हैं।

पहला है मॉडल इन्फ़रेंस लेटेंसी: मॉडल द्वारा आउटपुट जनरेट करने में लगने वाला समय। हमारे Flash मॉडल्स के लिए, नेटवर्क और एप्लिकेशन ओवरहेड को छोड़कर, सामान्य छोटे इनपुट पर यह लगभग 75 ms है। यह एक आंतरिक आंकड़ा है और एक मॉडल की दूसरे से तुलना करने में उपयोगी है। लेकिन यूज़र को यही समय अनुभव नहीं होता।

यूज़र के नज़रिए से आपको टाइम-टू-फर्स्ट-ऑडियो (TTFA) पर ध्यान देना चाहिए: यूज़र के बोलना बंद करने से लेकर एजेंट के जवाब का पहला सैंपल सुनाई देने तक का समय। TTFA हमेशा किसी एक मॉडल की इन्फ़रेंस लेटेंसी से अधिक होता है, क्योंकि इसमें पूरी पाइपलाइन शामिल होती है।

कैस्केडेड वॉइस एजेंट पाँच चरणों की एक चेन होता है:

• कैप्चर (माइक) -> STT -> LLM -> TTS -> प्लेबैक

ऑडियो को माइक्रोफ़ोन से कैप्चर किया जाता है, टेक्स्ट में ट्रांसक्राइब किया जाता है, लैंग्वेज मॉडल को भेजा जाता है, मॉडल के टेक्स्ट को फिर से स्पीच में सिंथेसाइज़ किया जाता है, और उस स्पीच को बफर करके चलाया जाता है। हर चरण लेटेंसी जोड़ता है और कई चरणों में सबसे बड़ी लागत वह नहीं होती जिसकी आप उम्मीद करते हैं।

यहाँ ऐसे अंग्रेज़ी-भाषा एजेंट का उदाहरण है जिसके सर्वर यूज़र के काफ़ी पास हैं। ये आंकड़े उदाहरण के लिए दी गई रेंज हैं, गारंटी नहीं।

आम तौर पर, लेटेंसी के दो सबसे बड़े घटक LLM का टाइम-टू-फर्स्ट-टोकन और चेन की शुरुआत में एंडपॉइंटिंग देरी होते हैं। 

टेबल पाइपलाइन को समझने का उपयोगी तरीका है, लेकिन इससे लगता है कि चरण पूरी तरह क्रम में चलते हैं, जबकि ऐसा नहीं है। वॉइस एजेंट लेटेंसी के कई महत्वपूर्ण ऑप्टिमाइज़ेशन इन चरणों को ओवरलैप करने से आते हैं, और इसी ओवरलैप से नीचे के बजट का बड़ा हिस्सा वापस मिलता है।

स्पीच टू टेक्स्ट: ट्रांसक्रिप्शन और एंडपॉइंटिंग लेटेंसी ऑप्टिमाइज़ेशन

ट्रांसक्रिप्शन पाइपलाइन का दूसरा चरण है और इसकी असली लागत ट्रांसक्रिप्शन नहीं, बल्कि यह तय करना है कि यूज़र ने बोलना कब बंद किया। यह सेक्शन वॉइस एजेंट लेटेंसी ऑप्टिमाइज़ करने में मदद के लिए दोनों पहलुओं को कवर करता है।

ट्रांसक्रिप्शन LLM तक पहुँचने से पहले होता है। Scribe v2 Realtime (scribe_v2_realtime) लगभग 150 ms में आंशिक ट्रांसक्रिप्शन लौटाता है और ऑडियो चंक्स में स्ट्रीम करता है, इसलिए यूज़र के बोलते रहने के दौरान ही ट्रांसक्रिप्ट तैयार हो जाता है। यह 8kHz से 48kHz तक PCM और mu-law एन्कोडिंग सपोर्ट करता है, जो नीचे दिए गए कोडेक सेक्शन के लिए अहम है। 150 ms वाले आंशिक ट्रांसक्रिप्शन कम लागत वाले होते हैं।

बड़ी लेटेंसी लागत एंडपॉइंटिंग है: वह क्षण जब आपका सिस्टम तय करता है कि यूज़र ने सच में अपनी बारी खत्म कर दी है।

वॉइस एक्टिविटी डिटेक्शन (VAD) स्पीच को खामोशी के आधार पर विभाजित करता है, और यहीं समय जमा होता है। उदाहरण के लिए, अगर आप बारी खत्म घोषित करने से पहले 700 ms की खामोशी का इंतज़ार करते हैं, तो आपने ट्रांसक्रिप्शन के अलावा हर बारी में 700 ms जोड़ दिए। यह देरी ट्रांसक्रिप्शन-एक्यूरेसी बेंचमार्क में दिखाई नहीं देती, लेकिन वास्तविक बातचीत में बहुत साफ़ महसूस होती है। यह अक्सर पूरी पाइपलाइन में सबसे बड़ी नियंत्रित की जा सकने वाली लेटेंसी होती है, इसलिए शुरुआत के लिए यह अच्छी जगह है।

एंडपॉइंटिंग में प्रतिक्रिया क्षमता और बीच में टोकने के बीच संतुलन होता है। कम साइलेंस थ्रेशहोल्ड एजेंट को जल्दी जवाब देने देता है, लेकिन सामान्य विराम के दौरान यूज़र की बात बीच वाक्य में कटने का जोखिम रहता है। लंबा थ्रेशहोल्ड सुरक्षित है, लेकिन धीमा। व्यवहार में, स्पीच टू टेक्स्ट में लेटेंसी ऑप्टिमाइज़ करने के लिए ये तीन बदलाव करें:

1. साइलेंस थ्रेशहोल्ड को फाइन-ट्यून करें: साइलेंस थ्रेशहोल्ड को उस न्यूनतम स्तर तक कम करें, जहाँ आपके यूज़र्स के स्वाभाविक विराम कटें नहीं। फिर अनुमान लगाने के बजाय प्रोडक्शन में इंटरप्शन रेट मापें।
2. फ़िज़िकल कंट्रोल इवेंट जोड़ें: जब आपके एप्लिकेशन को किसी दूसरे सिग्नल (पुश-टू-टॉक रिलीज़ या UI इवेंट) से पता हो कि बारी खत्म हो गई है, तो VAD टाइमर का इंतज़ार करने के बजाय मैन्युअल कमिट कंट्रोल इस्तेमाल करें।
3. LLM प्रोसेस के साथ ओवरलैप करें: आंशिक ट्रांसक्रिप्शन को जल्दी डाउनस्ट्रीम भेजें। स्थिर आंशिक ट्रांसक्रिप्शन LLM में भेजें और अंतिम ट्रांसक्रिप्ट अलग होने पर उसे संशोधित करें। यह स्पेक्युलेटिव एक्ज़ीक्यूशन का एक रूप है, जो एंडपॉइंटिंग देरी को LLM प्रॉम्प्ट प्रोसेसिंग के पीछे छिपा देता है।

अधिक जानकारी के लिए, Scribe v2 Realtime का विस्तृत विवरण स्पीच टू टेक्स्ट क्षमताओं वाले पेज और रीयलटाइम स्पीच टू टेक्स्ट प्रोडक्ट पेज पर दिया गया है।

LLM की लेटेंसी का योगदान

लैंग्वेज मॉडल आमतौर पर TTFA में सबसे बड़ा अकेला योगदान देता है, इसलिए वॉइस एजेंट लेटेंसी ऑप्टिमाइज़ेशन में ओवरलैप का सबसे अधिक फ़ायदा भी यहीं मिलता है। मुख्य बात यह है कि एजेंट को बोलना शुरू करने से पहले पूरा जवाब नहीं चाहिए।

सबसे अधिक लेटेंसी बजट वापस पाने का पैटर्न यह है कि LLM से टोकन स्ट्रीम किए जाएँ और आते ही उन्हें TTS में भेजा जाए, वाक्य या क्लॉज़ की सीमा पर चंक्स बनाकर। तर्क यह है कि वाक्य की सीमा तक टोकन बफर करें, फिर अगला वाक्य जनरेट होते रहने के दौरान उस वाक्य को सिंथेसाइज़ करें:

const SENTENCE_END = /(?<=[.!?])\s+/;

async function* speakLlmStream(tokens: AsyncIterable<string>) {
  let buffer = "";
  for await (const token of tokens) {
    buffer += token;
    const parts = buffer.split(SENTENCE_END);
    buffer = parts.pop() ?? ""; // keep the incomplete fragment
    for (const sentence of parts) {
      if (sentence.trim()) yield* synthesize(sentence.trim());
    }
  }
  if (buffer.trim()) yield* synthesize(buffer.trim());
}

async function* synthesize(text: string) {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  yield* stream;
}

लंबी चलने वाली बातचीत के लिए TTS WebSocket को प्राथमिकता दें, ताकि खुले कनेक्शन पर हर वाक्य के लिए कनेक्शन सेटअप का समय दोबारा खर्च किए बिना टेक्स्ट धीरे-धीरे प्राप्त किया जा सके। आपके कन्करेंसी लिमिट में केवल वही समय गिना जाता है जब मॉडल सक्रिय रूप से ऑडियो जनरेट कर रहा हो, इसलिए निष्क्रिय खुला WebSocket लगभग मुफ़्त होता है।

टेक्स्ट टू स्पीच: स्ट्रीमिंग और वॉइस का चुनाव

टेक्स्ट टू स्पीच वह चरण है जहाँ आप लेटेंसी को सबसे सटीक रूप से नियंत्रित कर सकते हैं। इसके दो मुख्य विकल्प हैं: आप ऑडियो को कैसे स्ट्रीम करते हैं और कौन-सी वॉइस चुनते हैं।

Flash v2.5 (eleven_flash_v2_5) एजेंट में इस्तेमाल करने वाला मॉडल है। यह छोटे इनपुट के लिए लगभग 75 ms का मॉडल इन्फ़रेंस देता है, 32 भाषाओं को सपोर्ट करता है और हर अनुरोध में 40,000 तक कैरेक्टर स्वीकार करता है।

75 ms का आंकड़ा केवल इन्फ़रेंस का है। ऊपर दिए बजट में TTS TTFA अधिक है, क्योंकि इसमें इन्फ़रेंस के अलावा नेटवर्क राउंड-ट्रिप और सर्वर शेड्यूलिंग भी जुड़ती है।

यहाँ सबसे बड़ा विकल्प स्ट्रीमिंग है। अगर आप पूरा ऑडियो अनुरोध करके उसका इंतज़ार करते हैं, तो यूज़र को कुछ सुनने से पहले पूरी क्लिप के सिंथेसाइज़ होने तक इंतज़ार करना पड़ता है। स्ट्रीम करने पर यूज़र पहला चंक जनरेट होते ही सुन लेता है और बाकी ऑडियो उसके सुनते समय आता रहता है। स्ट्रीमिंग मॉडल को तेज़ नहीं बनाती; यह बस मॉडल के जनरेट करते रहने के दौरान ही यूज़र को आउटपुट देना शुरू कर देती है।

स्ट्रीमिंग कैसे करें गाइड HTTP स्ट्रीमिंग को कवर करती है, और रीयलटाइम WebSocket गाइड उस WebSocket पाथ को कवर करती है जिसे LLM से टोकन भेजते समय आप इस्तेमाल करेंगे।

क्लाइंट को एक बार इनिशियलाइज़ करें और नीचे दिए हर कॉल के लिए उसे फिर से इस्तेमाल करें:

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

फिर स्ट्रीम सेट अप करें और आते ही उसे फ़ॉरवर्ड करें:

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text: "Your call is connected. How can I help today?",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

for await (const chunk of stream) {
  // forward each chunk to your audio sink as it arrives
}

दूसरा विकल्प वॉइस का चुनाव है, जिसकी भी लेटेंसी लागत होती है। डिफ़ॉल्ट वॉइसेज़, सिंथेटिक वॉइसेज़ और इंस्टेंट वॉइस क्लोन्स (IVCs), प्रोफेशनल वॉइस क्लोन्स (PVCs) की तुलना में तेज़ी से सिंथेसाइज़ होते हैं, क्योंकि PVCs में अतिरिक्त मॉडल जटिलता होती है जो हर जनरेशन में ओवरहेड जोड़ती है। सख्त लेटेंसी आवश्यकताओं वाले एजेंट के लिए Flash के साथ IVC या डिफ़ॉल्ट वॉइस का संयोजन सबसे कम लेटेंसी वाला विकल्प है।

स्ट्रीमिंग चंक साइज़ के विकल्प

जब टोकन TTS में जा रहे हों और ऑडियो वापस आ रहा हो, तो अगला फ़ैसला होता है कि टुकड़ों का आकार कितना रखा जाए और प्लेयर शुरू होने से पहले कितना बफर करे।

छोटे चंक्स प्लेयर तक जल्दी पहुँचते हैं और फर्स्ट-बाइट लेटेंसी घटाते हैं, लेकिन इनमें ज़्यादा मैसेज और हर चंक का थोड़ा अधिक ओवरहेड होता है। बड़े चंक्स ट्रांसपोर्ट करने में अधिक कुशल होते हैं, लेकिन यूज़र को पहले चंक के लिए ज़्यादा इंतज़ार कराते हैं। इंटरैक्टिव एजेंट के लिए, बोलने की शुरुआत में छोटे चंक्स को प्राथमिकता दें, क्योंकि यूज़र को पहले चंक का इंतज़ार होता है; बाद के चंक्स ऑडियो चलने के दौरान आते हैं और उनका आकार कम मायने रखता है।

बची हुई लेटेंसी का एक महत्वपूर्ण हिस्सा प्लेयर से आता है। अधिकांश ऑडियो प्लेयर पहले बाइट पर प्लेबैक शुरू नहीं करते। स्ट्रीम के थोड़ी देर धीमा होने पर रुक-रुक कर चलने से बचने के लिए वे थोड़ा बफर करते हैं। 500 ms का डिफ़ॉल्ट बफर आम है और यह सीधे महसूस होने वाली लेटेंसी में जुड़ जाता है। इसे कम करने पर TTFA कम होता है, लेकिन रुकने के जोखिम में थोड़ी बढ़ोतरी होती है। सही मान आपके सर्वर और क्लाइंट के बीच नेटवर्क जिटर पर निर्भर करता है:

• स्थिर कनेक्शन पर (सर्वर-साइड प्लेबैक या सह-स्थित क्लाइंट), 50 से 150 ms का बफर आमतौर पर सुरक्षित होता है और TTFA में स्पष्ट कमी लाता है।
• जिटर वाले मोबाइल या क्रॉस-रीजन कनेक्शन पर, बड़ा बफर सुनाई देने वाले गैप रोकता है, जो उसकी कीमत वाली लेटेंसी से बदतर होते हैं।

यहाँ आपके लिए सही कॉन्फ़िगरेशन आपके सक्रिय उपयोग के मामले और प्राथमिकताओं पर निर्भर करता है।

कोडेक के विकल्प

ऑडियो कहाँ जा रहा है, उसी के आधार पर आपके अनुरोधित कोडेक का चुनाव होना चाहिए। हम mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 और ulaw_8000 जैसे फ़ॉर्मैट लौटाते हैं। ट्रांसपोर्ट के नेटिव फ़ॉर्मैट से मिलान करने पर ट्रांसकोडिंग का एक चरण हट जाता है, जो वॉइस एजेंट लेटेंसी ऑप्टिमाइज़ेशन में मदद करता है।

Twilio और ऐसे ही अन्य प्रोवाइडर्स वाली टेलीफोनी के लिए ulaw_8000 इस्तेमाल करें। टेलीफोनी नेटवर्क शुरू से अंत तक 8kHz mu-law होता है, इसलिए इसे सीधे अनुरोध करने पर आपकी पाइपलाइन से ट्रांसकोडिंग का एक चरण हट जाता है और कैरियर की अपेक्षा वाला फ़ॉर्मैट मिलता है। अधिक फिडेलिटी वाला ऑडियो सिंथेसाइज़ करने का कोई लाभ नहीं है, क्योंकि फ़ोन नेटवर्क उसे तुरंत डाउनसैंपल कर देगा; आप सिर्फ़ लेटेंसी जोड़ेंगे और सुनाई देने वाली गुणवत्ता में कुछ नहीं मिलेगा।

WebRTC और ब्राउज़र प्लेबैक के लिए PCM (pcm_24000 या pcm_16000) या MP3 फ़ॉर्मैट इस्तेमाल करें। PCM अनकंप्रेस्ड है, इसलिए क्लाइंट पर डिकोड करने का चरण नहीं होता। इससे प्रति चंक थोड़ी लेटेंसी हटती है और Web Audio पाइपलाइन को सीधे फ़ीड करने में सुविधा होती है। MP3 नेटवर्क पर अधिक कॉम्पैक्ट होता है, जो सीमित कनेक्शन पर मदद करता है, लेकिन इसके लिए क्लाइंट-साइड पर हल्का डिकोड करना पड़ता है।

भौगोलिक दूरी और नेटवर्क दूरी

ऊपर दिए गए हर ऑप्टिमाइज़ेशन में यह माना गया है कि बाइट्स को कम दूरी तय करनी है। भौगोलिक स्थिति आपके लेटेंसी बजट की न्यूनतम सीमा तय करती है, इसलिए किसी और चीज़ को ट्यून करने से पहले इसकी जाँच करना फ़ायदेमंद है।

हम उत्तरी अमेरिका, यूरोप और दक्षिण-पूर्व एशिया के क्लस्टर्स से अनुरोधों को संभालते हैं और हर अनुरोध को अपने-आप निकटतम क्लस्टर तक रूट करते हैं। सार्वजनिक इंटरनेट पर नेटवर्क राउंड-ट्रिप आमतौर पर भौगोलिक निकटता के आधार पर 20 से 200 ms होता है और आपका इन्फ्रास्ट्रक्चर कहाँ चलता है इसे बदले बिना इसे कम नहीं किया जा सकता।

उत्तरी अमेरिकी क्लस्टर से थोड़ी दूरी पर स्थित सैन फ़्रांसिस्को में जो एजेंट तुरंत प्रतिक्रिया देता है, वह दक्षिण एशिया के उस यूज़र को धीमा लग सकता है जिसका ट्रैफ़िक हर बारी में दो बार समुद्र पार करता है।

समाधान यह है कि अपने एप्लिकेशन सर्वर को केवल हमारे नहीं, अपने यूज़र्स के भी पास रखें। अगर आपके यूज़र यूरोप में हैं, तो अपना एजेंट बैकएंड यूरोप में चलाएँ, ताकि यूज़र से आपके सर्वर तक की दूरी कम हो; फिर हमारी रूटिंग पास के क्लस्टर से आपके सर्वर से मॉडल तक की दूरी संभाल लेगी।

वॉइस एजेंट लेटेंसी खुद मापना

ऊपर लेटेंसी बजट टेबल में दिए आंकड़े योजना बनाने के लिए उदाहरणात्मक रेंज हैं। जिन आंकड़ों के आधार पर आप शिप करेंगे, वे आपके अपने डिप्लॉयमेंट पर चलाए गए इस जैसी स्क्रिप्ट से आने चाहिए।

नीचे दिया गया इंस्ट्रूमेंटेशन कई ट्रायल में अलग से TTS चरण का TTFA, यानी अनुरोध से पहले ऑडियो चंक तक का समय मापता है और परसेंटाइल रिपोर्ट करता है। इसे उसी रीजन से चलाएँ जहाँ आपके सर्वर चलते हैं, अपनी डेवलपमेंट मशीन से नहीं। यह पहले बताए गए elevenlabs क्लाइंट को मानकर चलता है:

const VOICE_ID = "JBFqnCBsd6RMkjVDRZzb";
const TEXT = "Thanks for waiting. I have pulled up your account and I can help with that now.";
const TRIALS = 50;

async function measureTtfa(): Promise<number | null> {
  const start = performance.now();
  const stream = await elevenlabs.textToSpeech.stream(VOICE_ID, {
    text: TEXT,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  for await (const _chunk of stream) {
    return performance.now() - start; // first chunk -> stop the clock
  }
  return null;
}

function percentile(values: number[], p: number): number {
  const v = [...values].sort((a, b) => a - b);
  const k = (v.length - 1) * (p / 100);
  const lo = Math.floor(k);
  const hi = Math.min(lo + 1, v.length - 1);
  return v[lo] + (v[hi] - v[lo]) * (k - lo);
}

const samples: number[] = [];
for (let i = 0; i < TRIALS; i++) {
  const ttfa = await measureTtfa();
  if (ttfa !== null) samples.push(ttfa);
  await new Promise((r) => setTimeout(r, 300)); // space requests, don't measure your own queueing
}

console.log(`trials: ${samples.length}`);
console.log(`P50:    ${percentile(samples, 50).toFixed(0)} ms`);
console.log(`P95:    ${percentile(samples, 95).toFixed(0)} ms`);

याद रखने योग्य कुछ बातें:

• P50 और P95 रिपोर्ट करें: औसत के बजाय इन पर ध्यान दें। औसत टेल को छिपा देता है, और टेल ही एजेंट को अविश्वसनीय महसूस कराती है। P95 बीस में से एक बारी का अनुभव दिखाता है। 
• लोकेशन-आधारित प्रयोग: जिस हर रीजन को आप सेवा देते हैं, वहाँ से वही स्क्रिप्ट चलाएँ और नतीजे अलग-अलग रखें।
• सटीकता के लिए अंतर रखें: अपने अनुरोधों के बीच अंतर रखें (ऊपर वाला setTimeout)। अगर आप सभी को एक साथ भेजते हैं, तो सेवा की बजाय अपनी क्यूइंग मापेंगे। कन्करेंसी लिमिट पार होने पर अनुरोध प्राथमिकता के आधार पर क्यू में लगते हैं, जिससे आमतौर पर लगभग 50ms जुड़ता है, और क्षमता से आगे जाने पर HTTP 429 मिलता है।
• पूरी लेटेंसी चेन मापें: इसी टाइमिंग पैटर्न को दूसरे चरणों तक बढ़ाएँ। अपने STT फ़ाइनलाइज़ेशन, LLM फर्स्ट-टोकन और प्लेयर स्टार्टअप को उसी performance.now() ब्रैकेट्स में रखें। इससे आप अपनी संख्याओं से पूरा बजट टेबल भर सकते हैं और देख सकते हैं कि पहले किस चरण पर काम करना है।

इन सुझावों का पालन करके आप वॉइस एजेंट लेटेंसी खुद माप पाएँगे। इसके बाद आपके पास पहले निपटाने वाली प्राथमिकताओं का स्पष्ट रास्ता होगा।

वॉइस एजेंट लेटेंसी को सबसे ज़्यादा क्या कम करता है?

अगर आप कुछ त्वरित कदमों पर ध्यान देना चाहते हैं, तो ये सबसे असरदार बदलाव हैं।

प्रभाव के मोटे क्रम में, एजेंट लेटेंसी कम करने के लिए आप ये तरीके अपना सकते हैं:

• एंडपॉइंटिंग देरी छिपाने के लिए स्थिर STT पार्टियल्स पर LLM का काम शुरू करें।
• वाक्य सीमाओं पर LLM टोकन को TTS में स्ट्रीम करें, ताकि पहले वाक्य का सिंथेसिस दूसरे वाक्य के जनरेशन के साथ ओवरलैप हो।
• TTS ऑडियो को प्लेयर तक स्ट्रीम करें और प्लेयर बफर को आपके नेटवर्क जिटर के अनुसार सबसे छोटे सहनीय मान तक घटाएँ।
• सबसे कम लेटेंसी वाले TTS के लिए Flash के साथ डिफ़ॉल्ट वॉइस या IVC इस्तेमाल करें और कोडेक को ट्रांसपोर्ट के अनुसार मिलाएँ (टेलीफोनी के लिए ulaw_8000, ब्राउज़र/WebRTC के लिए PCM या MP3)।
• अपने सर्वर को यूज़र्स के पास रखें और हर रीजन में मापें, क्योंकि नेटवर्क के हिस्से वास्तविक और असमान होते हैं।

ज़्यादा गहराई वाले खास तरीकों के लिए लेटेंसी ऑप्टिमाइज़ेशन की कैसे करें डेवलपर गाइड देखें। पूरी तरह चलने वाले शुरुआती उदाहरण के लिए API क्विकस्टार्ट और स्ट्रीमिंग कैसे करें गाइड में पूरे उदाहरण दिए गए हैं। 

फाइन-ट्यून्ड एजेंट कैस्केड्स तक तेज़ पहुँच चाहते हैं? ElevenAgents में यह पाइपलाइन ओवरलैप ऑप्टिमाइज़ेशन के साथ पहले से लागू है।

ElevenAgents के साथ कम-लेटेंसी वॉइस एजेंट बनाएँ

वॉइस एजेंट लेटेंसी ऑप्टिमाइज़ेशन के लिए हर चरण को मापना और फिर चरणों को ओवरलैप करना ज़रूरी है, ताकि सबसे धीमे चरण पहले से चल रहे काम के पीछे पूरे हों। आप ऊपर दिए पैटर्न का इस्तेमाल करके कई चरणों में इस कैस्केड को खुद बना और ट्यून कर सकते हैं, या ऐसी पाइपलाइन से शुरू कर सकते हैं जिसमें लेटेंसी ऑप्टिमाइज़ेशन पहले से मौजूद हों।

ElevenAgents में स्ट्रीमिंग STT से लेकर टोकन-दर-टोकन LLM हैंडऑफ़ और Flash TTS तक पूरा कैस्केड लागू है, जिसमें ओवरलैप तकनीकें पहले से शामिल हैं। शून्य से शुरू करने के बजाय, आप उस परफ़ॉर्मेंस के लिए थ्रेशहोल्ड ट्यून करेंगे जो आपके लिए सबसे अहम है।

शुरू करने के लिए ElevenAgents से आज ही एजेंट बनाएँ या अधिक जानकारी के लिए सेल्स से संपर्क करें।

वॉइस एजेंट लेटेंसी ऑप्टिमाइज़ेशन के बारे में अक्सर पूछे जाने वाले सवाल