Self-host de IA é rodar o modelo em infraestrutura própria — servidor local ou GPU alugada — em vez de chamar a API de um fornecedor. Em 2026 a decisão deixou de ser ideológica e passou a ser aritmética, por um motivo mensurável: no Artificial Analysis Intelligence Index v4.1.1, de 13 de agosto de 2026, o melhor modelo de pesos abertos (Kimi K3, com 60 pontos) está a apenas 4 pontos do melhor proprietário (Claude Opus 5, com 63). Um ano antes essa distância era de 13 pontos. O argumento de que modelo aberto é sempre inferior perdeu a base factual — o que sobra é a conta de custo, operação e licença, que é onde este artigo se concentra.
Artificial Analysis Intelligence Index — agosto de 2026
Índice composto de 9 avaliações (v4.1.1). Em violeta, os modelos de pesos abertos.
O melhor modelo aberto está 4 pontos atrás do melhor fechado — a menor distância já registrada.
O que o índice mede — e o que ele não mede
Antes de decidir com base em um número só, vale saber como ele é construído. O Intelligence Index é composto por nove avaliações: GDPval-AA v2, τ³-Banking, Terminal-Bench v2.1, SciCode, HLE, GPQA Diamond, CritPt, AA-Omniscience e AA-LCR. É versionado — a v4.1.1 é a leitura de agosto de 2026 —, o que permite comparar edições sem confundir mudança de modelo com mudança de régua.
O que ele não mede: latência percebida, custo por tarefa concluída, qualidade em português e adequação ao seu domínio específico. Um índice composto é bom para descartar candidatos, não para escolher o vencedor.
A distância entre modelos abertos e fechados
Diferença de pontos no Intelligence Index entre o melhor modelo de pesos abertos e o melhor proprietário.
Quanto menor, mais competitivo o ecossistema aberto. A queda de 13 para 4 pontos em um ano é o dado central deste artigo.
⚠️ “Pesos abertos” não significa “livre para usar”
Este é o erro mais caro que se comete ao planejar self-host, e o caso do líder atual ilustra bem.
O Kimi K3 é distribuído com pesos públicos, mas abandonou a licença MIT das versões anteriores. A licença própria impõe duas condições que afetam diretamente quem pretende revender capacidade:
- Acordo separado obrigatório se a receita do seu serviço de modelo-como-serviço passar de US$ 20 milhões em 12 meses.
- Atribuição visível “Kimi K3” na interface acima de 100 milhões de usuários mensais ou US$ 20 milhões de receita mensal.
Uso interno está isento. A distinção prática: open weights significa que você baixa e roda; open source no sentido MIT ou Apache 2.0 significa que você também revende sem gatilho. São coisas diferentes, e a diferença aparece no jurídico, não no benchmark.
Antes de padronizar um modelo, leia o arquivo LICENSE no repositório — não o texto de marketing do anúncio.
A armadilha técnica: parâmetros ativos não definem a VRAM
Os modelos abertos de topo usam arquitetura de mistura de especialistas (MoE), e isso produz um mal-entendido frequente no dimensionamento de hardware.
O Kimi K3 tem cerca de 2,8 trilhões de parâmetros totais, mas apenas 104 bilhões ativos por token. A leitura errada é concluir que basta hardware para 104 bilhões. Não basta: os pesos precisam estar carregados na memória para que o roteador escolha quais especialistas usar a cada token. A VRAM se dimensiona pelos totais; os ativos determinam a velocidade de inferência, não o requisito de memória.
O mesmo vale para o DeepSeek V4, cuja versão Pro tem 1,6 trilhão de parâmetros com 49 bilhões ativos. Some-se a isso o cache de chave-valor, que cresce com o tamanho do contexto — em janelas de 1 milhão de tokens, ele deixa de ser detalhe e passa a ser parcela significativa do consumo.
Os modelos abertos de topo, com licença e arquitetura
| Modelo | Total | Ativos | Contexto | Licença |
|---|---|---|---|---|
| Kimi K3 | 2,8 T | ~104 B | 1 M | Própria (com gatilho de receita) |
| DeepSeek V4 Pro | 1,6 T | 49 B | 1 M | MIT ✅ |
| DeepSeek V4 Flash | 284 B | 13 B | 1 M | MIT ✅ |
| gpt-oss-120b (OpenAI) | 117 B | 5,1 B | 128 K | Apache 2.0 ✅ |
O contraste é o ponto: o melhor modelo aberto é o único com licença restritiva. DeepSeek V4 é MIT em código e pesos; o gpt-oss-120b da OpenAI é Apache 2.0. “Aberto” não é um conceito único, e a diferença aparece no contrato, não no benchmark.
Um detalhe prático do gpt-oss-120b: por usar precisão MXFP4 nativa nos pesos do MoE, ele cabe em uma única GPU de 80 GB — afirmação do próprio card do modelo. É o caminho de menor atrito para quem quer começar.
Como calcular a VRAM de verdade
Não existe tabela oficial de VRAM por modelo — quem publica número fechado está estimando. O que existe é a fórmula, e ela tem quatro parcelas:
VRAM total = pesos + cache de chave-valor + ativações + overhead
Pesos = número de parâmetros × bytes por parâmetro. Os fatores reais por precisão:
- FP16 / BF16 → 2,0 bytes
- FP8 / INT8 → 1,0
- INT4 agrupado (GPTQ, AWQ) → 0,52 a 0,55
- GGUF Q4_K_M → ≈ 0,61 — são 4,9 bits efetivos, não 4,0, detalhe que a maioria dos tutoriais erra
Cache de chave-valor por token = 2 × camadas × cabeças_kv × dimensão_da_cabeça × bytes. Num Llama 3 de 8 B em FP16, isso dá 128 KB por token. Cresce linearmente com o contexto e com o lote — em janelas de 1 milhão de tokens, o cache pode superar o peso do próprio modelo. É a parcela mais esquecida do dimensionamento.
Quanto custa a GPU
| GPU | VRAM | RunPod (US$/h) | Lambda (US$/h) |
|---|---|---|---|
| RTX 4090 | 24 GB | 0,74 | — |
| L40S | 48 GB | 0,99 | — |
| A100 PCIe | 80 GB | 1,39 | 1,99 |
| A100 SXM | 80 GB | 1,59 | 1,99 |
| H100 PCIe | 80 GB | 2,89 | 3,29 |
| H100 SXM | 80 GB | 3,29 | 4,29 |
| H200 | 141 GB | 4,59 | não oferece |
| B200 | 180 GB | 6,79 | — |
| B300 | 288 GB | 7,89 | — |
Preços de tabela oficial, sob demanda, em agosto de 2026. Em instâncias de oito GPUs a Lambda cai para US$ 3,99 por H100 SXM e US$ 2,79 por A100 SXM de 80 GB.
⚠️ Vale uma nota de método: vários comparativos publicados erram esses números. Um agregador conhecido afirmava H100 PCIe a US$ 1,99 na RunPod quando a página oficial diz US$ 2,89 — diferença de 45% numa conta que decide investimento. Confira sempre na fonte antes de dimensionar orçamento.
Custo por hora de GPU na RunPod — agosto de 2026
Preço de tabela sob demanda, em dólares por hora. VRAM entre parênteses.
Máquina ociosa custa o mesmo que máquina em uso — utilização abaixo de ~60% destrói a conta do self-host.
Ferramentas: qual serve para quê
| Ferramenta | Para que serve | Perfil |
|---|---|---|
| Ollama | Rodar modelo local com um comando; catálogo pronto | Desktop, prototipagem |
| LM Studio | Interface gráfica para testar modelos sem terminal | Desktop, exploração |
| llama.cpp | Inferência otimizada em CPU e hardware modesto; quantização GGUF | Edge, máquina sem GPU dedicada |
| vLLM | Servidor de inferência com alto throughput e batching contínuo | Produção |
| SGLang | Servidor com foco em programas estruturados e reuso de prefixo | Produção |
A confusão comum é usar Ollama para atender produção. Ele resolve o “funciona na minha máquina”, mas não foi desenhado para concorrência alta — para isso existem vLLM e SGLang, com batching e gestão de memória pensados para múltiplas requisições simultâneas.
Quando self-host faz sentido
Há três razões que sustentam a decisão, e uma que costuma não sustentar.
- Soberania de dados. Se o dado não pode sair da sua infraestrutura por exigência regulatória ou contratual, a conta de custo é secundária. É o argumento mais sólido.
- Previsibilidade de fornecedor. Modelo baixado não é descontinuado por decisão de terceiro. Em 2026 isso deixou de ser hipótese: o Claude Fable 5 ficou cerca de três semanas indisponível por controle de exportação, e a Sora está sendo encerrada sem substituto.
- Volume alto e constante. Aqui a aritmética pode favorecer, mas depende de utilização real da GPU — máquina ociosa custa igual.
- Economia em volume baixo ou irregular. Normalmente não se sustenta. Modelos como o GPT-5.6 Luna, a US$ 0,20 por milhão de tokens de entrada, tornam difícil competir com API quando o uso é intermitente.
⚠️ Sobre o ponto de equilíbrio: circulam muitos cálculos de “quantos tokens por mês justificam self-host”, quase todos em blogs comerciais sem metodologia publicada — e eles divergem em uma ordem de magnitude. Vi estimativas de “2 a 5 milhões de tokens por dia” e de “6,8 milhões por mês“: um fator de trinta entre elas. Não reconcilio números que não pude verificar.
Dois pontos qualitativos, porém, aparecem de forma consistente e são mais defensáveis que qualquer cifra:
- Contra APIs de modelos abertos baratas — na faixa de US$ 0,14 a 0,50 por milhão de tokens —, o self-host quase nunca ganha em custo puro. O caso real é soberania de dados, latência e conformidade. Para operação brasileira sujeita à LGPD, com dado de cliente em jogo, esse é o argumento que sustenta.
- A GPU é só 30% a 40% do investimento real. O custo total de propriedade costuma sair 2,5 a 3 vezes o valor da máquina, somando rede, armazenamento, monitoramento e engenharia. É a parcela que os cálculos de blog omitem.
A conta que vale é a sua: custo/hora da GPU × horas necessárias, contra preço por token da API no seu volume real — com utilização honesta, não teórica.
Um detalhe que os rankings não mostram
Vale registrar uma regressão do líder atual, porque contraria a leitura de que cada versão é melhor em tudo: a taxa de alucinação do Kimi K3 piorou frente ao K2.6, subindo de 39% para 51%.
Índice composto mais alto com alucinação maior é perfeitamente possível — e é exatamente o tipo de compromisso que se perde quando a decisão se apoia em um número único. Se o seu caso de uso é extração factual ou atendimento, esse dado pesa mais que os 60 pontos do índice.
Como decidir
Uma sequência prática: comece pela licença, que é binária e elimina candidatos rápido. Depois dimensione a VRAM pelos parâmetros totais, somando o cache de contexto. Em seguida escolha a ferramenta pelo destino — vLLM ou SGLang se for produção. Por último, e só então, compare custo com a API no seu volume real.
E teste no seu dado, em português, com as suas tarefas. Os 4 pontos de diferença no índice dizem que o ecossistema aberto ficou competitivo; não dizem que o modelo aberto vai performar melhor no seu caso.
Fontes
- Intelligence Index e comparativo de modelos — Artificial Analysis
- Análise dos lançamentos de pesos abertos — Artificial Analysis
- Catálogo de modelos e licenças — Hugging Face
- Documentação do vLLM
- Documentação do SGLang
- Repositório do llama.cpp
- Biblioteca do Ollama
- Tabela de preços de GPU — RunPod
- Tabela de preços de GPU — Lambda
- Card do DeepSeek V4 Pro — Hugging Face
- Card do gpt-oss-120b — OpenAI no Hugging Face
Leia também
- Modelos de IA em 2026 — panorama com preços e versões atuais
- Benchmark de texto e raciocínio · de código · de agentes
- Kimi · DeepSeek — os modelos abertos de topo
- Hugging Face para empresas — do modelo à produção
- Benchmark de IA — a definição no glossário
