Os custos de inferência de IA, não o treinamento, estão remodelando a economia de servir modelos

O custo de um treinamento de modelo de ponta é um número que os jornalistas adoram citar — centenas de milhões de dólares, dezenas de milhares de GPUs, meses de tempo real. Também é, para a maioria das empresas de IA, o número errado a se preocupar. O treinamento acontece uma vez (ou algumas vezes por ano, para uma atualização). A inferência acontece em cada solicitação de cada usuário, para sempre, e escala com o sucesso: quanto melhor um produto se sai, mais caro é mantê-lo funcionando. Isso inverte uma parte da economia que prevaleceu durante a maior parte da história do software, em que o custo marginal de atender a mais um usuário era próximo de zero.

É por isso que a inferência, não o treinamento, é o item de linha que está realmente remodelando como as empresas de IA constroem produtos em 2026. As empresas que vencem na economia unitária não são necessariamente as que têm o melhor modelo — são as que mais reduziram o custo de responder a uma única consulta, por meio de um conjunto de técnicas já maduras o suficiente para serem prática padrão, e não curiosidades de pesquisa.

A aritmética que torna a inferência cara

Um passo para frente (forward pass) de um transformer custa aproximadamente 2 × número de parâmetros × tokens processados em operações de ponto flutuante. O treinamento custa aproximadamente três vezes isso por token, porque também executa um passo para trás (backward pass) e uma atualização de gradiente — mas o treinamento ocorre para um número fixo e limitado de tokens. A inferência não tem esse limite; ela escala com cada consulta de cada usuário, indefinidamente. Um modelo que atende um bilhão de consultas por dia consome mais computação cumulativa em semanas do que seu treinamento consumiu em meses, uma vez que o produto tenha uso real.

O comprimento do contexto piora isso. O cache de chave-valor (KV cache) que um transformer mantém durante a geração cresce com o comprimento da sequência × número de camadas × número de cabeças de atenção × dimensão de cada cabeça × tamanho do lote. Ao levar as janelas de contexto de 8K para 128K ou mais — algo que os produtos agora fazem rotineiramente — a memória necessária por solicitação simultânea cresce proporcionalmente, o que limita quantas solicitações uma determinada GPU pode atender ao mesmo tempo. Esse limite é o que realmente define o custo por consulta, mais do que os FLOPs brutos.

As técnicas que realmente cortam custos

A quantização é a palanca mais direta: executar a inferência em FP8 ou INT8 em vez de FP16/BF16 reduz aproximadamente à metade os requisitos de largura de banda de memória e pode dobrar ou mais a taxa de transferência no mesmo hardware, com uma perda de precisão cuidadosamente gerenciada. O INT4 vai além para modelos em que a perda de precisão é tolerável.

As arquiteturas Mixture-of-Experts (MoE) mudam o que "tamanho do modelo" significa para fins de custo. O DeepSeek-V3 tem 671 bilhões de parâmetros totais, mas ativa apenas cerca de 37 bilhões por token — você paga computação pelo subconjunto ativo, não pelo modelo completo. Essa é a principal razão pela qual os modelos MoE conseguem oferecer capacidade de nível de ponta por uma fração do custo de inferência de um modelo denso com um total de parâmetros equivalente.

As variantes de atenção atacam diretamente o problema do KV-cache. A atenção por consultas agrupadas (grouped-query attention, GQA), usada no Llama 3 e em muitos modelos atuais, compartilha projeções de chave/valor entre grupos de cabeças de atenção em vez de dar a cada cabeça sua própria projeção, reduzindo o tamanho do KV-cache várias vezes com perda mínima de qualidade. A atenção latente multi-cabeça (MLA) da DeepSeek comprime ainda mais o cache, projetando chaves e valores em um espaço latente menor antes de armazená-los em cache.

A decodificação especulativa adiciona um modelo "rascunho" pequeno e rápido que propõe vários tokens com antecedência, os quais o modelo completo verifica em paralelo em vez de gerar um token por vez. Quando o modelo rascunho acerta — o que acontece com bastante frequência em texto do dia a dia — isso reduz a latência e o tempo de GPU por token de saída em aproximadamente metade a dois terços, sem nenhuma perda na qualidade da saída (o modelo grande ainda tem a palavra final sobre cada token).

No lado da infraestrutura de serviço, o batching contínuo e o gerenciamento paginado de KV-cache — a técnica que o vLLM popularizou como PagedAttention — permitem que um servidor encaixe muito mais solicitações simultâneas na mesma memória de GPU, gerenciando a alocação do cache como um sistema de memória virtual em vez de reservar um bloco fixo de pior caso por solicitação. Esse é um ganho puramente de infraestrutura: mesmo modelo, mesmo hardware, taxa de transferência significativamente maior.

Roteamento: usar o modelo caro apenas quando necessário

Uma estratégia separada abandona a otimização da inferência de um único modelo e, em vez disso, otimiza qual modelo responde a cada consulta. Uma camada de roteamento envia consultas simples e de alta confiança para um modelo barato e rápido, e só escala para um modelo de ponta caro as consultas genuinamente difíceis. Produtos construídos assim relatam um custo médio por consulta bem abaixo do que custaria passar cada consulta pelo modelo de ponta, porque a maioria das consultas reais não precisa do raciocínio de um modelo de ponta — precisa de uma resposta correta e rápida.

Os problemas financeiros da Character.AI — que entrou com pedido de falência pelo Chapter 11 em 13 de outubro de 2026 — são um estudo de caso útil sobre o que acontece quando isso não é resolvido. Um produto de chat gera um volume enorme de inferência por usuário (conversas longas, frequentes e de ida e volta), e se o custo de inferência por mensagem não for reduzido agressivamente em relação ao que os usuários pagam ou ao que os anúncios geram, a economia unitária simplesmente não se sustenta, não importa quão grande a base de usuários se torne.

Hardware de inferência especializado

GPUs de uso geral continuam sendo a opção padrão, mas o silício de inferência dedicado — o LPU da Groq, o motor em escala de wafer da Cerebras, a arquitetura de fluxo de dados da SambaNova — troca flexibilidade de treinamento por menor latência e menor custo por token em cargas de trabalho somente de inferência. Isso importa mais em aplicações de alto volume e sensíveis à latência (assistentes de voz, ferramentas de codificação em tempo real), onde economizar milissegundos e centavos por solicitação em escala massiva supera a flexibilidade de um acelerador de uso geral.

Conclusões práticas

Se você está construindo um produto sobre uma API de LLM, acompanhe o custo por 1.000 tokens de saída como sua métrica central de economia unitária, não o custo por consulta — o aumento silencioso do comprimento do contexto é o assassino silencioso das margens. Defina um orçamento rígido de comprimento de contexto por funcionalidade, em vez de deixá-lo crescer sem controle. Use um modelo barato e rápido como padrão e só escale para um modelo caro em caso de incerteza detectada ou solicitação explícita do usuário por raciocínio mais profundo. E se você está avaliando provedores de API, pergunte diretamente sobre a estratégia de quantização, MoE e cache deles — um provedor que executa inferência FP8 MoE com batching consciente de KV-cache pode ser significativamente mais barato do que um que não o faz, para exatamente a mesma qualidade nominal de modelo.