High Bandwidth Flash (HBF) cherche à occuper un espace encore peu exploité dans le domaine des accélérateurs pour l’intelligence artificielle : une mémoire avec une capacité bien supérieure à celle de la HBM et un débit bien plus élevé que le stockage NAND traditionnel. Cependant, une analyse présentée par OXMIQ Labs lors de Hot Chips 2026 révèle que cette combinaison a ses limites. La HBF peut être très attractive lorsque l’enjeu est d’intégrer un modèle volumineux à proximité du processeur, mais elle perd une grande partie de ses avantages lorsque la charge doit déplacer continuellement ces données à grande vitesse.
Les points clés de High Bandwidth Flash en 20 secondes
- La HBF utilise de la NAND 3D empilée pour rapprocher plusieurs centaines de gigaoctets de capacité des accélérateurs IA.
- La spécification prévoit jusqu’à 512 Go par pile et environ 3 To/s dans sa version la plus avancée.
- Elle peut offrir entre 8 et 16 fois la capacité de la HBM à un coût comparable, selon ses promoteurs.
- OXMIQ avertit que la HBM reste meilleure lorsque le débit est déterminant pour la performance.
- Les modèles « Mixture of Experts » et les contextes très longs figurent parmi les usages les plus prometteurs.
Cette technologie est encore à ses débuts. Sandisk et SK hynix ont publié début août la première spécification technique de la HBF via le projet Open Compute (OCP), à peine six mois après le lancement officiel du processus de standardisation. Google et Tenstorrent ont également rejoint le groupe et participé à la validation de la technologie.
Le principe de la HBF est simple : l’IA nécessite de plus en plus de mémoire, et la HBM est extrêmement rapide mais aussi coûteuse et limitée en capacité. La NAND offre une capacité énorme à un moindre coût, même si elle a traditionnellement été trop lente pour fonctionner directement aux côtés d’une GPU.
La HBF cherche à créer une solution intermédiaire.
Entre la HBM et un SSD, mais avec une architecture différente
High Bandwidth Flash utilise de la mémoire NAND 3D organisée en piles et reliée par des interfaces à très haut débit.
La première spécification définit trois niveaux de performance.
Ce que l’on nomme Grade 1 démarre avec une pile de 256 Go offrant environ 384 Go/s. Grade 2 augmente la capacité à 512 Go et le débit jusqu’à environ 1,536 To/s.
Grade 3 conserve 512 Go mais atteint environ 3,072 To/s, en utilisant UCIe 2.0 à 32 GT/s.
| Technologie | Capacité caractéristique | Débit | Avantage principal |
|---|---|---|---|
| HBM | Decines de GB par pile | Très élevé | Alimenter en continu GPU/IA |
| HBF Grade 1 | 256 Go | 384 Go/s | Capacité |
| HBF Grade 2 | 512 Go | 1 536 To/s | Équilibre capacité/débit |
| HBF Grade 3 | 512 Go | 3 072 To/s | Rapprochement avec la performance HBM |
| SSD NVMe | Plusieurs To | Bien inférieur | Capacité et persistance |
Les chiffres montrent clairement pourquoi la HBF suscite de l’intérêt.
Un accélérateur pourrait disposer de plusieurs téraoctets de mémoire locale sans avoir à équiper une quantité équivalente en HBM.
Sandisk affirme que la HBF peut offrir entre 8 et 16 fois la capacité de la HBM à un coût comparable. Il s’agit d’une estimation, qui dépendra de l’évolution des produits commerciaux, mais elle résume bien la proposition : la HBF vise avant tout la capacité, sans simplement vouloir être une HBM à moindre coût.
Et cette différence est fondamentale.
Avoir 14 fois plus de mémoire ne signifie pas traiter 14 fois plus vite
OXMIQ Labs a utilisé Hot Chips pour analyser ce qui se produit lorsqu’une charge IA réaliste est appliquée à la HBF.
L’un de leurs modèles examine un rack de 72 accélérateurs exécutant Kimi K2, un modèle MoE (Mixture of Experts) comptant environ un billion de paramètres.
En conservant un budget similaire en coût et en puissance, la configuration basée uniquement sur la HBM fournit environ 20,7 To de capacité et un débit total de 1 584 To/s.
En remplaçant la HBM par la HBF, la capacité grimpe jusqu’à environ 294,9 To, soit environ 14 fois plus.
Le problème, c’est que le débit total descend à environ 922 To/s.
Cette différence illustre parfaitement le dilemme.
Si le principal enjeu est de faire tenir un modèle en mémoire, la HBF peut offrir un avantage énorme.
Si le modèle tient déjà en mémoire et que l’objectif est de produire le plus de tokens par seconde, la HBM peut s’avérer plus efficace.
Dans l’exemple de l’analyse, la capacité colossale de la HBF permettrait de loger une instance complète du modèle dans chaque accélérateur et d’en lancer jusqu’à 72 par rack.
La configuration avec la HBM nécessiterait huit accélérateurs simplement pour stocker chaque instance, réduisant le nombre d’instances indépendantes pouvant s’intégrer dans le même rack.
Mais lorsque le nombre d’utilisateurs simultanés augmente et que chaque GPU doit accéder en continu à de grandes quantités d’informations, c’est le débit qui devient déterminant.
Dans ce cas, la HBM reprend l’avantage.
C’est pourquoi le coût par gigaoctet ne détermine pas forcément le coût par token.
Les modèles MoE, un cas d’usage particulièrement intéressant
High Bandwidth Flash trouve une application particulièrement adaptée dans les modèles Mixture of Experts.
Ces modèles comportent plusieurs groupes de paramètres spécialisés, appelés experts, mais ils n’utilisent pas tous ces experts pour générer chaque token.
Le système sélectionne uniquement certains experts en fonction des données en cours de traitement.
Ce mécanisme crée une caractéristique très intéressante du point de vue mémoire : le modèle peut contenir une quantité énorme de paramètres, nécessaires pour la disponibilité, même si une grande partie reste inactive à tout instant.
OxMIQ a utilisé comme exemple un modèle ayant environ 1,56 To de poids, dont environ 1,45 To seraient ceux des experts MoE, représentant 93 %.
Stocker tout cet ensemble en HBM serait coûteux.
La HBF permettrait de maintenir à proximité du processeur une quantité bien plus grande de ces paramètres, en réservant la HBM pour les données nécessitant des accès fréquents.
L’architecture pourrait s’organiser conceptuellement selon une hiérarchie :
HBM pour les données très sollicitées, HBF pour de grands ensembles moins utilisés, et SSD ou stockage distant pour les données encore plus froides.
La différence avec un SSD classique réside dans le fait que la HBF serait beaucoup plus proche du processeur, avec un débit bien supérieur.
Moins de trafic entre GPU peut compenser une mémoire plus lente
Il existe aussi un autre avantage potentiel.
Les modèles MoE de grande taille répartissent souvent leurs experts sur plusieurs accélérateurs.
Lorsqu’un token nécessite un expert hébergé sur une autre GPU, une communication doit avoir lieu via la connexion réseau interconnectée.
À grande échelle, ces échanges de type « all-to-all » peuvent représenter une part importante du débit disponible et de la consommation énergétique du système.
Avec plusieurs téraoctets de HBF proches de chaque accélérateur, il serait possible d’y maintenir localement une proportion beaucoup plus importante d’experts.
Cela pourrait réduire la nécessité de répartir ces experts entre plusieurs GPU et diminuer une partie du trafic inter-accélérateurs.
Dans cette configuration, la HBF échangerait un compromis : moins de débit mémoire contre une capacité locale accrue et une dépendance moindre au réseau.
Mais cela ne fonctionnera pas toujours.
Lorsque la taille du batch augmente et qu’un grand nombre de requêtes différentes sont traitées simultanément, le système peut être amené à accéder à une gamme beaucoup plus étendue d’experts.
Dans ce cas, la partie « froide » du modèle devient alors chaude.
Si les données doivent être transférées en permanence de la HBF vers la HBM, la vitesse moindre de la NAND commence à pénaliser la performance.
Les grands contextes offrent une autre opportunité
Le second scénario particulièrement intéressant concerne l’inférence avec des contextes très longs.
Les modèles de langage maintiennent une structure appelée cache KV pour conserver des informations sur les tokens déjà traités et éviter de recalculer certaines opérations.
Lorsque le contexte atteint des centaines de milliers, voire des millions, de tokens, cette cache peut occuper une quantité énorme de mémoire.
Cependant, certaines architectures d’attention dispersée n’ont pas besoin de consulter tout ce contenu à chaque étape de génération.
Une vaste cache KV pourrait rester sur la HBF, tandis que seuls les blocs nécessaires en temps réel seraient transférés vers la HBM.
L’idée reste la même.
La HBF fonctionne mieux quand une application doit garder beaucoup d’informations à proximité, mais ne consulte qu’une petite partie à chaque instant.
Si l’accès doit se faire à presque tout en continu, la HBM sera plus appropriée.
La NAND a aussi ses limites, que la HBM ne connaît pas
Il existe aussi une différence physique que l’augmentation du débit seule ne peut corriger.
La HBF utilise toujours de la mémoire NAND Flash.
Cela signifie que ses opérations ne se comportent pas comme celles de la DRAM.
La spécification prévoit des lectures en blocs et des écritures plus volumineuses, et pour maximiser la performance, il faut effectuer des transferts relativement importants. De plus, OxMIQ souligne que les mouvements de données seraient réalisés via DMA, plutôt que directement intégrés dans la hiérarchie classique de cache CPU ou GPU.
L’endurance est aussi une préoccupation.
La NAND supporte un nombre limité de cycles d’écriture. Les systèmes devront donc gérer la répartition de l’utilisation des cellules afin d’éviter une usure prématurée.
Cela rend la HBF particulièrement adaptée aux données écrites peu souvent, mais relues fréquemment, comme les poids d’un modèle.
Pour les charges très écrasantes, la HBF pourrait devenir moins attractive.
Le vrai défi pourrait venir du logiciel
La fabrication des chips n’est qu’une étape dans le défi global.
Les frameworks d’inférence actuels sont principalement conçus pour la DRAM et la HBM.
Un système hybride doit donc décider en permanence quels données restent en HBM, lesquelles peuvent être transférées vers la HBF, et quand tout ramener en arrière.
Il doit aussi anticiper ces transferts.
Attendre qu’une GPU ait besoin d’un données pour commencer à le copier d’une mémoire plus lente peut ralentir le traitement. Le logiciel doit donc prévoir le préchargement et anticiper ces transferts.
OxMIQ indique que des plateformes comme vLLM nécessiteraient un support dédié pour la HBF, incluant gestionnaires de mémoire, politiques d’affectation, mécanismes de pré-chargement et surveillance de l’usure de la NAND.
Les fabricants d’accélérateurs devront aussi intervenir.
AMD, NVIDIA et autres devront fournir des mécanismes hardware, pilotes, et runtimes capables de déplacer efficacement les données entre la HBM et la HBF.
La technologie est définie sur papier, mais développer un écosystème logiciel capable de l’exploiter sera probablement beaucoup plus complexe.
La HBF ne vise pas à remplacer la HBM
La première spécification ouverte de la HBF contribue aussi à corriger une interprétation erronée qui a accompagné la technologie depuis ses débuts.
Sandisk a commencé à parler publiquement de High Bandwidth Flash en 2025 comme une solution à la problématique croissante de capacité mémoire dans les systèmes IA.
Depuis, la proposition a évolué.
En février 2026, Sandisk et SK hynix ont officialisé un groupe de travail au sein de l’Open Compute Project, et en août, ils ont publié la première spécification technique. Google et Tenstorrent participent aussi désormais au processus.
L’architecture en train de se dessiner montre qu’il est de moins en moins probable que la HBF remplace totalement la HBM.
Il semble plus logique d’envisager une nouvelle couche dans la hiérarchie mémoire des accélérateurs.
La HBM continuerait à gérer les données nécessitant le débit maximal.
La HBF stockerait des centaines de gigaoctets ou plusieurs téraoctets de données qui doivent rester proches, mais auxquelles on n’accède pas en permanence.
Les SSD continueraient à offrir des capacités encore plus grandes à un moindre coût, avec une latence supérieure.
Le choix final dépendra des cas d’usage.
Un modèle très dense, réalisé avec de gros lots, n’en tirera pas beaucoup d’avantages. En revanche, un gigantesque modèle MoE avec de nombreux paramètres inactifs peut constituer un très bon candidat.
D’où la conclusion d’OXMIQ lors de Hot Chips : la HBF est un outil spécialisé, pas une solution universelle pour les enjeux de mémoire en IA.
Si l’industrie parvient à intégrer matériel, pilotes et frameworks d’inférence, la High Bandwidth Flash pourrait trouver une place importante entre la HBM et les SSD.
Mais son succès ne dépendra probablement pas de sa capacité à remplacer la HBM.
Il s’agira plutôt de repérer les scénarios où disposer de téraoctets près du processeur sera plus important que de faire transiter chaque octet à la vitesse maximale possible.
Questions fréquentes
Qu’est-ce que High Bandwidth Flash ou HBF ?
La HBF est une technologie basée sur la NAND Flash conçue pour offrir une capacité et un débit bien supérieurs au stockage flash traditionnel, tout en étant placée à proximité des accélérateurs IA.
La HBF peut-elle remplacer la HBM ?
Pas dans tous les scénarios. La HBM reste préférable lorsque la performance dépend d’un accès constant à de grandes quantités de données, tandis que la HBF est plus pertinente lorsqu’il s’agit principalement de capacité mémoire.
Quelle capacité peut offrir la HBF ?
La première spécification prévoit des piles jusqu’à 512 Go. En combinant plusieurs piles, il sera possible de concevoir des accélérateurs avec plusieurs téraoctets de mémoire proche du processeur.
Quand pourra-t-on voir la HBF dans des systèmes commerciaux ?
La spécification ouverte a été publiée en août 2026 et la technologie est encore en développement. Sandisk envisageait initialement des premières démonstrations en 2026, mais l’adoption commerciale dépendra également du support des fabricants d’accélérateurs et de l’écosystème logiciel.