Cómo Hacer Fine-Tuning de un LLM: Métodos, Frameworks y Código Paso a Paso [2026]

El fine-tuning de un LLM consiste en tomar un modelo preentrenado y entrenarlo con tus datos específicos para que realice tu tarea mejor de lo que cualquier prompt podría conseguir. La barrera de entrada ha desaparecido: QLoRA + Unsloth ahora permiten hacer fine-tuning de un modelo de 8.000 millones de parámetros en una GPU de consumidor de 12 GB por menos de 1 € en costes de cloud.

Esta guía cubre todo el proceso -- cuándo hacer fine-tuning (vs. RAG o prompt engineering), qué método y framework elegir, cómo preparar tu dataset, un tutorial de Llama 3 listo para copiar y pegar, escenarios de costes reales y el despliegue.

El Fine-Tuning de un Vistazo

Antes de comprometerte con nada, aquí está el panorama rápido:

Ahora veamos si el fine-tuning es realmente la opción correcta para tu proyecto.

¿Cuándo Deberías Hacer Fine-Tuning de un LLM? (vs. RAG vs. Prompt Engineering)

Esta es la pregunta que la mayoría de los desarrolladores se saltan -- y les cuesta semanas de esfuerzo desperdiciado. El fine-tuning es poderoso, pero no siempre es la herramienta correcta. Aquí hay un marco para decidir.

La decisión se reduce a qué intentas cambiar. Aquí hay escenarios reales:

Si estás eligiendo el stack de IA correcto para tu SaaS, este marco de decisión es el primer paso. Muchos equipos construyen pipelines RAG complejos cuando un fine-tune de 500 ejemplos les daría resultados más consistentes con menor latencia.

Veredicto: Haz fine-tuning cuando necesites que el modelo se comporte de forma diferente, no solo que sepa cosas diferentes. Si solo necesitas nuevo conocimiento, RAG es más barato y fácil de mantener. Si necesitas ambas cosas, opta por el enfoque híbrido.

¿Cómo Funciona el Fine-Tuning de LLMs? Full vs. LoRA vs. QLoRA

Hay tres enfoques principales que difieren enormemente en requisitos de hardware, coste y calidad. Entender las compensaciones te evita sobreinvertir o no dar la talla.

Fine-Tuning Completo (Cuando el Presupuesto No es un Obstáculo)

El fine-tuning completo actualiza cada parámetro del modelo. Produce los mejores resultados posibles pero requiere recursos enormes -- aproximadamente 100+ GB de VRAM para un modelo 7B (necesitas almacenar el modelo, los estados del optimizador y los gradientes simultáneamente). Esto es territorio de clusters H100. A menos que trabajes en un laboratorio bien financiado, omite esto.

LoRA: La Revolución PEFT

LoRA (Low-Rank Adaptation) congela el modelo base y añade pequeñas matrices entrenables llamadas adaptadores. En lugar de actualizar directamente una enorme matriz de pesos W, LoRA descompone la actualización en dos pequeñas matrices A y B, donde el rango r es mucho menor que la dimensión del modelo. El resultado: entrenas aproximadamente el 1–2% de los parámetros originales mientras retienes el 98–99% de la calidad del fine-tuning completo.

La biblioteca peft de Hugging Face es la implementación estándar. Los adaptadores LoRA suelen tener 50–200 MB -- diminutos comparados con el modelo completo.

QLoRA: Fine-Tuning para Todos

QLoRA va un paso más allá que LoRA. Carga el modelo base en precisión de 4 bits usando un tipo de datos especial llamado NormalFloat4 (NF4), y luego aplica adaptadores LoRA encima. La cuantización a 4 bits reduce el uso de VRAM en otro ~25% comparado con LoRA estándar, preservando una calidad casi idéntica.

Esto es lo que hace accesible el fine-tuning. Un modelo 7B que necesita 100+ GB para el fine-tuning completo cabe en 12 GB con QLoRA.

Veredicto: Para el 90% de los desarrolladores, QLoRA es la elección correcta. La diferencia de calidad respecto al fine-tuning completo es despreciable para la mayoría de las tareas, y el ahorro en hardware es masivo. Empieza ahí y solo escala si tus métricas de evaluación lo requieren.

¿Qué Framework de Fine-Tuning Usar en 2026?

Elegir un framework importa más de lo que la mayoría de la gente cree. El correcto te ahorra horas de configuración y acelera significativamente el entrenamiento. Aquí está la comparación de las cuatro opciones principales.

Aquí la recomendación rápida:

• ¿Primer fine-tune? Usa Unsloth. Entrenamiento más rápido, configuración más fácil, notebooks de Colab gratuitos para empezar de inmediato.
• ¿Necesitas UI web sin código? Usa LLaMA-Factory. Su GUI LLaMA-Board te permite configurar y lanzar el entrenamiento desde un navegador.
• ¿Haciendo alineación (RLHF, DPO, GRPO)? Usa TRL. Es el estándar de Hugging Face para el entrenamiento basado en preferencias, y la v0.15.0 (marzo 2026) añadió soporte nativo de GRPO.
• ¿Pipelines de producción en multi-GPU? Usa Axolotl. Las configuraciones basadas en YAML hacen que los experimentos sean reproducibles y auditables.

Un truco útil: Unsloth y LLaMA-Factory pueden combinarse. LLaMA-Factory soporta Unsloth como backend de entrenamiento, dándote la comodidad de la GUI con las optimizaciones de velocidad de Unsloth.

¿Cómo Preparas un Dataset de Fine-Tuning?

La calidad de los datos es el factor más importante para el éxito del fine-tuning. Un dataset bien curado de 500 ejemplos superará casi siempre a uno con ruido de 10.000 ejemplos.

Formatos de Dataset

Los dos formatos dominantes son chat (compatible con OpenAI) e instruction (estilo Alpaca). Así es como se ve cada uno en formato JSONL:

Formato chat (recomendado para la mayoría de los casos de uso):

{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "I ordered a laptop 3 days ago (order #4821) and it still says processing."}, {"role": "assistant", "content": "I can see order #4821 is currently in our warehouse being prepared for shipment. Laptops typically ship within 3-5 business days. You should receive a tracking number by tomorrow. Would you like me to flag this for priority processing?"}]}
{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "Can I return my keyboard? Order #3019, bought it last week."}, {"role": "assistant", "content": "Absolutely! Order #3019 is within our 30-day return window. I'll email you a prepaid return label right now. Once we receive the keyboard, your refund will process within 2-3 business days."}]}
{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "My monitor arrived cracked. Order #5573."}, {"role": "assistant", "content": "I'm sorry about that! For order #5573, I'm initiating an immediate replacement shipment -- no need to return the damaged unit. The new monitor will ship today with express delivery. You'll get a tracking email within the hour."}]}

Formato instruction (estilo Alpaca):

{"instruction": "Summarize the following customer complaint in one sentence.", "input": "I've been waiting 2 weeks for my refund and nobody responds to my emails. This is the worst customer service I've ever experienced.", "output": "Customer is frustrated by a 2-week delay in receiving their refund and lack of email response from support."}
{"instruction": "Classify the sentiment of this review.", "input": "The product works fine but shipping took forever.", "output": "Mixed (positive product, negative shipping)"}

Directrices sobre el Tamaño del Dataset

¿Cuántos datos necesitas realmente? Depende de la complejidad de la tarea:

1. 50–100 ejemplos -- prueba de concepto, suficiente para comprobar si el fine-tuning ayuda
2. 500–1.000 ejemplos -- útil para la mayoría de las tareas simples (clasificación, extracción, formateo)
3. 5.000–10.000 ejemplos -- resultados de calidad de producción para tareas complejas
4. 10.000+ ejemplos -- rendimientos decrecientes a menos que tu tarea tenga alta variabilidad

Lista de Verificación de Calidad de Datos

Antes de entrenar, valida tu dataset con estos criterios:

• Formato consistente en todos los ejemplos (mismo prompt de sistema, misma estructura de salida)
• Ejemplos diversos que cubran casos límite y modos de fallo
• Sin contradicciones (no enseñes al modelo a decir tanto "sí" como "no" al mismo patrón de entrada)
• Distribución equilibrada de tipos de salida (en clasificación, no el 90% de los ejemplos en una clase)
• Eliminar entradas duplicadas o casi duplicadas

Consejo profesional: Usa GPT-4 o Claude para generar datos de entrenamiento sintéticos iniciales, y luego refínalos con revisión humana. 500 ejemplos sintéticos de alta calidad a menudo superan a 5.000 ejemplos reales con ruido. La guía de fine-tuning de Meta recomienda este enfoque para arrancar datasets.

Paso a Paso: Fine-Tuning de Llama 3 8B con QLoRA y Unsloth

Aquí está el tutorial completo. Cada bloque de código está listo para copiar y pegar -- puedes ejecutarlo en un notebook gratuito de Google Colab o en cualquier máquina con 12+ GB de VRAM.

Paso 1: Instalar Unsloth

pip install unsloth

Eso es todo. Unsloth gestiona todas las dependencias (transformers, peft, trl, bitsandbytes) automáticamente.

Paso 2: Cargar el Modelo Base en 4 Bits

from unsloth import FastLanguageModel

# Cargar Llama 3.1 8B en cuantización de 4 bits
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Meta-Llama-3.1-8B-bnb-4bit",
    max_seq_length=2048,
    load_in_4bit=True,
)

Esto descarga el modelo cuantizado a 4 bits (~4 GB) y lo carga en la memoria GPU. En una RTX 3060 (12 GB), tendrás suficiente margen para el entrenamiento.

Paso 3: Configurar los Adaptadores LoRA

# Añadir adaptadores LoRA al modelo
model = FastLanguageModel.get_peft_model(
    model,
    r=16,                # Rango LoRA -- 16 es el punto óptimo para la mayoría de las tareas
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                     "gate_proj", "up_proj", "down_proj"],
    lora_alpha=16,       # Factor de escala (normalmente igual a r)
    lora_dropout=0,      # Unsloth optimiza para dropout 0
    bias="none",
)

Con r=16, estás entrenando aproximadamente 40 millones de parámetros de 8.000 millones -- menos del 0,5% del modelo. Esa es la magia de LoRA.

Paso 4: Cargar tu Dataset

from datasets import load_dataset

# Cargar tu dataset JSONL desde Hugging Face Hub o archivo local
dataset = load_dataset("json", data_files="train.jsonl", split="train")

# Formatear en plantilla de chat
def format_chat(example):
    text = tokenizer.apply_chat_template(
        example["messages"],
        tokenize=False,
        add_generation_prompt=False,
    )
    return {"text": text}

dataset = dataset.map(format_chat)

Esto toma el formato de chat JSONL de la sección anterior y aplica la plantilla de chat de Llama 3. El tokenizador gestiona todos los tokens especiales (<|begin_of_text|>, <|eot_id|>, etc.).

Paso 5: Configurar y Ejecutar el Entrenamiento

from trl import SFTTrainer
from transformers import TrainingArguments
from unsloth import is_bfloat16_supported

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,
    dataset_text_field="text",
    max_seq_length=2048,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,    # Tamaño de batch efectivo = 8
        warmup_steps=5,
        max_steps=60,                     # Ajustar según el tamaño del dataset
        learning_rate=2e-4,               # Estándar para QLoRA
        fp16=not is_bfloat16_supported(),
        bf16=is_bfloat16_supported(),
        logging_steps=1,
        output_dir="outputs",
        seed=42,
    ),
)

# Iniciar el entrenamiento
trainer.train()

Hiperparámetros clave para entender:

• Tasa de aprendizaje (2e-4): El estándar para QLoRA. Baja (2e-5) si ves que el modelo olvida capacidades generales.
• Tamaño de batch (2) x acumulación de gradiente (4): Tamaño de batch efectivo de 8. Aumenta gradient_accumulation si tu GPU se queda sin memoria.
• max_steps (60): Para 500 ejemplos, esto es aproximadamente 1 época. Empieza con 1–3 épocas y monitoriza la pérdida de validación.
• Rango r (16): Menor (4–8) para tareas simples, mayor (32–64) para tareas complejas. 16 es un valor predeterminado seguro.

Paso 6: Guardar y Probar

# Guardar los adaptadores LoRA (pequeños -- ~50-200 MB)
model.save_pretrained("my-fine-tuned-model")
tokenizer.save_pretrained("my-fine-tuned-model")

# Prueba de inferencia rápida
FastLanguageModel.for_inference(model)
inputs = tokenizer(
    [tokenizer.apply_chat_template(
        [{"role": "user", "content": "I need to return order #7742"}],
        tokenize=False,
        add_generation_prompt=True,
    )],
    return_tensors="pt",
).to("cuda")

outputs = model.generate(**inputs, max_new_tokens=256)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Eso es todo el pipeline. En una RTX 4090 con Unsloth, entrenar 500 ejemplos tarda aproximadamente 15–30 minutos. En un Colab T4 gratuito, espera 1–2 horas.

¿Qué Hay del Fine-Tuning a través de API? (OpenAI, Google, Mistral)

No todo el mundo quiere gestionar GPUs. Los proveedores de API permiten el fine-tuning mediante un sencillo flujo de trabajo de carga y entrenamiento. Aquí está cómo se comparan con hacerlo tú mismo.

Cuándo tiene sentido el fine-tuning por API: Necesitas iterar rápido, tu dataset es pequeño, no quieres gestionar infraestructura, o específicamente necesitas un modelo cerrado como GPT-4o.

Cuándo gana el fine-tuning local: La privacidad de los datos importa (sanidad, finanzas, derecho), entrenas con frecuencia, quieres poseer y exportar los pesos, u optimizas para costes a escala.

Veredicto: El fine-tuning por API es el camino más rápido hacia una prueba de concepto. El fine-tuning local es el camino más barato hacia la producción. La mayoría de los equipos prototipan en una API, y luego pasan a Unsloth local una vez validado el enfoque.

¿Cuánto Cuesta el Fine-Tuning de un LLM?

La narrativa de que "el fine-tuning es caro" se quedó atascada en 2023. Esto es lo que cuesta realmente hoy.

La curva de costes se aplana rápidamente. Una startup haciendo fine-tuning de un modelo 8B en RunPod gasta menos en entrenamiento que en una taza de café. Incluso el escenario de producción 70B está por debajo de los €30 -- eso es el presupuesto de comidas de un mes de un desarrollador junior.

Proveedores de GPU en la nube a comparar: RunPod (mejores precios spot), Lambda (H100s bajo demanda fiables), Vast.ai (los más baratos pero calidad variable) y Modal (serverless, pago por segundo).

El gráfico anterior muestra por qué QLoRA cambió el juego. Un modelo 7B que requería un clúster multi-GPU para el fine-tuning completo ahora cabe en una GPU de laptop. El modelo 70B cae de "solo en la nube" a una única A100.

Veredicto: Puedes hacer fine-tuning de un modelo 8B de calidad de producción por menos de €1. La barrera de costes para el fine-tuning ha desaparecido. El coste real es el tiempo de preparación del dataset.

¿Cómo Evalúas un Modelo con Fine-Tuning?

El entrenamiento es solo la mitad del trabajo. Sin una evaluación adecuada, no puedes saber si tu modelo con fine-tuning ha mejorado realmente -- o si simplemente memorizó tus datos de entrenamiento.

Métricas Automatizadas

Rastrea estas durante y después del entrenamiento:

• Pérdida de entrenamiento / perplejidad: Debe disminuir de forma constante, luego estabilizarse. Si cae a casi cero, estás sobreajustando.
• Métricas específicas de la tarea: Precisión (clasificación), BLEU/ROUGE (resumen), coincidencia exacta (extracción), F1 (multi-etiqueta). Elige la métrica que coincida con tu tarea.

Evaluación Humana

Los números no capturan todo. Para tareas generativas:

• Pruebas A/B: Muestra el modelo base frente a la salida del modelo con fine-tuning en paralelo. Pide a 3–5 evaluadores que elijan la mejor respuesta entre 50+ ejemplos. Rastrea la tasa de victorias.
• Calificación en escala Likert: Puntúa las salidas en relevancia (1–5), precisión (1–5) y tono (1–5). Calcula la mejora media sobre el modelo base.

Comprobación del Olvido Catastrófico

Esta es la que la mayoría de los desarrolladores se saltan. Después del fine-tuning, ejecuta tu modelo en un benchmark general como MMLU o HellaSwag. Si las puntuaciones caen más de 2–3 puntos, tu modelo ha perdido demasiado conocimiento general. La solución: baja tu tasa de aprendizaje, reduce las épocas o cambia a LoRA (que congela los pesos base).

Regla práctica: Siempre reserva el 10–20% de tu dataset como conjunto de prueba. Nunca evalúes con datos de entrenamiento -- eso no te dice nada sobre el rendimiento en el mundo real.

¿Cómo Despliegas un Modelo con Fine-Tuning?

El entrenamiento ha terminado. Ahora necesitas servirlo. La mayoría de las guías se saltan esta parte completamente.

Paso 1: Fusionar los Adaptadores LoRA

Si usaste LoRA o QLoRA, fusiona los adaptadores de vuelta en el modelo base para la inferencia:

# Fusionar los adaptadores en el modelo base
model.merge_and_unload()
model.save_pretrained("merged-model")
tokenizer.save_pretrained("merged-model")

Paso 2: Elige tu Ruta de Despliegue

Desarrollo local y pruebas -- Ollama:

# Convertir al formato GGUF (formato nativo de Ollama)
python llama.cpp/convert_hf_to_gguf.py merged-model --outfile model.gguf --outtype q4_k_m

# Crear un modelo Ollama
ollama create my-fine-tuned-model -f Modelfile
ollama run my-fine-tuned-model

Serving en producción -- vLLM:

# Iniciar un servidor API compatible con OpenAI
python -m vllm.entrypoints.openai.api_server \
    --model merged-model \
    --host 0.0.0.0 \
    --port 8000

Serverless (cero infraestructura): Sube tu modelo a Together AI, Fireworks o Modal. Obtendrás un endpoint API sin gestionar servidores. El coste escala con el uso.

Avanzado: Serving Multi-Adaptador

Aquí hay un patrón que más equipos deberían usar: mantener un modelo base cargado en memoria e intercambiar adaptadores LoRA por solicitud. Podrías servir un adaptador de soporte al cliente, un adaptador de revisión de código y un adaptador de resumen -- todo desde una sola GPU. vLLM soporta esto de forma nativa con el flag --enable-lora.

¿Cuáles Son los Errores Más Comunes en el Fine-Tuning?

Después de ayudar a equipos a depurar decenas de runs de fine-tuning, estos son los errores que aparecen una y otra vez.

1. Sobreajuste en datasets pequeños. Entrenas durante 10 épocas con 200 ejemplos, la pérdida de entrenamiento llega casi a cero y el modelo repite tus datos de entrenamiento literalmente. Solución: máximo 1–3 épocas, usa un conjunto de validación y vigila la brecha entre pérdida de entrenamiento y pérdida de evaluación.

2. Olvido catastrófico. El modelo domina tu tarea específica pero ya no puede mantener una conversación básica. Solución: usa LoRA/QLoRA (congela los pesos base), mantén tasas de aprendizaje bajas (2e-5 para fine-tuning completo, 2e-4 para QLoRA) y evalúa en benchmarks generales antes del despliegue.

3. Mala calidad de los datos. Formato inconsistente, contradicciones entre ejemplos o duplicados. El modelo aprende el ruido. Solución: limpia tus datos antes de entrenar. Siempre. Dedica más tiempo a la curación de datos que al ajuste de hiperparámetros.

4. Empezar con un modelo demasiado grande. Los equipos saltan al 70B porque "más grande es mejor", y luego no pueden pagar los costes de GPU. Solución: empieza con 8B. Si 8B con buenos datos no puede resolver tu tarea, 70B con los mismos datos probablemente tampoco lo hará. Escala primero la calidad de los datos, luego el tamaño del modelo.

5. Sin pipeline de evaluación. Entrenar sin un conjunto de prueba reservado, luego desplegar basándose en corazonadas. Solución: divide tus datos 80/10/10 (train/val/test) antes de empezar. Compara con el modelo base en cada ejemplo de prueba.

6. Tasa de aprendizaje demasiado alta. Destruye el conocimiento preentrenado en los primeros pasos. El modelo produce disparates. Solución: empieza en 2e-4 para QLoRA, 2e-5 para fine-tuning completo. Si las salidas se degradan, baja más.

Cómo Aborda Techsy el Fine-Tuning de LLMs

En Techsy, seguimos un camino de escalada estricto para cada proyecto de IA: prompt engineering primero, RAG segundo, fine-tuning solo cuando los datos demuestran que es necesario. La mayoría de los proyectos de clientes realmente no requieren fine-tuning -- prompts bien elaborados o un pipeline RAG resuelven el problema con menor coste y complejidad.

Cuando el fine-tuning es la opción correcta, nuestro proceso es el siguiente:

1. Auditoría del dataset -- Revisamos los datos del cliente para verificar calidad, cobertura y formato. Si no tenemos suficientes ejemplos, ayudamos a construir un dataset sintético usando GPT-4 o Claude con revisión humana.
2. Selección de framework -- Unsloth + QLoRA para el 90% de los proyectos de startups. Axolotl para clientes que necesitan pipelines de producción reproducibles en multi-GPU.
3. Entrenamiento y evaluación -- Siempre entrenamos con un conjunto de prueba reservado y comparamos con el modelo base. Si el modelo con fine-tuning no mejora measurably la métrica objetivo, no lo desplegamos.
4. Despliegue -- vLLM para el serving en producción, patrones multi-adaptador cuando los clientes necesitan múltiples modelos especializados desde una sola GPU.

Hemos entregado modelos con fine-tuning para startups que no podían permitirse presupuestos de GPU empresariales -- QLoRA en RunPod mantiene los costes por debajo de los €30 incluso para modelos 70B.

¿Necesitas ayuda para hacer fine-tuning de un LLM para tu caso de uso? Ayudamos a equipos a ir desde datos brutos hasta el modelo desplegado. Obtén una consulta gratuita

Preguntas Frecuentes Sobre el Fine-Tuning de LLMs

¿Qué es el fine-tuning de un LLM?

El fine-tuning de un LLM es el proceso de entrenar un modelo de lenguaje preentrenado con tus propios datos específicos de una tarea para que realice mejor esa tarea. Básicamente estás enseñando al modelo nuevos comportamientos, formatos o experiencia en el dominio que el prompting genérico no puede lograr de manera fiable.

¿Cuándo debería hacer fine-tuning en lugar de usar RAG?

Haz fine-tuning cuando necesites que el modelo se comporte de forma diferente -- formato de salida consistente, lenguaje específico del dominio, tono particular. Usa RAG cuando el modelo necesite saber cosas diferentes, especialmente si ese conocimiento cambia frecuentemente. Para muchos sistemas de producción, un enfoque híbrido funciona mejor.

¿Cuánto cuesta el fine-tuning de un LLM?

Entre €0 y €540 según la escala. La mayoría de los desarrolladores individuales gastan menos de €1 usando QLoRA en un RunPod RTX 4090 (0,34 $/h). Un modelo de producción 70B en un A100 cuesta €17–27. El fine-tuning completo en clusters H100 cuesta €270–540. El fine-tuning por API (OpenAI) cuesta €3–25 para 1.000 ejemplos.

¿Puedo hacer fine-tuning de un LLM en mi laptop?

Sí, si tu laptop tiene una GPU con 12+ GB de VRAM. Una GPU laptop RTX 3060 maneja modelos 8B con QLoRA. Los Macs con Apple Silicon con 16+ GB de memoria unificada también pueden hacer fine-tuning vía MLX, aunque es más lento que CUDA. Para modelos más grandes, necesitarás GPUs en la nube.

¿Cuál es la diferencia entre LoRA y QLoRA?

Ambos añaden pequeñas capas de adaptadores entrenables mientras congelan el modelo base. La diferencia: QLoRA también cuantiza el modelo base a precisión de 4 bits (tipo de datos NF4), reduciendo el uso de VRAM en ~25% comparado con LoRA estándar. La calidad es casi idéntica -- QLoRA alcanza el 97–99% de la calidad del fine-tuning completo.

¿Cuántos ejemplos de entrenamiento necesito?

Depende de la complejidad de la tarea. 50–100 ejemplos son suficientes para una prueba de concepto. 500–1.000 ejemplos producen resultados útiles para la mayoría de las tareas simples. 5.000–10.000 ejemplos ofrecen calidad de producción para tareas complejas. Más de 10.000, alcanzas rendimientos decrecientes a menos que tu tarea tenga una variabilidad extremadamente alta.

¿Qué modelo base hacer fine-tuning en 2026?

Llama 3.x para tareas de propósito general (mejor relación calidad/tamaño). Mistral para idiomas europeos e inferencia eficiente. Qwen 2.5 para tareas multilingüe y de código. Phi-4 cuando necesitas la menor huella posible. Gemma 2 para integración en el ecosistema de Google.

¿Qué es GRPO y por qué importa?

GRPO (Group Relative Policy Optimization), introducido por DeepSeek, es un sucesor de RLHF para el entrenamiento de alineación. La ventaja clave: no requiere entrenar un modelo de recompensa separado, lo que reduce el coste computacional aproximadamente a la mitad. TRL v0.15.0 soporta GRPO de forma nativa, haciéndolo accesible para cualquiera que use el ecosistema de Hugging Face.

¿Cómo evito el olvido catastrófico?

Usa LoRA o QLoRA en lugar del fine-tuning completo -- congelan los pesos del modelo base, lo que preserva el conocimiento general. Mantén tu tasa de aprendizaje baja (2e-4 para QLoRA, 2e-5 para el completo). Entrena con el mínimo de épocas necesario (1–3 suele ser suficiente). Después del entrenamiento, ejecuta tu modelo en benchmarks generales (MMLU, HellaSwag) para verificar que no ha regresado.

¿Puedo combinar fine-tuning y RAG?

Absolutamente, y muchos sistemas de producción hacen exactamente eso. Haz fine-tuning para la consistencia de comportamiento y formato, y luego conecta RAG para la recuperación de conocimiento actualizado. El modelo con fine-tuning es mejor usando el contexto recuperado porque comprende el lenguaje y los requisitos de salida de tu dominio.

¿Cuánto tiempo dura el fine-tuning?

Para la mayoría de los proyectos, entre 30 minutos y 8 horas. Un modelo 8B con 500 ejemplos en Unsloth + RTX 4090 termina en 15–30 minutos. El mismo job en un Colab T4 gratuito tarda 1–2 horas. Los modelos 70B en A100s tardan 5–8 horas. El fine-tuning completo en setups multi-GPU puede tardar 20–40 horas.

¿Vale la pena la API de fine-tuning de OpenAI?

Para prototipado rápido, sí. Puedes subir un archivo JSONL y tener un GPT-4o-mini con fine-tuning en 30 minutos sin configuración de GPU. Para producción, el fine-tuning local suele ser mejor: posees los pesos, controlas la privacidad de tus datos y los costes son menores a escala. La mayoría de los equipos empiezan con la API para validar el enfoque y luego migran a local.

Conclusión

Hacer fine-tuning de un LLM ya no es la magia negra que era hace dos años. Aquí están las conclusiones clave:

1. Empieza con QLoRA + Unsloth -- cubre el 90% de los casos de uso en hardware de consumidor
2. Los buenos datos superan a un modelo más grande en todo momento. Dedica tu esfuerzo a la calidad del dataset, no a las actualizaciones de GPU.
3. La barrera de costes ha desaparecido -- haz fine-tuning de un modelo 8B por menos de €1 en GPUs cloud
4. Evalúa siempre frente al modelo base antes de desplegar. Si no es measurably mejor, no lo publiques.
5. Considera primero RAG -- haz fine-tuning solo cuando necesites que el modelo se comporte de forma diferente, no solo que sepa cosas diferentes

¿Listo para implementar? Consulta nuestras Best LLM Fine-Tuning Tools & Platforms [próximamente] para una comparación detallada de frameworks de entrenamiento y opciones de despliegue.

Si encontraste útil esta guía, consulta nuestra guía sobre cómo elegir el stack de IA correcto para las decisiones arquitectónicas más amplias en torno a los productos impulsados por IA.

Fuentes

• Repositorio GitHub de Unsloth -- framework de fine-tuning con mejoras de velocidad de 2–5x
• Documentación TRL de Hugging Face -- SFTTrainer, DPO e implementación GRPO
• Documentación PEFT de Hugging Face -- LoRA y fine-tuning eficiente en parámetros
• Paper QLoRA (Dettmers et al., 2023) -- investigación de cuantización NormalFloat de 4 bits
• Paper LoRA (Hu et al., 2021) -- adaptación de rango bajo de grandes modelos de lenguaje
• Documentación API Fine-Tuning OpenAI -- flujo de trabajo de fine-tuning basado en API
• Precios GPU Cloud RunPod -- referencia de costes de GPU en la nube
• Documentación vLLM -- serving de LLMs en producción
• Guía Fine-Tuning Llama de Meta -- recomendaciones oficiales de entrenamiento de Llama
• Paper DeepSeekMath (GRPO) -- Group Relative Policy Optimization