Modelo rápido de IA: quando a velocidade da resposta vale mais que a melhor resposta?

Resposta melhor não é a mesma coisa que resposta que chega a tempo

Numa interface, uma resposta excelente que demora 8 segundos pode valer menos que uma resposta boa que aparece em 1 segundo, porque o usuário já saiu do fluxo, já clicou em outra coisa, já desistiu

Só que essa troca tem hora certa pra acontecer

Esse post separa os cenários em que velocidade é o requisito principal daqueles em que descer de modelo sai caro, e mostra as alavancas que dão velocidade SEM você precisar trocar de modelo. Bora?

A régua da latência: 0,1s, 1s e 10s

Antes de olhar benchmark, olha a régua da interface

Os limites clássicos de tempo de resposta são três: 0,1 segundo é o que parece instantâneo pro usuário, 1 segundo mantém o fluxo de pensamento dele (ele sente a demora, mas não perde a linha), e 10 segundos é o limite pra manter a atenção na tarefa

Se liga que essa régua não fala nada de qualidade de modelo

Ela fala de percepção. É ela que define o requisito do seu produto, não a nota do modelo em benchmark

TTFT e TTFAT: o que exatamente você está medindo?

Quando alguém diz "esse modelo é rápido", quase sempre a frase está escondendo duas métricas diferentes

A primeira é o TTFT (time to first token): o tempo entre enviar a requisição e receber o primeiro token da resposta. Em modelos de raciocínio existe uma variação, o time to first answer token, que é medido depois do tempo de "thinking", conforme a metodologia de benchmarking da Artificial Analysis

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

A segunda é a velocidade de saída, em tokens por segundo, ou seja, o quão rápido o texto continua saindo depois que começou

E aí vem um detalhe que muita gente ignora: TTFT inclui latência de rede

Isso quer dizer que ele é sensível à localização do servidor. A Artificial Analysis, por exemplo, roda o servidor primário de teste na zona us-central1-a do Google Cloud, o que pode favorecer ou prejudicar um provedor dependendo de onde a infraestrutura dele está

Tome cuidado com isso na hora de comparar número de terceiro com o que você mede aí no seu produto: pode não ser o mesmo jogo

Cada cenário pressiona uma métrica diferente

Autocomplete e sugestão durante a digitação pressionam o TTFT, porque o que importa é a coisa COMEÇAR

Geração de um texto longo pressiona tokens por segundo, porque o começo já apareceu e agora o usuário está lendo enquanto o resto sai

Classificação de uma frase curta pressiona os dois, só que a resposta é tão pequena que o TTFT domina a conta

Mesma palavra ("rápido"), três requisitos diferentes

Onde o modelo leve muda a experiência

Agora os casos concretos, aqueles em que um modelo rápido de IA muda a experiência de verdade

Sugestão enquanto o usuário digita e classificação em tempo real. Aqui a resposta compete com o próximo caractere que a pessoa vai digitar. Não é à toa que o Google recomenda o Gemini 3.1 Flash-Lite justamente pra tradução, moderação de conteúdo e geração de interfaces: são tarefas de alto volume onde a espera é visível

Agentes de atendimento e chatbots. É o uso indicado na página do Claude Haiku, que posiciona o Haiku 4.5 pra aplicações em tempo real. Faz sentido: tem gente do outro lado com o cursor piscando

Extração de dados, ranking e subagentes. Esse é o posicionamento da OpenAI pro GPT-5.4 nano, descrito como a versão menor e mais barata do GPT-5.4, pra tarefas em que velocidade e custo pesam mais

Repara no padrão: são tarefas de resposta curta, volume alto e critério objetivo

O efeito do streaming na sensação de espera

Tem um truque de percepção aqui que é quase injusto de tão eficiente

Com streaming, o modelo começa a devolver a resposta antes de terminar a saída completa, e o usuário vê o texto aparecendo em tempo real. A latência total pode ser exatamente a mesma, mas a responsividade PERCEBIDA muda

É a diferença entre a tela congelada e a tela viva

Uma pessoa encarando um spinner por 6 segundos vive um inferno. A mesma pessoa lendo texto que aparece por 6 segundos está ocupada

Os números que existem sobre velocidade

Dado é dado, então vamos só ao que está publicado

A Anthropic afirma que o Haiku 4.5 roda até 4 a 5 vezes mais rápido que o Sonnet 4.5, a uma fração do custo. No anúncio de lançamento, em 15 de outubro de 2025, o posicionamento era de desempenho de código e raciocínio próximo do Sonnet 4.5, custando um terço

Já o Google informa que o Gemini 3.5 Flash-Lite roda a 350 tokens de saída por segundo, conforme medição da Artificial Analysis. E descreve o Gemini 3.1 Flash-Lite como 2,5 vezes mais rápido no Time to First Answer Token e 45% mais rápido na velocidade de saída em relação ao 2.5 Flash

São números declarados por quem vende, beleza? Servem pra dimensionar o degrau, não pra fechar a decisão

Modelos rápidos e preços: Haiku 4.5, Flash-Lite, GPT nano e mini

O bom da faixa leve é que ela é barata E rápida ao mesmo tempo, então o degrau aparece nas duas colunas

Preços por milhão de tokens, entrada e saída:

As duas últimas linhas estão ali só pra você enxergar o tamanho do salto

O preço do Sonnet 5, aliás, era introdutório e virou permanente em 10 de agosto de 2026

Duas notas de disponibilidade

O Haiku 4.5 é o Haiku atual em agosto de 2026, ao lado de Sonnet 5, Opus 5 e Fable 5. Não existe versão Haiku mais recente publicada, então se você viu "Haiku 5" em algum lugar, desconfia

E o Gemini 2.0 Flash-Lite foi desligado em 1º de junho de 2026, não está mais disponível. Se seu código ainda aponta pra ele, já era

Como ganhar velocidade sem descer de modelo

Aqui está o erro mais comum de todos: a pessoa sente lentidão e a primeira coisa que faz é trocar o modelo por um menor

Só que trocar de modelo é a ÚLTIMA alavanca da lista, não a primeira

A documentação da plataforma Claude sobre redução de latência lista três estratégias: escolher um modelo mais rápido, reduzir tokens de prompt e de saída, e usar streaming. E ela é explícita num ponto anterior a tudo isso: otimizar latência é passo posterior, não inicial

Juntando essas estratégias com o que a documentação de prompt caching e a do parâmetro effort trazem, essa é a ordem que eu sigo:

1. Construa primeiro um prompt que funcione bem sem restrição de modelo ou de tamanho. Parece contraintuitivo, mas a recomendação é essa: descubra qual é o teto de qualidade antes de otimizar. O erro comum deste passo: começar já espremido, e aí você nunca fica sabendo se a resposta ruim é do modelo, do prompt ou do corte que você mesmo fez

2. Ligue o streaming. É a alavanca mais barata de todas: o modelo começa a devolver antes de terminar, e a responsividade percebida melhora. O erro comum deste passo: montar uma interface que espera a resposta inteira pra só então renderizar, jogando fora o ganho do streaming

3. Reduza tokens de prompt e de saída. Menos texto entrando e menos texto saindo é menos tempo, em qualquer modelo. O erro comum deste passo: cortar o modelo antes de cortar tokens, que é otimizar a variável errada

4. Use prompt caching. Em prompts longos, o cache reduz a latência em até 85% e o custo em até 90%. É o tipo de ganho que faz a discussão de trocar de modelo até perder a graça

5. Faça cache pre-warming. Aqui é carregar o system prompt ou as definições de ferramentas no cache ANTES da requisição real do usuário. Isso elimina a penalidade de cache miss na primeira interação e reduz o TTFT em aplicações sensíveis a latência. O erro comum deste passo: medir seu TTFT só na primeira chamada fria e concluir que o modelo é lento

6. Ajuste o parâmetro effort. Ele controla quantos tokens o Claude gasta na resposta, trocando profundidade por eficiência DENTRO do mesmo modelo. O padrão é high, medium é o degrau intermediário e low é indicado pra cargas de alto volume ou sensíveis a latência, tipo classificação simples e consultas rápidas. Pra dimensionar: no benchmark DeepWideSearch, o low levou 4,5 minutos por problema contra 7,9 minutos no effort padrão

7. Só então troque por um modelo mais rápido, como o Haiku 4.5. Depois de tudo acima, aí sim a troca de modelo é uma decisão informada e não um chute

Se você quer ir mais fundo nessa escolha por tarefa, eu já escrevi sobre qual modelo usar em cada tarefa por lá

E fecho os passos com o erro que atravessa todos eles: medir TTFT esquecendo que ele inclui rede. Você pode passar a tarde inteira culpando o modelo por um problema que é de região do servidor

Quando trocar qualidade por velocidade é um erro

Agora o outro lado, sem romantismo

A troca de qualidade por velocidade é ruim quando o erro é silencioso e caro

Código que entra em produção. Decisão que segue sem revisão humana. Tarefa longa em que o resultado só é conferido lá no fim, quando já custou tempo de todo mundo

Nesses casos, ninguém está esperando na frente da tela mesmo, então velocidade não é requisito, é vaidade

A diferença medida é pequena no papel

Olha os números do SWE-bench Verified: o Haiku 4.5 marcou 73,3% (média de 50 execuções, sem test-time compute, orçamento de thinking de 128K, nas 500 tarefas do conjunto) contra 77,2% do Sonnet 4.5 (média de 10 execuções, orçamento de thinking de 200K)

Parece pouco, né?

E é pouco, na média. O detalhe é que essa distância não se distribui igualzinho: ela aparece exatamente nos casos difíceis, que são os que você não queria errar. Na tarefa fácil os dois acertam, e o barato ganha fácil. Na tarefa cabeluda o degrau vira o problema inteiro

Esse raciocínio é irmão de outro que já discuti aqui, sobre quando fazer na mão compensa: nem toda tarefa quer a ferramenta mais automática do mundo

Trabalho assíncrono não precisa ser rápido

Esse ponto é subestimado demais

Se o job roda de madrugada, se o resultado cai num relatório, se a fila é processada sem ninguém olhando, velocidade ali não compra NADA de experiência

E tem mais: o processamento em lote (batch) custa 50% menos em todos os modelos Claude, e a leitura de cache reduz o custo do input em até 90%. Ou seja, no assíncrono você consegue qualidade alta com preço baixo, sem precisar sacrificar a nota

Otimizar latência onde ninguém espera é gastar decisão à toa

A escolha nem sempre é binária

Outra coisa: o Haiku 4.5 é um modelo de raciocínio híbrido, com modo de extended thinking opcional (novidade na linha Haiku) e janela de contexto de 200 mil tokens

Então não é só "leve = burro, caro = esperto"

Dá pra ficar no modelo leve e ligar mais raciocínio quando a tarefa pedir, do mesmo jeito que dá pra ficar no modelo forte e baixar o effort pra low em rota de alto volume. São dois botões, e você pode girar os dois

A regra de decisão que eu usaria é uma pergunta dupla: quem está esperando e quanto custa refazer

Se tem alguém esperando e refazer é barato, desce de modelo sem medo. Se ninguém está esperando e refazer é caro, sobe e vai dormir tranquilo 🙂

Conclusão

A decisão de velocidade é por ROTA, não por modelo favorito

O mesmo produto tem rota de autocomplete (onde 1 segundo já é tarde), rota de chat (onde streaming resolve metade do problema) e rota de job noturno (onde velocidade não vale nada e batch corta 50% do custo)

Recapitulando o caminho: use a régua de 0,1s / 1s / 10s pra definir o requisito, entenda se o seu gargalo é TTFT ou tokens por segundo, aplique streaming, corte de tokens, prompt caching, pre-warming e effort ANTES de descer de modelo, e reserve o modelo caro pro que dói errar

Próximo passo bem concreto pra hoje: escolhe UMA rota do teu produto, mede o TTFT dela de verdade (lembrando que rede entra na conta), e roda a mesma rota com effort baixo ou com o modelo leve antes de decidir qualquer coisa

Medir uma rota vale mais que ler dez tabelas de benchmark…

até o próximo post!