Capítulo 15 — APIs Serverless vs Infraestrutura Dedicada

Décimo quinto post do passeio capítulo a capítulo pelo LLM Primer VI: Escalando Sistemas de IA. O capítulo que coloca a matemática do ponto de equilíbrio na mesa e depois nomeia o item de engenharia de plataforma que decide a resposta para a maioria dos times.

Por que este capítulo existe

O Capítulo 14 deixou o time com uma leitura clara do que compõe a fatura da API — e uma suspeita silenciosa de que ela poderia ser mais barata. A próxima pergunta natural é se o time deveria estar pagando por token. A alternativa é trazer a inferência para casa, rodar um modelo de pesos abertos sobre a pilha descrita nos capítulos anteriores e pagar por GPU-hora. O trade-off tem um ponto de equilíbrio limpo. O que é menos limpo, e o que a maioria dos times subestima, é tudo o que está do lado dedicado do balanço e não aparece na fatura da GPU — a engenharia de plataforma, os patches de segurança, a coreografia de upgrade de modelo, o alerta às 3 da manhã quando um nó cai da frota. O Capítulo 15 leva os dois lados a sério e deriva quando o self-hosting é a resposta certa.

15.1 A fórmula do ponto de equilíbrio é limpa e, em boa parte, um chamariz

A GPU produz throughput × utilização × 3.600 tokens de output por hora. Seu custo por milhão de tokens é (gpu_hora / tokens_por_hora) × 1.000.000. O ponto de equilíbrio contra a API é onde esse número iguala o preço por milhão da API. Um modelo de 70B em FP8 numa H100 a US$ 3 por hora, rodando 800 tokens por segundo agregados a 60 por cento de utilização, sai a algo como US$ 1 por milhão de tokens de output. A API de fronteira cobra US$ 15. A economia aparente é de 14× — um argumento pró self-hosting que o financeiro adora e que está ignorando o segundo item, maior, do balanço. O ponto de equilíbrio também depende da utilização; abaixo de 20 a 30 por cento de utilização, o custo por milhão do self-hosted sobe acima da tarifa da API e a GPU fica mais cara do que a alternativa que ela deveria estar substituindo. Utilização, por sua vez, é função do formato do tráfego, da qualidade do autoscaling e de o time conseguir ou não empacotar mais de uma workload na mesma frota.

15.2 A engenharia de plataforma é o item que decide o negócio

A fatura da GPU é a metade menor. A metade maior é o time que mantém a frota rodando: engines, drivers, orquestração, autoscaling, observabilidade, segurança. O time de API paga esse custo implicitamente pelo preço por token; o time de self-hosting paga em headcount. Uma regra prática útil: uma única frota de serving — uma ou duas variantes de modelo, autoscaling, observabilidade, plantão, upgrades trimestrais — exige aproximadamente um engenheiro de plataforma em tempo integral mais uma fração de um SRE. Uma frota mais diversa — vários engines, vários modelos, escalonamento multi-tenant — exige de dois a quatro. A US$ 300 mil por engenheiro totalmente carregado, a conta anual de plataforma fica entre US$ 300 mil e US$ 1,2 milhão. O tráfego mensal de equilíbrio em que o self-hosting se paga fica em algum lugar entre 200 milhões e 1 bilhão de tokens de output por mês. Abaixo disso, o overhead de engenharia excede a economia em tokens e o time deveria ficar na API. Acima disso, a economia domina. A engenharia de plataforma também chega em degraus, não em curvas suaves: a primeira contratação sobe a frota, a segunda acontece porque a primeira não cobre plantão de fim de semana, a terceira quando a frota cresce para multi-região.

15.3 A postura realista é híbrida, e o roteador é a peça de sustentação

A decisão mais limpa — tudo API ou tudo dedicado — raramente é a certa para um time com mais de um ano em produção. Workloads previsíveis em regime permanente (batch noturno, relatórios agendados, filas de classificação) se encaixam bem em capacidade dedicada planejada. Workloads em rajada (picos virais, enxurradas de tickets, lançamentos de novos cohorts) precisam da elasticidade da API. Workloads de latência estrita (autocompletar interativo, voz) se beneficiam de um deployment dedicado colocado próximo. Workloads sem latência (enriquecimento noturno, reindexação) se beneficiam de batch APIs pela metade do preço. A arquitetura que sustenta híbrido é um roteador na borda da aplicação que classifica cada requisição por orçamento de latência, complexidade e utilização atual do backend, e despacha para o backend mais barato que atenda ao SLA. Um roteador refinado também faz roteamento dentro da API por modelo (modelo barato para queries simples, fronteira para as complexas, tier de reasoning para as que precisam). O benefício de segunda ordem é opcionalidade: workloads podem migrar de um lado para o outro mudando política de roteador, não código de aplicação. E a opção dedicada em geral só se paga porque uma segunda workload — que de outra forma teria ido para a API — pega carona na GPU já paga. Um time que avalia o dedicado sobre uma única workload em geral nunca migra; um time que pensa em portfólios de workload migra, e economiza.

O que o Capítulo 15 prepara

O Capítulo 15 nomeou uma classe de workload que os agentes introduziram e que não se encaixa nem em "chamada de API" nem em "serving de modelo": o ambiente de execução de código gerado por LLM, que vive em funções serverless, microVMs (Firecracker, gVisor) ou sandboxes WASM, dependendo do isolamento e da flexibilidade de pacotes que o agente precisa. O Capítulo 16 fecha o volume com o catálogo dos movimentos de corte de custo que se aplicam dos dois lados da linha de postura: roteamento inteligente de modelos, compactação de contexto no nível da aplicação, batch APIs, cache semântico — movimentos que se compõem para virar um terço ou metade da fatura do mês passado.

Próximo — Capítulo 16: Estratégias de Corte de Custo em Produção. Os movimentos que se compõem para transformar a fatura do mês passado na economia do próximo.