¿Qué es GGUF? El formato de archivo de LLM detrás de Ollama y llama.cpp, explicado

GGUF (normalmente expandido como GPT-Generated Unified Format, o Formato Unificado Generado por GPT) es un formato de archivo binario para almacenar modelos de lenguaje grandes: los pesos, el tokenizador y todos los metadatos de configuración en un único archivo autónomo. Es el formato nativo de llama.cpp, y es el que utilizan Ollama, LM Studio, KoboldCpp, enero y la mayoría de las demás aplicaciones locales de LLM realmente se ejecutan. Si alguna vez ha descargado un archivo cuyo nombre termina en .gguf, o has extraído un modelo con ollama runollama run

Qué contiene realmente un archivo GGUF

Un archivo GGUF comienza con los cuatro bytes ASCII GGUF, seguidos de un número de versión, una sección de metadatos clave-valor y, después, los tensores propiamente dichos. Los metadatos representan la decisión de diseño más importante: almacenan la arquitectura del modelo, la longitud del contexto, el vocabulario del tokenizador, la plantilla de chat y los detalles de la cuantización como claves con nombre, de modo que un entorno de ejecución pueda cargar cualquier archivo GGUF sin necesidad de un archivo separado config.json o archivos de tokenizador junto con él.

De este diseño se derivan tres consecuencias prácticas:

• Un único archivo constituye el modelo completo. Puedes copiar un archivo .gguf entre máquinas y funcionará directamente. (Los modelos muy grandes a veces se dividen en partes numeradas, como -00001-of-00002.gguf, pero aún así representan un solo modelo lógico.)
• Es asignable a memoria (memory-mappable). Los entornos de ejecución pueden usar mmap el archivo y cargar los pesos por demanda mediante paginación, lo que acelera la carga y permite iniciar modelos más grandes que la RAM disponible.
• La cuantización está integrada en el formato. Un archivo GGUF almacena los pesos ya comprimidos a 2–8 bits por peso, razón por la cual un modelo de 8 mil millones de parámetros puede ocupar solo 4,9 GB en lugar de 16 GB.

Por qué GGUF reemplazó a GGML

Antes de agosto de 2023, llama.cpp utilizaba un formato denominado GGML (llamado así por la biblioteca de tensores subyacente). GGML funcionaba, pero tenía un defecto estructural: su disposición en el archivo era rígida e invariable. Cada vez que llama.cpp incorporaba una nueva característica —nuevas arquitecturas, mejores métodos de cuantización, parámetros de escalado RoPE—, el formato debía modificarse, y todos los archivos de modelos existentes en todos los discos duros dejaban de funcionar. Los usuarios tuvieron que volver a descargar o convertir íntegramente sus colecciones de modelos varias veces en pocos meses.

GGUF, introducido por el proyecto llama.cpp en agosto de 2023, resolvió este problema mediante dos cambios:

• Control de versiones. El archivo declara explícitamente su versión de formato, de modo que los lectores saben exactamente cómo analizarlo.
• Metadatos extensibles basados en pares clave-valor. Nueva información (un campo para arquitectura, una plantilla de chat, un hiperparámetro adicional) simplemente se añade como una nueva clave. Los archivos antiguos sin esa clave siguen cargando correctamente; los nuevos archivos que la incluyen funcionan en entornos de ejecución actualizados. Nada se rompe retroactivamente.

llama.cpp eliminó el soporte para GGML poco después, y el ecosistema lo siguió. Hoy en día, GGML subsiste únicamente como nombre de la biblioteca de tensores subyacente; si encuentras un archivo de modelo con extensión .ggml o .bin del año 2023, no se cargará en ninguna herramienta actual, por lo que deberías descargar en su lugar una versión en formato GGUF.

Cómo interpretar los sufijos de cuantización

Cada nombre de archivo GGUF incluye un sufijo como Q4_K_M que indica el grado de compresión aplicado a los pesos. El patrón es el siguiente:

• El número tras la letra Q indica aproximadamente los bits por peso: Q4 ≈ 4 bits, Q8 ≈ 8 bits. Menos bits implican un archivo más pequeño y una calidad inferior.
• _K denota los métodos de «cuantización k» más recientes, que destinan bits adicionales a los tensores más críticos para la calidad de salida. A igual tamaño, una cuantización K supera a la versión anterior.
• _S / _M / _L (pequeño/mediano/grande) son variantes dentro de una misma familia K — _M conserva algunos tensores especialmente sensibles con mayor precisión que _S.
• _0 (como en Q8_0, Q4_0) indica la antigua y más sencilla cuantización por bloques. Q8_0 sigue siendo muy utilizado porque a 8 bits el método simple ya está casi sin pérdida; Q4_0 está mayormente obsoleto — prefiere Q4_K_M.
• IQ prefijos («IQ2_M, IQ3_XS»…) son «i-quants» construidos con una matriz de importancia, utilizados para comprimir modelos por debajo de 4 bits con menos daño que las alternativas.
• F16 / BF16 / F32 significa pesos sin cuantificar de 16 o 32 bits — la calidad de referencia, al tamaño máximo.

Aquí está lo que cuestan en la práctica las opciones comunes, utilizando modelos instruct tipo Llama de 8B como ejemplo (los tamaños son aproximados y varían ligeramente según el modelo):

Quant	Tamaño de archivo (modelo 8B)	Calidad vs F16	Cuándo usar
F16	~16,1 GB	Referencia	Benchmarking, cuantificación adicional; raramente vale la pena ejecutar
Q8_0	~8,5 GB	Prácticamente indistinguible	Tienes VRAM de sobra y quieres calidad máxima
Q6_K	~6,6 GB	Pérdida negligible	Excelente calidad con un ahorro de tamaño significativo
Q5_K_M	~5,7 GB	Pérdida muy menor	Un buen equilibrio intermedio
Q4_K_M	~4,9 GB	Pequeña pérdida, generalmente aceptable	El estándar predeterminado. Mejor relación calidad-por-gigabyte para la mayoría de personas
Q3_K_M	~4,0 GB	Degradación notable	Solo cuando Q4 genuinamente no cabe
Q2_K / IQ2	~3,2 GB	Degradación significativa	Último recurso; a menudo es mejor un modelo más pequeño a Q4

Dos reglas útiles: la cuantificación afecta más a los modelos pequeños que a los grandes (un 70B a Q3 se aguanta mucho mejor que un 8B a Q3), y por debajo de Q4 la curva de calidad cae abruptamente. Cuando tengas dudas, Q4_K_M es el estándar de la comunidad por una razón.

Elegir una cuantización según tu VRAM

La memoria total necesaria es aproximadamente tamaño de archivo + caché de contexto + overhead. Presupuesta 1–2 GB adicionales al tamaño del archivo para unos pocos miles de tokens de contexto, más si ejecutas contextos largos. El modelo se ejecuta más rápido cuando todo eso cabe en VRAM de GPU; las herramientas basadas en llama.cpp pueden descargar el resto a RAM del sistema, lo que todavía funciona pero se vuelve mucho más lento cuanto más capas se derramen.

VRAM	Lo que cabe cómodamente
8 GB	Modelos de 7–8B a Q4_K_M o Q5_K_M
12 GB	8B a Q8_0, o 12–14B a Q4_K_M
16 GB	14B a Q5_K_M/Q6_K
24 GB	~32B a Q4_K_M, o 14B a Q8_0 con contexto largo

Para números exactos en un modelo específico y longitud de contexto, el Calculadora de VRAM hace la aritmética por ti, y hay un desglose por modelo en Requisitos de VRAM para cada LLM importante. Si estás eligiendo hardware en lugar de un quant, comienza con las mejores GPUs para LLMs locales.

GGUF frente a safetensors

Estos dos formatos coexisten porque sirven runtimes diferentes, no porque uno esté ganando.

	GGUF	safetensors
Diseñado para	llama.cpp y su ecosistema	El ecosistema de Hugging Face / PyTorch
Contenidos	Pesos + tokenizer + configuración en un archivo	Solo tensores; la configuración y el tokenizer son archivos JSON separados
Cuantización	Integrada en el formato (Q4_K_M, etc.)	Generalmente FP16/BF16; cuantizada mediante métodos separados (GPTQ, AWQ)
Entornos típicos	Ollama, LM Studio, llama.cpp, KoboldCpp, Jan	transformers, vLLM, TGI, SGLang
Punto óptimo	Hardware de consumidor, híbrido CPU+GPU, usuario único	GPUs de centro de datos, servicio de alto rendimiento, entrenamiento

La decisión depende realmente del software que ejecutes: las herramientas de escritorio y Ollama requieren GGUF; las pilas de servicio en GPU y cualquier cosa relacionada con el ajuste fino requieren safetensors. Los editores de modelos suelen publicar primero los archivos safetensors, y la comunidad los convierte a GGUF en cuestión de días.

De dónde provienen los archivos GGUF

Casi todos los archivos GGUF viven en Hugging Face. Los laboratorios ocasionalmente publican GGUFs oficiales, pero la mayoría proviene de cuantizadores de la comunidad — cuentas como bartowski, unsloth, lmstudio-community y ggml-org — que convierten cada nuevo lanzamiento en el rango completo de cuantizaciones. Un repositorio llamado algo como Meta-Llama-3.1-8B-Instruct-GGUF contendrá un archivo por nivel de cuantización.

También puedes convertir un modelo tú mismo con las herramientas de llama.cpp: convert_hf_to_gguf.py convierte un modelo de Hugging Face a GGUF F16, y el binario llama-quantize binario (compilado cuando construyes llama.cpp) lo comprime a tu cuantización elegida, p. ej. llama-quantize model-f16.gguf model-Q4_K_M.gguf Q4_K_M.

Cargar un GGUF en Ollama

Ollama puede extraer repositorios GGUF directamente desde Hugging Face, con la cuantización especificada después de los dos puntos:

ollama run hf.co/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q4_K_M

Para un archivo que ya tienes en disco, crea un archivo de texto plano llamado Modelfile que contenga:

FROM ./my-model.gguf

luego regístralo y ejecútalo:

ollama create my-model -f Modelfile
ollama run my-model

Las versiones actuales de Ollama leen la plantilla de chat integrada en los metadatos de GGUF; si un modelo importado produce salida distorsionada, la solución suele ser añadir una línea TEMPLATE explícita al Modelfile. La guía completa de Ollama cubre Modelfiles en profundidad.

Cargar un GGUF en LM Studio

El camino normal es el descargador integrado: abre la pestaña Discover, busca un modelo, y LM Studio lista las cuantizaciones GGUF disponibles, señalando cuáles caben en tu hardware. Para importar un archivo que ya tienes, usa la CLI (lms import path/to/model.gguf) o colócalo en el directorio de modelos de LM Studio — la ruta predeterminada exacta varía según la versión y el SO, pero la pestaña My Models te la muestra y te permite cambiarla. Los archivos deben estar en una estructura de subcarpeta publisher/model-name/ para ser reconocidos. Consulta la guía completa de LM Studio para el recorrido completo.

¿Listo para ejecutar uno? Nuestra guía sobre modelos GGUF cubre el dimensionamiento, las descargas y su ejecución en Linux, macOS y Windows.

Preguntas frecuentes

¿Es GGUF solo CPU, o usa la GPU?

Ambos. llama.cpp nació como un proyecto de inferencia de CPU, pero descarga capas del modelo a la GPU (CUDA, Metal, Vulkan, ROCm) y se ejecuta completamente en GPU cuando el modelo cabe en VRAM. Ollama y LM Studio manejan la división CPU/GPU automáticamente; con llama.cpp directamente la controlas con la bandera -ngl (número de capas GPU).

¿Cuál es la diferencia entre Q4_K_M y Q4_K_S?

Ambos son k-quants de ~4 bits; la letra es la variante de tamaño. _M (medium) mantiene más de los tensores sensibles a la calidad en precisión más alta que _S (small), así que es un poco más grande y un poco mejor. La diferencia es pequeña — elige _M a menos que los últimos cientos de megabytes decidan si el modelo cabe.

¿Cuánta calidad pierdo realmente con la cuantización?

En Q8_0 y Q6_K, efectivamente ninguna — las pruebas ciegas tienen dificultades para separarlas de F16. Q4_K_M muestra una pequeña pérdida medible que la mayoría de usuarios nunca nota en chat, aunque puede importar para tareas precisas como generación de código o matemáticas. Por debajo de Q4 la degradación se vuelve obvia, y los modelos pequeños sufren más que los grandes.

¿Puedo usar GGUF con transformers o vLLM?

Existe soporte pero es limitado y no es el camino nativo — transformers puede desquantizar algunos archivos GGUF al cargar, y vLLM tiene soporte experimental de GGUF que varía por arquitectura. Si estás construyendo sobre esos stacks, usa safetensors; GGUF debe tratarse como el formato para la familia de runtimes llama.cpp.

¿Por qué mi modelo está dividido en múltiples archivos .gguf?

Los modelos muy grandes se dividen en partes denominadas como model-00001-of-00002.gguf, principalmente para mantenerse dentro de los límites de tamaño de archivo en las plataformas de alojamiento. Mantén todas las partes en la misma carpeta y apunta tu tiempo de ejecución a la primera — llama.cpp y las herramientas construidas sobre él cargan el resto automáticamente.

Una vez que sabes qué cuantización se ajusta a tu hardware, la siguiente pregunta práctica es qué modelo colocar en él — la Base de datos de modelos enumera especificaciones, necesidades de VRAM y precios para 37 modelos actuales, y los mejores modelos locales para Ollama es una buena lista de referencia para comenzar.