Más allá de LoRA: benchmarking de técnicas PEFT en HuggingFace
HuggingFace publica un benchmark que compara 40+ técnicas de fine-tuning eficiente. LoRA domina, pero no siempre gana.
Qué es
HuggingFace ha publicado un benchmark sistemático que compara técnicas de PEFT (Parameter-Efficient Fine-Tuning) más allá de LoRA. El estudio, firmado por Benjamin Bossan, Sayak Paul, Marian y Kashif Rasul, parte de una pregunta directa: ¿estamos dejando rendimiento sobre la mesa por usar siempre LoRA?
La librería PEFT de HuggingFace implementa más de 40 técnicas distintas detrás de una API unificada. Pero la adopción está concentradísima en una sola.
La dominación de LoRA
Los números son contundentes:
- 98,4% de las model cards en HuggingFace que mencionan PEFT citan LoRA (20.509 de 20.834)
- 95,0% de los checkpoints de generación de imagen son LoRAs
- 71,3% de los snippets de GitHub con
from peft importusan LoRA. El segundo, LoHa, está en 3,7%
Como dicen en el post: la popularidad de LoRA se alimenta a sí misma.
Por qué comparar por papers no funciona
El problema es que cada paper que propone una técnica nueva usa modelos, datasets y benchmarks distintos. Los investigadores tienen presión por superar resultados existentes. Un estudio encontró que LoRA puede igualar a técnicas supuestamente superiores simplemente ajustando el learning rate. Y el código muchas veces no es reproducible.
Cómo aborda HuggingFace el benchmark
HuggingFace creó dos benchmarks diseñados para ser justos y reproducibles:
1. LLM Math Benchmark: fine-tuning de un LLM sobre MetaMathQA para razonamiento matemático (chain-of-thought). Mide accuracy en GSM8K.
2. Image Generation Benchmark: fine-tuning para aprender un concepto nuevo (un peluche con forma de gato) y generarlo en contextos distintos sin olvidar los existentes.
Todas las técnicas se evalúan en condiciones idénticas: mismo modelo base, mismo dataset, mismo código, mismo hardware. Se miden cuatro métricas: VRAM, forgetting/drift, runtime y checkpoint size. Los resultados están disponibles en un Space interactivo.
Resultados clave: LoRA va bien, pero no siempre gana
En LLM Math (Llama-3.2-3B sobre GSM8K)
| Técnica | Accuracy | VRAM (pico) |
|---|---|---|
| LoRA (rs-LoRA) | 53,2% | 22,6 GB |
| Lily | 54,9% | 25,6 GB |
| BEFT | 32,9% | 20,2 GB |
| LoRA-FA | ~48% | 20,2 GB |
| Vanilla LoRA | 48,1% | 22,5 GB |
LoRA está en la frontera de Pareto, pero comparte posición con otras técnicas. El detalle importante: el buen resultado de LoRA usa rank stabilized initialization (rs-LoRA), no LoRA vanilla. El vanilla debería evitarse.
En generación de imagen (FLUX.2-klein-base-4B)
| Técnica | Dino Similarity | VRAM |
|---|---|---|
| LoRA | 0,697 | 9,97 GB |
| OFT | 0,708 | 9,01 GB |
Aquí OFT domina estrictamente a LoRA: mejor accuracy y menos memoria. LoRA queda por debajo de la frontera de Pareto en esta tarea.
Limitaciones
El benchmark tiene límites honestos:
- Los hyper-parameter sweeps exhaustivos y justos son difíciles con tantas técnicas
- No captura todos los aspectos (por ejemplo, Cartridges, que comprime prompts largos, no se mide)
- No todas las técnicas soportan modelos cuantizados
- El tipo de capa modificable varía según la técnica
La comunidad puede contribuir experimentos via PRs.
¿Para quién es relevante?
- Equipos haciendo fine-tuning que quieran elegir la técnica correcta en lugar de defaultear a LoRA
- Investigadores en PEFT que necesiten un baseline reproducible
- Devs que trabajan con modelos cuantizados, donde la elección de técnica importa más
Conclusiones
LoRA es popular por razón: funciona bien en muchos casos y es simple. Pero no es siempre la mejor opción. El benchmark de HuggingFace demuestra que vale la pena probar alternativas —especialmente rs-LoRA en LLMs y OFT en generación de imagen— y que el LoRA vanilla debería retirarse.
📎 Fuente original: HuggingFace Blog ↗