llama.cpp 100k estrelas: a era dos agentes locais começou

Dois posts no X, na mesma semana, capturam bem onde a IA local chegou em 2026.

O primeiro é do Georgi Gerganov, criador do llama.cpp, comemorando que o projeto bateu 100 mil estrelas no GitHub. Ele aproveita o marco para fazer uma reflexão honesta sobre o estado do movimento de LLMs locais.

O segundo é do Julien Chaumond, CTO da Hugging Face, mostrando o agente Pi rodando Qwen3.6 27B via llama.cpp no MacBook Pro, em modo avião completo, atacando tarefas não triviais nos repositórios da HF — com qualidade que ele descreve como "muito, muito próxima do Opus mais recente no Claude Code".

Não é coincidência. É um sinal.

O marco: 100k estrelas e mais de 1500 contribuidores

llama.cpp não é um projeto novo. Mas chegar a 100k estrelas com 1500+ contribuidores, e fazendo isso da forma que faz — em C/C++, vendor-neutral, rodando em qualquer hardware imaginável — diz muito sobre que tipo de pilha de software a comunidade está apostando.

Como o Georgi escreve:

"A tecnologia é importante demais para ser travada a um fornecedor. Ela tem que ser desenvolvida em aberto, pela comunidade, junto com os fornecedores de hardware independentes."

Esse é o ponto que muita gente perde quando fica polarizada entre "LLM local é o futuro" e "LLM local é brinquedo". A pergunta certa não é se ele é tão bom quanto o GPT-5 hoje. É que tipo de infraestrutura você quer que sustente o software dos próximos 10 anos.

O que mudou em 12 meses

Há um ano, o argumento contra agentes locais era basicamente um: custo de memória e compute.

Os modelos disponíveis eram caros demais para tarefas com contexto longo, ferramentas múltiplas e loops de validação. Não havia um caminho óbvio de "isso roda no meu laptop e faz algo útil".

O próprio Georgi reconhece que não esperava a era agentica chegar tão rápido para o lado local. O que virou o jogo:

gpt-oss mudou o patamar — primeira vez que tool calling local funcionou de verdade dentro das restrições de um dispositivo do dia a dia.
Qwen3.5 e Qwen3.6 representam um salto qualitativo, cobrindo uma boa gama de tamanhos para diferentes máquinas.
GLM-4.7-Flash, MiniMax-M2.5 e variantes Coder ampliaram as opções práticas.

E o Julien fechando isso com Pi + Qwen3.6 27B + llama.cpp no MacBook Pro mostra o resultado prático: agente de código real, em código de produção, sem internet.

Não precisamos de fronteira para a maioria das tarefas

Esse talvez seja o argumento mais importante do Georgi, e o mais ignorado no hype:

não precisamos de inteligência de fronteira para automatizar busca e envio de e-mails
não precisamos de modelos trilhão para resumir documentos
não precisamos de data centers de GPU para apagar a luz da garagem

Existe um nível de inteligência útil que cabe num MacBook. E uma quantidade enorme de problemas reais que cabe nesse nível.

Comparar capacidade local vs. hospedada em um instante específico é o tipo de debate que envelhece mal. O que importa é a trajetória, e a trajetória está clara: a parcela de coisas úteis que dá pra fazer offline está crescendo rápido.

O elo fraco hoje não é o modelo. É o harness.

Outro ponto do Georgi que vale destacar: muito do que parece "modelo local ruim" é, na verdade, harness ruim.

Da tarefa digitada no cliente até o token final, há uma cadeia longa de componentes que ainda é frágil:

parsing de chat templates por modelo
construção de prompts
adaptação de tool calling
montagem de contexto
bugs sutis de inferência

A maioria das pessoas tentando "plugar Qwen3.5 no Claude Code" e ficando frustrada está esbarrando exatamente nessa cadeia. Não no modelo.

A recomendação dele é pragmática:

comece com modelos de qualidade total que caibam no seu hardware
saiba exatamente o que o seu harness faz — escreva o seu próprio, ou use o webui do llama-server (com suporte MCP nativo agora)
só depois de funcionar, parta para otimizações (quantização para velocidade, ajuste de parâmetros)

Esse último ponto se conecta direto com o que escrevi em Agent Harness Engineering na prática: o agente é modelo + harness. Trocar o modelo sem entender o harness raramente resolve.

Modelos que estão entregando hoje

Para quem quiser sair do papel, a lista do próprio Georgi de modelos que ele usa com aplicações reais (chat, MCP, código):

gpt-oss-120b
Qwen3-Coder-30B
GLM-4.7-Flash
MiniMax-M2.5
Qwen3.5-35B-A3B
(e o Qwen3.6 27B mostrado pelo Julien)

Para a maioria, quantizações Q8_0 preservam bem a qualidade original. Tamanho de modelo deixou de ser a barreira; mais relevante hoje é escolher o que casa com o hardware que você já tem.

Não é só llama.cpp: a família ggml.org

Vale lembrar que o llama.cpp não está sozinho. Ele é parte de um ecossistema mais amplo construído em volta do ggml — a biblioteca de tensores em C que o Georgi mantém — e que vive hoje sob a organização ggml-org no GitHub.

Dois projetos dessa família que valem ter no radar:

llama.cpp — inferência de LLM em C/C++. 110k+ estrelas, 18k+ forks. Roda em CPU, GPU NVIDIA/AMD/Intel, Metal (Apple Silicon), Vulkan, e até em ARM embarcado. MIT.
whisper.cpp — porte em C/C++ do Whisper da OpenAI. ~50k estrelas. Transcrição e tradução de áudio totalmente locais, no mesmo espírito: sem API, sem nuvem, em qualquer hardware decente. MIT.

Junte os dois e você já tem assistente de voz local de ponta a ponta: whisper.cpp transcreve, llama.cpp pensa e responde. Tudo no mesmo notebook, sem nada saindo da máquina.

Esse é o padrão arquitetural que dá lastro à conversa sobre soberania: peças pequenas, abertas, plugáveis, sem dependência de um único fornecedor.

Modo avião como bandeira

O que o post do Julien tem de marcante não é o tamanho do modelo. É o modo avião.

Um agente de código atacando repositório real, em código real, sem chamar API nenhuma:

Eficiência — sem latência de rede, sem fila de fornecedor.
Segurança — código sensível nunca sai da máquina.
Privacidade — nenhum prompt aparece em log de terceiro.
Soberania — sua stack não morre quando um fornecedor sobe preço, muda termo de uso ou some.

Ele chama isso de "segunda revolução da IA". A leitura faz sentido: a primeira foi a explosão dos modelos de fronteira via API. A segunda é o que acontece quando capacidade suficiente deixa de ser monopólio de quem tem GPU farm.

E como ele diz, "a maioria das pessoas ainda não percebeu isso". Quem percebe ganha vantagem antes do mercado precificar.

O que fazer agora

Se você trabalha com IA aplicada, três movimentos práticos para esta semana:

Instale o llama.cpp e rode o llama-server localmente com um modelo da lista acima. Use o webui dele com MCP para já sentir tool calling funcionando.
Escreva (ou audite) o seu harness. Se você não controla os passos do agente, você não controla o resultado. Pare de tentar fazer ferramentas fechadas falarem com modelos abertos por osmose.
Identifique um caso de uso que não precisa de fronteira. Resumir documentos internos, classificar tickets, indexar e buscar e-mails, mexer em código de um repositório. Comece por aí, antes de tentar "substituir o Claude Code".

Fechando

Vai existir IA de fronteira em data center? Sempre. Existem tarefas em que isso é o certo.

Mas a percepção de que toda IA precisa rodar lá fora está morrendo. E está morrendo porque:

o hardware do usuário melhorou
os modelos abertos melhoraram
a pilha (llama.cpp + ggml) ficou robusta
a comunidade decidiu que isso é importante demais para depender de um fornecedor

100k estrelas no llama.cpp não é placar de vaidade. É um voto. Sobre que tipo de infraestrutura de IA o mundo quer construir.

Se eu fosse apostar, 2026 vai ser o ano em que muita gente vai olhar pra própria stack e perceber que não precisava pagar por nuvem para metade do que está fazendo.