Fix simples para latência de cauda em aplicações LLM

Problema de latência de cauda em voz

A HOAi descreve um problema de latência de cauda em um agente de voz que atende chamadas telefônicas. Cada turno de conversa aciona uma solicitação a um LLM. Na maior parte das respostas, o retorno ocorre em até 1,5 segundo, mas ocasionalmente uma solicitação leva de 10 a 20 segundos. Em uma ligação telefônica, isso se traduz em longos períodos de silêncio, o que pode fazer o interlocutor desligar.

O artigo afirma que o problema é mais frequente do que parece. Uma chamada típica tem de 20 a 30 turnos. Se 1% das solicitações ao LLM forem excessivamente lentas, uma ligação de 25 turnos tem cerca de 22% de chance de encontrar um silêncio prolongado.

Alternativas avaliadas

A equipe apresenta duas opções diante do problema. A primeira era contratar um tier de prioridade do provedor, pagando o dobro do custo por token por respostas mais rápidas e consistentes. A segunda era permanecer no tier padrão e duplicar cada solicitação, usando a resposta que chegasse primeiro. O texto menciona que provedores como Anthropic, OpenAI e Gemini oferecem camadas de prioridade sob nomes diferentes, embora o teste descrito use o tier de prioridade da OpenAI.

Metodologia e resultados

Foram repetidas 50 solicitações reais de produção nos dois arranjos. As métricas rastreadas foram o tempo até o primeiro token, momento em que o agente começa a falar, e o tempo até a resposta completa, quando o sistema pode agir sobre chamadas de ferramentas.

No tempo até o primeiro token, o tier de prioridade teve mediana de 0,61 segundo, p95 de 1,04 segundo e p99 de 4,2 segundos. O tier padrão com envio duplo teve mediana de 0,58 segundo, p95 de 0,68 segundo e p99 de 1,2 segundo.

No tempo até a resposta completa, ambos tiveram mediana de 1,35 segundo. No p95, o tier de prioridade marcou 3,4 segundos, contra 2,0 segundos do envio duplo. No p99 e no pior caso, o tier de prioridade ficou em 9,8 segundos, enquanto o envio duplo ficou em 3,5 segundos.

Segundo o artigo, enviar cada solicitação duas vezes superou claramente o tier de prioridade, reduzindo o pior caso de tempo de resposta de 9,8 para 3,5 segundos e o pior caso de tempo até o primeiro token de 4,2 para 1,2 segundo. A mediana empatou com o tier de prioridade, apesar de o tier padrão ser individualmente mais lento.

Condição e recomendação

O autor ressalva que o mecanismo funciona quando respostas lentas são raras e independentes, pois enviar a solicitação duas vezes torna improvável que ambas as cópias sejam lentas no mesmo turno. A recomendação final é que equipes que constroem produtos interativos de LLM em tempo real comparem, por meio de benchmark, o custo de um tier mais rápido com a estratégia de duplicar solicitações antes de pagar pela camada superior. O artigo sustenta que essa alternativa pode oferecer melhor latência pelo mesmo custo, mas não afirma que serve para todos os cenários.