Custo por milhão de tokens: on-prem vs cloud

Há três formas honestas de comprar inferência de LLM em 2026: chamar o endpoint alojado de outra empresa e pagar por token (API de LLM na cloud), alugar uma GPU à hora e executar o seu próprio modelo (aluguer de GPU na cloud), ou comprar um servidor e pô-lo a funcionar no seu próprio rack (on-prem). O preço de um milhão de tokens é radicalmente diferente nas três opções — e não pela ordem que a maioria dos compradores assume.

Este artigo faz as contas em EUR sem IVA. Público-alvo: quem está a decidir se continua a pagar mensalmente à OpenAI, se muda para um fornecedor de modelos abertos alojados, se aluga um H100 ou se compra uma máquina de 4 ou 8 GPUs. Citamos preços de maio de 2026 e terminamos com um fluxo de decisão de cinco minutos. Referências cruzadas: T01 TCO por GPU, W07 seleção de placas, I04 números do lado da tomada.

As três plataformas

API de LLM na cloud. OpenAI, Anthropic, Google, Together, Fireworks. Paga-se por token de entrada e por token de saída. Sem custo em repouso, sem capex, sem operações. Também sem escolha de modelo para além do catálogo deles, sem LoRA e sem controlo da quantização.

Aluguer de GPU na cloud. AWS p5/p5e/p6, Azure ND H200/B200, GCP A3 Ultra, além de clouds especializadas (Lambda, CoreWeave, Nebius, RunPod). Aluga uma instância com GPU à hora e corre o que quiser. Traz o modelo, a stack de serviço e as operações. Paga quer sirva um token, quer sirva mil milhões nessa hora.

On-prem. Comprar uma máquina de 4 ou 8 GPUs. Montá-la em rack, no seu edifício ou num colocation. Traz a energia, o arrefecimento, a rede e as operações. Amortiza em três anos. O custo marginal de um token é a eletricidade. O custo fixo é tudo o que já pagou.

Três formas de custo diferentes — puramente variável, puramente fixa com degrau, capex mais custo marginal — que atingem o ponto de equilíbrio entre si em pontos diferentes do eixo do débito.

Preços das APIs de LLM na cloud

USD por milhão de tokens, páginas de preços públicas, maio de 2026. EUR a uma taxa EUR/USD ≈ 1.08.

Fornecedor Modelo Entrada $/Mtok Saída $/Mtok Entrada €/Mtok Saída €/Mtok
OpenAI GPT-5 1.25 10.00 1.16 9.26
OpenAI GPT-5 mini 0.25 2.00 0.23 1.85
OpenAI GPT-5 nano 0.05 0.40 0.05 0.37
OpenAI GPT-4.1 / o3 2.00 8.00 1.85 7.41
Anthropic Claude Opus 4.7 15.00 75.00 13.89 69.44
Anthropic Claude Sonnet 4.6 3.00 15.00 2.78 13.89
Anthropic Claude Haiku 4.5 1.00 5.00 0.93 4.63
Google Gemini 2.5 Pro 1.25 10.00 1.16 9.26
Google Gemini 2.5 Flash 0.30 2.50 0.28 2.31
Google Gemini 2.5 Flash-Lite 0.10 0.40 0.09 0.37
Together Llama 3.3 70B 0.88 0.88 0.81 0.81
Together Qwen 2.5 72B 1.20 1.20 1.11 1.11
Together DeepSeek-V3 1.25 1.25 1.16 1.16
Together Llama 3.1 405B 3.50 3.50 3.24 3.24
AWS Bedrock Llama 3.3 70B 0.72 0.72 0.67 0.67
Azure Llama 3.3 70B 0.59 0.79 0.55 0.73

Duas leituras honestas. Os modelos fechados de fronteira (Claude Opus 4.7, GPT-5, Gemini 2.5 Pro) são uma ordem de grandeza mais caros do que as APIs de modelos abertos alojados que servem Llama 70B ou DeepSeek-V3 — é o preço do "mais inteligente agora" face aos "melhores pesos abertos agora". Para a maioria das cargas de trabalho em produção (RAG, passos de agentes, código, classificação), o ponto de operação é o Sonnet 4.6 ou o GPT-5 mini, e não o topo de gama. Os tokens de saída custam três a sete vezes mais do que os de entrada nos fornecedores fechados e sensivelmente o mesmo em quem aloja modelos abertos. As SKU de modelos abertos dos hiperescaladores (Bedrock, Azure) cobram um prémio de 30–80% face à Together ou à Fireworks pelo mesmo modelo — está a pagar a integração com IAM e uma fatura única, não tokens mais baratos.

Custo por Mtok em on-prem

O custo por Mtok é o custo total a três anos dividido pelos tokens servidos nesses três anos. O denominador depende da utilização; o numerador é praticamente fixo.

€/Mtok on-prem =
    (capex + eletricidade 3 anos + manutenção 3 anos + operações 3 anos) /
    (tok/s sustentados × utilização × 3 × 8,760 × 3,600 / 1e6)

Introduzindo o TCO por GPU de T01 a 60% de utilização, €0.20/kWh, PUE 1.4:

Configuração TCO 3 anos € tok/s sustentados Tokens/3 anos (Mtok) € / Mtok
4× RTX 5090 (Llama 70B INT4 TP=4) 27,000 1,800 102,000 0.26
4× Pro 6000 BW SE (Llama 70B FP8 DP) 58,000 1,920 109,000 0.53
4× Pro 6000 BW SE (Qwen 32B INT4) 58,000 2,400 136,000 0.43
8× Pro 6000 BW SE (Llama 70B FP8 DP) 115,000 3,800 215,000 0.53
8× L4 (Llama 8B FP8) 36,000 5,200 295,000 0.12

Baixe a utilização para 30% e todos os valores duplicam. Suba para 80% e o 8B servido em L4 fica a €0.09/Mtok, mais barato do que qualquer API na cloud dessa classe. As contas desmoronam-se abaixo de 25% de utilização, porque o TCO é dominado pelo capex que pagou, quer o tenha usado quer não.

O ponto de equilíbrio

Sobreponha a linha da cloud. Llama 70B a 100 M tokens/mês, equilibrado 50/50, na Together: 100 × €0.81 = €81/mês → €2,916 em três anos. Contra uma máquina on-prem com 4× 5090 a €27,000, a Together ganha por €24,000. A 100 M tokens/mês, o on-prem é completamente desadequado.

Suba para 1 B tokens/mês: 1,000 × €0.81 = €810/mês → €29,160 em três anos. A Together e as 4× 5090 ficam a menos de €2,000 uma da outra. A 1.5 B/mês, o on-prem ganha de forma material.

O ponto de equilíbrio da inferência de classe 70B face à API de modelos abertos alojada mais barata situa-se por volta de 1.0–1.5 B tokens por mês sustentados numa máquina com 4× 5090. Para as APIs fechadas de fronteira (Claude Sonnet 4.6 a €8.34/Mtok combinado, GPT-5 a €5.21/Mtok combinado), o ponto de equilíbrio desce para 80–150 M tokens/mês — a linha da cloud é uma ordem de grandeza mais inclinada.

Este é o número mais importante do artigo: o ponto de equilíbrio não é "100 M tokens/mês para tudo". É específico de cada carga de trabalho e depende inteiramente da linha de cloud com que está a competir. Os compradores que dizem "chegámos aos 50 M, devíamos passar para on-prem" costumam estar a comparar com o Claude Opus, caso em que até têm razão — ignorando que mudar a carga de trabalho do Opus para o Sonnet 4.6 lhes poupa cinco vezes mais do que passar do Sonnet para on-prem nesse volume.

Aluguer de GPU na cloud — a opção intermédia

Tarifas horárias por GPU, on-demand em maio de 2026:

Fornecedor Instância GPUs $/h por instância $/GPU-h
AWS p5.48xlarge 8× H100 SXM 55.18 6.90
AWS p5e.48xlarge 8× H200 SXM 30.00 3.75
AWS p6-b200 8× B200 74.88 9.36
Azure ND H200 v5 8× H200 31.00 3.88
GCP a3-ultragpu-8g 8× H200 28.00 3.50
Lambda 8× H100 8× H100 16.00 2.00
CoreWeave 8× H100 8× H100 19.20 2.40

Compromissos reservados a 1 ano cortam 25–35%. O p5 on-demand da AWS custa cerca de 3× o da Lambda para o mesmo silício H100. Traduzindo para custo por token: 8× H100 na Lambda a correr Llama 3.3 70B FP8 a ~3,500 tok/s sustentados → $16/h × 8,760 × 3 = €389,000 em 3 anos → €1.96/Mtok a 60% de utilização. Isso é 4× uma máquina on-prem com 8× Pro 6000 SE (€0.53/Mtok) e 2.5× o custo de simplesmente chamar a Together (€0.81/Mtok).

Alugar H100 para servir inferência de modelos abertos é o pior dos dois mundos: paga tarifas de aluguer pela máquina e ainda tem de a operar. As contas só funcionam quando precisa de um modelo específico que ninguém aloja e não tem volume para on-prem. O aluguer de GPU na cloud tem, ainda assim, um caso de uso honesto: treino em picos. Um fine-tune LoRA em 8× H100 durante 8 horas custa ~$130 na Lambda. Nenhum TCO on-prem bate isso para um trabalho pontual. A lógica não se transfere para a inferência, que é sustentada e corre 24/7. A armadilha do "spot": os escalões spot/preemptible/community oferecem 50–80% de desconto, mas são interrompíveis. Servem bem para réplicas de inferência sem estado. Para um trabalho de treino de 18 horas que faz checkpoint a cada passo, duas interrupções duplicam o custo por passo concluído e já não sai mais barato do que o on-demand.

Custos escondidos que ninguém orça

Cloud: o tráfego de saída a $0.05–0.09/GB pesa quando devolve imagens, áudio ou vídeo. O registo acrescenta 5–10% à escala. O contexto refaturado é o pior — todas as APIs cobram o prompt completo em cada chamada, pelo que um contexto de agente de 50K tokens custa 50K tokens de entrada por passo de um ciclo de 20 passos. O caching de prompts (suportado pela Anthropic, OpenAI e Google) corta isto em 50–90% nos prefixos em cache, mas só se desenhar o sistema para isso. Os limites de taxa em produção começam nos 30K–500K TPM e exigem histórico de utilização; clientes novos não podem operar à escala no primeiro dia. As SKU de região UE custam mais 10–20% do que as de US East e têm menor disponibilidade.

On-prem: o tempo de operações, 0.1–0.3 FTE por servidor, representa €8k–€24k/ano que não entram nas contas por Mtok. As paragens exigem uma máquina redundante ou um recurso elegante à cloud. A eletricidade não custa €0.20/kWh em todo o lado — na indústria da UE em 2026 vai de €0.09/kWh (hídrica na Suécia e na Noruega) a €0.35/kWh (Itália, Irlanda), com a Alemanha nos €0.18–€0.22/kWh em tarifa industrial subsidiada e a Chéquia nos €0.18–€0.25/kWh em mercado comercial aberto. Para Itália ou Irlanda, todas as linhas de eletricidade de T01 sobem 50%. Um rack em colocation custa €100–€300/mês por 4U — €3,600–€10,800 em três anos, além do hardware.

O preço publicado da cloud é cerca de 1.2–1.5× a fatura real; o TCO on-prem publicado é cerca de 1.2–1.5× o preço de tabela. Os multiplicadores anulam-se na comparação.

Fatores que não são de custo

Há três coisas que se sobrepõem ao custo por Mtok para os compradores reais.

Soberania dos dados. A maior razão para os compradores europeus irem para on-prem em 2026 é o RGPD, somado às regras setoriais (DORA, NIS2, o Regulamento da IA, MDR). Enviar prompts de produção com dados pessoais, registos médicos ou segredos industriais para um endpoint alojado nos EUA é um problema contratual, independentemente do preço. SKU de região UE não significa controlo pela UE. Para um comprador regulado, o prémio do on-prem não é um custo, é o preço de poder legalmente avançar.

Piso de latência. A WAN até ao endpoint alojado mais próximo acrescenta 15–40 ms de RTT dentro da UE e 80–120 ms em ligação transatlântica. On-prem, numa LAN de 10 GbE, fica abaixo do milissegundo. Numa conversação interativa, a diferença da WAN é invisível face aos 800 ms de TTFT. Num ciclo de controlo robótico (I01) ou num agente de voz abaixo dos 300 ms, a WAN é fatal.

Personalização. As APIs na cloud entregam o modelo e a quantização que o fornecedor escolheu. Em on-prem, escolhe o modelo, a quantização, a stack de serviço (vLLM, SGLang, llama.cpp), os adaptadores LoRA e o descodificador especulativo. Para laboratórios de investigação ou produtos especializados, é isto que está a comprar — o custo por Mtok é secundário.

Se nada disto se aplicar, o comprador pertence à cloud enquanto estiver abaixo do ponto de equilíbrio. Nem todos os potenciais clientes devem comprar um servidor.

Decisão trabalhada: carga de trabalho de classe 70B em dois volumes

Perfil do cliente: SaaS que faz classificação e resumo de documentos, 70/30 entrada/saída, modelo de pesos abertos de classe 70B.

Opção A 100 M tok/mês (3 anos) A 2 B tok/mês (3 anos)
Together (Llama 3.3 70B) €2,916 €58,320
AWS Bedrock (Llama 3.3 70B) €2,412 €48,240
Claude Sonnet 4.6 (ref. de fronteira) €21,996 €439,920
On-prem 4× 5090 (amortizado) €27,000 €27,000
Lambda 8× H100 auto-alojado €389,000 €389,000

A 100 M tokens/mês, o Bedrock ganha por uma ordem de grandeza face ao on-prem; o cliente ainda não justifica a máquina. A 2 B tokens/mês, o on-prem ganha decisivamente por 1.8–2.2×, mesmo contra a alternativa alojada mais barata. O ponto de equilíbrio desta carga de trabalho ficou por volta dos 800 M – 1.2 B tokens/mês. Abaixo disso, alugue. Acima disso, compre.

Matriz de decisão

Volume / mês Modelo 8B–13B Modelo 32B Modelo 70B Fronteira (Claude / GPT-5)
< 100 M tok API na cloud API na cloud API na cloud API na cloud
100–500 M tok API na cloud ou 4× L4 API na cloud API na cloud API na cloud
500 M – 1 B 4–8× L4 on-prem 4× 5090 ou cloud Cloud (Bedrock/Together) API na cloud
1–5 B tok 8× L4 on-prem 4× 5090 4× 5090 ou 4× Pro 6000 SE Híbrido cloud + on-prem
5–50 B tok Cluster de 8× L4 4× Pro 6000 BW SE 4–8× Pro 6000 BW SE Cloud de fronteira + o resto on-prem
> 50 B tok L4 multinó 8× Pro 6000 BW SE 8× Pro 6000 SE × N Tarifas enterprise + híbrido

É conservador — um comprador regulado puxa a coluna on-prem uma linha mais cedo; um comprador experimental, uma linha mais tarde. A coluna de fronteira é especial: nenhuma configuração on-prem substitui o Claude Opus 4.7 ou o GPT-5. São SKU de qualidade que se chamam quando é preciso, não cargas de trabalho que se alojam.

A leitura honesta

A maioria dos potenciais clientes que chega convencida de que precisa de um servidor não precisa. Em volumes típicos — 5–50 M tokens/mês para um produto em fase inicial, 50–500 M em fase intermédia — as APIs na cloud ganham durante mais doze a vinte e quatro meses. A resposta certa é "use a Together ou o Bedrock, vigie a despesa mensal e contacte-nos quando ultrapassar os €1,500/mês de forma sustentada".

Os compradores para quem o on-prem faz sentido em 2026 encaixam em três perfis. Regulados: os dados não podem sair do edifício. Sustentados à escala: 1 B+ tokens/mês num modelo de classe 70B, onde as contas ganham por 2–3×. Robótica ou baixa latência: o piso imposto pela WAN inviabiliza a aplicação. Cerca de 30–40% dos nossos potenciais clientes encaixam num destes perfis. Para os restantes 60–70%, as APIs na cloud em 2026 são um produto notável e devem continuar a usá-las até as contas mudarem.

O treino é outra conversa. Quase todas as cargas de trabalho à escala dos Kentino AI (LoRA, QLoRA, fine-tune de 7B–32B) saem mais baratas em on-prem do que com aluguer de GPU na cloud — a máquina corre a 100% durante a execução. A exceção é o treino à hiperescala (pré-treino completo de 70B+, RLHF à escala), em que precisa de 8× H100 com NVLink, que não vendemos (W07 explica porquê). Alugue, execute e traga os pesos para casa.

O que fazer a seguir

Percorra esta sequência antes de falar com um fornecedor:

  1. Meça o volume mensal atual de tokens, repartido por escalão de modelo. Se não conseguir, instrumente-o durante duas semanas. Sem este número, todos os passos seguintes são adivinhação.
  2. Projete seis meses para a frente, de forma conservadora — multiplique por 1.5–2. As faturas de LLM crescem mais depressa do que o produto, porque os contextos aumentam e os agentes acrescentam passos.
  3. Identifique os escalões com honestidade. Que fração precisa mesmo de qualidade de fronteira? Que fração fica bem servida com Sonnet 4.6 / GPT-5 mini? Que fração fica bem com Llama 3.3 70B? Repartição típica: 5% / 25% / 70%.
  4. Calcule a fatura de cloud no volume projetado por escalão, a partir da tabela acima. É esse o seu concorrente.
  5. Calcule o on-prem para uma máquina com 4× 5090 ou 4× Pro 6000 SE no volume projetado, usando T01.
  6. Se a cloud exceder o on-prem em menos de 1.5×, fique na cloud. As operações, as paragens e o risco de capex comem esse pequeno ganho.
  7. Se a cloud exceder o on-prem em 2× ou mais, o caso para on-prem é real. A soberania, a latência e a personalização passam a ser critérios de desempate — e quase sempre reforçam o on-prem a essa escala.
  8. Se for regulado ou estiver limitado pela latência, salte as contas. Vai comprar on-prem de qualquer forma. Dimensione com T01 e W07.

O artigo seguinte, T03 , trabalha o sustentado face ao pico — quando faz sentido o híbrido e como dimensionar a base on-prem com transbordo para a cloud. Referências cruzadas: T01 (TCO por GPU e tok/s), W07 (seleção de GPU), I04 (a matemática elétrica do lado da tomada por trás do pressuposto de €/kWh).

Uma frase a reter: a pergunta do custo por milhão de tokens não tem resposta geral — tem uma resposta específica para a sua carga de trabalho, o seu volume, o seu escalão de modelo e o preço da eletricidade no seu país. Faça as contas antes de assinar o que quer que seja.