Ajustement d'un modèle de 235 milliards de paramètres sur quatre GPU : leçons tirées d'un déploiement infructueux

Les ingénieurs de Vertexcover ont réussi à effectuer l'ajustement fin du modèle Qwen3 de 235 milliards de paramètres sur une seule machine équipée de quatre GPU H100, atteignant des gains significatifs en précision par rapport aux modèles API payants. Malgré ce succès technique et la réduction du coût par jeton, l'équipe a décidé de ne pas déployer la solution après que de nouveaux modèles open source ont rendu cette infrastructure complexe inutile.

Ce qui s'est passé

L'équipe visait à remplacer les modèles OpenAI et Gemini ajustés finement, coûteux, utilisés pour la classification d'entités dans les documents clients. Ils ont sélectionné Qwen3-235B-A22B-Thinking, un modèle Mixture of Experts (MoE), car il surpassait les autres modèles ouverts lors des premiers benchmarks. L'objectif était de maintenir ou d'améliorer la précision tout en maîtrisant les coûts grâce à du matériel auto-hébergé.

Après un epoch d'entraînement sur environ 3 600 exemples, le modèle ajusté a amélioré le score F1 moyen de 7,6 points pour tous les locataires (tenants). Il a également réduit le coût par jeton à environ un tiers des solutions précédentes basées sur API. Le processus d'entraînement a duré 26 heures sur quatre GPU NVIDIA H100, chacun disposant de 80 Go de mémoire.

Malgré ces métriques positives, le projet a été mis de côté. L'équipe a constaté que servir le modèle de réflexion de 235 milliards de paramètres avec une faible latence et des coûts opérationnels raisonnables représentait un défi d'ingénierie plus important que l'ajustement fin lui-même. Parallèlement, de nouveaux modèles open source ont émergé, capables de gérer de nombreuses tâches de classification sans aucun ajustement fin, éliminant ainsi le besoin de leur infrastructure personnalisée.

Comment cela fonctionne

Qwen3-235B est un modèle MoE où seulement environ 22 milliards de ses 235 milliards de paramètres sont actifs pour n'importe quel jeton donné. Chaque couche contient 128 petits réseaux experts, et un routeur dirige les jetons vers les experts les plus pertinents. Cette architecture rend l'inférence moins coûteuse en calcul que celle des modèles denses de taille similaire, mais complique la gestion de la mémoire lors du chargement et de l'entraînement.

L'équipe a utilisé QLoRA (Quantized Low-Rank Adaptation) pour effectuer l'ajustement fin du modèle. Cette méthode compresse le modèle de base à une précision de 4 bits, réduisant son empreinte mémoire de 470 Go à environ 120 Go. De petites couches adaptatives sont ensuite entraînées par-dessus les poids de base gelés. Le défi réside dans la coordination des bibliothèques de compression et de sharding, qui ont des exigences contradictoires concernant le stockage et l'accès aux poids du modèle en mémoire.

Un entraînement réussi nécessitait DeepSpeed ZeRO-3 avec déchargement CPU (CPU offload). Cette configuration conservait des copies complètes du modèle compressé de 120 Go dans la RAM système plutôt que dans la mémoire GPU. Pendant l'entraînement, les couches étaient déplacées de la RAM vers les GPU selon les besoins, permettant aux quatre H100 de gérer la charge de travail malgré leurs limites de mémoire individuelles. Cette approche a sacrifié la vitesse au profit de la faisabilité, résultant en un temps d'entraînement de 26 heures.

Détails clés

• Le modèle a amélioré les scores F1 pour chaque locataire, avec des gains allant de +4,81 à +11,96 points.
• L'entraînement a utilisé 3 600 exemples incluant des traces de raisonnement, car Qwen3 est un modèle de « réflexion » (thinking).
• Quatre GPU H100 avec 80 Go de mémoire chacun et 960 Go de RAM système étaient requis.
• Les implémentations Axolotl, Unsloth et FSDP+QLoRA d’Answer.AI ont échoué en raison de problèmes de mémoire ou de compatibilité.
• LlamaFactory avec FSDP standard a échoué car Transformers désactivait silencieusement les paramètres d'économie de mémoire lors de la quantification.
• La configuration finale fonctionnelle utilisait LlamaFactory avec DeepSpeed ZeRO-3 et déchargement CPU pour gérer la mémoire.

Pourquoi c'est important

Ce cas met en évidence la complexité cachée de l'ajustement fin de modèles MoE massifs sur un matériel limité. Les ingénieurs supposent souvent que la quantification et le sharding permettront d'intégrer parfaitement les grands modèles dans la mémoire GPU disponible, mais les incompatibilités de bibliothèques et les problèmes d'ordre de la mémoire peuvent empêcher le démarrage de l'entraînement. Comprendre ces contraintes de bas niveau est crucial pour planifier l'infrastructure destinée aux modèles dépassant 100 milliards de paramètres.

Cela sert également de rappel que la capacité technique ne justifie pas toujours le déploiement. L'effort nécessaire pour optimiser l'inférence d'un modèle de 235 milliards de paramètres peut dépasser les avantages de l'ajustement fin, surtout lorsque le modèle de base est déjà performant. Les équipes doivent évaluer le coût total de possession, y compris la latence de service et les exigences matérielles, et non seulement la précision et le coût d'entraînement.

Enfin, le rythme rapide du développement open source signifie que le problème d'ingénierie difficile d'aujourd'hui pourrait être résolu par la sortie d'un nouveau modèle demain. Investir plusieurs semaines dans des pipelines d'ajustement fin personnalisés comporte le risque de coûts irrécupérables si un modèle généraliste s'améliore suffisamment pour traiter la tâche directement. Une patience stratégique peut parfois donner de meilleurs résultats qu'une personnalisation immédiate.

Ce que vous pouvez faire

• Effectuez des benchmarks sur plusieurs modèles ouverts avant de vous engager dans un ajustement fin, car les performances de base varient considérablement.
• Vérifiez la compatibilité des bibliothèques pour les modèles MoE, notamment en ce qui concerne l'ordre de quantification et de sharding.
• Assurez-vous que la RAM système est suffisante pour le déchargement CPU lorsque la mémoire GPU est insuffisante pour le modèle compressé complet.
• Surveillez les paramètres de Transformers pour détecter les changements silencieux apportés à la gestion de la mémoire lors des processus de quantification.
• Évaluez tôt les coûts d'inférence et les exigences de latence, et non seulement la précision et le coût d'entraînement.
• Réévaluez régulièrement le besoin d'ajustement fin, car de nouveaux modèles de base peuvent combler les écarts de performance sans personnalisation.