Contexte Technique
J'ai plongé dans les chiffres parce que le sujet des « 2,7T de paramètres et seulement 50B actifs » sonne impressionnant, mais les faits sont un méli-mélo. À ce jour, Qwen n'a pas de modèle officiel à 2,7 billions de paramètres. Très probablement, les gens ont confondu la taille du modèle avec le volume de données d'entraînement, ce qui est complètement différent.
Si l'on regarde les sorties réelles, le plus proche est Qwen3-235B-A22B : 235 milliards de paramètres au total et environ 22 milliards activés par token. C'est déjà une approche MoE sérieuse, et c'est précisément cela qui compte pour l'automatisation IA et les systèmes de production, car cela résout non seulement la qualité, mais aussi le coût d'inférence.
C'est là que je me suis vraiment arrêté : le MoE épars n'abolit pas la physique. Lorsque seule une petite fraction des poids est activée, les calculs par token sont moindres, oui. Mais la mémoire, le routage des experts, la bande passante d'interconnexion et la latence ne disparaissent pas.
Voilà pourquoi les calculs de la discussion sur des centaines de GPU, des dizaines de téraoctets de HBM et un budget faramineux ne semblent pas absurdes en soi. Ils paraissent absurdes lorsqu'on les applique au nombre attribué à Qwen, mais pas à l'idée même de pré-entraîner un modèle épars géant. Pour un entraînement complet à ce niveau, on ne parle généralement plus de « serveur », mais d'un programme d'infrastructure dédié.
Et oui, le fine-tuning est une autre douleur ici. LoRA peut encore être géré de manière relativement raisonnable, mais le ré-entraînement complet d'une énorme architecture MoE bute rapidement sur la mémoire, le partitionnement, les points de contrôle et le coût des expériences. Sur une serviette, ça se calcule bien, puis arrive la facture pour le cluster et le refroidissement.
Ce que cela change pour les entreprises et l'automatisation
Pour les entreprises, la leçon est très terre-à-terre : la plupart n'ont pas besoin de leur propre monstre à centaines de milliards de paramètres. Elles ont besoin d'une bonne architecture IA : choisir le modèle adapté à la tâche, construire un pipeline, ajouter de la récupération, du contrôle qualité et du monitoring.
Les gagnants sont ceux qui construisent des solutions IA pour les entreprises autour de l'efficacité, et non du fétichisme de la taille du modèle. Les perdants sont les équipes qui planifient leur budget sur la base du buzz sur X plutôt que sur les contraintes réelles de mémoire, de latence et de coût par token.
Je vois cela constamment : le problème n'est généralement pas que « le modèle est trop petit », mais que l'implémentation IA est mal ficelée. Chez Nahornyi AI Lab, nous résolvons justement ces goulots d'étranglement : où un agent est nécessaire, où un MoE compact suffit, et où il est moins cher et plus fiable de ne pas toucher du tout à l'entraînement lourd. Si votre pipeline commence à buter sur les coûts, la latence ou le chaos d'intégration, vous pouvez tranquillement revoir l'architecture avec moi et bâtir une automatisation IA sans gaspiller des millions en matériel.