GGUF sustituye a bitsandbytes para el entrenamiento LoRA con baja VRAM en hardware local

Una nueva receta de código abierto demuestra cómo realizar entrenamiento mediante Adaptación de Bajo Rango (LoRA) en grandes modelos de lenguaje usando significativamente menos memoria de vídeo de lo que se creía posible anteriormente. Al aprovechar el formato de archivo GGUF en lugar de las bibliotecas tradicionales de cuantización, los desarrolladores ahora pueden ajustar finamente modelos como Qwen3.6-35B con solo 16 GiB de VRAM sin depender de la lenta descarga al CPU. Este cambio sugiere que GGUF está preparado para reemplazar a bitsandbytes como el formato estándar de modelo base para el entrenamiento local eficiente.

Qué ha ocurrido

El desarrollador detrás del repositorio woct0rdho/transformers5-qwen3.5-recipe ha publicado un análisis técnico profundo sobre métodos de entrenamiento con baja VRAM adaptados a la arquitectura de hardware Strix Halo. Este trabajo desafía la sabiduría convencional de que el entrenamiento de modelos grandes requiere clústeres GPU masivos o extenso intercambio de memoria. En su lugar, muestra que con la combinación adecuada de modelos base cuantizados y kernels optimizados, incluso el hardware de grado consumidor o integrado de alto rendimiento puede manejar tareas sustanciales de ajuste fino.

El logro central implica entrenar varios modelos de pesos abiertos de última generación completamente dentro de límites de VRAM que antes se consideraban insuficientes. Por ejemplo, el modelo Qwen3.6-35B-A3B fue entrenado usando solo 16 GiB de VRAM. El autor señala que esta eficiencia implica que variantes más grandes, como Qwen3.5-122B-A10B, podrían entrenarse en 64 GiB, y el masivo Qwen3.5-397B-A17B en 192 GiB. De manera similar, el modelo DeepSeek-V4-Flash, que contiene 284 mil millones de parámetros, fue entrenado en 90 GiB de VRAM, mientras que el modelo Qwen3.8-Flash-Next requirió 40 GiB.

Este desarrollo es significativo porque trata la IA de pesos abiertos de manera similar al software de código abierto, donde los usuarios no solo ejecutan los pesos sino que también los modifican. La capacidad de modificar pesos localmente sin costos prohibitivos de hardware reduce la barrera de entrada para personalizar modelos fundacionales. Sin embargo, la implementación actual está específicamente ajustada para Strix Halo, lo que significa que se requiere un esfuerzo adicional de ingeniería para portar estas optimizaciones a otras arquitecturas GPU.

Cómo funciona

El método se basa en reemplazar la biblioteca bitsandbytes con GGUF como formato de modelo base para cargar pesos cuantizados. GGUF, popularizado originalmente por llama.cpp para la inferencia, ahora está siendo adaptado para flujos de trabajo de entrenamiento a través de una bifurcación personalizada de la biblioteca Transformers. Este enfoque utiliza un cuantizador GGUF que se integra directamente con el bucle de entrenamiento, permitiendo que el modelo permanezca en un estado comprimido durante el cálculo en lugar de descomprimirse completamente en formatos de alta precisión que consumen memoria excesiva.

Varios kernels especializados y técnicas de optimización hacen esto posible. El sistema emplea operaciones sintonizadas de Multiplicación General de Matrices (GEMM) y Cuantización de Precisión Mixta (MMQ) similares a las encontradas en llama.cpp. Para capas de Mezcla de Expertos (MoE), la receta utiliza kernels AITER Triton con configuraciones específicas para adaptadores LoRA no cuantizados. También implementa fórmulas inversas rápidas para actualizaciones de LoRA, similares a las utilizadas en Unsloth, para acelerar los cálculos de gradiente tanto para capas lineales como MoE.

Los ahorros de memoria se logran aún más deshabilitando ciertas características que no son estrictamente necesarias para la estabilidad del entrenamiento, como la caché de decodificación autoregresiva y la pérdida de equilibrio de carga. El sistema utiliza checkpointing de gradiente no reentrante y un optimizador AdamW de 8 bits de bitsandbytes para minimizar la huella de memoria. Además, se aplica torch.compile a la función de descuantización GGUF para reducir el uso de VRAM durante la fase de carga, asegurando que la sobrecarga de manejo de pesos comprimidos permanezca manejable.

Detalles clave

• Qwen3.6-35B-A3B entrena en 16 GiB de VRAM usando cuantización APEX-I-Mini, que ocupa solo 13.3 GiB.
• DeepSeek-V4-Flash (284B parámetros) entrena en 90 GiB de VRAM usando cuantización IQ2_XXS.
• Qwen3.8-Flash-Next entrena en 40 GiB de VRAM más 27 GiB para engramas, usando cuantización GSQ-RCO Q2_0.
• La solución utiliza una bifurcación personalizada de Transformers con soporte GGUF, rastreada en el problema #40070 de Hugging Face.
• Las optimizaciones incluyen GEMM sintonizado, MMQ, kernels AITER Triton y RMSNorm de Liger Kernel.
• Los kernels y parámetros actuales están específicamente ajustados para el hardware Strix Halo, requiriendo adaptación para otras GPUs.

Por qué importa

Para los ingenieros que construyen productos con IA, este cambio reduce el costo y la complejidad del ajuste fino de modelos grandes. Tradicionalmente, el entrenamiento requería ya sea instancias costosas en la nube con cientos de gigabytes de VRAM o configuraciones complejas involucrando descarga al CPU, lo cual ralentiza drásticamente los tiempos de entrenamiento. Al mantener todo el proceso de entrenamiento en VRAM usando cuantización eficiente, los desarrolladores pueden iterar más rápido y experimentar con modelos más grandes en hardware más accesible. Esto democratiza el acceso a la personalización de modelos, permitiendo a equipos más pequeños adaptar modelos fundacionales a sus dominios específicos sin enormes inversiones en infraestructura.

El movimiento hacia GGUF para el entrenamiento también señala una convergencia entre las cadenas de herramientas de inferencia y entrenamiento. Anteriormente, los desarrolladores tenían que mantener pipelines separados para convertir modelos para inferencia (a menudo usando GGUF o formatos similares) y para entrenamiento (usando precisión completa o bitsandbytes). Unificar estos formatos simplifica el flujo de trabajo, reduciendo el riesgo de errores durante la conversión y asegurando que el comportamiento del modelo durante el entrenamiento coincida estrechamente con su comportamiento durante el despliegue. Esta consistencia es crucial para mantener el rendimiento y la fiabilidad del modelo en entornos de producción.

Qué puedes hacer

• Experimenta con la receta proporcionada en hardware Strix Halo para evaluar la velocidad de entrenamiento y el uso de memoria para tus casos de uso específicos.
• Monitorea el problema #40070 de Hugging Face Transformers para rastrear la potencial fusión del soporte de cuantización GGUF en la biblioteca principal.
• Evalúa si tus flujos de trabajo actuales de ajuste fino pueden beneficiarse del cambio de bitsandbytes a cuantización basada en GGUF para modelos base.
• Investiga los kernels Triton personalizados y las implementaciones MMQ para entender cómo podrían adaptarse a tu arquitectura GPU específica si no usas Strix Halo.
• Considera los ahorros de memoria de deshabilitar la caché de decodificación autoregresiva y la pérdida de equilibrio de carga cuando diseñes tus bucles de entrenamiento para modelos grandes similares.
• Explora el uso de torch.compile en funciones de descuantización para optimizar aún más el uso de VRAM durante la carga y el entrenamiento del modelo.