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

वॉइस एजेंट की responsiveness इस बात पर निर्भर करती है कि यूज़र के बोलना खत्म करने और एजेंट के जवाब देने के बीच कुल कितना समय लगता है। ये देरी आमतौर पर किसी एक स्लो कंपोनेंट की वजह से नहीं होती, बल्कि कई अलग-अलग स्टेजेज़ में थोड़ी-थोड़ी मिलकर बनती है। हर स्टेज कुछ दस या सैकड़ों मिलीसेकंड जोड़ती है, और इसे कम करने के लिए आपको जानना होगा कि हर स्टेज में कितना समय लग रहा है।

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

यह आर्टिकल कॉन्सेप्चुअल लेटेंसी ओवरव्यू के साथ एक साथी गाइड की तरह है। वहाँ बताया गया है कि लेटेंसी क्या है, और यहाँ आर्किटेक्चर और मेज़रमेंट के बारे में बताया गया है, ताकि आप एक ऐसा लेटेंसी बजट बना सकें जिसे आप माप सकें और उस पर काम कर सकें।

सारांश

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

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

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

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

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

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

• कैप्चर (माइक) -> स्पीच टू टेक्स्ट -> LLM -> टेक्स्ट टू स्पीच -> प्लेबैक

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

यहाँ एक इंग्लिश-लैंग्वेज एजेंट का उदाहरण है, जिसमें सर्वर यूज़र के करीब हैं। ये नंबर सिर्फ उदाहरण के लिए हैं, गारंटी नहीं।

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

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

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

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

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

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

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

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

1. साइलेंस थ्रेशोल्ड को फाइन-ट्यून करें:साइलेंस थ्रेशोल्ड को इतना टाइट करें कि यूज़र्स की नैचुरल पॉज़ कट न हो, फिर प्रोडक्शन में interruption रेट मापें, अंदाजा न लगाएं।
2. फिजिकल कंट्रोल इवेंट जोड़ें: जब आपकी ऐप को किसी और सिग्नल (जैसे पुश-टू-टॉक रिलीज़, UI इवेंट) से पता हो कि टर्न खत्म हो गया है, तो मैन्युअल कमिट कंट्रोल यूज़ करें, VAD टाइमर का इंतजार न करें।
3. LLM प्रोसेस के साथ ओवरलैप करें:पार्टियल्स को जल्दी डाउनस्ट्रीम भेजें। स्टेबल पार्टियल्स को LLM में डालें और अगर फाइनल ट्रांसक्रिप्ट अलग हो तो रिवाइज़ करें—ये speculative execution है, जिससे एंडपॉइंटिंग डिले 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 वेबसॉकेट का इस्तेमाल करें, ताकि ओपन कनेक्शन में हर सेंटीन्स पर बार-बार कनेक्शन सेटअप का समय न लगे। सिर्फ वही समय जब मॉडल एक्टिवली ऑडियो जनरेट कर रहा है, आपकी concurrency लिमिट में गिना जाता है, तो आइडल ओपन 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
}

दूसरा फैक्टर है वॉइस का चुनाव, जिसमें भी लेटेंसी का फर्क पड़ता है। डिफॉल्ट वॉइस, सिंथेटिक वॉइस और Instant Voice Clones (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)। अगर सब एक साथ भेजेंगे, तो आप अपनी ही क्व्यूइंग मापेंगे, न कि सर्विस की। जब concurrency लिमिट पार हो जाती है, तो रिक्वेस्ट्स प्रायोरिटी के हिसाब से क्व्यू होती हैं, जिससे आमतौर पर 50ms जुड़ जाता है, और कैपेसिटी से ज्यादा पर HTTP 429 मिलता है।
• पूरी लेटेंसी चेन मापें:यही टाइमिंग पैटर्न बाकी स्टेजेस पर भी लागू करें। अपनी

इन टिप्स को फॉलो करके आप खुद वॉइस एजेंट लेटेंसी माप सकते हैं। इसके बाद, आपको साफ पता चल जाएगा कि किस पर सबसे पहले ध्यान देना है।

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

अगर आप जल्दी असरदार बदलाव चाहते हैं, तो ये सबसे ज्यादा असर करने वाले तरीके हैं।

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

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

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

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

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

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

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

शुरुआत करें ElevenAgents से आज ही एजेंट बनाएं या सेल्स से संपर्क करें और जानकारी के लिए।

वॉइस एजेंट लेटेंसी ऑप्टिमाइज़ेशन से जुड़े सवाल