LLMs open source frente a modelos de pago: qué elegir

A pergunta já não é se um modelo aberto pode competir com um proprietário, mas em que tarefas concretas o faz e a que custo real. Durante 2025, muitas equipes migraram parte do seu stack de IA para pesos baixáveis e descobriram duas coisas: que a economia na API nem sempre compensa o custo de infraestrutura, e que a licença importa mais do que parece quando o produto entra em produção.

Aqui não encontrará um ranking plano. Encontrará quais famílias de modelos abertos estão a dar resultados defensáveis, onde ficam aquém face aos de pagamento e como decidir com critérios que sobrevivam ao próximo lançamento.

O mapa real: o que significa «open source» em modelos de linguagem

Antes de comparar convém desmontar uma ambiguidade que gera decisões erradas. Quase nenhum modelo chamado aberto cumpre a definição estrita da OSI. O habitual é encontrar pesos baixáveis com licenças de uso comunitário que impõem restrições: limites de utilizadores mensais, proibição de uso competitivo, obrigação de mostrar o nome do modelo na interface ou cláusulas de escalonamento comercial.

Isto tem uma consequência prática: um modelo pode ser gratuito para prototipar e caro —legalmente— ao crescer. A família Llama é o exemplo clássico de licença com limiar de utilizadores; Qwen e DeepSeek publicam boa parte dos seus pesos sob Apache 2.0, o que facilita a integração comercial sem fricção legal; Mistral combina licenças Apache nos seus modelos pequenos com licenças de investigação nos grandes. Antes de escolher por benchmarks, reveja a licença do modelo concreto que vai implementar, não a do repositório em geral.

Modelos abertos que merecem um teste em 2025

Llama (Meta) continua a ser o padrão de facto do ecossistema. A sua vantagem não é o desempenho bruto, mas a maturidade do tooling: quantizações prontas, suporte em Ollama, vLLM e llama.cpp, e uma comunidade que resolve dúvidas rapidamente. A variante de 8B é um cavalo de batalha para classificação, extração e resumos; os tamanhos maiores competem em raciocínio, mas exigem hardware que raramente está no computador de um programador.

Qwen tem ganho terreno em tarefas multilingues e de código. As suas versões pequenas surpreendem na geração de SQL e na compreensão de instruções com formato estrito, e a licença Apache em muitos dos seus pesos elimina o debate legal. Em testes de extração de dados estruturados a partir de texto desorganizado, um modelo Qwen de tamanho médio costuma bastar onde um modelo proprietário grande seria sobredimensionado.

DeepSeek demonstrou que um laboratório com menos recursos pode publicar modelos competitivos em raciocínio matemático e código. A contrapartida é a opacidade sobre os dados de treino e a necessidade de validar enviesamentos em domínios regulados.

Mistral mantém uma proposta europeia com bons resultados em tarefas de instrução e uma comunidade ativa em torno dos seus formatos de quantização.

Gemma (Google) oferece pesos abertos com uma abordagem conservadora em segurança, útil quando precisa de um modelo que não gere conteúdo problemático por defeito, embora a sua licença também tenha condições de uso.

Onde o modelo aberto ganha sem discussão

Há cenários onde a comparação nem sequer faz sentido porque o proprietário não pode oferecer o que precisa.

Dados que não podem sair da sua infraestrutura

Se processa históricos clínicos, processos legais ou dados pessoais sob regulamentação estrita, enviar prompts para uma API externa exige uma análise de riscos que muitas equipes jurídicas não aprovam. Um modelo aberto executado localmente elimina a transferência de dados. Não elimina a responsabilidade: continua a precisar de registar que modelo usou, com que versão e que prompts, porque a rastreabilidade também é uma obrigação.

Volume alto e previsível

Quando a sua carga é constante e o modelo cabe numa GPU que já tem, o custo marginal por token tende para zero. Um caso típico: classificar milhares de tickets diários em categorias fixas. Um modelo de 7-8B quantizado a 4 bits corre numa GPU de consumo e faz essa tarefa com uma precisão que, após um ajuste fino ligeiro com exemplos próprios, iguala modelos proprietários muito maiores nesse domínio restrito. A chave é que a tarefa seja delimitada; se precisa de raciocínio aberto, o cálculo muda.

Latência controlada e sem dependência de terceiros

Para aplicações interativas onde 300 ms a mais arruínam a experiência, ou para produtos que não podem permitir-se uma queda do fornecedor, a implementação própria dá controlo. Também dá a obrigação de a monitorizar, algo que muitas equipes subestimam.

Onde o modelo de pagamento continua a ser a opção sensata

A honestidade obriga a dizê-lo: em raciocínio complexo de vários passos, no seguimento de instruções longas e em tarefas que requerem contexto de centenas de milhares de tokens, os modelos proprietários de fronteira mantêm vantagem. Um modelo aberto de tamanho médio pode escrever uma função correta; pedir-lhe que raciocine sobre um repositório inteiro e proponha uma refatoração coerente costuma produzir resultados frágeis.

Há também um fator que raramente aparece nas comparações: o custo de manutenção. Escolher um modelo aberto implica versionar pesos, gerir atualizações, montar avaliação contínua e assumir que um dia a comunidade deixa de manter a quantização que usa. Esse trabalho tem um preço em horas de engenharia que, em equipes pequenas, supera a despesa em API durante meses.

Um erro comum que tenho visto repetir-se

Equipes que migram para um modelo aberto porque num benchmark público obtém boa pontuação e depois descobrem que o seu caso de uso concreto —por exemplo, extrair campos de faturas digitalizadas com modelos heterogéneos— falha sistematicamente. O benchmark media raciocínio geral, não a capacidade de respeitar um esquema JSON com campos aninhados e valores nulos. A lição: monte um conjunto de avaliação com 50-100 exemplos reais do seu domínio antes de decidir. Se o modelo aberto não superar esse teste, a economia é fictícia.

Como comparar sem cair no ruído dos rankings

Os leaderboards mudam todas as semanas e misturam tarefas que não se parecem. Uma abordagem mais útil é construir a sua própria matriz de decisão com quatro eixos:

• Licença e conformidade: permite uso comercial sem limiares? exige atribuição? o que acontece se ultrapassar determinado volume?
• Encaixe no hardware: cabe na sua GPU com a quantização que precisa? que throughput real obtém com vLLM ou llama.cpp?
• Qualidade no seu domínio: resultados no seu set de avaliação, não no MMLU.
• Custo total: API face a infraestrutura mais horas de manutenção.

Um detalhe técnico que marca diferenças e que se passa por alto: a quantização degrada umas tarefas mais do que outras. A geração criativa aguenta bem 4 bits; o raciocínio matemático e a extração precisa de dados sofrem mais. Testar a mesma tarefa com o modelo em fp16 e em quantizado dir-lhe-á se a economia de VRAM justifica a perda.

Estratégia híbrida: o que funciona na prática

A dicotomia gratuito contra pagamento é enganadora. A arquitetura que mais rendimento dá em projetos reais combina ambos: um modelo aberto pequeno para o grosso do tráfego (classificação, filtragem, resumos curtos, respostas de FAQ) e um modelo proprietário como apoio para as consultas que o pequeno deriva por baixa confiança. Este padrão reduz custo sem sacrificar qualidade nos casos difíceis, e é mais fácil de justificar perante o negócio do que uma migração total.

Convém também recordar que «gratuito» não existe em inferência: alguém paga a eletricidade, a GPU e o tempo de quem mantém a implementação. A pergunta correta não é qual é gratuito, mas qual tem um custo total menor para o seu volume e a sua equipe.

O que vigiar nos próximos meses

O ritmo de publicação de pesos abertos não abranda, e a diferença face aos modelos de fronteira fecha-se em algumas tarefas enquanto se mantém noutras. Duas frentes merecem atenção: as licenças, que tendem a endurecer quando o modelo se torna popular, e as ferramentas de avaliação, que continuam a ser o elo fraco. Um modelo sem um bom sistema de avaliação próprio é uma caixa negra com boa imprensa.

Se tivesse de resumir o critério: teste modelos abertos primeiro em tarefas delimitadas e mensuráveis, reserve os proprietários para o que exige raciocínio amplo, e não tome nenhuma decisão sem um set de avaliação construído com os seus próprios dados. Essa é a única comparação que não caduca no mês seguinte.