Más allá de LoRA: elegir la mejor técnica PEFT | Keryc
Si vas a fine-tunear un modelo abierto con tus propios datos, probablemente hayas oído hablar de PEFT (parameter-efficient fine-tuning) y de su rey aparente: LoRA. ¿Significa eso que LoRA es siempre la mejor opción? No necesariamente. En este artículo técnico te explico por qué, cómo evaluar alternativas y qué herramientas te ayudan a tomar una decisión informada.
¿Por qué existe PEFT y por qué importa?
Entrenar un modelo desde cero es caro y lento. Fine-tuning de un modelo grande parece la solución natural, pero consume mucha memoria: en entrenamiento necesitas espacio para las copias del modelo, gradientes y optimizadores. La cuantización reduce el tamaño en memoria, pero no permite ajustar directamente los pesos. Ahí entra PEFT: un conjunto de técnicas que permiten ajustar modelos gastando solo una fracción de memoria.
¿Qué ganas con PEFT? Checkpoints pequeños, menor riesgo de olvido catastrófico, posibilidad de fine-tunear modelos cuantizados y servir múltiples adaptaciones sobre la misma base. En la práctica, eso significa poder experimentar en hardware de consumidor y escalar menos en costos.
LoRA: por qué domina y por qué esto puede engañar
LoRA (Low Rank Adaptation) agrega matrices de baja dimensión sobre el modelo base y entrena solo esas nuevas matrices. Es simple, efectiva y fácil de integrar: razones suficientes para su enorme popularidad.
Pero la popularidad puede autoalimentarse: más tutoriales, más soporte en herramientas (vLLM, llama.cpp, etc.), más checkpoints en Hugging Face Hub. Eso no prueba que sea la mejor en todos los casos. Además, existen muchas variantes y técnicas nuevas con reclamos académicos de superioridad, pero comparar papers puede ser engañoso por sesgos en tuning, benchmarks heterogéneos y reproducibilidad limitada. Incluso hay estudios que muestran que LoRA alcanza a técnicas nuevas si se ajustan hiperparámetros con cuidado (paper).
El benchmark unificado de Hugging Face: qué hicieron
Para ofrecer una comparación justa, Hugging Face integró muchas técnicas PEFT en la librería peft y creó benchmarks que ejecutan cada técnica con la misma base, datos, código y hardware. Dos tareas destacadas:
MetaMathQA: fine-tuning de LLMs para razonamiento matemático (cadena de pensamiento y formato de salida).
Image generation: aprender un nuevo concepto (un cat plushy) y generalizarlo a nuevos prompts.
Cada técnica se evaluó no solo por test accuracy, sino también por VRAM máxima, runtime, tamaño de checkpoint y métricas de drift/olvido. Resultado: comparaciones en igualdad de condiciones y la posibilidad de ver tradeoffs claros.
Resultados clave (lo que tienes que recordar)
LoRA sigue siendo una opción sólida, pero no siempre domina. En algunos experimentos otras técnicas superan a LoRA en precisión y/o consumo de memoria.
En MetaMathQA (ejemplo con meta-llama/Llama-3.2-3B): LoRA con inicialización estabilizada alcanzó 53.2% con 22.6 GB VRAM. Normal LoRA llegó a 48.1% usando 22.5 GB y se queda corto. Otros métodos, por ejemplo BEFT o Lily, aparecen en la frontera Pareto dependiendo de si priorizas memoria o accuracy.
En la tarea de imagen (FLUX.2-klein-base-4B), OFT superó a LoRA: OFT obtuvo mayor similitud dino (0.708) y menor VRAM (9.01 GB) frente a LoRA (0.697 y 9.97 GB). Es decir, OFT dominó a LoRA en ambos ejes en ese experimento.
Variantes de LoRA importan: LoRA-FA (optimización y congelado parcial) y ajustes de inicialización cambian mucho los resultados. No confundas "LoRA vanilla" con el ecosistema LoRA.
Interpretación: tradeoffs y Pareto frontier
Piensa en el problema como una balanza: precisión vs memoria vs tiempo vs tamaño de checkpoint. Si una técnica no puede ser mejorada en un eje sin empeorar otro por cualquiera de las alternativas, está en la frontera Pareto. LoRA suele estar en esa frontera en algunos benchmarks, pero no siempre. La conclusión práctica es: prueba varios métodos y elige según tus prioridades.
Limitaciones del benchmark y cómo contribuir
Ningún benchmark captura todo. Hiperparámetros, soporte de capas específicas, compatibilidad con modelos cuantizados y capacidades particulares (por ejemplo, Cartridges para prompts largos) pueden cambiar la decisión.
La buena noticia: la librería peft facilita añadir configuraciones y contribuir resultados. Si crees que un método mejora con otros hiperparámetros, puedes abrir un PR. Si quieres añadir un benchmark nuevo, también puedes colaborar.
Compatibilidad con ecosistema y conversión a LoRA
Una razón práctica para preferir LoRA es compatibilidad: muchas herramientas de inferencia solo cargan LoRA directamente. Para mitigar esto, peft ahora soporta convertir adaptadores no-LoRA a checkpoints LoRA. En pruebas de imagen, convertir GraLoRA a LoRA mantuvo puntuaciones casi iguales. Aun así, no todas las técnicas tienen conversión implementada; la expansión depende de la demanda.
Cómo elegir en la práctica (receta corta)
Define tus prioridades: ¿menos VRAM, mejor accuracy, menor tiempo de entrenamiento, checkpoints pequeños?
Usa la librería peft para probar múltiples configuraciones con la misma base y tus datos.
Revisa variantes de LoRA antes de descartarla: DoRA, rs-LoRA, LoRA-FA, etc.
Si necesitas servir en vLLM/llama.cpp y eliges otra técnica, convierte el checkpoint a LoRA si la herramienta lo permite.
Ejemplo mínimo de cambio en tu código para probar otra técnica:
from transformers import AutoModelForCausalLM
from peft import OFTConfig, get_peft_model
base_model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.2-3B", dtype="bfloat16")
config = OFTConfig(target_modules=["q_proj", "v_proj"])
model = get_peft_model(base_model, config)
Con un cambio de una línea en la configuración puedes evaluar OFT en lugar de LoRA y comparar resultados en tu dataset.
Reflexión final
LoRA no es la respuesta definitiva, pero sí un estándar práctico con enorme soporte. Las comparaciones justas muestran que otras técnicas pueden ganar según el objetivo. La recomendación técnica y práctica es abrir tu horizonte: usar la API unificada de peft, probar varias técnicas con tus datos y priorizar según tradeoffs reales. Experimentar cuesta poco y puede ahorrarte memoria o ganar accuracy.
