HBF pour les poids des modèles IA, HBM pour le cache KV

Le goulet d’étranglement lié à la mémoire HBM devrait bientôt s’atténuer grâce à l’initiative de SanDisk, qui développe la High-Bandwidth Flash (HBF) en partenariat avec SK hynix. Cette technologie pourrait répartir les tâches aujourd’hui exclusivement confiées à la HBM. Le tout pourrait déboucher sur des économies d’échelle significatives pour l’infrastructure IA.

HBF peut offrir une largeur de bande en lecture des ordres de grandeur supérieure à celle d’une HBM4 JEDEC, mais souffre en endurance d’écriture

Avant de détailler le standard HBF, revenons sur le problème du mur de mémoire qui se pose souvent avec la HBM.

HBM et le mur de mémoire

Un modèle d’IA doté de 100 milliards de paramètres et fonctionnant en fp16 (2 octets par paramètre) nécessite 200 Go de HBM rien que pour stocker les poids du modèle. Les poids indiquent au modèle l’importance à accorder à chaque concept ou chaîne de mots. En règle générale, plus le modèle est gros, plus il doit en stocker. Mais ce n’est pas tout.

Imaginez que vous écrivez une histoire, mais avec une mémoire à court terme terrible. À chaque nouveau mot, vous relisez tout ce que vous avez déjà écrit pour vous souvenir du texte. Logiquement, plus le texte s’allonge, plus ce processus devient laborieux. Le cache Key-Value (KV) est comme une feuille de notes séparée qui garde la trace de ce qui a été écrit. Cela accélère l’ensemble par des ordres de grandeur. Mais plus le contexte grandit, plus ce cache KV augmente, et il est généralement stocké dans la HBM en raison de la vitesse et de la fréquence d’accès nécessaires.

Voici le problème : les empilements HBM4 sont soudés à côté du GPU et disposent d’une bande passante mémoire limitée. Par exemple, un empilement 12-Hi standard contient 36 Go de données, et un 16‑Hi peut atteindre 48 Go. La HBM doit donc stocker à la fois les poids du modèle et le cache KV. Pour augmenter la capacité HBM, il faut généralement augmenter le nombre de GPU, ce qui devient très coûteux très vite.

Ajoutez HBF à cette équation

Comme nous l’avons détaillé plus tôt, SanDisk développe avec SK hynix un standard HBF offrant 512 Go de stockage et une bande passante de 0,4 To/s à 3 To/s. De la même manière que la HBM empile de la DRAM, la HBF empile des puces NAND les unes sur les autres, avec des TSV (Through Silicon Vias) pour les connecter, et une puce de contrôle logique liée à cet ensemble NAND.

Le problème des cellules NAND, c’est leur lenteur. Une SRAM offre des temps de lecture d’environ 1 nanoseconde, contre environ 100 nanosecondes pour la DRAM et environ 100 microsecondes pour la NAND. La NAND est donc 1 000 fois plus lente en lecture qu’une HBM à base de DRAM. Mais la HBF exploite le parallélisme pour multiplier la bande passante par ordres de grandeur : la logique planifie des milliers de lectures parallèles simultanées. Ainsi, même si chaque lecture individuelle d’une cellule NAND est 1 000 fois plus lente, l’accumulation de milliers de lectures parallèles délivre une bande passante cumulée de 0,3 To/s à 3 To/s, contre seulement 6,4 Go/s pour une HBM4 selon la norme JEDEC.

Malgré cela, la HBF ne peut pas compenser la très faible vitesse d’écriture et la fragilité de la NAND. Le cache KV devra donc rester sur la HBM, car il nécessite des écritures fréquentes. Les poids du modèle, en revanche, peuvent migrer vers la HBF.

Pour finir, notez que les empilements HBF ne devraient pas être aussi bon marché que les SSD, surtout parce qu’ils nécessitent un packaging avancé qui reste coûteux. Ils pourraient néanmoins être bien moins chers que la HBM, ce qui débloquerait des économies d’échelle substantielles. De plus, libérer la HBM pour le cache KV permet d’allonger le contexte du modèle sans nuire à la précision des résultats, un avantage supplémentaire pour ce paradigme émergent.