Qué modelo te cabe según tu hardware: cálculos honestos para tu RAM y GPU

El archivo que te bajas no es lo que ocupa

Te bajas un GGUF de 5,6 GB, lo lanzas y el sistema se come ~10 GB. La primera vez parece un error. No lo es.

Los pesos, el archivo, son solo una parte de la factura. Al generar texto, el modelo guarda un KV cache (las claves y valores de atención de todo lo que lleva leído) y reserva buffers de runtime. Por eso el tamaño del download y la memoria en ejecución no coinciden. Si eliges modelo por lo que pesa el fichero, te quedas sin RAM a mitad de frase.

He corrido Qwen 3.8 27B cuantizado a 4 bits. Para tareas agénticas y código es otra liga. También es el primer sitio donde se ve el truco con claridad: no decides por el tamaño del archivo, decides por el presupuesto real de memoria en marcha. El resto de esta guía es ese cálculo, sin humo.

Si no quieres gestionar modelos, cuantizaciones ni ventanas de contexto, local te va a saber a trabajo. Un 3B bien elegido para chat, o no montar nada, también es una respuesta honesta.

Cinco cosas que tienes que pillar

VRAM frente a RAM frente a memoria unificada. La VRAM es la memoria de la GPU: más rápida, más cara, más escasa. La RAM es la del sistema. Un modelo puede vivir en las dos, pero si parte se va a RAM, notas el lastre en cada token. Apple Silicon es un caso aparte: su memoria unificada la comparten CPU y GPU, lo que permite cargar modelos mayores al no tener que elegir entre una u otra; no la compares directamente con VRAM de tarjeta dedicada.

Quantization (Q4 / Q5 / Q8). Es bajarle los bits a cada peso. Q4 = 4 bits por peso. Q8 = 8 bits. Menos bits, menos memoria, algo de pérdida de calidad. Importante: un GGUF Q4 no ocupa exactamente parámetros × 4 bits; hay overhead de metadatos, tensores de embedding que suelen ir a mayor precisión y otros buffers. El archivo real siempre pesa algo más de la cuenta teórica. Para la mayoría de tareas de chat y código, Q4 frente a Q8 tiene un impacto normalmente pequeño, y el ahorro de memoria es bestial. Cuantiza antes de comprar hierro.

KV cache. Mientras genera, el modelo no recalcula todo el texto cada vez: guarda las claves y valores de atención. Esa memoria crece con el contexto que le has puesto delante. Es el asesino silencioso. El archivo no avisa. Y no todos los modelos tienen el mismo KV cache por capa: la arquitectura importa.

Contexto. Cuánto texto puede "tener en la cabeza" a la vez: 8K, 16K, 32K, 64K, 128K. Más contexto = más KV cache = más memoria. Pedir 128K "por si acaso" es la forma más tonta de quedarte sin GPU.

Offload a CPU. Cuando la VRAM no llega, una parte del modelo se ejecuta en RAM/CPU. Más lento, pero no se cae. En una GPU de 16 GB un 27B @ Q4 no entra entero: o recortas contexto, o offloadeas, o bajas de modelo.

El Qwen 3.8 27B no es un Transformer clásico: por qué importa para la memoria

La mayoría de estimaciones de KV cache asumen que todos los layers son full-attention. El Qwen 3.8 27B no funciona así. Tiene 64 capas en total, pero solo 16 son full-attention con 4 cabezas KV × 256 dimensiones por capa; las 48 restantes usan Gated DeltaNet con atención lineal y estado recurrente, lo que elimina prácticamente su contribución al KV cache. El resultado es un KV cache bastante más pequeño de lo que cabría esperar para un modelo de este tamaño.

Las cifras reales aproximadas por token:

• FP16: ~64 KiB/token
• KV Q8: ~32 KiB/token

Lo que eso significa en práctica, con KV Q8:

Ventana de contexto	KV cache aprox.
8K	~0,25 GiB
16K	~0,5 GiB
32K	~1 GiB
64K	~2 GiB
128K	~4 GiB

Los pesos en Q4_K_M pesan ~16,5 GiB reales (el formato tiene overhead; no es solo parámetros × 4 bits). A eso hay que sumar ~0,45 GiB de estado recurrente más los buffers de runtime. La memoria estructural total aproximada con KV Q8 queda así:

Ventana	Memoria estructural aprox.	Con overhead real (~0,5–1,5+ GiB)
16K	~17,5 GiB	~18–19 GiB
32K	~18 GiB	~18,5–19,5 GiB
64K	~19 GiB	~19,5–20,5 GiB
128K	~21 GiB	~21,5–23 GiB

En una GPU de 24 GB: 32K es cómodo y 64K perfectamente viable. El crecimiento del contexto es mucho más contenido que en un Transformer denso estándar del mismo tamaño aparente.

Recomendación de contexto para Qwen 3.8 27B:

• 16K: cómodo, punto de partida
• 32K: default razonable para código
• 64K: ideal para agentes largos con mucho contexto acumulado

Qué modelo te cabe según tu hardware

La tabla de abajo usa memoria total aproximada (pesos + KV cache + overhead). Para los modelos más pequeños, ventana de 8K con KV Q8. Para el Qwen 3.8 27B, las cifras reflejan su arquitectura híbrida real. Deja siempre margen para el sistema operativo y procesos en segundo plano.

Hardware	Modelo recomendado	Memoria total aprox.	Qué da de sí
8 GB RAM	Qwen3.5-0.8B / Qwen3.5-4B @ Q4	1–3,5 GiB	Chat básico, resúmenes cortos. No llega a código ni agentes.
12 GB RAM	Qwen3.5-4B @ Q4	~3,5 GiB	Chat fluido, código ligero: autocompletar, snippets, parches pequeños.
16 GB RAM	Qwen3.5-9B @ Q4	~6–7 GiB	Código decente, agentes básicos. Por debajo del umbral serio para refactors grandes.
16 GB VRAM	gpt-oss-20B @ MXFP4	16 GB de memoria requerida (12–13 GiB de checkpoint)	Mejor que el 9B; sigue por debajo del umbral para trabajo agéntico fiable. Los pesos del checkpoint pesan ~12–13 GiB, pero la memoria real en ejecución sube a ~16 GB con buffers y overhead. Requiere offload a RAM o una GPU con más VRAM para el 27B.
24 GB VRAM	Qwen 3.8 27B @ Q4_K_M	~18–20 GiB (32K)	Recomendación estrella. El sweet spot mínimo serio para código, agentes y refactorizaciones grandes. 32K cómodo, 64K viable.
32 GB+	Qwen 3.8 27B @ Q4_K_M (contexto largo) o mejor quant	~19–23 GiB	Antes de saltar a modelos más grandes, saca más partido al 27B: más contexto, mejor quantization.
48–64 GB+	Qwen3-Coder-Next u otros modelos grandes recientes @ Q4	Variable	Aquí sí tiene sentido explorar modelos más grandes. Hay opciones más actuales y competitivas que los modelos de generaciones anteriores.
Mac M4 64 GB (memoria unificada)	Modelos de 70B @ Q4	~45–50 GiB	La memoria unificada de Apple Silicon permite cargar modelos mayores al compartir RAM y GPU. Frontera en local, no un juguete.

Tramos pequeños (bajo el umbral serio): Qwen3.5-4B, Qwen3.5-9B y gpt-oss-20B son útiles para snippets, autocompletar y parches. Pero para refactorizaciones grandes, agentes autónomos y trabajo de código real, se quedan cortos. El umbral mínimo recomendable empieza en el 27B.

Cuantiza antes de comprar hardware

El Qwen 3.8 27B en Q4_K_M pesa ~16,5 GiB de pesos reales; en Q8 rondaría los ~27,1 GiB. Eso es un ahorro de memoria sustancial al bajar de Q8 a Q4, con un impacto en calidad que en la práctica es normalmente pequeño para chat, código y agentes. No es pérdida inexistente, pero tampoco es el abismo que algunos venden.

En modelos más pequeños el porcentaje es similar: un 9B pasa de ~9–11 GiB en Q8 a ~6–7 GiB en Q4, ahorrando cerca del 40% con impacto normalmente contenido.

La regla práctica es tozuda: si no te cabe en Q8, prueba Q4_K_M antes de plantearte comprar más hardware. Comprar una GPU para poder correr Q8 "por si acaso" es el atajo caro.

El KV cache te come la máquina en silencio (pero menos de lo que crees en el 27B)

La arquitectura híbrida del Qwen 3.8 27B cambia la ecuación. Con KV Q8, pasar de 16K a 64K añade solo ~1,5 GiB de cache. Es un comportamiento muy distinto al de un Transformer denso del mismo tamaño aparente.

Lo que sí sigue siendo verdad para cualquier modelo:

• Cuantizar el KV cache a 8-bit ahorra mucha memoria con un impacto en calidad normalmente muy pequeño. No es magia, pero la relación coste/beneficio es de las mejores que hay en optimización local.
• No pidas 128K porque queda bonito en la ficha técnica. En modelos sin esta arquitectura híbrida, escala de forma agresiva.
• La ventana de contexto que usas de verdad en tus tareas es la que importa. Un agente de código raramente necesita más de 32–64K de forma sostenida.

Si tu tarea es chat casual o snippets cortos, 16K sobra y te ahorra memoria para el resto del sistema. Si es un agente que acumula contexto durante una sesión larga, 32–64K es el rango honesto para el 27B.

Con qué lo lanzas

llama.cpp es el estándar en CPU y en Apple Silicon. Come GGUF, es el que menos teatro monta y el que más perdona un PC normal.

vLLM es otra historia: servidores y GPU potentes, más throughput, más piezas. Si estás solo en el salón con una 3060, no empieces aquí.

Ollama envuelve llama.cpp y te deja en marcha con menos fricción. Es la puerta de entrada decente. Cuando ya sepas qué modelo te cabe, pásate a llama.cpp directo: te da control fino sobre cuantización, contexto y offload a pelo.

La elección no es de marca, es de sitio: portátil / Mac → llama.cpp u Ollama. Caja con GPU gorda y varios usuarios → vLLM.

Comprueba tu máquina en runthisllm.com

Los números de arriba son la base. Tu máquina no es una fila de tabla: depende de cuánta VRAM tienes de verdad, de si compartes memoria (Apple Silicon), de qué deja libre el sistema operativo. Entra en runthisllm.com, mete tu hardware y mira qué te recomienda. La herramienta es orientativa; si choca con esta guía, fíate del cálculo (pesos + KV cache + contexto + overhead) y deja margen.

Tres anclas para no ir a ciegas:

• RTX 3060 12 GB. Los modelos de hasta ~8–9B @ Q4 entran bien. El 27B no entra entero: necesitas offload a RAM. Útil para explorar, malo como plan si el código y los agentes son el trabajo de cada día.
• RTX 3090 / 4090 24 GB VRAM. El Qwen 3.8 27B @ Q4_K_M es la recomendación estrella aquí. A 32K de contexto (con KV Q8) entra cómodo; a 64K, perfectamente viable. No abras Chrome con 40 pestañas a la vez, pero no es el equilibrio al límite que parecía con las estimaciones de un Transformer denso estándar.
• Mac M4 64 GB (memoria unificada). El 70B @ Q4 cabe en un Mac M4 de 64 GB. La memoria unificada de Apple Silicon no equivale directamente a VRAM de tarjeta dedicada: permite cargar modelos mayores al compartir RAM y GPU, con una gestión más flexible que en un PC con GPU discreta. Frontera en local, no un juguete de 8 GB.

Mide el techo, despliega lo barato

Mide el techo con el mejor modelo, despliega el más barato que aguante la tarea.

No uses un 70B para resumir un email. No uses un 27B para titular un párrafo. Prueba arriba para saber qué aspecto tiene "bien hecho" y bájate al más pequeño que aguante ese listón.

Un 3B o un 7B resuelven el chat casual y los snippets sencillos. Para código serio, agentes y refactorizaciones grandes, el mínimo recomendable es el Qwen 3.8 27B @ Q4_K_M: conserva muy bien la calidad respecto a Q8, y su arquitectura híbrida con Gated DeltaNet lo hace mucho más eficiente en memoria de lo que su tamaño sugiere. Por debajo de ese umbral, en trabajo agéntico real, te quedas corto.

Si estás eligiendo entre tres nombres que "salen bien en el bench", aplica una checklist anti-hype a la tarea real: un refactor, un ticket, un resumen tuyo, no al leaderboard.

Lo que de verdad cuesta el hardware

En CPU only, un 27B @ Q4 funciona si tienes RAM suficiente. Va lento. El coste es la memoria, no una GPU. Para empezar sin comprar nada: Qwen3.5-4B @ Q4 (~3,5 GiB) y a ver si la tarea sobrevive. Si sobrevive, no compres.

GPU de 24 GB: una RTX 3090 usada ronda 500–600€; una 4090, ~1.500€. Con cualquiera de las dos, el Qwen 3.8 27B @ Q4_K_M entra y responde fino a 32K, y tiene margen razonable hasta 64K. GPU de 16 GB: el 27B no entra entero. Offload a RAM. Útil para probar, malo como plan principal si el código y los agentes son el trabajo de cada día.

El coste real no es solo la tarjeta. Quien compra 24 GB y luego abre 128K a 16-bit en un Transformer denso está pagando dos veces. Con el Qwen 3.8 27B y su arquitectura híbrida, ese problema es mucho menor, pero la lógica de fondo no cambia: el contexto que usas de verdad es el que manda.

Si vas a entrar ahora, no empieces por la 4090. Empieza por CPU y un modelo pequeño. Si el cuello es código o agentes, sube al 27B @ Q4_K_M y, si la VRAM no llega, una 3090 usada es el camino más razonable. El techo se mide una vez; el despliegue, cada día.

Preguntas frecuentes

¿Cuánta memoria necesita el Qwen 3.8 27B para correrlo en local?

Los pesos en Q4_K_M pesan ~16,5 GiB reales (hay overhead; no es solo parámetros × 4 bits), más ~0,45 GiB de estado recurrente y buffers. Con KV Q8, el cache añade ~0,5 GiB a 16K, ~1 GiB a 32K y ~2 GiB a 64K. En total: ~18–19 GiB a 32K con overhead, ~19,5–20,5 GiB a 64K. En una GPU de 24 GB, el 32K es cómodo y el 64K perfectamente viable.

¿Es mejor Q4 o Q8 para un modelo local?

Q4_K_M, si el objetivo es que te quepa con margen. En la mayoría de tareas de chat, código y agentes, el impacto en calidad es normalmente pequeño y el ahorro de memoria es sustancial: en un 27B, pasar de Q8 a Q4 libera más de un tercio de la memoria. Q4 no es pérdida inexistente, pero tampoco es degradación severa para uso habitual. Cuantiza antes de comprar hardware.

¿Puedo ejecutar un modelo de 27B solo con CPU?

Sí, si tienes RAM de sobra. El Qwen 3.8 27B @ Q4_K_M a 32K pide ~18–19 GiB en total y en CPU funciona, lento. Para código o agentes de cada día, una GPU de 24 GB (una RTX 3090 usada ronda 500–600€) lo deja cómodo a 32K y con margen a 64K.

¿Por qué un GGUF de 5,6 GB acaba ocupando mucho más en ejecución?

Porque el archivo son los pesos cuantizados (con su propio overhead de formato), y al ejecutarse aparecen el KV cache y los buffers de runtime. El cache guarda las claves y valores de atención de todo el contexto activo y crece con la ventana que pides. Además, los GGUF Q4 no pesan exactamente parámetros × 4 bits: hay metadatos, tensores de embedding a mayor precisión y otros factores. No elijas modelo por lo que pesa el download.