GGUF, cuantización y VRAM: calcula la memoria para ejecutar modelos locales

La cuantización reduce los pesos, pero no toda la memoria necesaria

La cuantización representa los pesos de un modelo con menos precisión numérica para reducir el espacio que ocupan y, en algunos equipos, acelerar la inferencia. En GGUF encontrarás nombres como Q4_K_M, Q5_K_M o Q8_0. Son pistas sobre la cuantización, no una especificación completa del uso de memoria ni una garantía de calidad o velocidad.

El formato GGUF es un contenedor de modelo usado habitualmente con llama.cpp y herramientas basadas en ese motor. No es sinónimo de cuantización: puede contener pesos en distintos tipos y niveles de precisión. Tampoco «Q4» significa que cada parámetro ocupe exactamente cuatro bits. Los metadatos, las escalas y las partes guardadas con otra precisión añaden tamaño. Por eso, si está disponible, conviene consultar el tamaño real del archivo cuantizado que se va a cargar.

Para dimensionar un despliegue hay que separar al menos cuatro partidas: pesos, caché de claves y valores (KV), memoria temporal de cálculo y sobrecarga del motor. La suma depende de la arquitectura del modelo, el contexto, el lote, la distribución entre dispositivos y el software. Un cálculo basado solo en parámetros puede descartar una configuración que sí cabe, o dar por viable una que fallará al reservar memoria para la conversación.

La primera decisión no es «¿qué GPU es mejor?», sino «¿qué modelo, contexto, concurrencia y latencia necesito?». A partir de ahí se estima la memoria y se prueban configuraciones compatibles. Para comparar motores o modelos distintos, consulta una comparativa y define una carga de trabajo común; para explorar alternativas de inferencia local, organiza la búsqueda por tarea y hardware disponible.

Qué expresa Q4_K_M, Q5_K_M y Q8_0

En términos generales, cuantizar significa reducir la precisión con que se almacenan los pesos. El beneficio esperado es menor memoria para esos pesos; el coste posible es que las respuestas se alejen de las del modelo de referencia. La relación no es idéntica para todos los modelos, ni se puede resumir de forma responsable en un porcentaje fijo de pérdida.

En las variantes GGUF, el número indica una clase de cuantización, pero no toda la composición del archivo. Los sufijos distinguen métodos y asignaciones de precisión. En nombres como Q4_K_M, la familia K y la variante M forman parte del esquema; no deben interpretarse como un simple multiplicador uniforme de cuatro bits. El tamaño del archivo es un dato más fiable que deducir bytes exactos solo por el nombre.

Como guía cualitativa, una configuración Q4 suele requerir menos espacio para los pesos que una Q5 o Q8 del mismo modelo. A cambio, Q5 y Q8 conservan más precisión en los pesos, pero consumen más memoria. Eso no demuestra que vayan a responder mejor en toda tarea: hay que medir en la aplicación concreta. Un clasificador, un generador de código y un chat general pueden reaccionar de manera diferente a la misma cuantización.

GGUF también permite elegir formatos de cuantización distintos para una misma familia de modelos, pero la compatibilidad depende del motor y de la implementación. No asumas que dos archivos con etiquetas parecidas se ejecutan igual de rápido o producen los mismos resultados. Comprueba que el modelo esté preparado para el motor, que se haya cargado el backend esperado y que la evaluación compare la misma revisión del modelo.

Calcula por separado pesos, caché KV y margen

Para una primera aproximación, el tamaño de los pesos residentes puede estimarse a partir del archivo de modelo realmente cargado. Si solo se conoce el número de parámetros, una cuenta orientativa es parámetros multiplicados por bytes medios por parámetro; pero el valor medio debe corresponder a la cuantización real, no al número del nombre usado como si fuera exacto. En GGUF, la mezcla de precisiones hace que esa simplificación pueda desviarse.

La caché KV conserva información de tokens previos que el modelo necesita durante la generación. Su tamaño suele crecer con la longitud de la secuencia y el tamaño del lote, y depende de la arquitectura: capas, cabezas KV, dimensión de cabeza y tipo de dato de la caché. Una forma general de expresarla es: dos veces el número de capas, multiplicado por cabezas KV, dimensión de cabeza, tokens almacenados, lote y bytes por elemento. La fórmula se debe adaptar a la implementación y a arquitecturas que usen mecanismos de atención distintos.

Para obtener las dimensiones pertinentes, consulta la configuración del modelo y la documentación del motor, en lugar de inferirlas únicamente del número de parámetros o de las cabezas de consulta. En atención agrupada, las cabezas KV pueden ser menos numerosas que las cabezas de consulta; por tanto, calcular como si cada cabeza de consulta tuviera su propia caché puede sobreestimar el resultado. Otros diseños pueden necesitar una fórmula diferente.

La memoria temporal y la sobrecarga no equivalen a un porcentaje fijo de los pesos. El prellenado de prompts largos puede requerir buffers mayores que la generación token a token. También influyen la fragmentación, el backend, la reserva de memoria, las bibliotecas y el número de GPU. La estimación de AIMultiple separa pesos, KV, activaciones y sobrecarga; es útil como estructura de cálculo, pero sus resultados deben contrastarse con el modelo, el motor y la configuración exactos.

No existe una respuesta verificable única a «¿cuánta VRAM necesita un 7B Q4_K_M con 4096 tokens?» sin especificar modelo, lote, tipo de KV, motor, distribución y margen. El contexto de 4096 indica la longitud de secuencia, pero no define por sí solo la caché: faltan dimensiones de arquitectura y otros detalles. El tamaño del archivo puede ofrecer una base para los pesos, no el total requerido.

Elegir entre VRAM, RAM y descarga parcial

La VRAM disponible establece cuánto puede residir en la GPU, mientras que la RAM del sistema puede servir para cargar partes del modelo cuando el motor admite descarga parcial. Pero tener mucha RAM no convierte automáticamente una configuración en una experiencia interactiva: mover datos entre RAM y GPU puede reducir el rendimiento, y el resultado depende del enlace entre ambos y de cómo se distribuyan las capas.

Si la carga requiere respuesta rápida y repetida, prioriza que los pesos y la caché activa quepan en memoria de GPU con margen. Si el objetivo es ejecutar un modelo que de otro modo no cabría, acepta que la descarga a RAM puede ser una solución de capacidad con un coste de latencia. No confundas «se carga» con «cumple el requisito de velocidad».

En Apple Silicon, la memoria unificada es compartida por CPU y GPU, pero el sistema y otras aplicaciones también la usan. La RAM instalada no equivale necesariamente a memoria disponible para el modelo. En equipos con varias GPU tampoco basta con sumar sus capacidades: hay costes de comunicación y reservas por dispositivo, y el software debe soportar el reparto previsto.

El ancho de banda afecta especialmente a la generación, cuando se leen pesos de forma reiterada. La capacidad responde a si los datos caben; el ancho de banda y la implementación contribuyen a la velocidad una vez cargados. El motor, el soporte de kernels, el tipo de cuantización y la concurrencia pueden alterar el resultado, por lo que elegir hardware solo por VRAM o por una cifra teórica de ancho de banda deja fuera factores decisivos.

La configuración de 7B Q4 y 4096 tokens no tiene un mínimo universal

Un modelo de 7.000 millones de parámetros en Q4_K_M suele ocupar menos memoria de pesos que la misma familia en Q5 o Q8, pero no puede convertirse ese principio en una cifra mínima universal de VRAM o RAM. Los parámetros no describen completamente la arquitectura, los tensores que conservan otra precisión ni el tamaño exacto del archivo.

Los 4096 tokens tampoco bastan para calcular la caché. Para estimarla hacen falta, como mínimo, la arquitectura, el número de capas, las cabezas KV, la dimensión por cabeza, el tipo de dato de KV y el lote. Si se usa una ventana de atención o un mecanismo distinto, el cálculo cambia. La respuesta responsable es medir una configuración específica, no prometer que cualquier 7B Q4_K_M funcionará con una cantidad fija de memoria.

Como procedimiento práctico, toma el tamaño de archivo concreto como referencia de los pesos, calcula KV con los parámetros de arquitectura y añade memoria temporal y reserva del motor. Después verifica el pico de uso al cargar y generar. Si el sistema solo tiene RAM, la ejecución puede ser posible con un motor compatible, pero la velocidad no puede deducirse del tamaño del modelo.

En consecuencia, no se recomienda comprar una tarjeta basándose en una tabla genérica de «7B = X GB». Primero fija el modelo exacto y el objetivo de servicio: usuario único o concurrencia, contexto normal y máximo, respuesta en tiempo real o procesamiento por lotes. Un caso de uso definido permite dimensionar; una etiqueta de parámetros, por sí sola, no.

Rendimiento: mide velocidad, primera respuesta y concurrencia

Tokens por segundo describe una parte del rendimiento, pero debe aclararse si mide el prellenado del prompt o la generación. La latencia hasta el primer token incluye trabajo de recepción, prellenado y preparación; en prompts extensos puede crecer aunque la generación posterior sea rápida. Para una aplicación interactiva, ambas cifras importan.

La comparación debe mantener constantes modelo, prompt, longitud de salida, contexto, lote, motor, versión de software y temperatura del dispositivo. Ejecuta varias repeticiones y registra mediana y variación, además de memoria máxima. Evita comparar una prueba con una respuesta breve contra otra con contexto extenso: estarían midiendo cargas distintas.

No hay base suficiente en las fuentes aportadas para asignar tokens por segundo o latencia esperable a un 13B Q5_K_M en una GPU de 16 GB. El resultado depende de la GPU específica, el ancho de banda, el modelo y su arquitectura, el motor, las capas descargadas, el contexto y la configuración. Una estimación de capacidad no sustituye un benchmark en esa máquina.

Para servicio multiusuario, mide también throughput agregado y latencia por solicitud bajo concurrencia. Un motor optimizado para solicitudes simultáneas puede comportarse de forma diferente a uno local centrado en una sola conversación. La carga de trabajo debe reflejar el uso real: un único usuario que genera código no representa un servidor con varias sesiones y prompts largos.

Evalúa la pérdida de calidad con las tareas que importan

No existe una cifra única de degradación que describa el paso de Q8 a Q4 para todos los modelos y tareas. La diferencia depende de la arquitectura, del método de cuantización, del conjunto de evaluación y del criterio usado para puntuar. Una declaración como «pierde un 2 %» no es interpretable si no dice qué métrica, datos, versión y condiciones se compararon.

Construye una evaluación con ejemplos representativos y respuestas esperadas o criterios de puntuación definidos antes de probar. Para clasificación, usa un conjunto etiquetado y compara exactitud, precisión, exhaustividad o F1, según el coste de falsos positivos y negativos. Para generación, puntúa cumplimiento de instrucciones, exactitud factual verificable, formato y errores críticos con una rúbrica consistente. Para código, ejecuta pruebas automáticas sobre las salidas; no basta con una impresión subjetiva de que «parece correcto».

Compara cada cuantización con el mismo modelo de referencia, usando idéntico prompt, plantilla de conversación y parámetros de generación. Mantén las semillas cuando el motor lo permita y repite tareas estocásticas. Informa tanto del promedio como de los fallos graves: una media parecida puede ocultar una caída importante en un grupo pequeño de casos.

El trabajo alojado en alphaXiv sobre Qwen3.5-4B presenta un caso concreto de inferencia INT4 con destilación consciente de cuantización, decodificación especulativa y una GPU A10G. Es evidencia de ese sistema y configuración, no una prueba de que cualquier Q4 de GGUF mantenga la calidad o obtenga la misma aceleración. Además, el extracto no permite generalizar sus resultados a un modelo de 13B o a otra GPU.

Criterios para elegir cuantización y hardware

Empieza por el nivel de calidad que exige la tarea, no por la cuantización más pequeña que cabe. Si la calidad de referencia es imprescindible y hay memoria, conserva una precisión superior y valida la diferencia con Q4. Si el límite es la memoria, prueba Q4_K_M como candidato, mide el rendimiento y contrasta la calidad. Si falla la calidad, considera Q5, reducir el contexto o usar un modelo distinto antes de asumir que la única respuesta es comprar hardware.

La elección de hardware debe incluir capacidad de memoria, ancho de banda, compatibilidad del motor y facilidad para mantener el despliegue. Un equipo con VRAM suficiente puede seguir siendo lento si la cuantización no tiene kernels eficientes o parte del modelo se descarga. A la inversa, un modelo que cabe en RAM puede ser útil para pruebas o cargas no interactivas, aunque no alcance la latencia de una GPU.

Evalúa cada combinación con una tabla de decisión propia: modelo, cuantización, contexto, lote, memoria pico, latencia de primer token, velocidad de generación y puntuación de calidad. Esa tabla sirve para justificar una compra porque expone el requisito que realmente falta. También evita tratar el precio de una tarjeta como sustituto de una prueba.

Para comparar motores y configuraciones, conserva el mismo protocolo y revisa las opciones de una comparativa técnica. Para descubrir modelos compatibles, filtra por arquitectura, formato, licencia y tamaño real del archivo; no asumas que todas las variantes tienen el mismo comportamiento.

Conclusión: una estimación inicial se valida en el equipo real

GGUF facilita distribuir modelos locales con distintas cuantizaciones, pero el nombre Q4, Q5 o Q8 no basta para dimensionar un despliegue. Usa el tamaño real del archivo para orientar la estimación de pesos, calcula la caché KV con la arquitectura y la configuración previstas, y añade buffers y reserva del motor.

No hay una cifra universal de VRAM para un modelo de 7B Q4_K_M a 4096 tokens, ni una predicción fiable de tokens por segundo para un 13B Q5_K_M en una GPU de 16 GB sin más detalles. Presentar esos números como garantías ocultaría las variables que determinan el resultado.

La decisión final requiere dos validaciones: memoria y rendimiento en la carga real, y calidad en las tareas que justifican el despliegue. Registra contexto, lote, motor, versiones, memoria pico, latencia y métricas de calidad. Así podrás elegir entre cuantización, contexto menor, descarga parcial, otro modelo o una ampliación de hardware con evidencia comparable.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.