Modelos Open-Weight: Preço, Por Que Usá-los e Como Medir o Custo

Por alguns anos o padrão foi simples: escolher o modelo mais forte que o orçamento compra e mandar toda tarefa para ele. Esse hábito está ficando caro, e já não é a única opção que funciona.

A pergunta útil em 2026 é: qual modelo termina esta tarefa, no menor custo que ainda entrega o resultado? Essa pergunta não é "open ou fechado." Não é "qual é o melhor modelo." É o modelo certo para o trabalho na frente de você.

Eu percorri essa mudança num briefing do Agentic Hour, com um agente construindo um produto pequeno enquanto a gente conversava. Os exemplos daqui são modelos open-weight, porque é aí que a queda de preço aparece mais, e porque o hábito de sempre pegar a opção maior existe lá também. A regra é a mesma se o candidato é Claude, GPT, Gemini, Kimi ou DeepSeek.

A pergunta mudou duas vezes

Em 2023 a pergunta era "qual modelo é o melhor?" Um modelo frontier para chat, código e o resto.

Em 2024 e 2025 passou a ser "qual agente é o melhor?" O harness e o fornecedor eram a mesma coisa. Você comprava Claude Code, Codex, ou o que viesse amarrado à API que já pagava.

Agora a pergunta que importa é "qual modelo para este passo?" Trabalho fácil pode ir para um modelo menor. Trabalho médio, para um modelo de código de faixa intermediária. Arquitetura, debug difícil e a primeira quebra de um problema bagunçado ainda pedem um modelo mais forte. Mandar o mix inteiro para a opção maior, proprietária ou open, é o jeito de gastar 60 a 80 por cento do orçamento de IA em edição rotineira.

A Forbes relatou que a Uber esgotou o orçamento de IA de 2026 em quatro meses depois de colocar Claude Code, sem roteamento, na frente de cerca de 5.000 engenheiros. É isso que "usar o melhor modelo" vira em escala de empresa.

Open não é grátis, e open-weight não é local

"Modelo open-source" vira sinônimo de "modelo grátis que roda no notebook." As duas partes estão erradas para os modelos que importam em produção.

Pesos abertos (open weights) significam que você consegue os pesos. Inferência ainda se paga. Um modelo na classe de 3 trilhões de parâmetros não é coisa que você sobe no computador do time, e alugar GPU suficiente para servir isso por conta própria muitas vezes sai mais caro que uma API hospedada.

Na prática há três jeitos de rodar:

1. Inferência hospedada. Paga por token em Groq, Together, DeepInfra, OpenRouter, MixLayer, no gateway do OpenCode e provedores parecidos.
2. Inferência dedicada. Instâncias de GPU próprias quando você precisa de throughput garantido ou de residência dos dados.
3. Execução local. Ollama ou vLLM na workstation, para modelos menores e casos em que nada pode sair da máquina.

O argumento a favor de open-weight não é "open é de graça." É open igual a competição e opção. Você troca de provedor sem reescrever o produto. Compara preço, latência e privacidade. Mantém código e documentos fora de uma API fechada quando isso é restrição de verdade.

Existe faixa gratuita, e serve para um teste rápido. Trate como trial, não como produção. Esses endpoints costumam reservar o direito de treinar com os prompts que você envia. Se o trabalho é um app proprietário, pague um plano que não faça isso.

Por que open-weight entra no mix agora

Você ainda escolhe o modelo que consegue terminar a tarefa. Open-weight entra nessa lista agora porque a capacidade chegou a um ponto em que a história de lock-in ficou mais fraca.

O relatório do DeepSeek V3 colocou o treinamento final em US$ 5,576 milhões e 2,788 milhões de GPU-hours de H800. Esse número não inclui a pesquisa anterior, então não é o orçamento inteiro do laboratório. Ainda assim, em 27 de janeiro de 2025, a Reuters relatou uma queda de 17% na Nvidia e cerca de US$ 593 bilhões de valor de mercado evaporados num dia. O mercado assumia que só gasto bruto produzia qualidade frontier.

Em 2026 o campo open-weight não é um azarão só. Qwen3-Coder é feito para trabalho em repositório com vários arquivos. DeepSeek seguiu empurrando Mixture-of-Experts e preço baixo de inferência. GLM tem sido competitivo em tarefas agênticas de terminal. Kimi K3 é um modelo na classe 3T, com contexto de 1 milhão de tokens e visão, e os próprios benchmarks da Moonshot colocam ele ao lado de modelos proprietários frontier em vários testes de código e de agente. Benchmark de fornecedor é benchmark de fornecedor. Serve para você testar o modelo, não para confiar de olhos fechados.

Do lado das empresas, o padrão é o mesmo: tirar volume rotineiro da API frontier.

• Werner Vogels, CTO da Amazon, tem dito que times estão mandando trabalho rotineiro para modelos open-weight mais baratos e escolhendo modelo por tarefa.
• A Axios relatou que a Lindy migrou para DeepSeek V4 e afirmou milhões em economia, com resultado melhor no trabalho principal.
• A Harvey relatou uma queda de 3× no custo de inferência, sem perda de qualidade no teste, misturando Opus com GLM 5.1.
• Um case da distil labs diz que a Knowunity cortou 68% do custo de inferência em tarefas selecionadas com um fine-tune especializado de Qwen.

São afirmações atribuídas, não garantia para a sua carga. Já é o bastante para colocar modelo open-weight na mesma mesa que os proprietários, e ainda assim escolher por tarefa.

Custo por token é o número errado

Um modelo a US$ 0,20 por milhão de tokens que precisa de sete tentativas, 45 milhões de tokens e doze minutos de um engenheiro limpando o resultado não é barato. Um modelo a US$ 3,00 por milhão que termina numa tacada, com 8 milhões de tokens e sem correção, muitas vezes sai mais em conta.

O número que importa para agentes é custo por tarefa concluída, ou custo por pull request aceito. Preço de token é um insumo. Retry, cache, retrabalho humano e se o modelo segue o spec fecham a conta.

A Cursor publicou um exemplo útil. Reconstruiu o SQLite a partir de um manual de 835 páginas, em Rust, com mixes diferentes de modelo de planejamento e modelo executor. Os dois setups que eles destacam passaram 100% de um conjunto separado de testes. A faixa de custo publicada foi de US$ 1.339 a US$ 10.565, cerca de 7,9× de diferença para o mesmo resultado. Os modelos executores comeram mais de 90% dos tokens. No mix mais barato, entrou mais dinheiro em planejamento do que em execução, e esse é o ponto: planejamento é onde o modelo mais forte paga o preço. Quase qualquer modelo decente segue um bom plano. Plano fraco fica caro independente de quem executa.

Se você só olha a tabela de preço, escolhe o de US$ 0,20. Se olha o trabalho pronto, escolhe um mix.

Um teste em um único prompt

No briefing eu subi um agente no OpenCode com um spec e deixei rodando. O mesmo spec para os dois modelos. Sem prompt de correção. Uma tacada.

Uma calibração anterior desse spec:

O Flash usou cerca do dobro de tokens e ainda assim custou perto de oito vezes menos.

Os dois runs construíram o mesmo projeto. Em seguir as instruções, respeitar o spec e entregar o output certo, os dois empataram. O Kimi ficou um pouco melhor em UI e UX. Esse acabamento não justifica ser quase oito vezes mais caro que o DeepSeek.

US$ 3,70 e US$ 0,47 não são custo de um produto de IA em produção. São o custo de construir um app pequeno, incluindo testes e os retries do próprio agente. O app em si não chama modelo.

É isso que eu quero deixar claro. Você não precisa do maior modelo para terminar a tarefa. O teste usou dois modelos open-weight, um grande e um menor e mais barato, porque essa diferença de tamanho existe dentro do open-weight também, não só entre uma API frontier fechada e o resto. Os dois seguiram o spec. O dinheiro a mais comprou layout, não um produto diferente.

Mantenha o harness. Troque o modelo.

Se o produto de agente e o fornecedor do modelo são o mesmo contrato, você não roteia. Paga o preço deles, bate no limite deles e reconstrói se sair.

Um harness independente de modelo (OpenCode é um exemplo; Codex, Grok e outros podem ficar ao lado) é o que torna o roteamento uma opção de verdade. O mesmo AGENTS.md, as mesmas skills, as mesmas permissões. Modelo diferente por papel:

• Explorar: modelo barato e rápido para grep, listar arquivo e juntar contexto.
• Implementar: modelo de código para edição, teste e refatoração.
• Planejar e revisar: modelo mais forte de raciocínio para arquitetura e para pegar os casos que o executor vai deixar passar.

O mix da Cursor no SQLite é essa ideia com número publicado. Opus (ou o que você confiar para planejar) pensa. Um executor mais barato faz o volume. Naquele experimento, o mix mais barato ficou cerca de 7,5× abaixo da opção mais cara da mesa.

Self-hosting é decisão de depois. Você ganha controle dos dados e portabilidade. Também assume capacidade de GPU, uptime, segurança, upgrade e SLA. Comece num endpoint open hospedado. Hospede você mesmo quando volume, residência ou resiliência de fato pagarem esse trabalho.

Leaderboard público é filtro inicial, não é a eval. Modelo é treinado para ir bem nessas boards. Rode o mesmo spec, as mesmas ferramentas, o mesmo orçamento de retry e as mesmas regras de revisão numa tarefa que você já faz toda semana. Acompanhe taxa de acerto, tokens, tempo de parede e retrabalho humano juntos.

Quando ainda vale pagar um modelo maior

O maior modelo, open ou proprietário, é o padrão errado quando:

• A tarefa é planejar em cima de um codebase bagunçado, com tradeoffs que o modelo barato não vai notar.
• Uma run que falha custa caro em tempo de gente, então qualidade de uma tacada vale o prêmio de token.
• Você já mediu as suas tarefas e o modelo barato não segue o spec.

A estratégia não é "passar tudo para open-source porque é mais barato," e também não é "usar sempre o melhor modelo." É: casar o modelo com a tarefa. Parar de mandar formatação, busca e boilerplate para a API mais cara que você tem. Deixar o modelo caro no trabalho que de fato usa ele.

Como testar isso sem virar um projeto de pesquisa

Escolha uma tarefa recorrente: uma migration, um endpoint, um refactor que você já fez. Rode no modelo que você já usa, depois num menor, open-weight ou não, no agente que consiga apontar para outro provedor. Kimi K3, DeepSeek V4 Flash e GLM são pontos de partida fáceis no open-weight. Compare custo e o diff de verdade, não a impressão.

Se quiser um começo de baixo atrito, o OpenCode Go é uma assinatura de US$ 10/mês para uma lista de modelos open de código (o primeiro mês estava US$ 5 quando eu conferi). OpenCode Zen é pagar por uso. Trazer a sua própria chave é o máximo de controle. Nada disso é obrigatório. O obrigatório é medir custo por tarefa concluída no seu trabalho.

Para inferência em produção, compare os provedores hospedados. Na sessão, quem já tinha tirado chat de produção da OpenAI e colocado na MixLayer relatou cerca de 10× de queda, usando Kimi e GLM, com qualidade suficiente e às vezes melhor depois de ajustar prompt com o fornecedor. É número de um time. Faça a mesma comparação no seu tráfego antes de comprometer.

A versão curta

Escolha o modelo que termina a tarefa. Modelos open-weight entram nesse mix agora, e são baratos o bastante para que o padrão de sempre pegar a opção maior, proprietária ou open, vire desperdício. O teste em uma tacada é a versão curta disso: DeepSeek e Kimi construíram o mesmo projeto a partir do mesmo spec, os dois seguiram as instruções, e o layout um pouco melhor do Kimi não pagou uma conta 8× maior. Não escolha um modelo porque o preço do token parece pequeno, e não escolha o maior modelo só porque parece mais seguro. Meça o trabalho que termina. Mantenha o harness independente do fornecedor. Pague por privacidade. Deixe um modelo mais forte no loop para planejar e para os casos em que o modelo barato falha o spec.

É também o jeito de escopar trabalho de IA na A1 Lab. Um protótipo em tarefas reais diz qual modelo, qual harness e qual conta mensal de token você está comprando de verdade. As faixas de custo de infra e tokens continuam valendo. Escolha de modelo é a alavanca que mais mexe no número mensal, uma vez que o sistema existe.

Se quiser ajuda para rodar essa comparação num processo real, descreva a tarefa e o volume. Isso já dá para começar.

Veja também:

• Quanto custa implementar IA
• Agentes de IA ou automação
• Por que fazer um protótipo antes do projeto completo
• Agentes de IA