High Bandwidth Flash (HBF) vise un espace encore peu occupé dans les accélérateurs IA : une capacité bien supérieure à celle de la HBM, avec un débit très au-dessus de la NAND classique. Une analyse présentée par OXMIQ Labs lors de Hot Chips 2026 montre toutefois que cette combinaison a ses limites. La HBF peut faire une vraie différence quand il s’agit de loger un modèle volumineux près du processeur, mais elle perd une bonne partie de son intérêt dès que la charge doit déplacer ces données en continu et à grande vitesse.
L’essentiel en 20 secondes
- La HBF empile de la NAND 3D pour rapprocher plusieurs centaines de gigaoctets 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 promet 8 à 16 fois la capacité de la HBM à coût comparable, selon ses promoteurs.
- OXMIQ prévient que la HBM garde l’avantage dès que le débit devient le facteur limitant.
- Les modèles Mixture of Experts et les très longs contextes comptent parmi les usages les plus prometteurs.
La technologie en est à ses tout débuts. Sandisk et SK hynix ont publié début août la première spécification technique de la HBF via l’Open Compute Project (OCP), à peine six mois après le lancement officiel du processus de standardisation. Google et Tenstorrent ont depuis rejoint le groupe et participé à la validation.
Le principe reste simple sur le papier. L’IA réclame toujours plus de mémoire, et la HBM se fait de plus en plus rare et chère, avec une capacité par puce qui reste limitée. La NAND, elle, offre une capacité énorme pour un coût bien moindre, mais elle a toujours été trop lente pour tourner directement aux côtés d’un GPU. La HBF cherche à occuper le terrain entre les deux.
Entre la HBM et un SSD, une architecture à part
High Bandwidth Flash empile de la mémoire NAND 3D reliée par des interfaces à très haut débit. La première spécification définit trois niveaux de performance : le Grade 1 démarre avec une pile de 256 Go pour environ 384 Go/s, le Grade 2 monte à 512 Go et environ 1,536 To/s, et le Grade 3 conserve les 512 Go mais atteint environ 3,072 To/s grâce à UCIe 2.0 à 32 GT/s.
| Technologie | Capacité | Débit | Avantage principal |
|---|---|---|---|
| HBM | Dizaines de Go 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 | Se rapproche de la HBM |
| SSD NVMe | Plusieurs To | Bien inférieur | Capacité et persistance |
Ces chiffres expliquent l’intérêt pour la HBF : un accélérateur pourrait embarquer plusieurs téraoctets de mémoire locale sans avoir à équiper une quantité équivalente de HBM. Sandisk avance une capacité 8 à 16 fois supérieure à la HBM pour un coût comparable. C’est une estimation qui dépendra de l’évolution des produits commerciaux, mais elle résume bien l’objectif : la HBF vise la capacité avant tout, ce n’est pas simplement une HBM moins chère.
Avoir 14 fois plus de mémoire ne veut pas dire traiter 14 fois plus vite
OXMIQ Labs a profilé lors de Hot Chips ce qui se passe quand une charge IA réaliste tourne sur de la HBF. Leur exemple porte sur un rack de 72 accélérateurs exécutant Kimi K2, un modèle MoE (Mixture of Experts) d’environ un billion de paramètres. À budget coût et énergie équivalent, une configuration tout-HBM fournit environ 20,7 To de capacité pour un débit total de 1 584 To/s. En passant à la HBF, la capacité grimpe à environ 294,9 To, soit 14 fois plus, mais le débit total tombe à environ 922 To/s.
Ce contraste résume tout le dilemme. Quand l’enjeu est de faire tenir un modèle en mémoire, la HBF change la donne : sa capacité permet de loger une instance complète du modèle dans chaque accélérateur et d’en faire tourner jusqu’à 72 sur le même rack, là où une configuration HBM demanderait huit accélérateurs rien que pour stocker une instance, réduisant d’autant le nombre d’instances indépendantes. Mais dès que le nombre d’utilisateurs simultanés augmente et que chaque GPU doit accéder en continu à de gros volumes de données, c’est le débit qui commande, et la HBM reprend l’avantage. Le coût par gigaoctet ne détermine donc pas forcément le coût par token.
Les modèles MoE, terrain de prédilection de la HBF
High Bandwidth Flash trouve une application particulièrement adaptée dans les modèles Mixture of Experts, qui regroupent plusieurs blocs de paramètres spécialisés (les experts) sans tous les solliciter pour générer chaque token. Le système ne sélectionne que certains experts selon les données traitées à l’instant, ce qui crée une situation intéressante côté mémoire : le modèle doit contenir une quantité énorme de paramètres pour rester disponible, alors qu’une bonne partie reste inactive à tout moment.
OXMIQ prend l’exemple d’un modèle d’environ 1,56 To de poids, dont 1,45 To relèvent des experts MoE, soit 93 % du total. Tout stocker en HBM coûterait cher. La HBF permettrait de garder près du processeur une part bien plus large de ces paramètres, en réservant la HBM aux données sollicitées en permanence. L’architecture pourrait alors s’organiser en hiérarchie : HBM pour ce qui est très demandé, HBF pour les grands ensembles moins utilisés, SSD ou stockage distant pour ce qui reste encore plus froid, avec la HBF placée bien plus près du processeur qu’un SSD classique et un débit largement supérieur.
Moins de trafic entre GPU peut compenser une mémoire plus lente
Les gros modèles MoE répartissent souvent leurs experts sur plusieurs accélérateurs. Quand un token a besoin d’un expert hébergé sur une autre GPU, une communication passe par le réseau d’interconnexion, et à grande échelle, ces échanges dits « all-to-all » peuvent absorber une part importante du débit disponible et de la consommation énergétique du système. Avec plusieurs téraoctets de HBF près de chaque accélérateur, il devient possible d’y garder localement une bien plus grande proportion d’experts, ce qui réduit d’autant le besoin de les répartir sur plusieurs GPU et donc le trafic inter-accélérateurs.
La HBF échange alors moins de débit mémoire contre plus de capacité locale et une dépendance réduite au réseau. Ça ne fonctionne pas toujours : quand la taille du batch augmente et que le système traite un grand nombre de requêtes différentes en parallèle, il finit par solliciter une gamme bien plus large d’experts. La partie « froide » du modèle devient alors chaude, et si les données doivent transiter en permanence de la HBF vers la HBM, la lenteur relative de la NAND commence à pénaliser la performance.
Les très longs contextes, second terrain favorable
Le second scénario intéressant concerne l’inférence sur de très longs contextes. Les modèles de langage maintiennent un cache KV pour éviter de recalculer certaines opérations sur les tokens déjà traités, et quand le contexte atteint des centaines de milliers, voire des millions de tokens, ce cache peut occuper une place énorme en mémoire. Certaines architectures d’attention dispersée n’ont pourtant pas besoin de consulter tout ce contenu à chaque étape de génération : une vaste cache KV pourrait rester sur la HBF, et seuls les blocs nécessaires en temps réel remonteraient vers la HBM.
L’idée de fond reste la même dans les deux cas : la HBF fonctionne bien quand une application doit garder beaucoup d’informations à proximité sans en consulter qu’une petite partie à chaque instant. Dès qu’il faut accéder à presque tout en continu, la HBM reste la meilleure option.
La NAND garde ses contraintes, même en HBF
Il existe une différence physique qu’une hausse de débit ne corrige pas à elle seule : la HBF reste de la mémoire NAND Flash, et ses opérations ne se comportent pas comme celles de la DRAM. La spécification prévoit des lectures et écritures par blocs relativement volumineux pour maximiser la performance, et OXMIQ souligne que les mouvements de données passeraient par DMA plutôt que par la hiérarchie classique de cache CPU ou GPU. L’endurance pose aussi question : la NAND supporte un nombre limité de cycles d’écriture, ce qui obligera les systèmes à gérer la répartition de l’usure des cellules. La HBF convient donc surtout aux données écrites rarement mais relues souvent, comme les poids d’un modèle, et devient moins intéressante pour des charges très intensives en écriture.
Le vrai défi pourrait venir du logiciel
Fabriquer la puce n’est qu’une partie du problème. Les frameworks d’inférence actuels sont pensés pour la DRAM et la HBM, et un système hybride doit décider en permanence quelles données restent en HBM, lesquelles basculent vers la HBF, et quand tout rapatrier. Il doit aussi anticiper ces transferts : attendre qu’une GPU réclame une donnée pour commencer à la copier depuis une mémoire plus lente ralentirait tout le traitement, d’où la nécessité de précharger en amont.
OXMIQ estime que des plateformes comme vLLM auront besoin d’un support dédié, avec gestionnaires de mémoire, politiques d’affectation, mécanismes de préchargement et surveillance de l’usure de la NAND. Côté matériel, des acteurs comme d-Matrix explorent déjà des architectures mémoire alternatives pour l’inférence, un signe que le secteur cherche activement des solutions au même problème par plusieurs angles à la fois. AMD, NVIDIA et les autres fabricants d’accélérateurs devront de leur côté fournir les mécanismes matériels, pilotes et runtimes capables de déplacer efficacement les données entre HBM et HBF. La technologie est définie sur le papier ; construire l’écosystème logiciel qui l’exploite sera sans doute bien plus complexe.
Une nouvelle couche dans la hiérarchie mémoire, pas un remplacement
La première spécification ouverte de la HBF corrige au passage une idée reçue qui a accompagné la technologie depuis ses débuts. Sandisk avait commencé à en parler publiquement en 2025 comme réponse au problème croissant 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 avec Google et Tenstorrent désormais associés au processus.
L’architecture qui se dessine rend de moins en moins probable un remplacement total de la HBM. Il est plus juste d’y voir une nouvelle couche dans la hiérarchie mémoire des accélérateurs : la HBM continuerait à gérer les données qui réclament le débit maximal, la HBF stockerait des centaines de gigaoctets à plusieurs téraoctets de données qui doivent rester proches sans être sollicitées en permanence, et les SSD garderaient leur rôle de capacité massive à moindre coût, avec une latence plus élevée. Un modèle très dense traité en gros lots n’en tirera pas grand-chose ; un modèle MoE géant, avec une large part de paramètres inactifs à tout moment, en revanche, coche toutes les cases.
D’où la conclusion d’OXMIQ lors de Hot Chips : la HBF est un outil spécialisé, pas une solution universelle aux enjeux de mémoire en IA. Si l’industrie parvient à aligner matériel, pilotes et frameworks d’inférence, elle pourrait trouver une vraie place entre la HBM et les SSD, mais son avenir dépendra moins de sa capacité à remplacer la HBM que de la capacité du secteur à identifier les scénarios où avoir des téraoctets près du processeur compte plus que de faire transiter chaque octet à vitesse maximale.
Questions fréquentes
Qu’est-ce que High Bandwidth Flash ou HBF ?
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, 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 quand la performance dépend d’un accès constant à de grandes quantités de données ; la HBF est plus pertinente quand l’enjeu principal est la capacité.
Quelle capacité peut offrir la HBF ?
La première spécification prévoit des piles jusqu’à 512 Go. En combinant plusieurs piles, un accélérateur pourrait embarquer plusieurs téraoctets de mémoire proche du processeur.
Quand la HBF arrivera-t-elle dans des systèmes commerciaux ?
La spécification ouverte a été publiée en août 2026 et la technologie reste en développement. Sandisk envisageait de premières démonstrations dès 2026, mais l’adoption commerciale dépendra aussi du support des fabricants d’accélérateurs et de l’écosystème logiciel.