Ejecútalo sin GPU local

Nuestro rig de benchmark es una sola RTX 3060 con 12 GB, y ese detalle ha convencido a algunos lectores de que una GPU es el precio de entrada. No lo es. En MonkeyLLM el modelo es un binding, no una dependencia, y todas las demás piezas del bosque son software de CPU.

Dónde se sienta el modelo en realidad

MonkeyLLM separa el entorno del modelo. El bosque (un grafo enlazado de notas pequeñas y curadas que tu agente camina nodo por nodo) lo sirve la Station en infraestructura de CPU ordinaria. El modelo de lenguaje se sienta detrás de un binding de chat que habla con cualquier endpoint compatible con OpenAI, así que local versus remoto es una URL en tu configuración, no una decisión de arquitectura. Gasta inteligencia en el entorno para gastar menos en el modelo.

La capa de búsqueda nunca quiso una GPU

La puerta de entrada del bosque vuelve concreto el punto. La búsqueda de entrada es BM25 sobre SQLite: recall@5 = 1.00 a 1.3 ms p95 en nuestro corpus. Sin embeddings, sin base de datos vectorial, sin GPU. Ponderar los campos curados (título, alias) cerró por completo la brecha con la búsqueda híbrida, y el embedder sigue opcional y soportado, no eliminado, por si lo quieres después.

Lo que deja exactamente un componente que podría querer una GPU, el modelo de chat, y ese es el componente que puedes mover.

Tres caminos sin GPU

Un endpoint alojado. Apunta el binding de chat a OpenRouter o a cualquier otro proveedor compatible con OpenAI y elige un modelo. Cero inferencia local. Una advertencia honesta: los datos de tu bosque se quedan en tu infra, pero los prompts armados para el modelo sí viajan al proveedor. Si eso es inaceptable para tus datos, usa uno de los dos siguientes.

Un servidor llama.cpp. llama.cpp sirve una API compatible con OpenAI solo con CPU, totalmente privada, y además es el camino de offload cuando tienes una tarjeta chica. Más lento que la inferencia en GPU, pero nada sale de tu red.

Ollama. Ollama expone un endpoint compatible con OpenAI, maneja las descargas de modelos y corre en CPU o en la GPU que haya presente. Para un primer setup local es la opción de menor fricción de las tres.

El cableado es idéntico en los tres casos: en la pantalla Models, apunta el binding de chat a tu endpoint. La guía de despliegue tiene los pasos exactos.

Cuándo vale la pena una tarjeta local

Un 12B cuantizado cabe entero en 12 GB, y esa clase de modelo es exactamente lo que medimos: el mismo modelo local 12B anota 0/11 como lector de RAG top-k clásico y 11/11 como navegador de bosque en nuestro conjunto de preguntas estrictamente multi-salto. Las tarjetas de 8 GB funcionan con cuantización más agresiva o con offload a CPU vía llama.cpp. En otras palabras, una tarjeta de gama media compra privacidad total a la capacidad completa reportada; nada en el paper necesitó más hardware que eso.

Los presupuestos mantienen honesto a cualquier endpoint

Sea cual sea el endpoint que enlaces, cada salto que da el agente tiene presupuesto de tokens, y la pantalla Models (la portada de este post) muestra tus bindings, sus presupuestos y el puntaje acumulado del almacén de respuestas en un solo lugar. En nuestro benchmark el navegador gasta 0.58x tokens por respuesta correcta contra una línea base de RAG iterativo, a 8.4 s p95 contra los 17.5 s de la línea base. El punto de un presupuesto no es la tacañería; como dice el informe, "Failing cheaply is not economy" (fallar barato no es economía). La contabilidad completa está en RAG agéntico vs navegación con presupuesto, medida en 11 preguntas, que es poco y así se declara.

Apunta un binding a algo

Despliega el bosque con cuatro comandos desde el quickstart, apunta el binding de chat a un endpoint que ya tengas y reproduce los números tú mismo: el harness está versionado en github.com/JimmyWesley/MonkeyLLM, y el resto vive en monkeyllm.com.