¿Cómo convertir un modelo a GGUF con llama.cpp?
Respuesta rápida
Ejecuta el script de conversión de llama.cpp sobre un directorio de modelo en formato Hugging Face, especificando un tipo de salida como f16 (precisión completa) o un formato cuantizado como q4_k_m. El script lee los pesos y la configuración del modelo, los escribe en un único archivo .gguf, y ese archivo puede cargarse directamente con llama.cpp, Ollama o LM Studio.
- ▸El modelo de origen debe estar en formato Hugging Face (safetensors o checkpoint de PyTorch) antes de la conversión
- ▸Elige un tipo de salida: f16/f32 para precisión completa, o un tipo cuantizado para convertir y reducir el tamaño en un solo paso
- ▸Cuantizar por separado después de una conversión a f16 da más control que cuantizar durante la conversión
Actualizado: 15 de julio de 2026
Technique & Concept ExplainersIntermedio
Puntos clave
- ✓La conversión a GGUF lee los pesos y metadatos de un modelo en formato Hugging Face y los escribe en un único archivo .gguf portátil
- ✓Convierte primero a f16/f32 si planeas probar varios niveles de cuantización — cuantizar a partir de una conversión ya cuantizada pierde más calidad que cuantizar desde precisión completa
- ✓El tipo de salida que elijas al convertir determina tanto el tamaño del archivo como la calidad de inferencia — no hay almuerzo gratis entre ambos
- ✓La mayoría de los errores de conversión se deben a un directorio de modelo de origen incompatible o incompleto, no al script de conversión en sí
El proceso de conversión
La conversión tiene tres pasos prácticos: preparar el modelo de origen, ejecutar el script de conversión con un tipo de salida y, si convertiste a precisión completa, cuantizar después.
- ▸**1. Preparar el modelo de origen:** el script de conversión espera un directorio en formato Hugging Face que contenga los archivos de pesos del modelo (se prefiere safetensors sobre los checkpoints heredados de PyTorch en `.bin`), además de sus archivos de configuración y de tokenizer. Un directorio descargado parcialmente o ensamblado manualmente al que le faltan los archivos de tokenizer es la causa más común de fallos de conversión.
- ▸**2. Ejecutar el script de conversión con un tipo de salida:** `python convert_hf_to_gguf.py
--outtype f16` produce un archivo GGUF en precisión completa. Pasar un `--outtype` cuantizado (por ejemplo `q8_0`) cuantiza durante la conversión en un solo paso, pero da menos control que convertir primero a f16 y cuantizar por separado después con una herramienta de cuantización dedicada. - ▸**3. Cuantizar por separado para más control (opcional pero recomendado):** partiendo de un archivo GGUF en f16, ejecuta la herramienta de cuantización de llama.cpp para producir varias variantes cuantizadas (por ejemplo q4_k_m, q5_k_m) a partir de la misma fuente en precisión completa, lo que permite comparar los compromisos entre calidad y tamaño sin repetir la conversión cada vez.
Errores de conversión comunes
La mayoría de los fallos de conversión se agrupan en unas pocas categorías, casi siempre atribuibles al modelo de origen y no al script en sí.
- ▸**Arquitectura no reconocida:** el script de conversión mantiene una lista interna de arquitecturas de modelo compatibles. Una arquitectura muy nueva o poco habitual puede no estar aún soportada — revisa la lista de arquitecturas actual de la herramienta antes de asumir que los archivos del modelo están dañados.
- ▸**Faltan archivos de tokenizer:** la conversión necesita la configuración del tokenizer además de los pesos. Un directorio de modelo que solo tenga archivos de pesos y no archivos de tokenizer fallará a mitad de la conversión.
- ▸**Expectativas de formato de archivo no coincidentes:** los checkpoints heredados de PyTorch en `.bin` a veces necesitan un paso extra de conversión a safetensors, según la versión de la herramienta — prioriza descargar modelos que ya vengan en formato safetensors para evitar esto por completo.
- ▸**Espacio en disco o RAM insuficientes durante la conversión:** la conversión carga el modelo en precisión completa en memoria antes de escribirlo, por lo que necesita aproximadamente la misma RAM que el tamaño en precisión completa del modelo, más el espacio en disco para los archivos de origen y el archivo GGUF de salida al mismo tiempo.
Preguntas frecuentes
¿Debo cuantizar durante la conversión o convertir primero a precisión completa?▾
Convierte primero a precisión completa (f16) si planeas comparar varios niveles de cuantización — cuantizar por separado después desde esa misma fuente f16 da resultados más precisos que cuantizar directamente desde un modelo de origen durante la conversión, y te permite producir varias variantes cuantizadas sin repetir el paso de conversión.
¿Por qué mi archivo GGUF convertido no carga en Ollama o LM Studio aunque la conversión fue exitosa?▾
Una conversión exitosa no garantiza que la herramienta de carga sea compatible con esa arquitectura o versión de GGUF específica. Comprueba que la versión de tu herramienta de carga esté actualizada — tanto el formato GGUF como el soporte de arquitecturas evolucionan, y una versión de herramienta más antigua puede no reconocer un archivo producido por un script de conversión más reciente.
¿Cuánto espacio en disco necesita la conversión?▾
Calcula el tamaño completo del modelo de origen más el tamaño del archivo GGUF de salida al mismo tiempo — para una conversión en precisión completa, eso aproximadamente duplica el espacio ocupado por el modelo durante el proceso. Los archivos de salida cuantizados son más pequeños, pero necesitas que los archivos de origen sigan presentes hasta que termine la conversión.
¿Puedo convertir un modelo que ya ha sido afinado (fine-tuned)?▾
Sí — el proceso de conversión funciona igual con un modelo afinado que con un modelo base, siempre que los pesos afinados estén guardados en un formato estándar compatible con Hugging Face. Si el ajuste fino usó pesos de adaptador (como LoRA) en lugar de pesos completos, primero fusiona el adaptador con el modelo base y luego convierte el resultado fusionado.