Le développement incessant de l’IA a constamment démontré que les modèles plus vastes tendent à être plus intelligents, mais leurs exigences opérationnelles augmentent également. Cela crée un défi de taille, en particulier dans les régions où l’accès aux puces d’IA avancées est limité. Cependant, indépendamment des contraintes géographiques, on observe une tendance croissante parmi les développeurs de modèles à adopter des architectures de type “mélange d’experts” (Mixture of Experts, MoE) associées à des techniques de compression innovantes. L’objectif ? Réduire considérablement les ressources de calcul nécessaires pour déployer et exécuter ces vastes modèles de langage de grande taille (Large Language Models, LLM). À l’approche du troisième anniversaire de l’essor de l’IA générative déclenché par ChatGPT, l’industrie commence enfin à prendre sérieusement en considération les implications économiques du maintien en fonctionnement de ces modèles énergivores.
Bien que les modèles MoE, comme ceux de Mistral AI, existent depuis un certain temps, leur véritable percée s’est produite au cours de la dernière année. Nous avons assisté à une vague de nouveaux LLM open source provenant de géants de la technologie tels que Microsoft, Google, IBM, Meta, DeepSeek et Alibaba, tous exploitant une forme ou une autre d’architecture MoE. L’attrait est simple : les architectures MoE offrent une alternative beaucoup plus efficace aux architectures de modèles “denses” traditionnelles.
Surmonter les limitations de mémoire
Les fondements de l’architecture MoE remontent au début des années 1990, avec la publication de “Adaptive Mixtures of Local Experts”. L’idée centrale est de répartir les tâches entre un ou plusieurs sous-modèles spécialisés, ou “experts”, plutôt que de s’appuyer sur un seul modèle massif entraîné sur un large éventail de données.
En théorie, chaque expert peut être méticuleusement optimisé pour un domaine spécifique, du codage et des mathématiques à l’écriture créative. Cependant, il convient de noter que la plupart des développeurs de modèles fournissent des détails limités sur les experts spécifiques au sein de leurs modèles MoE, et le nombre d’experts varie d’un modèle à l’autre. Point crucial, seule une fraction du modèle global est activement sollicitée à un moment donné.
Prenons l’exemple du modèle V3 de DeepSeek, qui comprend 256 experts routés ainsi qu’un expert partagé. Pendant le traitement des jetons (tokens), seuls huit experts routés, plus l’expert partagé, sont activés. Cette activation sélective signifie que les modèles MoE peuvent ne pas toujours atteindre le même niveau de qualité que les modèles denses de taille similaire. Le modèle Qwen3-30B-A3B MoE d’Alibaba, par exemple, a systématiquement sous-performé le modèle dense Qwen3-32B dans les tests de référence d’Alibaba.
Cependant, il est essentiel de contextualiser cette légère baisse de qualité par rapport aux gains d’efficacité substantiels offerts par les architectures MoE. La réduction du nombre de paramètres actifs entraîne des besoins en bande passante mémoire qui ne sont plus directement proportionnels à la capacité nécessaire pour stocker les poids du modèle. Essentiellement, bien que les modèles MoE puissent encore nécessiter une mémoire substantielle, ils n’ont pas nécessairement besoin qu’elle soit la mémoire à bande passante élevée (High Bandwidth Memory, HBM) la plus rapide et la plus coûteuse.
Illustrons cela par une comparaison. Prenons le plus grand modèle “dense” de Meta, Llama 3.1 405B, et Llama 4 Maverick, un modèle comparable qui utilise une architecture MoE avec 17 milliards de paramètres actifs. Bien que de nombreux facteurs, tels que la taille du lot, les performances en virgule flottante et la mise en cache des paires clé-valeur, contribuent aux performances réelles, nous pouvons approximer les besoins minimaux en bande passante en multipliant la taille du modèle en gigaoctets à une précision donnée (1 octet par paramètre pour les modèles 8 bits) par le nombre de jetons cibles par seconde à une taille de lot de un.
L’exécution d’une version quantifiée 8 bits de Llama 3.1 405B nécessiterait plus de 405 Go de vRAM et au moins 20 To/s de bande passante mémoire pour générer du texte à 50 jetons par seconde. Les systèmes HGX H100 de Nvidia, qui jusqu’à récemment coûtaient 300 000 $ ou plus, ne fournissaient que 640 Go de HBM3 et environ 26,8 To/s de bande passante agrégée. L’exécution du modèle 16 bits complet aurait nécessité au moins deux de ces systèmes.
En revanche, Llama 4 Maverick, tout en consommant la même quantité de mémoire, nécessite moins de 1 To/s de bande passante pour atteindre des performances comparables. En effet, seuls 17 milliards de paramètres d’experts du modèle sont activement impliqués dans la génération de la sortie. Cela se traduit par une augmentation d’un ordre de grandeur de la vitesse de génération de texte sur le même matériel.
Inversement, si les performances pures ne sont pas une préoccupation primordiale, bon nombre de ces modèles peuvent désormais être exécutés sur une mémoire GDDR6, GDDR7 ou même DDR moins chère, bien que plus lente, comme on le voit dans les derniers Xeons d’Intel.
Les nouveaux serveurs RTX Pro de Nvidia, annoncés lors du Computex, sont adaptés à ce scénario. Au lieu de s’appuyer sur une HBM coûteuse et énergivore qui nécessite un emballage avancé, chacune des huit cartes graphiques RTX Pro 6000 de ces systèmes est équipée de 96 Go de mémoire GDDR7, le même type que celui que l’on trouve dans les cartes de jeu modernes.
Ces systèmes offrent jusqu’à 768 Go de vRAM et 12,8 To/s de bande passante agrégée, ce qui est plus que suffisant pour exécuter Llama 4 Maverick à des centaines de jetons par seconde. Bien que Nvidia n’ait pas révélé les prix, l’édition poste de travail de ces cartes se vend environ 8 500 $, ce qui suggère que ces serveurs pourraient coûter moins de la moitié du prix d’un HGX H100 d’occasion.
Cependant, la MoE ne signifie pas la fin des cartes graphiques empilées HBM. Attendez-vous à ce que Llama 4 Behemoth, en supposant qu’il soit un jour commercialisé, nécessite un rack rempli de cartes graphiques en raison de sa taille considérable.
Bien qu’il possède environ la moitié des paramètres actifs de Llama 3.1 405B, il se vante d’un total de 2 billions de paramètres. Actuellement, il n’existe pas un seul serveur GPU conventionnel sur le marché capable d’héberger le modèle 16 bits complet et une fenêtre de contexte d’un million de jetons ou plus.
La renaissance du CPU dans l’IA ?
Selon l’application spécifique, un GPU peut ne pas toujours être nécessaire, en particulier dans les régions où l’accès aux accélérateurs haut de gamme est limité.
Intel a présenté en avril une plateforme Xeon 6 à double socket équipée de MCRDIMM à 8800 MT/s. Cette configuration a permis d’atteindre un débit de 240 jetons par seconde dans Llama 4 Maverick, avec une latence de sortie moyenne de moins de 100 ms par jeton.
En termes plus simples, la plateforme Xeon pourrait prendre en charge 10 jetons par seconde ou plus par utilisateur pour environ 24 utilisateurs simultanés.
Intel n’a pas divulgué les chiffres de performance pour un seul utilisateur, car ils sont moins pertinents dans les scénarios réels. Cependant, les estimations suggèrent une performance de pointe d’environ 100 jetons par seconde.
Néanmoins, à moins qu’il n’y ait pas de meilleures alternatives ou d’exigences spécifiques, l’économie de l’inférence basée sur le CPU reste fortement dépendante du cas d’utilisation.
Réduction du poids : Élagage et quantification
Les architectures MoE peuvent réduire la bande passante mémoire nécessaire pour servir de grands modèles, mais elles ne réduisent pas la quantité de mémoire requise pour stocker leurs poids. Même à une précision de 8 bits, Llama 4 Maverick nécessite plus de 400 Go de mémoire pour fonctionner, quel que soit le nombre de paramètres actifs.
Les techniques d’élagage et les méthodes de quantification émergentes peuvent potentiellement réduire de moitié ces exigences sans sacrifier la qualité.
Nvidia est un partisan de l’élagage, publiant des versions élaguées des modèles Llama 3 de Meta qui ont vu les poids redondants supprimés.
Nvidia a également été parmi les premières entreprises à prendre en charge les types de données en virgule flottante 8 bits en 2022, et à nouveau la virgule flottante 4 bits avec le lancement de son architecture Blackwell en 2024. Les premières puces d’AMD à offrir un support natif pour FP4 devraient être commercialisées prochainement.
Bien que pas strictement essentiel, le support matériel natif de ces types de données réduit généralement la probabilité de rencontrer des goulets d’étranglement computationnels, en particulier lors de la mise en service à grande échelle.
Nous avons constaté un nombre croissant de développeurs de modèles adoptant des types de données de plus faible précision, Meta, Microsoft et Alibaba proposant des versions quantifiées 8 bits et même 4 bits de leurs modèles.
La quantification consiste à compresser les poids du modèle à partir de leur précision native, généralement BF16, à FP8 ou INT4. Cela réduit efficacement la bande passante mémoire et les exigences de capacité des modèles de moitié, voire des trois quarts, au prix d’une certaine qualité.
Les pertes associées à la transition de 16 bits à 8 bits sont souvent négligeables, et plusieurs constructeurs de modèles, dont DeepSeek, ont commencé à s’entraîner à une précision FP8 dès le départ. Cependant, réduire la précision de quatre bits supplémentaires peut entraîner une dégradation significative de la qualité. Par conséquent, de nombreuses approches de quantification post-entraînement, telles que GGUF, ne compressent pas tous les poids de la même manière, laissant certains à des niveaux de précision plus élevés pour minimiser la perte de qualité.
Google a récemment démontré l’utilisation de la formation consciente de la quantification (quantization-aware training, QAT) pour réduire ses modèles Gemma 3 d’un facteur 4x tout en maintenant des niveaux de qualité proches de BF16 natif.
La QAT simule des opérations de faible précision pendant la formation. En appliquant cette technique pendant environ 5 000 étapes sur un modèle non qualifié, Google a pu réduire la baisse de perplexité, une mesure de la mesure des pertes liées à la quantification, de 54% une fois converti en INT4.
Une autre approche de la quantification basée sur la QAT, connue sous le nom de Bitnet, vise des niveaux de précision encore plus faibles, compressant les modèles à seulement 1,58 bits, soit environ un dixième de leur taille d’origine.
La synergie des technologies
La combinaison de MoE et de la quantification 4 bits offre des avantages significatifs, en particulier lorsque la bande passante est limitée.
Pour les autres qui ne sont pas limités en bande passante, cependant, l’une ou l’autre des deux technologies, que ce soit MoE ou la quantification, peut considérablement réduire le coût de l’équipement et du fonctionnement pour exécuter des modèles plus grands et plus puissants; cela en supposant qu’un service de valeur peut être trouvé pour qu’ils puissent fonctionner.
Et sinon, vous pouvez au moins vous consoler en sachant que vous n’êtes pas seul : une récente enquête d’IBM a révélé que seulement un déploiement d’IA sur quatre a généré le retour sur investissement qui était promis.