मॉडल्स

फ्लैगशिप मॉडल्स

टेक्स्ट टू स्पीच

स्पीच टू टेक्स्ट

म्यूज़िक

मॉडल्स की जानकारी

ElevenLabs API अलग-अलग इस्तेमाल, क्वालिटी स्तरों और परफ़ॉर्मेंस की ज़रूरतों के लिए ऑप्टिमाइज़ किए गए कई ऑडियो मॉडल्स देता है।

बंद किए गए मॉडल्स

Eleven v3

Eleven v3 हमारा सबसे नया और उन्नत स्पीच सिंथेसिस मॉडल है। यह अत्याधुनिक मॉडल कई भाषाओं में व्यापक भावनात्मक अभिव्यक्ति और संदर्भ की समझ के साथ प्राकृतिक, इंसानों जैसी आवाज़ बनाता है।

यह मॉडल इन स्थितियों में अच्छा काम करता है:

• किरदारों की बातचीत: एक-दूसरे से बातचीत करने वाले कई किरदारों के ऑडियो अनुभवों के लिए बेहतरीन।
• ऑडियोबुक प्रोडक्शन: जटिल भावनात्मक प्रस्तुति वाले लंबे नैरेशन के लिए एकदम सही।
• भावनात्मक संवाद: व्यापक भावनात्मक अभिव्यक्ति और संदर्भ की समझ के साथ प्राकृतिक, जीवंत संवाद जनरेट करें।

Eleven v3 के साथ नया टेक्स्ट टू डायलॉग API आता है, जिससे आप कई भाषाओं में व्यापक भावनात्मक अभिव्यक्ति और संदर्भ की समझ के साथ प्राकृतिक, जीवंत संवाद जनरेट कर सकते हैं। Eleven v3 का इस्तेमाल टेक्स्ट टू स्पीच API के साथ भी किया जा सकता है, ताकि कई भाषाओं में व्यापक भावनात्मक अभिव्यक्ति और संदर्भ की समझ के साथ प्राकृतिक, जीवंत आवाज़ जनरेट की जा सके।

टेक्स्ट टू डायलॉग API के बारे में यहां और पढ़ें।

समर्थित भाषाएं

Eleven v3 मॉडल 70+ भाषाओं को support करता है, जिनमें शामिल हैं:

अफ़्रीकान्स (afr), अरबी (ara), अर्मेनियाई (hye), असमिया (asm), अज़रबैजानी (aze), बेलारूसी (bel), बांग्ला (ben), बोस्नियाई (bos), बल्गेरियाई (bul), कैटलन (cat), सेबुआनो (ceb), चिचेवा (nya), क्रोएशियाई (hrv), चेक (ces), डेनिश (dan), डच (nld), अंग्रेज़ी (eng), एस्टोनियाई (est), फ़िलिपीनो (fil), फ़िनिश (fin), फ़्रेंच (fra), गैलिशियन (glg), जॉर्जियाई (kat), जर्मन (deu), यूनानी (ell), गुजराती (guj), हौसा (hau), हिब्रू (heb), हिंदी (hin), हंगेरियन (hun), आइसलैंडिक (isl), इंडोनेशियाई (ind), आयरिश (gle), इतालवी (ita), जापानी (jpn), जावानीज़ (jav), कन्नड़ (kan), कज़ाख़ (kaz), किर्गिज़ (kir), कोरियाई (kor), लातवियाई (lav), लिंगाला (lin), लिथुआनियाई (lit), लक्ज़मबर्गिश (ltz), मैसेडोनियाई (mkd), मलय (msa), मलयालम (mal), मंदारिन चीनी (cmn), मराठी (mar), नेपाली (nep), नॉर्वेजियन (nor), पश्तो (pus), फ़ारसी (fas), पोलिश (pol), पुर्तगाली (por), पंजाबी (pan), रोमानियाई (ron), रूसी (rus), सर्बियाई (srp), सिंधी (snd), स्लोवाक (slk), स्लोवेनियाई (slv), सोमाली (som), स्पेनिश (spa), स्वाहिली (swa), स्वीडिश (swe), तमिल (tam), तेलुगु (tel), थाई (tha), तुर्की (tur), यूक्रेनी (ukr), उर्दू (urd), वियतनामी (vie), वेल्श (cym)।

Eleven v3 Conversational

Eleven v3 Conversational रीयलटाइम स्पीच सिंथेसिस के लिए हमारा सबसे भावपूर्ण मॉडल है। यह अत्याधुनिक मॉडल कई भाषाओं में व्यापक भावनात्मक अभिव्यक्ति और संदर्भ की समझ के साथ प्राकृतिक, इंसानों जैसी आवाज़ बनाता है।

यह मॉडल इन स्थितियों में अच्छा काम करता है:

• सपोर्ट एजेंट्स: ऐसे वॉइस एजेंट्स तैयार करें जो रीयलटाइम में ग्राहकों के सवाल हल करें।
• AI असिस्टेंट्स: व्यापक भावनात्मक अभिव्यक्ति और संदर्भ की समझ के साथ प्राकृतिक, जीवंत संवाद जनरेट करें।
• इंटरैक्टिव किरदार: भावपूर्ण किरदारों वाले ऑडियो अनुभवों के लिए बेहतरीन।

Eleven v3 Conversational के साथ नया टेक्स्ट टू डायलॉग WebSocket आता है, जिससे आप कई भाषाओं में व्यापक भावनात्मक अभिव्यक्ति और संदर्भ की समझ के साथ प्राकृतिक, जीवंत संवाद जनरेट कर सकते हैं।

टेक्स्ट टू डायलॉग WebSocket के बारे में यहां और पढ़ें।

समर्थित भाषाएं

Eleven v3 मॉडल 70+ भाषाओं को support करता है, जिनमें शामिल हैं:

अफ़्रीकान्स (afr), अरबी (ara), अर्मेनियाई (hye), असमिया (asm), अज़रबैजानी (aze), बेलारूसी (bel), बांग्ला (ben), बोस्नियाई (bos), बल्गेरियाई (bul), कैटलन (cat), सेबुआनो (ceb), चिचेवा (nya), क्रोएशियाई (hrv), चेक (ces), डेनिश (dan), डच (nld), अंग्रेज़ी (eng), एस्टोनियाई (est), फ़िलिपीनो (fil), फ़िनिश (fin), फ़्रेंच (fra), गैलिशियन (glg), जॉर्जियाई (kat), जर्मन (deu), यूनानी (ell), गुजराती (guj), हौसा (hau), हिब्रू (heb), हिंदी (hin), हंगेरियन (hun), आइसलैंडिक (isl), इंडोनेशियाई (ind), आयरिश (gle), इतालवी (ita), जापानी (jpn), जावानीज़ (jav), कन्नड़ (kan), कज़ाख़ (kaz), किर्गिज़ (kir), कोरियाई (kor), लातवियाई (lav), लिंगाला (lin), लिथुआनियाई (lit), लक्ज़मबर्गिश (ltz), मैसेडोनियाई (mkd), मलय (msa), मलयालम (mal), मंदारिन चीनी (cmn), मराठी (mar), नेपाली (nep), नॉर्वेजियन (nor), पश्तो (pus), फ़ारसी (fas), पोलिश (pol), पुर्तगाली (por), पंजाबी (pan), रोमानियाई (ron), रूसी (rus), सर्बियाई (srp), सिंधी (snd), स्लोवाक (slk), स्लोवेनियाई (slv), सोमाली (som), स्पेनिश (spa), स्वाहिली (swa), स्वीडिश (swe), तमिल (tam), तेलुगु (tel), थाई (tha), तुर्की (tur), यूक्रेनी (ukr), उर्दू (urd), वियतनामी (vie), वेल्श (cym)।

Multilingual v2

Eleven Multilingual v2 हमारा सबसे उन्नत, भावनाओं को समझने वाला स्पीच सिंथेसिस मॉडल है। यह कई भाषाओं में व्यापक भावनात्मक अभिव्यक्ति और संदर्भ की समझ के साथ प्राकृतिक, जीवंत आवाज़ बनाता है।

यह मॉडल स्पीकर की अनोखी विशेषताएं और एक्सेंट बनाए रखते हुए, सभी समर्थित भाषाओं में एक जैसी वॉइस क्वालिटी और पर्सनैलिटी देता है।

यह मॉडल उन स्थितियों में बेहतरीन है जिनमें उच्च-क्वालिटी, भावनात्मक रूप से बारीक आवाज़ चाहिए:

• किरदारों के वॉइसओवर: अपनी भावनात्मक अभिव्यक्ति की रेंज के कारण गेमिंग और ऐनिमेशन के लिए आदर्श।
• प्रोफेशनल कंटेंट: कॉर्पोरेट वीडियो और ई-लर्निंग सामग्री के लिए उपयुक्त।
• मल्टीलिंगुअल प्रोजेक्ट्स: भाषा बदलने पर भी वॉइस क्वालिटी एक जैसी रखता है।
• स्थिर क्वालिटी: लगातार उच्च-क्वालिटी ऑडियो आउटपुट देता है।

Flash मॉडल्स की तुलना में इसकी लेटेंसी और प्रति कैरेक्टर लागत ज़्यादा है, लेकिन जिन प्रोजेक्ट्स में जीवंत आवाज़ ज़रूरी है, उनके लिए यह बेहतर क्वालिटी देता है।

हमारे multilingual v2 मॉडल्स 29 भाषाओं को support करते हैं:

अंग्रेज़ी (USA, UK, ऑस्ट्रेलिया, कनाडा), जापानी, चीनी, जर्मन, हिंदी, फ़्रेंच (फ़्रांस, कनाडा), कोरियाई, पुर्तगाली (ब्राज़ील, पुर्तगाल), इतालवी, स्पेनिश (स्पेन, मेक्सिको), इंडोनेशियाई, डच, तुर्की, फ़िलिपीनो, पोलिश, स्वीडिश, बल्गेरियाई, रोमानियाई, अरबी (सऊदी अरब, UAE), चेक, यूनानी, फ़िनिश, क्रोएशियाई, मलय, स्लोवाक, डेनिश, तमिल, यूक्रेनी और रूसी।

Flash v2.5

Eleven Flash v2.5 हमारा सबसे तेज़ स्पीच सिंथेसिस मॉडल है, जिसे रीयल-टाइम ऐप्लिकेशंस और Agents Platform के लिए डिज़ाइन किया गया है। यह 32 भाषाओं में बेहद कम लेटेंसी (~75ms†) के साथ उच्च-क्वालिटी आवाज़ देता है।

यह मॉडल स्पीड और क्वालिटी के बीच संतुलन बनाता है, इसलिए यह इंटरैक्टिव ऐप्लिकेशंस के लिए आदर्श है। साथ ही, भाषाओं के बीच प्राकृतिक सुनाई देने वाला आउटपुट और एक जैसी वॉइस विशेषताएं बनाए रखता है।

यह मॉडल खास तौर पर इनके लिए उपयुक्त है:

• Agents Platform: रीयल-टाइम वॉइस एजेंट्स और चैटबॉट्स के लिए एकदम सही।
• इंटरैक्टिव ऐप्लिकेशंस: गेम्स और तुरंत जवाब देने वाली ऐप्लिकेशंस के लिए आदर्श।
• बड़े पैमाने पर प्रोसेसिंग: बड़ी मात्रा में टेक्स्ट-टू-स्पीच कन्वर्ज़न के लिए प्रभावी।

API जनरेशन के लिए कम कीमत और 75ms लेटेंसी के साथ, Flash v2.5 कई भाषाओं में तेज़ और भरोसेमंद स्पीच सिंथेसिस चाहने वाले हर व्यक्ति के लिए किफ़ायती विकल्प है।

Flash v2.5, v2 मॉडल्स की सभी भाषाओं के साथ-साथ 32 भाषाओं को support करता है:

हंगेरियन, नॉर्वेजियन और वियतनामी

ध्यान देने वाली बातें

मॉडल चुनने की गाइड

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

कैरेक्टर सीमाएं

एक टेक्स्ट-टू-स्पीच रिक्वेस्ट में समर्थित कैरेक्टर की अधिकतम संख्या मॉडल के अनुसार अलग-अलग होती है।

Scribe v2

Scribe v2 हमारा अत्याधुनिक स्पीच रिकग्निशन मॉडल है, जिसे 90+ भाषाओं में सटीक ट्रांसक्रिप्शन के लिए बनाया गया है। यह शब्द-स्तर के सटीक टाइमस्टैंप और स्पीकर डायराइजेशन व डायनामिक ऑडियो टैगिंग जैसी उन्नत सुविधाएं देता है।

यह मॉडल उन स्थितियों में बेहतरीन है जहां सटीक स्पीच-टू-टेक्स्ट कन्वर्ज़न चाहिए:

• ट्रांसक्रिप्शन सेवाएं: ऑडियो/वीडियो कंटेंट को टेक्स्ट में बदलने के लिए बेहतरीन
• मीटिंग डॉक्यूमेंटेशन: बातचीत को कैप्चर और डॉक्यूमेंट करने के लिए आदर्श
• कंटेंट विश्लेषण: ऑडियो कंटेंट प्रोसेसिंग और विश्लेषण के लिए उपयुक्त
• मल्टीलिंगुअल रिकग्निशन: 90+ भाषाओं में सटीक ट्रांसक्रिप्शन का समर्थन

मुख्य सुविधाएं:

• शब्द-स्तर के टाइमस्टैंप के साथ सटीक ट्रांसक्रिप्शन
• कई स्पीकर्स वाले ऑडियो के लिए स्पीकर डायराइजेशन
• बेहतर संदर्भ के लिए डायनामिक ऑडियो टैगिंग
• 90+ भाषाओं का समर्थन
• एंटिटी डिटेक्शन
• कीटर्म प्रॉम्प्टिंग
• ट्रांसक्रिप्ट एडिटिंग

Scribe v2 के बारे में और पढ़ें यहां।

Scribe v2 Realtime

Scribe v2 Realtime, हमारा सबसे तेज़ और सटीक लाइव स्पीच रिकग्निशन मॉडल, बेहद कम 150ms लेटेंसी के साथ 90 से अधिक भाषाओं में अत्याधुनिक सटीकता देता है।

यह मॉडल कन्वर्सेशनल उपयोग के मामलों में बेहतरीन है:

• लाइव मीटिंग ट्रांसक्रिप्शन: रियलटाइम ट्रांसक्रिप्शन के लिए बेहतरीन
• AI एजेंट्स: लाइव बातचीत के लिए आदर्श
• मल्टीलिंगुअल रिकग्निशन: ऑटोमैटिक भाषा पहचान के साथ 90+ भाषाओं में सटीक ट्रांसक्रिप्शन का समर्थन

मुख्य सुविधाएं:

• बेहद कम लेटेंसी: ~150 मिलीसेकंड में आंशिक ट्रांसक्रिप्शन पाएं
• स्ट्रीमिंग सपोर्ट: रियल-टाइम में ट्रांसक्रिप्ट पाते हुए ऑडियो को हिस्सों में भेजें
• कई ऑडियो फॉर्मैट: PCM (8kHz से 48kHz) और μ-law एन्कोडिंग का समर्थन
• वॉइस एक्टिविटी डिटेक्शन (VAD): साइलेंस डिटेक्शन के आधार पर ऑटोमैटिक स्पीच सेगमेंटेशन
• मैन्युअल कमिट कंट्रोल: ट्रांसक्रिप्ट सेगमेंट को फाइनल करने के समय पर पूरा नियंत्रण
• एंटिटी डिटेक्शन
• ट्रांसक्रिप्ट एडिटिंग

Scribe v2 Realtime के बारे में और पढ़ें यहां।

Scribe v2 Medical

Scribe v2 Medical मेडिकल और क्लिनिकल ऑडियो के लिए विशेष रूप से बनाया गया बैच स्पीच रिकग्निशन मॉडल है। यह Scribe v2 का एक फाइन-ट्यून है, जो रोज़मर्रा की बोलचाल में Scribe v2 जैसी सटीकता बनाए रखते हुए दवाओं के नाम, एनाटॉमी, पैथोलॉजी और क्लिनिकल डिक्टेशन की पहचान को बेहतर बनाता है। यह Scribe v2 के समान स्पीच टू टेक्स्ट API का इस्तेमाल करता है और इसकी बिलिंग भी उसी दर पर होती है। model_id के रूप में scribe_v2_medical पास करें।

यह मॉडल इनके लिए उपयुक्त है:

• क्लिनिकल डॉक्यूमेंटेशन: एम्बिएंट एनकाउंटर्स और नोट्स, जहां बातचीत के दौरान मेडिकल शब्द आते हैं
• डिक्टेशन: दवाओं, डोज़ और निष्कर्षों के सघन क्रम
• इंटेक और कोऑर्डिनेशन कॉल: मरीज़ अपनी स्थितियों का वर्णन करते हैं, अक्सर फोन पर
• कंप्लायंस वर्कफ़्लो: PHI कैटेगरी के लिए एंटिटी डिटेक्शन के साथ जोड़ें

मुख्य सुविधाएं:

• Scribe v2 जैसी ही रिक्वेस्ट संरचना (keyterms, entity_detection, no_verbatim, डायराइजेशन, टाइमस्टैंप)
• दवाओं के नाम, एनाटॉमी और पैथोलॉजी शब्दों की बेहतर पहचान
• Scribe v2 की तुलना में रोज़मर्रा की बोलचाल पर कोई गिरावट नहीं
• 90+ भाषाओं का समर्थन
• कई स्पीकर्स वाले ऑडियो के लिए स्पीकर डायराइजेशन
• डायनामिक ऑडियो टैगिंग
• PHI कैटेगरी सहित एंटिटी डिटेक्शन

Scribe v2 Medical एक बैच मॉडल है। लाइव ट्रांसक्रिप्शन के लिए Scribe v2 Realtime इस्तेमाल करें।

Scribe v2 Medical HIPAA के लिए योग्य है। Enterprise ग्राहकों के लिए बिज़नेस एसोसिएट एग्रीमेंट और ज़ीरो रिटेंशन मोड (ZRM) उपलब्ध हैं। ZRM चालू होने पर, हर रिक्वेस्ट पूरी होते ही ऑडियो इनपुट और टेक्स्ट आउटपुट डिलीट हो जाते हैं। ElevenLabs कुछ भी रिटेन नहीं करता, और आपके ऐप्लिकेशन को पूरा API रिस्पॉन्स मिलता है तथा ट्रांसक्रिप्ट आपके अपने नियंत्रण में रहते हैं।

स्पीच टू टेक्स्ट के बारे में और पढ़ें यहां।

Eleven Music

Eleven Music हमारा स्टूडियो-ग्रेड म्यूज़िक जेनरेशन मॉडल है। यह आपको किसी भी स्टाइल में नेचुरल लैंग्वेज प्रॉम्प्ट के साथ म्यूज़िक जेनरेट करने देता है।

यह मॉडल इन स्थितियों के लिए बेहतरीन है:

• गेम साउंडट्रैक: गेम्स के लिए इमर्सिव साउंडट्रैक बनाएं
• पॉडकास्ट बैकग्राउंड: प्रोफेशनल म्यूज़िक से पॉडकास्ट को बेहतर बनाएं
• मार्केटिंग: ऐड रील्स में बैकग्राउंड म्यूज़िक जोड़ें

मुख्य सुविधाएं:

• जॉनर, स्टाइल और स्ट्रक्चर पर पूरा नियंत्रण
• वोकल्स या सिर्फ इंस्ट्रूमेंटल
• अंग्रेज़ी, स्पैनिश, जर्मन, जापानी और अन्य भाषाओं सहित मल्टीलिंगुअल
• अलग-अलग सेक्शन या पूरे गाने की साउंड और लिरिक्स एडिट करें

Eleven Music के बारे में और पढ़ें यहां।

समकालिकता और प्राथमिकता

आपका सब्सक्रिप्शन प्लान तय करता है कि एक साथ कितने अनुरोध प्रोसेस किए जा सकते हैं और क्यू में आपके अनुरोधों की प्राथमिकता का स्तर क्या होगा। स्पीच टू टेक्स्ट की समकालिकता सीमा अधिक होती है। समकालिकता सीमा पूरी हो जाने पर, अगले अनुरोध कम-प्राथमिकता वाले अनुरोधों के साथ क्यू में प्रोसेस किए जाते हैं। व्यवहार में, इससे आम तौर पर केवल ~50ms की लेटेंसी बढ़ती है।

रिस्पॉन्स हेडर में current-concurrent-requests और maximum-concurrent-requests शामिल होते हैं, जिनका इस्तेमाल आप अपनी समकालिकता मॉनिटर करने के लिए कर सकते हैं।

प्रति मिनट API अनुरोध बनाम समकालिक अनुरोध

यह समझना ज़रूरी है कि प्रति मिनट API अनुरोध और समकालिक अनुरोध अलग-अलग मेट्रिक हैं, जो आपके उपयोग पैटर्न पर निर्भर करते हैं।

प्रति मिनट API अनुरोधों की संख्या समकालिक अनुरोधों से अलग हो सकती है, क्योंकि यह हर अनुरोध में लगने वाले समय और अनुरोधों को बैच करने के तरीके पर निर्भर करती है।

उदाहरण 1: अंतराल वाले अनुरोध अगर आपके पास प्रति मिनट 180 अनुरोध हों, जिनमें से हर एक को पूरा होने में 1 सेकंड लगता हो और आप उन्हें 0.33 सेकंड के अंतराल पर भेजें, तो अधिकतम समकालिक अनुरोध 3 होंगे और औसत भी 3 होगा, क्योंकि हमेशा 3 अनुरोध प्रगति पर होंगे।

उदाहरण 2: बैच किए गए अनुरोध वहीं, अगर आपका उपयोग पैटर्न अलग हो, जैसे प्रति मिनट 180 अनुरोध, जिनमें से हर एक को पूरा होने में 3 सेकंड लगते हों लेकिन वे सभी एक साथ भेजे जाते हों, तो अधिकतम समकालिक अनुरोध 180 होंगे और औसत 9 होगा (मिनट के पहले 3 सेकंड में एक साथ 180 अनुरोध होंगे और आखिरी 57 सेकंड में 0 अनुरोध)।

क्योंकि हमारा सिस्टम समकालिकता पर ध्यान देता है, इसलिए प्रति मिनट अनुरोधों की संख्या से ज़्यादा अहम यह है कि हर अनुरोध को कितना समय लगता है और उन्हें किस पैटर्न में भेजा जाता है।

एंडपॉइंट अनुरोध करने का तरीका समकालिकता सीमाओं को प्रभावित करता है:

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

समकालिकता सीमाएं समझें

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

सामान्य तौर पर, 5 की समकालिकता सीमा आमतौर पर लगभग 100 एक साथ ऑडियो ब्रॉडकास्ट को सपोर्ट कर सकती है।

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

अगर आप किसी भी समय अपने प्लान की समकालिकता सीमा पार कर देते हैं और Enterprise प्लान पर हैं, तो उपलब्ध क्षमता के आधार पर सर्वोत्तम प्रयास के आधार पर मॉडल अनुरोध धीमे होने पर भी सफल हो सकते हैं।

टेक्स्ट टू डायलॉग समकालिकता

टेक्स्ट टू डायलॉग अनुरोधों को API कॉल करने के तरीके के आधार पर दो अलग-अलग तरीकों से मापा जाता है:

• HTTP एंडपॉइंट (डायलॉग बनाएं और डायलॉग स्ट्रीम करें) ऑडियो जनरेट होने के दौरान, किसी भी अन्य टेक्स्ट टू स्पीच अनुरोध की तरह, आपके प्लान की मानक समकालिकता सीमा में गिने जाते हैं।
• टेक्स्ट टू डायलॉग WebSocket जैसे WebSocket एंडपॉइंट को डायलॉग सेशन के रूप में मापा जाता है। एक खुला कनेक्शन, ऑडियो जनरेट हो रहा हो या नहीं, खुले रहने तक एक डायलॉग सेशन रखता है।

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

अगर आप कनेक्शन तब खोलते हैं, जब आपके वर्कस्पेस के सभी डायलॉग सेशन उपयोग में हों, तो नए कनेक्शन को too_many_concurrent_requests त्रुटि के साथ अस्वीकार कर दिया जाता है। सेशन खाली करने के लिए, जिन कनेक्शन की अब ज़रूरत नहीं है उन्हें बंद करें — अगर आप keep_alive मैसेज नहीं भेजते हैं, तो निष्क्रियता के 20 सेकंड बाद कनेक्शन अपने आप भी बंद हो जाता है।

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

स्केल टेस्टिंग समकालिकता सीमाएं

स्केल टेस्टिंग क्लाइंट-साइड स्केलिंग समस्याओं की पहचान करने और यह जांचने के लिए उपयोगी हो सकती है कि आपके उपयोग मामले के लिए समकालिकता सीमाएं सही तरीके से सेट हैं या नहीं।

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

• रॉ अनुरोधों का नहीं, यूज़र्स का सिमुलेशन करें
• अनुरोध करने से पहले ऑडियो प्लेबैक, यूज़र का बोलना या ट्रांसक्रिप्शन पूरा होने का इंतज़ार करने जैसे सामान्य यूज़र व्यवहार का सिमुलेशन करें
• कुछ मिनटों की अवधि में यूज़र्स की संख्या धीरे-धीरे बढ़ाएं
• अनुरोध के समय और अनुरोधों के आकार में रैंडमनेस जोड़ें
• लेटेंसी मेट्रिक और API से मिलने वाले सभी त्रुटि कोड कैप्चर करें

उदाहरण के लिए, 100 एक साथ बातचीतों को सपोर्ट करने के लिए बनाए गए एजेंट सिस्टम का परीक्षण करने के लिए, आप बातचीत का सिमुलेशन करने वाले अधिकतम 100 अलग-अलग “यूज़र” बनाएंगे। बातचीत में आमतौर पर ~10 सेकंड यूज़र के बोलने का दोहराव वाला चक्र होता है, उसके बाद ~150 कैरेक्टर के लिए TTS API कॉल और फिर यूज़र के लिए ~10 सेकंड ऑडियो प्लेबैक होता है। इसलिए, हर यूज़र को हर 20 सेकंड में 150 कैरेक्टर के टेक्स्ट के लिए websocket टेक्स्ट-टू-स्पीच API कॉल करने के पैटर्न का पालन करना चाहिए, जिसमें इंतज़ार की अवधि और मांगे गए कैरेक्टर की संख्या में थोड़ी रैंडमनेस हो। टेस्ट में 100 यूज़र होने तक हर सेकंड एक यूज़र शुरू करना और फिर कुल स्थिरता जांचने के लिए 10 मिनट तक टेस्ट करना शामिल होगा।

import json
import random
import time
import gevent
import locust
from locust import User, task, events, constant_throughput
import websocket
# Averages up to 10 seconds of audio when played, depends on the voice speed
DEFAULT_TEXT = (
    "Hello, this is a test message. I am testing if a long input will cause issues for the model "
    "like this sentence. "
)
TEXT_ARRAY = [
    "Hello.",
    "Hello, this is a test message.",
    DEFAULT_TEXT,
    DEFAULT_TEXT * 2,
    DEFAULT_TEXT * 3
]
# Custom command line arguments
@events.init_command_line_parser.add_listener
def on_parser_init(parser):
    parser.add_argument("--api-key", default="YOUR_API_KEY", help="API key for authentication")
    parser.add_argument("--encoding", default="mp3_22050_32", help="Encoding")
    parser.add_argument("--text", default=DEFAULT_TEXT, help="Text to use")
    parser.add_argument("--use-text-array", default="false", help="Text to use")
    parser.add_argument("--voice-id", default="aria", help="Text to use")
class WebSocketTTSUser(User):
    # Each user will send a request every 20 seconds, regardless of how long each request takes
    wait_time = constant_throughput(0.05)
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.api_key = self.environment.parsed_options.api_key
        self.voice_id = self.environment.parsed_options.voice_id
        self.text = self.environment.parsed_options.text
        self.encoding = self.environment.parsed_options.encoding
        self.use_text_array = self.environment.parsed_options.use_text_array
        if self.use_text_array:
            self.text = random.choice(TEXT_ARRAY)
        self.all_recieved = False
    @task
    def tts_task(self):
        # Do jitter waiting of up to 1 second
        # Users appear to be spawned every second so this ensures requests are not aligned
        gevent.sleep(random.random())
        max_wait_time = 10
        # Connection details
        uri = f"{self.environment.host}/v1/text-to-speech/{self.voice_id}/stream-input?auto_mode=true&output_format={self.encoding}"
        headers = {"xi-api-key": self.api_key}
        ws = None
        self.all_recieved = False
        try:
            init_msg = {"text": " "}
            # Use proper header format for websocket - this is case sensitive!
            ws = websocket.create_connection(uri, header=headers)
            ws.send(json.dumps(init_msg))
            # Start measuring after websocket initiated but before any messages are sent
            send_request_time = time.perf_counter()
            ws.send(json.dumps({"text": self.text}))
            # Send to flush and receive the audio
            ws.send(json.dumps({"text": ""}))
            def _receive():
                t_first_response = None
                audio_size = 0
                try:
                    while True:
                        # Wait up to 10 seconds for a response
                        ws.settimeout(max_wait_time)
                        response = ws.recv()
                        response_data = json.loads(response)
                        if "audio" in response_data and response_data["audio"]:
                            audio_size = audio_size + len(response_data["audio"])
                        if t_first_response is None:
                            t_first_response = time.perf_counter()
                            first_byte_ms = (
                                t_first_response - send_request_time
                            ) * 1000
                            if audio_size is None:
                                # The first response should always have audio
                                locust.events.request.fire(
                                    request_type="websocket",
                                    name="Bad Response (no audio)",
                                    response_time=first_byte_ms,
                                    response_length=audio_size,
                                    exception=Exception("Response has no audio"),
                                )
                                break
                        if "isFinal" in response_data and response_data["isFinal"]:
                            # Fire this event once finished streaming, but report the important TTFB metric
                            locust.events.request.fire(
                                request_type="websocket",
                                name="TTS Stream Success (First Byte)",
                                response_time=first_byte_ms,
                                response_length=audio_size,
                                exception=None,
                            )
                            break
                except websocket.WebSocketTimeoutException:
                    locust.events.request.fire(
                        request_type="websocket",
                        name="TTS Stream Timeout",
                        response_time=max_wait_time * 1000,
                        response_length=audio_size,
                        exception=Exception("Timeout waiting for response"),
                    )
                except Exception as e:
                    # Typically JSON decode error if the server returns HTTP backoff error
                    locust.events.request.fire(
                        request_type="websocket",
                        name="TTS Stream Failure",
                        response_time=0,
                        response_length=0,
                        exception=e,
                    )
                finally:
                    self.all_recieved = True
            gevent.spawn(_receive)
            # Sleep until recieved so new tasks aren't spawned
            while not self.all_recieved:
                gevent.sleep(1)
        except websocket.WebSocketTimeoutException:
            locust.events.request.fire(
                request_type="websocket",
                name="TTS Stream Timeout",
                response_time=max_wait_time * 1000,
                response_length=0,
                exception=Exception("Timeout waiting for response"),
            )
        except Exception as e:
            locust.events.request.fire(
                request_type="websocket",
                name="TTS Stream Failure",
                response_time=0,
                response_length=0,
                exception=e,
            )
        finally:
            # Try and close the websocket gracefully
            try:
                if ws:
                    ws.close()
            except Exception:
                pass