2026-01-04 · Actualizado 2026-07-15

[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

LLM Fine-Tuning Guía: LoRA, QLoRA, DoRA, Unsloth, Axolotl y despliegue

La mayoría de los fallos fine-tuning se deben a problemas en la toma de decisiones. Un equipo realiza entrenamiento antes de comprobar si la inducción de prompts, la recuperación de información o constrained decoding pueden resolver el problema; evalúa los resultados en la distribución de datos utilizada para el entrenamiento; o descubre, una vez finalizado el entrenamiento, que el resultado generado es difícil de utilizar.

Esta guía considera la adaptación como un experimento que cuenta con un punto de salida operativo definido. Comienza por delimitar el umbral de decisión y, a continuación, sigue una secuencia que incluye el procesamiento de los datos, LoRA o QLoRA, la evaluación específica para cada tarea, la exportación de resultados y serving.

TL;DR: Realice el ajuste fino cuando una línea de base medida indique que modificar el comportamiento del modelo justifica una actualización de pesos. Utilice la recuperación de información para cambiar hechos y constrained decoding para la sintaxis. Empiece con LoRA cuando el modelo base se adapte sin problemas; emplee QLoRA cuando la limitación sea la memoria con pesos congelados. Reserve un conjunto de evaluación antes del entrenamiento, compárelo con la línea de base sin ajustar y elija el artefacto de despliegue antes de decidirse por un método específico.

¿Debería realizarse algún tipo de ajuste fino?

Antes de invertir GPU horas, decida si fine-tuning es la herramienta adecuada para resolver el problema que tiene entre manos.

Fine-tuning frente a RAG

Fine-tuning puede modificar la forma en que un modelo utiliza el lenguaje del dominio, pero constituye un mecanismo de actualización deficiente para aquellos hechos que cambian o deben citarse. La recuperación de información y fine-tuning abordan aspectos diferentes del problema y, con frecuencia, deben integrarse dentro del mismo sistema.

Fine-tuning frente a prompt engineering

Los modelos modernos LLMs responden de manera óptima ante instrucciones claras prompts y ejemplos concretos. Pruebe esas opciones antes de invertir en fine-tuning.

[!TIP] Pruebe primero con prompts Comience utilizando prompt y ejemplos representativos. Si solo la sintaxis de la salida es poco fiable, añada constrained decoding antes de modificar los pesos.

Fine-tuning frente a constrained decoding

Bibliotecas como xgrammar y outlines Se limita la generación a un JSON schema, una expresión regular o una gramática. En función de la restricción y de backend, se compila un autómata o una gramática que permite filtrar los tokens siguientes inválidos. No es necesario realizar ninguna actualización de pesos.

Esto garantiza la pertenencia al idioma de salida admitido, pero no implica que los valores sean verdaderos, completos o semanticamente adecuados. Una llamada a función sintácticamente válida puede seguir conteniendo un ID de cliente incorrecto.

Un orden práctico:

1. Comience con prompts y ejemplos de few-shot para el formateo básico.
2. Añada constrained decoding (xgrammar o outlines) cuando la sintaxis es inconsistente.
3. Realice el ajuste fino únicamente cuando sea necesario introducir cambios de comportamiento que un esquema no pueda imponer.

Referencia rápida: asociación de problemas con soluciones

Hacer que el caso de negocio sea medible

Fine-tuning puede reducir la cantidad de tokens prompt que se generan de forma recurrente o permitir que un modelo más pequeño cumpla con los requisitos establecidos, pero ninguna de estas economías se produce de forma automática. Es necesario calcular el punto de equilibrio utilizando los datos de tráfico y las tarifas propias del proyecto:

[ \text{Solicitudes de punto de equilibrio} = \frac{\text{Coste de entrenamiento + evaluación + despliegue}}{\text{Coste base/solicitud} - \text{Coste ajustado/solicitud}} ]

Si el denominador es pequeño, negativo o se basa en una suposición de calidad no comprobada, el proyecto aún no cuenta con un argumento económico sólido.

[!TIP] La configuración híbrida Una arquitectura habitual consiste en un modelo más pequeño adaptado a la tarea, combinado con mecanismos de recuperación de información para actualizar datos cuando sea necesario. Considere el modelo más grande, activado mediante prompts, como referencia base, y mantenga el modelo más pequeño únicamente si cumple con los mismos umbrales de calidad y seguridad específicos de la tarea.

Tipos de fine-tuning

Existen tres formas principales que puede adoptar fine-tuning. Diferen según el tipo de datos que requieren y qué enseñan al modelo.

1. Preentrenamiento continuo (no supervisado)

Entrenas el modelo base con más texto en bruto, sin etiquetas. Continúa realizando predicciones de token siguiente, tal como ocurría durante la fase inicial de preentrenamiento.

Cuándo utilizarlo:

• El dominio cuenta con un vocabulario que el modelo base nunca ha visto (médico, legal, bases de código internas).
• Dispones de grandes cantidades de texto del dominio, pero sin pares etiquetados (entrada, salida).
• El modelo base tiene dificultades para manejar la terminología específica del dominio.

Ejemplo: entrenamiento con millones de notas clínicas para que el modelo aprenda las abreviaturas médicas, los nombres de fármacos y los flujos de trabajo clínicos.

2. Aprendizaje supervisado fine-tuning (SFT)

SFT se entrena con pares etiquetados de entrada y salida. Se le muestra al modelo la salida exacta que se desea obtener para cada entrada.

Cuándo utilizarlo:

• Dispones de una tarea específica con un formato de entrada/salida bien definido.
• Contas con datos etiquetados de calidad, incluso en cantidades reducidas.
• Necesitas un comportamiento predecible para formas conocidas de entrada.

Entrenamiento con pares de (descripción de consulta SQL, código SQL) para la tarea de texto a SQL.

{
    "input": "Get all users who signed up last month",
    "output": "SELECT * FROM users WHERE signup_date >= DATE_SUB(NOW(), INTERVAL 1 MONTH)"
}

3. Ajuste de instrucciones

El ajuste por instrucciones es un caso especial de SFT cuyo objetivo es hacer que los modelos sigan una gran variedad de instrucciones en lenguaje natural. Los datos de entrenamiento consisten en pares (instrucción, respuesta) provenientes de numerosas tareas diferentes.

Cuándo utilizarlo:

• Deseas un asistente de uso general (como ChatGPT o Claude).
• El modelo debe poder gestionar solicitudes variadas y abiertas.
• Estás desarrollando una interfaz de chat.

Ejemplo: entrenamiento con miles de instrucciones diversas como “Resumir este artículo”, “Escribir un poema sobre X” o “Explicar Y de forma sencilla”.

Comparación

[!NOTA] Qué es lo que realmente hacen los usuarios SFT y el ajuste por instrucciones emplean el mismo objetivo basado en el siguiente token; la diferencia radica en el alcance y la estructura de los dataset. El entrenamiento previo continuo constituye un experimento independiente, al cual deben seguir pruebas tanto para evaluar las mejoras en el dominio específico como para detectar cualquier regresión en las capacidades generales.

El proceso de 7 etapas fine-tuning pipeline

Fine-tuning es un pipeline, y no una única orden. Cada etapa presenta sus propios modos de fallo, y omitir alguna de ellas suele manifestarse posteriormente como un modelo de mala calidad.

Cada etapa se basa en la anterior:

1. Preparación de datos — Definir la unidad de evaluación, dividir los datos y, a continuación, limpiarlos y formatearlos.
2. Selección del modelo — Elegir el modelo base adecuado e cargar sus pesos.
3. Configuración del entrenamiento — Configurar el hardware, los hiperparámetros y la estrategia de optimización.
4. Fine-tuning — Ejecutar SFT, DPO o el entrenamiento ORPO.
5. Evaluación — Analizar el rendimiento de Benchmark y validar la calidad.
6. Despliegue — Exportar y hacer disponible el modelo.
7. Monitoreo — Seguir de cerca el rendimiento, realizar mantenimiento e iterar.

[!ADVERTENCIA] Los datos son la base fundamental El entrenamiento reproduce defectos sistemáticos en los ejemplos. Antes de invertir tiempo en pruebas con optimizadores, es necesario examinar las etiquetas, los problemas de fuga de información, el nivel de cobertura y el cumplimiento de las políticas establecidas.

Etapa 1: Preparación de datos

La mayoría de los proyectos fine-tuning fracasan en esta fase, y no durante el entrenamiento. La preparación moderna de datos va más allá de simplemente aplicar expresiones regulares a archivos CSV.

El proceso de datos en 5 etapas pipeline

Herramientas como DataTrove y Distilabel pueden ser útiles a gran escala, pero la selección de pipeline debe basarse en la taxonomía de fallos y el contrato de datos, y no en la preferencia por una herramienta concreta.

1. Ingestión y filtrado

• Acción: descartar las respuestas de rechazo (“No puedo responder a eso”), los datos con codificación UTF-8 corrupta y los textos en idiomas no objetivo.
• Herramientas: Trafilatura para la extracción de información, FastText para la identificación del idioma.

2. Política de datos sensibles

• Acción: determinar qué es lo que el modelo está autorizado a aprender, y posteriormente redactar, tokenizar o excluir los campos personales y confidenciales según sea necesario.
• Herramientas: Microsoft Presidio o scrubadub.
• Por qué: un detector constituye únicamente un medio de control; siguen siendo aplicables los requisitos relacionados con el origen de los datos, el consentimiento, la conservación, el acceso y la eliminación.

3. Duplicación (MinHash LSH)

• Acción: eliminar duplicados casi idénticos para que el modelo no los memorice.
• Herramientas: DataTrove gestiona con eficacia el procesamiento a escala de terabytes.

4. Aumentación sintética, si es necesario

• Acción: utilizar un modelo maestro más potente (GPT-4o, DeepSeek-V3) para reescribir los datos brutos como pares de instrucción-respuesta estructurados.
• Herramientas: Distilabel.
• Validación: analizar muestras de las salidas del modelo maestro, compararlas con la misma escala de evaluación que se emplea para las etiquetas generadas por humanos, y mantener separados en la evaluación los fragmentos sintéticos de los escritos por personas reales.

5. Formato

• Acción: convertir a un formato estándar (Alpaca o ShareGPT).

Ejemplos de formatos de datos

Formato Alpaca (seguimiento de instrucciones):

{
    "instruction": "Summarize the following text.",
    "input": "The text to be summarized...",
    "output": "This is the summary."
}

Formato ShareGPT/ChatML (conversacional):

{
    "conversations": [
        { "from": "user", "value": "Hello, who are you?" },
        { "from": "assistant", "value": "I am a helpful AI assistant." }
    ]
}

Qué es lo que realmente importa

• Cobertura antes que volumen. Incluir ejemplos que representen modos de fallo distintos, y no repeticiones del caso más común y sencillo.
• Limpieza. Eliminar texto irrelevante, normalizar los espacios en blanco y mantener una formato consistente.
• Equilibrio. Conservar los casos raros importantes e informar sobre el rendimiento por cada segmento.
• Separación. Dividir los datos según la fuente, el usuario, el documento o el tiempo, cuando la división aleatoria de filas pudiera generar duplicados cercanos.
• Procedencia. Registrar la fuente, la licencia o permiso, el historial de transformaciones y la ruta de eliminación para cada versión de dataset.

Etapa 2: Selección del modelo y hardware

Elegir el modelo base y conocer el límite inferior definido por GPU determina qué es lo que realmente se puede entrenar.

Comience con el modelo base más pequeño que ya supere las verificaciones básicas indispensables. Confirme:

• Términos de licencia y redistribución para el producto previsto;
• Idioma, dominio, uso de herramientas y comportamiento de seguridad antes de la adaptación;
• Compatibilidad del tokenizador y de las plantillas de chat con dataset;
• Contexto máximo y comportamiento de truncación requeridos por los ejemplos reales;
• Soporte tanto en el motor de entrenamiento framework como en el motor de destino serving.

Fine-tuning representa una fase de adaptación y no una corrección para una base inadecuada. Si el modelo carece de las capacidades que abarca dataset, es necesario seleccionar otra base antes de continuar con la entrenamiento durante más épocas.

Ajuste el tamaño de la ejecución, no el nivel de marketing

No existe una tabla estable y duradera que relacione el “tamaño del modelo → GPU”. El consumo máximo de memoria varía en función de la precisión de los pesos, el optimizador, la cantidad de parámetros entrenables, la longitud de las secuencias, el tamaño de los microlotes, la implementación de checkpoints de activación, la forma en que se gestiona la atención, así como del sobrecoste generado por framework. Comience haciendo una estimación preliminar del uso de memoria y, a continuación, ejecute una prueba rápida de longitud máxima con la configuración técnica exacta.

El artículo original QLoRA logró adaptar un modelo LLaMA de 65 mil millones de parámetros en un único dispositivo GPU de 48 GB, dentro de su configuración específica. Dicho resultado constituye un límite útil, pero no garantiza que toda arquitectura actual de 70 mil millones de parámetros, ni ninguna longitud de contexto, kernel o algoritmo de entrenamiento, pueda adaptarse al mismo equipo.

Matemáticas de la memoria

En el caso de un modelo con (P) parámetros, solo los pesos requieren aproximadamente (2P) bytes en BF16/FP16 o (0.5P) bytes si se almacenan con cuatro bits, sin contar aún los metadatos de cuantización ni los buffers de runtime. El entrenamiento completo al estilo Adam añade además los gradientes, los estados del optimizador y, con frecuencia, pesos maestros de mayor precisión. LoRA permite evitar la mayor parte de la memoria dedicada a los estados entrenables; por su parte, QLoRA reduce aún más el espacio ocupado por los pesos base congelados. No obstante, las activaciones siguen pudiendo ser los componentes que dominen el consumo de memoria en secuencias muy largas.

Utilice este flujo de trabajo:

1. Elija la secuencia más larga y el tamaño del micro-lote que deba soportar.
2. Estime los pesos y los estados entrenables, reservando espacio adicional para las activaciones y los núcleos.
3. Ejecute un paso hacia adelante/atrás con la longitud máxima permitida.
4. Registre la memoria máxima asignada y reservada.
5. Solo entonces ajuste el tamaño del lote, el número de procesadores, la longitud de la secuencia o el conteo de GPU.

Etapa 3: Métodos de entrenamiento (PEFT y LoRA)

fine-tuning completo frente a PEFT

El proceso completo de fine-tuning (FFT) actualiza cada peso individualmente, por lo que los gradientes y el estado del optimizador escalan junto con todo el modelo. No es posible determinar el consumo máximo de memoria únicamente a partir del número de parámetros, pero este valor está muy por encima de la memoria necesaria para cargar los pesos con el fin de realizar inferencias.

El fine-tuning (PEFT) eficiente en parámetros entrena únicamente un subconjunto reducido de parámetros y congela el resto. De este modo, las operaciones matemáticas se vuelven mucho más sencillas.

LoRA: el punto de partida

LoRA (Adaptación de rango bajo) consiste en congelar una matriz preentrenada y representar su actualización aprendida mediante dos matrices más pequeñas. El artículo original justifica este enfoque partiendo de la hipótesis de que las actualizaciones de adaptación útiles presentan un rango intrínseco bajo.

Para una matriz congelada (W0 \in \mathbb{R}^{d{out} \times d_{in}}), LoRA aprende:

• (A \in \mathbb{R}^{r \times d_{in}})
• (B \in \mathbb{R}^{d_{out} \times r})

La capa adaptada es:

[ W’ = W_0 + \frac{\alpha}{r}BA ]

El adaptador cuenta con (r(d*{in}+d*{out})) parámetros entrenables en lugar de (d*{in}d*{out}) para dicha matriz. En el caso de una matriz cuadrada de 4.096 elementos con rango 16, esto supone una reducción de 128× en su tamaño, y no una reducción de 10.000× como ocurre en modelos arbitrarios. La cifra de 10.000× mencionada en el artículo LoRA se refería específicamente a una configuración de GPT-3 de 175 mil millones de parámetros que aplicaba adaptaciones a matrices seleccionadas.

Comparación de métodos PEFT

Cuándo elegir uno u otro

• LoRA: Se inicia aquí. Es rápido, eficiente en cuanto al uso de memoria y cuenta con un amplio soporte técnico.
• QLoRA: Cuando el mismo experimento LoRA no es aplicable debido a los pesos base congelados.
• DoRA: Tras una comparación directa LoRA que demuestre una mejora significativa.
• Completo fine-tuning: Solo después de PEFT se puede determinar si se trata de un cuello de botella real o de una suposición.

DoRA: LoRA descompuesto por pesos

DoRA (Adaptación de Bajo Rango Descompuesta por Pesos) separa la magnitud de cada vector de pesos de su dirección. Aplica una actualización LoRA al componente direccional, mientras que aprende la magnitud de forma independiente.

Cómo funciona:

En lugar de tratar los pesos como una única entidad, DoRA divide los pesos preentrenados en dos componentes:

1. Magnitud: un valor entrenable asociado a cada vector de pesos. 2. Dirección: un vector normalizado que se actualiza mediante matrices de rango bajo.

En notación compacta por columnas:

[ W’ = m \frac{V + BA}{\lVert V + BA \rVert_c} ]

Donde:

• m = magnitud (entrenable)
• (V) = la matriz direccional congelada
• (BA) = la actualización direccional de bajo rango aprendida
• (\lVert \cdot \rVert_c) = normalización por columnas

Qué obtienes con esa estructura adicional:

• Dispone de más grados de libertad que los LoRA estándar, ya que su magnitud puede variar de forma independiente.
• Ofrece mejores resultados que los LoRA en varias configuraciones, según se indica en el artículo original.
• Requiere parámetros y cálculos adicionales, por lo que es necesario verificar si la ventaja es real en su tarea específica y en el serving correspondiente.

Fusión de adaptadores para el aprendizaje multi-tarea

Métodos comunes de fusión:

1. Concatenación: combina los parámetros de los adaptadores y aumenta el rango efectivo. Es un método rápido y sencillo.
2. Combinación lineal: suma ponderada de los adaptadores. Permite ajustar sus parámetros de forma precisa.
3. SVD: descomposición matricial utilizada para la fusión. Ofrece mayor flexibilidad, pero es más lento.

Un adaptador para la resumenización y otro para la traducción, fusionados en un único modelo multitarea.

Etapa 4: Fine-tuning y alineación de preferencias

SFT aprende a partir de demostraciones. En cambio, la optimización de preferencias se basa en comparaciones como “la respuesta seleccionada A es mejor que la respuesta rechazada B”. Úsala únicamente cuando la preferencia entre pares sea la etiqueta adecuada para describir el error; la corrección factual y el cumplimiento de políticas suelen requerir evaluadores más robustos que una preferencia global.

PPO basado en RLHF

La receta original constaba de tres fases pipeline:

1. SFT: aprender la tarea.
2. Modelo de recompensa: entrenamiento basado en las preferencias humanas (elegidas frente a rechazadas).
3. PPO (Optimización de políticas proximal): aprendizaje por refuerzo utilizado para optimizar la política.

El costo operativo proviene de las partes móviles:

• Es complicado de implementar y mantener.
• Es costoso, ya que se deben entrenar múltiples modelos.
• El muestreo on-policy y la optimización de recompensas requieren un control riguroso de la estabilidad y pruebas contra el reward-hacking.

DPO

DPO (Optimización de preferencias directas) elimina el modelo de recompensa explícito y el bucle de aprendizaje por refuerzo. Sigue optimizando el objetivo RLHF (maximización de recompensas con una restricción de divergencia KL), pero lo hace como un problema de aprendizaje supervisado reparametrizado en lugar de mediante aprendizaje por refuerzo:

{
    "prompt": "Explain quantum computing",
    "chosen": "Quantum computing uses qubits...",   # Preferred response
    "rejected": "Well, it's complicated..."        # Non-preferred response
}

Qué cambios operativos se producen:

• Ruta de código más sencilla (sin modelo de recompensa separado, sin bucle de RL).
• Un objetivo offline basado en pares de preferencias, en lugar de un aprendizaje por refuerzo on-policy.
• Una política de referencia o probabilidades de registro de referencia equivalentes en la formulación estándar.

Prototipar DPO resulta más sencillo que hacerlo con un PPO pipeline completo, pero esto no implica necesariamente una mejora automática en la calidad. Los resultados dependen de la política de partida, de la calidad de las parejas de datos, de los parámetros de pérdida, de los efectos derivados de la longitud de los inputs y del protocolo de evaluación. Es conveniente compararlo con un SFT checkpoint utilizando los mismos conjuntos de preferencias y tareas reservadas para pruebas.

ORPO

ORPO (Odds-Ratio Preference Optimization) integra la pérdida de verosimilitud logarítmica negativa SFT con una penalización basada en la razón de probabilidades aplicada a las respuestas rechazadas. Este método elimina la necesidad de utilizar un modelo de referencia independiente y permite combinar el aprendizaje por tareas con la optimización de preferencias en una sola ejecución.

Cómo funciona: ORPO utiliza una pérdida combinada que realiza dos acciones al mismo tiempo:

1. Maximiza la probabilidad de que se elija la respuesta adecuada (aprendizaje de la tarea).
2. Castiga la respuesta rechazada mediante un término basado en la relación de probabilidades (aprendizaje de preferencias).

Hipérmparametros que merecen atención:

from trl import ORPOConfig

config = ORPOConfig(
    learning_rate=8e-6,  # Very low, as recommended by the ORPO paper
    beta=0.1,            # Controls strength of preference penalty
    # ... other params
)

• Tasa de aprendizaje: el artículo empleó tasas bajas en sus experimentos; ajuste este valor en función de su modelo, lotes y datos, en lugar de copiar directamente un valor como regla general.
• Beta: controla el término de preferencia en relación con el término SFT.

El compromiso:

• Una sola fase de entrenamiento en lugar de dos.
• No se utiliza modelo de recompensa.
• No se realiza paso forward con el modelo de referencia.
• Se ejecuta un proceso acoplado: si el aprendizaje de tareas o el comportamiento de preferencia regresan, no existe ningún SFT checkpoint intermedio generado a partir del mismo pipeline que pueda analizarse.

Elige entre los diseños de datos y evaluación:

• Utilice DPO cuando ya cuente con un SFT checkpoint satisfactorio y desee realizar un experimento de preferencias offline más sencillo.
• Pruebe ORPO cuando un objetivo de una sola etapa, sin necesidad de referencias externas, se ajuste a sus restricciones de datos y operativas.
• Empiece a emplear PPO-based RLHF cuando sea necesario realizar muestreo en línea basado en una recompensa aprendida de forma explícita, y pueda monitorear la explotación de dicha recompensa.

El valor por defecto en todas las tareas es “ninguno”. Es necesario mantener una línea de base exclusiva basada en SFT y reportar tanto las métricas relacionadas con la tarea como las métricas de preferencia.

Fine-tuning frameworks

Frameworks La superposición y los cambios ocurren con gran rapidez. Es necesario seleccionar según la ruta de ejecución que se vaya a soportar, fijar las versiones y mantener la configuración de entrenamiento lo suficientemente portátil como para poder reproducirla fuera de un entorno de notebooks.

Unsloth: eficiencia en velocidad y consumo de memoria

Unsloth se integra con Hugging Face trl y transformers Además, ofrece núcleos optimizados, mecanismos de checkpointing y rutas fine-tuning cuantizadas para los modelos compatibles.

• Núcleos personalizados de Triton GPU para mecanismos de atención, RoPE y entropía cruzada que evitan la sobrecarga generada por PyTorch.
• Proceso de retropropagación eficiente en términos de memoria, que vuelve a calcular las activaciones durante el paso hacia atrás en lugar de almacenarlas en memoria.
• Operaciones fusionadas que combinan varios pasos (normalización por capa + transformación lineal, entre otras) en una sola llamada a GPU.
• Cuantización de 4 bits integrada directamente en el flujo de QLoRA, con una descuantización optimizada.

[!IMPORTANTE] El orden de importación es crucial Sigue el orden de importación del ejemplo de Unsloth correspondiente a la versión que hayas fijado. Unsloth aplica parches durante el proceso de importación, por lo que es necesario importarlo primero. trl y transformers Evita la omisión de optimizaciones o errores propios de determinadas versiones.

# ✅ Correct order
from unsloth import FastLanguageModel  # Must be first!
from trl import SFTTrainer
from transformers import TrainingArguments

# Avoid this order with Unsloth's patched path
from trl import SFTTrainer
from unsloth import FastLanguageModel

Ideal para: entrenamiento individual con GPU, prototipado, cuadernos de trabajo de Colab, y para todo aquel que deba hacer frente a la factura de GPU.

Las cifras relativas a la velocidad de publicación y al consumo de memoria varían en función del modelo, de la longitud de la secuencia, del lote de procesamiento, de la precisión numérica y del hardware utilizado. Es importante considerar los tokens por segundo generados por Benchmark así como el consumo máximo de memoria en la ejecución concreta, en lugar de interpretar una relación indicada en titulares como si se tratara de una propiedad estática de framework.

Axolotl: entrenamiento impulsado por configuraciones

# config.yaml - no code required
base_model: meta-llama/Meta-Llama-3-8B
adapter: qlora
lora_r: 32
lora_alpha: 16
datasets:
    - path: data/my_data.jsonl
      type: alpaca
sample_packing: true

Ejecutar con: accelerate launch -m axolotl.cli.train config.yaml

Ideal para: ejecuciones declarativas y reproducibles, así como opciones integradas de inicio para el entrenamiento distribuido.

La principal ventaja radica en una configuración declarativa que permite su revisión, versionado y reutilización tanto en ejecuciones locales como distribuidas.

Framework comparación

Demo práctica: fine-tuning con Unsloth

He aquí un ejemplo completo de mi unsloth-finetune-demo repositorio. La demostración realiza un ajuste fino de Nemotron-Nano para function calling.

Inicio rápido

# Clone and setup
git clone https://github.com/slavadubrov/unsloth-finetune-demo.git
cd unsloth-finetune-demo

# Install with uv (recommended)
uv sync

# Run fine-tuning (quick test)
uv run finetune --max-samples 1000

Configuración

Las partes interesantes se encuentran en config.py:

# Model & Dataset
MODEL_NAME = "nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1"  # 4B params, 128K context
DATASET_NAME = "glaiveai/glaive-function-calling-v2"   # 113K examples

# LoRA Configuration
LORA_R = 16        # Adapter capacity; tune against held-out results
LORA_ALPHA = 32    # Update scaling; alpha/r is the classic LoRA scale
MAX_SEQ_LENGTH = 4096

# Candidate modules for this Llama-family model
LORA_TARGET_MODULES = [
    "q_proj", "k_proj", "v_proj", "o_proj",
    "gate_proj", "up_proj", "down_proj",
]

[!NOTE] La relación alfa-a-valor de rango alpha/r escala la actualización clásica de LoRA. alpha = 2r

Código de entrenamiento principal

from unsloth import FastLanguageModel
from trl import SFTConfig, SFTTrainer

# Load model with 4-bit quantization
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1",
    max_seq_length=4096,
    load_in_4bit=True,
)

# Add LoRA adapters
model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                    "gate_proj", "up_proj", "down_proj"],
    use_gradient_checkpointing="unsloth",  # Lower activation memory; extra compute
)

# The data step creates versioned train_dataset and eval_dataset objects.
# Each row has the chat messages and tool schemas expected by current TRL.

# Train with the current TRL configuration surface.
trainer = SFTTrainer(
    model=model,
    processing_class=tokenizer,
    train_dataset=train_dataset,
    eval_dataset=eval_dataset,
    args=SFTConfig(
        output_dir="outputs/nemotron-function-calling",
        max_length=4096,
        packing=True,
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        learning_rate=2e-4,
        num_train_epochs=3,
        bf16=True,
    ),
)
trainer.train()

Fine-tuning con Axolotl

[!NOTE] Próxima demostración Estoy trabajando en una demostración práctica con Axolotl. Hasta entonces, la Guía para acelerar el paralelismo n-D El documento proveniente de Hugging Face constituye una referencia útil para las estrategias de entrenamiento multi-GPU.

En configuraciones basadas en la configuración y distribuidas, Axolotl permite que el flujo de trabajo sea reproducible:

# axolotl_config.yaml
base_model: meta-llama/Meta-Llama-3-8B
model_type: LlamaForCausalLM

# QLoRA configuration
load_in_4bit: true
adapter: qlora
lora_r: 32
lora_alpha: 16
lora_dropout: 0.05
lora_target_modules:
    - q_proj
    - k_proj
    - v_proj
    - o_proj
    - gate_proj
    - up_proj
    - down_proj

# Dataset
datasets:
    - path: data/training_data.jsonl
      type: alpaca

# Training settings
sequence_len: 4096
sample_packing: true # Benchmark with your length distribution
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
num_epochs: 3

# Precision and attention path; verify support on the pinned stack
bf16: true
flash_attention: true

Ejecutar el entrenamiento:

axolotl train axolotl_config.yaml

Etapa 5: Evaluación

Congele el contrato de evaluación antes del primer ejecución. Como mínimo, compare la versión ajustada de checkpoint con la versión base sin ajustes, bajo las mismas condiciones de prompt, parámetros de decodificación y entorno de herramientas. Solo presente los resultados globales de calidad una vez comprobados los casos de fallo que el proyecto debía corregir.

Rastrea cuatro grupos:

1. Tarea objetivo: coincidencia exacta, éxito en la ejecución, evaluación humana, u otro resultado relacionado con el caso de uso.
2. Regresión: capacidades generales y subtareas previamente soportadas que podrían verse afectadas negativamente por la adaptación.
3. Seguridad y políticas: rechazos, fugas de datos, prompt injection, o restricciones específicas del dominio.
4. Operaciones: latencia, ancho de banda, memoria, tamaño de los artefactos, y coste en la configuración serving prevista.

Automatización de benchmarks

Utilizar lm-evaluation-harness para tareas estandarizadas relevantes, y no como sustituto de la evaluación del producto:

lm_eval --model hf \
    --model_args pretrained=./outputs/merged-model \
    --tasks hellaswag,arc_easy,mmlu \
    --batch_size 8

LLM como juez

En cuanto a la calidad subjetiva, un modelo más grande puede ayudar a realizar la puntuación, pero es necesario calibrarlo con ejemplos revisados por humanos y mantener oculta la identidad del candidato:

judge_prompt = """
Rate this response from 1-5 on:
- Relevance
- Accuracy
- Formatting

Response: {model_output}
Expected: {ground_truth}
"""

Evaluación específica del dominio

Se deben excluir los ejemplos reales por origen, usuario, documento o fecha de tal manera que los casi duplicados no puedan filtrarse entre las dos partes del conjunto de datos. En el caso de function calling, es necesario validar toda la trayectoria del proceso: selección de herramientas, argumentos utilizados, resultado de ejecución, acciones de recuperación y respuesta final. Cuando la muestra sea pequeña, se deben presentar intervalos de confianza o conteos de éxitos y fracasos correspondientes, además de analizar detenidamente cada regresión que ocurra en una franja crítica del tiempo.

Etapa 6: Despliegue y formatos de salida

Elige el artefacto en función del motor serving y del plan de reversión, y no únicamente del tamaño del archivo:

1. Adaptador LoRA

uv run finetune  # Saves ~100-500MB adapter

• Tamaño: es proporcional a los módulos objetivo, el rango, las capas y el dtype; suele ser mucho más pequeño que el modelo base.
• Útil para: el desarrollo, adaptadores de tareas versionados y motores que admiten directamente LoRA.
• Ventaja adicional: se pueden intercambiar los adaptadores sin tener que volver a descargar el modelo base.

2. Modelo fusionado

uv run finetune --merge  # Creates a standalone full model

• Tamaño: aproximadamente el tamaño total de la base checkpoint según la precisión de salida seleccionada.
• Útil para: motores o rutas de distribución que no admiten el adaptador de forma independiente.
• Compromiso: archivo resultante más grande y proceso de despliegue más lento; carga de un único modelo más sencilla.

3. Formato GGUF

uv run finetune --gguf q4_k_m  # Creates ~2-4GB quantized model

• Tamaño: depende del modelo; aproximadamente pesos de cuatro bits más metadatos para las variantes Q4.
• Mejor para: inferencia con CPU, Ollama, llama.cpp, y despliegue en entornos periféricos.
• Opciones: q4_k_m (más pequeño), q5_k_m (mayor fidelidad en el peso). q8_0 (mayor tamaño y mayor fidelidad). Medir el impacto de la tarea tras la conversión.

Etapa 7: Serving y monitoreo

Con vLLM

# Serve the base and expose a PEFT adapter as a model name.
vllm serve nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1 \
    --enable-lora \
    --lora-modules function-calling=./outputs/adapter \
    --host 0.0.0.0 \
    --port 8000 \
    --max-model-len 4096

Consulta mediante el API compatible con OpenAI:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
response = client.chat.completions.create(
    model="function-calling",
    messages=[{"role": "user", "content": "Book a flight to Tokyo"}]
)

Con Ollama (local)

# Create Modelfile
echo 'FROM ./outputs/unsloth-nemotron-function-calling-gguf/model-q4_k_m.gguf' > Modelfile

# Import to Ollama
ollama create my-function-model -f Modelfile

# Run
ollama run my-function-model

Con llama.cpp (CPU)

./llama-cli -m ./outputs/model-q4_k_m.gguf \
    -p "What's the weather in Tokyo?" \
    --ctx-size 4096

Monitorear el modelo publicado

El ciclo de vida no finaliza cuando la pérdida durante el entrenamiento alcanza un valor aceptable. Se debe registrar la versión del modelo base, el tokenizador y la plantilla de chat, el hash del adaptador, la versión de dataset, la configuración de entrenamiento y el informe de evaluación como una única unidad de lanzamiento. En producción, se debe monitorear el éxito de las tareas, las salidas inválidas, los fallos en las políticas, la latencia y la deriva de las entradas mediante los mismos datos de muestra que se utilizaron en modo offline. Asimismo, es necesario mantener los artefactos anteriores listos para ser cargados y definir un umbral de retroceso antes del despliegue.

Conclusiones clave

1. Realice el ajuste fino únicamente después de que una versión base sin ajustar y una taxonomía de fallos demuestren que la adaptación de pesos resuelve el problema.
2. El módulo de recuperación se encarga de gestionar las pruebas variables; constrained decoding se ocupa de la sintaxis; ninguno de ellos es reemplazado por SFT.
3. LoRA reduce el número de estados entrenables. QLoRA comprime adicionalmente los pesos base congelados. No atribuya las cifras de memoria de QLoRA a LoRA.
4. La cobertura de datos, la integridad de las particiones, el origen de los mismos y el enmascaramiento de pérdidas son más importantes que copiar una configuración de optimizador de moda.
5. DPO, ORPO y los diseños experimentales basados en PPO y RLHF son enfoques distintos, no una escala de calidad con un valor predeterminado universal.
6. Evalúe el comportamiento deseado, las regresiones, la seguridad y las operaciones utilizando el mismo modelo base.
7. Elija la salida del adaptador, la combinada o GGUF según los requisitos de serving y de reversión antes de iniciar el entrenamiento.

Referencias

Artículos y trabajos de investigación

• LoRA: Adaptación de bajo rango de modelos de lenguaje grandes
• QLoRA: Afinado eficiente de LLMs cuantizado
• DoRA: Adaptación de rango bajo descompuesta por pesos
• DPO: Optimización de preferencias directas
• ORPO: Optimización de la preferencia mediante razón de probabilidades
• PPO: Algoritmos de optimización de políticas proximales — OpenAI, 2017

Herramientas de procesamiento de datos

• DataTrove — Hugging Face procesamiento de datos a gran escala Distilable — Generación de datos sintéticos (Argilla)
• Procesamiento de datos — Extracción de texto de web y crawling FastText — Identificación de idioma de Facebook AI (soporta 217 idiomas) Microsoft Presidio — Detección y anonimización de PII
• scrubadub — Biblioteca en Python para la eliminación de PII

Constrained decoding

• xgrammar — Constrained decoding con autómatas finitos de estado esquemas — Generación estructurada para LLMs

Entrenamiento frameworks

• perezoso — Optimizado fine-tuning framework
• Axolotl — Entrenamiento dirigido por configuraciones y lanzadores distribuidos
• TRL — Hugging Face SFT y biblioteca de entrenamiento basado en preferencias Torchtune — PyTorch-biblioteca nativa fine-tuning

Inferencia e implementación

• vLLM LoRA adaptadores — Servir uno o varios adaptadores junto con el modelo base Ollama — Ejecutor local LLM para Mac/Windows/Linux
• llama.cpp — Inferencia CPU/GPU en formato GGUF

Evaluación

• lm-evaluation-harness — EleutherAI ha estandarizado las pruebas de rendimiento LLM.

Guías y recursos

• Repositorio de demostraciones — Ejemplo práctico de fine-tuning LLM Fine-Tuning. Intuición teórica e implementación práctica — Cuaderno de investigación de NotebookLM
• Guía para acelerar el paralelismo n-D — Hugging Face estrategias de entrenamiento multi-GPU