LoRA y QLoRA: fine-tuning eficiente al alcance de un solo portátil

LoRA (Low-Rank Adaptation) y QLoRA (Quantized LoRA) democratizaron el fine-tuning de modelos de lenguaje grandes al resolver el problema central que lo hacía prohibitivo: la memoria de GPU. La idea detrás de LoRA es elegante en su simplicidad. En lugar de actualizar todos los parámetros del modelo durante el entrenamiento, añade matrices de adaptación de rango bajo. Esas matrices aprenden el delta entre el comportamiento del modelo base y el comportamiento deseado.

QLoRA lleva esa idea más lejos combinando cuantización del modelo base con los adaptadores LoRA, lo que hace viable el fine-tuning de modelos de 70 B en hardware de consumo.

Puntos clave

• LoRA añade matrices de bajo rango (rango 4-64) en capas de atención; el modelo base permanece congelado.

• QLoRA cuantiza el modelo base a 4 bits (NF4) y solo mantiene los adaptadores LoRA en precisión completa, reduciendo la memoria necesaria en un 65-75 %.

• Un Llama 3 8B requiere 128 GB de VRAM para fine-tuning completo; con QLoRA cabe en una RTX 3090 de 24 GB.

• La pérdida de calidad frente al fine-tuning completo es del 1-3 % en benchmarks estándar, un margen asumible cuando adaptas el modelo a un dominio concreto.

• La decisión entre LoRA/QLoRA y prompt engineering depende del volumen de datos disponible y la especificidad del dominio.

El problema que resuelven

El fine-tuning tradicional de un modelo Llama 3 de 8 B requiere almacenar simultáneamente:

• Los parámetros del modelo: 8 B × 4 bytes = 32 GB solo para los pesos.

• Los gradientes de entrenamiento: otros 32 GB.

• El estado del optimizador Adam: 64 GB adicionales (dos momentos por parámetro).

• Total: 128 GB de VRAM, el equivalente a cuatro A100 de 80 GB.

A escala de 70 B, el coste se multiplica por 8,75x y supera lo que puede comprarse con cualquier presupuesto razonable para experimentación.

LoRA resuelve el problema con una observación teórica del paper original de Hu et al.^[1]: los cambios que el fine-tuning induce en los pesos del modelo tienen rango intrínseco bajo. No necesitas actualizar una matriz densa de millones de parámetros; puedes aproximar ese cambio con el producto de dos matrices mucho más pequeñas:

ΔW ≈ A × B
donde A ∈ ℝ^(d×r) y B ∈ ℝ^(r×k), con r << d y r << k

Si el rango r es 8 y la dimensión original es 4096, el número de parámetros entrenables cae de 4096² ≈ 16 M a 2 × 4096 × 8 = 65 k. Una reducción de 250x en parámetros entrenables, lo que implica una reducción proporcional en gradientes y estado del optimizador.

QLoRA: cuantización más adaptadores

QLoRA añade un paso más: cuantiza el modelo base a NF4 (Normal Float 4-bit). Ese formato preserva la distribución de los pesos de los LLM mejor que la cuantización entera estándar.

El paper de Dettmers y otros^[2] introdujo la técnica. Reporta el finetuning de un modelo de 65 B en una sola GPU de 48 GB sin pérdida de rendimiento frente a fine-tuning completo en 16 bits. Sobre ese modelo cuantizado, los adaptadores LoRA se entrenan en BFloat16 completo.

La combinación permite:

• Cargar un modelo de 70 B en cuatro GPU de 24 GB (en lugar de diez de 80 GB).

• Cargar un modelo de 7 B en una sola GPU de 8 GB.

• Fine-tune de modelos de 13 B en un laptop con GPU RTX 3080 de 16 GB.

La pérdida de calidad de NF4 frente a FP16 está bien documentada: entre el 1 % y el 3 % en benchmarks de razonamiento y coding. Ese margen es asumible cuando adaptas el modelo a un dominio específico.

Flujo de trabajo con PEFT y Hugging Face

El ecosistema de Hugging Face hace que el flujo sea sorprendentemente directo. La librería PEFT^[3] (Parameter-Efficient Fine-Tuning) gestiona los adaptadores LoRA; transformers carga el modelo base; trl (Transformer Reinforcement Learning) aporta SFTTrainer para fine-tuning supervisado:

from transformers import AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer

# Cargar modelo cuantizado (QLoRA)
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype="bfloat16",
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Meta-Llama-3-8B-Instruct",
    quantization_config=bnb_config,
    device_map="auto",
)

# Configurar adaptadores LoRA
lora_config = LoraConfig(
    r=16,                     # rango de las matrices
    lora_alpha=32,            # factor de escala
    target_modules=["q_proj", "v_proj"],  # capas a adaptar
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# trainable params: 5,242,880 || all params: 8,035,885,056 || trainable%: 0.0653

El resultado: menos del 0,07 % de los parámetros son entrenables, con una reducción de memoria proporcional en gradientes y estado del optimizador.

Arquitectura Transformer completa con sus bloques de codificador y decodificador, capas de atención multi-cabezal y capas feed-forward. Ahí es donde LoRA inserta las matrices de adaptación de bajo rango durante el fine-tuning (Imagen: dvgodoy, CC BY 4.0, vía Wikimedia Commons)

Elección de hiperparámetros

Los hiperparámetros de LoRA que más impactan el resultado:

• Rango (r): valores bajos (4-8) para tareas simples de estilo o formato; valores medios (16-32) para adaptación de dominio; valores altos (64-128) para cambios de comportamiento más profundos. A mayor rango, más parámetros entrenables y mayor capacidad, pero también mayor riesgo de overfitting.

• lora_alpha: 2× el rango como valor de partida. Controla el factor de escala de los adaptadores.

• target_modules: las capas de proyección de query y valor (q_proj, v_proj) son el mínimo; añadir proyecciones de key (k_proj) y output (o_proj) mejora la calidad a costa de más parámetros.

• Learning rate: entre 1e-4 y 3e-4, por debajo de lo que usarías en fine-tuning completo.

Para modelos que luego servirás con vLLM en producción, asegúrate de que el formato de los adaptadores LoRA es compatible con la versión de vLLM que usas. El soporte de Multi-LoRA permite servir más de un adaptador sobre el mismo modelo base.

LoRA/QLoRA frente a prompt engineering

La decisión entre fine-tuning y prompt engineering depende de tres factores:

Cuándo el fine-tuning compensa:

• Tienes más de 500-1 000 ejemplos de entrenamiento de alta calidad.

• El dominio tiene vocabulario, formato o razonamiento específicos que el modelo base no conoce.

• La tarea requiere consistencia alta de formato (el prompt engineering puede dar variabilidad indeseada).

• El coste de tokens en producción es significativo; un modelo fine-tuned necesita prompts más cortos.

Cuándo el prompt engineering es suficiente:

• Los datos de entrenamiento son escasos o difíciles de obtener.

• La tarea es razonablemente general y el modelo base la resuelve bien con instrucciones.

• Necesitas iterar rápido sin ciclos de entrenamiento.

• La alucinación del modelo base es aceptable para el caso de uso.

El error más común es hacer fine-tuning sobre datos insuficientes (<200 ejemplos) esperando mejoras grandes. Con pocos datos, el modelo aprende el formato pero pierde generalización. Con LoRA/QLoRA hay poca fricción técnica para experimentar, pero eso no elimina el requisito de tener datos de calidad.

Despliegue de adaptadores LoRA

Una vez entrenado, el adaptador LoRA se guarda como un fichero independiente del modelo base: 10-200 MB frente a los gigabytes del modelo completo. Las opciones de despliegue:

• Fusión: merge_and_unload() fusiona los pesos del adaptador en el modelo base, generando un modelo estándar que cualquier runtime puede servir.

• Multi-LoRA con vLLM: servir más de un adaptador sobre el mismo modelo base, conmutando por petición. Eficiente cuando tienes más de un fine-tune especializado; la documentación de vLLM sobre adaptadores LoRA^[4] detalla cómo cargarlos y descargarlos en caliente.

• Adaptador separado con transformers: carga el modelo base más el adaptador dinámicamente; útil para experimentación.

Para observabilidad del modelo fine-tuned en producción, el reto específico de los adaptadores LoRA es saber qué adaptador se usó en cada inferencia. Ese campo no sale de la instrumentación por defecto: lo añades tú como atributo de la traza.

Conclusión

LoRA y QLoRA eliminaron la barrera de hardware que hacía prohibitivo el fine-tuning para quien no tiene un clúster de GPU. Con QLoRA, un modelo de 7 B cabe en una GPU de 8 GB, y la pérdida de calidad frente al fine-tuning completo es marginal en la práctica. El verdadero cuello de botella ya no es el hardware ni el framework. Son los datos de entrenamiento de calidad y la evaluación rigurosa de si el fine-tuning mejora lo que importa para tu caso de uso.

Este artículo también está disponible en inglés: LoRA and QLoRA: Efficient Fine-Tuning on a Single Laptop.

Fuentes:

1. Hu et al., LoRA: Low-Rank Adaptation of Large Language Models (arXiv:2106.09685)^[1]
2. Dettmers et al., QLoRA: Efficient Finetuning of Quantized LLMs (arXiv:2305.14314)^[2]
3. Hugging Face, documentación de PEFT^[3]
4. vLLM, documentación de adaptadores LoRA^[4]

Preguntas frecuentes

¿Cuánta VRAM necesito para hacer fine-tuning de un Llama 3 8B con QLoRA?

Cabe en una RTX 3090 de 24 GB. El fine-tuning completo del mismo modelo requiere 128 GB de VRAM: 32 GB de pesos, 32 GB de gradientes y 64 GB de estado del optimizador Adam. Son cuatro A100 de 80 GB, mientras que QLoRA cuantiza el modelo base a NF4 y entrena solo los adaptadores. Con eso, un 7 B cabe en una GPU de 8 GB y uno de 13 B en un portátil con RTX 3080; uno de 70 B necesita cuatro GPU de 24 GB.

¿Cuánta calidad pierdo con QLoRA frente al fine-tuning completo?

Entre un 1% y un 3% en benchmarks estándar de razonamiento y coding, una pérdida asumible cuando adaptas el modelo a un dominio específico. El paper de Dettmers et al. reporta el fine-tuning de un modelo de 65 B en una sola GPU de 48 GB. No hay pérdida de rendimiento frente al fine-tuning completo en 16 bits. El formato NF4 (Normal Float 4-bit) preserva mejor la distribución de los pesos de los LLM que la cuantización entera estándar.

¿Cuántos ejemplos necesito antes de que el fine-tuning con LoRA compense frente al prompt engineering?

Más de 500-1 000 ejemplos de alta calidad, y que el dominio tenga vocabulario, formato o razonamiento que el modelo base no conoce o que la tarea exija consistencia alta de formato. El error más común es hacer fine-tuning con menos de 200 ejemplos esperando mejoras grandes: con pocos datos el modelo aprende el formato pero pierde generalización. Si los datos son escasos o necesitas iterar rápido sin ciclos de entrenamiento, el prompt engineering es suficiente.

Fuentes

1. paper original de Hu et al.
2. paper de Dettmers y otros
3. PEFT
4. documentación de vLLM sobre adaptadores LoRA