O ecossistema local de LLM não precisa do Ollama

• Ollama foi uma ferramenta inicial que simplificou a execução local de LLMs, mas depois perdeu a confiança da comunidade por ocultar a origem e migrar para uma abordagem centrada na nuvem
• Ao minimizar o mérito do motor principal, o llama.cpp, e trocar para um backend próprio baseado em ggml, surgiram queda de desempenho e reintrodução de bugs
• A comunidade continuou criticando o projeto por nomes de modelos enganosos, distribuição de apps GUI fechados e uma estrutura ineficiente de Modelfile
• Gargalo no registro de modelos, vulnerabilidades de segurança e uma estrutura de vendor lock-in entram em conflito com a filosofia local-first
• Alternativas open source como llama.cpp, LM Studio e Jan já oferecem mais desempenho e transparência e se consolidaram como centro do ecossistema local de LLMs

---

Problemas do Ollama e alternativas no ecossistema local de LLMs

• Origem do Ollama e seu papel inicial

  • Ollama chamou atenção como o primeiro wrapper de llama.cpp a simplificar a execução local de LLMs
    • Os usuários podiam rodar modelos sem precisar compilar C++ manualmente nem configurar um servidor
  • Depois disso, passou a esconder a origem, induzir usuários ao erro e se afastar da filosofia local-first, migrando para uma estrutura centrada em nuvem e impulsionada por capital de risco
  • Os fundadores são Jeffrey Morgan e Michael Chiang, que anteriormente criaram o Kitematic, uma GUI para Docker que foi adquirida pela Docker Inc.
  • Vindos da Y Combinator (W21), fizeram o lançamento público em 2023 com o slogan “Docker for LLMs”

• Crédito inadequado ao llama.cpp

  • A inferência do Ollama depende inteiramente do llama.cpp de Georgi Gerganov
  • Por mais de um ano, não houve menção ao llama.cpp no README, no site nem no material de marketing, e nem mesmo o aviso da licença MIT foi incluído
  • A issue da comunidade pedindo conformidade de licença (#3185) ficou mais de 400 dias sem resposta
  • Depois, um dos cofundadores adicionou apenas uma linha no fim do README: “llama.cpp project founded by Georgi Gerganov”
  • O Ollama afirmou que “estamos fazendo muitos patches e vamos migrar gradualmente para nosso próprio motor”, reduzindo deliberadamente o crédito dado ao projeto original

Migração para backend próprio e queda de desempenho

• Introdução de um backend customizado baseado em ggml

  • Em meados de 2025, o Ollama trocou o llama.cpp por uma implementação própria baseada em ggml
  • A justificativa foi estabilidade, mas o resultado foi a reintrodução de bugs já resolvidos
  • Surgiram vários problemas, como erros em saída estruturada, falhas em modelos de visão e crashes por assertion do GGML
  • Modelos recentes como GPT-OSS 20B não funcionavam ou esbarravam em tipos de tensor não suportados
  • O próprio Gerganov apontou diretamente que o Ollama fez um fork incorreto do ggml

• Resultados de comparação de desempenho

  • Em benchmarks da comunidade, o llama.cpp foi 1,8x mais rápido que o Ollama (161 vs 89 tokens/s)
  • No CPU também houve diferença de 30~50% em desempenho
  • No teste com Qwen-3 Coder 32B, o llama.cpp teve throughput 70% maior
  • As causas apontadas são a arquitetura em daemon do Ollama, offloading ineficiente para GPU e backend desatualizado

Nomes de modelos enganosos

• Caso DeepSeek-R1

  • O Ollama rotulou modelos reduzidos como DeepSeek-R1-Distill-Qwen-32B simplesmente como “DeepSeek-R1”
  • Apesar de não serem o modelo real de 671B parâmetros, usou o mesmo nome
  • Usuários passaram a acreditar que haviam “rodado o DeepSeek-R1 localmente”, o que prejudicou a reputação da DeepSeek
  • As issues relacionadas no GitHub (#8557, #8698) foram tratadas como duplicadas e continuaram sem solução
  • Ainda hoje, ollama run deepseek-r1 executa um modelo reduzido

Lançamento de app fechado

• Distribuição não pública do app GUI

  • Em julho de 2025, foi lançado o app GUI do Ollama para macOS e Windows
  • O desenvolvimento ocorreu em um repositório privado, e o app foi distribuído sem licença e com o código-fonte fechado
  • Para um projeto que mantinha imagem de open source, isso representou uma guinada abrupta para o fechado
  • A comunidade levantou preocupações sobre possível dependência de AGPL-3.0 e risco de violação de licença
  • O site colocava o botão de download ao lado do link do GitHub, passando a impressão de que também era open source
  • Após meses de silêncio, só em novembro de 2025 o código foi incorporado ao repositório principal
  • A XDA criticou dizendo que “projetos que se apresentam como open source devem deixar claro o que é público e o que não é”

Ineficiência do Modelfile

• Sobreposição com o formato GGUF

  • O formato GGUF já inclui em um único arquivo todas as informações necessárias para executar um modelo
  • O Ollama adiciona a isso um arquivo de configuração separado chamado Modelfile, com estrutura parecida com Dockerfile
  • Ele redefine informações que já estão no GGUF, criando complexidade desnecessária
  • O Ollama reconhece automaticamente apenas uma lista hardcoded de templates, ignorando novos templates
  • Como resultado, o formato de instruções do modelo quebra, e o usuário precisa converter manualmente

• Alteração ineficiente de parâmetros

  • Para mudar parâmetros, é preciso extrair com ollama show --modelfile, editar e recriar com ollama create
  • Nesse processo ocorre a cópia completa de modelos de 30~60GB
  • A comunidade criticou isso como “ineficiente e duplicação desnecessária”
  • No llama.cpp, os parâmetros podem ser ajustados simplesmente por argumentos de linha de comando

• Problemas de compatibilidade de templates

  • O Ollama usa sintaxe de template Go, que não coincide com os templates Jinja usados por criadores de modelos
  • LM Studio e llama.cpp suportam Jinja diretamente, mas no Ollama é necessária conversão
  • Foram relatados muitos problemas de quebra no formato de conversa causados por erros nessa conversão

Gargalo no registro de modelos

• Atraso no registro de modelos

  • Mesmo quando um novo modelo é publicado no Hugging Face, no Ollama ele só pode ser usado depois de ser empacotado e registrado manualmente
  • Os formatos de quantização suportados também são limitados, como Q4_K_M e Q8_0
  • Como consequência, há atraso entre o lançamento do modelo e seu uso no Ollama
  • Na comunidade, se espalharam posts em tom de PSA dizendo para “testar novos modelos com llama.cpp ou vLLM”

• Limitações de quantização

  • O Ollama não suporta linhas Q5, Q6 e IQ
  • Mesmo quando usuários pedem suporte, a resposta é “use outra ferramenta”
  • Passou a ser possível chamar diretamente modelos do Hugging Face com ollama run hf.co/{repo}:{quant}, mas eles ainda são copiados para um armazenamento interno com hash, sem compartilhamento, e os problemas de template continuam

Migração para nuvem e problemas de segurança

• Introdução de modelos em nuvem

  • No fim de 2025, o Ollama adicionou modelos hospedados em nuvem
  • Mesmo sendo uma ferramenta focada em uso local, alguns modelos passaram a enviar prompts para servidores externos
  • Ao usar modelos de terceiros como MiniMax, os dados podem ser enviados para fora
  • O Ollama declarou que “não armazena logs”, mas as políticas dos terceiros permanecem pouco claras
  • No caso de modelos baseados na Alibaba Cloud, não há garantia de retenção de dados

• Vulnerabilidades de segurança

  • CVE-2025-51471: vulnerabilidade que permite a um servidor de registro malicioso roubar tokens de autenticação
  • Havia um PR de correção, mas ele não foi incorporado por meses
  • Para uma ferramenta que se apresenta com privacidade local como valor central, isso representa um grave problema estrutural

Estrutura centrada em capital de risco

• Um padrão recorrente

  • Um projeto open source é encapsulado para ganhar base de usuários → captar investimento → migrar para monetização
  • Etapas do Ollama
    • começou como open source, construído sobre o llama.cpp
    • reduziu a visibilidade da origem e se apresentou como produto independente
    • passou a induzir lock-in por meio do registro e do formato de modelos
    • lançou uma GUI fechada
    • avançou para a monetização com a introdução de serviços em nuvem

• Estrutura de vendor lock-in

  • O Ollama armazena modelos com nomes de arquivo em hash, dificultando a compatibilidade com outras ferramentas
  • É possível importar GGUF, mas exportar foi desenhado de forma inconveniente
  • A estrutura faz com que o usuário fique preso ao ecossistema do Ollama

Ferramentas alternativas

• llama.cpp

  • Oferece servidor de API compatível com OpenAI (llama-server), web UI, controle fino de parâmetros e alto throughput
  • Em fevereiro de 2026, a ggml.ai se juntou ao Hugging Face, garantindo sustentabilidade contínua
  • Baseado na licença MIT, com participação de mais de 450 contribuidores

• Outras alternativas

  • llama-swap: suporta carregamento de múltiplos modelos e hot swap
  • LiteLLM: oferece proxy compatível com OpenAI entre vários backends
  • LM Studio: baseado em GUI, usa llama.cpp e tem compatibilidade total com GGUF
  • Jan, Msty: apps desktop open source com design local-first
  • koboldcpp, Red Hat ramalama: execução de modelos baseada em contêiner, com atribuição de origem clara

Conclusão: o rumo do ecossistema local de LLM

• O llama.cpp de Georgi Gerganov é a base da inovação em IA local
  • Graças à colaboração da comunidade, tornou-se possível rodar modelos poderosos até em hardware de consumo
• O Ollama cresceu sobre essa base, mas perdeu a confiança por causa de ocultação de origem, queda de qualidade, fechamento do projeto e migração para a nuvem
• O que o ecossistema local de LLM realmente precisa não é do Ollama, e sim do llama.cpp
  • A verdadeira abertura e o desempenho já estão sendo oferecidos por ferramentas centradas na comunidade

[shblue21]

Concordo até certo ponto, e para usar direito em ambiente local, o LM Studio parece ser uma opção melhor.

[kirinonakar]

Eu também comecei com o Ollama no início, mas já faz tempo que troquei para o LM Studio.

[GN⁺]

Comentários do Hacker News

• A maioria dos usuários de LLM local acha que o Ollama resolveu os problemas de UX
  Dá para rodar modelos com um comando de uma linha, e os drivers ROCm também são tratados automaticamente
  Já o llama.cpp começa pelo nome, que soa como uma biblioteca em C++, então é difícil para o usuário comum se aproximar
  Eu simplesmente não quero compilar programa nenhum; só quero brincar com isso

  • Agora o llama.cpp inclui GUI por padrão. Antes não tinha, mas os tempos mudaram
  • Há muitas alternativas, como “LM Studio, Jan, Msty, koboldcpp...”, mas fico curioso sobre qual seria o sucessor capaz de substituir o Ollama
    Uso um Mac Mini, mas uma ferramenta de CLI também serve. O ponto forte do Ollama era a facilidade de instalação e de baixar modelos, então espero um nível parecido de conveniência nas alternativas
  • Sugerem kobold.cpp ou LM Studio. O LM Studio não é open source, mas dá o crédito devido ao llama.cpp
    Acho importante haver controle de qualidade, para evitar que o suporte a modelos seja integrado quebrado ou que GGUFs errados sejam enviados
  • Concordo. É uma situação parecida com a do Docker
    Claro, você pode usar runc diretamente, mas a maioria escolhe docker run
    UX é um fator central na adoção de tecnologia, e se um projeto não consegue criar uma boa interface, não há nada de errado em fazer um wrapper
  • O fato de o Ollama ter resolvido problemas de UX não absolve uma violação de licença

• Cansaram de repetir o mesmo argumento, então reuniram de uma vez a linha do tempo e as fontes que conhecem

  • Agradecem por terem escrito esse texto. Eu também participei um pouco do llama.cpp, e o comportamento dos fundadores do Ollama foi realmente decepcionante
    Como alternativa, recomendam o llama-file. O llamafile da Mozilla AI funciona como um executável único em qualquer sistema operacional e é totalmente open source
    É baseado em CosmopolitanC, criado pela Justine Tunney, e usa o llama.cpp oficialmente
  • Para quem valoriza o espírito FOSS, foi um texto muito instrutivo
  • Disseram que havia muitos fatos que não conheciam
  • Avaliaram que o resumo e a linha do tempo ficaram excelentes

• Acham que o Ollama é 1000 vezes melhor em facilidade de uso
  O llama.cpp é excelente, mas não é amigável para o usuário comum
  Comecei com Ollama, mas migrei para o llama.cpp por causa das correções mais recentes
  Mesmo assim, ainda uso o Ollama para gerenciar modelos. É tão conveniente que eu mesmo escrevi scripts para gerenciar o diretório de cache

  • No post do blog disseram que as alternativas são intuitivas, mas na prática não são
    Para um app simples de chat talvez, mas quando você precisa de API compatível com OpenAI e gerenciamento de modelos, a acessibilidade cai muito
  • O context size padrão do Ollama era pequeno demais, então muita gente reclamava que os modelos ficavam burros
    Para mudar isso de forma persistente, era preciso criar um novo arquivo de modelo, o que era ainda mais complicado
    A abordagem estilo Docker acaba sendo mais incômoda para usuários comuns, e acho que para usuários avançados o llama.cpp é melhor
  • Como referência, agora o llama.cpp tem modo router, então dá para trocar modelos em tempo real
  • As versões recentes ficaram muito mais poderosas. Dá para conferir em llama.cpp tools/serv
  • Uso o LM Studio há 3 anos, e mesmo naquela época ele já era muito melhor que o Ollama

• Organizam duas visões sobre a licença MIT

  1. “Se der uma linha de crédito, pode fazer qualquer coisa”
  2. “Juridicamente é livre, mas existe uma responsabilidade moral com a comunidade”
     O criador do llama.cpp, Georgi Gerganov, só demonstrou insatisfação pela falta de crédito. Ou seja, na prática ele age mais próximo da primeira interpretação
  • Acham que a segunda interpretação não faz sentido. Se você quer obrigações de GPL, então use GPL
    MIT é um documento jurídico, não uma diretriz moral
    Pessoalmente, acham melhor usar GPL para software voltado ao usuário
    Reclamar que empresas pegaram seu código depois de escolher MIT é contraditório
    Empresas não têm moral, só pessoas têm
  • Se o Georgi quisesse, poderia ter mudado para GPL a qualquer momento. Mas não fez isso
    No fim, os dois projetos continuaram evoluindo, e os usuários ganharam mais opções

• Antes era inconveniente porque não dava para mudar a pasta padrão dos modelos
  Para registrar um modelo, era preciso seguir um processo parecido com um Dockerfile, e o modelo era copiado para um armazenamento por hash sem possibilidade de mudar de lugar
  Por isso migraram para o LM Studio. Não é totalmente open source, mas expunha a pasta de modelos e se integrava ao Hugging Face

  • Agora isso é possível. Dá para definir o caminho com a variável de ambiente OLLAMA_MODELS no arquivo de configuração do servidor
  • Também sofri com esse problema. Queria comparar com o LM Studio antes e depois de um upgrade de SSD, mas o processo de encontrar e organizar a localização dos modelos foi complicado e desnecessariamente doloroso demais

• Por causa da estrutura em que o Ollama copia os arquivos de modelo para um armazenamento de blobs por hash, não dá para compartilhá-los com outras ferramentas
  Talvez tenha sido projetado para desduplicação, mas na prática isso dificulta testar outras ferramentas
  Como os arquivos de modelo são enormes, espaço de armazenamento e downloads viram um grande peso

• No Arch Linux, pacman -Ss ollama retorna 16 resultados, mas llama.cpp ou lmstudio retornam 0
  Esperam que isso mude algum dia

  • llama.cpp atualiza rápido demais para virar pacote estável, mas dá para instalar pelo AUR
    Há suporte para versões Vulkan, ROCm e CUDA
  • Já no openSUSE, dá para encontrar llamacpp com zypper
    Como a versão e o suporte variam de distro para distro, esse é justamente um dos motivos de existirem tantas distribuições Linux
  • Instalei em CachyOS com yay -S llama.cpp, e foi muito mais rápido e melhor que o Ollama

• O nome “llama.cpp” agora soa pouco amigável
  Antes remetia aos modelos Llama da Meta, mas hoje há modelos open source mais poderosos

  • Mas o “Ollama” sofre do mesmo problema
    Hoje “Local LLaMA” acabou sendo usado como um nome genérico para rodar modelos localmente
  • A lista da Wikipédia de marcas generalizadas mostra que esse fenômeno é comum

• Evitaram o Ollama desde o início porque ele dava a impressão de querer controlar todo o workflow
  No fim, acham que foi a escolha certa

• A estrutura de armazenamento de blobs por hash do Ollama é a maior armadilha
  Se você passou meses baixando modelos, ao migrar para outra ferramenta precisa baixar tudo de novo
  A maioria dos usuários só percebe isso depois de já ter investido bastante e então sente fortemente o custo de saída