FAQ

Respuestas directas a las preguntas que un escéptico hace de verdad. Versión corta primero: VRAMPilot es un wrapper alrededor de llama.cpp. Lo que hace que las herramientas populares no hacen: recuperarse de un out-of-memory en tiempo de ejecución en lugar de colgarse, recordar la configuración que realmente funcionó, y sobrevivir a un OOM en plena generación.

¿Es solo una interfaz para llama.cpp?

En gran parte, sí — y lo decimos antes que tú. VRAMPilot es una capa de automatización y de UX por encima de llama.cpp. Es llama.cpp quien hace el trabajo de verdad: carga del modelo, offload de GPU, tensor split, servicio. VRAMPilot no ejecuta ninguna operación de inferencia por sí mismo — lanza llama-server y gestiona los flags. No es ni un nuevo motor de inferencia, ni un resultado de investigación. Lo que añade: el bucle de recuperación OOM en tiempo de ejecución, la persistencia de lo que realmente arrancó, el watchdog durante la inferencia, y el informe honesto de lo que se ha sacrificado. Esas son las únicas partes que merecen tu atención.

¿En qué se diferencia de LM Studio, Ollama o Jan? Ya ajustan los modelos automáticamente.

Es cierto, y VRAMPilot no pretende lo contrario. Los estimadores de VRAM y el dimensionamiento automático del contexto ya existen — el «Fit to Hardware» de Jan, los contextos por niveles de VRAM de Ollama, el estimador de pre-carga de LM Studio. Es la norma. La diferencia está en el momento en que se produce el ajuste: estas herramientas previenen el OOM al cargar. Ninguna se recupera en tiempo de ejecución. Cuando una configuración se desborda igualmente — un contexto explícito impuesto, un prompt largo que desborda la KV-cache, una VRAM menos libre de lo estimado — se cuelgan, o se desbordan silenciosamente hacia la RAM del sistema y se ralentizan sin decírtelo. Ninguna de ellas tiene un bucle detectar → replegarse → reintentar (verificado herramienta por herramienta en 2026, ver la página de comparación). Esa carencia es la razón de ser de VRAMPilot.

¿Qué es exactamente la «recuperación OOM»?

Cuando el servidor no arranca — o arranca pero no puede generar ningún token — el lanzador lee el log de error, lo clasifica como out-of-memory, se repliega un escalón, y reintenta. El orden preserva la mayor capacidad: la precisión de la KV-cache primero (conserva tu contexto completo, lossy en el razonamiento largo), luego la reducción del contexto, luego más descarga hacia la CPU. Si nada encaja, dice que ha alcanzado el suelo en lugar de fingir. En el run validado, una configuración deliberadamente imposible a 262144 de contexto se recuperó a 131072 — 4x más contexto del que habría conservado un repliegue solo sobre el contexto — y sirvió una respuesta de verdad.

¿Qué retiene en mi máquina?

Cada configuración que realmente arrancó, persistida por (huella de la máquina, hash de la cabecera del modelo, contexto solicitado) en un archivo SQLite local — en modo append-only: una configuración que ya no funciona se conserva en el historial, nunca se sobrescribe. El siguiente lanzamiento arranca directamente sobre la configuración conocida-buena; un cambio de driver o de GPU la invalida y dispara un nuevo plan. Por qué es útil: un intento fallido cuesta una carga completa del modelo, medida en ~220 s por intento para un MoE de 9,5 Go en el disco de la máquina del gate. Nada sale de tu máquina; vrampilot configs list muestra todo lo que retiene, y --no-cache lo desactiva por completo.

¿Y si la VRAM falla en plena generación?

Es un crash que ninguna de las herramientas que sondeamos cubre (nominalmente, 2026 — ver la página de comparación): estás en medio de una generación larga, otra aplicación toma VRAM, y el servidor muere. En NVIDIA, el watchdog mide la VRAM libre con lecturas reales de nvidia-smi, emite una alerta suave ante una mala tendencia, y en el suelo auto-calibrado hace un reinicio controlado sobre una configuración degradada, luego persiste la superviviente para que el próximo lanzamiento parta de ahí. Run validado bajo presión real: suelo franqueado a 102 MiB libres → recuperado en 223,9 s a un contexto 8192 → 4096 mientras la presión seguía ahí → completación real servida. El coste honesto, anunciado por la propia herramienta: la generación en curso se pierde. La recuperación es real, no invisible. Contraprueba: 0 soft alerts, 0 interventions en generaciones normales. En Vulkan/Apple, la VRAM libre es una estimación, así que el watchdog se rebaja honestamente a vigilancia de proceso + salud — y te lo dice.

¿Tengo que instalar llama.cpp yo mismo?

No. El primer lanzamiento descarga un build de llama.cpp fijado (b9592) para tu OS y tu GPU, con verificación SHA256 obligatoria: un mismatch borra el archivo y se detiene en seco. Medido en la máquina del gate: 7,6 s desde un arranque en frío hasta una completación real servida. Por defecto: Vulkan en Windows/Linux (un solo binario, sea cual sea el fabricante de la GPU), Metal en macOS, CUDA opt-in. Si prefieres tu propio build de llama-server, siempre puedes apuntarlo.

¿Funciona de verdad? ¿Qué está validado?

Medido en hardware real, no afirmado al aire. Arranca y sirve una completación real en 3 fabricantes de GPU: una NVIDIA RTX 3070 (CUDA), una AMD Radeon 780M (iGPU, Vulkan), y un chip Apple M1 (Metal). La recuperación OOM se ha demostrado de principio a fin en NVIDIA y AMD: ante una configuración deliberadamente imposible, se recuperó y sirvió una respuesta de verdad. La persistencia y el watchdog se han validado de principio a fin en una NVIDIA RTX 4070 Laptop GPU, 8 Go — incluido un MoE de 9,5 Go a 32k de contexto vía expert-offload. Los logs en bruto están commiteados junto a cada afirmación.

¿Puede ejecutar un modelo más grande que la VRAM de mi GPU?

Dentro de ciertos límites, sí — para eso sirve la descarga: los runs validados incluyen un archivo de 9,5 Go en una GPU de 8 Go, ajustado vía expert-offload MoE. Pero existe un suelo físico: un modelo demasiado grande incluso en la configuración suelo no puede ejecutarse, y ningún software vence a la física. La descarga a la CPU también cuesta velocidad — VRAMPilot te dice lo que ha sacrificado, pero lento sigue siendo lento. Y en una máquina muy pequeña, una petición absurda puede arrancar y producir galimatías; el uso normal limita el contexto al límite de entrenamiento del modelo.

¿Cuál es el moat? ¿LM Studio u Ollama no pueden simplemente copiarlo?

Respuesta incómoda: sí, pueden. Es un moat de ingeniería, no una patente ni un moat de datos. De hecho ya ha empezado por el lado de la prevención: los builds recientes de llama.cpp incorporan un auto-fit al cargar (-fit), así que la prevención al cargar es ya la norma aguas arriba. Lo que sigue sin estar cubierto: el bucle de recuperación en tiempo de ejecución, la persistencia, y el informe honesto de lo que se ha perdido. La apuesta: entregar ahora, ir a fondo en el repliegue multi-ejes, y validar en varios fabricantes. Si los actores establecidos lo añaden, es una victoria para todos los que ejecutan modelos en local.

¿Qué es lo que NO hace?

Dicho simple: no es un nuevo motor de ejecución — es llama.cpp quien infiere, y si llama.cpp no puede ejecutar tu modelo, esto tampoco. No agranda tu GPU — un modelo que no cabe ni siquiera en el suelo no puede ejecutarse. La recuperación no es gratis — un reinicio del watchdog pierde la generación en curso, y una configuración degradada está degradada (el informe nombra la pérdida). La recuperación en Apple no está enteramente demostrada: el arranque y el servicio funcionan en M1 y el mecanismo está en su sitio, pero una demostración limpia de OOM forzado no era posible en el pequeño runner de CI. Es una utilidad modesta y útil, construida en solitario, en sprint — no una revolución.

¿Por qué fiarse del informe «honesto» de las pérdidas?

Porque es el principio, y porque es verificable. La herramienta muestra la traza del repliegue y nombra cada compromiso; ves exactamente qué configuración arrancó. Este sitio se aplica la misma regla a sí mismo: cada cifra publicada está envuelta en un marcado de claim que apunta al archivo de validación commiteado que la contiene, y la construcción del sitio falla si una cifra y su fuente divergen.

¿Es gratis?

Sí, la herramienta es gratis. El repositorio de código es privado por ahora, con la intención de abrirlo. Se apoya en llama.cpp, que es open source.