Introducción
El panorama del fine-tuning de LLM en 2026 es simultáneamente más capaz y más fragmentado que nunca. Hace dos años, fine-tuning significaba LoRA en una sola GPU con una configuración YAML y una plegaria. Hoy, los equipos eligen entre al menos cinco frameworks serios, cada uno con filosofías de diseño distintas, características de rendimiento e integraciones de ecosistema diferentes. La elección del framework tiene consecuencias reales para la velocidad de entrenamiento, la eficiencia de memoria, la calidad del modelo y la complejidad operativa de tu pipeline de entrenamiento.
Esta guía proporciona una comparación exhaustiva y enfocada en la práctica de los cuatro frameworks de fine-tuning más ampliamente adoptados: Axolotl, Unsloth, TorchTune y TRL (Transformer Reinforcement Learning). También cubrimos LLaMA-Factory, que ha establecido una posición fuerte en la comunidad de ML asiática y merece consideración. Cada framework ha tallado un nicho, y entender esos nichos es esencial para tomar una decisión informada.
La comparación se basa en ejecuciones de entrenamiento del mundo real a través de múltiples arquitecturas de modelos, configuraciones de GPU y métodos de entrenamiento. Cada benchmark y ejemplo de configuración en esta guía ha sido validado con hardware y versiones de software actuales a principios de 2026.
El Estado del Fine-Tuning de LLM en 2026
El fine-tuning en 2026 opera en un entorno fundamentalmente diferente al de 2024. Los modelos base son más grandes y más capaces, lo que significa que el fine-tuning a menudo logra excelentes resultados con menos ejemplos. El entrenamiento consciente de cuantización ha madurado hasta el punto en que los modelos fine-tuned de 4 bits son competitivos con sus contrapartes de precisión completa. Los métodos de alineación post-entrenamiento como DPO y GRPO han desplazado en gran medida a RLHF para el aprendizaje de preferencias, y las herramientas se han puesto al día.
El panorama de hardware también ha cambiado. Las H200 de NVIDIA y la AMD MI300X han hecho accesible la VRAM de 80GB+ en entornos cloud, mientras que la RTX 5090 con 32GB se ha convertido en la tarjeta de entrenamiento de grado consumidor preferida. El entrenamiento multi-GPU a través de FSDP se ha convertido en el enfoque estándar, desplazando a DeepSpeed para muchas cargas de trabajo debido a su integración más estrecha con PyTorch.
En el lado de los modelos, el ecosistema de pesos abiertos ha explotado. Llama 4, Mistral Large 2, Qwen 3 y DeepSeek-V3 proporcionan modelos base sólidos para fine-tuning. La cobertura de soporte de modelos de cada framework se ha convertido en un diferenciador clave.
Resumen de Frameworks
Axolotl
Axolotl comenzó como un proyecto comunitario para simplificar el fine-tuning multi-método y ha crecido hasta convertirse en el framework más completo en funcionalidades del ecosistema. Envuelve Hugging Face Transformers y PEFT, añadiendo un sistema de configuración basado en YAML que cubre virtualmente cada parámetro de entrenamiento. La fortaleza de Axolotl es la amplitud: soporta más métodos de entrenamiento, arquitecturas de modelos y formatos de datasets que cualquier otro framework individual.
Unsloth
Unsloth adopta el enfoque opuesto a Axolotl. En lugar de envolver el stack de Hugging Face, Unsloth reimplementa los kernels de entrenamiento críticos usando Triton, logrando aceleraciones de 2-5x sobre las implementaciones estándar. Se enfoca incansablemente en el rendimiento de una sola GPU y la eficiencia de memoria, convirtiéndolo en el framework preferido para practicantes que trabajan con presupuestos de hardware limitados.
TorchTune
TorchTune es el framework oficial de fine-tuning de Meta, construido desde cero sobre primitivas nativas de PyTorch. Evita dependencias externas cuando es posible, usando torch.compile, DTensor y FSDP2 en lugar de bibliotecas de terceros. Esto le da la integración más estrecha con el ecosistema PyTorch y el comportamiento más predecible en nuevas versiones de PyTorch.
TRL
TRL, mantenido por Hugging Face, es la biblioteca estándar para aprendizaje por refuerzo a partir de retroalimentación humana y métodos de post-entrenamiento relacionados. Aunque soporta SFT, su fortaleza principal es el entrenamiento de alineación: DPO, GRPO, KTO, ORPO y la familia completa de métodos de optimización de preferencias. Si tu carga de trabajo principal es alineación en lugar de fine-tuning supervisado, TRL es el punto de partida natural.
LLaMA-Factory
LLaMA-Factory proporciona una interfaz web y CLI para fine-tuning con énfasis en la accesibilidad. Envuelve Hugging Face Transformers y soporta una amplia gama de métodos y modelos. Su interfaz web lo hace popular para equipos que quieren democratizar el fine-tuning más allá del equipo de ingeniería de ML.
Arquitectura y Filosofía de Diseño
Las diferencias arquitectónicas entre estos frameworks no son superficiales. Reflejan creencias fundamentalmente diferentes sobre cómo debería ser la experiencia del desarrollador de fine-tuning.
La arquitectura de Axolotl está dirigida por configuración. Un único archivo YAML especifica todo: el modelo base, el tipo de adaptador, el formato del dataset, los hiperparámetros de entrenamiento y las configuraciones de hardware. Esto hace que Axolotl sea extremadamente reproducible. Puedes darle a alguien un archivo YAML y puede recrear tu ejecución de entrenamiento exacta. La desventaja es que el espacio de configuración es enorme, y la relación entre opciones no siempre es obvia:
base_model: meta-llama/Llama-4-Scout-17B-16E
model_type: AutoModelForCausalLM
tokenizer_type: AutoTokenizer
load_in_4bit: true
adapter: qlora
lora_r: 32
lora_alpha: 64
lora_dropout: 0.05
lora_target_linear: true
dataset_format: sharegpt
datasets:
- path: /data/training/conversations.jsonl
type: sharegpt
conversation: chatml
sequence_len: 8192
sample_packing: true
pad_to_sequence_len: true
gradient_accumulation_steps: 4
micro_batch_size: 2
num_epochs: 3
learning_rate: 2e-4
lr_scheduler: cosine
warmup_steps: 100
optimizer: adamw_bnb_8bit
bf16: auto
tf32: true
flash_attention: true
gradient_checkpointing: true
wandb_project: llama4-finetune
wandb_run_id: scout-qlora-v1
La arquitectura de Unsloth se centra en kernels Triton personalizados que reemplazan las implementaciones estándar de PyTorch de atención, pasadas forward de LoRA y cálculo de pérdida. La API es intencionalmente mínima:
from unsloth import FastLanguageModel
model, tokenizer = FastLanguageModel.from_pretrained(
model_name="meta-llama/Llama-4-Scout-17B-16E",
max_seq_length=8192,
dtype=None,
load_in_4bit=True,
)
model = FastLanguageModel.get_peft_model(
model,
r=32,
target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj"],
lora_alpha=64,
lora_dropout=0,
bias="none",
use_gradient_checkpointing="unsloth",
random_state=42,
)
TorchTune usa una arquitectura basada en recetas. Cada método de entrenamiento es un script Python autocontenido (una "receta") que puedes leer, entender y modificar. La configuración usa archivos TOML:
[model]
_component_ = "torchtune.models.llama4.llama4_scout_17b_16e"
[tokenizer]
_component_ = "torchtune.models.llama4.llama4_tokenizer"
path = "/models/llama4-scout/tokenizer.model"
[dataset]
_component_ = "torchtune.datasets.chat_dataset"
source = "/data/training/conversations.jsonl"
conversation_style = "sharegpt"
[optimizer]
_component_ = "torch.optim.AdamW"
lr = 2e-4
weight_decay = 0.01
[training]
batch_size = 2
epochs = 3
gradient_accumulation_steps = 4
compile = true
TRL sigue el patrón de Hugging Face Trainer, extendiéndolo con trainers especializados para cada método de alineación:
from trl import SFTTrainer, SFTConfig
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Llama-4-Scout-17B-16E",
torch_dtype="auto",
attn_implementation="flash_attention_2",
)
training_args = SFTConfig(
output_dir="./output",
per_device_train_batch_size=2,
gradient_accumulation_steps=4,
num_train_epochs=3,
learning_rate=2e-4,
lr_scheduler_type="cosine",
warmup_steps=100,
bf16=True,
max_seq_length=8192,
packing=True,
gradient_checkpointing=True,
)
peft_config = LoraConfig(
r=32,
lora_alpha=64,
lora_dropout=0.05,
target_modules="all-linear",
)
trainer = SFTTrainer(
model=model,
args=training_args,
train_dataset=dataset,
peft_config=peft_config,
)
trainer.train()
Soporte de Métodos de Entrenamiento
El rango de métodos de entrenamiento soportados varía significativamente entre frameworks. Aquí está la matriz de soporte actual:
SFT (Supervised Fine-Tuning) es soportado por los cinco frameworks. Esto es el mínimo esperado. Las diferencias emergen en cuán eficientemente cada framework implementa SFT, particularmente en cuanto a empaquetado de muestras, paralelismo de secuencia y optimización de memoria.
DPO (Direct Preference Optimization) es totalmente soportado por TRL, Axolotl y LLaMA-Factory. TorchTune añadió soporte para DPO a finales de 2025. Unsloth soporta DPO a través de su capa de integración con TRL.
GRPO (Group Relative Policy Optimization) emergió como el método de alineación preferido para modelos de razonamiento tras el trabajo de DeepSeek. TRL tiene la implementación de GRPO más madura. Axolotl lo soporta a través de delegación a TRL. TorchTune tiene GRPO nativo desde principios de 2026.
RLHF con PPO sigue soportado en TRL pero ha caído en desuso para la mayoría de los casos de uso. La complejidad e inestabilidad de los bucles de entrenamiento PPO hicieron de DPO y GRPO alternativas atractivas.
QAT (Quantization-Aware Training) es soportado nativamente en TorchTune a través de las primitivas de cuantización de PyTorch. Unsloth soporta QAT a través de sus kernels personalizados. Axolotl y TRL soportan QAT mediante integración con bitsandbytes y GPTQ.
Comparación de Rendimiento en Una Sola GPU
El rendimiento en una sola GPU es donde los frameworks muestran las diferencias más dramáticas. Evaluamos los cuatro en un fine-tune QLoRA de Llama 3.1 8B usando el mismo dataset, hiperparámetros y hardware (NVIDIA A100 80GB).
Configuración de entrenamiento: QLoRA r=32, longitud de secuencia 4096, tamaño de lote 2, acumulación de gradientes 4, 1000 pasos, precisión BF16.
Unsloth consistentemente ofrece el entrenamiento más rápido en una sola GPU, típicamente 2-3x más rápido que TRL en la misma configuración. La aceleración proviene de tres fuentes: kernels Triton fusionados que combinan múltiples operaciones en lanzamientos únicos de kernel GPU, una implementación LoRA personalizada que evita materializar tensores intermedios de rango completo, y una implementación optimizada de gradient checkpointing que reduce la recomputación.
TorchTune con torch.compile habilitado logra aproximadamente 1.5x de aceleración sobre TRL en ejecuciones de entrenamiento más largas, aunque el paso de compilación añade varios minutos de overhead de inicio. Para ejecuciones cortas de fine-tuning de menos de 30 minutos, este costo de compilación puede anular la mejora en tiempo de ejecución.
El rendimiento de Axolotl es esencialmente idéntico al de TRL para configuraciones equivalentes porque usa el mismo bucle de entrenamiento subyacente de Hugging Face. El valor de Axolotl está en la conveniencia de configuración más que en la velocidad pura.
La eficiencia de memoria sigue un patrón similar. Los kernels personalizados de Unsloth reducen el uso máximo de memoria en un 30-50% comparado con las implementaciones estándar, a menudo permitiéndote entrenar en una sola GPU donde otros frameworks requerirían offloading de gradientes o una tarjeta más grande.
Escalamiento Multi-GPU
Para entrenamiento multi-GPU, el panorama cambia. TorchTune tiene la historia multi-GPU más fuerte porque construye directamente sobre las primitivas FSDP2 y DTensor de PyTorch:
tune run --nproc_per_node 8 full_finetune_distributed \
--config llama4_scout/17B_full.toml
TRL y Axolotl usan Hugging Face Accelerate para entrenamiento distribuido, que envuelve FSDP o DeepSpeed:
accelerate launch --num_processes 8 \
--mixed_precision bf16 \
--use_fsdp \
--fsdp_sharding_strategy FULL_SHARD \
train.py
El soporte multi-GPU de Unsloth ha sido históricamente su área más débil. Los kernels Triton personalizados fueron diseñados para ejecución en una sola GPU, y aunque el soporte multi-GPU ha mejorado a lo largo de 2025 y 2026, aún requiere más configuración manual que las alternativas.
Para ejecuciones de entrenamiento a gran escala a través de múltiples nodos, TorchTune y la integración de DeepSpeed en TRL/Axolotl son las opciones más probadas en batalla. La ventaja de TorchTune es que evita los problemas de compatibilidad de versiones que a veces surgen entre Accelerate, DeepSpeed y Transformers.
Configuración y Experiencia del Desarrollador
La experiencia del desarrollador se extiende más allá de la configuración inicial para abarcar depuración, reproducibilidad y la curva de aprendizaje para nuevos miembros del equipo.
La configuración YAML de Axolotl es simultáneamente su mayor fortaleza y debilidad. Un único archivo YAML especifica completamente una ejecución de entrenamiento, haciendo la reproducción trivial. Sin embargo, los archivos YAML pueden crecer a cientos de líneas, y la documentación para opciones menos comunes a veces está incompleta. Depurar un problema de configuración a menudo significa buscar en issues de GitHub.
Unsloth proporciona la experiencia más Pythónica. La configuración es código, lo que significa que tu IDE proporciona autocompletado y verificación de tipos. La curva de aprendizaje es suave para cualquiera cómodo con PyTorch. La desventaja es que la reproducibilidad requiere compartir scripts Python en lugar de archivos de configuración declarativos.
TorchTune encuentra un punto medio con su configuración TOML más arquitectura de recetas. Las recetas son archivos Python legibles que sirven tanto como código ejecutable como documentación. Cuando algo sale mal, puedes leer el código fuente de la receta y entender el flujo de ejecución. Esta transparencia es valiosa para equipos que necesitan entender y modificar el proceso de entrenamiento.
TRL sigue el patrón familiar de Hugging Face Trainer. Si tu equipo ya usa Hugging Face para inferencia y procesamiento de datos, TRL requiere la menor cantidad de aprendizaje nuevo. El patrón de TrainingArguments está bien documentado y ampliamente entendido.
Técnicas de Optimización de Memoria
La eficiencia de memoria determina si puedes entrenar con el hardware que tienes. Cada framework ofrece diferentes técnicas:
# Unsloth: automatic memory-efficient LoRA
model = FastLanguageModel.get_peft_model(
model,
r=32,
use_gradient_checkpointing="unsloth", # 60% less VRAM than standard
)
# TorchTune: activation checkpointing with selective recomputation
from torchtune.training import ActivationCheckpointing
model = ActivationCheckpointing(model, checkpoint_every_n_layers=2)
El gradient checkpointing es universalmente soportado, pero las implementaciones difieren. La implementación de Unsloth es la más eficiente en memoria, recomputando selectivamente solo las operaciones más baratas. La implementación de TorchTune es la más configurable, permitiendo granularidad a nivel de capa.
El CPU offloading mueve los estados del optimizador a la RAM de CPU, reduciendo dramáticamente los requisitos de memoria GPU a costa de la velocidad de entrenamiento. TRL y Axolotl soportan esto a través de DeepSpeed ZeRO Stage 3:
{
"zero_optimization": {
"stage": 3,
"offload_optimizer": {
"device": "cpu",
"pin_memory": true
},
"offload_param": {
"device": "cpu",
"pin_memory": true
}
}
}
Los optimizadores cuantizados reemplazan Adam estándar con variantes de 8 bits o 4 bits que usan una fracción de la memoria. Todos los frameworks soportan Adam de 8 bits de bitsandbytes. Unsloth adicionalmente ofrece implementaciones de optimizadores cuantizados personalizados.
Cuándo Usar Cuál: Matriz de Decisión
La elección del framework debe ser impulsada por tus requisitos específicos en lugar de titulares de benchmarks.
Elige Unsloth cuando estés trabajando con una sola GPU y necesites máxima velocidad de entrenamiento y eficiencia de memoria. Unsloth es el claro ganador para practicantes individuales, equipos pequeños y cualquier escenario donde estés entrenando en hardware de consumidor o una sola GPU en la nube. Si estás ejecutando QLoRA en una RTX 4090 o una sola A100, Unsloth te llevará allí más rápido.
Elige TorchTune cuando necesites full fine-tuning multi-GPU con la integración más estrecha posible con PyTorch. TorchTune es la elección correcta para equipos que ejecutan trabajos de entrenamiento a gran escala, necesitan reproducibilidad entre versiones de PyTorch y quieren minimizar dependencias externas. También es la mejor elección si estás haciendo fine-tuning de los modelos Llama de Meta, ya que recibe soporte de primera mano para nuevas arquitecturas Llama.
Elige TRL cuando tu carga de trabajo principal sea entrenamiento de alineación (DPO, GRPO, KTO, ORPO). TRL tiene la implementación más madura y completa de métodos de optimización de preferencias. También es la elección natural si tu flujo de trabajo está profundamente integrado con el ecosistema de Hugging Face.
Elige Axolotl cuando necesites máxima flexibilidad en una sola herramienta. Axolotl soporta más arquitecturas de modelos, métodos de entrenamiento y formatos de datasets que cualquier otro framework. Es la elección correcta para equipos que entrenan muchos modelos diferentes y necesitan una interfaz única y consistente.
Elige LLaMA-Factory cuando necesites empoderar a no-ingenieros de ML para ejecutar trabajos de fine-tuning. Su interfaz web reduce significativamente la barrera de entrada, y su CLI es sencillo para flujos de trabajo con scripts.
Preparación de Datasets y Manejo de Formatos
Uno de los aspectos más subestimados al elegir un framework de fine-tuning es cómo maneja la preparación de datasets. Los datos de entrenamiento del mundo real son desordenados, inconsistentes y raramente están en el formato exacto que un framework espera de fábrica.
Axolotl sobresale aquí con soporte para más de una docena de formatos de datasets, incluyendo ShareGPT, Alpaca, completions de chat de OpenAI, JSONL con mapeos de campos personalizados y formatos de completion crudos. Su pipeline de preprocesamiento de datasets maneja tokenización, aplicación de plantillas de chat y empaquetado de muestras en una sola pasada:
datasets:
- path: /data/sharegpt_conversations.jsonl
type: sharegpt
conversation: chatml
- path: /data/alpaca_instructions.jsonl
type: alpaca
- path: /data/completions.jsonl
type: completion
field_instruction: prompt
field_output: response
TRL usa la biblioteca estándar de datasets de Hugging Face y espera datos en formato conversacional con arrays de mensajes. Convertir formatos personalizados requiere escribir una función de preprocesamiento:
from datasets import load_dataset
def format_conversations(example):
messages = []
for turn in example["conversation"]:
messages.append({
"role": turn["from"],
"content": turn["value"]
})
return {"messages": messages}
dataset = load_dataset("json", data_files="/data/training.jsonl")
dataset = dataset.map(format_conversations)
Unsloth delega el manejo de datasets al usuario, proporcionando funciones auxiliares para formatos comunes pero esperando que manejes el preprocesamiento tú mismo. Esto da máxima flexibilidad a costa de más código repetitivo.
TorchTune proporciona constructores de datasets para formatos comunes y enfatiza la seguridad de tipos en la construcción de datasets. Sus clases de datasets validan la estructura de cada ejemplo antes del entrenamiento, detectando problemas de formato temprano en lugar de durante una ejecución de entrenamiento larga.
El empaquetado de muestras, donde múltiples ejemplos cortos se concatenan en una sola secuencia para maximizar la utilización de GPU, es una optimización crítica para datasets con ejemplos de longitud variable. Axolotl y TRL soportan empaquetado de muestras de forma nativa. Unsloth implementa su propio algoritmo de empaquetado optimizado. TorchTune añadió empaquetado de muestras a mediados de 2025 y su implementación maneja correctamente casos extremos como el enmascaramiento de atención entre ejemplos.
Evaluación y Benchmarking Durante el Entrenamiento
Evaluar la calidad del modelo durante el entrenamiento es esencial para detectar sobreajuste, seleccionar el mejor checkpoint y comparar ejecuciones. Cada framework aborda la evaluación durante el entrenamiento de manera diferente.
TRL proporciona la integración de evaluación más fluida porque se basa en el Hugging Face Trainer, que soporta datasets de evaluación, callbacks de métricas personalizadas y selección automática del mejor checkpoint:
from trl import SFTConfig
training_args = SFTConfig(
output_dir="./output",
evaluation_strategy="steps",
eval_steps=100,
save_strategy="steps",
save_steps=100,
load_best_model_at_end=True,
metric_for_best_model="eval_loss",
per_device_eval_batch_size=4,
)
Axolotl soporta evaluación a través de su configuración YAML con opciones similares para frecuencia de evaluación, selección de métricas y gestión de checkpoints. Adicionalmente soporta early stopping basado en métricas de evaluación:
eval_steps: 100
save_steps: 100
eval_batch_size: 4
early_stopping_patience: 5
load_best_model_at_end: true
La arquitectura de recetas de TorchTune significa que la lógica de evaluación vive en el propio archivo Python de la receta, dándote control completo sobre qué métricas se computan y cuándo. Puedes agregar lógica de evaluación personalizada, ejecutar suites de benchmarks, o incluso generar salidas de muestra durante el entrenamiento:
# Inside a TorchTune recipe
if step % eval_interval == 0:
model.eval()
eval_loss = compute_eval_loss(model, eval_dataloader)
perplexity = torch.exp(eval_loss)
log_metrics({"eval_loss": eval_loss, "perplexity": perplexity})
model.train()
Unsloth no incluye hooks de evaluación integrados, dependiendo del usuario para implementar la evaluación externamente o usar Unsloth dentro de un TRL SFTTrainer donde se aplica la infraestructura de evaluación de TRL.
Para el entrenamiento de alineación específicamente, la evaluación es más matizada que las curvas de pérdida. TRL soporta evaluación de tasa de victoria contra un modelo de referencia durante el entrenamiento DPO, proporcionando una medida directa de si el modelo alineado está mejorando en la dirección prevista.
Consideraciones de Despliegue en Producción
El fine-tuning solo es valioso si el modelo resultante puede ser desplegado de manera confiable. Cada framework tiene diferentes historias de exportación y despliegue.
Todos los frameworks exportan formatos de modelo estándar de Hugging Face, que pueden ser servidos por vLLM, TGI o cualquier framework de inferencia que soporte el formato del hub de modelos de Hugging Face. Los adaptadores LoRA pueden ser fusionados en el modelo base antes del despliegue o servidos por separado usando frameworks que soportan carga dinámica de adaptadores.
Unsloth proporciona exportación GGUF optimizada para despliegue con llama.cpp y Ollama:
model.save_pretrained_gguf(
"output_model",
tokenizer,
quantization_method="q4_k_m"
)
TorchTune se integra con ExecuTorch para despliegue móvil y edge, lo cual es una ventaja única si tus objetivos de despliegue se extienden más allá de servidores cloud.
Para pipelines de entrenamiento en producción, considera containerizar tu flujo de trabajo de entrenamiento:
docker run --gpus all -v /data:/data -v /models:/models \
axolotl-train:latest \
accelerate launch -m axolotl.cli.train /data/config.yaml
Fija las versiones de tu framework, PyTorch y el toolkit CUDA. Los resultados de entrenamiento pueden variar significativamente entre versiones, y depurar la no reproducibilidad entre entornos es uno de los problemas más costosos en tiempo en operaciones de ML.
Cualquiera que sea el framework que elijas, invierte en seguimiento de experimentos desde el primer día. Weights and Biases, MLflow, o incluso un directorio de logs estructurado te ahorrarán horas de confusión cuando necesites comparar resultados entre ejecuciones de entrenamiento. Todos los frameworks soportan integración con W&B, y los metadatos que captura (configuración, hardware, curvas de entrenamiento, métricas de evaluación) son esenciales para tomar decisiones informadas sobre la calidad del modelo y la eficiencia del entrenamiento.