Hot Chips 2026 : la mémoire HBF prépare son arrivée

15 fois plus de capacité qu’en HBM

Mise au point par le consortium OCP (Open Compute Platform, qui standardise des technologies pour les hébergeurs), la norme HBF définit déjà trois modèles : un circuit de 256 Go de capacité avec un débit de 384 Go/s (a priori déjà obsolète), un autre de 512 Go avec un débit de 1,5 To/s (le modèle à commercialiser) et un dernier de toujours 512 Go, mais avec un débit de 3 To/s (la génération suivante).

Comparativement, les données sur un SSD dans une baie connectée en réseau sont lues ou écrites à des vitesses qui oscillent, au mieux, entre 40 et 80 Go/s.

En termes de capacité, un circuit HBF offre 15 fois mieux qu’un circuit HBM qui ne contient au mieux que 36 Go. Et, ce, pour le même prix de fabrication. Un GPU classiquement équipé de huit circuits mémoires pourrait ainsi disposer de 4 To de capacité s’il n’était pourvu que de HBF (au lieu de 288 Go en HBM).

Pour autant, l’OCP imagine qu’il est plus réaliste de plancher sur des GPU dont seul un quart des composants mémoires serait de la HBF et le reste de la HBM. Car le débit d’un circuit HBM atteint déjà 2,75 To/s. Dans cette configuration, un GPU doté de huit composants mémoires aurait 1,24 To de capacité et un débit cumulé de 19,5 To/s (contre 22 To/s en HBM seul).

Des contraintes et des perspectives

Au sein de la startup Oxmiq Labs, qui planche sur la conception de GPU de nouvelle génération, l’architecte de circuits électroniques Anurag Agrawal est l’un des ingénieurs les plus avancés dans l’implémentation de la mémoire HBF. Selon la présentation qu’il a faite lors de la conférence Hot Chips 2026, deux contraintes techniques restent à lever avant de passer de la théorie à la pratique.

D’une part, il faut lire ou écrire des données par blocs de 64 Ko (environ 16 000 tokens), alors que les LLM écrivent et lisent en mémoire des données avec une granularité qui peut descendre à un seul octet. Pire, pour tirer pleinement profit de la bande passante, il faudrait aussi écrire à chaque fois un train de 16 blocs, soit 1 Mo d’un coup (256 000 tokens).

D’autre part, il faut ajouter dans la puce accélératrice une sorte de firmware qui sache comment répartir les écritures pour limiter l’usure des cellules NAND. Cette partie logicielle devrait aussi gérer le routage des données vers la HBM ou vers la HBF selon ce que veut faire l’application.

Anurag Agrawal entrevoit aussi deux possibilités qui permettraient à la mémoire HBF de présenter de l’intérêt au-delà d’un stockage simplement plus rapide.

Avec les LLM MoE (Mixture of Experts), qui sont des assemblages de plusieurs petits LLM spécialisés, il serait possible d’économiser une grande partie de la mémoire HBM. En y chargeant seulement les morceaux de LLM utiles au prompt en cours et en laissant le reste sur la mémoire HBF.

Avec des GPU interconnectés pour travailler de concert, la mémoire HBF pourrait aussi faire office de cache pour stocker les données d’un autre GPU, sans attendre de les récupérer depuis le réseau.

Mais, encore une fois, tous les logiciels qui implémenteraient de telles capacités restent à écrire. Car il n’est pas possible de simplement remplacer de la HBM par de la HBF.