LLMs open source: mitos e realidades na empresa

O ruído em torno dos modelos abertos

Quando uma equipe diretiva pergunta pela primeira vez sobre LLMs open source, a conversa costuma começar com uma promessa grande e uma dúvida ainda maior. Os mitos circulam mais rápido que a documentação técnica. E as decisões são tomadas, em muitos casos, com informação de segunda mão. Este artigo não pretende vender a adoção de modelos abertos, mas separar o que pode ser comprovado do que se repete sem evidência.

Mito 1: «O open source é grátis»

O peso do modelo é baixável sem custo. Isso é verdade. O que não é grátis é tudo o que é necessário para que esse peso funcione de forma estável em produção. Os custos reais aparecem em quatro frentes:

• Infraestrutura: uma GPU com memória suficiente para servir um modelo de 70B com contexto longo não é um portátil. O aluguel por horas ou a compra do hardware têm um custo que se repete todos os meses.
• Engenharia: alguém tem de montar o servidor de inferência, ajustar o batching, monitorizar latências e gerir versões do modelo.
• Avaliação: cada atualização do modelo ou do prompt exige voltar a medir a qualidade. Sem um banco de testes próprio, navega-se às cegas.
• Manutenção: os repositórios de pesos e as bibliotecas de inferência evoluem rapidamente. O que funcionava há seis meses pode exigir ajustes hoje.

Na prática, o custo por token de um modelo aberto servido em infraestrutura própria pode ser competitivo ou até inferior ao de uma API fechada, mas apenas a partir de um certo volume sustentado. Abaixo desse limiar, a API costuma ganhar em custo total. Segundo documentação de fornecedores de infraestrutura cloud, a utilização média das GPUs dedicadas à inferência em empresas pequenas raramente supera os 30 %, o que encarece cada token servido.

O erro de contar apenas o preço do token

Um padrão que se repete em equipes que dão o salto: comparam o preço por milhão de tokens da API com o preço por hora da GPU e concluem que o modelo aberto é mais barato. Esquecem o custo de oportunidade da equipe de plataforma, as horas de integração e o tempo dedicado a resolver incidentes. Um cálculo honesto inclui essas horas, ainda que de forma aproximada.

Mito 2: «Se é aberto, os meus dados estão seguros por defeito»

Executar o modelo na tua própria infraestrutura elimina a saída de dados para um terceiro, mas não torna o sistema seguro por artes mágicas. A segurança depende de como se implementa, não apenas de onde se executa. Os pontos que costumam ficar fora da conversa inicial:

• Os registos de prompts e respostas. Se forem armazenados sem controlo, o dado sensível continua exposto, ainda que o modelo seja local.
• O acesso ao endpoint de inferência. Sem autenticação e limites de uso, qualquer pessoa dentro da rede pode consultar o modelo com as permissões do serviço.
• A cadeia de fornecimento do modelo. Os pesos descarregados de um repositório público devem ser verificados; um ficheiro corrompido ou manipulado é um vetor real.
• A filtragem de conteúdo. Um modelo aberto não traz por defeito as camadas de moderação que um fornecedor gerido aplica na sua API.

A vantagem de privacidade existe, mas é uma condição necessária, não suficiente. Requer o mesmo trabalho de governação de dados que qualquer outro sistema interno.

Mito 3: «Têm um desempenho pior que os modelos fechados»

Aqui o matiz importa muito, e generalizar é o erro. Em tarefas de raciocínio complexo, matemática e código, os modelos fechados de primeira linha mantiveram durante boa parte de 2025 e início de 2026 uma vantagem em benchmarks públicos. Mas em tarefas delimitadas —classificação de tickets, extração de campos de um documento, resumo de conversas com formato fixo, geração de respostas a partir de um contexto recuperado— os modelos abertos de tamanho médio igualam ou superam modelos fechados pequenos, com a vantagem de que podes ajustá-los com os teus próprios dados.

Um caso concreto que ilustra bem a diferença: uma empresa de seguros que processa partes de sinistros em PDF. Um modelo fechado generalista cometia erros ao extrair montantes quando o documento misturava tabelas e texto livre. Após fazer fine-tuning de um modelo aberto de 8B com 2.000 exemplos anotados internamente, a precisão nesse formato específico subiu de forma notável e o custo por documento reduziu-se. Não porque o modelo aberto fosse melhor em geral, mas porque estava especializado na distribuição exata dos seus documentos. Esse é o terreno onde os modelos abertos brilham.

Onde não chegam (e convém reconhecê-lo)

Um modelo aberto de 7B ou 8B não vai resolver consultas que exijam raciocínio multi-passo sobre contextos de 200.000 tokens com a mesma solidez que um modelo fechado de gama alta. Também não é a opção natural para tarefas criativas de longo alcance onde a coerência estilística é crítica. Se o teu caso de uso depende disso, o modelo aberto não é a resposta, e forçá-lo gera frustração na equipe e desconfiança na tecnologia.

Mito 4: «Basta descarregar o modelo e pronto»

A distância entre descarregar pesos e ter um serviço em produção é a parte que menos se documenta nos artigos introdutórios. Os passos intermédios incluem:

• Escolher uma biblioteca de inferência adequada ao hardware disponível.
• Definir o esquema de prompting e versioná-lo junto ao código.
• Montar uma camada de recuperação (RAG) se o modelo necessitar de conhecimento atualizado da empresa.
• Estabelecer métricas de qualidade e um conjunto de avaliação representativo.
• Configurar limites de uso, filas e degradação controlada perante picos de procura.

Segundo documentação oficial das principais bibliotecas de serving, o desempenho por GPU varia muito consoante a técnica de quantização e o tamanho do lote. Um mesmo modelo pode passar de servir 10 pedidos por segundo a 40 conforme a configuração. Essa diferença não aparece na ficha do modelo; aparece ao medir.

Mito 5: «O open source garante independência total do fornecedor»

Substituir a dependência de uma API fechada pela dependência de um fornecedor de GPU, de uma biblioteca de inferência concreta ou de um repositório de pesos único não é independência, é mudar de dependência. A liberdade real chega quando a equipe pode migrar o modelo sem reescrever a aplicação. Isso exige uma camada de abstração no código, um formato de prompts portátil e um banco de testes que permita comparar candidatos com o mesmo critério.

As empresas que fizeram bem este passo costumam ter um catálogo interno de modelos avaliados, não um único modelo. Podem mudar de um para outro conforme o custo, a latência ou a qualidade numa tarefa concreta. O open source possibilita essa flexibilidade; não a garante.

Realidade: quando faz sentido e quando não faz

Depois de ver várias implementações, o padrão de decisão é bastante consistente:

Sinais a favor

• Volume alto e estável de inferência que justifica o investimento em infraestrutura.
• Dados que não podem sair do perímetro por requisitos regulatórios ou contratuais.
• Necessidade de especialização profunda num domínio com dados próprios etiquetados.
• Latência crítica em ambientes onde a rede para um fornecedor externo acrescenta um salto inaceitável.
• Requisito de reprodutibilidade: saber exatamente que versão do modelo respondeu o quê.

Sinais contra

• Equipe sem perfil de plataforma ou MLOps e prazos apertados.
• Casos de uso muito variados que exigem um modelo generalista de máxima qualidade.
• Volumes baixos ou intermitentes onde a API fechada sai mais barata.
• Ausência de dados próprios para especializar: sem fine-tuning nem RAG, o modelo aberto compete em desvantagem.

Um aviso sobre as avaliações

Os benchmarks públicos são uma referência útil, mas não preveem o desempenho no teu caso. Um modelo que lidera uma tabela generalista pode ficar abaixo na tarefa concreta que te importa. A única medida fiável é construir um conjunto de avaliação com exemplos reais do teu negócio, anonimizados se necessário, e comparar candidatos com o mesmo prompt e o mesmo critério de correção. Sem esse banco de testes, qualquer decisão sobre modelos abertos apoia-se em opiniões, não em dados.

E convém recordar uma limitação que não desaparece: nenhum modelo, aberto ou fechado, garante resultados. A qualidade do sistema depende do dado, do design do prompt, da avaliação contínua e do critério humano que revê as saídas nos pontos críticos. O open source acrescenta controlo e opções; não substitui o trabalho.