O balanço invisível da IA: onde o dinheiro evapora em produção

Todo mundo fala do modelo. Quase ninguém fala do extrato bancário da requisição. E é ali, entre um token e outro, que a margem some.

Coloque um assistente com RAG no ar e a planilha começa discreta: embed, busca, geração, moderação. No terceiro sprint, aparecem as taxas de egress, a memória do KV cache inflando como balão de festa, o autoscaling que escala o que não devia, as consultas no vetor que dobram com um simples filtro por cliente. Mais duas semanas e algum alerta obscuro às 3h da manhã ensina que latência P95 é um imposto emocional.

Vamos ao osso. Três coisas comem sua margem sem pedir permissão.

Primeiro: o custo que não está no modelo. Provedores cobram por mil tokens, mas a cadeia real inclui pelo menos quatro chamadas a mais: embeddings para indexação/consulta, um moderador de entrada, possivelmente um reescritor de prompt, e um verificador de saída. Cada camada adiciona latência e, pior, taxa de acerto incerta. Em produtos corporativos, é comum ver 1,6 a 2,3 chamadas de inferência extras por requisição “simples” — o equivalente a comprar uma passagem e pagar por três conexões que você não pediu.

Segundo: memória do KV cache. É aqui que a física aparece. O cache por token, para um transformer decente, é aproximadamente 2 × L × d × bytes. Para algo no porte de um Llama 70B (L≈80 camadas, d≈8192, FP16), isso dá algo em torno de 2,6 MB por token. Uma janela de 8k tokens caberia só se você tiver uns 20 GB livres por requisição — antes de pensar em batch. Por isso sistemas como vLLM usam PagedAttention: paginam o KV cache em blocos, reciclam páginas, e mantêm o throughput sem explodir a GPU. Funciona, mas muda o jogo de capacidade; seu gargalo deixa de ser FLOPs e vira gerência de memória sob rajada.

Terceiro: batching e a loteria da latência. Continuous batching (vLLM, TGI, TensorRT-LLM) faz milagres no throughput, mas aumenta o tail se você mistura prompts curtíssimos com contextos enciclopédicos. Dois caminhos que o mercado está usando: roteamento de tráfego por perfil (curto vai para um 8–13B agressivamente quantizado; longo vai para uma instância menos lotada) e “prefill prioritário” — dar prioridade à fase de prefill de contextos grandes para não travar decodificação alheia. Dá trabalho, mas a diferença entre 120 e 450 ms no P95 é a diferença entre “parece instantâneo” e “parece burocracia”.

Agora o RAG, que promete economia e muitas vezes entrega o contrário. O índice vetorial é outro P&L. HNSW tem ótima latência/recall, mas cobra memória e construção de índice; IVF-Flat/IVF-PQ reduz footprint, mas você paga em recall e ajuste fino do nlist/nprobe. Adicione filtros de metadados (empresa, região, rótulos) e parte dos sistemas cai para um re-ranking custoso ou até um scan parcial. Em nuvem gerenciada, cada salto pela rede vira linha no balancete: egress entre VPCs, storage, e a brincadeira de “trazer o modelo para onde os dados estão” que Databricks e Snowflake estão vendendo há um motivo — é mais barato mover compute do que mover dados, a não ser que você goste de financiar o capex do provedor.

Detalhe prático que quase ninguém modela: dimensão de embedding. Sair de 768 para 3072 dimensões parece “mais semântico”, mas multiplica custo de storage, largura de banda e tempo de ANN. Quando a conta chega, equipes reduzem para 768–1024 com bom tuning de recall, compensam com re-ranking em lote, e resolvem 80% do problema. Métrica real: custo por documento útil recuperado no top-k, não custo por consulta.

Exemplos concretos de rua: produtos que streamam tokens cedo (Character.ai, chatbots de suporte) fazem a percepção de velocidade aumentar sem alterar o custo total. Já plataformas enterprise que encadeiam guardrails — detecção de PII, segurança, policy enforcement — multiplicam chamadas. Copilots corporativos frequentemente têm 3 a 5 modelos envolvidos numa única resposta. O usuário vê uma caixa de texto; o CFO vê um pipeline distribuído com cinco SLAs diferentes.

Quantização é outro campo minado. INT8/FP8 dão ganhos grandes de throughput; mas o que mata é o tail: quantização agressiva piora perplexidade de maneira desigual, e o seu P99 de “respostas erradas” cresce nos casos que mais importam. Equipes resolvem com roteamento dinâmico: 80% do tráfego em 8–13B quantizado, 20% no 70B para queries “difíceis”, usando um classificador barato para decidir. Quando esse roteador erra, você economiza centavos e perde clientes. Escolha.

Falemos de caching. Prompt caching funciona quando você tem repetição de prefixos longos (templates, contexto jurídico, instruções de estilo). Hash de prefixo + armazenamento de logits/prefix tokens reduz prefill, mas exige coerência de versão do tokenizer e do checkpoint. Troque o modelo sem invalidar a cache e você cria bug fantasma — o tipo que aparece só na auditoria. Empresas com alto volume (busca, suportes L2 com base padrão) já colheram 15–30% de economia só com caching disciplinado e deduplicação de contexto.

Observabilidade é uma linha de custo, não um slide. Logar todo token com traço detalhado vira fatura. OTelemetry com amostragem adaptativa ajuda: trace completo em erros e em latências acima do P95, métricas agregadas no resto. Sanitização de PII precisa acontecer no limite do cliente ou num sidecar confiável; fazer isso depois é pedir para um comitê de compliance transformar sua retro em confissão.

E os servidores? Orquestradores como Ray Serve, KServe e Sagemaker Endpoints entregam o básico, mas o jogo fino mora nos policies: burst control, warm pools e bin packing de GPU por perfil de contexto. Misturar workloads de 32k janelas com chat curto no mesmo nó é receita para fragmentação de KV cache. Quem separa filas por janelas (curta, média, longa) e ajusta o batch size por fila, normalmente ganha 10–20% de throughput sem tocar no modelo.

Impacto econômico direto? Em produtos de alto uso, cada 100 ms de latência economizada aumenta conversão e reduz reenvio de perguntas. O custo por sessão cai quando você reduz chamadas “qps-fantasma”: retriggers, timeouts e reenvios. No final, IA em produção parece menos com “rodar um modelo” e mais com operar um exchange: roteamento, filas, arbitragem de preço, e proteção de cauda.

Riscos e trade-offs que não cabem no roadmap feliz: lock-in de dados vetoriais (migrar HNSW grande não é simples), dependência de provedores com políticas de preço voláteis por mil tokens, e a tentação de colar modelos demais no caminho. Segurança multiplicada por três não vira segurança ao cubo; vira custo cúbico. E existe o risco de otimizar para o que a planilha enxerga: economizar centavos em GPU e perder dólares em satisfação de usuário.

Conclusão

IA lucrativa não nasce no laboratório; nasce no escalonador. A vantagem competitiva saiu do “melhor modelo” e foi para o encanamento: quem controla o caminho do dado, o minuto da GPU e a política de lote controla a margem. O resto é vitrine.

Se a primeira onda foi treinar, a segunda é operar com frieza de tesouraria. Os moats não estão no paper — estão no roteador que escolhe o modelo certo, no índice que não sangra e no cache que não mente. E, sim, às vezes a solução mais barata é um “não”: cortar etapas que a experiência não justifica. O produto agradece. O balanço também.