Les modèles d’intelligence artificielle en open source connaissent une croissance exponentielle, atteignant des chiffres qui semblaient inimaginables il y a seulement quelques années : Kimi K3 atteint 2,8 billions de paramètres et DeepSeek-V4-Pro en compte 1,6 billion. L’évolution des architectures Mixture of Experts (MoE) permet d’activer seulement une petite partie du modèle pour traiter chaque token, mais ne résout pas un défi physique fondamental : tous ces paramètres doivent être stockés et accessibles. Pour d-Matrix, cette nouvelle course transforme la mémoire, et non uniquement la capacité de calcul, en l’une des principales limitations lors de l’inférence.
Les clés de la nouvelle course à la mémoire en IA en 20 secondes
- Kimi K3 atteint 2,8 billions de paramètres, avec 104,000 millones activés par token.
- DeepSeek-V4-Pro utilise 1,6 billion de paramètres au total, avec 49 milliards actifs.
- Les modèles MoE réduisent la charge de calcul, mais leurs poids nécessitent toujours une quantité importante de mémoire.
- HBM offre à la fois une grande bande passante et une capacité élevée, tandis que la SRAM privilégie la vitesse.
- d-Matrix mise sur l’empilement direct de DRAM avec le calcul.
La paradoxe réside dans le fait que ces modèles peuvent nécessiter de calculer sur relativement peu de paramètres à chaque instant tout en exigeant une infrastructure capable de maintenir une immense bibliothèque de poids disponible en permanence.
Kimi K3 l’illustre clairement. Moonshot AI indique 2,8 billions de paramètres au total, avec 104 milliards activés par token, soit environ 3,7 % du modèle. Son architecture intègre 896 experts, en sélectionne 16 pour chaque token.
DeepSeek-V4-Pro suit une logique similaire à une échelle différente : 1,6 billion de paramètres au total, dont 49 milliards activés lors du traitement de chaque token.
C’est précisément cette différence entre paramètres stockés et paramètres actifs qui modifie la conception des accélérateurs.
Les modèles MoE économisent du calcul mais pas la mémoire
La technique MoE permet de créer des modèles très grands sans exécuter toutes leurs composantes en interne à chaque opération.
Au lieu d’utiliser tous les paramètres en permanence, un mécanisme de sélection décide quels experts doivent intervenir pour chaque token. L’avantage est une réduction significative du calcul par rapport à un modèle dense de même taille.
Cependant, les experts non sollicités pour un token donné ne disparaissent pas.
Ils font toujours partie du modèle.
Quand un autre token demande l’un d’eux, le système doit pouvoir accéder rapidement à ses paramètres. Cela nécessite de conserver une grande quantité d’informations en mémoire ou de concevoir des mécanismes pour les transférer depuis des couches plus lentes sans interrompre l’inférence.
Voici apparaître le concept de mural de la mémoire.
Un accélérateur peut disposer de vastes unités mathématiques, mais celles-ci peuvent rester en partie inactives si la mémoire ne fournit pas les données rapidement.
Dans l’inférence générative, ce problème est particulièrement visible lors de la phase de décodage, où le modèle génère les tokens successivement pour produire la réponse.
Augmenter la capacité de calcul ne résout pas toujours cette attente.
HBM, SRAM et DRAM répondent à des enjeux différents
L’industrie propose plusieurs technologies pour construire la hiérarchie mémoire d’un système IA, mais aucune ne combine simultanément capacité énorme, bande passante extrême, faible latence, faible consommation et coût réduit.
| Technologie | Avantage principal | Limitation principale |
|---|---|---|
| SRAM | Latence très faible et bande passante élevée | Capacité limitée et coût élevé par bit |
| HBM | Très grande bande passante avec une capacité élevée | Coût, consommation, encapsulage et capacité limitée par accélérateur |
| DRAM conventionnelle | Haute capacité à un coût inférieur | Proximité et bande passante inférieures par rapport aux unités de calcul |
| 3D DRAM intégrée au calcul | Réduit la distance et peut accroître la bande passante | Complexité accrue de fabrication, gestion thermique et intégration |
La SRAM est extrêmement rapide et peut être placée très près des unités de calcul. Cependant, sa taille occupe beaucoup de surface sur le silicium.
Construire plusieurs centaines de gigaoctets ou téraoctets de SRAM autour d’un accélérateur serait difficilement envisageable.
L’HBM a été la réponse de l’industrie pour les GPU destinés à l’IA. Plusieurs couches de DRAM sont empilées près du processeur et connectées via des interfaces très larges, offrant plusieurs téraoctets par seconde.
Mais la croissance des modèles dépasse la capacité mémoire disponible sur chaque accélérateur.
La solution consiste souvent à répartir le modèle sur plusieurs GPU.
Ce qui engendre un nouveau coût : la communication entre accélérateurs.
Plus de GPU signifie aussi déplacer davantage de données
Distribuer un modèle massif entre plusieurs cartes permet d’obtenir la capacité nécessaire, mais oblige ces cartes à échanger en permanence des informations.
Le réseau interne devient une partie critique du processus d’inférence.
Les technologies telles que NVLink, InfiniBand, Ethernet à haute vitesse tentent de réduire ces échanges, mais transférer des données d’une carte à une autre reste plus coûteux que de les accéder dans la même unité.
d-Matrix propose que l’augmentation de la mémoire proche du calcul peut réduire ces déplacements.
La société développe depuis plusieurs années des accélérateurs spécifiques à l’inférence et travaille désormais avec de la DRAM empilée directement sur la logique de calcul. Sa prochaine architecture Raptor utilise précisément cette approche 3D pour réduire la distance physique entre les données et les unités de traitement.
L’idée est simple : si une carte peut contenir localement une portion plus grande du modèle, il y aura moins de sauts entre accélérateurs.
Cela ne supprime pas la nécessité d’un réseau. Les modèles avec plusieurs billions de paramètres nécessitent toujours une infrastructure distribuée.
Mais réduire chaque transfère inutile peut améliorer la latence, la consommation d’énergie et l’utilisation du matériel.
Kimi K3 illustre l’ampleur croissante du défi
La taille de Kimi K3 permet de mettre ce problème en perspective.
Moonshot AI a présenté en juillet un modèle de 2,8 billions de paramètres, avec 896 experts et 104 milliards d’actifs par token. La fenêtre de contexte avoisine un million de tokens.
Son architecture utilise la quantification MXFP4 pour les poids, réduisant considérablement la mémoire nécessaire comparée au stockage en FP16 ou BF16.
Cependant, déployer un tel modèle requiert encore une infrastructure importante.
La quantification diminue le nombre de bits par paramètre, mais ne change rien à une réalité fondamentale : 2,8 billions de paramètres représentent une quantité énorme de données, même si chaque paramètre occupe peu de bits.
Et la mémoire requise lors de l’inférence ne se limite pas aux poids.
Il faut aussi considérer les activations, les buffers internes et surtout la cache KV, dont l’utilisation peut augmenter avec la taille du contexte et le nombre de requêtes simultanées.
Cela explique pourquoi la prochaine compétition entre accélérateurs ne pourra probablement pas se limiter à des FLOPS.
Le débit et la latence ont des tendances opposées
Un autre défi concerne ceux qui gèrent des services IA.
Les GPU peuvent traiter simultanément de nombreuses requêtes en utilisant le batching. Grouper les demandes augmente la cadence d’utilisation du matériel et améliore souvent le nombre total de tokens traités par seconde.
Mais attendre que les lots soient complets et les traiter peut augmenter la latence pour chaque utilisateur.
Les fournisseurs cherchent ainsi à équilibrer deux métriques :
le débit, c’est-à-dire le nombre total de tokens générés, et la latence, le temps que met chaque utilisateur pour recevoir sa réponse.
d-Matrix se concentre beaucoup sur l’inférence avec faible latence et petits lots.
Selon la société, rapprocher la mémoire du calcul permet de maintenir un flux de données élevé sans dépendre uniquement de gros lots pour exploiter efficacement les unités de traitement. Cette approche sera comparée à des solutions commerciales lors de la commercialisation de Raptor.
Ils ont déjà présenté du silicium initial pour leur technologie 3D DRAM et collaborent avec Alchip pour son intégration commerciale.
Empiler la mémoire pose ses propres défis
Rapprocher concrètement DRAM et calcul peut sembler évident, mais sa fabrication est complexe.
La logique d’un accélérateur génère beaucoup de chaleur.
La DRAM est sensible à la température, car ses cellules doivent maintenir la charge électrique représentant les données.
Empiler ces couches impose une gestion précise du refroidissement, de la recharge mémoire et de la fiabilité.
Il faut également connecter ces couches via de nombreux liens microscopiques, tout en assurant une fabrication rentable.
Les recherches académiques sur le silicium initial de Raptor détaillent des techniques spécifiques pour gérer la température, la redondance, la correction d’erreurs et la recharge de la DRAM.
D’où le fait que la proposition dépasse largement le simple « empiler de la mémoire sur le chip ».
L’avantage potentiel réside dans l’acceptation de cette complexité pour simplifier une autre étape du système : le transfert des données.
La course ne se limite plus à fabriquer une GPU plus rapide
Pendant que l’IA générative connaît une croissance explosive, la performance de l’infrastructure était majoritairement évaluée par le nombre et le type de GPU disponibles.
L’évolution des modèles rend cette approche de moins en moins représentative.
Une installation peut disposer d’une capacité mathématique énorme mais être limitée par la mémoire, la connectivité ou la consommation électrique.
Les nouveaux modèles MoE accentuent ces limitations.
Kimi K3 n’active que 104 milliards de ses 2,8 billions de paramètres par token. DeepSeek-V4-Pro active 49 milliards sur 1,6 billion. C’est une méthode très efficace pour éviter des calculs inutiles, mais cela implique de maintenir un ensemble de poids bien plus vaste prêt à l’emploi.
L’industrie répond selon plusieurs axes :
L’HBM continue d’augmenter en capacité et en vitesse. High Bandwidth Flash cherche à créer une nouvelle couche de grande capacité entre HBM et SSD. Les fabricants d’interconnexion augmentent le débit entre accélérateurs. D’autres utilisent de la SRAM spécialisée.
d-Matrix mise sur la modification de la disposition physique de la mémoire.
Aucune de ces technologies ne remplacera complètement les autres. Il est probable que les futurs systèmes IA utiliseront plusieurs couches de mémoire, chacune adaptée à des données correspondant à leurs caractéristiques de capacité, latence et bande passante.
La montée en puissance de modèles dépassant le billion de paramètres montre surtout pourquoi ce sujet devient crucial.
Les techniques MoE ont permis de rendre ces tailles exploitables sans exécuter la totalité des trillions de paramètres pour chaque token.
Aujourd’hui, ce n’est plus seulement une question de FLOPS disponibles mais aussi de faire parvenir le bon paramètre au bon endroit, au bon moment.
Questions fréquentes
Combien de paramètres possède Kimi K3 ?
Kimi K3 dispose de 2,8 billions de paramètres au total, selon Moonshot AI. Son architecture Mixture of Experts active environ 104 milliards de ces paramètres pour traiter chaque token.
Combien de paramètres comporte DeepSeek-V4-Pro ?
DeepSeek précise 1,6 billion de paramètres au total, avec 49 milliards actifs par token dans DeepSeek-V4-Pro.
Pourquoi un modèle MoE nécessite-t-il autant de mémoire malgré l’utilisation de peu de paramètres ?
Parce que tous les experts font partie du modèle et doivent rester accessibles, même si seul un sous-ensemble est activé pour chaque token. MoE limite principalement le calcul, mais ne supprime pas la nécessité de stocker tous les poids.
Que signifie empiler de la DRAM directement sur un accélérateur ?
Cela réduit la distance physique que doivent parcourir les données et peut considérablement augmenter la bande passante disponible pour le traitement. En revanche, cela augmente la complexité d’encapsulage, de refroidissement et de gestion thermique.
source : d-matrix.ai