High Bandwidth Flash дає AI-прискорювачу сотні гігабайтів, але не замінює HBM

High Bandwidth Flash задумана як проміжний рівень між швидкою, дорогою HBM і значно повільнішою NAND у звичайному SSD. На Hot Chips 2026 компанія OXMIQ показала моделювання, за яким HBF справді може дати AI-прискорювачу сотні гігабайтів локальної пам’яті, але не є універсальною дешевою заміною HBM. Її перевага виникає лише тоді, коли завдання обмежене місткістю, а не пропускною здатністю.

Три заплановані класи HBF

Початковий Grade 1 передбачає 256 ГБ NAND у восьмишаровому стеку, UCIe зі швидкістю 8 GT/s та смугу 384 ГБ/с. Grade 2 збільшує місткість до 512 ГБ і пропускну здатність до 1,536 ТБ/с завдяки 16 GT/s. Grade 3 з UCIe 2.0 на 32 GT/s має досягти 3,072 ТБ/с за тієї самої місткості. Навіть найшвидший варіант використовує NAND, тому має інші затримки, блоки читання й обмежений ресурс запису.

Головна привабливість — у 8–16 разів більша місткість за HBM за порівнюваної вартості стека. Це може дозволити тримати величезну модель на одному прискорювачі замість розподілу між кількома GPU. Але дешевий гігабайт не дорівнює дешевому токену: якщо процесор чекає на дані, вища місткість не компенсує нижчу смугу.

Що показало моделювання

OXMIQ порівняла 72-прискорювальну стійку для моделі Kimi-K2 на один трильйон параметрів у FP4. HBM-конфігурація мала 20,7 ТБ пам’яті та сукупну смугу 1584 ТБ/с. Варіант лише з HBF збільшував місткість приблизно у 14 разів — до 294,9 ТБ, але зменшував смугу до 922 ТБ/с. Це дозволяло розмістити більше окремих копій моделі, проте при великій кількості одночасних запитів HBM краще використовувала обчислювальні блоки.

Ці числа є моделлю OXMIQ, а не тестом готової HBF. Вони добре ілюструють принцип: коли GPU потрібна пам’ять просто для розміщення ваг, HBF може скоротити кількість прискорювачів. Коли важлива максимальна генерація токенів на стійку, пропускна здатність знову стає вирішальною.

Де технологія має сенс

Найочевидніший сценарій — Mixture-of-Experts. У таких моделях більшість експертних ваг активується лише для окремих токенів. Рідко потрібні блоки можна тримати в HBF, а часто використовувані дані — у HBM. Інший варіант — великі KV-кеші для довгого контексту, якщо доступ до них достатньо розріджений. Велика локальна місткість також може зменшити мережевий обмін між GPU.

Для навчання або щільного інференсу, де всі ваги постійно читаються, HBF може погіршити результат. Гібридний кеш HBM теж не є магічним рішенням: за великого batch та різнорідних запитів популярність експертів вирівнюється, кеш промахується частіше.

Програмне забезпечення ще не готове

HBF потребує великих передач — до десятків кілобайт на читання та близько мегабайта на запис — через DMA, а не звичайну кеш-ієрархію GPU. Система повинна сама вирішувати, що зберігати в HBM, що в HBF, коли робити prefetch і як контролювати зношення NAND. За оцінкою OXMIQ, популярним рушіям на кшталт vLLM потрібна окрема підтримка такого рівня пам’яті.

Отже, HBF вирішує проблему місткості, але не скасовує потреби у HBM. Найреалістичніше майбутнє — багаторівнева пам’ять, де кожен тип отримує власну роль. Поки немає серійних продуктів і незалежних вимірювань, HBF слід оцінювати як спеціалізовану технологію для окремих великих моделей, а не як новий стандарт для всіх AI-прискорювачів.