Cuando una empresa decide hacer fine-tuning de su propio LLM, la primera pregunta casi nunca es "¿cómo?" sino "¿tenemos el hardware para esto?". La respuesta depende del método que elijas. La diferencia entre full fine-tuning y QLoRA puede superar un factor de diez en VRAM para un modelo de 7B — y eso decide si el entrenamiento corre en una RTX 4090 o si necesitas un clúster de A100 alquilado.
Este artículo recorre los tres enfoques principales — LoRA, QLoRA y full fine-tuning — desde la perspectiva del despliegue práctico. Encontrarás cifras concretas, un marco de decisión y advertencias sobre situaciones en las que el método más barato no es suficiente.
Conceptos básicos para quienes empiezan
Antes de entrar en los números, una introducción breve:
Full fine-tuning actualiza todos los pesos del modelo. Para un modelo de 7B eso significa entrenar 7 000 millones de parámetros — y mantener en memoria también los gradientes y los optimizer states.
LoRA (Low-Rank Adaptation) congela los pesos originales y añade pequeñas matrices «adaptadoras» de bajo rango (rank). El entrenamiento solo toca esos adaptadores, que son órdenes de magnitud más pequeños que el modelo original.
QLoRA (Quantized LoRA) va un paso más allá: los pesos congelados del modelo base se cuantifican a 4 bits, lo que reduce radicalmente su huella en memoria. Los adaptadores LoRA permanecen en mayor precisión (BF16). El entrenamiento opera sobre valores descuantificados — lo que introduce una ligera ralentización, pero un ahorro enorme de VRAM.
Los números que deciden: VRAM por método
Estas son cifras verificadas para modelos densos (es decir, no arquitecturas MoE como Llama 4 o Qwen3, donde los requisitos son notablemente más altos debido a la carga de todos los expertos):
Para un modelo de 7B en FP16/BF16: - Full fine-tuning: ~67 GB VRAM - LoRA: ~15 GB VRAM - QLoRA 8-bit: ~9 GB VRAM - QLoRA 4-bit: ~5 GB VRAM
Para un modelo de 13B: - Full fine-tuning: ~125 GB VRAM - LoRA: ~28 GB VRAM - QLoRA 8-bit: ~17 GB VRAM - QLoRA 4-bit: ~9 GB VRAM
Para un modelo de 70B: - Full fine-tuning: ~672 GB VRAM — prácticamente fuera del alcance de una configuración single-node - LoRA: ~146 GB VRAM — mínimo 2× A100 80GB - QLoRA 8-bit: ~88 GB VRAM — una A100 80GB con márgenes ajustados - QLoRA 4-bit: ~46 GB VRAM — una A100 80GB con holgura
Regla general para full FT: cuenta con aproximadamente 10–16 GB de VRAM por cada mil millones de parámetros — el extremo inferior (~10 GB, coherente con la tabla anterior) aplica con optimizer de 8 bits y gradient checkpointing; el superior (~16 GB) con Adam estándar de 32 bits. La cifra incluye optimizer states, gradientes y activaciones.
Un detalle importante: el fine-tuning requiere bastante más memoria que la inferencia del mismo modelo. Un modelo de 7B corre inferencia con 8 GB, pero el entrenamiento con LoRA sobre ese mismo modelo necesita ~15 GB. Esta es la fuente de sorpresa más frecuente en la práctica — «si el modelo ya me funciona, ¿por qué falla el entrenamiento?»
Cuándo tiene sentido cada método
QLoRA 4-bit es el punto de partida para cualquiera que no tenga un servidor de entrenamiento dedicado. Un modelo de 7B en QLoRA 4-bit corre cómodamente en una RTX 3090 o RTX 4090 (24 GB) y, con gradient checkpointing (un ahorro adicional de ~30 % de VRAM a cambio de un entrenamiento ~2 % más lento), también en una RTX 3060 de 12 GB. Para trabajo exploratorio, proof-of-concept y ajuste de instrucciones sobre datasets pequeños (miles de ejemplos), QLoRA 4-bit es una elección razonable.
LoRA en FP16 supone un escalón arriba en calidad y en requisitos. Para un modelo de 7B necesitas ~15 GB — es decir, una RTX 4090 o una A100 40GB. La calidad es orientativamente un 90–95 % de la del full fine-tuning. Para la mayoría de tareas de dominio (clasificación, extracción, ajuste de instrucciones sobre documentación corporativa), LoRA FP16 es el compromiso óptimo.
Full fine-tuning lo recomendamos en tres casos concretos: 1. Razonamiento, matemáticas y codificación, donde una diferencia del 5 % en calidad es significativa 2. Continual learning — fine-tunings secuenciales sobre múltiples dominios (aquí LoRA tiene debilidades sistémicas, véase más abajo) 3. Cambio fundamental del comportamiento del modelo, no solo adaptación a un dominio
Para despliegues empresariales en la categoría «chatbot sobre documentación propia» o «clasificación de incidencias», el full fine-tuning suele ser innecesario y caro. Hemos visto decenas de proyectos en los que QLoRA o LoRA alcanzaron la calidad requerida con una fracción del coste.
Marco de decisión en la práctica
Estas preguntas, en este orden, reducen la ventana de decisión:
1. ¿Qué modelo planeas entrenar? Dense de 7B o 13B: tienes flexibilidad. Dense de 70B: QLoRA 4-bit en A100 80GB es la puerta de entrada realista. Modelos MoE (p. ej. Llama 4, Qwen3): los requisitos de VRAM son notablemente más altos de lo que sugieren los parámetros activos — verifica cifras concretas para cada modelo antes de planificar el hardware.
2. ¿Cuál es tu objetivo? Ajuste de instrucciones, adaptación a un dominio, cambio de tono → LoRA o QLoRA. Razonamiento, codificación, matemáticas → considera full FT o al menos un rank más alto de LoRA + DoRA. Continual learning secuencial → full FT (LoRA tiene problemas documentados aquí).
3. ¿Tienes suficientes datos? Para supervised fine-tuning (SFT) el mínimo recomendado son miles de ejemplos de calidad — en tanto que cubran los principales temas del dominio. Entrenar con datos insuficientes produce un modelo que responde con confianza desde sus lagunas. Eso es peor que un modelo base que sabe decir «no lo sé». Antes del entrenamiento, el control de calidad de los datos es más importante que la elección del método.
4. ¿Cuál es el plan de despliegue?
QLoRA 4-bit se usa durante el entrenamiento, no en producción. Después del entrenamiento, el adaptador se fusiona con el modelo base y se despliega en precisión normal (BF16/FP16) — o se vuelve a cuantificar para el serving productivo (GGUF para llama.cpp, AWQ/GPTQ para vLLM). «Modelo de producción QLoRA» es un concepto erróneo que aparece tanto en documentación como en planes de proyecto.
Hiperparámetros de LoRA: dónde está el margen de optimización
El rank (r) es la palanca principal. Mayor rank = más parámetros entrenables = potencialmente mejor calidad, pero también más memoria y riesgo de sobreajuste con datasets pequeños.
Recomendaciones verificadas:
- rank=4 a rank=8: tareas simples (clasificación, respuestas plantilla), datasets pequeños
- rank=16 a rank=32: ajuste de instrucciones más complejo, adaptación a dominio
- rank=64 en adelante: solo cuando tienes datos abundantes y reserva de hardware; un rank más alto también aumenta el riesgo de «intruder dimensions» (véase más abajo)
Alpha (α) se configura habitualmente igual que el rank, o al doble del rank. Para la variante rsLoRA, el valor teóricamente fundamentado es α/√r.
Target modules: recomendamos entrenar sobre todas las capas lineales — q_proj, k_proj, v_proj, o_proj más gate_proj, up_proj, down_proj. Limitarse solo a las capas de atención es un patrón antiguo de 2023 que los frameworks modernos han superado.
DoRA y otras variantes PEFT
DoRA (Weight-Decomposed LoRA) descompone la actualización de pesos en magnitud y dirección. En la práctica cierra aproximadamente la mitad de la brecha de calidad entre LoRA y full FT con un overhead de solo +5–10 % de VRAM. Disponible en la librería PEFT, Unsloth y Axolotl. Para proyectos en los que LoRA no alcanza pero el full FT queda fuera de presupuesto, DoRA es el siguiente paso natural.
GaLore optimiza el entrenamiento directamente en el espacio de gradientes con bajo rango — sin matriz adaptadora explícita. Los resultados son comparables al full FT con memoria significativamente menor, pero el despliegue es técnicamente más exigente.
Para proyectos empresariales habituales recomendamos: empieza con LoRA o QLoRA; si no es suficiente, prueba DoRA antes de dar el salto al full FT.
Lo que sabemos sobre la calidad: intruder dimensions
El trabajo de investigación «LoRA vs Full Fine-tuning: An Illusion of Equivalence» (2024) aportó una advertencia importante: LoRA y full FT alcanzan resultados superficialmente similares, pero por mecanismos distintos.
LoRA crea las denominadas «intruder dimensions» — nuevos vectores singulares de alto rango que no existen en el modelo base. Estos interfieren con el espacio de representación original, lo que se manifiesta en el continual learning — es decir, cuando entrenas el modelo secuencialmente sobre múltiples dominios. LoRA muestra un olvido catastrófico notablemente mayor que full FT en este escenario.
Para un fine-tuning puntual sobre un único dominio (que representa el 90 % de los casos empresariales), esta limitación es prácticamente irrelevante. Sin embargo, si planeas refinar el modelo de forma continua sobre nuevos datos o nuevos dominios, full FT o continual learning con replay buffer es un enfoque más seguro.
Artículo relacionado: SFT, DPO, GRPO — qué método usar y cuándo
Frameworks en 2026
Cuatro herramientas principales cubren todo el stack y compiten entre sí en los detalles:
`Unsloth` es el framework single-GPU más rápido — 2–5× más rápido que el pipeline estándar de HuggingFace con un ~70 % de ahorro de VRAM frente al full fine-tuning. Kernels Triton fusionados, gradient checkpointing como opción predeterminada, soporte para Qwen3, Llama 4 y arquitecturas MoE. Open-source para single-GPU; el entrenamiento distribuido multi-GPU está detrás de la suscripción Unsloth Pro.
`TRL` de HuggingFace es el estándar para métodos de alineación — SFT, DPO, GRPO, ORPO en una sola librería. Bien documentado, integrado en el ecosistema Transformers.
`Axolotl` es un pipeline de producción dirigido por YAML — adecuado para escalar a múltiples GPU y para pipelines más complejos (QAT, sequence parallelism, reward modeling). Para proyectos que requieren un setup de entrenamiento reproducible y versionado.
`LLaMA-Factory` combina GUI y CLI y soporta la gama más amplia de modelos — indicado para equipos en los que el entrenamiento no lo lanzan solo ingenieros de ML.
Elección práctica: para un proof-of-concept interno empieza con Unsloth (menor barrera de entrada, velocidad). Para un pipeline de producción con escalado, considera Axolotl. Para experimentos de alineación (DPO/GRPO), utiliza TRL.
Más sobre evaluación de resultados: Cómo medir si el fine-tuning ha servido de algo
Qué hacer con el adaptador entrenado
Un adaptador LoRA es un archivo pequeño (típicamente de pocos a decenas de MB) que se puede compartir y versionar de forma independiente del modelo base. Para el despliegue tienes dos opciones:
Fusionar en el modelo base: peft.merge_and_unload() fusiona las matrices del adaptador con los pesos originales. El resultado es un modelo completo sin overhead en tiempo de ejecución. Recomendado para producción.
Carga en tiempo de ejecución: el adaptador se carga dinámicamente durante la inferencia. Flexible para experimentación (varios adaptadores para el mismo modelo base), pero añade latencia.
Tras la fusión puedes cuantificar el modelo para un serving más eficiente — GGUF para llama.cpp y Ollama, AWQ o GPTQ para vLLM. Este es el flujo productivo estándar: entrenamiento en QLoRA 4-bit → fusión del adaptador → cuantificación para serving.
Temas relacionados: Cuantificación de LLM (GGUF, AWQ, GPTQ) y Modelo pequeño fine-tuned vs modelo base grande
Preguntas frecuentes
¿Es QLoRA simplemente una versión más barata de LoRA? No exactamente. QLoRA cuantifica los pesos congelados del modelo base a 4 bits, mientras que los adaptadores LoRA permanecen en BF16. El mecanismo es diferente y el entrenamiento es ~20–30 % más lento debido al overhead de descuantificación. QLoRA no es gratis — es un trade-off entre VRAM y velocidad, no solo un descuento en calidad.
¿Puedo desplegar directamente en producción un modelo QLoRA 4-bit? No directamente. La descripción QLoRA 4-bit se refiere al proceso de entrenamiento, no al modelo de producción. Tras el entrenamiento, el adaptador se fusiona con el modelo base y se despliega en precisión estándar, o se vuelve a cuantificar para un serving eficiente (GGUF, AWQ). «Modelo de producción QLoRA» es un concepto erróneo.
¿Por qué el full fine-tuning necesita tanta VRAM comparado con la inferencia? Porque el entrenamiento mantiene en memoria mucho más que los pesos: los gradientes (del mismo tamaño que los pesos), los optimizer states (con Adam, 2× los pesos adicionales) y las activaciones para la retropropagación. Un modelo de 7B corre inferencia con 8 GB; el entrenamiento con LoRA necesita ~15 GB; el full FT, ~67 GB.
¿Cuándo LoRA no es suficiente y hace falta full fine-tuning? En tres casos: (1) razonamiento, matemáticas, codificación — donde una diferencia del 5 % en calidad es significativa; (2) continual learning con fine-tunings secuenciales sobre múltiples dominios (LoRA muestra mayor olvido catastrófico aquí); (3) cambio fundamental del comportamiento del modelo más allá de la adaptación a un dominio.
¿Un rank más alto en LoRA siempre da mejor resultado?
No automáticamente. Un rank más alto aumenta la memoria y el tiempo de entrenamiento, pero con datasets pequeños incrementa el riesgo de sobreajuste. Un rank más alto también produce más «intruder dimensions», lo que puede agravar el olvido catastrófico. Para el ajuste de instrucciones, rank=16 o rank=32 suele ser suficiente.
Conclusión
*La elección entre LoRA, QLoRA y full fine-tuning es ante todo una decisión de hardware — y solo en segundo lugar una cuestión de calidad. Para la gran mayoría de los casos empresariales (chatbots de dominio, clasificación, extracción de documentos), LoRA o QLoRA alcanzan la calidad requerida con una fracción del coste. Reserva el full fine-tuning para las situaciones en las que ese cinco por ciento realmente importa. En MP Industrial Solutions ayudamos a las empresas a tomar esta decisión con datos concretos — desde el análisis del dataset y la selección del hardware hasta el despliegue. Si estás planteando tu primer fine-tuning o quieres verificar si tu configuración actual tiene sentido, con mucho gusto revisamos tu caso.*