Fine-Tuning de LLMs Locales con QLoRA: Del Experimento al GGUF en Producción

No faltan tutoriales de fine-tuning. La mayoría muestran cómo poner en marcha un modelo con un dataset de juguete. Pocos explican qué cambia realmente cuando necesitas que el resultado funcione de forma fiable con datos de producción y requisitos de dominio específicos.

Este es el pipeline que usamos — cubriendo curación del dataset, entrenamiento QLoRA en una A100, evaluación, cuantización y serving con vLLM u Ollama.

Cuándo Vale la Pena el Fine-Tuning

El fine-tuning no siempre es la respuesta correcta. Antes de comprometerte con él, valida que el caso de uso no puede resolverse con:

• Mejor prompting: prompts estructurados con ejemplos few-shot cubren la mayoría de requisitos de formato y estilo
• RAG: si la necesidad es conocimiento de dominio (recuperar hechos de documentos), la recuperación supera a hornear conocimiento en los pesos
• System prompt + uso de herramientas: para comportamiento especializado en un contexto multi-turno

El fine-tuning gana su coste cuando necesitas: (1) formato de salida consistente que el prompting no puede producir de forma fiable, (2) patrones de razonamiento específicos de dominio que no están en el modelo base, o (3) estilo de respuesta que no puede lograrse mediante prompting con latencia aceptable.

La Curación del Dataset es el 80% del Trabajo

La calidad de un modelo fine-tuneado está casi completamente determinada por la calidad del dataset. Esto no es una figura retórica.

Qué hace bueno a un dataset de fine-tuning:

• 500-5.000 ejemplos de alta calidad para instruction fine-tuning (más no siempre es mejor si la calidad cae)
• Formato consistente: cada ejemplo en el mismo esquema instrucción/respuesta
• Representativo de la distribución real de producción — no solo de los casos fáciles
• Ejemplos negativos: incluir casos donde la respuesta correcta es “no puedo responder esto” o un rechazo
• Deduplicación: incluso datasets pequeños suelen contener casi-duplicados que sesgan el entrenamiento

Errores comunes:

• Generar datos de entrenamiento con un modelo más grande y usarlos directamente. El alumno aprende tanto los errores del profesor como sus patrones. Revisar y filtrar los datos generados sintéticamente.
• Entrenar solo con ejemplos positivos. El modelo aprende qué decir pero no cuándo declinar.
• No dividir por tiempo o fuente. Si tu conjunto de validación tiene los mismos documentos que el de entrenamiento, tus métricas de evaluación son optimistas.

La Configuración de Entrenamiento QLoRA

Para la mayoría de tareas de fine-tuning enterprise, QLoRA (Adaptación de Bajo Rango Cuantizada) en un modelo base de 7B-14B parametros alcanza el equilibrio óptimo entre capacidad y coste de entrenamiento. El modelo completo permanece congelado en cuantización de 4 bits; solo las pequeñas matrices adaptadoras LoRA se entrenan.

Hardware: Una A100 de 80GB en RunPod maneja un modelo de 14B con QLoRA con tamaños de batch cómodos. Para modelos de 7B, una A100 de 40GB es suficiente.

Stack recomendado: Unsloth + HuggingFace Transformers + TRL. Las optimizaciones de memoria de Unsloth dan 2-4x de velocidad de entrenamiento respecto a PEFT estándar sin coste en precisión.

Hiperparámetros clave que realmente importan:

• r (rango LoRA): 16 para la mayoría de tareas, 64 para tareas de razonamiento complejo. Mayor rango = más parámetros = más expresivo pero más propenso a sobreajuste con datasets pequeños.
• learning_rate: 2e-4 es un punto de partida seguro. Menor (1e-4) si el modelo base ya está cerca; mayor (3e-4) solo si la tarea es muy diferente del preentrenamiento.
• num_train_epochs: Observa la pérdida de validación. Para cuando deje de decrecer — típicamente 1-3 épocas con un dataset bien curado. Más allá de eso estás memorizando, no generalizando.

Evaluación Antes del Despliegue

Un modelo fine-tuneado que puntúa bien en tu conjunto de evaluación pero falla con entradas reales es la sorpresa post-despliegue más común.

Requisitos mínimos de evaluación:

1. Conjunto de test reservado: 10-15% de los datos originales, nunca vistos durante el entrenamiento
2. Ejemplos fuera de distribución: entradas que son válidas pero no están representadas en tus datos de entrenamiento
3. Entradas adversariales: intentos de obtener el formato incorrecto, casos límite, y entradas que el modelo debería declinar
4. Regresión en capacidad general: ejecuta el modelo fine-tuneado en un subconjunto de benchmark estándar (MMLU, HellaSwag) para verificar que no has degradado el razonamiento general. Cualquier caída de más de 2-3 puntos requiere investigación.

Cuantización y Exportación a GGUF

Una vez que el adaptador está entrenado y fusionado con el modelo base, necesitas exportar a un formato que tu servidor de inferencia entienda.

Para llama.cpp / Ollama: formato GGUF. Exportar con llama.cpp/convert.py, luego cuantizar. Q4_K_XL (variante de Cuantización Dinámica de Unsloth) da el mejor balance calidad-tamaño a 4 bits. Q5_K_M vale la VRAM adicional si tienes una GPU de consumo de 24GB.

Para vLLM: GGUF no está soportado — usa cuantización AWQ o GPTQ en su lugar, o ejecuta el modelo fusionado en FP16/BF16 si la VRAM lo permite.

Serving: Para producción, vLLM con un endpoint API compatible con OpenAI es el estándar. Establece --max-model-len basándote en tu caso de uso real — no uses por defecto la longitud máxima de contexto del modelo. Para usuarios concurrentes, establece --gpu-memory-utilisation a 0,85-0,90 y haz benchmarking con tu perfil de concurrencia real.

El modelo fine-tuneado y cuantizado ejecutándose en tu propio hardware es el estado final: coste cero por inferencia, trazabilidad completa, sin dependencia de APIs externas.