Opóźnienia w agentach głosowych: TTFT to za mało, liczy się cała ścieżka

Wybór odpowiedniego API do inferencji dla agentów głosowych często opiera się na metryce Time to First Token (TTFT), czyli czasie do otrzymania pierwszego tokena. Jednak jak wynika z analizy, to podejście może być mylące. TTFT mierzy jedynie moment rozpoczęcia generacji, podczas gdy model syntezy mowy (TTS) potrzebuje całej klauzuli lub zdania, aby wygenerować dźwięk. Różnica między tymi dwoma punktami decyduje o tym, czy agent będzie sprawiał wrażenie konwersacyjnego, czy też będzie przerywany.

Całościowe spojrzenie na opóźnienia

Agent głosowy to w istocie budżet na opóźnienia, w którym działa model językowy. Każdy etap przetwarzania pochłania milisekundy, które użytkownik może usłyszeć. TTFT jest definiowane jako interwał między wysłaniem żądania inferencji a otrzymaniem pierwszego tokena. IBM określa to jako moment przejścia systemu ze stanu bezczynności do widocznej aktywności. O ile w przypadku czatu TTFT jest niemal pełnym obrazem, o tyle w przypadku głosu to tylko jeden z elementów sumy.

Mechanizm działania modeli TTS wymaga kompletnej klauzuli lub zdania, zanim wygenerują dźwięk. Dlatego LiveKit wprowadza metrykę Time-to-First-Sentence (TTFS), argumentując, że to właśnie TTFS jest odczuwalne przez użytkowników. Daje to dwie zmienne do optymalizacji: TTFT kontroluje moment rozpoczęcia generacji, a liczba tokenów na sekundę (TPS) określa szybkość ukończenia pierwszego zdania. Dostawca, który wygrywa w jednej kategorii, a przegrywa w drugiej, nie zapewni szybkiego działania.

LiveKit w swoim przeglądzie agentów głosowych szacuje czas trwania pojedynczej tury konwersacji na:

• STT (mowa na tekst): około 100–200 ms
• LLM (model językowy): 300–500 ms (ze strumieniowaniem)
• TTS (tekst na mowę): 100–200 ms
• Sieć (WebRTC): 50–150 ms

Całkowity praktyczny cel dla opóźnienia end-to-end to 700 ms do 1,2 s. Kwindla Hultman Kramer, współtwórca Pipecat, sugeruje celowanie w medianę opóźnienia głos-głos na poziomie 800 ms, dopuszczając 1500 ms dla prototypów. Podzielił to na cztery równe części po około 200 ms: transport i przetwarzanie mediów, STT z wykrywaniem końca frazy, inferencja LLM oraz TTS.

Ludzka baza odniesienia, według Daily, to około 500 ms typowego czasu reakcji w rozmowie. Pauzy powyżej 800 ms zaczynają być odczuwalne jako nienaturalne. Wymagania LLM dla naturalnej konwersacji to czas głos-głos poniżej 1500 ms, co przekłada się na około 700 ms budżetu TTFT dla modelu LLM w trybie tekstowym.

Metodologia i czynniki wpływające na wyniki

Przed analizą konkretnych danych warto zwrócić uwagę na pięć kluczowych aspektów metodologii, które wpływają na interpretację wyników:

1. Kształt obciążenia: Artificial Analysis zmieniło domyślne obciążenie na zapytania z 10 000 tokenów wejściowych zamiast 1000. Dłuższe zapytania zwiększają zarówno TTFT, jak i szybkość generowania. LiveKit argumentuje, że to bliższe rzeczywistości dla agentów głosowych, którzy przetwarzają polityki, persony, reguły eskalacji i schematy narzędzi.
2. Lokalizacja serwera: Testy Artificial Analysis są przeprowadzane z maszyny wirtualnej w strefie us-central1-a Google Cloud. TTFT uwzględnia opóźnienia sieciowe, co może faworyzować lub dyskryminować dostawców w zależności od ich lokalizacji serwerów.
3. Tokeny rozumowania: W definicji Artificial Analysis, TTFT dla modelu rozumującego to pierwszy token rozumowania, a nie pierwszy token odpowiedzi.
4. Pomiar po stronie odbiorcy: Daily zaznacza, że dostawcy modeli czasem podają TTFT wewnętrzne dla swoich stosów inferencyjnych. Daily mierzy od wysłania żądania do pierwszego użytecznego tokena z API.
5. Brak powtarzalności: TTFT znacząco różni się między kolejnymi uruchomieniami testów, a dostawcy zmieniają stosy inferencyjne i wagi modeli bez zmiany ich nazw.

Dane pochodzą z rankingu dostawców API Artificial Analysis z 30 sierpnia 2026 roku, dla obciążenia 10 000 tokenów wejściowych, pojedynczego zapytania, mediana z 72 godzin.

Wyniki i obserwacje dotyczące LLM

Producenci układów scalonych często optymalizują pod kątem innych metryk niż te potrzebne agentom głosowym. Przykładem jest Mercury 2, model językowy oparty na dyfuzji, który generuje 770 tokenów na sekundę, ale jego pierwszy fragment pojawia się po 3,07 s. To czterokrotnie więcej niż cały budżet LLM dla naturalnej konwersacji.

Z kolei Cerebras i Groq prezentują inne podejście. Ich TTFT jest przyzwoite, a przepustowość wyjątkowa. Dla TTFS ta kombinacja jest bardzo mocna, ponieważ zdanie jest kompletne niemal natychmiast po pojawieniu się pierwszego tokena.

Warto zauważyć, że ten sam model na różnych hostach może mieć różne wyniki. GPT-5.6 Luna (bez rozumowania) osiąga 0,59 s na Amazon Bedrock i 0,74 s na własnym API OpenAI. Hosting i routing mają więc równie duże znaczenie, co same wagi modelu.

LiveKit publikuje własne dane TTFT dla swojego produktu inferencyjnego. Gemma 4 31B na LiveKit Inference osiągnęła 192 ms, w porównaniu do Gemini 2.5 Flash (911 ms), GPT-5.5 (966 ms), GPT-4.1 (1006 ms) i tej samej Gemma 4 31B przez OpenRouter (1876 ms).

LiveKit wyjaśnia, że uruchamia Gemmę za SGLang z dekodowaniem spekulatywnym i celowo niedostatecznie obciąża GPU, aby opóźnienia w kolejce były niskie. Ciepłe żądanie, jak podają, zaczyna zwracać tokeny w około 100 ms. Kompromisem jest koszt, wynoszący 1,20 USD za 1 milion tokenów wyjściowych.

Ten sam post raportuje TTFS dla pełnych konwersacji:

• Gemma 4 31B na LiveKit: 354 ms
• Gemini 2.5 Flash: 1034 ms
• GPT-4.1: 1088 ms
• Gemini 3.0 Flash: 1267 ms
• GPT-5.5: 1404 ms

W zakresie możliwości, na platformie IFBench (ocenionej niezależnie przez Artificial Analysis), Gemma 4 31B uzyskała 75,6% w porównaniu do GPT-5.5 (75,9%), GPT-4.1 (43%) i Gemini 2.5 Flash (39%). Na τ²-bench, GPT-5.5 prowadzi z 93,9%, a Gemma 4 31B osiąga 76,9%.

Mowa na tekst (STT): szybkość transkrypcji a wykrywanie końca mowy

Dla głosu, opóźnienie STT to nie szybkość transkrypcji, lecz czas, po którym system wie, że użytkownik przestał mówić. Artificial Analysis mierzy dwie rzeczy na swojej tablicy wyników streamingowego STT, obie od momentu wykrycia końca mowy przez SileroVAD: czas do pierwszej częściowej transkrypcji i czas do ostatecznej transkrypcji. Ich indeks AA-WER Streaming opiera się na około 8 godzinach audio, ważonych AA-AgentTalk (50%), VoxPopuli (25%) i Earnings-22 (25%).

Deepgram Flux jest architektonicznie interesującym rozwiązaniem. Włącza wykrywanie końca tury bezpośrednio do modelu rozpoznawania, zamiast dodawać VAD (Voice Activity Detection) jako osobną warstwę. Deepgram twierdzi, że może to skrócić opóźnienie odpowiedzi agenta o 200–600 ms w porównaniu do tradycyjnego potoku STT+VAD. Udostępnia parametry eot_threshold (0.5–0.9), eager_eot_threshold (0.3–0.9) oraz zdarzenie EagerEndOfTurn, które pozwala na wcześniejsze uruchomienie LLM. Ta ostatnia funkcja jest kluczowa, ponieważ pozwala całkowicie usunąć TTFT LLM z krytycznej ścieżki, jeśli przewidywanie jest poprawne.

AssemblyAI Universal-Streaming odwraca typowy model częściowych, a następnie ostatecznych transkrypcji, emitując niezmienne transkrypcje. AssemblyAI podało medianę emisji słów na poziomie 307 ms w porównaniu do 516 ms dla Deepgram Nova-3 w swoich pomiarach z 2025 roku. Dokumentacja firmy zaleca również używanie niesformatowanych transkrypcji dla agentów głosowych, ponieważ formatowanie pojawia się później i rzadko zmienia zachowanie LLM.

Roszczenia dotyczące dokładności są często kwestionowane i publikowane przez samych dostawców. AssemblyAI raportuje Universal-3.5 Pro Realtime z WER (Word Error Rate) na poziomie 6,99% w otwartym benchmarku Pipecat, wyprzedzając Google Chirp3 (9,04%), ElevenLabs Scribe v2 (9,76%) i Deepgram Flux (15,58%).

LiveKit również dokumentuje generowanie prewencyjne, które uruchamia LLM na częściowej transkrypcji. Ostrzeżenie jest jednak istotne: jeśli odpowiedź musi zostać wygenerowana ponownie po otrzymaniu ostatecznej transkrypcji, zużywa się tokeny i nie oszczędza się czasu.

Tekst na mowę (TTS): różnice między deklaracjami a rzeczywistością

W tej kategorii liczby podawane przez dostawców najbardziej odbiegają od doświadczeń użytkowników. ElevenLabs twierdzi, że Flash v2.5 dostarcza dźwięk w około 75 ms. Jednak ich dokumentacja precyzuje, że 75 ms odnosi się wyłącznie do czasu inferencji modelu. Strona dotycząca koncepcji opóźnień firmy wymienia typowy czas podróży sieciowej (round-trip) na 20–200 ms w zależności od lokalizacji geograficznej i zauważa, że większość odtwarzaczy audio buforuje dźwięk przed odtwarzaniem, przy czym 500 ms buforowania jest powszechne. Firma zaznacza również, że Eleven v3 nie jest przeznaczony do pracy w czasie rzeczywistym i rekomenduje Flash v2.5, Flash v2 lub Multilingual v2 dla swojej platformy Agents.

Cartesia deklaruje TTS poniżej 90 ms i opóźnienie transkrypcji 100 ms dla Sonic-3.6 i Ink-2. Marktechpost w swojej relacji z premiery Sonic-3.6 zaznaczył, że są to deklarowane przez dostawcę opóźnienia modelu, a nie mierzone czasy end-to-end. Cartesia wcześniej twierdziła, że Sonic 3.5 osiągał 82 ms czasu end-to-end do pierwszego dźwięku. Sonic działa na modelach przestrzeni stanów, a nie transformatorach, które skalują się liniowo, a nie kwadratowo z długością sekwencji.

W kwestii jakości, arena Artificial Analysis Provider Voice, oceniana metodą Elo przez niewidomych słuchaczy (dane z 30 sierpnia 2026), pokazuje, że różnica między Sonic 3.6 (1288) a Flash v2.5 (1083) to koszt jakościowy niższej latencji, na której działa większość agentów.

Modele mowa-na-mowę (Speech-to-Speech)

Modele mowa-na-mowę łączą STT, LLM i TTS w jednym przejściu. Mniejsza liczba rund powinna oznaczać niższe opóźnienia. LiveKit jednak ostrożnie zauważa, że modele czasu rzeczywistego nie zawsze gwarantują szybsze działanie, a dobrze dostrojony potok może być bardzo konkurencyjny.

Dane potwierdzają tę ostrożność. Z rankingu mowa-na-mowę Artificial Analysis, TTFA mierzone na Big Bench Audio (dane z 30 sierpnia 2026):

Grok Voice Think Fast 2.0 High wyróżnia się na tej liście: 0,70 s TTFA z 97% rozumowaniem mowy i 94,7% sukcesem zadania.

Kara za wysiłek rozumowania jest widoczna w ramach pojedynczych rodzin modeli. Gemini 3.1 Flash Live przechodzi z 0,96 s na 2,99 s między trybami Minimal i High. OpenAI GPT-Realtime-2.1 przechodzi z 0,97 s na 1,21 s, zyskując 2,1 punktu procentowego sukcesu zadania.

OpenAI wprowadziło gpt-realtime-2.1 i gpt-realtime-2.1-mini na początku lipca 2026 roku, deklarując, że ulepszone buforowanie skróciło opóźnienie p95 o co najmniej 25% we wszystkich ich modelach głosowych czasu rzeczywistego. Opóźnienie ogonowe (tail latency) jest tym, co sprawia, że agent telefoniczny wydaje się zepsuty, więc jest to bardziej użyteczne twierdzenie niż poprawa mediany.

Benchmark Daily kwantyfikuje, dlaczego większość agentów produkcyjnych nadal używa kaskadowych potoków. W teście aiwf_medium_context, GPT Realtime uzyskał 86,7% w porównaniu do GPT-4.1 (94,9%). Ultravox 0.7 został oceniony przez Daily jako pierwszy model mowa-na-mowę, który dobrze radzi sobie z długimi, wieloturnusowymi konwersacjami, i jest modelem o otwartych wagach.

Artificial Analysis benchmarkuje również cztery domyślne systemy kaskadowe dostawców, co stanowi użyteczny kontekst dla tego, co platformy faktycznie oferują:

• Deepgram Voice Agent: Nova-3 + GPT-4o Mini + Aura-2
• ElevenLabs Agents: Scribe v2 Realtime + Gemini 2.5 Flash + Eleven Flash v2
• Cartesia Line: Ink + Gemini 2.5 Flash + Sonic
• Inworld Realtime: Inworld STT 1 + Gemini 2.5 Flash + Inworld TTS 1.5 Mini

Trzy z czterech systemów używają Gemini 2.5 Flash, co wskazuje na pewien konsensus rynkowy.

Szacowane opóźnienia dla agresywnych potoków kaskadowych

Agresywny potok kaskadowy, hostowany w USA, kolokowany, może osiągnąć następujące szacunkowe czasy:

• STT (Deepgram Flux, eager EOT): 100 ms
• LLM (LiveKit Gemma 4, ciepłe żądanie): 100 ms
• TTS (Cartesia Sonic 3.6)

Źródło: marktechpost.com