Het artikel behandelt het probleem van 'tail latency' bij Large Language Models (LLM's), specifiek binnen de context van real-time voice agents waarbij incidentele vertragingen van 10 tot 20 seconden leiden tot een slechte gebruikerservaring. De auteur vergelijkt twee strategieën om dit op te lossen: het upgraden naar een kostbare 'priority tier' van de provider of het simpelweg dubbel verzenden van elk verzoek op de standaard tier.
Uit tests met productieverzoeken blijkt dat het dubbel verzenden van verzoeken superieur is. De resultaten tonen aan dat de p95- en p99-latentie voor zowel het eerste token als de volledige reactie aanzienlijk lager liggen dan bij de priority tier. De conclusie is dat ontwikkelaars van interactieve LLM-producten deze methode zouden moeten benchmarken voordat ze investeren in duurdere servicelagen.
Een eenvoudige oplossing voor LLM tail latency
Wanneer LLM-reacties te traag zijn voor uw real-time use case, bent u wellicht geneigd om het dubbele te betalen voor een snellere servicelaag. De Priority tier van Anthropic, priority processing van OpenAI, priority inference van Gemini, whatever uw LLM-provider het noemt. Er is een eenvoudigere oplossing: stuur elk verzoek twee keer en neem de snelste reactie.
Waarom tail latency belangrijk is voor voice agents
Onze voice agent bij HOAi beantwoordt telefoongesprekken. Elke beurt in een gesprek resulteert in een LLM-verzoek. De meeste reacties komen binnen 1,5 seconde terug, maar af en toe duurt er een 10 tot 20 seconden. In een telefoongesprek betekent dat 10 seconden ongemakkelijke stilte, en na voldoende stilte hangt de beller op.
Dit gebeurt vaker dan u denkt. Een typisch telefoongesprek heeft 20 tot 30 beurten. Als 1% van de LLM-verzoeken catastrofaal traag is, heeft een gesprek van 25 beurten ongeveer 22% kans om een lange stilte te ervaren.
Priority tier versus elk verzoek twee keer verzenden
We hadden twee opties:
- Upgraden naar de priority tier van OpenAI en 2x de kosten per token betalen voor snellere, consistentere reacties.
- Blijven op de standaard tier, maar elk verzoek twee keer verzenden en de snelste reactie gebruiken.
We hebben 50 echte productieverzoeken getest tegen beide opstellingen en hebben twee statistieken bijgehouden: de tijd tot het eerste token (wanneer de agent begint te spreken) en de tijd tot de volledige reactie (wanneer de agent actie kan ondernemen op tool-aanroepen).
Tijd tot het eerste token
| Priority tier | Standaard tier, twee keer verzonden |
|---|
| Mediaan | 0,61s | 0,58s |
| p95 | 1,04s | 0,68s |
| p99 | 4,2s | 1,2s |
Tijd tot volledige reactie
| Priority tier | Standaard tier, twee keer verzonden |
|---|
| Mediaan | 1,35s | 1,35s |
| p95 | 3,4s | 2,0s |
| p99 | 9,8s | 3,5s |
| Worst-case | 9,8s | 3,5s |
Het twee keer verzenden van het verzoek presteerde duidelijk beter dan de priority tier. De worst-case tijd voor een volledige reactie daalde van 9,8s naar 3,5s. De worst-case tijd tot het eerste token daalde van 4,2s naar 1,2s. Zelfs de mediaan kwam exact overeen met de priority tier, ondanks dat de standaard tier per individueel verzoek trager is.
Dit werkt wanneer trage reacties zeldzaam en onafhankelijk zijn. Door het verzoek twee keer te verzenden, is de kans klein dat beide kopieën in dezelfde beurt traag zijn. Dit heeft de stiltes van 10 seconden die onze bellers ervoeren aanzienlijk verminderd.
De belangrijkste conclusie
Als u een real-time interactief LLM-product bouwt, benchmark dan eerst het dubbel verzenden van verzoeken voordat u betaalt voor een snellere servicelaag. Het kan zijn dat u een betere latentie krijgt tegen dezelfde kosten.
Een eenvoudige oplossing voor LLM tail latency
Wanneer LLM-reacties te traag zijn voor uw real-time use case, bent u wellicht geneigd om het dubbele te betalen voor een snellere servicelaag. De Priority tier van Anthropic, priority processing van OpenAI, priority inference van Gemini, whatever uw LLM-provider het noemt. Er is een eenvoudigere oplossing: stuur elk verzoek twee keer en neem de snelste reactie.
Waarom tail latency belangrijk is voor voice agents
Onze voice agent bij HOAi beantwoordt telefoongesprekken. Elke beurt in een gesprek resulteert in een LLM-verzoek. De meeste reacties komen binnen 1,5 seconde terug, maar af en toe duurt er een 10 tot 20 seconden. In een telefoongesprek betekent dat 10 seconden ongemakkelijke stilte, en na voldoende stilte hangt de beller op.
Dit gebeurt vaker dan u denkt. Een typisch telefoongesprek heeft 20 tot 30 beurten. Als 1% van de LLM-verzoeken catastrofaal traag is, heeft een gesprek van 25 beurten ongeveer 22% kans om een lange stilte te ervaren.
Priority tier versus elk verzoek twee keer verzenden
We hadden twee opties:
- Upgraden naar de priority tier van OpenAI en 2x de kosten per token betalen voor snellere, consistentere reacties.
- Blijven op de standaard tier, maar elk verzoek twee keer verzenden en de snelste reactie gebruiken.
We hebben 50 echte productieverzoeken getest tegen beide opstellingen en hebben twee statistieken bijgehouden: de tijd tot het eerste token (wanneer de agent begint te spreken) en de tijd tot de volledige reactie (wanneer de agent actie kan ondernemen op tool-aanroepen).
Tijd tot het eerste token
| Priority tier | Standaard tier, twee keer verzonden |
|---|
| Mediaan | 0,61s | 0,58s |
| p95 | 1,04s | 0,68s |
| p99 | 4,2s | 1,2s |
Tijd tot volledige reactie
| Priority tier | Standaard tier, twee keer verzonden |
|---|
| Mediaan | 1,35s | 1,35s |
| p95 | 3,4s | 2,0s |
| p99 | 9,8s | 3,5s |
| Worst-case | 9,8s | 3,5s |
Het twee keer verzenden van het verzoek presteerde duidelijk beter dan de priority tier. De worst-case tijd voor een volledige reactie daalde van 9,8s naar 3,5s. De worst-case tijd tot het eerste token daalde van 4,2s naar 1,2s. Zelfs de mediaan kwam exact overeen met de priority tier, ondanks dat de standaard tier per individueel verzoek trager is.
Dit werkt wanneer trage reacties zeldzaam en onafhankelijk zijn. Door het verzoek twee keer te verzenden, is de kans klein dat beide kopieën in dezelfde beurt traag zijn. Dit heeft de stiltes van 10 seconden die onze bellers ervoeren aanzienlijk verminderd.
De belangrijkste conclusie
Als u een real-time interactief LLM-product bouwt, benchmark dan eerst het dubbel verzenden van verzoeken voordat u betaalt voor een snellere servicelaag. Het kan zijn dat u een betere latentie krijgt tegen dezelfde kosten.
Groetjes,