Le déport d’Engram de DeepSeek déplace la mémoire IA au-delà de la HBM

Le déport d’Engram de DeepSeek a déplacé 189 GiB de mémoire de modèle hors de la HBM des GPU, les tests en DRAM surpassant parfois une configuration entièrement en HBM. Ce résultat remet en cause une hypothèse fondamentale de l’infrastructure des grands modèles. La mémoire la plus rapide n’est pas automatiquement le meilleur emplacement pour chaque paramètre.

SemiAnalysis a publié ces nouvelles expérimentations le 18 septembre, en utilisant DeepSeek-V4.1-Flash et son framework de service InferenceX. Ses tests ont placé les tables Engram dans la DRAM hôte ou dans des fichiers mappés en mémoire sur des disques NVMe locaux. Le chemin DRAM a amélioré une configuration B300 en réduisant le parallélisme tensoriel, tandis que la première implémentation SSD restait plus lente et moins économique.

Cette distinction compte. Engram n’élimine pas la demande de GPU Nvidia ni de mémoire à haute bande passante. Il modifie les paramètres du modèle qui méritent cette capacité rare. À court terme, la compétition n’oppose donc pas la HBM au SSD. Elle oppose un modèle de déploiement entièrement en HBM à un système à plusieurs niveaux qui attribue différentes charges de travail à la HBM, à la DRAM et au stockage.

Le déport d’Engram de DeepSeek transforme le placement des paramètres

Le changement central est architectural : un vaste bloc de mémoire apprise peut quitter la HBM sans obliger l’ensemble du modèle à se comporter comme un réseau neuronal déporté.

DeepSeek a présenté Engram comme un module de mémoire conditionnelle pour les modèles de langage. Il étend les embeddings de tokens ordinaires par des recherches apprises portant sur des motifs récurrents de plusieurs tokens. Ces motifs peuvent inclure des noms, des fragments de code, du texte passe-partout et des expressions relationnelles courantes.

Un Transformer classique reconstruit souvent ces motifs locaux via les couches d’attention et de propagation avant. Engram offre au modèle un chemin de recherche distinct. Il hache les séquences de tokens, récupère une petite collection de lignes d’embeddings et les combine avec l’état caché du modèle.

L’article sur la mémoire conditionnelle décrit cette approche comme une seconde forme de parcimonie. Un modèle Mixture-of-Experts, ou MoE, n’active qu’une partie des calculs du modèle pour chaque token. Engram n’active qu’une infime partie d’une table mémoire bien plus vaste.

Cette distinction détermine la manière dont le matériel peut servir le modèle. Un expert MoE contient des matrices de poids utilisées pour des calculs substantiels. Le déplacer entre niveaux de stockage peut nécessiter des transferts importants au pire moment.

Les adresses Engram sont différentes. Elles dépendent des identifiants de tokens et de leur séquence locale, plutôt que d’un état caché intermédiaire. Un runtime peut savoir quelles lignes il lui faut avant que les couches ultérieures du modèle aient terminé leurs calculs.

Cette prévisibilité crée une fenêtre de prélecture. Le serveur peut récupérer les lignes depuis la mémoire hôte pendant que le GPU traite les opérations antérieures. Si la récupération se termine dans cette fenêtre, le modèle évite une grande part de la latence habituellement associée au déport.

Les recherches publiées par DeepSeek ont porté une table Engram expérimentale à 27 milliards de paramètres. Dans des comparaisons contrôlées, les auteurs ont signalé des gains par rapport à une référence MoE ayant des paramètres et des calculs équivalents. Les améliorations rapportées concernaient les connaissances factuelles, le raisonnement, le code, les mathématiques et la récupération dans de longs contextes.

Ces chiffres provenaient de modèles de recherche, et non du système de production exact testé par SemiAnalysis. Ils expliquent néanmoins pourquoi Engram ne peut pas être considéré comme de simples métadonnées facultatives. Il devient une partie du chemin de raisonnement du modèle entraîné.

SemiAnalysis a renforcé ce point en retirant Engram pendant l’inférence. Selon son analyse, les benchmarks factuels ne conservaient que 29 à 44 % de leurs performances initiales dans l’ablation de l’article antérieur. La compréhension de lecture en conservait 81 à 93 %.

Cette perte ne prouve pas qu’Engram surpasse tous les modèles conventionnels. Le réseau a été entraîné pour dépendre de son module mémoire. Retirer ce module crée un décalage entre l’entraînement et l’inférence.

L’expérience montre toutefois que les opérateurs ne peuvent pas simplement supprimer la table lorsque la mémoire devient limitée. Ils doivent la servir efficacement, la compresser ou la placer ailleurs.

DeepSeek-V4.1-Flash rend le problème de placement concret. DeepSeek indique que le modèle possède une ossature MoE de 552 milliards de paramètres, dont 8 milliards sont actifs lors du traitement des entrées et 16 milliards lors de la génération des sorties. Engram ajoute un autre vaste réservoir de mémoire conditionnelle.

La publication de V4.1-Flash affirme également que son cache KV nécessite un quart de la HBM et un huitième du stockage SSD de son prédécesseur. Le cache KV conserve un état d’attention réutilisable issu des tokens précédents. Il est distinct d’Engram, mais ces deux fonctions redéfinissent les besoins en mémoire des serveurs.

SemiAnalysis a utilisé environ 189 GiB pour la table Engram du modèle. Pourtant, chaque position de token traitée ne demandait que 24 lignes sur deux couches Engram. Cela représentait environ 12,4 KiB pour l’ensemble du modèle, soit 3,1 KiB par GPU dans une configuration à quatre GPU.

La table est énorme, mais la lecture active est minuscule. Cette asymétrie explique pourquoi le déport d’Engram de DeepSeek fonctionne.

Le déport en DRAM met sous pression la conception entièrement en HBM

Engram affaiblit le lien entre le nombre total de paramètres et la capacité HBM nécessaire, même lorsque la bande passante du GPU reste essentielle.

La HBM possède deux propriétés précieuses pour l’inférence IA. Elle offre une bande passante élevée et se trouve à proximité des unités de calcul GPU. Ces avantages en font l’emplacement naturel des poids fréquemment sollicités et d’un cache KV croissant.

La capacité reste toutefois coûteuse à l’échelle du système. Un opérateur ajoute souvent des GPU parce qu’un modèle ne tient pas en mémoire, même lorsque la charge de travail n’exige pas toute leur puissance de calcul. Ces accélérateurs supplémentaires introduisent alors des coûts de communication et une complexité opérationnelle.

Engram offre un moyen de dissocier capacité et calcul. Le serveur peut conserver les couches denses, les experts actifs et l’état sensible à la latence dans la HBM. Il peut placer la table mémoire creuse dans la DRAM hôte.

SemiAnalysis a testé cette organisation via Unified Virtual Addressing, ou UVA. UVA permet à un GPU d’adresser de la mémoire hôte épinglée dans un espace d’adressage partagé. Le même kernel GPU sélectionnait et déquantifiait les lignes Engram depuis la HBM ou la DRAM.

Il ne s’agissait pas d’un déport classique géré par CPU. Le GPU accédait directement à l’allocation hôte épinglée. L’exécution asynchrone permettait de chevaucher la récupération avec d’autres tâches du modèle.

Le résultat surprenant est apparu sur le B300 de Nvidia. SemiAnalysis a indiqué que le déplacement d’Engram vers la DRAM permettait à sa configuration de passer d’un parallélisme tensoriel à quatre voies à deux voies.

Le parallélisme tensoriel répartit les opérations du modèle sur plusieurs GPU. Il peut permettre à un grand modèle de tenir en mémoire, mais chaque division ajoute synchronisation et communication. Réduire cette division peut donc compenser un niveau de mémoire plus lent.

Selon le test, la frontière entre débit et interactivité du B300 résultante s’est améliorée jusqu’à 1,6 fois. Replacer la table dans la HBM n’a pas apporté d’amélioration mesurable au-delà des variations d’une exécution à l’autre sur cette pile logicielle encore précoce.

Ce constat inverse l’argument le plus simple de la hiérarchie mémoire. La HBM rendait chaque recherche individuelle plus rapide, mais ces recherches ne représentaient qu’une partie du chemin de service complet. Engram consommait une capacité qui aurait autrement pu prendre en charge le cache KV, le traitement par lots ou une réplique plus petite.

La DRAM a amélioré l’ensemble du système en modifiant sa topologie. L’avantage ne venait pas du fait que la DRAM dépasse la HBM en vitesse d’accès brute.

C’est la principale pression exercée sur la conception des systèmes GPU. Les opérateurs ont traditionnellement évalué l’adéquation d’un modèle en additionnant la taille du checkpoint, l’état d’exécution et une marge de sécurité. Engram les oblige à classer la mémoire selon son profil d’accès.

Les poids chauds, denses et intensifs en bande passante favorisent toujours la HBM. Des lignes creuses prévisibles peuvent tolérer la DRAM lorsque le calcul masque le transfert. Les lignes peu sollicitées pourraient à terme résider sur NVMe, à condition que la mise en cache et les surcoûts logiciels restent maîtrisés.

Ce changement a des implications pour les fournisseurs de mémoire. Engram ne met pas fin à la demande de HBM. Les expériences de SemiAnalysis suggèrent plutôt que la bande passante peut compter davantage que la capacité HBM maximale pour certaines configurations d’inférence.

Dans le même temps, la DRAM des serveurs devient une composante de l’enveloppe de performance du service de modèles. La planification de capacité doit tenir compte des allocations épinglées, des canaux mémoire, du comportement PCIe et de la contention entre répliques.

Le NVMe acquiert également un rôle potentiel au-delà du stockage des checkpoints et du cache KV. Son marché adressable augmente si les paramètres de modèle sont servis activement depuis le stockage local. Cette opportunité dépend toutefois de la capacité des logiciels à rendre les lectures de stockage économiquement utiles.

Les gagnants immédiats ne sont pas nécessairement les fournisseurs qui vendent les plus grands pools de mémoire. Ce sont les systèmes qui coordonnent plusieurs niveaux sans immobiliser des accélérateurs coûteux.

Pour les acheteurs d’infrastructure IA, la taille totale du modèle devient un signal d’approvisionnement moins utile. Les paramètres actifs, les octets récupérés par token, la distance de prélecture et la topologie des répliques offrent des indications plus pertinentes.

Un système de 748 milliards de paramètres peut imposer des exigences matérielles très différentes de celles d’un modèle dense de taille comparable. DeepSeek-V4.1-Flash associe une ossature creuse à une mémoire conditionnelle et à un cache KV réduit. Chaque élément sollicite une ressource différente.

Cette complexité rend également les comparaisons plus difficiles. Un benchmark ne mesurant que les tokens par seconde peut masquer la latence à certains niveaux de concurrence. Un résultat de coût peut changer lorsqu’une configuration ajoute des GPU uniquement pour leur capacité mémoire.

La comparaison la plus utile cartographie le débit par rapport à l’interactivité visible par l’utilisateur. Elle demande ensuite combien de travail utile chaque serveur complet produit, et non à quelle vitesse s’exécute un kernel isolé.

Pourquoi Engram fonctionne hors de la mémoire GPU

L’adressage déterministe donne au runtime le temps de récupérer la mémoire, tandis que l’accès creux maintient chaque transfert suffisamment petit pour chevaucher les calculs.

Engram commence par les N-grammes, qui sont de courtes séquences de tokens adjacents. L’architecture compresse le vocabulaire du tokenizer, hache les séquences locales au moyen de plusieurs têtes et associe ces hachages à des lignes apprises.

La compression du vocabulaire est importante, car les tokenizers attribuent souvent différents identifiants à des textes visuellement similaires. La capitalisation, les espaces et les formes Unicode peuvent fragmenter les motifs répétitifs. L’article fait état d’une réduction de 23 % du vocabulaire effectif pour un vocabulaire de 128 000 tokens.

Les embeddings récupérés n’entrent pas tels quels dans le modèle. Une porte sensible au contexte contrôle l’influence de chaque recherche sur l’état caché actuel. Une convolution légère ajoute du contexte proche avant que la contribution mémoire n’atteigne les couches ultérieures.

Cette conception aide à expliquer à la fois la valeur et les limites d’Engram. La table stocke des motifs statistiques réutilisables, mais le modèle décide toujours dans quelle mesure les employer. Il ne s’agit pas d’une base de données conventionnelle contenant des enregistrements factuels propres.

SemiAnalysis a analysé les motifs à porte élevée dans DeepSeek-V4.1-Flash. Il y a trouvé des noms, des fragments de code, des formulations relationnelles, des licences, des fragments bibliographiques et du texte passe-partout web. Un exemple inhabituel faisait référence à la série de jeux Ace Attorney.

Ces résultats suggèrent que la table optimise la prédiction du token suivant, et non les jugements humains sur les connaissances de valeur. Une mise en forme répétée peut devenir utile si elle fournit un raccourci de prédiction.

Ce constat complique la mise en cache. Une porte forte n’identifie pas nécessairement une ligne fréquemment consultée. Une ligne peut avoir une grande valeur lorsqu’elle est récupérée, tout en apparaissant rarement dans le trafic de production.

Le runtime ne peut pas non plus éviter chaque recherche faible après avoir observé sa porte. Le calcul de la porte nécessite la clé correspondante, ce qui a déjà déclenché la récupération. Ignorer cette lecture exigerait un prédicteur distinct opérant avant l’accès mémoire.

La fréquence d’accès devrait toujours suivre une distribution à longue traîne. Les mots courants, les motifs de programmation et la syntaxe de routine devraient apparaître plus souvent que les entités rares. Cela rend plausible un cache à plusieurs niveaux.

Les lignes fréquemment demandées pourraient rester en HBM. Un ensemble de travail plus vaste pourrait rester dans la DRAM hôte. Les lignes rares pourraient résider sur NVMe et accéder à des niveaux plus rapides à mesure que le trafic les rend utiles.

La recherche sur la mémoire CXL étend la même idée au-delà de la DRAM directement attachée à un seul serveur. Ses auteurs proposent de mutualiser la mémoire Engram via Compute Express Link, qui prend en charge un accès fin à des périphériques de mémoire partagée.

Cette proposition reste de la recherche, et non une démonstration de rentabilité en production. CXL ajoute ses propres considérations de latence, de topologie et de logiciel. Elle illustre néanmoins la manière dont la mémoire conditionnelle modifie les frontières du système.

Un opérateur pourrait faire évoluer séparément le pool de recherche et le calcul GPU. Plusieurs accélérateurs pourraient partager la capacité au lieu de dupliquer toute la table dans chaque réplique GPU.

Le préchargement est le mécanisme central de ces architectures. Les couches Engram ne peuvent pas être placées arbitrairement tôt si la latence de stockage doit être masquée. Davantage de calcul préalable crée une fenêtre de récupération plus longue.

La qualité du modèle peut tirer dans le sens opposé. Une intervention précoce de la mémoire aide le réseau à éviter de consacrer ses premières couches à reconstruire des motifs locaux courants. Placer Engram trop tard peut affaiblir cet avantage.

Cela crée un véritable problème de co-conception. Les chercheurs en modèles choisissent les couches d’insertion, les dimensions des tables, le comportement de hachage et les portes. Les ingénieurs runtime conçoivent les files de préchargement, les caches, les noyaux et les chemins de transfert autour de ces choix.

Les équipes matérielles décident ensuite de la bande passante et de la capacité que doit offrir chaque niveau. Aucune de ces décisions ne peut être optimisée indépendamment.

L’article de DeepSeek a rapporté une relation en U entre les paramètres alloués au calcul MoE et ceux alloués à la mémoire Engram. Trop peu de mémoire laissait les motifs répétés au backbone neuronal. Trop de mémoire réduisait le calcul disponible pour d’autres tâches.

Ce résultat plaide contre l’idée d’Engram comme une capacité bon marché et illimitée. Ajouter des lignes à la table peut améliorer la perte de validation, mais uniquement dans un système équilibré. La qualité des données d’entraînement détermine également ce que ces lignes apprennent.

L’implication architecturale plus large est importante. Mettre à l’échelle ne signifie plus placer chaque nouveau paramètre à côté de l’arithmétique GPU. Un modèle peut ajouter de la capacité par récupération clairsemée et prévisible, tout en réservant la bande passante coûteuse au calcul dynamique.

Le déport SSD n’est pas encore la solution bon marché

La première expérimentation NVMe a économisé de la capacité DRAM engagée, mais son chemin de données non optimisé s’est révélé inférieur à la DRAM épinglée tant en vitesse qu’en efficacité.

SemiAnalysis a remplacé l’allocation Engram de 189 GiB par des fichiers mappés en mémoire sur des SSD locaux. Un fichier mappé en mémoire permet au système d’exploitation d’exposer le stockage via des pages de mémoire virtuelle. Les pages récemment consultées peuvent rester dans le cache du système de fichiers.

Cette approche offre une flexibilité opérationnelle. Le système d’exploitation peut récupérer les pages mises en cache lorsque d’autres applications ont besoin de mémoire. Les opérateurs évitent d’épingler en permanence l’intégralité de la table Engram dans la DRAM.

Cependant, un cache de pages chaud ne rend pas le chemin SSD équivalent à un déport natif vers la DRAM. Le prototype transférait toujours les identifiants de lignes vers le CPU, supprimait les doublons, regroupait les lignes dans des tampons épinglés et les copiait en retour.

Il déquantifiait ensuite les lignes sélectionnées sur le GPU. Ces étapes s’exécutaient entre des segments d’exécution GPU plutôt que via le noyau UVA direct utilisé pour la mémoire hôte épinglée.

Chaque étape ajoute de la coordination. La planification CPU, les transferts d’identifiants, le regroupement des lignes, la gestion des tampons et les copies GPU peuvent coûter plus cher que la lecture physique du stockage. Un fichier mis en cache peut donc être moins performant que la DRAM épinglée, même lorsqu’aucune requête n’atteint la mémoire flash NAND.

Les résultats B200 ont révélé cet écart. À près de 125 tokens par seconde pour chaque utilisateur, la configuration DRAM produisait 121 millions de tokens totaux par unité de dépense. Le chemin SSD en produisait 52 millions.

La DRAM a donc fourni environ 2,3 fois plus de tokens dans cette comparaison mesurée. Elle a également dominé les configurations SSD observées en matière d’interactivité P90, qui mesure l’expérience des requêtes plus lentes proches de la queue de distribution.

Les chercheurs n’ont pas pu activer GPUDirect Storage, ou GDS, pour le test. GDS peut transférer des données entre NVMe et la mémoire GPU avec une moindre implication du CPU. Son absence limite ce que l’expérience permet de conclure sur un chemin de stockage optimisé.

Le résultat ne doit pas être présenté comme la preuve que NVMe ne peut pas servir Engram. Il montre qu’un support de stockage bon marché ne crée pas automatiquement une inférence bon marché.

Les quatre GPU B200 sont restés dans le serveur. Il en allait de même du CPU, du réseau, de l’alimentation et de la plupart des infrastructures de support. Remplacer la DRAM par des SSD a réduit une exigence de capacité sans réduire les parties coûteuses de la configuration.

Un gain économique exige un second effet. Le déport SSD doit permettre un serveur moins cher, accueillir davantage de répliques productives, prendre en charge un modèle plus grand ou libérer de la DRAM pour une autre charge de travail précieuse.

Le prototype n’a atteint aucun de ces résultats dans sa configuration mesurée. Son cache de système de fichiers pouvait aussi consommer une grande partie de la DRAM que le stockage par fichiers était censé économiser.

La localité de la charge de travail crée une autre incertitude. Un service stable avec des prompts répétés pourrait maintenir un cache chaud utile. Une charge de travail d’agents diversifiée pourrait accéder à une plage plus large de N-grammes et générer davantage de ratés de stockage.

Le traitement par lots modifie encore l’équation. Plusieurs requêtes peuvent réutiliser des lignes au sein d’un lot, tandis que la déduplication réduit les transferts. Pourtant, des lots plus importants augmentent aussi les besoins en cache KV et peuvent modifier la latence.

Les seules spécifications matérielles SSD ne permettront pas de prédire le résultat. La latence de lecture aléatoire, la profondeur de file, le comportement du système de fichiers, la taille des pages, la surcharge CPU et la politique de cache contribuent tous au résultat.

Les systèmes de recommandation offrent un précédent historique utile. Ils servent de grandes tables d’embeddings à partir de mémoire hiérarchisée depuis des années. Certains systèmes mettent les lignes populaires en cache dans la DRAM tout en plaçant la longue traîne sur des SSD.

Le trafic Engram des modèles de langage est suffisamment similaire pour emprunter des idées, mais il n’est pas identique. La génération autorégressive impose une latence séquentielle stricte. Un délai à une position de token peut bloquer les positions suivantes.

AgentX rend cette préoccupation plus visible. Il représente un trafic de codage agentique à contexte long et à plusieurs tours, plutôt qu’un court prompt synthétique. De telles charges alternent un traitement substantiel des entrées et une génération sensible à la latence.

Le cas du stockage ne s’améliorera que lorsque le logiciel traitera Engram comme une primitive de service de premier ordre. Un fichier générique mappé en mémoire est utile pour l’expérimentation, mais il laisse trop de travail sur le chemin contrôlé par le CPU.

Les futures architectures ont besoin d’E/S directes, de files asynchrones, de caches tenant compte des lignes et de calendriers de préchargement prévisibles. Elles pourraient également nécessiter des formats de stockage alignés sur les lignes quantifiées d’Engram.

NVMe reste donc une opportunité plutôt que le choix par défaut actuel. La DRAM a déjà montré que la hiérarchisation peut améliorer le système. Les SSD ont encore besoin d’une pile de service conçue autour du schéma d’accès clairsemé du modèle.

AgentX montre l’avantage logiciel autour des nouvelles architectures

Engram modifie le placement de la mémoire, mais le support logiciel dès le lancement détermine toujours quel accélérateur peut transformer l’architecture en service exploitable.

SemiAnalysis a évalué DeepSeek-V4.1-Flash sur les systèmes Nvidia H100, H200, B200, B300, GB200 et GB300. Il a également testé le MI355X d’AMD au moyen du framework InferenceX.

Les mesures InferenceX utilisent du matériel réel et comparent le débit à l’interactivité. AgentX fournit une charge de travail de codage à contexte long conçue pour ressembler à des sessions répétées orientées outils.

Selon SemiAnalysis, le chemin vLLM de Nvidia fonctionnait sur les six plateformes Nvidia testées au lancement du modèle. L’image de conteneur référencée par AMD n’était pas disponible publiquement durant les 23 premières heures.

Le support AMD est arrivé plus tard, mais l’écart de performance initial est resté significatif dans les mesures de l’analyste. Sept jours après la sortie, SemiAnalysis plaçait les performances du MI355X par unité de dépense entre deux et quatre fois derrière celles du B200.

Il s’agit d’affirmations sensibles aux fournisseurs provenant d’une seule organisation de benchmarking. Elles dépendent des hypothèses cloud, des versions runtime, de la quantification, de la topologie et des évolutions logicielles rapides. Elles ne doivent pas être généralisées à tous les modèles ou à toutes les charges de travail AMD.

Elles révèlent une contrainte importante. Une architecture peut être conçue pour le déport, mais le déploiement dépend toujours des noyaux, de la capture de graphes, de l’adressage mémoire, de la quantification et de la planification distribuée.

Le déport DeepSeek Engram exige plus qu’une bande passante PCIe adéquate. Le runtime doit chevaucher les transferts sans casser les graphes de décodage. Il doit sélectionner et déquantifier efficacement les lignes sur chaque plateforme.

Un nouveau modèle teste donc l’écosystème d’accélérateurs avant que les équipes matérielles aient eu des mois pour l’optimiser. La familiarité des mainteneurs et des pipelines de publication fonctionnels deviennent une composante de la performance.

Cette dynamique renforce la position logicielle de Nvidia même lorsque l’architecture du modèle réduit la capacité HBM nécessaire par réplique. Moins de GPU par réplique peut réduire les communications, mais chaque GPU restant nécessite des noyaux matures et une intégration runtime.

L’effet sur la demande totale d’accélérateurs n’est pas simple. Une meilleure utilisation de la mémoire peut réduire le nombre de GPU requis pour une réplique de modèle. Des coûts de service plus bas peuvent aussi accroître la demande en rendant davantage d’applications économiquement viables.

Engram pourrait encourager des modèles plus grands, car la mémoire conditionnelle évolue séparément du calcul actif. Les opérateurs pourraient utiliser la HBM économisée pour davantage de sessions simultanées plutôt que d’acheter moins d’accélérateurs.

DeepSeek a également réduit les besoins en cache KV dans V4.1-Flash, selon ses documents de lancement. Le déport Engram et la compression KV libèrent ensemble de la mémoire selon deux mécanismes différents.

Cette combinaison importe pour l’inférence agentique. Les agents conservent de longs historiques, des sorties d’outils, du code et des plans intermédiaires. Leur cache KV peut occuper une capacité considérable même lorsque les poids du modèle tiennent déjà.

Un serveur qui déplace les tables de recherche clairsemées vers la DRAM peut consacrer davantage de HBM à ces sessions actives. L’avantage pratique peut se traduire par une concurrence plus élevée, et non par un modèle physique plus petit.

Le point de vue sceptique reste nécessaire. La reproduction d’Engram par SemiAnalysis a utilisé le code et les réglages d’entraînement publiés, car DeepSeek n’a pas diffusé les deux modèles de recherche entraînés de l’article original. Le comportement en production peut différer des expériences contrôlées de mise à l’échelle.

Le chemin SSD était explicitement non optimisé. Les résultats Nvidia et AMD reflétaient des piles logicielles précoces qui évolueront. Même le meilleur résultat DRAM dépendait d’une topologie B300 et d’une frontière de charge de travail spécifiques.

Engram stocke également tout ce que l’entraînement récompense. Davantage de capacité peut préserver du code standard et des motifs accessoires aux côtés d’entités ou de code utiles. Une meilleure allocation de mémoire ne garantit pas une meilleure sélection des données.

Les éléments disponibles soutiennent une conclusion plus étroite. La mémoire conditionnelle est techniquement compatible avec des niveaux de mémoire moins coûteux, et la DRAM peut améliorer les performances globales de service. Ils n’établissent pas encore une configuration universelle.

Trois signaux décideront de l’impact de la DRAM et du NVMe

La prochaine phase dépend d’un service SSD optimisé, de gains de topologie reproductibles et d’un large support runtime au-delà d’une seule sortie de modèle.

Le premier signal est une implémentation NVMe optimisée utilisant un chemin direct orienté GPU. La comparaison importante n’est pas la bande passante SSD maximale. C’est la frontière complète entre débit et interactivité P90 par rapport à la DRAM épinglée.

La prise en charge de GPUDirect Storage supprimerait une partie de l’aller-retour CPU. La déduplication native des lignes, le préchargement asynchrone et des formats de stockage adaptés à Engram pourraient réduire davantage la surcharge.

Si un chemin optimisé approche les performances de la DRAM tout en réduisant sensiblement la mémoire hôte requise, l’opportunité NVMe deviendra crédible. Si les SSD mis en cache restent nettement en retrait, Engram renforcera plutôt la demande de DRAM.

Le deuxième signal consiste à vérifier si des topologies de répliques plus petites reproduisent les résultats sur différents matériels et charges de travail. Le passage de SemiAnalysis sur B300, du parallélisme tensoriel à quatre voies à deux voies, a produit le résultat le plus déterminant.

Des tests indépendants devraient examiner les B200, H200, MI355X et les futurs systèmes. Ils devraient inclure diverses longueurs de contexte, tailles de lots, niveaux de concurrence et états de cache.

Des gains répétés confirmeraient que l’offloading Engram transforme l’économie des serveurs en réduisant les communications. L’incapacité à les reproduire limiterait cette conclusion à une configuration initiale spécifique.

Le troisième signal est l’adoption par l’écosystème. DeepSeek-V4.1-Flash fournit un test visible, mais une mémoire de type Engram doit se diffuser à davantage de familles de modèles et de moteurs de serving pour remodeler la demande matérielle.

Le rapport de SemiAnalysis évoque des mécanismes apparentés de N-grams dans les modèles LongCat et Qwen. Des chercheurs ont également proposé une capacité Engram mutualisée via CXL. Ces approches nécessitent une prise en charge stable dans vLLM, SGLang et les runtimes des fournisseurs.

Une adoption généralisée renforcerait la demande de serveurs équilibrés, avec davantage de bande passante DRAM, un NVMe local performant et des interconnexions flexibles. Une adoption limitée laisserait Engram comme une optimisation importante, mais spécifique à DeepSeek.

Les développeurs devraient surveiller les recettes de déploiement, plutôt que les seuls chiffres de paramètres. Les acheteurs en entreprise devraient demander des performances correspondant à leurs propres longueurs de contexte et objectifs de latence. Les équipes d’infrastructure devraient mesurer séparément les états de cache froid, chaud et mixtes.

Les travailleurs du savoir en ressentiront les effets indirectement. Un meilleur placement de la mémoire peut prendre en charge des sessions plus longues, une latence réduite et un accès élargi à des modèles performants. Ces avantages ne comptent que lorsque les applications complètes les exploitent de manière fiable.

Les équipes qui évaluent des systèmes d’IA devraient conserver leurs propres éléments de preuve parallèlement aux affirmations issues des benchmarks. Une base de connaissances d’ingénierie consultable peut maintenir le lien entre les fiches de modèles, les versions de runtime et les résultats des tests internes.

L’offloading DeepSeek Engram ne marque pas la fin de l’inférence dominée par la HBM. Il montre que l’architecture des modèles peut décider, dès le départ, quels paramètres méritent la HBM. La prochaine question est de savoir si un NVMe optimisé et une mémoire partagée peuvent reproduire le résultat de la DRAM sans déplacer le goulot d’étranglement vers le logiciel.