Majestic Labs défie les limites de mémoire des GPU tandis que Blocks Files met Prometheus en lumière

Majestic Labs remet en cause le statu quo des GPU avec Prometheus, un serveur conçu autour de 128 To de mémoire partagée plutôt que de capacités HBM rares. Le rapport de Blocks Files met clairement en lumière ce conflit. Majestic estime que l’infrastructure IA comporte désormais trop de calcul coûteux et trop peu de mémoire accessible.

La startup ne promet pas un GPU légèrement plus rapide. Elle veut dissocier la capacité mémoire de la puissance de calcul et faire évoluer chaque ressource indépendamment. Cette approche cible les charges d’inférence où les processeurs attendent fréquemment les poids des modèles, les tokens mis en cache ou d’autres données.

Nvidia et AMD répondent à la même pression avec des systèmes HBM plus grands, des interconnexions plus rapides et des racks étroitement intégrés. Majestic adopte l’approche inverse. L’entreprise utilise un vaste pool de mémoire conventionnelle, des chiplets d’interface personnalisés et des processeurs IA programmables au sein d’un même serveur.

Cette distinction fait de Prometheus bien plus qu’une simple annonce d’accélérateur. C’est un test direct visant à déterminer si les futurs systèmes IA ont besoin de davantage de capacité de calcul arithmétique ou d’une relation différente entre processeurs et mémoire.

Majestic a dévoilé des revendications ambitieuses en matière de capacité, de performances et d’énergie. Toutefois, ses processeurs ne sont pas encore parvenus chez les clients, et des résultats de benchmarks indépendants restent indisponibles. L’idée est suffisamment crédible pour attirer l’attention, mais l’avantage promis dépend encore de l’exécution matérielle, logicielle et industrielle.

Le rapport de Blocks Files révèle un défi GPU différent

Majestic Labs soutient que le secteur a acheté des GPU supplémentaires en partie pour acquérir de la mémoire, même lorsque les charges de travail ne peuvent pas exploiter pleinement la puissance de calcul additionnelle.

L’article du 23 juillet consacré au serveur axé sur la mémoire décrit le rejet par l’entreprise du couple traditionnel GPU et mémoire à large bande passante. La HBM place une mémoire rapide, empilée verticalement, près d’un accélérateur. Cette proximité offre une large bande passante, mais limite la capacité totale.

Selon Majestic, les contraintes physiques autour d’un grand processeur limitent le nombre de piles HBM pouvant être connectées efficacement. Augmenter la hauteur des piles crée également des complications techniques et industrielles. Les systèmes modernes combinent donc plusieurs accélérateurs lorsqu’un seul dispositif ne dispose pas d’assez de mémoire.

Cette solution apporte davantage de mémoire, mais introduit une surcharge de communication. Les données doivent transiter via des liaisons GPU, des commutateurs ou des niveaux de mémoire hôte. Les développeurs doivent décider où placer les poids des modèles, les activations et les caches clé-valeur.

Un cache clé-valeur stocke des informations issues de tokens précédemment traités afin qu’un modèle ne recalcule pas l’intégralité de la conversation. Il peut consommer une quantité importante de mémoire lors d’inférences à long contexte. Un nombre d’utilisateurs plus élevé accentue cette pression, car chaque requête active conserve son propre état.

Majestic affirme que les systèmes conventionnels associent également chaque nouveau bloc de mémoire à un autre processeur coûteux. Certaines charges de travail reçoivent plus de puissance de calcul qu’elles ne peuvent en utiliser simplement parce que le déploiement nécessite une capacité supplémentaire.

Prometheus tente de rompre ce couplage. Le serveur prévu relie jusqu’à 12 processeurs IA personnalisés à un seul pool de mémoire plat. Selon l’entreprise, chaque processeur devrait voir le même espace d’adressage avec des caractéristiques d’accès cohérentes.

Les chiplets d’agrégation mémoire, ou MAC, sont placés près des composants mémoire montés sur carte. Ils collectent le trafic provenant de nombreuses puces mémoire et relient ces puces au système de calcul par de courts câbles en cuivre. Blocks Files rapporte que ces connexions peuvent atteindre environ un mètre.

Cette distance est importante, car la HBM doit rester extrêmement proche du boîtier du processeur. L’approche de Majestic offre aux concepteurs de systèmes davantage d’espace physique pour la mémoire sans exiger que chaque composant entoure la puce de calcul centrale.

L’entreprise appelle son processeur Ignite et le décrit comme une AIU, ou unité d’intelligence artificielle. La puce associe des cœurs programmables à une accélération matricielle pour les calculs utilisés par les réseaux neuronaux.

Prometheus est le serveur complet construit autour d’Ignite, des chiplets d’interface, des modules mémoire et des logiciels associés. Les spécifications publiques de Prometheus publiées par Majestic revendiquent jusqu’à 128 To de mémoire partagée à large bande passante dans un seul système.

À titre de comparaison, les serveurs d’accélérateurs actuels mesurent leur mémoire directement attachée en téraoctets à l’échelle d’un rack entier, et non en dizaines de téraoctets au sein d’un seul serveur. Cet écart de capacité constitue la promesse centrale de Prometheus.

L’article de Blocks Files met donc en évidence un désaccord architectural. Le modèle de Nvidia part de GPU haute performance et s’étend vers l’extérieur. Majestic commence par l’ensemble de données de travail qu’une application IA doit conserver, puis attribue suffisamment de calcul pour le traiter.

L’inférence IA accroît la pression sur la mémoire

Le problème de mémoire devient plus difficile parce que l’inférence combine de grands modèles, des contextes plus longs et de nombreux utilisateurs simultanés.

L’entraînement concentre une grande partie de l’attention autour de l’infrastructure IA. Pourtant, l’inférence, c’est-à-dire le processus consistant à exécuter un modèle entraîné pour les utilisateurs, crée un équilibre différent entre mémoire et calcul.

Les paramètres d’un modèle doivent rester disponibles pendant qu’il génère une sortie. Chaque étape de génération lit les poids du modèle et traite l’état actuel. Lorsque les unités arithmétiques terminent plus vite que la mémoire ne peut fournir les données, ajouter du calcul offre un bénéfice limité.

Cette situation est couramment appelée une performance limitée par la mémoire. Le processeur dispose de capacité de calcul, mais le déplacement des données détermine le taux réel d’exécution.

Des fenêtres de contexte plus longues accentuent le déséquilibre. Un modèle traitant des invites courtes conserve moins d’état conversationnel. Un modèle gérant de longs documents, des dépôts logiciels, des collections de recherche ou des sessions d’agents étendues doit préserver beaucoup plus d’informations.

Les systèmes agentiques ajoutent une autre exigence. Un agent peut appeler des outils, examiner les résultats, réviser son plan et répéter le processus. Chaque étape prolonge la session et peut accroître son empreinte mémoire active.

Les modèles de mélange d’experts créent un défi connexe. Ces systèmes contiennent plusieurs groupes de paramètres spécialisés et activent des groupes sélectionnés pour chaque token. Ils réduisent le travail arithmétique, mais l’ensemble plus large des paramètres nécessite toujours un stockage accessible.

Le cofondateur de Majestic, Sha Rabii, a déclaré à EE Times que la capacité de calcul augmentait plus vite que la bande passante mémoire. Il a affirmé que la plupart des inférences sur grands modèles étaient déjà limitées par le déplacement de la mémoire. La conception détaillée de pooling mémoire vise plus de 100 To de DRAM standard basse consommation par environnement d’accélérateur.

La mémoire double débit de données basse consommation, ou LPDDR, offre une capacité nettement supérieure à la HBM, avec des caractéristiques de bande passante et de latence différentes. Le défi technique de Majestic consiste à faire en sorte que cette capacité se comporte comme un système de mémoire rapide pour accélérateurs.

L’entreprise ne peut pas réussir en reliant de la mémoire ordinaire via un bus serveur conventionnel. Cela fournirait de la capacité sans le débit nécessaire pour alimenter plusieurs processeurs IA.

Majestic développe plutôt de concert l’interface physique, le protocole de communication, le contrôle de flux, les mécanismes de fiabilité et les logiciels. Ses chiplets doivent répartir les requêtes entre de nombreux dispositifs mémoire tout en maintenant une bande passante élevée et des délais prévisibles.

L’entreprise prévoit également de répartir les données sur l’ensemble du pool. Cette répartition divise les informations entre plusieurs dispositifs mémoire, permettant à de nombreux composants de traiter les requêtes en parallèle.

Si ce système fonctionne comme décrit, les opérateurs pourraient conserver des modèles et des caches plus importants au sein d’un domaine cohérent. Ils auraient besoin de moins de transferts entre la mémoire locale des accélérateurs, les accélérateurs distants et la mémoire hôte.

Cela compte pour les entreprises qui exploitent des systèmes de recherche, d’analyse documentaire, des agents de codage ou de longues conversations. Ces applications se préoccupent souvent davantage du nombre de tokens achevés par unité d’énergie que du pic arithmétique théorique d’un processeur.

Majestic affirme que sa conception peut prendre en charge bien plus d’utilisateurs simultanés par serveur. Cette affirmation n’a pas reçu de validation indépendante. Elle identifie néanmoins l’indicateur économique que les acheteurs surveillent de plus en plus.

Un centre de données dispose d’une capacité limitée en électricité, refroidissement, espace au sol et réseau. Ajouter un GPU supplémentaire n’aide que lorsque la charge de travail peut le maintenir actif. Des unités arithmétiques inactives continuent de consommer des ressources sans produire une sortie proportionnelle.

Le cadrage de Blocks Files est utile parce qu’il détourne l’attention du nombre maximal d’opérations par seconde. La véritable compétition porte sur la quantité de travail utile qu’un système entier accomplit dans les limites de sa puissance et de sa mémoire.

Prometheus remplace le rack GPU par un pool de mémoire partagée

Prometheus place la mémoire au centre de la machine, tandis que ses processeurs deviennent les consommateurs d’une ressource de données commune.

Majestic a été fondée en 2023 par Ofer Shacham, Sha Rabii et Masumi Reynders. Tous trois avaient auparavant travaillé dans des organisations de silicium personnalisé chez Google et Meta.

Leurs parcours couvrent les processeurs, les systèmes et le matériel grand public commercialisé. Majestic indique que son équipe élargie détient plus de 120 brevets et a contribué à des centaines de millions de puces personnalisées.

L’entreprise est sortie publiquement du mode furtif avec plus de 100 millions de dollars de financement. Bow Wave Capital a mené sa série A, tandis que Lux Capital avait mené un précédent tour d’amorçage. Parmi les autres participants figuraient SBI, Upfront, Grove Ventures, Hetz Ventures, QP Ventures, Aidenlair Global et TAL Ventures.

Cette annonce de financement présentait un système revendiquant 1 000 fois plus de mémoire par processeur qu’un GPU de premier plan. Elle affirmait également qu’un serveur pouvait consolider la capacité mémoire et la bande passante associées à plusieurs racks avancés.

Il s’agit de projections de l’entreprise, et non de résultats indépendants publiés. Elles dépendent du matériel retenu pour la comparaison, de la charge de travail exécutée et de la manière dont le benchmark mesure la sortie utile.

Le mécanisme dévoilé est néanmoins concret. Prometheus contient deux éléments majeurs de silicium personnalisé. L’un est le processeur Ignite, tandis que l’autre est le chiplet d’interface mémoire qui relie le calcul à la LPDDR mutualisée.

Jusqu’à 12 dispositifs Ignite peuvent accéder à un espace mémoire contigu. Majestic décrit cet espace comme plat, ce qui signifie que les logiciels ne devraient pas avoir à gérer plusieurs niveaux de mémoire visiblement différents.

Ce modèle de programmation cible une faiblesse importante des déploiements multi-GPU. Un développeur doit actuellement composer avec la HBM locale, la mémoire attachée à d’autres GPU, la mémoire CPU et le stockage. Chaque niveau présente une capacité, une bande passante et une latence différentes.

Les frameworks répartissent les modèles entre les dispositifs afin de respecter ces contraintes. Ils coordonnent également la communication entre accélérateurs. Les performances peuvent diminuer lorsque le partitionnement choisi produit des transferts excessifs ou une répartition inégale du travail.

Prometheus vise à supprimer une partie de ces décisions. Selon l’entreprise, chaque processeur Ignite pourrait atteindre chaque emplacement du pool partagé avec une latence et une bande passante comparables.

La conception utilise une cohérence relâchée plutôt que de reproduire chaque comportement d’un CPU conventionnel à mémoire partagée. La cohérence définit la manière dont les processeurs maintiennent une vue cohérente lorsqu’ils lisent ou modifient des données communes.

Majestic n’a pas publié suffisamment de détails d’implémentation pour permettre à des observateurs externes d’évaluer tous les compromis. Ses mécanismes propriétaires de contrôle des flux et d’opérations atomiques détermineront dans quelle mesure le système gère les contentions et la synchronisation.

L’architecture du processeur compte également. Majestic combinerait de la propriété intellectuelle Arm, des éléments RISC-V et sa propre conception. Les moteurs matriciels accélèrent les calculs denses courants dans les modèles d’IA.

L’entreprise prévoit de prendre en charge PyTorch, le framework d’apprentissage automatique largement utilisé, ainsi que Triton, un langage de programmation destiné aux noyaux optimisés pour accélérateurs. La compatibilité logicielle est essentielle, car l’avantage de Nvidia dépasse largement le silicium.

CUDA offre aux clients de Nvidia des bibliothèques matures, des compilateurs, des outils de débogage, des guides de performance et des développeurs expérimentés. Un nouveau matériel peut afficher des spécifications séduisantes tout en peinant à s’imposer si les applications exigent d’importantes réécritures.

Rabii a reconnu que le succès d’un serveur dépend largement de la rapidité avec laquelle les développeurs peuvent l’utiliser et de la fiabilité de ses outils. Cet aveu révèle la seconde moitié du défi de Majestic.

Le matériel doit déplacer les données efficacement. Le logiciel doit aussi rendre ce déplacement suffisamment invisible pour que les applications existantes en tirent parti.

Nvidia et AMD étendent HBM, sans l’abandonner

Majestic parie contre un modèle de montée en puissance centré sur HBM, tandis que les plus grands fournisseurs d’accélérateurs continuent d’investir massivement dans ce modèle.

Les systèmes à l’échelle du rack de Nvidia relient de nombreux GPU via NVLink et des technologies réseau associées. Cette approche crée un domaine de calcul plus vaste tout en conservant une mémoire extrêmement rapide à proximité de chaque accélérateur.

AMD suit une direction comparable avec ses accélérateurs Instinct et la conception de rack Helios. Son MI455X, détaillé récemment, utilise HBM4 et offre 432GB de mémoire ainsi que 23.3TB par seconde de bande passante par GPU.

Répartie sur 72 accélérateurs, l’architecture MI455X fournit 31.1TB de HBM dans un seul rack. AMD affirme que Helios rassemble cette mémoire dans un domaine cohérent.

Ces systèmes reconnaissent le même problème que Majestic identifie. Nvidia et AMD augmentent la capacité mémoire, la vitesse mémoire, la bande passante des caches, les performances d’interconnexion et la coordination au niveau du rack.

Le désaccord porte sur la mesure dans laquelle cette stratégie peut évoluer de façon économique. Majestic soutient qu’associer de la HBM haut de gamme à chaque dispositif de calcul haut de gamme maintient un ratio défavorable entre capacité et ressources arithmétiques.

Les fournisseurs établis peuvent répondre à cette préoccupation de plusieurs manières. Ils peuvent augmenter la densité de HBM, améliorer le packaging, compresser les données des modèles, affiner la mise en cache ou répartir les charges de travail plus efficacement.

Ils peuvent aussi utiliser un réseau plus rapide pour réduire le coût de la mémoire distante. Des améliorations logicielles telles que la quantification réduisent le nombre de bits nécessaire pour chaque paramètre. Le décodage spéculatif peut augmenter le débit en permettant aux modèles de vérifier ensemble plusieurs jetons proposés.

Ces méthodes réduisent la pression sans remplacer l’architecture GPU. Elles fonctionnent également dans des environnements matures que les clients exploitent déjà.

La meilleure opportunité de Majestic réside dans les charges de travail où la capacité prime. Les très grands modèles clairsemés, les réseaux neuronaux de graphes, les agents fonctionnant sur de longues périodes et les fenêtres de contexte extrêmes peuvent exiger davantage de mémoire que de calcul arithmétique.

Sa position est plus faible pour les tâches qui exploitent pleinement le calcul matriciel dense et tiennent confortablement dans la HBM locale. Les GPU conventionnels restent bien adaptés à ces charges de travail.

L’entraînement crée également une concurrence plus difficile. Il effectue de manière répétée de grandes opérations matricielles et synchronise les mises à jour entre de nombreux appareils. Il peut utiliser une mémoire énorme, mais bénéficie aussi des meilleures performances disponibles en calcul et en interconnexion.

Majestic affirme que Prometheus peut prendre en charge l’entraînement. Toutefois, son accent initial reste mis sur l’inférence et les charges de travail d’agents. Ce choix donne à l’entreprise une cible plus étroite et plus facile à tester.

Qualcomm poursuit une autre voie centrée sur la mémoire. Son approche near-memory place la logique d’accélération sous des empilements de DRAM plutôt que de s’appuyer sur un packaging HBM conventionnel.

Qualcomm revendique une bande passante par watt six fois supérieure à celle de HBM et une capacité plus de 200 fois supérieure à celle de la SRAM sur puce. L’entreprise n’a pas divulgué la bande passante absolue de l’architecture, laissant d’importantes comparaisons sans réponse.

L’existence de plusieurs approches renforce le diagnostic de Majestic, mais pas nécessairement ses affirmations sur le produit. Les grands concepteurs de puces considèrent clairement le mouvement des données comme une contrainte centrale.

Le marché ne choisit donc pas entre des entreprises qui reconnaissent le mur de la mémoire et d’autres qui l’ignorent. Il choisit entre différentes manières de surmonter ce mur.

L’article de blocks files présente la position la plus agressive de Majestic : l’association GPU-HBM a atteint une impasse. Nvidia, AMD et leurs fournisseurs de mémoire dépensent massivement pour prouver le contraire.

Les affirmations non vérifiées sont aussi importantes que l’architecture

Prometheus reste un système en phase de développement ; sa capacité mise en avant ne peut donc pas encore établir ses performances applicatives, son efficacité ou sa fiabilité commerciale.

Les processeurs de Majestic et ses chiplets d’interface mémoire devraient entrer en tape-out en 2026. Le tape-out marque l’achèvement de la conception d’une puce avant le début de la fabrication. Cela ne signifie pas que du silicium de production fonctionnel soit immédiatement disponible.

L’entreprise prévoit que les serveurs commenceront à parvenir aux premiers clients en 2027. Un autre rapport situe l’introduction plus large vers le milieu de cette année-là.

Ce calendrier laisse plusieurs étapes entre l’architecture actuelle et un produit déployable. La fabrication, le packaging, la validation des cartes, le firmware, le développement des compilateurs, les tests thermiques et l’intégration système peuvent chacun révéler des problèmes.

L’interface mémoire constitue la plus grande question technique. LPDDR offre une forte capacité et des caractéristiques énergétiques favorables, mais les dispositifs individuels n’atteignent pas la bande passante de HBM.

Majestic doit combiner de nombreux canaux mémoire sans créer de congestion. Les chiplets MAC, les liens en cuivre, les protocoles et le système d’entrelacement doivent fournir à la fois du débit et des temps d’accès prévisibles.

Les grands pools de mémoire créent aussi des défis de gestion des défaillances. Davantage de composants signifient davantage de pannes possibles. Un système de production doit détecter les erreurs, isoler les défaillances et continuer de fonctionner sans corrompre l’état du modèle.

Prometheus doit y parvenir tout en présentant aux logiciels un modèle de mémoire simple. La commodité ne peut pas masquer un comportement qui produit des pauses imprévisibles ou un effondrement des performances en cas de contention.

Les définitions des benchmarks soulèvent une autre préoccupation. Majestic a revendiqué des performances plus de 50 fois supérieures dans certains scénarios, ainsi qu’entre 10 et 50 fois plus de jetons par mégawatt.

Ces chiffres exigent une interprétation prudente. L’architecture du modèle, la précision, la taille de lot, la longueur du contexte, la longueur de sortie, l’objectif de latence et le nombre d’utilisateurs simultanés peuvent modifier radicalement les résultats d’inférence.

Un système optimisé pour de grands lots peut produire de nombreux jetons tout en répondant trop lentement pour un service interactif. Un système doté d’une capacité exceptionnelle peut néanmoins être moins performant sur des modèles plus petits et intensifs en calcul.

Les comparaisons dépendent également de la référence Nvidia ou AMD retenue. Un seul GPU, un ancien rack et un système actuel à l’échelle du rack produisent des ratios très différents.

Aucun laboratoire indépendant n’a publié de benchmarks applicatifs issus de matériel Prometheus de production. Majestic n’a pas divulgué de résultats complets concernant la latence, la bande passante, la consommation électrique ou la compatibilité logicielle.

Les commandes clients rapportées ne comblent pas ce manque de vérification. Les engagements précoces peuvent indiquer une forte demande, mais les clients associent souvent des jalons techniques et des conditions de livraison aux achats de matériel émergent.

L’adoption logicielle présente un autre risque. La prise en charge de PyTorch et Triton est un début nécessaire. Elle ne reproduit pas automatiquement l’étendue ni la maturité des bibliothèques CUDA.

Les opérateurs ont besoin de noyaux optimisés, d’outils d’exécution distribuée, d’observabilité, de contrôles de sécurité, d’automatisation du déploiement et de mises à jour stables. Ils ont aussi besoin d’un comportement prévisible sur des modèles réels, et non sur des démonstrations sélectionnées.

Majestic compte environ 40 employés répartis entre la Californie et Israël, selon le profil publié par EE Times en mai. C’est une équipe réduite pour mener simultanément les travaux sur les puces, les serveurs, la mémoire, les compilateurs et la production.

Ses fondateurs possèdent une expérience pertinente, et son financement donne au projet une marge de développement. Nvidia et AMD disposent néanmoins d’organisations d’ingénierie, de relations avec les fournisseurs et de bases clients installées bien plus importantes.

La conclusion sceptique est simple. Majestic a identifié une contrainte réelle et proposé un mécanisme cohérent. L’entreprise n’a pas encore démontré que Prometheus peut fournir les ratios annoncés au-delà de projections internes.

Cette distinction devrait guider la lecture de la couverture de blocks files par les acheteurs. L’architecture mérite de l’attention, mais l’attention ne vaut pas validation.

Trois signaux montreront si Majestic peut tenir ses promesses

La prochaine phase dépendra d’un silicium fonctionnel, de benchmarks applicatifs reproductibles et de preuves que les logiciels d’IA existants peuvent migrer sans reconstruction extensive.

Le premier signal est une validation réussie du silicium. Majestic a déclaré que Ignite et son chiplet d’interface mémoire entreraient tous deux en tape-out en 2026.

Un tape-out achevé maintiendrait le calendrier en vie. Des échantillons fonctionnels atteignant les objectifs prévus de fréquence, de consommation et de liaison apporteraient des preuves bien plus solides.

Tout retard réduirait la probabilité de livraisons aux clients en 2027. Les problèmes d’interface seraient particulièrement importants, car le tissu mémoire représente la différenciation centrale de l’entreprise.

Le deuxième signal est un benchmark qui expose la configuration complète de la charge de travail. Des résultats utiles devraient préciser le modèle, la précision numérique, la taille de lot, la longueur des entrées, la longueur des sorties, l’objectif de latence et la puissance du système.

Les tests devraient comparer Prometheus aux racks Nvidia et AMD actuels, et non à un seul accélérateur ou à une plateforme obsolète. Ils devraient également distinguer le délai avant le premier jeton de la génération des jetons suivants.

L’inférence à contexte long fournirait un test particulièrement révélateur. Prometheus devrait obtenir un avantage lorsqu’un modèle et son cache dépassent la capacité pratique de la mémoire des GPU conventionnels.

Les modèles plus petits et intensifs en calcul offrent le contre-test. Si Prometheus y maintient des résultats compétitifs, son marché pourrait s’étendre au-delà des déploiements spécialisés à forte intensité mémoire.

Le troisième signal est la migration logicielle. Majestic doit montrer qu’un véritable modèle PyTorch peut être transféré vers Prometheus avec des modifications de code limitées.

Une démonstration devrait inclure la compilation, des noyaux optimisés, la supervision et la reprise après défaillance. Elle devrait également révéler quels composants dépendant de CUDA nécessitent un remplacement.

Les déploiements chez les premiers clients compteront davantage que des déclarations génériques de compatibilité. Un client crédible devrait décrire la charge de travail, l’objectif opérationnel et la raison pour laquelle il a choisi un système privilégiant la mémoire.

Ces signaux renforceront ou affaibliront le jugement central de Majestic. Un silicium réussi, des benchmarks transparents et une migration maîtrisable montreraient que le partage de pools mémoire peut concurrencer les racks de GPU.

Une faible bande passante, des conditions de benchmark étroites ou de lourdes réécritures logicielles conforteraient la stratégie des acteurs établis. Les acheteurs continueraient d’accepter une capacité HBM limitée en échange d’outils matures et de performances éprouvées.

La question la plus importante n’est pas de savoir si l’IA a besoin de plus de mémoire. Chaque feuille de route majeure d’accélérateurs répond déjà à cette question par des systèmes mémoire plus grands.

La question est de savoir si la mémoire doit rester attachée à chaque processeur haut de gamme ou devenir une ressource système évolutive de manière indépendante. Majestic a fondé toute son architecture sur la seconde réponse.

Pour les développeurs et les acheteurs d’infrastructure, la prochaine étape pratique consiste à examiner les traces de charge de travail avant d’adhérer aux arguments de l’un ou l’autre camp. Mesurez l’utilisation des accélérateurs, la croissance du cache, les transferts de données, la latence et la consommation électrique en conditions réelles. Surveillez ensuite si la prochaine mise à jour de Blocks Files apporte des mesures en production plutôt qu’une nouvelle affirmation sur la capacité.