Modelos multimodales en local: la cuenta de VRAM en una tarjeta de 16 GB

Tienes una tarjeta de 16 GB y quieres enseñarle una captura de pantalla a un modelo que corra en tu propia máquina. La pregunta no es si existe el modelo, existen varios: es si la suma de pesos, proyector de visión, cache KV y tokens de imagen cabe en esos 16 GB con un contexto que sirva para algo. Aquí está la cuenta, con los bytes exactos que publican Qwen, Ollama y el repositorio de llama.cpp, para que puedas rehacerla con tu tarjeta.

Puntos clave

• Un modelo multimodal son tres piezas: codificador de visión, proyector y modelo de lenguaje. Solo la tercera se vuelve a leer en cada token que se genera.
• Los pesos de Qwen3-VL 8B en Q4_K_M pesan 4,68 GiB, y el proyector de visión es un fichero aparte de 1,08 GiB que casi nadie cuenta.
• La cache KV de ese modelo cuesta 144 KiB por token. A 8.192 tokens son 1,13 GiB; a los 262.144 nativos serían 36 GiB.
• Una captura de 1920 × 1080 se convierte en 2.025 tokens visuales: 285 MiB de cache y 2.025 tokens de contexto gastados antes de escribir la pregunta.
• Con 16 GB entran los modelos de 7B a 12B con contextos de 8K a 32K. Lo que no entra es contexto largo, vídeo o un 24B con margen para trabajar.

Cómo está montado un modelo multimodal

Un modelo de visión y lenguaje no es un modelo de texto al que le han enchufado una cámara. Son tres bloques encadenados. El primero es un codificador de visión, casi siempre un Vision Transformer, que trocea la imagen en parches y produce un vector por parche. El segundo es un proyector, una capa pequeña que traduce esos vectores al espacio de embeddings del modelo de lenguaje. El tercero es el modelo de lenguaje propiamente dicho, que recibe esos vectores mezclados con el texto y genera la respuesta.

Esa separación tiene una consecuencia práctica muy concreta: los tres bloques ocupan memoria, pero no se comportan igual. El codificador y el proyector se ejecutan una vez por imagen, durante el prellenado. El modelo de lenguaje se relee entero en cada token que escribe. Por eso el tamaño del fichero de pesos manda en la velocidad, mientras que el codificador manda en cuántas imágenes puedes meter antes de quedarte sin sitio.

En Qwen3-VL la estructura es explícita hasta en los ficheros que se descargan. El repositorio oficial de GGUF publica el modelo y el proyector por separado, y llama.cpp los carga también por separado con el argumento --mmproj. En MiniCPM-V la separación es todavía más visible: el manifiesto de Ollama lista la capa del proyector como una capa propia de 0,97 GiB, distinta de los 4,13 GiB del modelo.

La cuenta para Qwen3-VL 8B

Dentro de la tarjeta conviven cuatro partidas: los pesos del modelo de lenguaje, el codificador de visión con su proyector, la cache KV y el contexto de CUDA con los buffers de activación, que rondan el medio giga. Las dos primeras son ficheros que puedes pesar, y cómo cambian según la cuantización elegida está desarrollado en el artículo sobre cuantización de modelos con llama.cpp. La tercera hay que calcularla, y salen cuatro números del config.json del modelo: 36 capas, 8 cabezas de clave y valor, dimensión de cabeza 128, y dos bytes por valor si la guardas en media precisión.

# Qwen3-VL-8B-Instruct, valores tomados de su config.json
capas, kv_heads, head_dim, bytes_por_valor = 36, 8, 128, 2

por_token = 2 * capas * kv_heads * head_dim * bytes_por_valor
print(por_token)                      # 147456 bytes = 144 KiB por token

for ctx in (8192, 32768, 262144):
    print(ctx, round(por_token * ctx / 2**30, 2), "GiB")
    # 8192    1.13 GiB
    # 32768   4.5  GiB
    # 262144  36.0 GiB

Con eso la tabla se rellena sola. Los dos primeros tamaños son los que devuelve la API de Hugging Face para los ficheros del repositorio oficial de Qwen, no estimaciones.

Sumando pesos, proyector y una cache de 8K salen 6,89 GiB, que con el contexto de CUDA se queda en torno a 7,5 GiB. Sobra media tarjeta. Con 32K de contexto la suma sube a 10,26 GiB y sigue entrando. A 64K la cache sola pide 9 GiB y el total roza los 15 GiB: ahí es donde una tarjeta de 16 GB dice que no. Y el contexto nativo de 256K que anuncia el modelo es sencillamente inalcanzable en hardware de consumo, con 36 GiB solo de cache.

Una comprobación que da confianza en los números: 4,68 más 1,08 son 5,76 GiB, y el blob que descarga Ollama con la etiqueta qwen3-vl:8b mide 5,72 GiB. Dos fuentes independientes que coinciden dentro del uno por ciento.

Cuánto cuesta una captura de pantalla

Aquí es donde la aritmética se vuelve interesante, porque el coste de una imagen no es fijo: depende del número de píxeles. El preprocessor_config.json de Qwen3-VL declara un tamaño de parche de 16 y una fusión espacial de 2, así que cada token visual resume un bloque de 32 × 32 píxeles.

# preprocessor_config.json: patch_size 16, merge_size 2
px_por_token = (16 * 2) ** 2          # 1024 pixeles por token visual

print(1920 * 1080 // px_por_token)    # 2025 tokens
print(3840 * 2160 // px_por_token)    # 8100 tokens
print(16777216 // px_por_token)       # 16384, el tope que fija el procesador

El último número no es casualidad. El campo size del procesador declara un máximo de 16.777.216 píxeles, que dividido entre 1.024 da exactamente 16.384 tokens, y un mínimo de 65.536 píxeles, que da exactamente 64. Los valores son múltiplos exactos, lo que confirma que el bloque de 32 × 32 es el correcto.

Traducido a memoria: una captura de pantalla a 1080p ocupa 2.025 tokens visuales, que a 144 KiB por token son 285 MiB de cache KV. Una captura en 4K se va a 8.100 tokens y 1,11 GiB. No es que no quepa, es que si le pasas cuatro capturas en 4K te has comido 32.400 tokens de contexto y 4,4 GiB de cache antes de que el modelo escriba una sola palabra.

Gemma 3 resuelve ese mismo problema por el camino contrario. Su codificador trabaja a resolución fija de 896 × 896 y comprime cada imagen a un número fijo de vectores. El informe técnico de Google DeepMind lo dice sin adornos: "We reduce the inference cost of image processing by condensing the vision embeddings into a fixed size of 256 vectors". Doscientos cincuenta y seis tokens por recorte, siempre, pase lo que pase con la resolución de entrada. Es predecible y barato, y a cambio pierde detalle fino en imágenes anchas salvo que entre en juego el recorte adaptativo que llaman Pan and Scan.

Qué modelos entran de verdad en 16 GB

Todos los tamaños de esta tabla salen de consultar directamente los manifiestos del registro de Ollama, no de la página web ni de una recopilación de terceros.

Fuera de la tabla hay dos más que entran sin problema: llama3.2-vision:11b con 7,28 GiB y minicpm-v:8b con 4,13 GiB de modelo más 0,97 GiB de proyector. La última fila es la que marca el límite real: un 24B cuantizado cabe en la tarjeta, pero con menos de 2 GiB libres el contexto que te queda es testimonial.

Cómo ejecutarlos

Con Ollama la ruta más corta son dos órdenes, y la ruta de la imagen va dentro del propio mensaje. Si vienes de cero, la puesta en marcha está cubierta en la guía de instalación de Ollama.

ollama pull qwen3-vl:8b
ollama run qwen3-vl:8b "Describe el error que aparece en ./captura.png"

  # dentro de la sesión interactiva, para fijar el contexto:
  # /set parameter num_ctx 8192

Ese num_ctx no es un detalle menor. Ollama arranca con un contexto por defecto muy por debajo de los 262.144 tokens que admite el modelo, y una captura de 1080p ya se lleva 2.025 de ellos. Si el modelo parece olvidar la imagen a mitad de conversación, casi siempre es esto.

Con llama.cpp el control es más fino porque cargas los dos ficheros a mano. La biblioteca libmtmd es la que da soporte multimodal, y tanto llama-cli como llama-server y llama-mtmd-cli admiten el argumento --mmproj.

llama-mtmd-cli 
  -m Qwen3VL-8B-Instruct-Q4_K_M.gguf 
  --mmproj mmproj-Qwen3VL-8B-Instruct-F16.gguf 
  --image captura.png 
  -p "Que error muestra esta captura?" 
  -c 8192 -ngl 99

Por defecto el proyector se descarga también a la GPU. Si vas justo de VRAM, --no-mmproj-offload lo deja en la CPU y te devuelve ese giga largo a costa de un prellenado más lento. Para trastear sin línea de órdenes, LM Studio carga los mismos GGUF con su proyector.

A qué velocidad van

Aquí toca ser honesto: no tenemos una tarjeta NVIDIA de 16 GB con la que medir, así que no vamos a inventar una cifra. Lo que sí hay es una medición publicada en el hilo de rendimiento CUDA del propio repositorio de llama.cpp. Una RTX 5060 Ti de 16 GB, con llama-bench y descarga completa a la GPU, da sobre Llama 2 7B en Q4_0 (3,56 GiB de pesos) 93,46 tokens por segundo de generación y 4.195 tokens por segundo de prellenado, con atención flash activada.

De ahí se puede estimar, sin medirlo, qué cabe esperar de Qwen3-VL 8B. La generación está limitada por el ancho de banda de la memoria, porque cada token obliga a releer los pesos del modelo de lenguaje. Escalando por la relación de tamaños, 93,46 por 3,56 entre 4,68 da unos 71 tokens por segundo. Es una estimación, no una medida: Q4_0 y Q4_K_M usan núcleos distintos, y el proyector añade una pasada por el Vision Transformer que llama-bench no cronometra.

Para el prellenado la cuenta es más directa. A 4.195 tokens por segundo, los 2.025 tokens de una captura de 1080p tardan medio segundo en entrar, más lo que cueste el codificador de visión. Es decir, la primera respuesta tarda un segundo largo en empezar y luego fluye. Suficiente para trabajar. Muy lejos de lo que da un modelo alojado, pero eso ya se sabía.

En qué aciertan y en qué fallan

Qwen dice de su propio modelo que "It can now generate code from images or videos, for example, turning a design mockup into Draw.io, HTML, CSS, or JavaScript code". Es la afirmación del fabricante, no un resultado independiente, y conviene tomarla como tal. Lo que sí es consistente con la experiencia de cualquiera que haya probado estos modelos es que van bien en lo que podríamos llamar comprensión de nivel medio: leer un mensaje de error de una consola, describir la estructura de una interfaz, sacar el esquema de un diagrama de arquitectura, transcribir un texto grande y limpio.

Donde se rompen es en el detalle fino, y la razón se ve en la propia aritmética. Si cada token resume un bloque de 32 × 32 píxeles, una fuente de interfaz de 12 píxeles de alto mete cuatro o cinco caracteres dentro de un único token visual. El modelo no está leyendo esas letras, está adivinando qué palabra encaja en ese borrón. Por eso las tablas densas salen con celdas cambiadas de sitio y las cifras pequeñas salen mal.

Y luego está el problema estructural, que no se arregla con más resolución. El trabajo de Rahmanzadehgervi y sus colegas, publicado en julio de 2024, sometió a cuatro modelos punteros a siete tareas visuales elementales, del tipo decir si dos círculos se tocan o contar los aros de un logotipo olímpico. La media fue del 58,07 por ciento y el mejor de todos se quedó en el 77,84, frente al 100 esperable de una persona. Sus pruebas de sondeo lineal mostraron que el codificador de visión sí tenía la información; era el modelo de lenguaje el que no sabía leerla. Si eso le pasa a los modelos alojados grandes, no esperes que un 8B en tu escritorio te dé coordenadas fiables.

La conclusión práctica es sencilla: pídeles descripción y estructura, no medidas ni posiciones exactas. Lo mismo que ya se comentaba al hablar de la multimodalidad nativa de GPT-4o y del salto de contexto de Gemini 2.5, pero con menos margen.

Cuándo 16 GB no dan para más

Hay tres situaciones en las que la tarjeta se queda corta y no es cuestión de afinar parámetros. La primera es el contexto largo: por encima de 64K tokens la cache KV se come la tarjeta ella sola. La segunda es el vídeo, porque un puñado de fotogramas multiplica el coste de la imagen por el número de fotogramas. La tercera son los modelos de 24B o más con margen de trabajo.

El ejemplo más claro del tercer caso se publicó el 9 de agosto de 2026: Muse-Glimmer-30B, de Meta, con licencia Apache 2.0 y 29.600 millones de parámetros, de los cuales 1.800 millones son un codificador ViT-G/14. Su compilación GGUF más comprimida pesa 15,61 GiB y su proyector otros 1,30 GiB, así que suma 16,91 GiB y se queda fuera de una tarjeta de 16 GB por poco más de un giga. Su ficha lo sitúa en un margen de 24 o 32 GB, y ahí es donde tiene sentido.

Ese modelo enseña además algo que la tabla de descargas no dice: tiene 52 capas pero solo dos cabezas de clave y valor, así que su cache KV cuesta 52 KiB por token, poco más de un tercio de lo que cuesta la de Qwen3-VL 8B, que es cuatro veces más pequeño. El tamaño del fichero no es el único eje de la cuenta, y a veces ni siquiera es el que decide.

Las salidas son tres también, en orden de coste. La barata es bajar de modelo: qwen3-vl:4b ocupa 3,07 GiB y deja 12 GB libres para contexto, y para leer errores de consola cumple. La intermedia es cuantizar la cache KV a 8 bits, que la parte por la mitad, o descargar el proyector a la CPU. La cara es cambiar de tarjeta, y ahí conviene mirar antes qué alternativas hay a NVIDIA, porque el criterio a partir de 16 GB deja de ser la potencia y pasa a ser cuánta memoria te dan por euro.

Preguntas frecuentes

¿Puedo usar el contexto de 256K que anuncia Qwen3-VL?

En una tarjeta de consumo no. La cache KV de ese modelo cuesta 144 KiB por token, así que 262.144 tokens serían 36 GiB solo de cache, sin contar los pesos. Ese contexto está pensado para servidores con varias tarjetas o con mucha memoria unificada.

¿Merece la pena Q8 en lugar de Q4 con 16 GB?

Depende del contexto que necesites. El GGUF en Q8_0 de Qwen3-VL 8B pesa 8,11 GiB frente a los 4,68 de Q4_K_M. Con proyector y una cache de 8K te vas a 10,3 GiB, que entra, pero pierdes la mitad del margen para el contexto y para las imágenes.

¿Por qué mi modelo multimodal ocupa más de lo que decía la ficha?

Porque la ficha suele contar solo los pesos del modelo de lenguaje. Falta el proyector de visión, que en Qwen3-VL 8B es un fichero aparte de 1,08 GiB, y falta la cache KV, que depende del contexto que hayas configurado y no del modelo.

Conclusión

La respuesta corta es que sí, un modelo multimodal de 8B cabe en 16 GB de VRAM con contexto suficiente para trabajar, y va a unos 70 tokens por segundo en una tarjeta reciente de esa gama. La respuesta larga es que la cifra que importa no son los 5 GB del fichero, sino los 144 KiB por token de la cache y los 2.025 tokens que se lleva una captura de pantalla. Con esos dos números y una calculadora puedes decidir en un minuto qué modelo y qué contexto te caben, sin fiarte de la tabla de requisitos de nadie. Si quieres ver la misma cuenta aplicada a otro modelo abierto reciente, está el artículo sobre Gemma 4 en tu propio equipo con Ollama. La versión en inglés de este artículo está en Local multimodal models: the VRAM arithmetic on a 16 GB card.

Fuentes

1. Qwen, ficha de Qwen3-VL-8B-Instruct con su config.json y preprocessor_config.json
2. Qwen, repositorio GGUF de Qwen3-VL-8B-Instruct con los ficheros mmproj
3. Gemma Team, Google DeepMind, informe técnico de Gemma 3
4. Ollama, ficha de la biblioteca qwen3-vl
5. llama.cpp, documentación multimodal
6. llama.cpp, hilo de rendimiento sobre NVIDIA CUDA
7. Rahmanzadehgervi, Bolton, Taesiri y Nguyen, Vision language models are blind
8. Meta, ficha de Muse-Glimmer-30B
9. Meta, repositorio GGUF de Muse-Glimmer-30B