Executar agentes de IA em hardware próprio só compensa financeiramente face a modelos frontier dispendiosos, e apenas acima de cerca de 5 milhões de tokens por dia. Face às API de modelos de pesos abertos, que se situam entre 0,14 e 0,50 dólares por milhão de tokens, o ponto de equilíbrio desloca-se para milhares de milhões de tokens por mês e a maioria das organizações nunca lá chegará. A implicação é simples: se o custo for a única consideração, a resposta é normalmente não. Os argumentos que se sustentam são a soberania dos dados, a fixação da versão e a latência — e esses têm de ser avaliados com honestidade.
A pergunta que quase todas as organizações fazem é a pergunta errada
A discussão abre quase sempre com quanto vamos poupar se corrermos isto internamente. É uma pergunta que se consegue calcular, o que a faz parecer segura — mas quase nunca é a verdadeira razão pela qual uma organização executa um modelo em casa.
Três argumentos sustentam-se, e nenhum deles é a poupança direta. O primeiro é a soberania dos dados: quando a informação que entra no prompt não pode sair da organização, a questão económica é secundária face à questão da autorização. O segundo é a fixação da versão: um fornecedor que atualiza um modelo altera o comportamento de um agente calibrado para a versão anterior, ao passo que um modelo a correr em hardware próprio não muda enquanto não for essa a vossa decisão. O terceiro é a latência estável em volume elevado, em particular para tarefas de classificação e extração que correm centenas de vezes por minuto.
Se nenhum destes três casos se aplica, a aritmética que se segue devolve-vos quase sempre à API.
A aritmética, sem magia
Em meados de 2026, alugar uma única H100 custa entre cerca de 2 dólares por hora nos fornecedores de GPU dedicados e cerca de 14 dólares por hora nos hyperscalers, com o acesso on-demand a rondar os 3 dólares por hora. Comprar uma placa custa de 30.000 a 40.000 dólares para cima. Tomemos um preço reservado de 2 dólares por hora — cerca de 1.460 dólares por mês para uma placa em funcionamento contínuo.
| Com o que está a comparar | Preço por milhão de tokens | Volume mensal no ponto de equilíbrio | Equivalente diário |
|---|---|---|---|
| Modelo frontier dispendioso | 10 $ | ~146 milhões | ~5 milhões |
| Modelo frontier mais barato | 2,50 $ | ~584 milhões | ~19 milhões |
| API de modelo de pesos abertos | 0,25 $ | ~5,8 mil milhões | ~195 milhões |
A tabela é calculada diretamente: 1.460 dólares por mês a dividir pelo preço por milhão de tokens. A terceira linha é a que encerra a discussão na maioria das organizações — 195 milhões de tokens por dia é o volume de um produto à escala, não de um agente interno.
Note-se que este cálculo é generoso para o lado do hardware. Pressupõe um preço reservado, uma única placa e custo operacional zero. Os três pressupostos caem em produção.
A utilização é toda a história
Uma API cobra por token. Uma placa cobra por hora, incluindo as horas em que ninguém lhe envia nada. É essa diferença que torna errada a maioria dos cálculos de ROI de alojamento próprio.
Um modelo quantizado na classe dos 70 mil milhões de parâmetros, numa única H100 com batching eficiente, atinge a ordem dos 3.000 tokens por segundo. A 2 dólares por hora, isso traduz-se assim.
| Utilização média | Custo efetivo por milhão de tokens | Face a uma API de pesos abertos |
|---|---|---|
| 100% | ~0,19 $ | Competitivo |
| 50% | ~0,37 $ | Igual ou mais caro |
| 25% | ~0,74 $ | Três vezes mais caro |
| 10% | ~1,85 $ | Sete vezes mais caro |
Utilização a 100% não existe no mundo real. A carga do negócio é cíclica — horário de trabalho, dias úteis, fecho do mês — pelo que uma utilização média de 50 a 60 por cento é considerada muito boa para uma carga interna. Abaixo disso, o alojamento próprio perde tanto para as API de pesos abertos como para parte do frontier.
Daqui decorre uma regra prática simples: se não conseguir apontar uma carga contínua que encha a placa pelo menos metade do tempo, está a pagar por ar.
O que o cálculo deixa de fora
O preço da placa é a única componente fácil de orçamentar, e é por isso a única que é orçamentada. O custo total do alojamento próprio em produção fica tipicamente três a cinco vezes acima.
- Redundância. Uma placa é um ponto único de falha. Um agente que serve clientes precisa de pelo menos duas, ou de uma rota de recurso para uma API.
- Operações. Um servidor de inferência, monitorização, gestão de filas, atualizações de drivers e requantização a cada atualização de modelo.
- Piquete. Alguém tem de responder quando a GPU cai às duas da manhã. Uma API tem SLA; a vossa placa tem-vos a vós.
- Infraestrutura de testes. Cada troca de modelo ou alteração de quantização exige uma execução completa do conjunto de testes, como se detalha no guia de avaliação de agentes.
- Custo de oportunidade. Um modelo que fixou há um ano fica onde está enquanto o frontier avança.
A arquitetura que funciona mesmo: encaminhamento por tarefa
A escolha não é binária. Um agente de negócio típico executa um conjunto de tarefas de natureza muito distinta, e a lógica económica difere em cada uma.
| Tipo de tarefa | Características | Onde executar |
|---|---|---|
| Classificação, etiquetagem, extração de campos | Volume elevado, saída curta, exige consistência | Modelo pequeno em hardware próprio |
| Sumarização e reescrita | Volume médio, qualidade média é suficiente | API de modelo de pesos abertos |
| Planeamento, raciocínio, decisões | Volume baixo, alta sensibilidade à qualidade | Modelo frontier via API |
| Dados sensíveis que não podem sair | Restrição regulatória | Hardware próprio, independentemente do volume |
Este encaminhamento entrega a maior parte da poupança sem a maior parte do risco: as tarefas de volume elevado, que são também as mais simples, descem para um modelo local barato, enquanto as decisões difíceis ficam com o melhor modelo disponível. Outras técnicas para reduzir o custo na camada da API são tratadas no guia de redução do custo de inferência, e a última linha da tabela deve derivar da vossa classificação de dados empresariais.
Seis perguntas antes de comprar uma placa
- Qual é hoje o vosso volume diário de tokens, medido e não estimado, e qual a sua taxa de crescimento.
- Com que preço alternativo estão a comparar — frontier ou pesos abertos. As duas respostas apontam em direções opostas.
- Que utilização esperam ao longo de um dia e de uma semana, incluindo as horas sem tráfego.
- Quem na equipa mantém o servidor de inferência, e o que acontece quando essa pessoa está de férias.
- Existe uma rota de recurso para uma API quando o hardware falha, e quem decide mudar para ela.
- Existe um argumento que não seja o custo. Se não, a decisão fica quase sempre com a API.
Esta decisão parece infraestrutura mas é arquitetura. Determina que partes do agente podem mudar e quais ficam fixas, pelo que deve ser tomada contra o mapa completo de componentes descrito em Anatomia de um agente de IA empresarial.
Perguntas frequentes
É mais barato correr um modelo de IA no nosso próprio servidor?
Apenas em condições específicas. Face a um modelo frontier a cerca de 10 dólares por milhão de tokens, o ponto de equilíbrio de uma H100 reservada situa-se em cerca de 5 milhões de tokens por dia. Face a uma API de modelo de pesos abertos a cerca de 0,25 dólares por milhão, o equilíbrio salta para perto de 195 milhões de tokens por dia, um volume que a maioria das organizações nunca atinge.
Qual é o ponto de equilíbrio entre alojamento próprio e API?
Decorre de uma divisão simples: o custo mensal do hardware a dividir pelo preço alternativo por milhão de tokens. Uma placa que custa cerca de 1.460 dólares por mês face a uma API a 10 dólares por milhão atinge o equilíbrio perto dos 146 milhões de tokens por mês. Multiplique o resultado por três a cinco para refletir o custo operacional completo.
Porque é que a utilização da GPU importa tanto?
Porque uma API cobra por token enquanto uma placa cobra por hora, incluindo horas ociosas. A carga cíclica do negócio produz, no melhor dos casos, uma utilização média de 50 a 60 por cento, pelo que o custo efetivo por milhão de tokens é quase sempre pelo menos o dobro do cálculo teórico.
Quais são os argumentos não económicos a favor do alojamento próprio?
Três principais: soberania dos dados quando a informação não pode sair da organização, fixação da versão do modelo para que um agente calibrado não se desloque porque um fornecedor lançou uma atualização, e latência estável em tarefas de volume elevado. Quando um destes se aplica, a questão económica é secundária.
É possível combinar os dois?
Habitualmente é essa a arquitetura certa. Classificação e extração de volume elevado correm num modelo local pequeno, a sumarização numa API de pesos abertos, e as decisões e o raciocínio num modelo frontier. Este encaminhamento remove a maior parte do custo sem abdicar da qualidade onde ela decide o resultado.