Ejecutar Gemma 4 12B con 8GB de VRAM: cómo ajustar la descarga híbrida en llama-cli

Ejecutar Gemma 4 12B con 8GB de VRAM no es principalmente un problema de espacio en disco. La presión real está en la VRAM durante la ejecución.

Con una versión GGUF cuantizada como Q4_K_M, el archivo del modelo puede acercarse ya a los 8GB. Al ejecutarlo también hacen falta KV cache, buffers temporales de cálculo, uso del escritorio y sobrecarga del driver. El resultado es conocido: parece que el modelo “casi cabe”, pero al abrir contexto largo aparece OOM.

Si la máquina solo tiene 8GB de VRAM, la estrategia razonable no es forzar todo a la GPU, sino usar descarga híbrida entre VRAM y memoria del sistema: poner tantas capas como sea posible en la GPU y dejar el resto en RAM con participación de la CPU.

Script recomendado

Supongamos que la ruta del modelo es:

1

./models/gemma-4-12b-it-Q4_K_M.gguf

En Linux / macOS puedes crear run_gemma4.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#!/usr/bin/env bash
set -e

MODEL_PATH="./models/gemma-4-12b-it-Q4_K_M.gguf"

./llama-cli \
  -m "$MODEL_PATH" \
  -ngl 26 \
  -c 8192 \
  -t 8 \
  --flash-attn \
  --mlock \
  -n -1 \
  --color \
  -i

Dale permisos:

1

chmod +x run_gemma4.sh

Ejecuta:

1

./run_gemma4.sh

En Windows puedes crear run_gemma4.bat:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

@echo off
set MODEL_PATH=.\models\gemma-4-12b-it-Q4_K_M.gguf

llama-cli.exe ^
  -m "%MODEL_PATH%" ^
  -ngl 26 ^
  -c 8192 ^
  -t 8 ^
  --flash-attn ^
  -n -1 ^
  --color ^
  -i

En Windows normalmente no conviene poner --mlock por defecto. Su comportamiento depende de versión, permisos y configuración del sistema. Primero importa que el modelo arranque. En Linux, si hay suficiente memoria del sistema, --mlock sí merece la pena probarse.

Por qué usar descarga híbrida

-ngl es el parámetro más importante de esta configuración. Controla cuántas capas se descargan a la GPU.

1

-ngl 26

Con 8GB de VRAM, el objetivo no es meter todo el modelo en la GPU, sino dejar margen para KV cache y buffers de ejecución. -ngl 26 puede usarse como valor inicial: algunas capas van a VRAM y la memoria del sistema recibe el resto.

La forma de ajustar es simple:

En una máquina con 8GB de VRAM no mires solo el tamaño del modelo. Lo importante es si capas del modelo, KV cache, fragmentación de VRAM y escritorio caben con margen.

--flash-attn: recomendable con 8GB de VRAM

1

--flash-attn

Este parámetro ayuda mucho con poca VRAM. Reduce la presión de memoria en attention y mejora la eficiencia de inferencia con contexto largo.

Si tu build de llama.cpp, backend GPU o arquitectura de tarjeta no soporta Flash Attention, puede fallar al arrancar. En ese caso, quita primero --flash-attn para confirmar que el modelo funciona, luego actualiza llama.cpp o revisa soporte de CUDA / Metal / Vulkan.

Con 8GB de VRAM, actívalo si puedes. Si no, baja primero el contexto.

-c 8192: empezar con contexto 8K

1

-c 8192

Cuanto más largo sea el contexto, mayor será la KV cache. Muchos modelos anuncian contexto muy largo, pero una máquina con poca VRAM no debería abrir el máximo de entrada.

Con 8GB de VRAM, 8192 es un punto de partida equilibrado. Sirve para chat diario, análisis de fragmentos de código y textos medianos, sin comerse la VRAM tan rápido como 32K o 64K.

Si sigue habiendo OOM, baja:

1

-c 4096

Si cambias a una cuantización más pequeña y hay margen claro de VRAM, prueba:

1

-c 12288

No persigas el contexto máximo al principio. Primero estabilidad, luego expansión.

--mlock: reducir intercambio de memoria

1

--mlock

Si la memoria del sistema es relativamente amplia, este parámetro intenta mantener el modelo residente en memoria física y evitar que el sistema lo mande a swap o pagefile lento.

En modo de descarga híbrida, algunas capas quedan en RAM. Si esas páginas se intercambian fuera, la respuesta puede volverse muy lenta o entrecortada. --mlock reduce ese riesgo.

Dos advertencias:

• En Linux puede requerir ajustar ulimit -l o permisos.
• En Windows no siempre hace falta activarlo por defecto. Primero arranca el modelo.

Si --mlock impide el arranque, elimínalo. Es una optimización de estabilidad y velocidad, no un requisito.

-t 8: no subir hilos CPU a ciegas

1

-t 8

-t controla el número de hilos CPU. En descarga híbrida, las capas que no entran en VRAM necesitan participación de CPU, así que los hilos afectan la velocidad.

Usa el número de núcleos físicos, no de hilos lógicos:

Más hilos no siempre es mejor. Demasiados pueden empeorar planificación, ancho de banda de memoria y respuesta del escritorio. Empieza con núcleos físicos y ajusta con tokens/s reales.

Sobre -p "<|think|>\n"

El script original incluía:

1

-i -p "<|think|>\n"

Conviene usarlo con cuidado. Distintos modelos, conversiones GGUF y plantillas tratan los thinking markers de forma distinta. Forzar <|think|> en el prompt no activa de forma fiable “pensamiento profundo” y puede contaminar el formato de salida.

Lo más seguro al principio es solo activar modo interactivo:

1

-i

Si la model card del GGUF de Gemma 4 indica que hace falta un system prompt o token especial, añádelo según esa documentación. No trates un marcador concreto como interruptor universal.

Primera ejecución conservadora

Si te preocupa la estabilidad con 8GB de VRAM, empieza con un script más conservador:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#!/usr/bin/env bash
set -e

MODEL_PATH="./models/gemma-4-12b-it-Q4_K_M.gguf"

./llama-cli \
  -m "$MODEL_PATH" \
  -ngl 20 \
  -c 4096 \
  -t 8 \
  --flash-attn \
  --mlock \
  -n 512 \
  --color \
  -i

Este sacrifica contexto y capas descargadas a GPU, pero es más fácil que arranque. Cuando sea estable, vuelve hacia:

1

-ngl 26

y:

1

-c 8192

Para acelerar, cambia primero la cuantización

Si Q4_K_M solo permite descargar unas veinte capas en 8GB de VRAM, la velocidad estará limitada por CPU y ancho de banda de memoria. La mejora más directa es usar una cuantización más pequeña.

Puedes probar:

Con Q3_K_M o Q3_K_L, prueba:

1

-ngl 34

o incluso:

1

-ngl 38

Si la mayoría de capas entran en GPU, la velocidad puede mejorar bastante. Pero cuanto más baja la cuantización, más puede caer la calidad. Compara con los mismos prompts, no solo tokens/s.

El ancho de banda de memoria también importa

La descarga híbrida no es gratis. Las capas que no entran en VRAM pasan por CPU y memoria del sistema, por lo que la velocidad depende mucho del ancho de banda de memoria.

Revisa:

• Si la memoria del sistema está en doble canal.
• Si DDR5 tiene XMP / EXPO activado.
• Si hay procesos en segundo plano consumiendo mucho ancho de banda de memoria.
• Si un portátil está en modo de alto rendimiento.

Si la memoria está en canal único, la descarga híbrida será claramente más lenta. En una configuración de 8GB de VRAM, tener suficiente memoria del sistema es solo el primer paso. El ancho de banda también cuenta.

Orden de resolución de problemas

Si aparece OOM, no cambies muchos parámetros a la vez. Sigue este orden:

1. Baja contexto:

1

-c 4096

2. Baja capas descargadas a GPU:

1

-ngl 22

Si hace falta:

1

-ngl 20

3. Quita --mlock:

1

# Eliminar --mlock

4. Si --flash-attn da error, quítalo primero para confirmar si es un problema del backend:

1

# Eliminar --flash-attn

5. Cambia a un modelo cuantizado de menos bits.

Cambia un parámetro cada vez y registra tokens/s, uso de VRAM y si hay OOM. Así sabrás dónde está el cuello de botella real.

Tabla de ajuste

Lo peor con 8GB de VRAM es intentar maximizar todo de golpe. Empieza conservador y sube -ngl y -c paso a paso.

Resumen

Ejecutar Gemma 4 12B Q4_K_M con 8GB de VRAM depende sobre todo de la descarga híbrida. Empieza con -ngl 26, -c 8192, --flash-attn, --mlock y -t 8. Si hay OOM, baja primero el contexto y luego las capas GPU.

Si buscas velocidad, cambiar a Q3_K_M o Q3_K_L suele ser más efectivo que insistir con Q4_K_M. La memoria del sistema puede absorber parte de la presión de la descarga híbrida, pero la sensación real de velocidad depende de las capas descargadas a GPU, el tamaño de KV cache y el ancho de banda de memoria.