VRAMPilot

Ejecuta tus modelos GGUF en local y se recupera de un out-of-memory en ejecución en lugar de fallar.

VRAMPilot es una herramienta local gratuita que ejecuta modelos GGUF con llama.cpp y se recupera de un out-of-memory en ejecución en lugar de fallar. Le das un archivo .gguf; lee tu GPU, elige una configuración que quepa, lanza un llama-server, y si el modelo se desborda igualmente — al arrancar o en plena generación — retrocede, reintenta hasta servir, y te dice qué ha sacrificado para que quepa.

El problema: los fallos OOM

El primer muro al lanzar un modelo local es el out-of-memory. Una herramienta estima que el modelo cabe, lo lanza, y la estimación resulta ser falsa — fragmentación, otra aplicación que ocupa la VRAM, un contexto más largo de lo previsto por el cálculo. Las herramientas populares previenen el OOM en la carga; cuando la estimación es falsa a pesar de todo, el servidor falla, o se desborda silenciosamente hacia la RAM del sistema y se vuelve muy lento sin decirte por qué.

Un estimador es una suposición hecha antes del lanzamiento. El bucle de recuperación es lo que se ejecuta una vez que la suposición ya se ha equivocado.

Lo que hace

Cinco cosas, cada una validada en hardware real — cada cifra de este sitio enlaza el archivo de validación del que procede, y esos archivos se publican tal cual bajo /proofs/ — haz clic en cualquier cifra para leer su fuente bruta.

Plan de ajuste automático. Lee el modelo a partir de los bytes reales de la cabecera GGUF (capas, expertos MoE, cuantización, tamaño) y la VRAM libre de tu GPU (medida en NVIDIA, estimada en AMD/Intel/Apple — el informe siempre dice cuál de las dos), y luego elige las capas GPU, el contexto, la precisión del KV-cache y el expert-offload MoE para que el modelo quepa. Validado hasta un archivo de 9,5 Go en una GPU de 8 Go.
Recuperación OOM en ejecución. Si el lanzamiento topa igualmente con un error out-of-memory, lo detecta, retrocede en varios ejes — primero la precisión del KV-cache (para conservar tu contexto), luego el contexto, luego más descarga hacia la CPU — y reintenta hasta que el servidor arranca y sirve realmente un token. Después te muestra la traza del retroceso.
Persistencia de lo que arrancó. Cada configuración que realmente arrancó se almacena en una base SQLite local, en modo append-only. El siguiente lanzamiento parte de la configuración conocida-buena; un cambio de driver o de GPU la invalida y desencadena un nuevo plan. Nada sale de tu máquina, y un comando configs list muestra todo lo que recuerda.
Watchdog durante la inferencia. Cubre el fallo que las herramientas de carga no cubren: el agotamiento de la VRAM en mitad de una generación larga. En un run validado bajo verdadera presión de VRAM externa, se cruzó el suelo con 102 MiB libres y el servidor se recuperó en 223,9 s sobre una configuración degradada — mientras la presión seguía ahí. El coste honesto, anunciado por la propia herramienta: la generación en curso se pierde. La recuperación es real, no invisible.
Instalación sin requisitos previos. No hace falta instalar llama.cpp: el primer lanzamiento descarga un build de llama.cpp fijado para tu OS y tu GPU con verificación SHA256 obligatoria (un mismatch borra el archivo y detiene en seco). Medido en la máquina del gate: 7,6 s desde un arranque en frío hasta una verdadera completación servida — con un modelo de prueba de 1 Go ya en disco (el tiempo incluye la descarga del binario fijado, no la del modelo).

Alcance honesto

VRAMPilot es una capa de automatización y de UX por encima de llama.cpp, que hace la inferencia real (carga, offload, servicio). No es ni un nuevo motor de ejecución, ni un avance de investigación. Si llama.cpp no puede ejecutar tu modelo, VRAMPilot tampoco.
El ajuste automático en la carga ya existe aguas arriba: los builds recientes de llama.cpp incorporan una opción -fit, y LM Studio, Ollama y Jan estiman todos antes del lanzamiento. La prevención en la carga es la norma. Lo que sigue sin cubrirse — y lo que VRAMPilot añade — es la recuperación en ejecución, la persistencia de lo que realmente arrancó, y el informe honesto de lo que se ha perdido.
El moat es un moat de ingeniería, no una barrera infranqueable. Cualquier actor establecido podría añadir un bucle de recuperación en una versión menor. La apuesta: ser correcto y completo en algo realmente no cubierto hoy.
Ningún software vence a la física. Un modelo que no cabe ni siquiera en la configuración mínima no puede ejecutarse; VRAMPilot te dice que ha alcanzado el suelo en lugar de fingir.

Sin cookies

Este sitio no deposita ninguna cookie y no carga nada desde terceros. Como la propia herramienta: local, nada se transmite.