IA en tu ordenador con una tarjeta gráfica antigua: qué se puede hacer y qué no

Con una tarjeta gráfica antigua puedes usar IA en local, pero con modelos pequeños y cuantizados, no con los que salen en las noticias. Lo que decide es la memoria: un modelo de 8.000 millones de parámetros comprimido a 4 bits ocupa unos 4,6 GiB, así que entra en una gráfica de 6 u 8 GB, mientras que los grandes piden decenas o cientos de gigas. Con llama.cpp u Ollama lo pones en marcha, y si la gráfica se queda corta, el modelo se reparte entre la gráfica y la RAM del ordenador, más despacio.

La cuenta que manda: cuánto ocupa el modelo

Un modelo de lenguaje es, sobre todo, un fichero enorme de números (los pesos). La documentación de cuantización de llama.cpp lo dice sin rodeos: los modelos se cargan enteros en memoria, y por ahora la memoria que piden es la misma que ocupan en disco. Si el fichero pesa 5 GB, necesitas 5 GB libres y algo más.

Ese «algo más» es el contexto, la conversación que el modelo tiene presente mientras te contesta. Ollama arranca con una ventana de 4.096 tokens y guarda esa caché en 16 bits salvo que le digas otra cosa. Cuanto más largo, más memoria come, y un modelo que «cabe justo» puede dejar de caber cuando le pegas un documento largo.

Y hay dos memorias. La VRAM es la de la tarjeta gráfica, rápida y escasa. La RAM es la del sistema, más abundante y más lenta para esto. Lo ideal es que el modelo quepa entero en la VRAM.

Cuantización en llano: qué quieren decir Q4 y Q8

Cuantizar es guardar cada peso del modelo con menos bits. El original suele ir en 16 bits por peso. Una versión Q8 usa unos 8 bits, y una Q4, entre 4 y 5. El fichero adelgaza mucho y a cambio puede perder algo de precisión, que llama.cpp mide con indicadores como la perplejidad.

La tabla que publica llama.cpp para Llama 3.1 de 8.000 millones de parámetros:

Formato	Bits por peso	Tamaño
F16 (sin cuantizar)	16,0	14,96 GiB
Q8_0	8,5	7,95 GiB
Q4_K_M	4,89	4,58 GiB
IQ2_XXS	2,38	2,23 GiB

Q4_K_M es la etiqueta que vas a ver por todas partes, y es la que usa la propia guía de llama.cpp en sus ejemplos. Yo la tomaría como punto de partida. Las de 2 y 3 bits adelgazan todavía más, pero yo no las usaría sin comparar antes sus respuestas con las de una versión mayor, con tus propias preguntas.

Todo esto va empaquetado en GGUF, el formato de fichero que creó el autor de llama.cpp y que Hugging Face describe como un formato binario pensado para cargar y guardar modelos rápido. Si buscas un modelo para tu gráfica, busca la versión GGUF. Vas a ver otros nombres, como AWQ, FP8, FP4 o EXL3, que son cuantizaciones para otros motores, como vLLM o ExLlamaV3. En un PC normal, GGUF.

Qué gráfica tienes y qué te deja hacer

Ollama admite gráficas NVIDIA con «compute capability» 5.0 o superior, lo que incluye las GTX 750 Ti, la serie 900 y las GTX 1050 a 1080 Ti, aunque las de 5.0 a 6.2 piden el controlador 570 o posterior. En AMD la lista oficial con ROCm es más corta, y para el resto tira de Vulkan. llama.cpp tiene motores para CUDA, AMD (HIP), Vulkan, Intel (SYCL) y Metal.

Con la tabla de arriba puedes hacer la cuenta. Así lo veo yo, contando el tamaño del fichero como mínimo:

• Con 4 GB de VRAM vas justo. Hasta el Gemma 4 más pequeño de Ollama, el E2B en Q4_K_M, ocupa 4,6 GB, así que irá repartido entre la gráfica y la RAM.
• Con 8 GB, un modelo de unos 8.000 millones en Q4_K_M, como el Llama 3.1 de la tabla (4,58 GiB), con algo de margen para el contexto. Con 6 GB, más apretado.
• Con 12 GB o más, ya puedes subir a Q8 en esos mismos modelos (7,95 GiB) o probar algo mayor en Q4.
• Los modelos de 70.000 millones, ni soñarlo: la misma tabla de llama.cpp da 43,1 GB para Llama 3.1 70B en Q4_K_M.

Es orientativo. Cada modelo tiene su arquitectura y el contexto cambia mucho la cuenta.

CPU frente a GPU, y el reparto entre las dos

Si el modelo no cabe en la gráfica, no está todo perdido. llama.cpp hace inferencia híbrida: mete en la GPU las capas que caben y deja el resto en la CPU y la RAM, para «acelerar parcialmente modelos mayores que la VRAM total», en palabras del proyecto. Ollama hace ese reparto solo, y con ollama ps te dice cómo ha quedado. Si pone 100% GPU, está entero en la gráfica. Si pone algo como 48%/52% CPU/GPU, está partido.

Y también puedes tirar solo de procesador. llama.cpp aprovecha las instrucciones AVX, AVX2 y AVX512 de los procesadores x86, así que funciona en un portátil sin gráfica dedicada. Lo que no te puedo dar es una cifra de velocidad para tu equipo, porque depende de demasiadas piezas, y no me fío de las que circulan sin decir en qué máquina se midieron.

Apple Silicon: la memoria unificada cambia la cuenta

En un Mac con chip M la separación entre VRAM y RAM no existe. Apple lo explicó al presentar el M1: memoria unificada, un único bloque de memoria al que acceden la CPU y la GPU sin copiar datos entre ellas. Para la IA local eso quiere decir que la gráfica tira de la memoria del equipo, y un Mac con 16 GB tiene más sitio para el modelo que un PC con una gráfica de 4 GB.

llama.cpp trata Apple Silicon como «ciudadano de primera» y usa Metal, y Ollama también acelera con Metal. Apple tiene su propio marco, MLX (licencia MIT), y en la biblioteca de Ollama ya aparecen variantes MLX de algunos modelos. Eso sí, la memoria la compartes con el sistema y con lo que tengas abierto, así que no cuentes con usarla toda.

Hasta dónde se estira: dos proyectos que no son para tu ordenador

vllm-backport (licencia Apache-2.0) es una copia modificada de vLLM, otro motor para servir modelos, pensada para correr modelos punteros en «tarjetas más antiguas como la A6000, la 3090 y la A100». Antiguas para un centro de datos, claro. La configuración que el propio README da por verificada para GLM-5.3-Flash usa cuatro A100 de 80 GB, y para la alternativa con ocho RTX A6000 habla de tarjetas de 48 GB. El repositorio se presenta como «dogfooding», que en la jerga quiere decir que sus autores lo usan para su propio trabajo. Yo lo leo como experimental, sin promesas de estabilidad para nadie más.

GLM-5.3-Flash-EXL3-2x-DGX-Sparks es una receta para servir el modelo GLM-5.3 Flash repartido entre dos, tres o cuatro NVIDIA DGX Spark. Los pesos, ya cuantizados a 4 bits en formato EXL3, ocupan unos 164 GiB. Un DGX Spark no es un ordenador normal. Según NVIDIA, es un equipo de sobremesa construido alrededor del chip GB10 Grace Blackwell, con 128 GB de memoria unificada (hay una versión de 64 GB a través de fabricantes asociados), su propio sistema DGX OS y una tarjeta de red ConnectX con la que se enlazan hasta cuatro. NVIDIA dice que uno solo mueve modelos de hasta 200.000 millones de parámetros, y dos enlazados, con 256 GB, hasta 400.000 millones. Como 164 GiB no caben en 128 GB, hacen falta dos.

El README publica sus propias medidas en dos Spark, entre 36 y 83 tokens por segundo de generación con la configuración por defecto, según el tipo de texto. Son cifras de los autores, no mías. Y la licencia tiene miga. El código va con AGPL-3.0, que en llano quiere decir que si lo modificas y lo ofreces como servicio a otros por la red, tienes que darles también el código fuente. El modelo de borrador DFlash2 que usa para acelerar va con CC BY-NC-ND 4.0, que no admite uso comercial. Y el propio README avisa de que hay una versión mejorada, el repositorio con sufijo TensorFold, que va con Apache-2.0.

Los dos sirven para ver hasta dónde llega la técnica. Para tu GTX 1060 no cambian nada.

Cuándo compensa y cuándo no

Compensa si ya tienes la gráfica y quieres algo concreto: resumir o clasificar textos que no quieres sacar de tu equipo, trabajar sin conexión, o aprender cómo funciona esto por dentro. Ahí un modelo pequeño a 4 bits da para bastante, y pagas la luz. Si quieres echar números, aquí va cómo medir el consumo eléctrico del ordenador.

No compensa si buscas la calidad de los asistentes grandes. Un modelo de 8.000 millones en tu tarjeta no se parece a lo que te contesta un servicio en la nube, y comprar una gráfica solo para acercarte sale caro y sigue lejos. Para el uso diario, las versiones gratuitas de los asistentes cubren más, y lo cuento en qué puedes hacer gratis con ChatGPT, Gemini, Claude y Copilot.

Si te pica la curiosidad, yo empezaría por Ollama, que es lo más directo: lo instalas, eliges un modelo pequeño de su biblioteca y miras con ollama ps si ha cabido en la gráfica. Si quieres más control sobre la cuantización o el reparto de capas, llama.cpp. Los dos son libres, con licencia MIT. Y si quieres ver qué más se mueve por GitHub, tienes esta selección de repositorios.