Modele

Flagowe modele

Text to Speech

Speech to Text

Agenci głosowi

Muzyka

Przegląd modeli

API ElevenLabs oferuje szeroki wybór modeli audio zoptymalizowanych pod różne zastosowania, poziomy jakości i wymagania dotyczące wydajności.

Wycofane modele

Eleven v4

Eleven v4 to nasz najnowocześniejszy model syntezy mowy, oferujący najwyższą jakość audio, ekspresję i kontrolę nad sposobem wypowiedzi głosów. Eleven v4 obsługuje klonowanie głosu w wysokiej jakości z niezawodnym zachowaniem cech mówcy podczas generowania długich tekstów.

Ten model sprawdza się w następujących zastosowaniach:

• Głosy postaci: Idealny do gier i animacji dzięki szerokiemu zakresowi emocji.
• Emocjonalne dialogi: Twórz naturalne, realistyczne dialogi o szerokiej gamie emocji i z uwzględnieniem kontekstu.
• Produkcja audiobooków: Idealny do długich narracji o złożonym przekazie emocjonalnym.
• Projekty wielojęzyczne: Utrzymuje spójną jakość głosu przy zmianie języka.

Eleven v4 jest dostępny przez Text to Dialogue API.

Obsługiwane języki

Rodzina modeli Eleven v4 obsługuje ponad 90 języków, w tym:

Afrikaans (af), arabski (ar), ormiański (hy), asamski (as), asturyjski (ast), azerski (az), białoruski (be), bengalski (bn), bośniacki (bs), bułgarski (bg), birmański (my), kantoński (yue), kataloński (ca), cebuański (ceb), chorwacki (hr), czeski (cs), duński (da), niderlandzki (nl), angielski (en), estoński (et), filipiński (fil), fiński (fi), francuski (fr), galicyjski (gl), gruziński (ka), niemiecki (de), grecki (el), gudźarati (gu), hausa (ha), hebrajski (he), hindi (hi), węgierski (hu), islandzki (is), indonezyjski (id), irlandzki (ga), włoski (it), japoński (ja), jawajski (jv), kannada (kn), kazachski (kk), koreański (ko), kirgiski (ky), łotewski (lv), lingala (ln), litewski (lt), luksemburski (lb), macedoński (mk), malajski (ms), malajalam (ml), maltański (mt), mandaryński chiński (zh), maoryski (mi), marathi (mr), mongolski (mn), nepalski (ne), norweski (no), oksytański (oc), orija (or), paszto (ps), perski (fa), polski (pl), portugalski (pt), pendżabski (pa), rumuński (ro), rosyjski (ru), serbski (sr), sindhi (sd), słowacki (sk), słoweński (sl), somalijski (so), hiszpański (es), suahili (sw), szwedzki (sv), tadżycki (tg), tamilski (ta), telugu (te), tajski (th), turecki (tr), ukraiński (uk), urdu (ur), uzbecki (uz), wietnamski (vi), walijski (cy), joruba (yo).

Eleven v4 Turbo

Eleven v4 Turbo to nasz najnowocześniejszy model syntezy mowy w czasie rzeczywistym, oferujący wysoką jakość audio, ekspresję i kontrolę nad sposobem wypowiedzi głosów. Eleven v4 Turbo obsługuje klonowanie głosu w wysokiej jakości i zapewnia wyniki przy medianie opóźnienia inferencji wynoszącej ~100 ms.

Ten model sprawdza się w następujących zastosowaniach:

• Agenci wsparcia: Zasilaj agentów głosowych, którzy rozwiązują zgłoszenia klientów w czasie rzeczywistym.
• Asystenci AI: Twórz naturalne, realistyczne dialogi o szerokiej gamie emocji i z uwzględnieniem kontekstu.
• Interaktywne postacie: Doskonały do doświadczeń audio z ekspresyjnymi postaciami.

Eleven v4 Turbo jest dostępny przez WebSocket Text to Dialogue.

Obsługiwane języki

Rodzina modeli Eleven v4 obsługuje ponad 90 języków, w tym:

Afrikaans (af), arabski (ar), ormiański (hy), asamski (as), asturyjski (ast), azerski (az), białoruski (be), bengalski (bn), bośniacki (bs), bułgarski (bg), birmański (my), kantoński (yue), kataloński (ca), cebuański (ceb), chorwacki (hr), czeski (cs), duński (da), niderlandzki (nl), angielski (en), estoński (et), filipiński (fil), fiński (fi), francuski (fr), galicyjski (gl), gruziński (ka), niemiecki (de), grecki (el), gudźarati (gu), hausa (ha), hebrajski (he), hindi (hi), węgierski (hu), islandzki (is), indonezyjski (id), irlandzki (ga), włoski (it), japoński (ja), jawajski (jv), kannada (kn), kazachski (kk), koreański (ko), kirgiski (ky), łotewski (lv), lingala (ln), litewski (lt), luksemburski (lb), macedoński (mk), malajski (ms), malajalam (ml), maltański (mt), mandaryński chiński (zh), maoryski (mi), marathi (mr), mongolski (mn), nepalski (ne), norweski (no), oksytański (oc), orija (or), paszto (ps), perski (fa), polski (pl), portugalski (pt), pendżabski (pa), rumuński (ro), rosyjski (ru), serbski (sr), sindhi (sd), słowacki (sk), słoweński (sl), somalijski (so), hiszpański (es), suahili (sw), szwedzki (sv), tadżycki (tg), tamilski (ta), telugu (te), tajski (th), turecki (tr), ukraiński (uk), urdu (ur), uzbecki (uz), wietnamski (vi), walijski (cy), joruba (yo).

Eleven v3

Eleven v3 to nasz model syntezy mowy poprzedniej generacji, który tworzy naturalną, realistyczną mowę o szerokiej gamie emocji i z uwzględnieniem kontekstu w wielu językach.

Wraz z Eleven v3 wprowadziliśmy nowe Text to Dialogue API, które pozwala tworzyć naturalne, realistyczne dialogi o szerokiej gamie emocji i z uwzględnieniem kontekstu w wielu językach. Eleven v3 można też używać z Text to Speech API do tworzenia naturalnej, realistycznej mowy o szerokiej gamie emocji i z uwzględnieniem kontekstu w wielu językach.

Więcej o Text to Dialogue API przeczytasz tutaj.

Obsługiwane języki

Model Eleven v3 obsługuje ponad 70 języków, w tym:

Afrikaans (af), arabski (ar), ormiański (hy), asamski (as), asturyjski (ast), azerski (az), białoruski (be), bengalski (bn), bośniacki (bs), bułgarski (bg), birmański (my), kantoński (yue), kataloński (ca), cebuański (ceb), cziczewa (ny), chorwacki (hr), czeski (cs), duński (da), niderlandzki (nl), angielski (en), estoński (et), filipiński (fil), fiński (fi), francuski (fr), galicyjski (gl), gruziński (ka), niemiecki (de), grecki (el), gudźarati (gu), hausa (ha), hebrajski (he), hindi (hi), węgierski (hu), islandzki (is), indonezyjski (id), irlandzki (ga), włoski (it), japoński (ja), jawajski (jv), kannada (kn), kazachski (kk), kirgiski (ky), koreański (ko), łotewski (lv), lingala (ln), litewski (lt), luksemburski (lb), macedoński (mk), malajski (ms), malajalam (ml), maltański (mt), mandaryński chiński (zh), maoryski (mi), marathi (mr), mongolski (mn), nepalski (ne), norweski (no), oksytański (oc), orija (or), paszto (ps), perski (fa), polski (pl), portugalski (pt), pendżabski (pa), rumuński (ro), rosyjski (ru), serbski (sr), sindhi (sd), słowacki (sk), słoweński (sl), somalijski (so), hiszpański (es), suahili (sw), szwedzki (sv), tadżycki (tg), tamilski (ta), telugu (te), tajski (th), turecki (tr), ukraiński (uk), urdu (ur), uzbecki (uz), wietnamski (vi), walijski (cy), joruba (yo).

Eleven v3 Conversational

Eleven v3 Conversational to nasz model syntezy mowy w czasie rzeczywistym poprzedniej generacji. Tworzy naturalną, realistyczną mowę o szerokiej gamie emocji i z uwzględnieniem kontekstu w wielu językach.

Wraz z Eleven v3 Conversational wprowadziliśmy nowy WebSocket Text to Dialogue, który pozwala tworzyć naturalne, realistyczne dialogi o szerokiej gamie emocji i z uwzględnieniem kontekstu w wielu językach.

Wraz z Eleven v3 Conversational wprowadziliśmy nowy WebSocket Text to Dialogue, który pozwala tworzyć naturalne, realistyczne dialogi o szerokiej gamie emocji i z uwzględnieniem kontekstu w wielu językach.

Więcej o WebSocket Text to Dialogue przeczytasz tutaj.

Obsługiwane języki

Model Eleven v3 obsługuje ponad 70 języków, w tym:

Afrikaans (af), arabski (ar), ormiański (hy), asamski (as), asturyjski (ast), azerski (az), białoruski (be), bengalski (bn), bośniacki (bs), bułgarski (bg), birmański (my), kantoński (yue), kataloński (ca), cebuański (ceb), cziczewa (ny), chorwacki (hr), czeski (cs), duński (da), niderlandzki (nl), angielski (en), estoński (et), filipiński (fil), fiński (fi), francuski (fr), galicyjski (gl), gruziński (ka), niemiecki (de), grecki (el), gudźarati (gu), hausa (ha), hebrajski (he), hindi (hi), węgierski (hu), islandzki (is), indonezyjski (id), irlandzki (ga), włoski (it), japoński (ja), jawajski (jv), kannada (kn), kazachski (kk), kirgiski (ky), koreański (ko), łotewski (lv), lingala (ln), litewski (lt), luksemburski (lb), macedoński (mk), malajski (ms), malajalam (ml), maltański (mt), mandaryński chiński (zh), maoryski (mi), marathi (mr), mongolski (mn), nepalski (ne), norweski (no), oksytański (oc), orija (or), paszto (ps), perski (fa), polski (pl), portugalski (pt), pendżabski (pa), rumuński (ro), rosyjski (ru), serbski (sr), sindhi (sd), słowacki (sk), słoweński (sl), somalijski (so), hiszpański (es), suahili (sw), szwedzki (sv), tadżycki (tg), tamilski (ta), telugu (te), tajski (th), turecki (tr), ukraiński (uk), urdu (ur), uzbecki (uz), wietnamski (vi), walijski (cy), joruba (yo).

Multilingual v2

Eleven Multilingual v2 to model syntezy mowy poprzedniej generacji, rozpoznający emocje. Tworzy naturalną, realistyczną mowę o szerokiej gamie emocji i z uwzględnieniem kontekstu w wielu językach.

Model zapewnia spójną jakość i charakter głosu we wszystkich obsługiwanych językach, zachowując unikalne cechy i akcent mówcy.

Ten model wyróżnia się w zastosowaniach wymagających wysokiej jakości, emocjonalnie zniuansowanej mowy:

• Głosy postaci: Idealny do gier i animacji dzięki szerokiemu zakresowi emocji.
• Profesjonalne treści: Dobrze sprawdza się w filmach firmowych i materiałach e-learningowych.
• Projekty wielojęzyczne: Utrzymuje spójną jakość głosu przy zmianie języka.
• Stała jakość: Tworzy spójne audio wysokiej jakości.

Choć ma większe opóźnienie i koszt na znak niż modele Flash, oferuje wyższą jakość w projektach, gdzie liczy się realistyczna mowa.

Nasze wielojęzyczne modele v2 obsługują 29 języków:

angielski (USA, Wielka Brytania, Australia, Kanada), japoński, chiński, niemiecki, hindi, francuski (Francja, Kanada), koreański, portugalski (Brazylia, Portugalia), włoski, hiszpański (Hiszpania, Meksyk), indonezyjski, niderlandzki, turecki, filipiński, polski, szwedzki, bułgarski, rumuński, arabski (Arabia Saudyjska, ZEA), czeski, grecki, fiński, chorwacki, malajski, słowacki, duński, tamilski, ukraiński i rosyjski.

Flash v2.5

Eleven Flash v2.5 to nasz najszybszy model syntezy mowy, zaprojektowany dla aplikacji czasu rzeczywistego i Agents Platform. Oferuje wysokiej jakości mowę z ultraniskim opóźnieniem (~75 ms†) w 32 językach.

Model równoważy szybkość i jakość, więc idealnie nadaje się do aplikacji interaktywnych, zachowując naturalne brzmienie oraz spójne cechy głosu w różnych językach.

Ten model jest szczególnie odpowiedni do:

• Agents Platform: Idealny dla agentów głosowych i chatbotów w czasie rzeczywistym.
• Aplikacji interaktywnych: Idealny do gier i aplikacji wymagających natychmiastowej odpowiedzi.
• Przetwarzania na dużą skalę: Wydajny przy masowej zamianie tekstu na mowę.

Dzięki niższej cenie generowania przez API i opóźnieniu 75 ms Flash v2.5 to opłacalna opcja dla każdego, kto potrzebuje szybkiej i niezawodnej syntezy mowy w wielu językach.

Flash v2.5 obsługuje 32 języki — wszystkie języki z modeli v2 oraz:

węgierski, norweski i wietnamski

Uwagi

Przewodnik po wyborze modelu

Wskazówki, który model najlepiej pasuje do twoich wymagań i zastosowania, znajdziesz w przewodniku po wyborze modelu.

Limity znaków

Maksymalna liczba znaków obsługiwana w pojedynczym żądaniu zamiany tekstu na mowę zależy od modelu.

Scribe v2

Scribe v2 to nasz najnowocześniejszy model rozpoznawania mowy, zaprojektowany do dokładnej transkrypcji w ponad 90 językach. Zapewnia precyzyjne znaczniki czasu na poziomie słów oraz zaawansowane funkcje, takie jak diarizacja mówców i dynamiczne tagowanie audio.

Ten model wyróżnia się w zastosowaniach wymagających dokładnej zamiany mowy na tekst:

• Usługi transkrypcji: Idealny do zamiany treści audio/wideo na tekst
• Dokumentacja spotkań: Idealny do rejestrowania i dokumentowania rozmów
• Analiza treści: Dobrze sprawdza się w przetwarzaniu i analizie treści audio
• Rozpoznawanie wielojęzyczne: Obsługuje dokładną transkrypcję w ponad 90 językach

Najważniejsze funkcje:

• Dokładna transkrypcja ze znacznikami czasu na poziomie słów
• Diaryzacja mówców w audio z wieloma osobami
• Dynamiczne tagowanie audio dla lepszego kontekstu
• Obsługa ponad 90 języków
• Wykrywanie encji
• Podpowiedzi słów kluczowych
• Edycja transkrypcji

Więcej o Scribe v2 przeczytasz tutaj.

Scribe v2 Realtime

Scribe v2 Realtime, nasz najszybszy i najdokładniejszy model rozpoznawania mowy na żywo, zapewnia najnowocześniejszą dokładność w ponad 90 językach przy ultraniskim opóźnieniu 150 ms.

Ten model wyróżnia się w zastosowaniach konwersacyjnych:

• Transkrypcja spotkań na żywo: Idealny do transkrypcji w czasie rzeczywistym
• Agenci AI: Idealny do rozmów na żywo
• Rozpoznawanie wielojęzyczne: Obsługuje dokładną transkrypcję w ponad 90 językach z automatycznym rozpoznawaniem języka

Najważniejsze funkcje:

• Ultraniskie opóźnienie: otrzymuj częściowe transkrypcje w około 150 milisekund
• Obsługa streamingu: wysyłaj audio w fragmentach, jednocześnie otrzymując transkrypcje w czasie rzeczywistym
• Wiele formatów audio: obsługa PCM (od 8 kHz do 48 kHz) i kodowania μ-law
• Voice Activity Detection (VAD): automatyczne segmentowanie mowy na podstawie wykrywania ciszy
• Ręczne sterowanie zatwierdzaniem: pełna kontrola nad momentem finalizacji segmentów transkrypcji
• Wykrywanie encji
• Edycja transkrypcji

Więcej o Scribe v2 Realtime przeczytasz tutaj.

Scribe v2 Medical

Scribe v2 Medical to wsadowy model rozpoznawania mowy wyspecjalizowany w audio medycznym i klinicznym. To Finetune Scribe v2, który poprawia rozpoznawanie nazw leków, anatomii, patologii i dyktowania klinicznego, zachowując dokładność Scribe v2 w codziennej mowie. Korzysta z tego samego Speech to Text API co Scribe v2 i jest rozliczany w tej samej stawce. Przekaż scribe_v2_medical jako model_id.

Ten model dobrze sprawdza się w:

• Dokumentacji klinicznej: Wizytach ambientowych i notatkach, gdzie terminy medyczne pojawiają się w trakcie rozmowy
• Dyktowaniu: Gęstych sekwencjach leków, dawek i wyników
• Rozmowach przy przyjęciu i koordynacji: Pacjentach opisujących własny stan, często przez telefon
• Procesach zgodności: Połącz z wykrywaniem encji dla kategorii PHI

Najważniejsze funkcje:

• Ten sam format żądania co Scribe v2 (keyterms, entity_detection, no_verbatim, diarizacja, znaczniki czasu)
• Lepsze rozpoznawanie nazw leków oraz terminów z anatomii i patologii
• Brak pogorszenia wyników dla codziennej mowy względem Scribe v2
• Obsługa ponad 90 języków
• Diaryzacja mówców w audio z wieloma osobami
• Dynamiczne tagowanie audio
• Wykrywanie encji, w tym kategorii PHI

Scribe v2 Medical to model wsadowy. Do transkrypcji na żywo użyj Scribe v2 Realtime.

Scribe v2 Medical kwalifikuje się do HIPAA; klienci Enterprise mogą zawrzeć Business Associate Agreement oraz skorzystać z Zero Retention Mode (ZRM). Po włączeniu ZRM wejściowe audio i wyjściowy tekst są usuwane natychmiast po zakończeniu każdego żądania. ElevenLabs niczego nie zachowuje, a twoja aplikacja otrzymuje pełną odpowiedź API i przechowuje transkrypcje pod własną kontrolą.

Więcej o Speech to Text przeczytasz tutaj.

Eleven Realtime

Eleven Realtime to nowa klasa modeli Speech to Speech do tworzenia naturalnych agentów głosowych. Każdy model Realtime to kompletny agent głosowy: rozpoznawanie mowy, wykrywanie aktywności głosowej i zmiany tury, LLM oraz zamiana tekstu na mowę — wybrane i dostrojone przez ElevenLabs tak, aby działały razem jako jeden system. Wybierz model Realtime, a jednym wyborem otrzymasz sprawnego agenta, bez komponentów do konfiguracji.

Dostępne są dwa modele Realtime.

Eleven Realtime v1 Mini jest zoptymalizowany pod kątem szybkich, naturalnych rozmów i sprawdza się w następujących zastosowaniach:

• Asystenci AI: Szybkie, ekspresyjne dialogi, gdzie sama rozmowa jest produktem.
• Tutorzy edukacyjni: Naturalna wymiana zdań, która dotrzymuje kroku uczącemu się.
• Interaktywne postacie: Ekspresyjne postacie do gier i rozrywki.

Eleven Realtime v1 Max jest zoptymalizowany pod kątem złożonych zadań i sprawdza się w następujących zastosowaniach:

• Obsługa klienta: Rozwiązywanie zgłoszeń wymagających realizacji procesu i wyszukiwania informacji.
• Kwalifikacja leadów: Ustrukturyzowane rozmowy, które zbierają informacje i określają kolejne kroki.
• Wieloetapowe workflow: Zadania, które wywołują narzędzia, by wyszukiwać informacje lub wykonywać działania.

Najważniejsze funkcje:

• Rozpoznawanie mowy, zmiana tury, model językowy i głos w jednym wyborze modelu
• Naturalna zmiana tury i obsługa przerwań
• Wywoływanie narzędzi
• Głosy z biblioteki głosów ElevenLabs z możliwością dostosowania
• Obsługa ponad 90 języków
• Przełączanie między v1 Mini a v1 Max przez wybór modelu, bez zmiany integracji

Eleven Realtime jest dostępny w ElevenAgents, gdzie wybierasz model Realtime z listy modeli, oraz przez Realtime API, zaprojektowane tak, by było zgodne z Realtime API OpenAI przez WebSocket. Jeśli używasz już Realtime API OpenAI, zobacz przewodnik migracji.

Obsługiwane języki

Modele Realtime obsługują ponad 90 języków. Zobacz listę języków Eleven v4.

Więcej o Eleven Realtime przeczytasz tutaj.

Eleven Music

Eleven Music to nasz studyjnej jakości model generowania muzyki. Pozwala tworzyć muzykę w dowolnym stylu za pomocą promptów w języku naturalnym.

Ten model doskonale sprawdza się w następujących zastosowaniach:

• Ścieżki dźwiękowe do gier: Twórz wciągające ścieżki dźwiękowe do gier
• Tło podcastów: Wzbogać podcasty profesjonalną muzyką
• Marketing: Dodawaj muzykę w tle do rolek reklamowych

Najważniejsze funkcje:

• Pełna kontrola nad gatunkiem, stylem i strukturą
• Wokal lub sama muzyka instrumentalna
• Wiele języków, w tym angielski, hiszpański, niemiecki, japoński i inne
• Edytuj dźwięk i tekst pojedynczych części lub całego utworu

Więcej o Eleven Music przeczytasz tutaj.

Współbieżność i priorytet

Twój plan subskrypcji określa, ile żądań może być przetwarzanych jednocześnie oraz jaki priorytet mają twoje żądania w kolejce. Speech to Text ma wyższy limit współbieżności. Po osiągnięciu limitu współbieżności kolejne żądania są przetwarzane w kolejce wraz z żądaniami o niższym priorytecie. W praktyce zwykle dodaje to tylko około 50 ms opóźnienia.

Nagłówki odpowiedzi zawierają current-concurrent-requests i maximum-concurrent-requests, których możesz użyć do monitorowania współbieżności.

Żądania API na minutę a żądania współbieżne

Warto wiedzieć, że żądania API na minutę i żądania współbieżne to różne wskaźniki zależne od sposobu użycia.

Liczba żądań API na minutę może różnić się od liczby żądań współbieżnych, ponieważ zależy od czasu trwania każdego żądania i sposobu ich grupowania.

Przykład 1: Żądania w odstępach Jeśli masz 180 żądań na minutę, z których każde trwa 1 sekundę, i wysyłasz je co 0,33 sekundy, maksymalna i średnia liczba żądań współbieżnych wyniesie 3, ponieważ zawsze będą przetwarzane 3 żądania.

Przykład 2: Żądania wsadowe Jeśli jednak masz inny sposób użycia, na przykład 180 żądań na minutę, z których każde trwa 3 sekundy, ale wszystkie są wysyłane naraz, maksymalna liczba żądań współbieżnych wyniesie 180, a średnia 9 (przez pierwsze 3 sekundy minuty jest 180 żądań naraz, a przez ostatnie 57 sekund — 0 żądań).

Ponieważ nasz system uwzględnia współbieżność, liczba żądań na minutę ma mniejsze znaczenie niż czas trwania każdego żądania i schemat ich wysyłania.

Sposób wysyłania żądań do endpointów wpływa na limity współbieżności:

• W HTTP każde żądanie osobno wlicza się do limitu współbieżności.
• W WebSocket Text to Speech do limitu współbieżności wlicza się tylko czas generowania audio przez nasz model. Oznacza to, że przez większość czasu otwarty websocket w ogóle nie wlicza się do limitu współbieżności.
• WebSockety Text to Dialogue działają inaczej: każde otwarte połączenie rezerwuje jedną sesję dialogu z osobnej puli na cały czas jego trwania, a audio generowane przez połączenie nie wlicza się do standardowego limitu współbieżności. Ułatwia to planowanie: jedno połączenie to jedna sesja, a limity sesji dialogu są dostosowane do tej nowej metody współbieżności. Zobacz współbieżność Text to Dialogue.

Jak rozumieć limity współbieżności

Limit współbieżności powiązany z twoim planem nie oznacza maksymalnej liczby jednoczesnych rozmów, połączeń telefonicznych, nałożonych głosów postaci itd., które można obsłużyć naraz. Rzeczywista liczba zależy od kilku czynników, w tym użytych głosów AI i charakterystyki przypadku użycia.

Zasadniczo limit współbieżności wynoszący 5 zwykle pozwala obsłużyć około 100 jednoczesnych transmisji audio.

Wynika to z szybkości generowania audio w porównaniu z czasem przetwarzania żądania TTS. Poniższy diagram pokazuje przykład obsługi 4 jednoczesnych połączeń z różnymi użytkownikami przy wykorzystaniu tylko 2 współbieżnych żądań.

Jeśli w dowolnym momencie przekroczysz limity współbieżności planu i korzystasz z planu Enterprise, żądania modelu mogą nadal się powieść, choć wolniej, zależnie od dostępnej pojemności.

Współbieżność Text to Dialogue

Żądania Text to Dialogue są rozliczane na dwa sposoby, zależnie od tego, jak wywołujesz API:

• Endpointy HTTP (Utwórz dialog i Streamuj dialog) wliczają się do standardowego limitu współbieżności twojego planu podczas generowania audio, tak jak każde inne żądanie Text to Speech.
• Endpointy WebSocket, takie jak WebSocket Text to Dialogue, są rozliczane jako sesje dialogu. Otwarte połączenie zajmuje sesję dialogu przez cały czas jego trwania, niezależnie od tego, czy audio jest aktualnie generowane.

Rozliczanie na podstawie sesji upraszcza planowanie pojemności: jedno połączenie to jedna sesja, więc użycie nie zmienia się wraz z aktywnością generowania. Ponieważ sesja jest zajęta przez całe połączenie, a nie tylko podczas generowania audio, limity sesji dialogu są dostosowane do tej nowej metody współbieżności.

Jeśli otworzysz połączenie, gdy wszystkie sesje dialogu w twoim obszarze roboczym są używane, nowe połączenie zostanie odrzucone z błędem too_many_concurrent_requests. Aby zwolnić sesje, zamknij niepotrzebne połączenia — połączenie zamknie się też automatycznie po 20 sekundach bezczynności, chyba że wysyłasz wiadomości keep_alive.

Aby monitorować sesje dialogu, otwórz Deweloperzy na dole paska bocznego panelu, wybierz kartę Analityka i sprawdź wskaźnik Żądania współbieżne w widoku Użycie. Sesje dialogu są raportowane jako osobna seria, Sesje Websocket TTD, niezależnie od pozostałych żądań współbieżnych.

Testowanie limitów współbieżności na dużą skalę

Testowanie na dużą skalę może pomóc wykryć problemy ze skalowaniem po stronie klienta i sprawdzić, czy limity współbieżności są prawidłowo ustawione dla twojego przypadku użycia.

Zdecydowanie zalecamy testowanie workflow end-to-end jak najbliższych rzeczywistemu użyciu. Najlepszą metodą jest symulowanie i mierzenie liczby użytkowników, których można obsłużyć. Ważne, aby:

• Symulować użytkowników, a nie surowe żądania
• Symulować typowe zachowania użytkowników, takie jak oczekiwanie na odtworzenie audio, zakończenie mówienia przez użytkownika lub transkrypcji przed wysłaniem żądania
• Powoli zwiększać liczbę użytkowników przez kilka minut
• Wprowadzać losowość w czasie żądań i ich rozmiarze
• Rejestrować wskaźniki opóźnienia oraz kody błędów zwracane przez API

Na przykład, aby przetestować system agenta zaprojektowany do obsługi 100 jednoczesnych rozmów, utwórz do 100 osobnych „użytkowników”, z których każdy symuluje rozmowę. Rozmowy zwykle składają się z powtarzającego się cyklu: około 10 sekund mówienia użytkownika, następnie wywołanie API TTS dla około 150 znaków, a potem około 10 sekund odtwarzania audio użytkownikowi. Dlatego każdy użytkownik powinien co 20 sekund wykonywać wywołanie API Text to Speech przez websocket dla 150 znaków tekstu, z niewielką losowością w czasie oczekiwania i liczbie żądanych znaków. Test powinien uruchamiać jednego użytkownika na sekundę, aż będzie ich 100, a następnie trwać łącznie 10 minut, aby sprawdzić ogólną stabilność.

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