Anders e Tom criam Magnitude para bater o llama.cpp em IA local

Os dois autores já haviam criado um agente de navegador de código aberto com mais de 4 mil estrelas no GitHub e 100 mil downloads. Eles afirmam que motores atuais sacrificam o desempenho: projetos como vLLM e SGLang miram lotes em data centers, enquanto llama.cpp e Ollama priorizam compatibilidade ampla em vez de calibrar para cada chip. A proposta do Magnitude atraiu 194 pontos e 97 comentários no fórum Hacker News. O debate esquentou rápido.

Promessas de velocidade esbarram em dados ausentes

A falta de números detalhados despertou ceticismo. O usuário nateb2022 cobrou método: "Existe alguma fonte sobre os benchmarks e a metodologia além da imagem? Há uma tonelada de variação possível no desempenho do llama.cpp dependendo de como foi configurado. Eu também gostaria de ver benchmarks contra o MLX." Bater o concorrente comum não impressiona todos. O participante kmike84 resumiu o cenário: "Isso parece uma boa ideia. No entanto, bater o llama.cpp em velocidade é uma régua baixa. Achei uma boa linha de base, mas pelo menos no Mac sempre houve algo bem mais rápido e com melhores requisitos de memória, como vocês disseram: ds4, omlx, mtplx."

Nos testes de bancada, a teoria da compilação adaptativa esbarrou em falhas de detecção. O desenvolvedor herf colocou duas placas gráficas para rodar e encontrou lentidão: "Eu tenho duas GPUs NVIDIA (16GB+16GB) aqui, e ele detecta cada uma duas vezes (diz que tenho 4 GPUs). Mas aí diz que a maioria dos modelos é grande demais (qualquer coisa acima de 8GB?) e parece rodar apenas em uma GPU (5070ti). Infelizmente, mesmo com a minha 5070ti, o llama.cpp parece ser cerca de 20% a 30% mais rápido no decode". Ele usou o modelo google/gemma-4-12B-it-qat-q4_0-gguf com contexto em 262144 tokens no llama-server. O teste desmentiu o ganho anunciado.

Gargalos reais aparecem na memória e no contexto longo

Apesar das divergências nos testes, criadores e usuários concordam que os motores genéricos deixam desempenho na mesa ao rodar agentes locais. Quem opera fluxos contínuos esbarra nos mesmos limites: decodificação especulativa ausente, consumo excessivo de VRAM no cache de chaves e valores e perda de velocidade em janelas longas de 100 mil a 200 mil tokens. O usuário msdz questionou a viabilidade de manter código sob medida para cada rede: "Parte da 'inércia dos motores de inferência' decorre de exigir código específico para o modelo ou para a arquitetura a cada novo modelo de pesos abertos lançado". Manter kernels otimizados consome tempo.

O debate deixa sem resposta se o ajuste automático no chip do cliente consegue superar a maturidade de ferramentas consolidadas. Anders e Tom concentram o código nas arquiteturas abertas mais populares para elevar o teto de processamento em computadores pessoais. Para quem projeta sistemas com agentes locais, a escolha exige pesar o suporte a múltiplas GPUs e o consumo de memória contra a promessa de maior velocidade. A estabilidade prática ainda decide a escolha.