¿LLM local sin VRAM? Compara pesos y caché KV con gputaskman

Tu modelo local cargó bien ayer, hoy falla al cargar o va a paso de tortuga, y lo único que cambiaste fue la longitud de contexto. Un culpable habitual es la caché KV, y una herramienta de terminal gratuita llamada gputaskman puede mostrártelo en lugar de dejarte adivinando.

Un monitor de GPU típico te dice cuánta VRAM está ocupada. Eso es el "qué", no el "por qué". El README de gputaskman (consultado el 5 de noviembre de 2026) se describe como "Un htop para lo que hay dentro de tu GPU, no solo para cuánto está llena". Es un proyecto temprano, experimental y con licencia MIT, así que trátalo como una lente útil, no como un veredicto.

Qué llena realmente tu VRAM#

Piensa en la VRAM como una maleta. Dentro van tres cosas:

• Pesos: el modelo en sí. Tamaño fijo para un modelo y una cuantización dados.
• Caché KV: la memoria a corto plazo del modelo sobre tu conversación. Crece a medida que crece el contexto.
• Búferes de cómputo: espacio de trabajo que el runtime necesita mientras opera.

Cuando la gente dice "el modelo no cabe", a menudo quiere decir que los pesos caben pero la caché que pediste encima no. Esa distinción decide la solución, y es exactamente lo que oculta un monitor corriente.

Instala gputaskman y mira por proceso#

El README enumera tres formas de entrar: un ZIP portátil para Windows, un clon ejecutado con uv run --locked gputaskman, o pip dentro de un entorno virtual de Python 3.11+. Plataformas, tal como las describe el README:

• Windows 10/11 de 64 bits con una GPU NVIDIA o AMD (ZIPs x64 y ARM64 en la página de Releases);
• Linux y WSL con una GPU NVIDIA (glibc 2.35+; WSL puede leer los contadores del host de Windows);
• macOS en Apple Silicon solo desde un clon del código fuente, sin compilación portátil.

Los ZIPs de Windows no están firmados. Descárgalos solo desde la página de Releases del repositorio oficial, github.com/shanselman/gputaskman. Copia los comandos exactos del README: el proyecto es joven y las opciones pueden cambiar.

Una vez en marcha, dos vistas importan para este problema:

1. Vista de dispositivo: uso de VRAM, actividad de la GPU, PCIe, temperatura, potencia, relojes y gráficos de historial. Buena para "¿algo se disparó?".
2. Vista de proceso: memoria GPU local por proceso, RAM del sistema accesible por la GPU, actividad del motor y el runtime detectado (CUDA, HIP, Vulkan, Direct3D, ggml, ONNX Runtime).

En la vista de proceso, encuentra tu servidor de modelos (para Ollama, su runner incluido). Luego revisa el resto de la lista. Si un navegador o un juego ocupa unos cuantos gigabytes, has encontrado tu respuesta sin tocar el modelo.

Pesos, caché KV, búferes: de dónde salen los números#

El inspector de modelos muestra arquitectura, cuantización y tamaños de búfer cuando están disponibles. Una advertencia importante: según el README, los pesos, la caché KV y los búferes de cómputo provienen de los logs de carga del runtime cuando el registro compatible está habilitado. Para llama.cpp, inicia tu propio llama-server con registro (--log-file server.log -lv 4; el README dice que se necesita el nivel 4 para los tamaños de búfer). Para Ollama, gputaskman usa server.log de Ollama si está disponible. De lo contrario son estimaciones a partir de los metadatos GGUF y el tamaño de contexto, asumiendo una colocación al estilo llama.cpp. La contabilidad de KV por modelo dentro de un solo proceso aún no está soportada.

Así que lee un desglose estimado como "aproximadamente", y un desglose basado en logs como "lo que reportó el runtime". Para Ollama, el README dice que se detectan los runners incluidos, los blobs GGUF se nombran a partir de los manifiestos de Ollama, y se usa server.log cuando está disponible. El soporte de LM Studio es parcial: los modelos se nombran desde su carpeta y se sondean mediante su API local, pero esto se probó con respuestas de fixture, no de extremo a extremo.

También puedes guardar dos instantáneas como JSON y compararlas con el comando diff. Es una forma limpia de responder "¿qué cambió cuando pasé de 4K a 16K de contexto?": toma una instantánea, cambia el ajuste, recarga, toma otra.

Qué palanca girar#

Leer el desglose te da una decisión, no solo una imagen.

Los pesos son la porción grande. Pasa a una cuantización más pequeña o a un modelo más pequeño. Es la única palanca que reduce los pesos. Si quieres las cuentas de memoria detrás de esto, consulta ¿Puede un modelo de 125B ejecutarse en una GPU de 16 GB?

La caché KV es la porción grande. Acorta el contexto. En Ollama puedes probarlo directamente en la sesión:

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 es solo un valor de ejemplo; elige lo que tu tarea realmente necesita (comando según la documentación de Ollama, consultada el 5 de noviembre de 2026).

Si más adelante ves una lentitud extraña en el procesamiento de prompts con una caché cuantizada en llama.cpp, esta corrección para la caché KV q5_1 es el siguiente paso. Para saber qué contiene una ventana de contexto en primer lugar, lee ¿Qué es una ventana de contexto?

Otro proceso es la porción grande. Ciérralo, o ejecútalo en la GPU integrada. No hace falta cambiar nada del modelo.

Si no funciona#

• El desglose parece raro. Comprueba si es una estimación (sin logs de carga compatibles). Con llama.cpp, ejecuta tu llama-server con --log-file server.log -lv 4 y recarga el modelo. Con Ollama, gputaskman usa server.log si existe; una etiqueta de estimación es normal ahí.
• LM Studio muestra menos detalle. El soporte es parcial, como se indicó.
• Sin GPU NVIDIA o AMD. La herramienta cubre solo cargas de trabajo de GPU local; las cargas solo de CPU, solo de NPU y en la nube quedan fuera de alcance.
• macOS. Ejecútala desde un clon del código fuente; no hay compilación portátil.

Cuando un modelo alojado es la solución más simple#

Supón que necesitas un contexto largo para una tarea, como resumir un documento grande, y tu GPU solo admite el modelo con uno corto. Puedes seguir ajustando, o sacar la VRAM de la ecuación. Para tareas así, CheapTokens ofrece DeepSeek-V4-Flash: contexto de 380K, hasta 32.768 tokens de salida por respuesta, un precio a cualquier hora del día, mediante una API compatible con OpenAI. GLM-5.3-Flash tiene un contexto de 390K y hasta 8.192 tokens de salida.

La llamada es el formato habitual de OpenAI (pon tu clave en una variable de entorno):

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

Los detalles de configuración están en la documentación. Una regla general para decidir: si una tarea sigue necesitando más contexto o un modelo más grande del que cabe en tu tarjeta, y la vista de proceso muestra que tu VRAM ya está bien usada, envía esa tarea a la API y mantén local los trabajos pequeños y rápidos. ¿Ejecutar DeepSeek localmente o usar una API? profundiza en el equilibrio.

Supón que resumes 100 documentos grandes, cada uno de 60.000 tokens de entrada y 1.000 tokens de salida (bien dentro de la ventana de 380K). Esto es lo que cuesta hoy:

Con esos números, $0.001 por documento es el precio en vivo para una llamada así, y en total, contando entrada y salida juntas, queda por debajo de OpenRouter.