Quem cobra por cada token: a contabilidade secreta da IA de produto

Todo pedido a um modelo grande aciona uma fila de cobradores invisíveis. O provedor de LLM mede tokens, a camada de segurança mede tokens, o RAG injeta tokens, o gateway observa tokens. A soma disso é o que separa um protótipo inspirador de um P&L sangrando em silêncio.

O detalhe incômodo: não é só o preço do modelo. A economia da IA de produto é a soma de microimpostos distribuídos pela pilha — computação, memória, rede, indexação, latência garantida — que crescem na sombra do hype. E como qualquer bom imposto, muitos deles são difíceis de mapear e fáceis de subestimar.

O custo técnico do token não é linear

Quem opera inferência aprende rápido que “um milhão de tokens” não é uma unidade homogênea. Existem duas fases com custos diferentes:

1) Prefill (leitura do prompt). É quando o modelo processa o contexto. O custo explode com o tamanho da janela por causa da atenção quadrática e por ser bound por memória/largura de banda. Colocar 60 páginas de contexto para “garantir” que o modelo vai ler tudo é um pedido formal de fatura maior e jitter de latência.

2) Decode (geração). Aqui, a cache KV faz o trabalho pesado: cada novo token consulta estados anteriores. É mais estável e, bem otimizado, pode ser barato — se você tiver batching contínuo decente e cache não estourando a VRAM.

Três técnicas mudam materialmente a conta de ambos os lados:

– Batching contínuo (vLLM, TGI). Agrupar requisições em tempo real aumenta tokens/s por GPU sem transformar a UX em um ônibus lotado. O trade-off é tuning: lotes grandes reduzem custo médio, mas pioram picos de latência e fairness entre usuários.

– Speculative decoding. Um modelo pequeno “chuta” vários tokens e o grande só valida. Quando a taxa de aceitação é alta, o throughput sobe significativamente. Quando o draft erra muito, você só adiciona complexidade e novas superfícies de falha.

– PagedAttention e KV cache quantizada. Paginando a cache na VRAM e, em alguns cenários, quantizando KV para 8 ou 4 bits, dá para multiplicar a concorrência por GPU sem perda perceptível de qualidade em tarefas comuns. O risco: padrões de acesso ficam mais irregulares, e queda de qualidade aparece primeiro em prompts longos e raciocínio estruturado.

Prompt gigante é boleto recorrente; cache é cupom

Provedores começaram a oferecer “prompt caching”: se você repete o mesmo sistema/prompt base, eles armazenam o estado e cobram menos (ou nada) pela parte repetida. Funciona: reduzir 3 mil tokens fixos por chamada salva dinheiro e latência. Mas a conta vem em outra linha:

– Lock-in. O cache é por provedor e geralmente por hash interno. Você não consegue “levar” esse estado para outro endpoint. Se migrar, volta a pagar o prompt inteiro.

– Observabilidade opaca. Medir acerto de cache e quedas de performance vira exercício de confiança. Sem métricas de hit rate e tempos por fase (prefill/decode), você celebra economias que podem ter vindo de lotes mais lentos, não do cache.

– Variância de custo. Mudanças triviais no prompt invalidam o cache. Aquele ajuste de tom aprovado pelo jurídico transforma um mês de previsibilidade em uma semana de surpresa.

RAG não é desconto automático

Recuperar contexto antes de gerar parece uma barganha: menos alucinação, mais precisão, possivelmente menos saída. Na prática, o RAG só recalibra quem está cobrando.

– Embeddings. São baratos por vetor, até virarem milhares por hora. Se você usa janela deslizante em documentos longos, paga embedding extra que não entra no top-k quase nunca. Indexes como HNSW pedem memória (e overhead) que morde o orçamento de RAM.

– Busca vetorial. Postgres+pgvector é ótimo até um certo volume. Passou disso, clusters dedicados (Pinecone, Weaviate, Milvus) entram no jogo com contas de armazenamento, consultas e egress. Cada salto de região ou shard soma milissegundos que o usuário percebe — e você compensa gerando respostas maiores (mais tokens).

– Re-ranking. Usar um cross-encoder para reordenar resultados melhora a precisão de forma visível, mas adiciona mais GPU e mais latência. O ganho em qualidade precisa superar o custo e o impacto na experiência. Medir recall@k sem medir “passagem lida pelo usuário” é otimizar métrica errada.

Resumo honesto: RAG fica barato quando você controla granularidade de chunk, constrói filtros decentes, treina disciplina de contexto (MMR, limite por fonte) e mede o custo por resposta útil — não por requisição.

Os middlewares discretos que engordam a fatura

Entre o usuário e o modelo, há uma procissão de serviços que valem a pena — até não valerem:

– Gateways e roteadores de modelo. Fazem fallback, A/B e políticas. Custam pouco por chamada, mas forçam round-trips extras e logs caros. Numa empresa com compliance agressivo, o “custo por log” facilmente supera o “custo por token”.

– Guardrails. Classificadores de segurança, PII scrubbers, validação de saída. Muitos usam o próprio LLM por trás. Você adiciona 1–2 chamadas invisíveis para cada resposta “segura”. Multiplique por volume e descubra o imposto da tranquilidade.

– Ferramentas estruturadas. JSON estrito, checagens de função, graph-of-thought. Ótimo para integridade, péssimo para excesso de tokens de controle. Vira fácil 20–30% de overhead em prompts “bem organizados”.

Infra própria, API de terceiros, ou o meio-termo

Rodar o próprio stack com vLLM, SGLang ou TGI corta intermediários e dá previsibilidade. Dá trabalho também. Coisas que raramente entram no slide:

– Planejamento de capacidade. Inferência sofre com sazonalidade e campanhas. GPUs ociosas custam, mas filas longas custam marca. O sweet spot requer modelos menores para rotinas e grandes para exceções — com roteamento real, não PowerPoint.

– Métricas certas. Tokens/s por GPU, taxa de aceitação no speculative, utilização de KV, hit de cache, p95 de prefill vs decode, custo por conversa “resolvida”. Sem isso, você só muda quem te cobra — não quanto você paga.

– Quantização e afinamento leve. Q4 ou Q8 reduzem memória e preço efetivo, mas alteram o comportamento em raciocínio e código. Adapte prompts e testes. O ganho some se o time passar semanas consertando corner cases.

No outro extremo, agregadores e “serverless de LLM” fazem sentido quando você quer velocidade e variedade. Só aceite a margem como parte do produto: SLA, curadoria e incidentes tratados às 3h da manhã por alguém que não é você. Margem boa quando existe labirinto regulatório; cara quando seu tráfego é previsível e volumoso.

Pequenos números que mudam estratégia

– A relação input/output quase sempre mata o orçamento pelo lado da saída. Bots falantes, respostas longas, explicações didáticas: o cliente adora, o financeiro não. Parametrizar verbosidade não é detalhe de UX, é ajuste fino de COGS.

– Latência compra qualidade percebida. Uma busca vetorial 40 ms mais lenta vira “modelo burro” aos olhos do usuário, que responde pedindo “explique melhor” — mais 200 tokens. Otimize a primeira resposta antes de otimizar a melhor resposta.

– Provedores mudam preços e limites. Features como cache de contexto surgem, somem, mudam de contrato. Modelos “mini” ganham capacidade que mata metade dos usos “grandes”. Negociar volume e portabilidade hoje vale mais que trocar de stack amanhã.

Depois do ponto final, a fatura

Empresas maduras em IA não soam inteligentes: soam econômicas. Sabem onde cada token nasce, onde morre e quem cobrou pedágio no caminho. Elas tratam prefill e decode como centros de custo diferentes, fazem RAG com parcimônia de bibliotecário e guardrails com austeridade de auditor. E, quando alguém sugere “vamos colocar todo o histórico no prompt para ficar mais esperto”, respondem com a frieza de quem já pagou essa conta.

A lição incômoda é que a “inteligência” mais decisiva não está no modelo — está no desenho do fluxo. Mudar o que você pede, quando pede e para quem pede reconfigura a economia do sistema. No fim, IA de produto é engenharia de caixa: se a experiência melhora e a fatura não cresce de forma imprevisível, o resto é ruído. O que parece magia para o usuário final precisa soar, nos bastidores, como planilha bem-feita.