AMD se met à promouvoir un logiciel baptisé Mext : sur les serveurs Epyc, il utilise du flash NVMe à la place d'une partie de la DRAM, et s'appuie sur un modèle d'IA qui prédit quelles pages mémoire vont être utilisées sous peu pour les ramener en RAM avant que le système d'exploitation et les applications ne s'en aperçoivent. Selon AMD, avec la moitié de la DRAM remplacée par du flash, certaines charges conservent encore jusqu'à 99 % de leurs performances, et le coût des serveurs d'entreprise peut baisser jusqu'à 83 %.
Mext était à l'origine une entreprise indépendante ; AMD a racheté cette technologie en juin dernier. Gary Smerdon, ancien PDG de Mext et aujourd'hui vice-président du développement commercial chez AMD, a indiqué à The Register que le logiciel est déjà déployé sur les 145 premiers systèmes. D'après son estimation, les clients ont déjà économisé environ 5 millions de dollars d'achats de DRAM.
Pourquoi personne n'ose activer le swap classique
Dans un serveur, la mémoire « occupée » n'est souvent pas réellement utilisée. Smerdon cite une étude de Meta selon laquelle 50 % à 80 % des pages mémoire restent cinq minutes, dix minutes, voire plus, sans être consultées. Ses mots : « Cinq minutes, c'est une éternité pour un Epyc. »
Déplacer les pages froides vers un support moins cher relève de la même idée que le swap des systèmes d'exploitation ou le fichier d'échange de Windows. Le problème, c'est la vitesse : d'après les chiffres de Smerdon, le flash coûte environ 50 fois moins cher que la DRAM par bit et consomme environ 30 fois moins d'énergie, mais il est environ 500 fois plus lent. Le swap traditionnel ne va chercher une page sur le disque qu'au moment où le programme en a besoin ; la latence explose, les accords de niveau de service (SLA) ne sont plus tenus, et les équipes d'exploitation le désactivent donc dès qu'elles le peuvent.
L'approche de Mext consiste à rapatrier les pages avant que le besoin n'apparaisse. « Nous faisons en sorte que le flash ressemble à de la DRAM de façon transparente », résume Smerdon. Dans son exemple, un serveur Epyc qui devait recevoir 2 To de mémoire peut n'en acheter que 1 To, l'autre téraoctet étant fourni par Mext sous forme de flash.
Le modèle de prédiction est entraîné à la volée sur le CPU
Le modèle principal chargé de la prédiction est un dérivé de l'architecture Transformer. L'analogie de Smerdon : un grand modèle de langage prédit le mot suivant, celui-ci prédit la prochaine page mémoire qui sera utilisée. Tant que la page est revenue en DRAM avant d'être consultée, peu importe que l'ordre soit un peu brouillé.
Les schémas d'accès à la mémoire varient selon les charges, si bien qu'il n'est pas réaliste de préentraîner un modèle générique. Mext utilise un cœur Epyc pour entraîner une première version en moins d'une seconde, puis la réentraîne en cours d'exécution jusqu'à ce que les prédictions soient suffisamment justes. Tout le processus ne fait appel qu'au CPU, sans GPU, de sorte qu'en théorie tout client d'Epyc peut l'utiliser.
Le coût se situe aussi là. The Register souligne qu'en environnement virtualisé, le logiciel occupe un cœur par machine virtuelle : plus il y a de VM, plus de cœurs sont mobilisés. Pour les scénarios avec conteneurs, AMD n'a pas encore répondu à la demande du média.
Les chiffres de performance se lisent charge par charge
Smerdon affirme qu'une fois les pages froides déplacées, il n'y a « absolument aucun impact sur les performances » ; les mesures fournies par AMD elle-même sont plus prudentes :
- Synopsys PrimeTime (outil d'EDA pour la conception de puces) : avec la moitié de la mémoire remplacée par du flash, les performances atteignent 95 % de celles d'une configuration 100 % DRAM ; avec seulement 25 % de DRAM et 75 % de flash, elles tombent à 80 %.
- Apache Spark : avec la moitié de la DRAM remplacée par du flash, les performances se maintiennent à 99 %.
Les logiciels d'EDA sont très gourmands en mémoire, mais les données réellement traitées par les cœurs de calcul à un instant donné ne représentent souvent que quelques Mo, ce qui explique pourquoi Mext a commencé par eux. La prise en charge a ensuite été étendue aux bases de données et aux pipelines d'inférence d'agents, des scénarios sensibles à la latence ; les chiffres de ces derniers n'ont pas été publiés cette fois, et aucune mesure indépendante n'existe encore.
Un calcul approximatif sur le coût de la machine entière
Selon Smerdon, dans le coût des serveurs à grande mémoire, celle-ci représente, par estimation prudente, six à sept dixièmes, et jusqu'à huit ou neuf dixièmes pour les machines à très grande mémoire. En partant de son exemple de 2 To : si la mémoire pèse 70 % du coût de la machine, que l'on supprime la moitié de la DRAM et que l'on y substitue du flash à un prix unitaire d'environ un cinquantième, sans compter la licence Mext, le coût total baisse d'un peu plus de trente pour cent. Le plafond de 83 % correspond sans doute à des configurations où la part de la mémoire est plus élevée et la proportion remplacée plus grande ; AMD n'a pas publié le détail du calcul.
Le prix de la licence reste inconnu. Mext ne fonctionne que sur du matériel AMD et sera vendu sous forme de licence avec les serveurs Epyc par des OEM comme HPE ; le tarif n'a pas été annoncé. Sous Linux, il suffit d'installer un pilote noyau ; AMD propose en outre un outil nommé RAM View, qui aide les entreprises à déterminer quelles machines et quelles charges se prêtent à l'activation de Mext.
L'expansion des centres de données d'IA entretient la pénurie de mémoire, et AMD parie que ses clients accepteront de perdre quelques points de performance contre une grosse économie sur leur budget mémoire. Selon son plan, on en est à la première phase, où l'on prépare avec les OEM des machines « Mext ready » ; la seconde phase seulement verra la vente des licences et la préinstallation de RAM View sur les machines Epyc sortant d'usine.
Sources : entretien de The Register avec Gary Smerdon, CocoLoop, étude de Meta sur les accès mémoire ; les ratios de performance, les 145 déploiements et la baisse de coût de 83 % sont des chiffres d'AMD.