🚀 Desvendando o Segredo da Conversa Fluida com IAs: Por Que o "Primeiro Token" Engana Você!

Olá, pessoal! Aqui é o Lucas Tech, e hoje a gente vai mergulhar em um tópico que parece bem técnico, mas que faz toda a diferença na hora de interagir com aqueles assistentes de voz que a gente tanto usa – sabe, aqueles que às vezes parecem ler sua mente ou, em outros momentos, te deixam no vácuo? Pois é, estamos falando da latência em agentes de voz com Inteligência Artificial!

Muita gente foca no "Time to First Token" (TTFT), que é o tempo que leva para o modelo começar a gerar a primeira palavra. Mas e se eu te disser que essa métrica, sozinha, pode te enganar e muito quando o assunto é voz? Para ter uma conversa fluida e natural com uma IA, o tempo é ouro, e cada milissegundo conta. Vamos entender por que o TTFT é só o começo da história e o que realmente importa para que uma IA de voz pareça… humana!

TTFT: O Ponto de Partida Certo, o Ponto de Chegada Errado

Imagine a seguinte situação: você faz uma pergunta para uma IA de voz. O "Time to First Token" (TTFT) mede o tempo que leva desde que você envia sua pergunta até o modelo de linguagem (LLM) começar a "pensar" na resposta e gerar o primeiro pedacinho dela. Para um chat de texto, isso é quase tudo, né? Você vê a primeira palavra e já sabe que a IA está respondendo.

Mas para voz, a coisa muda de figura! Um modelo de Texto-para-Fala (TTS) não consegue falar "meia palavra". Ele precisa de uma frase ou cláusula completa para conseguir sintetizar o áudio. É por isso que o TTFT, sozinho, não te diz o quão rápido a IA vai começar a falar. A LiveKit, uma empresa fera nessa área, chama a métrica que realmente importa de Time-to-First-Sentence (TTFS), ou seja, o "tempo para a primeira frase". É isso que a gente, como usuário, realmente sente!

Pense nisso como ter dois botões: o TTFT controla quando a geração começa, e os "tokens por segundo" controlam o quão rápido a primeira frase termina. Se um provedor é super rápido para começar, mas lento para terminar a frase, a experiência final não vai ser boa. É um equilíbrio delicado!

O Orçamento da Latência: O Custo de Uma "Virada" de Conversa

Construir um agente de voz é como gerenciar um orçamento apertado, mas de tempo. Cada etapa gasta milissegundos que o usuário consegue perceber. A LiveKit, por exemplo, detalha o que acontece em uma "virada" de conversa (onde a IA responde):

• Fala-para-Texto (STT): Ouve o que você diz e transforma em texto. Custa uns 100-200ms.
• Modelo de Linguagem (LLM): Pensa na resposta e a gera. Com streaming, 300-500ms.
• Texto-para-Fala (TTS): Transforma o texto da resposta em áudio. Mais 100-200ms.
• Rede (WebRTC): A comunicação entre todos esses pontos. Mais 50-150ms.

Somando tudo, o tempo ideal para uma interação completa (do seu "falei" ao "ouvi a resposta") fica entre 700ms e 1.2 segundos.

Kwindla Hultman Kramer, um dos criadores da Pipecat, sugere um alvo ainda mais ambicioso: 800ms de latência média voz-a-voz. Para uma prova de conceito, 1.5 segundo ainda é aceitável.

Curiosidade humana: Em uma conversa normal entre pessoas, o tempo de resposta é de cerca de 500ms. Pausas maiores que 800ms já começam a parecer estranhas e desconfortáveis. Ninguém gosta de ser "deixado no vácuo" por uma IA, né?

Isso significa que, dentro do nosso orçamento de 1.5 segundo para uma conversa natural, o LLM (que é o cérebro da coisa) tem um orçamento de TTFT de cerca de 700ms. Esse é o padrão de excelência que precisamos buscar para cada provedor!

Como Entender um Benchmark de TTFT Sem Cair em Armadilhas

Antes de olharmos para os números, é crucial entender algumas regras do jogo que mudam completamente o significado dos dados. Afinal, a metodologia importa!

1. A Carga de Trabalho Faz Toda a Diferença

A Artificial Analysis, um site de benchmarks super respeitado, mudou sua carga de trabalho padrão. Agora eles usam prompts de 10 mil tokens de entrada, em vez de 1 mil. Por quê? Prompts mais longos aumentam tanto o TTFT quanto a velocidade de saída, mas a LiveKit argumenta que isso está mais próximo da realidade para agentes de voz. IAs de produção precisam "carregar" muita coisa: regras de negócio, a persona da IA, dados recuperados e até as ferramentas que ela pode usar.

2. A Localização do Servidor é Crucial

Os testes da Artificial Analysis são feitos de uma máquina virtual em uma zona específica da Google Cloud (us-central1-a). O TTFT sempre inclui a latência da rede, e isso pode beneficiar ou prejudicar provedores dependendo de onde seus servidores estão localizados em relação ao ponto de teste. Pense no Wi-Fi da sua casa: às vezes, o problema não é o computador, mas a conexão!

3. Tokens de Raciocínio Contam

Para modelos que precisam "raciocinar" antes de dar uma resposta direta, o TTFT, na definição da Artificial Analysis, é o primeiro token de raciocínio, não o primeiro token da resposta final. Fique de olho, são colunas diferentes!

4. Meça do Lado do Cliente

A Daily, outra empresa importante no setor, alerta: provedores de modelos às vezes citam o TTFT interno às suas próprias pilhas de inferência. Mas o que importa para a gente é o tempo desde que a requisição é enviada até o primeiro token utilizável ser recebido pela API. É a experiência real, não a interna!

5. Os Testes Não São Repetíveis (Exatamente)

A Daily é bem direta: o TTFT varia bastante entre diferentes testes. Além disso, os provedores vivem mudando suas pilhas de inferência e, às vezes, até os "pesos" dos modelos sem mudar o nome. É um campo em constante evolução, então um benchmark de hoje pode não ser o mesmo de amanhã!

Camada 1: LLM – O Tempo para o Primeiro Token

Ok, agora que entendemos as regras, vamos aos números! Os dados abaixo vêm da Artificial Analysis (coletados em 30 de agosto de 2026), considerando uma carga de trabalho de 10 mil tokens de entrada e um único prompt.

Latência Mais Baixa para o Primeiro "Pedaço" (Chunk)

Olha só: Baseten está mandando muito bem com 0.23s! Isso é super rápido. Mas perceba que a Cerebras, embora tenha um TTFT um pouco maior (0.49s), tem uma velocidade de saída absurda (1.697 tok/s). Lembra que eu falei do TTFT e dos "tokens por segundo"? É aqui que a mágica acontece!

A Armadilha da Produtividade (Throughput Trap)

Vendedores de hardware (silício) muitas vezes otimizam seus sistemas para uma métrica diferente do que os agentes de voz precisam: a produtividade (throughput), ou seja, quantos tokens eles conseguem gerar por segundo.

O caso do Mercury 2 é um exemplo clássico. Ele gera 770 tokens por segundo, o que é rápido. MAS, o primeiro "pedaço" só chega depois de 3.07 segundos! Isso é quatro vezes o orçamento total de TTFT que a gente tem para uma conversa natural. Imagine a IA pensando por 3 segundos antes de soltar a primeira palavra. Frustrante, né?

Cerebras e Groq são um caso diferente: o TTFT deles é bom, e a produtividade é excepcional. Para o TTFS (tempo para a primeira frase), essa combinação é poderosa, porque a frase é completada quase que instantaneamente depois que o primeiro token chega!

Endpoints de Fronteira e Proprietários

Fique de olho: O mesmo modelo, o GPT-5.6 Luna (sem raciocínio), tem 0.59s no Amazon Bedrock e 0.74s na API da própria OpenAI. Isso mostra que a hospedagem e o roteamento são tão importantes quanto o modelo em si!

O "Ponto Fora da Curva" Medido pelo Fornecedor

A LiveKit publica números de TTFT para seu próprio produto de inferência. Eles conseguiram um impressionante 192ms para o Gemma 4 31B em sua infraestrutura, contra 911ms para o Gemini 2.5 Flash e até 1.876ms para o mesmo Gemma 4 31B via OpenRouter.

Como eles fazem isso? Com um truque chamado SGLang e decodificação especulativa, além de usar as GPUs de forma "subutilizada" de propósito para evitar atrasos na fila. O lado negativo é o custo: US$1.20 por milhão de tokens de saída. Eles são transparentes, o que é ótimo!

Além disso, a LiveKit também reporta o TTFS em conversas completas: 354ms para o Gemma 4 31B na LiveKit, contra mais de 1 segundo para outros modelos populares. Isso é um resultado e tanto para a fluidez da conversa!

Camada 2: Fala-para-Texto (STT) e Detecção de "Fim de Turno"

Para agentes de voz, a latência do STT não é apenas a velocidade da transcrição. É quanto tempo depois que o usuário para de falar que o sistema sabe que ele parou de falar. Essa detecção é crucial para a IA começar a responder rapidamente.

A Artificial Analysis mede duas coisas em sua tabela de STT de streaming: tempo para a primeira transcrição parcial e tempo para a transcrição final.

Números de Latência Publicados pelos Fornecedores

O Deepgram Flux é interessante porque ele integra a detecção de fim de turno diretamente no modelo de reconhecimento, em vez de usar um VAD (Voice Activity Detection) separado. Eles dizem que isso pode reduzir a latência de resposta do agente em 200-600ms! Eles até permitem que você comece o LLM mais cedo com um sinal de "EagerEndOfTurn". Se a IA adivinhar certo que você terminou de falar, ela já começa a pensar na resposta enquanto você ainda está falando a última palavra. Genial!

O AssemblyAI Universal-Streaming inverte o modelo tradicional (parciais e depois final) emitindo transcrições imutáveis. Em seus próprios testes, eles reportaram 307ms para emissão de palavra, contra 516ms para o Deepgram Nova-3.

Atenção: As alegações de precisão aqui são dos próprios fornecedores e podem ser contestadas. Sempre é bom testar você mesmo!

A LiveKit também fala sobre a geração preemptiva, que inicia o LLM com uma transcrição parcial. A ressalva é real: se a IA tiver que gerar a resposta novamente porque a transcrição final foi diferente, você gasta tokens à toa e não economiza nada. É um risco.

Camada 3: Texto-para-Fala (TTS) – Tempo para o Primeiro Áudio

Aqui é onde os números dos fornecedores mais se afastam da experiência real do usuário.

A ElevenLabs afirma que o Flash v2.5 entrega aproximadamente 75ms. MAS, eles mesmos qualificam isso: 75ms é apenas o tempo de inferência do modelo. A página de conceitos de latência deles vai além, listando um round-trip de rede de 20-200ms e, o mais importante, que a maioria dos players de áudio fazem um buffer de 500ms antes de tocar! Ou seja, o usuário provavelmente vai esperar bem mais que 75ms. Eles recomendam o Flash v2.5 para tempo real, não o Eleven v3.

A Cartesia afirma ter TTS abaixo de 90ms para o Sonic-3.6 e Ink-2. Novamente, essa é a latência do modelo, não o tempo total que você, como usuário, vai experimentar. O Sonic usa modelos de espaço de estado em vez de transformadores, o que ajuda na escalabilidade.

Qualidade do TTS (Avaliação por Ouvintes)

A Artificial Analysis tem um ranking de qualidade baseado na avaliação cega de ouvintes. É tipo uma disputa de Elo para ver quem tem a voz mais natural.

Perceba a diferença entre o Sonic 3.6 (1.288) e o Flash v2.5 (1.083). Essa diferença no Elo representa o custo de qualidade para ter aquela baixa latência que a maioria dos agentes realmente precisa. Você troca um pouco de "naturalidade" por velocidade.

Camada 4: Fala-para-Fala (S2S) – Tempo para o Primeiro Áudio

Modelos de "Fala-para-Fala" (Speech-to-Speech) tentam colapsar tudo – STT, LLM e TTS – em uma única passada. A ideia é que menos "idas e vindas" deveriam significar menor latência.

Mas a LiveKit é cautelosa, lembrando que modelos em tempo real não são garantidamente mais rápidos em todos os casos. Uma boa arquitetura "cascateada" (onde cada etapa é separada) pode ser muito competitiva.

Os dados corroboram essa cautela. Do ranking da Artificial Analysis para S2S (TTFA = Tempo para o Primeiro Áudio):

Destaque: O Grok Voice Think Fast 2.0 High se destaca com 0.70s de TTFA, 97% de raciocínio de fala e 94.7% de sucesso na tarefa. Isso é um show!

Dá pra ver claramente o "custo" do raciocínio. O Gemini 3.1 Flash Live vai de 0.96s para 2.99s entre as versões "Minimal" e "High". A OpenAI reduziu a latência da "cauda" (p95) em 25% em seus modelos Realtime. Isso é super importante, porque é justamente a latência nos 5% dos piores casos que faz um agente de voz parecer "quebrado" ou falho.

A Lacuna de Capacidade

A Daily quantifica por que a maioria dos agentes de produção ainda usa pipelines "cascateadas" (as etapas separadas). Em seus testes, o GPT Realtime marcou 86.7% contra 94.9% do GPT-4.1. Ou seja, os modelos S2S ainda não são tão capazes quanto os modelos LLM separados para tarefas complexas.

É interessante notar que, entre os sistemas "cascateados" padrão de alguns fornecedores (Deepgram, ElevenLabs, Cartesia, Inworld), três dos quatro usam o Gemini 2.5 Flash como LLM. Um consenso revelador, não acham?

Orçamentos de Referência: O Que Esperar na Prática

Vamos montar um "orçamento" de latência com os números que vimos, pensando em cenários reais.

Pipeline Cascatedo Agressivo (Servidor nos EUA, Co-localizado)

Isso se encaixa bem ou até um pouco acima da meta de 800ms do Kwindla, mostrando que é ambicioso, mas possível!

Fala-para-Fala (S2S), Modelo Único

É um tempo comparável, mas com menos visibilidade (é uma caixa preta) e, segundo os benchmarks, com uma lacuna de capacidade perceptível para tarefas complexas, como uso de ferramentas ou seguir instruções.

O Que Fazer Com Toda Essa Informação?

Com tanta coisa nova e tão rápida, como a gente se vira para criar agentes de voz realmente úteis e que pareçam naturais?

• Escolha a métrica certa: Se você tem um modelo TTS na sua arquitetura, foque em otimizar o TTFS, não apenas o TTFT. Isso significa que o TTFT e os "tokens por segundo" precisam trabalhar juntos.
• Co-localize antes de otimizar modelos: O impacto da co-localização (colocar o agente e o modelo LLM no mesmo servidor ou próximos) é GIGANTESCO! Mais importante que escolher o modelo mais rápido às vezes. Se você usa SIP, mantenha o tronco geograficamente próximo também.
• Limite o esforço de raciocínio: Essa é a maior alavanca de TTFT que vimos nas tabelas. A maioria dos endpoints modernos tem uma flag de configuração para isso. Menos raciocínio, mais velocidade!
• Orçamento para chamadas de ferramentas: Qualquer "virada" de conversa que envolva a IA chamando uma ferramenta (tipo, "qual a previsão do tempo?") praticamente dobra a latência do LLM. Limite os passos, consolide chamadas de API externas e, o mais importante, toque um som de "pensando" para que o usuário não fique no silêncio total.
• Instrumente antes de ajustar: Meça tudo! O SDK da LiveKit Agents mostra a latência de ponta a ponta (e2e_latency), TTFT do LLM e tempo para o primeiro byte do TTS por turno. Registre esses dados e fique de olho para qualquer regressão (quando algo fica mais lento).
• Meça o p95, não apenas o p50: A melhora da OpenAI foi na latência da "cauda" (p95). O p50 é a média, mas o p95 te mostra os 5% piores casos. É aí que os agentes de voz "quebram" e a experiência vira frustração.
• Cuidado com as armadilhas da infraestrutura: Agentes auto-hospedados em tipos de instâncias "burstáveis" da AWS (como t3 ou t4g) podem ter problemas sérios de latência e timeouts, mesmo com uso de CPU aparentemente baixo. Fique de olho na sua infra!

Principais Aprendizados (O Resumão do Lucas Tech!)

• O TTFT mais rápido para uma carga de 10k tokens (medido independentemente) foi da Baseten com gpt-oss-120b: 0.23 segundos! Voando baixo!
• Produtividade e TTFT são diferentes: A Cerebras atinge 1.697 tokens/s, mas com TTFT de 0.49s. Já o Mercury 2 da Inception tem 770 tokens/s, mas com um TTFT altíssimo de 3.07s. Não confunda!
• As promessas de latência dos fornecedores (tipo 75ms da ElevenLabs ou menos de 90ms da Cartesia) são APENAS o tempo de inferência do modelo. Elas não contam com a rede ou o buffer do player de áudio (que pode ser de 500ms!).
• O esforço de raciocínio é a maior alavanca do TTFT: o Gemini 3.1 Flash Live vai de 0.96s para 2.99s quando você aumenta o nível de raciocínio (de "Minimal" para "High").
• Só o TTFT não te diz como o agente se sente. O que realmente importa para a conversa é o Tempo para a Primeira Frase (TTFS), porque a síntese de voz precisa de uma cláusula completa para começar a falar.

Minha Visão

Galera, essa discussão sobre latência e as diferentes métricas é fascinante, mas o impacto dela vai muito além dos números. Ela define se um assistente de voz será um aliado útil e agradável ou uma fonte de frustração. Para mim, a grande sacada é que a tecnologia está avançando tão rápido que já não é mais suficiente ter um modelo "inteligente"; ele precisa ser fluido, responsivo e parecer natural na interação. Ver as empresas brigando por milissegundos e explorando arquiteturas complexas como S2S ou pipelines cascateadas otimizadas mostra que o futuro das nossas interações com IAs está em um ponto de virada emocionante. É sobre construir uma experiência onde a máquina quase desaparece, e a conversa flui como se fosse com outra pessoa. A tecnologia aqui não é só sobre performance, mas sobre a humanização da experiência digital.

E você, o que achou desses dados? Já teve alguma experiência frustrante (ou incrível!) com agentes de voz que te fez pensar na latência? Conta pra mim nos comentários! 👇

Referência: Matéria Original

Posts relacionados:

Cansado de esperar pela nova versão da assistente de voz? Experimente esses assistentes de IA avançados no seu iPhone hoje mesmo. Esta atualização do Google Chrome pode transformar a navegação – descubra quem poderá experimentá-la primeiro. Apple e a IA generativa: Quem realmente depende de quem? Blade Runner 2099: O PRIMEIRO vislumbre da SDCC!