- Ajuste fino con LoRA entrena un conjunto diminuto de pesos adaptadores en lugar del modelo completo —típicamente del 1 al 5 % de los parámetros totales—, lo que permite ajustar finamente un modelo de 7B en una sola GPU de consumo.
- QLoRA añade cuantización de 4 bits al modelo base congelado, reduciendo aún más la VRAM: un modelo de 7B cabe en ~6 GB y uno de 13B en ~10 GB.
- Rango (r) y alpha son los dos parámetros que controlan en qué medida el adaptador puede modificar el comportamiento del modelo. Comience con r=16 y alpha=32.
- El ajuste fino suele ser la herramienta equivocada. Si su problema es falta de conocimiento, use RAG. Si se trata de formato o tono, mejore primero su indicación del sistema.
El ajuste fino con LoRA (Adaptación de bajo rango) es un método eficiente en parámetros para adaptar un modelo de lenguaje previamente entrenado a una tarea específica. En lugar de actualizar todos los pesos del modelo, LoRA congela los pesos originales e inyecta pequeñas matrices entrenables en las capas de atención. El resultado es un adaptador —un archivo habitualmente inferior a 100 MB— que se acopla al modelo base en tiempo de inferencia. Obtiene un comportamiento especializado sin tener que volver a entrenar miles de millones de parámetros.
Cómo funciona LoRA
Una matriz de pesos estándar de transformador podría ser de 4096 × 4096. LoRA descompone la actualización de esa matriz en dos matrices mucho más pequeñas: una de tamaño 4096 × r y otra de r × 4096, donde r es el rango (comúnmente entre 4 y 64). Durante el entrenamiento, solo se actualizan estas matrices de bajo rango. En la inferencia, el producto de las dos matrices pequeñas se suma de nuevo a la original congelada —no hay latencia adicional en la mayoría de las implementaciones, porque el adaptador se fusiona antes de la implementación.
Esto es importante para el hardware: como los pesos del modelo base están congelados, no necesitan estados del optimizador ni gradientes. Solo los parámetros del adaptador los requieren. Por eso los requisitos de VRAM disminuyen drásticamente en comparación con el ajuste fino completo.
LoRA frente a QLoRA
| Método | Precisión del modelo base | Precisión del adaptador | VRAM para modelo de 7B (entrenamiento) | 13B VRAM (entrenamiento) |
|---|---|---|---|---|
| Ajuste fino completo | bf16/fp16 | — | ~60 GB | ~110 GB |
| LoRA | bf16/fp16 | bf16/fp16 | ~16 GB | ~28 GB |
| QLoRA | 4 bits (NF4) | bf16/fp16 | ~6 GB | ~10 GB |
QLoRA, introducida por Dettmers et al. (2023), carga el modelo base con cuantización de 4 bits en NormalFloat (NF4) y mantiene el adaptador en precisión completa. El entrenamiento es más lento que el LoRA estándar debido a la sobrecarga de descuantización en cada paso hacia adelante, pero los ahorros de VRAM permiten entrenar modelos de 13B y 70B en hardware accesible para la mayoría de los usuarios. La calidad frente a LoRA completo suele ser prácticamente indistinguible en ajustes finos específicos de una tarea; sin embargo, en tareas complejas de razonamiento, es posible cierta degradación.
Antes de comprometerse con un hardware determinado, ejecute su modelo objetivo mediante la Calculadora de VRAM —esta herramienta tiene en cuenta el tamaño del lote y la longitud de la secuencia, ambos factores que modifican significativamente los valores estimados.
Rango y alpha: ¿qué hacen realmente?
Rango (r) controla la capacidad expresiva del adaptador. Un rango de 4 añade muy pocos parámetros y produce cambios sutiles; un rango de 64 otorga mayor capacidad al adaptador para modificar el comportamiento del modelo, pero incrementa tanto el uso de VRAM como el riesgo de sobreajuste.
Alpha (α) es un factor de escalado aplicado a la salida de LoRA antes de sumarla a los pesos congelados. La tasa de aprendizaje efectiva del adaptador escala con α/r. Mantener alpha al doble del rango (por ejemplo, r=16, alpha=32) es el punto de partida más habitual y funciona bien en la práctica.
| Uso previsto | r recomendado | alpha recomendado |
|---|---|---|
| Cambio de estilo o tono | 4–8 | 8–16 |
| Preguntas y respuestas específicas de un dominio | 16 | 32 |
| Nuevo formato de tarea (p. ej., llamadas a funciones) | 32–64 | 64–128 |
| Cambio complejo de comportamiento | 64 | 128 |
Un rango mayor no siempre implica mejores resultados. Para la mayoría de los ajustes finos orientados a instrucciones, r=16 es suficiente. Si la pérdida en validación no mejora, aumente el rango o añada más datos antes de incrementar el número de épocas.
Requisitos realistas de VRAM y tiempo
Las cifras siguientes suponen QLoRA con un tamaño de lote de 1 y una longitud de secuencia de 2048. Las configuraciones multi-GPU escalan aproximadamente de forma lineal con respecto a la VRAM, pero requieren configuraciones con FSDP o DeepSpeed.
| Tamaño del modelo | GPU mínima | GPU cómoda | ~1000 pasos (A100) |
|---|---|---|---|
| 3B | RTX 3060 (12 GB) | RTX 4070 (12 GB) | ~5 min |
| 7B | RTX 3060 (12 GB) | RTX 4080 (16 GB) | ~15 min |
| 13B | RTX 3090 (24 GB) | RTX 4090 (24 GB) | ~30 min |
| 34B | 2× RTX 3090 | A100 de 40 GB | ~90 min |
| 70B | 2× A100 de 40 GB | 4× A100 | ~4 horas |
Los costos en la nube varían. Un solo A100 de 80 GB en Lambda Labs cuesta aproximadamente $1,50–$2,00/hora a mediados de 2026. Un ajuste fino QLoRA de un modelo de 7B sobre 50 000 ejemplos suele completarse en menos de dos horas —un costo total considerablemente inferior a $5. Para tomar decisiones sobre la compra de GPU, consulte la guía de GPU para LLM locales.
Herramientas: cómo ejecutar realmente un ajuste fino con LoRA
Los dos frameworks dominantes son Hugging Face TRL + PEFT y Axolotl. Ambos soportan LoRA y QLoRA. Unsloth es una opción popular alternativa que logra un entrenamiento hasta dos veces más rápido mediante kernels CUDA personalizados.
Ejemplo mínimo con TRL + PEFT (Python)
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer, SFTConfig
import torch
bnb_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16,
)
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Meta-Llama-3-8B-Instruct",
quantization_config=bnb_config,
device_map="auto",
)
lora_config = LoraConfig(
r=16,
lora_alpha=32,
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05,
task_type="CAUSAL_LM",
)
model = get_peft_model(model, lora_config)
trainer = SFTTrainer(
model=model,
train_dataset=your_dataset, # espera una columna llamada "text"
args=SFTConfig(output_dir="./output", num_train_epochs=3),
)
trainer.train()
model.save_pretrained("./my-lora-adapter")
El adaptador guardado en ./my-lora-adapter suele tener entre 50 y 300 MB. Intégrelo en el modelo base para inferencia más rápida mediante model.merge_and_unload() antes de guardar.
Axolotl (orientado a configuración)
Axolotl gestiona todo el flujo de trabajo desde un archivo YAML, lo que facilita la reproducción de experimentos. Instálelo con pip install axolotl, entonces:
# config.yml
base_model: meta-llama/Meta-Llama-3-8B-Instruct
load_in_4bit: true
adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
datasets:
- path: ./data/train.jsonl
type: alpaca
output_dir: ./output
num_epochs: 3
accelerate launch -m axolotl.cli.train config.yml
Cuándo el ajuste fino es la herramienta equivocada
El ajuste fino con LoRA resuelve un problema específico: modificar cómo el comportamiento o las respuestas de un modelo. No inyecta de forma fiable conocimientos factuales. Si su caso de uso entra en alguna de estas categorías, otro enfoque producirá mejores resultados con menos esfuerzo:
- El modelo carece de conocimientos actualizados o propietarios. Utilice la generación aumentada con recuperación (RAG). El ajuste fino basado en hechos produce modelos que sufren alucinaciones con alta confianza sobre cualquier cosa fuera del conjunto de entrenamiento.
- Necesita que el modelo siga instrucciones específicas. Pruebe primero un mensaje del sistema detallado. Un mensaje bien diseñado aplicado a un modelo base potente suele superar el rendimiento de un modelo más pequeño ajustado finamente para la misma tarea.
- Dispone de menos de ~500 ejemplos de alta calidad. La relación señal-ruido es demasiado baja; es muy probable que el modelo sobreajuste. Mejore la calidad y cantidad de los datos o utilice el *prompting* con pocos ejemplos (*few-shot prompting*) en su lugar.
- Está realizando una fase de prototipado. El ajuste fino fija un comportamiento determinado. Utilice la API e itere sobre los mensajes hasta que el comportamiento se estabilice; luego considere el ajuste fino para reducir los costos por token a escala. La Calculadora de costos de API ayuda a cuantificar cuándo resulta más económico ajustar finamente un modelo local que pagar por cada token.
Si está evaluando a largo plazo un modelo local ajustado finamente frente a una API alojada, la calculadora de punto de equilibrio entre alojamiento local y uso de API le indica el punto de equilibrio según su volumen de uso y los costos de la GPU.
Preguntas frecuentes
¿Cuántos datos necesito para el ajuste fino con LoRA?
Para seguir instrucciones o cambiar el estilo, suelen bastar entre 500 y 2000 ejemplos de alta calidad y diversidad. Para adaptaciones complejas a un dominio específico, entre 5000 y 20000 ejemplos producen resultados más robustos. La calidad importa mucho más que la cantidad: 200 ejemplos cuidadosamente seleccionados superan a 2000 ejemplos ruidosos.
¿Puedo ejecutar inferencia con LoRA en hardware de consumo?
Sí. Un adaptador fusionado no añade sobrecarga alguna durante la inferencia respecto al modelo base. Un adaptador no fusionado añade una pequeña cantidad de cálculo adicional en cada paso hacia adelante (*forward pass*). Tanto llama.cpp como Ollama admiten directamente la carga de adaptadores LoRA convertidos al formato GGUF. Consulte la Guía de requisitos de VRAM para conocer las cifras de memoria exclusivas de la inferencia.
¿Cuál es la diferencia entre LoRA y el ajuste fino completo?
El ajuste fino completo actualiza todos los pesos del modelo y requiere almacenar los estados del optimizador para cada uno de ellos —aproximadamente 16–20 bytes por parámetro en precisión mixta con Adam—. LoRA actualiza únicamente las matrices de adaptadores de bajo rango, reduciendo así los parámetros entrenables entre 10 y 1000 veces. El compromiso radica en la capacidad: el ajuste fino completo puede remodelar el modelo de forma más exhaustiva, pero para la mayoría de tareas prácticas LoRA logra resultados comparables.
¿Qué capas debo seleccionar para aplicar LoRA?
Las capas de proyección de atención (q_proj y v_proj) son los objetivos más comunes y funcionan bien en la mayoría de las tareas. Añadir k_proj, o_projy las capas de la red neuronal de perceptrón multicapa (MLP) (gate_proj, up_proj, down_proj) incrementa la capacidad a costa de mayor VRAM y tiempos de entrenamiento ligeramente mayores. Si la VRAM es limitada, comience únicamente con las proyecciones q y v.
¿QLoRA genera un modelo peor que LoRA completo?
Para la mayoría de los ajustes finos especializados por tarea, la diferencia es despreciable. Los benchmarks publicados muestran que QLoRA obtiene resultados dentro de 1–2 puntos porcentuales respecto a LoRA completo en evaluaciones estándar. Esta brecha puede ampliarse en tareas complejas de razonamiento con conjuntos de datos muy pequeños, ya que el ruido introducido por la cuantización se acumula junto con la señal limitada. Si la precisión es crítica y dispone de suficiente VRAM, prefiera LoRA sobre un modelo base en bf16.
¿Cómo evalúo si mi ajuste fino realmente mejoró el rendimiento?
Reserve entre el 10 % y el 20 % de sus datos como conjunto de validación y supervise la pérdida de validación durante el entrenamiento. Detenga el entrenamiento cuando la pérdida de validación deje de mejorar (*early stopping*). Luego realice evaluaciones específicas para la tarea: para clasificación, mida la precisión sobre ejemplos reservados; para generación, use revisiones humanas o una configuración de «modelo de lenguaje como juez» (*LLM-as-judge*) sobre 50–100 ejemplos. Una disminución de la pérdida de validación que no se traduzca en un mejor rendimiento en la tarea indica una falta de coincidencia entre la distribución de sus datos de entrenamiento y las entradas reales.
