Optymalizacja opóźnień agenta głosowego: przewodnik krok po kroku

Szybkość reakcji agenta głosowego zależy od całkowitego opóźnienia między zakończeniem wypowiedzi przez użytkownika a rozpoczęciem odpowiedzi przez agenta. To opóźnienie rzadko wynika z jednego wolnego elementu – zbiera się na kilku niezależnych etapach, z których każdy dokłada kilkadziesiąt lub kilkaset milisekund. Żeby je zmniejszyć, trzeba wiedzieć, ile czasu zajmuje każdy etap.

Optymalizacja opóźnień agenta głosowego polega na znalezieniu, gdzie ten czas się ukrywa, i odzyskiwaniu go etap po etapie.

Ten artykuł uzupełnia przegląd opóźnień. Tamta strona wyjaśnia, czym są opóźnienia, a tutaj skupiamy się na architekturze i pomiarach. Dzięki temu poznasz swój budżet opóźnień i konkretne działania, które możesz podjąć.

TL;DR

• Time-to-first-audio obejmuje cały pipeline, a nie tylko czas działania jednego modelu.
• Największy wpływ mają czas do pierwszego tokena LLM i opóźnienie endpointingu.
• Najwięcej zyskujesz, gdy etapy pipeline’u zachodzą na siebie, zamiast działać po kolei.
• Streaming, wybór kodeka i ustawienie bufora w odtwarzaczu pozwalają urwać kolejne milisekundy.
• Mierz opóźnienia osobno dla każdego regionu, na swoim wdrożeniu, raportując P50 i P95.

Definiowanie budżetu opóźnień agenta głosowego

Budżet opóźnień to docelowy czas do pierwszego dźwięku, rozdzielony na poszczególne etapy pipeline’u. Każdy etap dostaje swoją pulę, a suma musi zmieścić się w limicie. To pierwszy krok – i najczęstsze miejsce pomyłek, bo inżynierowie często mylą dwie podobne liczby, które znaczą coś innego.

Pierwsza to opóźnienie inferencji modelu, czyli czas generowania odpowiedzi przez model. Dla naszych modeli Flash to ok. 75 ms dla krótkich wejść (bez sieci i narzutu aplikacji). To liczba wewnętrzna, przydatna do porównywania modeli, ale nie odczuwalna przez użytkownika.

Z perspektywy użytkownika liczy się time-to-first-audio (TTFA): czas od zakończenia wypowiedzi do usłyszenia pierwszego fragmentu odpowiedzi agenta. TTFA zawsze jest większe niż opóźnienie pojedynczego modelu, bo obejmuje cały pipeline.

Agent głosowy w kaskadzie to łańcuch pięciu etapów:

• nagranie (mikrofon) -> STT -> LLM -> TTS -> odtwarzanie

Dźwięk trafia z mikrofonu, jest transkrybowany na tekst, wysyłany do modelu językowego, tekst zamieniany na mowę, a ta buforowana i odtwarzana. Każdy etap dokłada opóźnienie, a w kilku przypadkach największy koszt jest tam, gdzie się go nie spodziewasz.

Oto przykład dla agenta anglojęzycznego z serwerami blisko użytkownika. Liczby są orientacyjne, nie gwarantowane.

Największy wpływ na opóźnienie mają zwykle czas do pierwszego tokena LLM i opóźnienie endpointingu na początku łańcucha.

Tabela dobrze pokazuje pipeline, ale sugeruje, że etapy działają po kolei – a tak nie jest. Największe optymalizacje opóźnień agenta głosowego wynikają z nakładania się etapów, i to tam odzyskujesz większość budżetu.

Speech to Text: optymalizacja transkrypcji i endpointingu

Transkrypcja to drugi etap pipeline’u, ale jej prawdziwy koszt to nie sama transkrypcja, tylko decyzja, kiedy użytkownik skończył mówić. Ten rozdział omawia oba aspekty, żebyś mógł zoptymalizować opóźnienia agenta głosowego.

Transkrypcja odbywa się przed LLM.Scribe v2 Realtime (scribe_v2_realtime) zwraca częściowe transkrypcje w ok. 150 ms i streamuje dźwięk w kawałkach, więc transkrypcja powstaje, gdy użytkownik jeszcze mówi. Obsługuje PCM od 8 kHz do 48 kHz i kodowanie mu-law, co ma znaczenie przy wyborze kodeka. Te 150 ms częściowe transkrypcje są tanie.

Większy koszt to endpointing, czyli moment, w którym system uznaje, że użytkownik skończył mówić.

Voice Activity Detection (VAD) dzieli mowę na podstawie ciszy – i to tam zbiera się czas. Jeśli czekasz np. 700 ms ciszy, zanim uznasz, że tura się skończyła, dokładasz 700 ms do każdej wypowiedzi, oprócz czasu transkrypcji. Tego opóźnienia nie widać w benchmarku dokładności transkrypcji, ale w rozmowie jest bardzo odczuwalne. To często największe opóźnienie, które możesz kontrolować – więc warto zacząć właśnie tutaj.

Endpointing to balans między szybkością reakcji a ryzykiem przerwania użytkownika. Krótki próg ciszy sprawia, że agent odpowiada szybciej, ale może uciąć użytkownika w połowie zdania. Długi próg jest bezpieczny, ale wolniejszy. W praktyce, trzy zmiany, które najbardziej optymalizują opóźnienia w speech to text, to:

1. Dopasuj próg ciszy:Ustaw próg ciszy na najkrótszy, który nie ucina naturalnych pauz użytkowników, a potem mierz faktyczną liczbę przerw w produkcji – nie zgaduj.
2. Dodaj fizyczny sygnał zakończenia: Użyj ręcznego potwierdzenia, jeśli twoja aplikacja wie, że tura się skończyła (np. po puszczeniu przycisku push-to-talk lub zdarzeniu w UI), zamiast czekać na licznik VAD.
3. Nakładaj na siebie z LLM:Przekazuj częściowe transkrypcje do LLM jak najwcześniej. Jeśli końcowa transkrypcja się różni, poprawiasz odpowiedź – to tzw. spekulacyjne wykonanie, które ukrywa opóźnienie endpointingu za przetwarzaniem promptu LLM.

Więcej o Scribe v2 Realtime znajdziesz na stronie speech to text oraz na stronie produktu rozpoznawanie mowy na tekst na żywo.

Wpływ LLM na opóźnienia

Model językowy to zwykle największy pojedynczy składnik TTFA, więc tutaj nakładanie etapów daje największy efekt. Klucz: agent nie musi mieć całej odpowiedzi, żeby zacząć mówić.

Najwięcej czasu odzyskasz, streamując tokeny z LLM do TTS na bieżąco, w kawałkach na granicach zdań lub fraz. Buforujesz tokeny do końca zdania, potem syntezujesz to zdanie, a kolejne generuje się w tle:

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;
}

Przy dłuższych rozmowach wybierz TTS WebSocket, żeby otwarte połączenie mogło odbierać tekst na bieżąco, bez ponownego łączenia przy każdej wypowiedzi. Tylko czas aktywnego generowania audio liczy się do limitu równoległości, więc otwarty, nieużywany WebSocket praktycznie nic nie kosztuje.

Text to Speech: streaming i wybór głosu

Text to speech to etap, gdzie możesz najdokładniej kontrolować opóźnienia. Masz dwa główne narzędzia: sposób streamowania audio i wybór głosu.

Flash v2.5 (eleven_flash_v2_5) to model do użycia w agencie. Daje ok. 75 ms inferencji dla krótkich wejść, obsługuje 32 języki i przyjmuje do 40 000 znaków na żądanie.

Te 75 ms to tylko inferencja. TTFA TTS w budżecie powyżej jest większe, bo dochodzi sieć i kolejkowanie na serwerze.

Największy wpływ ma streaming. Jeśli czekasz na całe audio, użytkownik słyszy odpowiedź dopiero po wygenerowaniu całości. Jeśli streamujesz, pierwszy fragment pojawia się od razu, a reszta dociera w trakcie słuchania. Streaming nie przyspiesza modelu – po prostu zaczynasz odtwarzać, gdy model jeszcze generuje.

Zobacz poradnik o streamingu o streamingu HTTP oraz poradnik o WebSocket – to ścieżka, której potrzebujesz, gdy przekazujesz tokeny z LLM.

Zainicjuj klienta raz i używaj go do wszystkich poniższych wywołań:

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

Potem ustaw stream i przekazuj go dalej na bieżąco:

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
}

Drugim narzędziem jest wybór głosu, który też wpływa na opóźnienie. Głosy domyślne, syntetyczne i Instant Voice Clones (IVC) generują się szybciej niż Professional Voice Clones (PVC), bo PVC są bardziej złożone i mają dodatkowy narzut. Jeśli zależy ci na najniższym opóźnieniu, połącz Flash z IVC lub głosem domyślnym.

Wybór wielkości kawałków streamingu

Gdy tokeny trafiają do TTS, a audio wraca, musisz zdecydować, jak duże mają być kawałki i ile odtwarzacz buforuje przed startem.

Mniejsze kawałki szybciej trafiają do odtwarzacza, skracając czas do pierwszego dźwięku, ale generują więcej wiadomości i trochę większy narzut na kawałek. Większe są wydajniejsze w transporcie, ale użytkownik dłużej czeka na pierwszy fragment. Dla agentów interaktywnych lepiej wybrać mniejsze kawałki na początku wypowiedzi – bo na nie użytkownik czeka. Kolejne docierają już podczas odtwarzania, więc ich wielkość ma mniejsze znaczenie.

Odtwarzacz odpowiada za sporą część pozostałego opóźnienia. Większość odtwarzaczy nie zaczyna grać od pierwszego bajtu – buforują trochę, żeby uniknąć zacięć przy chwilowym spowolnieniu streamu. Domyślny bufor to często 500 ms i jest on dodawany bezpośrednio do odczuwanego opóźnienia. Zmniejszenie go to kompromis: trochę większe ryzyko zacięć za niższe TTFA. Optymalna wartość zależy od jittera sieci między serwerem a klientem:

• Przy stabilnym połączeniu (odtwarzanie po stronie serwera, klient w tej samej lokalizacji) bufor 50–150 ms jest zwykle bezpieczny i wyraźnie skraca TTFA.
• Przy niestabilnym połączeniu mobilnym lub między regionami większy bufor zapobiega przerwom w dźwięku, które są gorsze niż samo opóźnienie.

Dokładna konfiguracja zależy od twojego przypadku i priorytetów.

Wybór kodeka

To, dokąd trafia audio, powinno decydować o wyborze kodeka. Zwracamy formaty takie jak mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 i ulaw_8000. Dopasowanie formatu do transportu usuwa krok transkodowania i pomaga w optymalizacji opóźnień agenta głosowego.

Dla telefonii (np. Twilio i podobnych) użyj ulaw_8000. Sieć telefoniczna działa w 8 kHz mu-law end-to-end, więc żądając tego formatu, omijasz transkodowanie i dostarczasz to, czego oczekuje operator. Nie ma sensu generować audio o wyższej jakości, które sieć i tak natychmiast obetnie – tylko dodasz opóźnienie, a nic nie zyskasz.

Dla WebRTC i odtwarzania w przeglądarce użyj PCM (pcm_24000 lub pcm_16000) albo MP3. PCM jest nieskompresowane, więc klient nie musi dekodować – to usuwa trochę opóźnienia na kawałek i jest wygodne, gdy korzystasz bezpośrednio z Web Audio. MP3 jest mniejsze, co pomaga przy słabym łączu, ale wymaga lekkiego dekodowania po stronie klienta.

Geografia i odległości w sieci

Wszystkie powyższe optymalizacje zakładają, że bajty mają do pokonania krótką drogę. Geografia wyznacza dolną granicę twojego budżetu opóźnień, więc warto ją sprawdzić, zanim zaczniesz tuning.

Obsługujemy żądania z klastrów w Ameryce Północnej, Europie i Azji Południowo-Wschodniej, a każde żądanie trafia automatycznie do najbliższego klastra. Sieciowy round-trip przez publiczny internet to zwykle 20–200 ms, zależnie od odległości, i nie da się go skrócić bez zmiany lokalizacji infrastruktury.

Agent, który wydaje się natychmiastowy w San Francisco (blisko klastra w Ameryce Północnej), może być wolny dla użytkownika w Azji Południowej, którego ruch dwa razy przekracza ocean.

Rozwiązanie: umieść swoje serwery aplikacji blisko użytkowników, nie tylko nas. Jeśli twoi użytkownicy są w Europie, uruchom backend agenta w Europie, żeby skrócić trasę użytkownik–twój serwer; my zadbamy o trasę twój serwer–model z najbliższego klastra.

Samodzielny pomiar opóźnień agenta głosowego

Liczby w tabeli budżetu opóźnień powyżej to orientacyjne zakresy do planowania. Twoje własne liczby powinny pochodzić ze skryptu jak poniżej, uruchomionego na twoim wdrożeniu.

Poniższy kod mierzy TTFA dla etapu TTS osobno – od żądania do pierwszego fragmentu audio, przez wiele prób, i raportuje percentyle. Uruchamiaj go z tego samego regionu, w którym działają twoje serwery, nie z komputera deweloperskiego. Zakłada użycie klienta elevenlabs z wcześniejszego przykładu:

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`);

Kilka rzeczy do zapamiętania:

• Raportuj P50 i P95:Skup się na tych wartościach, nie na średniej. Średnia ukrywa ogon, a to ogon sprawia, że agent wydaje się zawodny. P95 to doświadczenie jednej tury na dwadzieścia.
• Testuj w różnych lokalizacjach: Uruchom ten sam skrypt z każdego regionu, który obsługujesz, i trzymaj wyniki osobno.
• Rozdzielaj żądania dla dokładności:Rozstaw żądania w czasie (setTimeout powyżej). Jeśli wyślesz je naraz, mierzysz własne kolejki, a nie usługę. Po przekroczeniu limitu równoległości żądania trafiają do kolejki (zwykle +50 ms), a po przekroczeniu pojemności dostajesz HTTP 429.
• Mierz cały łańcuch opóźnień:Zastosuj ten sam wzorzec pomiaru do pozostałych etapów. Owiń finalizację STT, pierwszy token LLM i start odtwarzacza w performance.now(), a wypełnisz własną tabelę budżetu i zobaczysz, który etap wymaga optymalizacji.

Stosując te wskazówki, samodzielnie zmierzysz opóźnienia agenta głosowego i ustalisz, czym zająć się najpierw.

Co najbardziej skraca opóźnienia agenta głosowego?

Jeśli chcesz szybko poprawić wyniki, skup się na tych zmianach.

W kolejności wpływu, te metody najbardziej skracają opóźnienia agenta:

• Uruchamiaj LLM na stabilnych częściach STT, żeby ukryć opóźnienie endpointingu.
• Streamuj tokeny LLM do TTS na granicach zdań, żeby synteza pierwszego zdania zachodziła na generowanie drugiego.
• Streamuj audio TTS do odtwarzacza i ustaw bufor na najniższą wartość, jaką toleruje twoja sieć.
• Użyj Flash i głosu domyślnego lub IVC dla najniższego TTFA, a kodek dopasuj do transportu (ulaw_8000 dla telefonii, PCM lub MP3 dla przeglądarki/WebRTC).
• Umieść serwery blisko użytkowników i mierz osobno dla każdego regionu – bo trasy sieciowe są realne i różne.

Więcej technik znajdziesz w poradniku optymalizacji opóźnień dla deweloperów. Pełne przykłady znajdziesz w API quickstart i poradniku o streamingu.

Chcesz szybciej korzystać z gotowych kaskad agentów?ElevenAgents wdraża ten pipeline z optymalizacjami nakładania już na starcie.

Buduj agentów głosowych z niskim opóźnieniem z ElevenAgents

Optymalizacja opóźnień agenta głosowego wymaga pomiaru każdego etapu i nakładania ich na siebie, żeby najwolniejsze działały w tle. Możesz zbudować i dostroić taką kaskadę samodzielnie, korzystając z powyższych wzorców, albo zacząć od pipeline’u z gotowymi optymalizacjami.

ElevenAgents wdraża całą tę kaskadę – od streamingu STT, przez tokeny LLM, po Flash TTS – z technikami nakładania już wbudowanymi. Zamiast zaczynać od zera, dostrajasz tylko progi pod swoje potrzeby.

Zacznij od ElevenAgents, żeby stworzyć agenta już dziś lub skontaktuj się z działem sprzedaży po więcej informacji.

FAQ o optymalizacji opóźnień agenta głosowego