Por que a conta explodiu

Quando a equipe adicionou a IA generativa pela primeira vez, enviou cada solicitação de usuário para o modelo mais novo e capaz. À medida que o tráfego crescia, os custos por solicitação aumentavam na mesma proporção, e a planilha do CFO mostrava que os gastos estavam superando o crescimento de usuários. A solução rápida habitual — "use apenas um modelo mais barato" — falha em produção porque diferentes consultas exigem diferentes níveis de raciocínio. A verdadeira alavanca é como a solicitação é enviada, não qual modelo é sempre utilizado.

Construindo uma camada de roteamento que economiza dinheiro

O engenheiro tratou o serviço de inferência como qualquer outro componente de produção: definiu níveis (tiers), estabeleceu SLAs e impôs orçamentos de latência. A arquitetura resultante possui quatro partes móveis que, juntas, entregam a redução de 95%.

Roteamento por níveis

Um front-end leve classifica cada solicitação recebida por dificuldade. Aproximadamente 95% das consultas caem em um nível "barato" que executa um modelo modesto; apenas os 5% mais difíceis são escalonados para um modelo premium. A classificação pode ser baseada em regras (ex: comprimento, presença de palavras-chave específicas do domínio) ou aprendida a partir de dados históricos de escalonamento. Ao adotar o nível de baixo custo como padrão, o custo mensal do chatbot caiu de US$ 420 para US$ 28.

Dimensionamento correto dos modelos

Combinar a capacidade do modelo com a complexidade da tarefa gera a maior economia:

  • Chat simples – use um modelo leve em vez da oferta principal (97,5% de economia).
  • Classificação – substitua um modelo de médio porte por uma alternativa mais barata (98,3% de economia).
  • Resumo – substitua o modelo de nível superior por um de médio porte (97,2% de economia).

Os nomes exatos dos modelos não são críticos; o princípio é manter o modelo mais capaz em reserva para as poucas consultas que realmente precisam dele.

Cache inteligente

Cada acerto de cache (cache hit) elimina uma chamada de rede e uma cobrança de API. Um cache Redis distribuído armazena respostas bem-sucedidas, bem como respostas "negativas" ("Eu não sei"). Quando a mesma pergunta sem resposta aparece novamente, o sistema retorna o "Eu não sei" em cache em vez de invocar o modelo uma segunda vez. Ao longo de milhares de solicitações, isso por si só reduz uma parte considerável da conta.

Compressão de prompt

Prompts longos impulsionam o uso de tokens, o que se traduz diretamente em custo. A equipe executa um sumarizador barato no lado do cliente ou em uma etapa de pré-processamento, encolhendo um contexto de 2.000 tokens para cerca de 400 tokens antes que ele chegue ao modelo caro. A redução de tokens se multiplica em todas as solicitações, proporcionando economias massivas sem alterar a experiência do usuário final.

Agrupamento estratégico

O agrupamento (batching) agrupa várias solicitações independentes em uma única chamada de API. A regra de ouro é simples: se um usuário estiver esperando por uma resposta, não faça o agrupamento; se a solicitação for executada em segundo plano (relatórios noturnos, tarefas agendadas), agrupe tudo. Apenas os jobs de batch noturnos reduzem outros 10-20% dos gastos.

Monitorando o ciclo de otimização

Você não pode melhorar o que não mede. O engenheiro configurou quatro métricas semanais:

  1. Custo por solicitação detalhado por nível.
  2. Taxa de acerto de cache para cada caminho de roteamento.
  3. Taxa de escalonamento dos níveis baratos para os premium.
  4. Gasto por segmento de cliente.

Esses números revelam desvios — por exemplo, uma taxa de escalonamento crescente pode sinalizar que a lógica de classificação está muito agressiva ou que a qualidade do modelo barato degradou. A equipe itera sobre limiares, atribuições de modelos e políticas de cache toda semana, transformando o controle de custos em um hábito, em vez de uma resposta a crises.

Conclusão

Uma camada de roteamento disciplinada que classifica solicitações, ajusta o tamanho dos modelos, faz cache de forma agressiva, comprime prompts e agrupa tarefas de segundo plano pode reduzir os gastos com APIs de IA em até 95%, mantendo a confiabilidade alta. Trate a pilha de inferência como um serviço de produção: defina níveis, meça resultados e itere semanalmente.