Rode Sem GPU Local

Nosso rig de benchmark é uma única RTX 3060 com 12 GB, e esse detalhe convenceu alguns leitores de que uma GPU é o preço do ingresso. Não é. No MonkeyLLM o modelo é um binding, não uma dependência, e todas as outras partes da floresta são software de CPU.

Onde o modelo realmente fica

O MonkeyLLM separa o ambiente do modelo. A floresta (um grafo interligado de pequenas notas curadas que seu agente percorre nó a nó) é servida pela Station em infraestrutura comum de CPU. O modelo de linguagem fica atrás de um binding de chat que fala com qualquer endpoint compatível com OpenAI, então local versus remoto é uma URL na sua configuração, não uma decisão de arquitetura. Gaste inteligência no ambiente para gastar menos no modelo (spend intelligence on the environment so you can spend less on the model).

A camada de busca nunca quis uma GPU

A porta de entrada da floresta torna o ponto concreto. A busca de entrada é BM25 sobre SQLite: recall@5 = 1.00 a 1.3 ms p95 no nosso corpus. Sem embeddings, sem banco vetorial, sem GPU. Dar peso aos campos curados (título, aliases) fechou completamente a lacuna para a busca híbrida, e o embedder continua opcional e suportado, não removido, se você quiser depois.

O que deixa exatamente um componente que poderia querer uma GPU, o modelo de chat, e esse é o componente que você pode mover.

Três caminhos sem GPU

Um endpoint hospedado. Aponte o binding de chat para o OpenRouter ou qualquer outro provedor compatível com OpenAI e escolha um modelo. Zero inferência local. Uma ressalva honesta: os dados da sua floresta ficam na sua infra, mas os prompts montados para o modelo viajam até o provedor. Se isso é inaceitável para os seus dados, use um dos dois próximos.

Um servidor llama.cpp. O llama.cpp serve uma API compatível com OpenAI só com CPU, totalmente privado, e é também o caminho de offload quando você tem uma placa pequena. Mais lento que inferência em GPU, mas nada sai da sua rede.

Ollama. O Ollama expõe um endpoint compatível com OpenAI, cuida dos downloads de modelo e roda em CPU ou em qualquer GPU que estiver presente. Para um primeiro setup local, é a opção de menor atrito das três.

A fiação é idêntica nos três casos: na tela Models, aponte o binding de chat para o seu endpoint. O guia de deploy tem os passos exatos.

Quando uma placa local vale a pena

Um 12B quantizado cabe inteiro em 12 GB, e essa classe de modelo é exatamente o que medimos: o mesmo modelo local de 12B marca 0/11 como leitor de RAG top-k clássico e 11/11 como navegador de floresta no nosso conjunto de perguntas estritamente multi-hop. Placas de 8 GB funcionam com quantização mais apertada ou offload para CPU via llama.cpp. Em outras palavras, uma placa intermediária compra privacidade total na capacidade total reportada; nada no paper precisou de mais hardware que isso.

Orçamentos mantêm qualquer endpoint honesto

Seja qual for o endpoint que você vincular, cada salto do agente tem orçamento de tokens, e a tela Models (a capa deste post) mostra seus bindings, seus orçamentos e a pontuação corrente do repositório de respostas em um só lugar. No nosso benchmark o navegador gasta 0.58x tokens por resposta correta contra um baseline de RAG iterativo, a 8.4 s p95 contra 17.5 s do baseline. O objetivo de um orçamento não é avareza; como diz o relatório, "falhar barato não é economia" (failing cheaply is not economy). A contabilidade completa está em RAG agêntico vs navegação orçada, medida em 11 perguntas, o que é pouco e está dito como tal.

Aponte um binding para alguma coisa

Suba a floresta com quatro comandos a partir do quickstart, mire o binding de chat em um endpoint que você já tem e reproduza os números você mesmo: o harness está commitado em github.com/JimmyWesley/MonkeyLLM, e o resto vive em monkeyllm.com.