SFT, DPO, GRPO: tres métodos para afinar un modelo y cuándo usar cada uno

Cuando una empresa se plantea afinar su propio modelo de lenguaje, la primera pregunta suele ser: «¿Cuántos datos necesitamos?» La pregunta correcta es: «¿Qué queremos cambiar en el modelo — y qué objetivo de entrenamiento corresponde a eso?» SFT, DPO y GRPO son tres respuestas distintas a tres problemas distintos. Elegir el método adecuado antes de recopilar datos determina si el proyecto funcionará en seis meses o no.

Este artículo no explica cómo instalar un framework de entrenamiento. Explica qué hace cada método, cuándo desplegarlo, cuántos datos se necesitan realmente y por qué el orden SFT → DPO → GRPO no es casual.

Base: qué es LoRA y qué es el objetivo de entrenamiento — dos conceptos distintos

Antes de comparar los métodos conviene distinguir dos cosas que en los debates se mezclan con frecuencia.

LoRA (Low-Rank Adaptation) y QLoRA (su variante comprimida por cuantización) son *mecanismos* — la forma de modificar físicamente el modelo sin tocar todos los pesos. En lugar de eso, se entrenan pequeñas matrices adaptadoras que se superponen a los pesos existentes. Esto permite trabajar con mucha menos memoria de GPU: un modelo 7B típico se puede afinar con QLoRA en una GPU de ~9 GB de VRAM, mientras que el fine-tuning completo requeriría ~70–120 GB. Una comparación más detallada de estos mecanismos está en el artículo LoRA vs QLoRA vs full fine-tuning.

SFT, DPO y GRPO son, en cambio, *objetivos de entrenamiento* — definen qué aprende el modelo. Al igual que LoRA, el fine-tuning completo también es un mecanismo. Se puede hacer SFT con LoRA, SFT con fine-tuning completo, DPO con QLoRA — las combinaciones son libres. En la práctica, la mayoría de los proyectos de dominio se hacen hoy con LoRA o QLoRA simplemente por razones económicas, pero el objetivo de entrenamiento sigue siendo la decisión más importante.

SFT — supervised fine-tuning: enseñar al modelo formato y comportamiento

SFT (supervised fine-tuning, ajuste supervisado) es el método base. Se le da al modelo una entrada y la salida deseada, y el modelo aprende a imitar esos pares. Es esencialmente una extensión del preentrenamiento: el modelo aprende de muestras con el formato (prompt → respuesta).

SFT responde a la pregunta: *«¿Cómo debe reaccionar el modelo ante este tipo de tarea?»*

Cuándo usar SFT

SFT es la elección correcta cuando:

• El modelo tiene el conocimiento adecuado pero responde en el formato equivocado (demasiado largo, demasiado escueto, idioma incorrecto, estructura incorrecta)
• Se quiere enseñar al modelo jerga de dominio, terminología o estilo de comunicación
• Hay una tarea claramente definida con patrones consistentes — por ejemplo, clasificación de documentos, extracción de entidades, generación de informes según una plantilla
• Se quiere transferir por destilación el comportamiento de un modelo más potente a uno más pequeño (el modelo teacher genera los ejemplos, el modelo student se entrena)

SFT funciona también como base para todos los demás métodos. Un modelo base sin SFT no puede afinarse de forma fiable con DPO o GRPO — volveré a esto más adelante.

Cuántos datos necesita SFT

La investigación ha demostrado que 1 000 ejemplos de alta calidad pueden producir una salida notablemente mejor que 100 000 muestras de baja calidad. Pero para sistemas en producción el tamaño típico de un dataset es más bien 10 000–100 000 pares, porque se quiere cubrir la larga cola de variantes de entrada que aparecen en operación real.

El mínimo práctico para obtener resultados fiables en un proyecto de dominio es de unos 5 000 ejemplos de calidad que cubran la mayoría de las áreas temáticas con las que se encontrará el modelo. Por debajo de ese umbral, el modelo puede mejorar su comportamiento con los datos que ha visto, pero falla en variantes que no ha visto.

Para los sectores regulados (derecho, medicina, farmacia) rige una regla más estricta: el dataset debe cubrir cada jurisdicción y cada tipo de documento con el que trabajará el modelo. Una cobertura parcial produce un modelo que responde con alta confianza incluso en áreas donde carece de suficientes ejemplos de entrenamiento — eso es peor que no abordar el problema en absoluto.

Qué no resuelve SFT

SFT no enseña al modelo a *evaluar* — no sabe que una respuesta es mejor que otra, solo que esa respuesta existe. Si el modelo tiende a responder de forma inapropiada, a ser excesivamente escueto cuando eso perjudica, o a evitar ciertos tipos de preguntas, SFT por sí solo no lo corregirá. Para eso sirve DPO.

DPO — direct preference optimization: enseñar al modelo qué es mejor

El entrenamiento de DPO (direct preference optimization) se realiza mediante pares de preferencia — para cada prompt se tienen dos respuestas: winner (preferida) y loser (menos preferida). El modelo aprende a orientar su distribución de respuestas hacia el winner y alejarse del loser.

DPO es una variante simplificada del RLHF original (reinforcement learning from human feedback) — no requiere un modelo de recompensa separado, lo que lo hace mucho más económico y estable para el entrenamiento.

DPO responde a la pregunta: *«¿Cómo debe decidir el modelo cuando existen múltiples respuestas posibles?»*

Cuándo usar DPO

DPO es la elección correcta cuando:

• Se tienen preferencias definidas: qué respuesta es mejor y cuál es peor (verificadas por humanos o mediante un proceso automático)
• Se quiere reducir la tendencia del modelo a responder de una forma no deseada — demasiado pasivo, demasiado extenso, con demasiadas frases de cobertura
• Se quiere ajustar el tono de comunicación sin reescribir completamente los datos de entrenamiento
• Ya se dispone de una base SFT y se quiere seguir mejorando el alineamiento del modelo

Cuántos datos necesita DPO

La cantidad mínima recomendada son ~2 000 pares de preferencia con evaluación winner/loser verificada por humanos. Este no es un número arbitrario — por debajo de ese umbral la señal de preferencia no puede separarse de forma fiable del ruido en la distribución, y el modelo puede sobreajustarse a los artefactos de los evaluadores concretos.

Para una buena generalización se necesita mayor cobertura: 5 000–10 000 pares que cubran diferentes tipos de prompts y escenarios es el objetivo habitual en producción.

Más importante que el número es la calidad de la evaluación. Si los pares winner/loser se evalúan de forma inconsistente o con criterios poco claros, el modelo aprenderá una política inconsistente. Antes de recopilar datos es imprescindible tener una rúbrica clara — qué hace concretamente que una respuesta sea mejor.

Orden: SFT antes de DPO es imprescindible

DPO se aplica sobre un modelo que ya ha pasado por SFT — no sobre el modelo base directamente. La razón es práctica: el modelo base produce demasiada variabilidad en las respuestas, y la señal de DPO se «diluye» — el modelo no tiene una base estable sobre la que aplicar el gradiente de preferencia.

En la práctica queda así:

1. 1.Modelo base → SFT → modelo instruction-tuned (sabe responder de forma consistente a los tipos de tarea dados)
2. 2.Modelo instruction-tuned → DPO → modelo alineado (prefiere las mejores respuestas sobre las peores)

Saltarse el SFT y aplicar DPO directamente desde el modelo base típicamente produce resultados inestables o un modelo que no sigue instrucciones.

GRPO — group relative policy optimization: enseñar al modelo a razonar

GRPO (group relative policy optimization) es un método de la familia RL-from-rewards (reinforcement learning con recompensas). En lugar de pares de preferencia, el modelo recibe una tarea verificable — una ecuación matemática, un problema lógico, una tarea de codificación — y obtiene una recompensa según si su salida es objetivamente correcta.

GRPO ganó prominencia tras la publicación de DeepSeek R1, donde se usó para el fine-tuning orientado al razonamiento. La ventaja clave frente al PPO antiguo (proximal policy optimization): GRPO no requiere un modelo critic separado, lo que reduce los requisitos de VRAM y simplifica el pipeline de entrenamiento.

GRPO responde a la pregunta: *«¿Cómo enseñar al modelo a razonar mejor en tareas donde la respuesta correcta es verificable?»*

Cuándo usar GRPO

GRPO es la elección correcta cuando:

• Se tienen tareas con respuestas verificables — matemáticas, código, lógica, consultas SQL, extracción de datos estructurados con anotación gold
• Se quiere mejorar el razonamiento — la capacidad del modelo para recorrer múltiples pasos sin perder el contexto
• Se quiere que el modelo genere chain-of-thought (cadena de razonamiento) en tareas donde tiene valor
• Se dispone de un entorno donde se puede evaluar automáticamente la corrección de la salida sin un evaluador humano

GRPO suele ser el tercer paso del pipeline, no el primero. El modelo debe tener una base SFT sólida y preferiblemente también alineamiento DPO antes de que el entrenamiento RL se aplique de forma eficaz.

Cuántos datos necesita GRPO

El mínimo son ~1 000 trayectorias puntuadas — prompts con respuesta verificable y señal de recompensa funcional. El énfasis está en «verificable»: la recompensa debe ser consistente y calculable de forma automática. Si la recompensa depende de una evaluación subjetiva, el entrenamiento RL produce resultados inestables.

En la práctica, GRPO se hace con datasets más pequeños y específicos (miles, no cientos de miles) — porque la señal de recompensa es más intensa que la señal supervisada. Por otro lado, recopilar recompensas verificables es costoso: hay que definir la métrica, escribir el evaluador y garantizar que el propio evaluador no comete errores.

El estado actual de GRPO como área de investigación

GRPO es un espacio de investigación activo. Existen múltiples variantes (DAPO y otras) y la comunidad sigue explorando activamente dónde están sus límites. Para la mayoría de los proyectos de dominio en entornos B2B, GRPO es relevante solo si:

• Se trabaja en tareas de razonamiento intensivo (análisis complejo, código multilínea, diagnóstico técnico)
• Se tiene capacidad para escribir y validar la función de recompensa
• El equipo tiene experiencia en entrenamiento RL — depurar RL es notablemente más complejo que depurar SFT

Para la mayoría de las adaptaciones de dominio (estilo, terminología, formato), SFT + DPO es suficiente y mucho más estable.

Los tres métodos en paralelo — comparación rápida

SFT — supervised fine-tuning: - Entrada: pares (prompt, respuesta deseada) - Aprende: formato, estilo, terminología, comportamiento en tareas específicas - Mínimo de datos: ~5 000 pares de calidad para un sistema de dominio en producción - Orden: siempre el primer paso

DPO — direct preference optimization: - Entrada: tríadas (prompt, respuesta winner, respuesta loser) - Aprende: qué respuesta es preferida, alineamiento, mejora del tono y la toma de decisiones - Mínimo de datos: ~2 000 pares de preferencia verificados por humanos - Orden: después de SFT, no desde el modelo base

GRPO — group relative policy optimization: - Entrada: prompt + señal de recompensa automática (corrección verificable) - Aprende: razonamiento, chain-of-thought, precisión en tareas verificables - Mínimo de datos: ~1 000 trayectorias puntuadas con un evaluador funcional - Orden: después de SFT (e idealmente DPO) como tercer paso

El olvido catastrófico — el coste oculto de todo fine-tuning

Cada método conlleva el riesgo de olvido catastrófico (catastrophic forgetting): un modelo entrenado intensamente en un dominio estrecho puede degradar las capacidades que no ha visto en los datos de entrenamiento. En la práctica significa: un modelo que destaca generando informes técnicos puede empezar a gestionar peor las preguntas conversacionales o el razonamiento lógico fuera del dominio.

Los mecanismos PEFT como LoRA mitigan este efecto porque modifican solo una pequeña parte de los pesos — pero no lo eliminan. Mitigación en la práctica:

1. 1.Mezclar en el dataset de entrenamiento datos de dominio con muestras generales (5–15 % de mezcla general)
2. 2.Evaluar el modelo fuera del dominio después de cada ciclo de entrenamiento — no solo con benchmarks de dominio
3. 3.Conservar la versión del modelo anterior al fine-tuning como fallback

Un análisis más detallado de cómo medir si el fine-tuning ha ayudado o ha perjudicado está en el artículo Cómo medir si el fine-tuning ha funcionado.

Pipeline en la práctica: del modelo base al despliegue en producción

En proyectos B2B donde hemos desplegado modelos de dominio, el proceso típico es el siguiente:

Fase 1 — elección del modelo base. Se elige un modelo open-weight adecuado (familia Qwen, Llama, Mistral) según la capacidad de VRAM y el contexto requerido. Para la mayoría de las tareas de dominio, un modelo de 7B–14B ofrece la mejor relación rendimiento/coste. Con una GPU de 24 GB de VRAM (p. ej. RTX 3090/4090), QLoRA 7B funciona con holgura; para un modelo de 13B se entra justo. Más información sobre selección de modelo y sizing de GPU en el artículo Qué GPU para inferencia de LLM.

Fase 2 — recopilación de datos SFT. Se identifican los tipos de tarea, el formato de las respuestas esperadas y la terminología. Se recopilan o generan 5 000–50 000 pares. Para proyectos de dominio hay una buena receta: 150–200 ejemplos semilla de alta calidad elaborados por humanos, amplificados 10–100× mediante un modelo frontier potente (Claude, GPT como teacher). El resultado se verifica con anotación manual de una muestra.

Fase 3 — ciclo de SFT. Entrenamiento con LoRA o QLoRA, típicamente varias épocas. En una GPU A100 se mide en horas, no en días. Los costes aproximados en la nube son del orden de decenas de euros por ciclo para un modelo 7B con 10 000 ejemplos — depende del proveedor y de la GPU utilizada.

Fase 4 — evaluación y decisión. Un conjunto de pruebas que cubre todos los tipos de tarea. Si los resultados son satisfactorios, el modelo va a producción. Si no — se analiza dónde falla, no se añaden datos a ciegas.

Fase 5 (opcional) — DPO. Si se tiene capacidad para recopilar pares de preferencia y el modelo presenta un comportamiento concreto que se quiere cambiar (no solo conocimiento que falta), DPO es el siguiente paso correcto.

Fase 6 (especializada) — GRPO. Solo si se trabaja en un caso de uso con razonamiento intensivo y se dispone de una señal de recompensa verificable.

Cuándo no hacer fine-tuning

El fine-tuning no es la respuesta a todos los problemas. Hemos visto proyectos donde la empresa invirtió semanas en SFT y el resultado fue peor que un pipeline RAG sencillo con un buen prompt. Antes del fine-tuning conviene preguntarse:

• ¿El problema está en lo que el modelo no sabe (hechos, documentos)? En ese caso, RAG es más eficaz y más económico. El fine-tuning no enseña al modelo nuevos hechos de forma fiable, solo cambia el comportamiento.
• ¿El problema está en que el modelo responde con un formato o estilo incorrecto? En ese caso puede bastar un mejor prompt de sistema antes de invertir en un dataset.
• ¿Se dispone de suficientes datos de calidad para cubrir el dominio? Si no, el fine-tuning produce un modelo que responde con confianza incluso donde no tiene base suficiente.

El marco de decisión RAG vs fine-tuning se analiza en detalle en el artículo independiente RAG vs fine-tuning — cuándo cada uno.

Preguntas frecuentes

¿Puedo hacer DPO directamente desde el modelo base sin SFT?

Técnicamente sí; el resultado suele ser inestable. El modelo base produce salidas demasiado variables — el gradiente de DPO no puede aplicarse con eficacia porque el modelo no tiene una base de comportamiento consistente. En la práctica casi siempre se necesita al menos un pase mínimo de SFT antes de DPO.

¿Es GRPO adecuado para proyectos empresariales fuera del sector tecnológico?

GRPO es potente donde se tienen respuestas verificables — matemáticas, código, extracciones estructuradas con anotación gold. Para la mayoría de los casos de uso B2B (atención al cliente, asistente de documentación, generación de informes), SFT + DPO es suficiente y mucho más sencillo de implementar y depurar. Recomendamos GRPO solo si el equipo tiene experiencia en entrenamiento RL.

¿Cuánto cuesta el fine-tuning en la nube para un modelo 7B?

Estimación aproximada: un ciclo de SFT con 10 000 ejemplos tarda en una GPU A100 del orden de unas horas; los costes están en el rango de decenas de euros (en proveedores más económicos) a pocas centenas de euros (hiperscaladores). El coste real de un proyecto depende del número de iteraciones, del tamaño del dataset y de cuántas veces se repite el entrenamiento tras ajustar los datos. El coste mayor suele estar en la recopilación y anotación de datos, no en el entrenamiento en sí.

¿Qué es el olvido catastrófico y cómo evitarlo?

El olvido catastrófico ocurre cuando el fine-tuning en un dominio estrecho degrada las capacidades generales del modelo — por ejemplo, el razonamiento lógico o las habilidades conversacionales fuera del dominio. Se mitiga mezclando datos de dominio con datos generales (5–15 % de mezcla general en el dataset), usando el mecanismo LoRA/QLoRA (modificación menos agresiva de los pesos) y evaluando sistemáticamente fuera del dominio después de cada ciclo de entrenamiento.

¿Qué modelo open-weight recomendáis como base para SFT de dominio?

Para la mayoría de los proyectos de dominio en 2026, las familias Qwen, Llama o Mistral en el rango 7B–14B son una buena base. La elección depende de la longitud de contexto, la licencia y qué modelo base es compatible con el framework de entrenamiento elegido. Para recomendaciones específicas con cifras, véase Cómo elegir un modelo LLM.

*Si estáis valorando afinar vuestro propio modelo y no sabéis por dónde empezar — SFT, DPO u otro método — estaremos encantados de repasar con vosotros el caso de uso concreto y proponer un plan realista. Contactadnos en mp-is.eu o reservad una consulta directamente.*