Calculando custos de inference em escala com aritmética simples

O cálculo de custo por usuário em 2026 não é mais um exercício de adivinhação, é aritmética aplicada com base em três pilares reais: largura de banda de memória (não apenas TFLOPS), eficiência do KV cache e taxa de ocupação real da GPU. A B200, por exemplo, não entrega seus 9.000 TFLOPS FP4 em produção porque seu gargalo é o acesso à HBM3e: 8 TB/s de largura de banda versus 562 operações por byte carregado. Isso significa que, sem otimizações como PagedAttention e GQA, você desperdiça 98% do potencial computacional, os núcleos ficam ociosos esperando dados.

Modelos como Llama 3, Mistral Large 3 e DeepSeek V3 já nascem com GQA embutido, reduzindo o KV cache em até 8× em comparação com MHA tradicional. Isso não é um ajuste pós-treino: é uma escolha arquitetural que define o custo operacional desde o primeiro token gerado. E o FP8 não é só 'mais rápido', é o ponto de equilíbrio entre precisão e throughput: ele reduz o footprint de memória em 2× sem exigir recalibração pesada, permitindo servir modelos de 32B com contexto de 200k tokens em uma única B200, algo inviável com FP16.

Em 2026, o preço por milhão de tokens saída caiu para US$ 0,075 (Gemini Flash), mas esse número é irrelevante se seu motor de inferência não aproveita a memória HBM3e com eficiência. Um SaaS que ignora PagedAttention ou usa GQA incorretamente paga até 6× mais por usuário do que um concorrente com a mesma GPU. A lucratividade não vem do modelo, mas da forma como você orquestra matmuls, cache e alocação de VRAM. Se sua app tem 80% de tempo ocioso por sessão, não é problema de hardware, é sinal de que você pode escalar de 50 para 500 usuários por B200 com ajustes de software, não de infraestrutura.