Serverless vs Dedicado vs Self-Hosted: quando rodar seu próprio LLM fica mais barato

Se você roda modelos de linguagem em produção, uma decisão define seus custos: serverless, dedicado ou self-hosted? A DigitalOcean publicou um experimento detalhado comparando as três abordagens, com dados reais de latência, custo e provisionamento. O resultado: self-hosting pode ser até 4x mais barato que serverless — mas só a partir de um certo volume.

Metodologia do experimento

O teste usou o mesmo modelo (Llama 3.1 8B) executado de três formas diferentes na infraestrutura da DigitalOcean:

Latência: self-hosted é 25x mais rápido na primeira palavra

O dado mais impressionante do experimento é a latência do time to first token (TTFT) — o tempo entre o envio do prompt e a primeira palavra gerada:

• Serverless: latência alta e variável, especialmente em cold starts
• Self-hosted (GPU Droplet): 25x mais rápido que serverless para o primeiro token
• Dedicado: desempenho similar ao self-hosted, mas com custo 30% maior

Essa vantagem do self-hosted se mantém até que a concorrência ultrapasse 32 requisições simultâneas — ponto em que o balanceamento de carga do serverless começa a compensar.

O ponto de virada: quando self-hosting fica mais barato

O experimento identificou o crossover point — o momento exato em que self-hosting passa a valer mais a pena que serverless:

• GPU Droplet vs Serverless: self-hosting vence quando a GPU está entre 22% e 48% ocupada
• Dedicado vs Serverless: o breakeven sobe para 29% de utilização, porque o dedicado custa 30% mais que um GPU Droplet equivalente

Na prática: se você processa prompts de forma consistente ao longo do dia (não apenas em picos), o self-hosted se paga rapidamente. Se seu uso é esporádico (poucas chamadas por hora), serverless ainda é a melhor escolha.

Quatro armadilhas ao rodar o experimento

A equipe da DigitalOcean documentou quatro problemas reais que enfrentou durante os testes — erros que qualquer pessoa rodando LLMs em produção já encontrou ou vai encontrar:

1. Cold starts matam a experiência do usuário: no serverless, a primeira requisição após um período ocioso pode levar segundos. Para aplicações interativas, isso é inaceitável
2. Configuração de GPU não é trivial: self-hosting exige conhecimento de drivers CUDA, versões de PyTorch e otimização de memória
3. Subutilização é cara nos dois lados: GPU parada custa dinheiro (self-hosted), mas pagar por token em volume baixo também é ineficiente
4. O modelo certo muda tudo: o experimento usou Llama 3.1 8B. Modelos maiores (70B+) têm custos de GPU que alteram completamente a equação

Quando uma startup deve migrar do serverless

Com base nos dados do experimento, a recomendação prática é:

• Estágio inicial (MVP, validação): fique no serverless. Provisionamento instantâneo, sem risco de GPU ociosa
• Crescimento (100+ requisições/dia consistentes): avalie um GPU Droplet. O breakeven de 22-48% de utilização é atingível com volume moderado
• Escala (1000+ requisições/dia): self-hosted é a escolha óbvia. Considere múltiplas GPUs com balanceador de carga próprio

Traduzindo para a realidade brasileira

No Brasil, GPUs em cloud ainda são caras — uma H100 alugada pode custar entre R$ 8.000 e R$ 15.000 por mês. Mas alternativas como L40S e A100 usadas estão cada vez mais acessíveis. E com a popularização de inferência em CPUs otimizadas (via llama.cpp, Ollama e OpenVINO), até mesmo servidores on-premise sem GPU podem ser competitivos para modelos menores como Llama 8B e Mistral 7B.

O cálculo que o experimento da DigitalOcean faz em dólares precisa ser adaptado: considere o custo de energia elétrica brasileira (~R$ 0,70/kWh residencial, ~R$ 0,45/kWh industrial), a disponibilidade de hardware no mercado local e a latência adicional de chamadas a APIs hospedadas nos EUA.