A conta do 'rodar em casa' está errada: por que o custo real de inferência varia até 36×

§1 — O que o paper afirma

A pergunta que o paper ataca é a mais concreta que existe numa diretoria de tecnologia: rodar o modelo na nossa própria infraestrutura sai mais barato do que pagar a API por token? A resposta que quase toda planilha dá está errada — e o erro tem uma causa única e mensurável.

O erro está em assumir a GPU sempre cheia. O autor levantou mais de 15 calculadoras públicas de custo de LLM (Helicone, LiteLLM, llm-prices.com e outras) e todas cometem o mesmo pecado: tratam a ocupação da GPU (utilization) como um número que o usuário digita — ou assumem silenciosamente 100% (§2.1, §6.1). Ocupação não é uma entrada que você escolhe; é um resultado de quanto tráfego chega. Uma GPU só fica cheia quando há requisições suficientes chegando ao mesmo tempo para preencher o lote de processamento. Com pouco tráfego, ela fica ociosa esperando — e você paga a hora de GPU inteira para processar um punhado de tokens.

A consequência em dinheiro é enorme. No mesmo hardware H100, o custo efetivo por milhão de tokens de saída varia de US$ 0,21 a US$ 15,25 — uma penalidade de subutilização de 17,5× a 36,3× (Abstract; §5.1; Conclusão §7). O que controla essa faixa é uma variável só: a taxa de chegada de requisições (o paper chama de λ, “lambda”). A regra matemática por trás é a Lei de Little — o número de requisições sendo processadas ao mesmo tempo é aproximadamente a taxa de chegada multiplicada pelo tempo de cada uma (§3). Nenhuma calculadora pública expõe essa variável.

O caso concreto do modelo denso de referência (Llama 3.1 8B, uma única GPU H100 a US$ 6,98/hora) está na Tabela 3:

A 1 requisição/segundo: custo efetivo de US$ 7,60/milhão de tokens — 24,4× a estimativa ingênua.
A 10 req/s: US$ 0,79 — ainda 2,5× errado.
A 25 req/s: US$ 0,37 — penalidade cai para 1,18×.
A 50 req/s ou mais: US$ 0,31–0,32 — a GPU satura e a estimativa ingênua finalmente acerta.

Ou seja: a economia do self-hosting que a planilha promete só aparece quando a GPU está saturada de tráfego. Abaixo disso, você paga múltiplos do previsto. E “10 req/s” — que a maioria não chamaria de tráfego baixo — ainda erra por 2,5× no modelo denso e 3,8× no MoE (§5.1).

Quando o “in-house” perde para a API. O paper refaz a análise de ponto de equilíbrio (self-host vs. API) corrigindo a ocupação (§5.6, Fig. 5). Sob o modelo ingênuo, toda configuração self-hosted parece permanentemente mais barata que qualquer API. Corrigido: a 1 req/s, o Mixtral 8x7B FP16 custa US$ 15,25/milhão de tokens — mais caro que o preço de saída do Claude Sonnet 4.6 (US$ 15/milhão). O cruzamento fica em torno de 1,5–2 req/s: abaixo disso, os tiers mais baratos de API (Gemini 3.1 Pro, Claude Sonnet 4.6) saem mais em conta que rodar em casa.

Alguns achados secundários com peso de decisão:

Parâmetros ativos importam mais que tamanho total. O Qwen3-30B-A3B (30 bilhões de parâmetros, mas só 3 bilhões ativos por token) sai mais barato por token na saturação (US$ 0,209) que o Llama 3.1 8B (US$ 0,238) — ambos em FP8 —, apesar de ser quase 4× maior no papel (Result 3, §5.2). A intuição de “modelo menor é mais barato de servir” se inverte. MoE (mixture-of-experts) é a arquitetura que ativa só uma fração dos parâmetros a cada token — daí o custo baixo apesar do tamanho.
A API cobra caro pela saída, não pela entrada. GPT-5.5: US$ 5/milhão na entrada vs. US$ 30 na saída; Claude Sonnet 4.6: US$ 3 vs. US$ 15; Gemini 3.1 Pro: US$ 2 vs. US$ 12 — saída custa 5–6× mais (§6.3). O self-hosting cobra o mesmo pela GPU independente disso, então a vantagem de rodar em casa cresce justamente em cargas que geram muito texto: código, redação longa, agentes.
Ferramenta aberta. O autor liberou o vllm-cost-meter (código aberto, licença MIT), que se conecta a um servidor vLLM ao vivo e reporta o custo real por milhão de tokens contra o tráfego da própria operação (§6.6, §7.1), validado em produção simulada com 32.401 requisições e 100% de sucesso (Tabela 7).

§2 — Por que importa para o negócio

A leitura para a diretoria não é “existe uma calculadora de custo melhor”. É: a decisão mais cara da sua estratégia de IA — rodar em casa ou pagar a API — está sendo tomada sobre uma planilha que erra por uma ordem de grandeza, e sempre para o lado que faz o “rodar em casa” parecer barato.

Nos últimos dois decodes, a conversa foi sobre ter acesso a capacidade barata: o DeepSeek-R1 derrubou o preço da fronteira, o Llama 3 transformou “alugar inteligência ou ser dono dela” numa decisão real. Este paper é o boleto que chega depois dessa decisão. Ele mostra que “ser dono” só é mais barato acima de um volume de tráfego específico — e que abaixo desse volume, a GPU fica ociosa esperando requisição, você paga a hora cheia por um punhado de tokens, e o custo por token dispara até 36×. A 1 requisição por segundo, um modelo aberto rodando na sua infra saiu mais caro que pagar o Claude por token. O ponto de virada no exemplo do paper é ~1,5–2 requisições por segundo. Pergunte-se: qual dos seus casos de uso sustenta esse tráfego o dia inteiro?

Para o mercado brasileiro, o detalhe cruel é quem mais perde. O perfil que mais sofre com GPU ociosa é o de demanda intermitente — varejo com pico sazonal, cobrança em lote, atendimento que enche de manhã e esvazia à tarde. É exatamente o perfil de boa parte das empresas que estão sendo aconselhadas a “internalizar a IA para economizar”. A economia prometida assume uma GPU saturada que a operação delas nunca vai ter.

E há a inversão que quebra a intuição da diretoria: o gatilho do custo não é o tamanho do modelo nem o preço da placa — é a taxa de utilização. Um modelo grande do tipo MoE pode custar menos por token que um modelo pequeno, porque o que pesa é quantos parâmetros ele ativa, não quantos ele tem. Quem decide self-hosting olhando “modelo menor = mais barato” e “GPU potente = resolvido” está respondendo à pergunta errada. A pergunta certa — a única que importa aqui — é: qual é o nosso λ real? E quase ninguém na diretoria sabe responder.

§3 — O que fazer a respeito

Antes de assinar qualquer business case de self-hosting, exija o número corrigido pela utilização real. Se a planilha que chegou à sua diretoria assume a GPU sempre cheia (e quase toda assume), ela está errada para o lado que te empurra a internalizar. O paper libera uma ferramenta aberta — o vllm-cost-meter — que mede o custo real contra o seu próprio tráfego. Peça esse número, não o da calculadora de fornecedor.
Descubra o seu λ antes de discutir GPU. A pergunta que abre a reunião não é “qual placa compramos” — é “quantas requisições por segundo esse caso de uso realmente sustenta, na média e no vale?”. Sem essa resposta, todo o resto é chute. Se a operação é intermitente, o custo por token que você vai pagar é múltiplo do que a planilha mostra.
Para tráfego baixo ou irregular, comece na API — e migre por gatilho, não por ideologia. Pague por token (ou use endpoint serverless) até o volume cruzar o ponto de equilíbrio (~1,5–2 req/s no exemplo do paper) de forma consistente. “Ser dono” é uma decisão de escala, não de princípio; internalizar cedo demais é pagar caro por soberania que o volume ainda não justifica.
Onde o self-hosting realmente ganha: cargas que geram muito texto. A API cobra 5–6× mais pela saída do que pela entrada; rodar em casa cobra o mesmo pela GPU. Então priorize internalizar os casos generation-heavy — geração de código, redação longa, agentes que produzem passos — e deixe na API o que é leitura/classificação de baixo volume.
Na escolha do modelo para servir, olhe parâmetros ativos, não tamanho total. Um MoE grande pode custar menos por token que um denso pequeno. Não deixe o time descartar um modelo “porque é grande demais” sem medir o custo de servir de verdade.

§4 — Limite da evidência

O paper é honesto sobre as próprias fragilidades, e elas importam para não superinterpretar os números.

Números são um teto, não uma média. O experimento roda com prefix caching e speculative decoding desligados de propósito (§4.3, §5.7), para estabelecer um piso de desempenho reproduzível. Deployments reais, com essas otimizações ligadas, custam menos. Ou seja: os valores absolutos são limites superiores de custo — a direção do erro joga a favor do self-hosting, não contra.
Comparação com API usa preço de tabela. Os preços de API citados são de lista, sem aplicar três descontos reais (entrada ~5× mais barata, cache de prompt ~uma ordem de grandeza, contratos de volume ~50%) que empurrariam o ponto de equilíbrio para um tráfego ainda mais alto (§5.6). De novo: conservador a favor do self-hosting.
Escopo pequeno: 3 arquiteturas, 1 autor, ~US$ 65 de GPU. São 42 benchmarks em três modelos (Llama denso, Qwen e Mixtral MoE), rodados por um pesquisador independente em ~4,5 horas de GPU (§4.4). A tese de “parâmetros ativos governam o custo” repousa em n=3 e o próprio paper pede validação mais ampla (modelo denso grande como Llama 70B, terceira razão de esparsidade). Não é um estudo de larga escala.
Carga sintética, não tráfego real. Os testes usam entradas/saídas de tamanho fixo (512/256 tokens), não conversas reais de tamanho variável (§6.9). O autor mediu variantes (tamanho variável, rajadas, RAG) e a penalidade se manteve ou até aumentou — mas o tráfego da sua operação pode se comportar diferente. A recomendação do próprio paper é medir no seu ambiente, não copiar os números.
Depende do motor e do hardware. A magnitude do erro muda com o motor de inferência (o mesmo Llama espalha 24,4× no vLLM vs. 12,0× no SGLang, Tabela 6) e com a GPU (na A100, a faixa cai para 7,0–11,4×, §5.9). O fenômeno reproduz em dois hardwares, mas o número exato é condicional ao seu setup.
O “653×” da validação ao vivo é sinal, não dado. A demonstração em produção reporta uma variação de 653× entre o minuto mais barato e o mais caro (§6.7, Tabela 7), mas o próprio autor marca isso como artefato de janela de um minuto perto da ociosidade — direcional, não reproduzível. O número sério do paper é a faixa 17,5–36,3×.
Conflito de interesse: baixo. O autor é pesquisador independente (declara explicitamente que “não representa a visão do empregador”) e não é fornecedor de GPU nem de API — o incentivo para inflar um lado é fraco. O maior risco é o oposto: os preços de GPU e de API mudam a cada trimestre, então os valores em dólar envelhecem rápido. O valor durável aqui é o método (medir custo contra a utilização real), não a tabela.