GGUF remplace bitsandbytes pour l'entraînement LoRA à faible VRAM sur matériel local

Une nouvelle recette open-source démontre comment effectuer un entraînement par Adaptation de Rang Faible (LoRA) sur de grands modèles de langage en utilisant significativement moins de mémoire vidéo que ce qui était considéré comme possible auparavant. En exploitant le format de fichier GGUF au lieu des bibliothèques de quantification traditionnelles, les développeurs peuvent désormais affiner des modèles tels que Qwen3.6-35B avec seulement 16 GiB de VRAM, sans recourir au lent déchargement CPU. Ce changement suggère que GGUF est prêt à remplacer bitsandbytes comme format standard de modèle de base pour un entraînement local efficace.

Ce qui s'est passé

Le développeur derrière le dépôt woct0rdho/transformers5-qwen3.5-recipe a publié une analyse technique approfondie des méthodes d'entraînement à faible VRAM adaptées à l'architecture matérielle Strix Halo. Ces travaux remettent en question la sagesse conventionnelle selon laquelle l'entraînement de grands modèles nécessite d'importants clusters GPU ou une extensive permutation de mémoire. Au contraire, ils montrent qu'avec la bonne combinaison de modèles de base quantifiés et de noyaux optimisés, même du matériel grand public ou intégré à haute performance peut gérer des tâches substantielles d'affinage.

L'exploit principal consiste à entraîner plusieurs modèles open-weight de pointe entièrement dans les limites de VRAM précédemment considérées comme insuffisantes. Par exemple, le modèle Qwen3.6-35B-A3B a été entraîné en utilisant seulement 16 GiB de VRAM. L'auteur note que cette efficacité implique que des variantes plus grandes, telles que Qwen3.5-122B-A10B, pourraient être entraînées dans 64 GiB, et le massif Qwen3.5-397B-A17B dans 192 GiB. De même, le modèle DeepSeek-V4-Flash, qui contient 284 milliards de paramètres, a été entraîné dans 90 GiB de VRAM, tandis que le modèle Qwen3.8-Flash-Next nécessitait 40 GiB.

Ce développement est significatif car il traite l'IA open-weight de manière similaire aux logiciels open-source, où les utilisateurs non seulement exécutent les poids mais les modifient également. La capacité de modifier les poids localement sans coûts matériels prohibitifs abaisse la barrière d'entrée pour la personnalisation des modèles fondamentaux. Cependant, l'implémentation actuelle est spécifiquement ajustée pour Strix Halo, ce qui signifie qu'un effort d'ingénierie supplémentaire est requis pour porter ces optimisations vers d'autres architectures GPU.

Comment cela fonctionne

La méthode repose sur le remplacement de la bibliothèque bitsandbytes par GGUF comme format de modèle de base pour charger les poids quantifiés. GGUF, initialement popularisé par llama.cpp pour l'inférence, est désormais adapté aux flux de travail d'entraînement via un fork personnalisé de la bibliothèque Transformers. Cette approche utilise un quantiseur GGUF qui s'intègre directement dans la boucle d'entraînement, permettant au modèle de rester dans un état compressé pendant le calcul plutôt que de se décompresser complètement dans des formats de haute précision qui consomment une mémoire excessive.

Plusieurs noyaux spécialisés et techniques d'optimisation rendent cela possible. Le système emploie des opérations de multiplication matricielle générale (GEMM) ajustées et une Quantification à Précision Mixte (MMQ) similaires à celles trouvées dans llama.cpp. Pour les couches Mixture of Experts (MoE), la recette utilise des noyaux AITER Triton avec des configurations spécifiques pour les adaptateurs LoRA non quantifiés. Elle implémente également des formules de rétropropagation rapides pour les mises à jour LoRA, analogues à celles utilisées dans Unsloth, pour accélérer les calculs de gradient pour les couches linéaires et MoE.

Les économies de mémoire sont encore réalisées en désactivant certaines fonctionnalités qui ne sont pas strictement nécessaires à la stabilité de l'entraînement, telles que le cache de décodage autorégressif et la perte d'équilibrage de charge. Le système utilise un checkpointing de gradient non-rentrant et un optimiseur AdamW 8-bit de bitsandbytes pour minimiser l'empreinte mémoire. De plus, torch.compile est appliqué à la fonction de déquantification GGUF pour réduire l'utilisation de VRAM pendant la phase de chargement, garantissant que la surcharge liée à la gestion des poids compressés reste gérable.

Détails clés

• Qwen3.6-35B-A3B s'entraîne dans 16 GiB de VRAM en utilisant la quantification APEX-I-Mini, qui n'occupe que 13,3 GiB.
• DeepSeek-V4-Flash (284B paramètres) s'entraîne dans 90 GiB de VRAM en utilisant la quantification IQ2_XXS.
• Qwen3.8-Flash-Next s'entraîne dans 40 GiB de VRAM plus 27 GiB pour les engrammes, en utilisant la quantification GSQ-RCO Q2_0.
• La solution utilise un fork personnalisé de Transformers avec support GGUF, suivi dans le problème Hugging Face #40070.
• Les optimisations incluent GEMM ajusté, MMQ, noyaux AITER Triton et RMSNorm de Liger Kernel.
• Les noyaux et paramètres actuels sont spécifiquement ajustés pour le matériel Strix Halo, nécessitant une adaptation pour d'autres GPU.

Pourquoi c'est important

Pour les ingénieurs construisant des produits avec l'IA, ce changement réduit le coût et la complexité de l'affinage de grands modèles. Traditionnellement, l'entraînement nécessitait soit des instances cloud coûteuses avec des centaines de gigaoctets de VRAM, soit des configurations complexes impliquant un déchargement CPU, ce qui ralentissait drastiquement les temps d'entraînement. En maintenant l'ensemble du processus d'entraînement dans la VRAM grâce à une quantification efficace, les développeurs peuvent itérer plus rapidement et expérimenter avec des modèles plus grands sur du matériel plus accessible. Cela démocratise l'accès à la personnalisation des modèles, permettant à de petites équipes d'adapter les modèles fondamentaux à leurs domaines spécifiques sans investissements massifs en infrastructure.

Le passage vers GGUF pour l'entraînement signale également une convergence entre les chaînes d'outils d'inférence et d'entraînement. Auparavant, les développeurs devaient maintenir des pipelines séparés pour convertir les modèles pour l'inférence (utilisant souvent GGUF ou des formats similaires) et pour l'entraînement (utilisant la pleine précision ou bitsandbytes). Unifier ces formats simplifie le flux de travail, réduisant le risque d'erreurs lors de la conversion et garantissant que le comportement du modèle pendant l'entraînement correspond étroitement à son comportement pendant le déploiement. Cette cohérence est cruciale pour maintenir la performance et la fiabilité des modèles dans les environnements de production.

Ce que vous pouvez faire

• Expérimentez avec la recette fournie sur le matériel Strix Halo pour évaluer les vitesses d'entraînement et l'utilisation mémoire pour vos cas d'usage spécifiques.
• Surveillez le problème #40070 de Hugging Face Transformers pour suivre le potentiel de fusion du support de quantification GGUF dans la bibliothèque principale.
• Évaluez si vos flux de travail actuels d'affinage peuvent bénéficier du passage de bitsandbytes à la quantification basée sur GGUF pour les modèles de base.
• Étudiez les noyaux Triton personnalisés et les implémentations MMQ pour comprendre comment ils pourraient être adaptés à votre architecture GPU spécifique si vous n'utilisez pas Strix Halo.
• Considérez les économies de mémoire obtenues en désactivant le cache de décodage autorégressif et la perte d'équilibrage de charge lors de la conception de vos boucles d'entraînement pour des modèles similaires de grande taille.
• Explorez l'utilisation de torch.compile sur les fonctions de déquantification pour optimiser davantage l'utilisation de VRAM pendant le chargement et l'entraînement des modèles.