Self-Hosting de um LLM de Peso Aberto vs. uma API: A Verdadeira Matemática de Custos

O seu produto entra em produção, chama uma API de LLM, e a fatura tem vindo a subir todos os meses. Então faz o que todos os builders acabam por fazer: abre um novo separador e pergunta-se se alugar uma GPU e executar o Llama por conta própria não sairia mais barato.

A questão do custo de self-hosting de LLM tem uma resposta, mas não é o número único que os primeiros resultados de pesquisa e as AI Overviews andam a repetir. Depende de três coisas que esses artigos achatam: com que API se está a comparar, quão ocupada está a sua GPU, e o custo de operações que ninguém põe na folha de cálculo.

Aqui vai a versão curta antes dos detalhes: para a maioria dos builders a solo, o self-hosting não vence no custo neste momento. Mas há uma linha específica onde isso vira, e pode calculá-la na sua própria fatura em cerca de dois minutos. Em baixo está a matemática de 2026 (preços atuais, números de VRAM por modelo, e uma fórmula que pode aplicar).

A versão curta

• O ponto de equilíbrio não é um número. São três, consoante a API com que se está a comparar. Face a uma API de fronteira (GPT-5.x, Claude Sonnet 5 / Opus 4.8, Gemini Pro), o self-hosting atinge o equilíbrio mais cedo. Face a uma API de peso aberto económica (DeepSeek, DeepInfra, Together a cerca de $0.14–$0.50 por milhão de tokens), quase nunca vence só no custo.
• A utilização é o multiplicador que mata o caso a solo. Uma GPU alugada custa o mesmo em repouso e a plena carga, por isso uma GPU a correr a 10% de utilização custa por token cerca de 10× o que custa a plena carga. As cargas de trabalho a solo, em rajadas, ficam por defeito em baixa utilização.
• Abaixo do ponto de equilíbrio, a poupança de custo é normalmente mudar para uma API de peso aberto económica, não o self-hosting. O self-hosting justifica-se quando o volume sustentado face aos preços de fronteira ultrapassa a linha com 60%+ de utilização, ou quando tem uma razão que não é de custo (privacidade, latência, controlo de fine-tuning).
• Aplique a fórmula aos seus próprios números antes de alugar seja o que for. Tokens no ponto de equilíbrio ≈ custo mensal da VPS de GPU ÷ o seu preço de API combinado por token.

O Que Isto Não Cobre

• Clusters de GPU multi-nó ou à escala de datacenter. Esta é uma decisão de custo a solo, não uma frota.
• A economia do fine-tuning em qualquer profundidade (um cálculo à parte, com os seus próprios compromissos).
• Um tutorial passo a passo de configuração Ollama-vs-vLLM. O âmbito aqui é a questão do dinheiro, não a instalação.
• Hardware próprio como o seu veículo principal. O pressuposto ao longo de tudo é uma GPU alugada, já que esse é o caminho realista para um builder que ainda não tenha uma GPU em cima da secretária.

O Que Determina o Custo (e Onde os Números Populares Se Enganam)

Pesquise "self host LLM vs API cost" e vai cair numa figura de equilíbrio arrumadinha: algo como 11 mil milhões de tokens por mês, ou cerca de $4,200 em gasto mensal de API, citada pela análise de custos da braincuber e ecoada quase textualmente na AI Overview no topo da página. É um número limpo. Mas é também quase inútil por si só, porque esconde as duas variáveis que decidem a sua resposta.

A razão por que isto é escorregadio é que os dois lados da comparação têm formas de custo diferentes. Uma fatura de API é um custo variável: paga por token, por isso a fatura sobe e desce consoante o quanto a usa. Uma GPU alugada é um custo fixo: paga a mesma taxa mensal quer empurre mil milhões de tokens por ela quer a deixe parada. Comparar um custo variável com um custo fixo com um único número exige fingir que sabe exatamente quantos tokens vão fluir, e à escala a solo, normalmente não sabe.

Isso deixa três alavancas que movem o ponto de equilíbrio:

• Com que API se está a comparar. Uma API de fronteira e uma API de peso aberto económica estão separadas por cerca de duas ordens de grandeza no preço. O ponto de equilíbrio face a cada uma é radicalmente diferente.
• A sua utilização de GPU. O custo fixo só compensa se a GPU estiver ocupada. O tempo parado é dinheiro que gastou para nada.
• O custo oculto de operações. As suas horas, a rotatividade de atualizações de modelos, e as surpresas de VRAM que só aparecem quando já está em produção.

Ponha um preço a cada uma dessas e o nevoeiro dissipa-se. É esse o resto deste artigo.

Conclusão da secção: o ponto de equilíbrio não é um número único. São três números, um por escalão de API, e escolher o escalão errado para comparar é onde a maioria das estimativas de custo se engana.

O Ponto de Equilíbrio a Três Vias: API de Fronteira vs. Intermédia vs. Económica

Fazer self-hosting de um LLM de peso aberto numa VPS de GPU bate uma API de fronteira (classe GPT-5, Claude Sonnet 5 / Opus 4.8, Gemini Pro) por volta de uns milhões de tokens por dia, desde que mantenha a GPU numa utilização saudável (digamos 60% ou mais). Face a uma API de peso aberto económica a cerca de $0.14–$0.50 por milhão de tokens, raramente vence no custo, se é que vence. Essa diferença é a história toda, e é por isso que um único número de equilíbrio não pode estar certo.

Aqui vai o contorno da coisa ao longo dos três escalões. Trate estes limiares como intervalos indicativos, não como linhas rígidas. Vêm de estimativas da comunidade e dos preços de 2026, e ambos mudam depressa.

Preços das páginas de preços da OpenAI, Anthropic, Google, DeepInfra, Together, e DeepSeek à data de julho de 2026. Cada um destes números tem uma validade medida em meses, por isso verifique as páginas atuais antes de se comprometer.

Agora o ponto contrário, porque é o que muda decisões. Anda por aí um argumento alto e correto de que as APIs económicas mataram o ponto de equilíbrio do self-hosting. As APIs de peso aberto como as da DeepInfra e Together servem agora modelos Llama e Qwen a uma fração dos preços de fronteira, e os próprios preços de fronteira caíram acentuadamente desde 2025. Face a essas taxas económicas, o equilíbrio por token dispara para os milhares de milhões de tokens por mês. Um solopreneur não está a empurrar milhares de milhões de tokens por mês. Por isso, se o seu único objetivo é uma fatura mais baixa, o primeiro passo normalmente não é "alugar uma GPU", é "mudar para uma API de peso aberto económica e ter zero operações".

O argumento de custo do self-hosting sobrevive em dois sítios: na comparação com preços de fronteira caros a um volume genuinamente alto e sustentado, e nas razões que não são de custo (privacidade, latência, controlo de fine-tuning) abordadas mais abaixo. Em todo o resto, a API económica vence o argumento do dinheiro.

A Fórmula do Ponto de Equilíbrio

break-even tokens per month ≈ GPU VPS monthly cost ÷ your blended API price per token

Exemplo trabalhado, à escala de solopreneur: digamos que uma única VPS de GPU topo de gama custa cerca de $1,000/mês (intervalo de catálogo de 2026 para um escalão de GPU única de topo), e está numa API de fronteira com uma taxa combinada à volta de $6 por milhão de tokens (aproximadamente $0.000006 por token). Isso dá ~$1,000 ÷ $0.000006 ≈ 167 milhões de tokens/mês antes de a GPU se pagar no papel. Agora refaça face a uma API de peso aberto económica a $0.40 por milhão ($0.0000004/token): ~$1,000 ÷ $0.0000004 = 2.5 mil milhões de tokens/mês. Mesma GPU, mesmo custo fixo, e o ponto de equilíbrio move-se mais de 10× dependendo puramente da API que puser no denominador. E isto é antes da utilização, que piora o número.

Conclusão da secção: A API com que se compara pode mover o seu ponto de equilíbrio em 10× ou mais, por isso "fazer as contas" significa fazê-las face à API específica que substituiria de facto.

O Que a Utilização Faz ao Custo por Token

Pegue nesse equilíbrio de fronteira de ~167 milhões de tokens e acrescente a variável que a fórmula assume calmamente de lado: a sua GPU está ocupada o tempo todo. Não está. Uma GPU alugada fatura o mesmo esteja saturada ou parada, por isso o seu custo efetivo por token na VPS de GPU escala de forma inversa à utilização. Corra a 10% de carga e cada token que serve carrega cerca de 10× o custo que teria a plena carga, porque está a pagar pelos 90% de capacidade que não usou. As estimativas da comunidade e os relatos de profissionais colocam o piso prático à volta de 50–60% de utilização sustentada antes de os números deixarem de o envergonhar (figuras indicativas, não constantes de laboratório).

Para uma carga de trabalho a solo em rajadas (tráfego que dispara durante o dia e estabiliza a zero durante a noite), 60% de utilização sustentada é difícil de atingir. É essa a armadilha. Eis o que isso faz ao custo por milhão de tokens em alguns pontos concretos, usando os preços de GPU de catálogo de 2026 divididos pela vazão mensal aproximada em cada nível de utilização:

Os cêntimos absolutos por token dependem do seu modelo, da quantização e de quantos pedidos concorrentes consegue meter na placa, por isso trate as colunas como mostrando a forma da penalização e não uma cotação. O que importa é o multiplicador: caia de plena carga para um quarto de carga e o seu custo por token quadruplica aproximadamente. É normalmente isso que mata o caso do self-hosting a solo, não o preço de tabela da GPU.

Há uma escotilha de fuga estrutural, e é a razão pela qual alugar pode bater ter para uma procura irregular: pode parar uma instância alugada quando está parada. Seja dono do hardware e ele deprecia-se e consome energia quer o use quer não. Em aluguéis à hora ou a pedido, pode parar ou desmontar a instância quando o trabalho termina e evitar pagar por horas paradas. Em planos mensais fixos, a fatura continua fixa para o período de faturação, por isso a utilização continua a ser o principal problema de custo. Isto não resolve uma carga de trabalho genuinamente de baixa utilização o dia todo, mas para uma procura ocupada em rajadas e morta no intervalo, a capacidade de desligar o contador é a única alavanca que faz o alugar-vs-ter pender para o alugar.

Conclusão da secção: a utilização, e não o preço mensal da GPU, é normalmente o que decide se o self-hosting fecha as contas, e é a variável que os números populares de equilíbrio deixam de fora por completo.

Que Modelo Cabe em Que GPU: a Realidade da VRAM

O plano que se parte primeiro é "vou só executar um 70B numa 4090". Não consegue. Um modelo de 70B com quantização Q4_K_M precisa de aproximadamente 40–46 GB de VRAM, e uma RTX 4090 de 24 GB ou uma RTX 5090 de 32 GB simplesmente não têm espaço. Force-o para uma placa de 24 GB e fica reduzido à quantização Q2_K (à volta de 21 GB) com perda de qualidade visível, ou o modelo transborda para a RAM de sistema e a velocidade de geração colapsa. A VRAM é a parede rígida que decide que modelos estão sequer em cima da mesa para uma dada GPU.

Eis o que cabe onde. As figuras de VRAM são aproximadas: derivam da aritmética padrão de bytes por parâmetro (FP16 ≈ params × 2 com ~15% de overhead; Q4_K_M ≈ params × ~0.55 com overhead), por isso trate-as como orientação de dimensionamento, não como garantias.

As figuras de VRAM são cruzadas com as páginas oficiais de especificações de GPU da NVIDIA para cada placa. A A100 dá a um 70B quantizado uma margem mais confortável; a RTX 6000 Ada pode funcionar para setups Q4 mais apertados, ao passo que as placas de consumo de 24 GB e 32 GB não têm VRAM suficiente para uma implantação normal de um 70B Q4. Se quiser a análise completa de como os formatos GGUF, GPTQ, AWQ e EXL2 consomem memória, essa é uma toca de coelho que vale a sua própria leitura: GGUF, GPTQ, AWQ, EXL2: como os formatos de quantização de LLM realmente usam a memória.

O ponto ideal da comunidade para uma única placa de 24 GB é um modelo de 24B a 32B (Mistral Small 3.1 ou Qwen 3 32B em Q4). É esse o tamanho que dá a um builder a solo um modelo útil no escalão de GPU mais barato sem andar a lutar contra a VRAM a todo o momento. Se está a ponderar que placa alugar para começar, o nosso benchmark H100 vs RTX 4090 para cargas de trabalho de IA compara os escalões em vazão.

Dica: reserve orçamento para o KV cache, não só para os pesos. A surpresa de primeira implantação mais comum: dimensiona a GPU para os pesos do modelo, carrega-o, e cabe. Depois chegam os pedidos, o KV cache cresce com o comprimento de contexto e a concorrência, e fica sem VRAM a servir os seus primeiros utilizadores. Quando a VRAM transborda e o modelo passa para a CPU, a velocidade de geração cai 10–100×. Deixe margem acima das figuras de peso na tabela para o cache, sobretudo se estiver a servir contextos longos ou vários utilizadores ao mesmo tempo.

Os Custos Ocultos Que Apagam a Poupança Ingénua

A folha de cálculo que diz que o self-hosting é mais barato quase sempre tem uma linha: o preço mensal da GPU. A fatura que paga tem mais linhas. Há o seu tempo (cada hora que passa a corrigir, a reiniciar um servidor de inferência pendurado, ou a perseguir um crash de falta de memória é uma hora que não passou no produto). Há a rotatividade de atualizações de modelos: o modelo de peso aberto que implantou fica ultrapassado, e voltar a fazer benchmark e a implantar é trabalho recorrente, não uma configuração única. Há a surpresa de VRAM e de KV cache da secção anterior. E há o desperdício em repouso, as horas em que a GPU fica a faturar enquanto nada corre.

Os profissionais que contaram estas coisas colocam o custo verdadeiro em aproximadamente 1.3–2× o preço bruto da GPU depois de dobrada a hora de operações, e alguns vão mais alto, até 3–5×, em setups mais desarrumados. São multiplicadores indicativos de relatos da comunidade, não figuras auditadas, mas a direção é o que importa. Como diz um enquadramento muito citado, uma GPU parada não é um ativo, é um passivo faturado à hora. Para um builder a solo, a forma certa de pôr preço a isto não é uma linha de salário de MLOps, são as suas próprias horas, que são a coisa mais escassa que tem. Se o self-hosting lhe poupa $200 por mês no papel mas lhe custa seis horas de operações que de outra forma passaria a produzir, isso não é obviamente uma vitória.

Quando o Self-Hosting Vence Mesmo Assim: Privacidade, Latência e Fine-Tuning

O custo não é a única razão para executar o seu próprio modelo, e para alguns builders nem sequer é a principal. Abaixo do ponto de equilíbrio de custo, onde o dinheiro diz "fique na API", há três razões para fazer self-host à mesma. Soberania de dados: manter os prompts e os dados dos seus utilizadores fora do pipeline de um fornecedor de IA externo, o que importa para alguns produtos independentemente do que digam os números. Latência previsível: sem fila de inquilinos partilhados, sem limites de taxa que não definiu, sem lentidões-surpresa durante o pico de tráfego de outra pessoa. E controlo total: a liberdade de fazer fine-tune, quantizar, trocar modelos e fixar versões sem esperar por um fornecedor.

Há uma ressalva quanto ao ponto da privacidade, e saltá-la seria desonesto. Uma VPS de GPU alugada continua a correr no hardware de outra pessoa, num datacenter de outra pessoa. Isso é uma soberania significativa face ao pipeline de treino e de registo do fornecedor de IA (os seus prompts não estão a fluir pelos sistemas de um fornecedor de modelos), mas não é o mesmo que equipamento on-premises que controla fisicamente. Se o seu requisito é isolamento on-prem verdadeiro, uma VPS alugada não o leva lá. Se o seu requisito é "manter os nossos dados fora das mãos de um fornecedor de modelos externo", leva. Saiba de qual precisa.

Para cargas de trabalho que correm em ambientes de rede restritivos, um modelo self-hosted em infraestrutura que controla também pode contornar dependências de endpoints externos que possam estar inacessíveis, uma capacidade que importa independentemente de onde o implanta.

Então Deve Fazer Self-Host? Uma Resposta Direta por Situação

Tudo o que está acima arruma-se numa decisão curta. Tem uma fatura, uma noção grosseira do seu volume mensal de tokens, e agora os três escalões de equilíbrio, a penalização de utilização e o multiplicador de custo oculto. Mapeie a sua situação a uma destas:

• Está abaixo do equilíbrio de fronteira e o custo é a sua única preocupação. Fique numa API, e ponha a sério o preço de uma API de peso aberto económica (DeepSeek, DeepInfra, Together) antes de qualquer outra coisa. É normalmente essa a poupança de custo, não o self-hosting. Trocar de API é uma alteração de configuração; o self-hosting é um segundo emprego.
• Tem volume alto e sustentado face a preços de fronteira e consegue manter uma GPU a 60%+ de utilização. É aqui que o self-hosting compensa. Aplique a fórmula à sua taxa de fronteira, confirme que ultrapassa o limiar com utilização sustentada (não de pico), e uma VPS de GPU alugada começa a vencer.
• Tem um fator que não é de custo: privacidade, latência ou controlo de fine-tuning. Faça self-host abaixo do ponto de equilíbrio deliberadamente, com os olhos abertos de que está a pagar pelo controlo. Só não diga a si próprio que é mais barato se não for.
• Está a meio caminho. Veja o padrão híbrido em que a maioria dos profissionais aterra em 2026: um pequeno modelo self-hosted para tarefas simples de alto volume, mais uma API de fronteira para o raciocínio difícil ao qual o seu modelo local chega a 85–90% do caminho (benchmarks da comunidade, não verificados em laboratório, e o último troço é muitas vezes onde mais precisa da qualidade).

Quanto à questão de "como arranjo a GPU", a resposta para um builder a solo é quase sempre alugar, não comprar. Ser dono de hardware de nível datacenter é uma aposta de capex que só faz sentido a uma escala que ainda não tem. A inferência serverless pode reduzir o desperdício em repouso ao escalar para zero e faturar só pela computação ativa, mas muitas vezes troca isso por uma taxa por hora de GPU mais alta e por latência de cold-start. Uma VPS de GPU alugada fica no meio: sem capex, uma fatura mensal previsível, acesso root, e a capacidade de parar a instância quando está parada.

Se aplicou a fórmula, ultrapassou o ponto de equilíbrio, e quer um servidor de inferência dedicado, privado e com acesso root sem comprar uma placa, é exatamente para isso que serve uma máquina de GPU alugada. Os planos de VPS de GPU da Cloudzy cobrem a gama desde um modelo de 8B numa única placa até um 70B quantizado, e a aplicação Ollama de um clique no marketplace implanta-se em cerca de um minuto com uma REST API compatível com clientes OpenAI, por isso a mudança de uma API paga para o seu próprio servidor pode aproximar-se de uma alteração drop-in no seu código, sem custo por token depois da mensalidade fixa. Consulte a página para os preços atuais; as taxas de GPU mudam.

A única ação que vale a pena tomar antes de alugar seja o que for: aplique a fórmula do ponto de equilíbrio à sua própria fatura. Leva dois minutos e vai dizer-lhe em qual das quatro situações acima se encontra.

Perguntas frequentes

É Mais Barato Fazer Self-Host de um LLM ou Usar uma API?

Depende de qual API. Fazer self-hosting de um modelo de peso aberto numa VPS de GPU pode bater uma API de fronteira (classe GPT-5, Claude Sonnet 5 / Opus 4.8) a um volume alto e sustentado com boa utilização de GPU. Raramente bate uma API de peso aberto económica (DeepSeek, DeepInfra, Together a cerca de $0.14–$0.50 por milhão de tokens à data de julho de 2026) só no custo: esse ponto de equilíbrio dispara para os milhares de milhões de tokens por mês, que a maioria dos builders a solo nunca alcança.

Que GPU Preciso Para Executar um Modelo de 70B?

Um modelo de 70B com quantização Q4_K_M precisa de aproximadamente 40–46 GB de VRAM só para os pesos quantizados. Uma A100 de 80 GB é a opção de GPU única mais segura porque deixa espaço para o KV cache, o overhead de runtime e prompts mais longos. Uma RTX 6000 Ada de 48 GB pode funcionar para setups Q4 mais apertados, mas o comprimento de contexto e a concorrência têm de ser geridos com cuidado.

Como É Que a Utilização de GPU Afeta o Custo por Token?

Uma GPU alugada custa o mesmo esteja parada ou a plena carga, por isso o seu custo efetivo por token escala de forma inversa à utilização. A 10% de carga, cada token que serve custa cerca de 10× o que custaria a plena carga, porque está a pagar pela capacidade não utilizada. O piso prático para o self-hosting fazer sentido é à volta de 50–60% de utilização sustentada.

Quantos Tokens por Mês Antes de o Self-Hosting Valer a Pena?

Face a uma API de fronteira, cerca de 160–256 milhões de tokens por mês a uma utilização saudável é o limiar indicativo (à data de julho de 2026). Face a uma API de peso aberto económica são milhares de milhões por mês, na prática inalcançável a solo. O número exato depende do seu custo de GPU e da taxa de API combinada, por isso aplique a fórmula: tokens no ponto de equilíbrio ≈ custo mensal da VPS de GPU ÷ o seu preço de API por token, e depois desconte-o para a utilização sustentada.

Posso Executar um LLM de Peso Aberto numa VPS?

Sim, numa VPS de GPU dimensionada à VRAM do modelo. Uma ferramenta como o Ollama executa modelos de peso aberto (Llama, Qwen, Mistral e outros) com uma implantação de um clique e uma REST API compatível com OpenAI, por isso o seu código existente que chama APIs pode apontar para o seu próprio servidor com alterações mínimas. Faça corresponder o escalão de GPU ao seu modelo: um 8B cabe confortavelmente numa placa de 24 GB, um 70B quantizado precisa de 48–80 GB.