Cinco formas de ajustar un LLM sin un clúster costoso: LoRA, QLoRA, Unsloth, DPO y la GPU adecuada

Una historia habitual: un equipo decide ajustar un modelo abierto para su propia tarea, mira los precios de las GPU en la nube y aparca la idea para tiempos mejores. Es un error. La mayor parte de la factura no responde a una necesidad real, sino a la costumbre de hacerlo todo «a lo grande»: actualizar todos los pesos, mantener el modelo en precisión completa y alquilar la tarjeta más potente. KDnuggets ha analizado cinco técnicas que rompen esa costumbre. Aquí explicamos qué hay detrás de ellas y cómo aplicarlas.

De dónde sale la factura

En el ajuste fino completo, la memoria no alberga solo el modelo. A su lado están los gradientes y el estado del optimizador (en Adam, dos números más por cada parámetro). Como estimación aproximada, un modelo de 7.000 millones de parámetros necesita más de 100 GB de memoria de vídeo. Eso son varias tarjetas caras, no una.

Las cinco técnicas atacan uno de tres puntos: cuántos parámetros entrenamos, con qué precisión guardamos el modelo y por qué hardware pagamos.

Las cinco técnicas, por orden

1. LoRA. En lugar de actualizar todos los pesos, congelamos el modelo y añadimos a las capas pequeñas matrices adaptadoras entrenables. Se entrena una fracción de un porcentaje de los parámetros, y los gradientes y el estado del optimizador se calculan solo para ellos. El resultado es un adaptador de decenas de megabytes que se puede guardar por separado y conectar al modelo base. Cada cliente o tarea tiene su propio archivo, y no una copia del modelo de 14 GB.

2. QLoRA. El mismo LoRA, pero con el modelo base congelado y comprimido a 4 bits. Los adaptadores, mientras tanto, se entrenan con mayor precisión. Este truco es el que permitió ajustar modelos en una sola tarjeta de consumo o un servidor económico. El precio es un paso de entrenamiento algo más lento y un pequeño riesgo de pérdida de calidad, por lo que conviene contrastar el resultado con tu propia validación.

3. Unsloth. No es un algoritmo nuevo, sino una implementación optimizada: kernels reescritos y un manejo más económico de la memoria. Para el profesional lo importante es que se asienta sobre la pila habitual (Hugging Face, PEFT, TRL) y ofrece mejoras de velocidad y VRAM sin cambiar el método. Es el paso más barato en esfuerzo: cambiar la importación y medir.

4. DPO. Si no se trata de enseñar algo nuevo al modelo, sino de corregir su comportamiento (tono, formato, rechazos, estilo), el RLHF clásico con un modelo de recompensa aparte es excesivo. DPO se entrena directamente con pares «buena respuesta / mala respuesta», sin modelo de recompensa ni ciclo de generación. Menos componentes, menos memoria, menos puntos de fallo. Los datos son más fáciles de reunir de lo que parece: bastan registros en los que el usuario eligió una de dos opciones.

5. El tamaño correcto de GPU. El punto más aburrido y el que más dinero ahorra. Para QLoRA en un modelo de la clase 7–8B suele bastar una tarjeta de 24 GB, y alquilar un acelerador de gama alta «por si acaso» significa pagar varias veces más por memoria ociosa. Primero mide el pico de memoria con un lote pequeño y después elige la tarjeta. Ayudan el gradient checkpointing, la acumulación de gradientes y los contextos cortos en los ejemplos de entrenamiento.

Limitaciones y qué hacer

Ninguna de estas técnicas sustituye a los datos de calidad. Mil ejemplos limpios y bien seleccionados suelen ser más útiles que cien mil de basura, y un método barato con un mal conjunto de datos te dará, barato, un mal modelo. Además, LoRA y QLoRA encajan peor cuando el modelo necesita un cambio profundo de conocimientos o de idioma; para una adaptación ligera a un dominio y un formato funcionan estupendamente.

El orden práctico de actuación es este:

• Empieza con QLoRA en un modelo pequeño y una sola tarjeta, incorporando Unsloth si admite tu arquitectura.
• Configura de inmediato una validación con tus propias tareas y compara con el modelo base y con el prompting: a veces el ajuste fino ni siquiera hace falta.
• Si necesitas corregir la manera de responder, añade DPO sobre el adaptador ya entrenado.
• Elige la GPU según la memoria medida, no según la lista de precios del proveedor.

Una salvedad importante: describimos los enfoques a partir del anuncio del artículo de KDnuggets, y las cifras concretas de velocidad y memoria dependen del modelo, la longitud del contexto y las versiones de las bibliotecas. Compruébalas en tu propio hardware antes de basar en ellas un presupuesto.