IA en local: qué significan 7B, Q4, cuantización y cuánto hardware necesitas realmente

Si estás empezando a meterte en el mundo de los modelos de IA en local, seguramente ya te chocaste con nombres como qwen3:8b, gemma3:27b-it-q4_K_M o deepseek-r1:14b-q8_0 y te quedaste igual que al inicio.

Los números y las letras no son decoración: te están diciendo qué tan grande es el modelo, qué tan comprimido está y, de forma indirecta, si te va a entrar en tu máquina o no.

En este artículo vamos a desarmar esos términos y, sobre todo, vamos a ver la regla práctica para calcular cuánta memoria necesitas antes de descargarte 20 GB para nada.

Primero: ¿qué significa "IA en local" en la práctica?

"IA en local" es un término bastante genérico y cada persona lo entiende distinto según lo que hace:

• Si programas, probablemente lo enfocas a generar código.
• Si quieres un ChatGPT propio (personal o para la empresa), lo enfocas a chat.
• Si automatizas cosas, lo enfocas a tener un asistente o agente que ejecute tareas.

Más allá del enfoque, siempre vas a necesitar tres piezas:

1. El modelo — los pesos que vas a descargar y ejecutar.
2. El harness — el programa que usa ese modelo y le da forma útil a la respuesta (un editor de código, una interfaz de chat, un agente de terminal).
3. El hardware — la parte pesada, la que cuesta dinero y la que hay que saber configurar.

El punto 2 parece trivial, pero importa más de lo que crees: los modelos son muy genéricos y muchos harnesses o son cerrados o simplemente no contemplan modelos abiertos. No todo lo que existe va a funcionar con el modelo que descargaste.

Y el punto 3 es donde todo el mundo se atasca, así que empecemos por ahí.

El hardware: tres escenarios reales

1. GPU de consumo (una sola tarjeta)

Es el caso de la mayoría. Si ya editas video, juegas o haces trabajo pesado, probablemente tienes una gráfica decente: una 3090, 4090, 5090 o similar.

Sirve perfectamente para ejecutar un modelo de vez en cuando, para tareas puntuales y para no pagar suscripciones eternas. La limitación no es la potencia bruta, es la VRAM: 24 GB marcan un techo bastante claro de qué modelos te entran.

2. Clúster de GPUs

Aquí ya combinas varias tarjetas. Es el camino más potente, pero también el más caro y el más trabajoso: no es solo conectarlas, es alimentación, soporte físico, refrigeración y configurarlas para que funcionen como un solo sistema. Básicamente estás armando un mini data center.

Es un escenario especializado. La gran mayoría no está aquí, y está bien.

3. AI workstations con memoria unificada

Es la categoría que creció más rápido en el último tiempo: Mac Studio / Mac Mini, DGX Spark, y las versiones equivalentes que están sacando AMD e Intel.

La característica común es la memoria unificada: en lugar de tener RAM por un lado y VRAM por otro, hay un solo pool de memoria compartida y de gran tamaño. Como el enfoque de estos equipos es justamente ejecutar modelos, priorizan darte mucha memoria antes que máximo rendimiento por core.

Es la entrada más simple: no compras una tarjeta, compras un equipo que ya viene pensado para esto.

El modelo: open weight no es lo mismo que open source

Este es probablemente el malentendido más común.

Los modelos más usados hoy son cerrados: GPT, Claude, Gemini. Son de una empresa, se consumen por suscripción o API y no los puedes descargar.

Del otro lado están los open weight: Qwen, DeepSeek, GLM, Kimi, Llama, Mistral, Gemma. Estos laboratorios publican los pesos, es decir, los datos ya entrenados. Tú puedes:

• descargarlos,
• ejecutarlos en tu propia infraestructura,
• y hacerles fine-tuning.

¿Por qué entonces no se les llama open source? Porque no te dan el pipeline completo: no publican los datos con los que fueron entrenados ni todo el proceso de cómo se construyeron. Te entregan el resultado, no la receta.

Y hay un detalle extra: algunos modelos tienen licencias con restricciones. Llama, por ejemplo, tiene límites de uso para empresas por encima de cierto número de usuarios. Eso no pasa en el open source real.

Para un usuario normal que quiere ejecutar un modelo en su computadora, en la práctica no hay ningún problema: puedes ejecutar prácticamente cualquier modelo open weight que encuentres.

Dato para no repetir el error: no todos los open weight son chinos. Qwen (Alibaba), DeepSeek, GLM y Kimi sí lo son, pero Llama es de Meta, Mistral es francés y Gemma es de Google.

El harness: el programa que realmente usas

Una vez tienes el modelo, necesitas algo que lo use. Depende del trabajo:

• Código: OpenCode y proyectos similares te permiten conectar modelos locales a un flujo de desarrollo real.
• Agentes de terminal / web: hay varios proyectos que corren como agente y aceptan endpoints locales.
• Chat tipo ChatGPT: Open WebUI o LibreChat. Descargas la interfaz, la apuntas a tu modelo y listo.

El harness no cambia la calidad del modelo, pero sí cambia muchísimo qué tan útil se siente.

La parte importante: ¿cuánta memoria necesito?

No existe una regla exacta, pero sí una regla práctica que funciona muy bien para orientarte:

Memoria ≈ (parámetros × bytes por parámetro) + overhead + KV cache

Vamos parte por parte.

Parámetros (la "B")

La B significa billions en inglés, o sea miles de millones de parámetros. Es la forma de decirte qué tan grande es el modelo.

Cuando salió Llama, los tamaños de referencia fueron 7B, 13B, 33B y 65B, y esa referencia todavía sirve para hacerse una idea:

Es solo una referencia: en la práctica vas a encontrar 4B, 9B, 12B, 27B, 30B y muchos otros. Pero sirve para entender la lógica: los laboratorios lanzan tamaños pensando en dónde los vas a poder ejecutar.

Bytes por parámetro (la cuantización)

Cada parámetro se guarda con una precisión numérica determinada. Ahí entran las siglas raras.

Modelos en precisión completa:

• FP32, FP16, BF16 → mayor precisión numérica. Están pensados para entrenar o hacer fine-tuning. Para un usuario normal son casi irrelevantes porque pesan muchísimo.

Modelos cuantizados:

• Q8 → 8 bits por parámetro = 1 byte
• Q4 → 4 bits por parámetro = 0.5 bytes
• Q3, Q2 → aún más comprimidos

Piénsalo como un modelo comprimido: pierdes algo de precisión, pero entra en equipos con recursos limitados. Y esto es lo que la gran mayoría de usuarios realmente necesita.

Recuerda: 1 byte = 8 bits. De ahí sale toda la aritmética.

¿Se degrada mucho la respuesta al bajar de Q8 a Q4? Los benchmarks muestran que sí se degrada, pero no de forma dramática. Un Q4 sigue siendo perfectamente utilizable para la mayoría de tareas. Lo ideal es un Q8 con un tamaño decente de parámetros, pero si tu hardware no da, un Q4 te va a funcionar bien en la práctica.

Overhead

Es la memoria extra que el modelo necesita más allá de sus pesos: buffers de activación, el propio runtime, etc.

Regla práctica: entre 10% y 20% adicional sobre el tamaño del modelo.

KV cache

Cuando el modelo responde, guarda en memoria el procesamiento de los tokens anteriores para no recalcular todo en cada turno. Eso es el KV cache, y también ocupa memoria.

Cuánto depende del contexto que quieras soportar: mientras más tokens de contexto, más caché. Para contextos modestos puedes pensar en 1-2 GB extra; si quieres duplicar el contexto, más o menos duplica ese número.

Ejemplo completo: un modelo de 27B

Supongamos que quieres ejecutar un modelo de 27B.

En Q8 (1 byte por parámetro):

27 × 1 = 27 GB (solo los pesos)
+ 15% de overhead ≈ 4 GB
+ KV cache ≈ 2 GB
─────────────────────────
≈ 33 GB

Es decir: no te entra en una 4090.

En Q4 (0.5 bytes por parámetro):

27 × 0.5 = 13.5 GB (solo los pesos)
+ 15% de overhead ≈ 2 GB
+ KV cache ≈ 2 GB
─────────────────────────
≈ 17.5 GB

Ahora sí: entra cómodamente en 24 GB de VRAM.

Ese cálculo, hecho en 30 segundos, te ahorra descargar 27 GB para descubrir que no arranca.

El detalle que casi nadie explica: Q4_K_M

Si entras a Ollama y revisas un modelo, vas a ver etiquetas como q4_K_M o q4_K_S. Esa K_M no es adorno.

Significa que no son 4 bits exactos, sino precisión mixta: algunas capas del modelo (las más sensibles) se guardan con más bits que otras. En la práctica, un Q4_K_M termina pesando el equivalente a unos 4.8 – 5 bits por parámetro, no 4.

Rehagamos el cálculo del 27B con eso:

27 × 0.6 ≈ 16 GB
+ overhead ≈ 3 GB
+ KV cache ≈ 2 GB
─────────────────
≈ 21 GB

Que es exactamente el orden de magnitud que ves reportado en la página del modelo. Ahora ya sabes de dónde sale ese número.

Las herramientas, ordenadas por dificultad

Esta es la escalera que yo recomendaría seguir:

1. LM Studio — el más fácil

Interfaz gráfica, catálogo de modelos listos para descargar, y te indica los tamaños y si te entra en tu equipo. Ideal si no quieres tocar la terminal ni entender qué pasa por debajo. Es literalmente descargar y chatear.

2. Ollama — el punto dulce

Es lo más práctico para aprender de verdad. Los modelos vienen preconfigurados con sus parámetros ya definidos, así que instalas y funciona. Pero si quieres ir variando el tamaño, la cuantización o el contexto, tienes el Modelfile, donde defines el modelo junto con sus parámetros.

3. llama.cpp — control total

Es el motor de inferencia que Ollama usa por debajo. Aquí ejecutas comandos y configuras a mano todo lo que vimos: cuantización, contexto, capas en GPU, overhead. Es más trabajoso, pero es donde realmente juegas con las métricas y encuentras la configuración óptima para tu hardware.

4. vLLM — despliegue y concurrencia

Este ya es otro caso de uso. Si quieres servir un modelo — por ejemplo, una aplicación tipo ChatGPT donde múltiples personas se conectan al mismo modelo desplegado en un servidor — no usas llama.cpp, usas vLLM. Está optimizado para usuarios concurrentes, no para que tú chatees solo con tu modelo.

Resumido:

Una expectativa honesta sobre la calidad

Hay que decirlo claro: un modelo que corre en tu 4090 no va a igualar a un modelo frontier desplegado en la nube. Es cuestión de números.

Ahora, para las tareas comunes de todos los días — desarrollo web, un chat sencillo, resúmenes, automatizaciones simples — estos modelos rinden sorprendentemente bien. La limitación se nota cuando subes el nivel: análisis complejos, documentos largos, razonamiento de varios pasos.

Así que la pregunta correcta no es "¿es tan bueno como Claude o GPT?", sino "¿es suficientemente bueno para lo que yo hago, corriendo gratis en mi máquina?". Para muchísimos casos, la respuesta es sí.

Resumen

Cuando trabajes con modelos locales, solo necesitas tener claras tres cosas:

1. Los pesos — qué modelo y de qué tamaño (la B).
2. El hardware — cuánta memoria tienes realmente disponible.
3. El programa — LM Studio, Ollama, llama.cpp o vLLM según tu nivel y tu objetivo.

Y una fórmula que te ahorra descargas inútiles:

Memoria ≈ (parámetros × bytes) + 10-20% overhead + KV cache

Con eso ya puedes entrar a cualquier catálogo de modelos, mirar los nombres raros y saber exactamente qué estás viendo.

En próximos artículos y videos voy a cubrir llama.cpp y vLLM con ejemplos prácticos, que son los dos que me quedan pendientes. LM Studio y Ollama ya los publiqué antes en el canal.

Si tienes una duda o quieres que profundice en alguno de estos puntos, déjamelo en los comentarios.