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

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

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

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

सारांश

• टाइम-टू-फर्स्ट-ऑडियो पूरे पाइपलाइन को दर्शाता है, किसी एक मॉडल के इन्फ़रेंस समय को नहीं।
• 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 के आंशिक परिणाम कम लागत वाले हैं।

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

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

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

1. साइलेंस थ्रेशहोल्ड को फाइन-ट्यून करें: साइलेंस थ्रेशहोल्ड को उस न्यूनतम मान तक घटाएँ जो यूज़र्स के सामान्य विरामों को काटता न हो। फिर अनुमान लगाने के बजाय प्रोडक्शन में इंटरप्शन रेट मापें।
2. फ़िज़िकल कंट्रोल इवेंट जोड़ें: VAD टाइमर का इंतज़ार करने के बजाय, जब आपके एप्लिकेशन को किसी दूसरे सिग्नल (पुश-टू-टॉक रिलीज़, UI इवेंट) से टर्न समाप्त होने का पता हो, तो मैन्युअल कमिट कंट्रोल इस्तेमाल करें।
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
}

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

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