3 августа 2026 года Sandisk и SK hynix опубликовали первую спецификацию HBF через Open Compute Project. Она задаёт ёмкость до 512 ГБ на стек и пропускную способность от 0,4 до 3,0 ТБ/с, но сама по себе не описывает доступную к заказу серверную платформу.
Вердикт для закупки в 2026 году: не включай HBF в обязательные требования без коммерческого предложения на серийное оборудование и результатов испытаний. Для узла вывода ИИ запроси у поставщика дорожную карту, цену и срок поставки. Конфигурации под 1С, терминальный доступ, видеоархив, файловое хранилище и резервное копирование продолжай считать по их нагрузке — анонс HBF не даёт оснований менять этот расчёт.
HBF добавляет слой между HBM и SSD
HBF расшифровывается как High Bandwidth Flash. SK hynix и Sandisk ставят её между HBM и SSD в архитектуре систем вывода ИИ.
HBM обслуживает часть архитектуры с высокой пропускной способностью. HBF выступает поддерживающим слоем: разработчики рассчитывают совместить высокую ёмкость обработки данных с меньшим энергопотреблением на этапе вывода ИИ.
Речь идёт об обработке запросов уже обученной моделью. Поэтому оценивать HBF нужно по тому, как она влияет на ёмкость памяти, задержку, энергопотребление и скорость конкретной модели, а не по характеристикам обычного серверного ОЗУ.
Для остальных нагрузок по-прежнему считай рабочий набор данных, задержку, IOPS и объём хранения. Если база или виртуальные машины упираются в дисковую подсистему, сравнивай доступные All Flash СХД и локальные NVMe, а не будущий слой памяти.
Спецификация задаёт интерфейс, но не готовый сервер
Документ Sandisk и SK hynix описывает интерфейс между xPU и HBF, электрические требования, ожидаемую производительность, надёжность, упаковку стеков и операции чтения и записи. Для соединения выбран UCIe.
Этого хватает разработчикам ускорителей, памяти и корпусов, чтобы проектировать компоненты под общий стандарт. Закупщику нужен следующий уровень конкретики: серверная платформа, перечень поддерживаемых ускорителей, условия поставки и результаты тестов на рабочей модели.
Перед включением HBF в спецификацию закупки запроси пять параметров:
- задержку при твоём профиле обращений;
- энергопотребление одного стека;
- ресурс записи;
- число стеков на ускоритель;
- цену модуля и всей платформы.
SK hynix называет снижение совокупной стоимости владения одной из целей HBF. Цель ещё не равна измеренному результату. Экономию можно внести в расчёт закупки после того, как поставщик назовёт цену и энергопотребление, а испытание покажет производительность на конкретной модели.
512 ГБ и 3 ТБ/с ещё не говорят о скорости модели
Первая спецификация предусматривает стеки из 8 или 16 слоёв NAND. Максимальная ёмкость — 512 ГБ, пропускная способность разделена на три класса в диапазоне примерно от 0,4 до 3,0 ТБ/с. Эти параметры SK hynix раскрыла при анонсе стандарта.
Из них можно посчитать только идеальный последовательный проход. Берём десятичные единицы и делим объём на пропускную способность:
0,512 ТБ / 0,4 ТБ/с = 1,28 с;0,512 ТБ / 3,0 ТБ/с ≈ 0,17 с.
Расчёт не учитывает задержку, размер блоков, долю случайных обращений, работу контроллера и ограничения xPU. По нему нельзя определить число токенов или запросов в секунду. Он показывает лишь разницу между крайними классами HBF при непрерывном последовательном чтении.
Тестировать HBF имеет смысл, когда доступной HBM не хватает для модели и её KV-кэша, а обращения к накопителям уже ограничивают вывод. Порог придётся определить на своей нагрузке: он зависит от модели, длины контекста, размера пакета и архитектуры ускорителя.
Открытый стандарт не отменяет риск ранней закупки
Sandisk и SK hynix начали совместную стандартизацию в августе 2025 года. Рабочая группа OCP стартовала в феврале 2026-го, а первую спецификацию выпустили в августе. Google и Tenstorrent участвовали в проверке технологии и подготовке стандарта.
Открытая публикация через OCP даёт производителям общую техническую основу. Но открытый интерфейс не заменяет проверку конкретного сервера: закупщику всё равно нужны матрица совместимости, условия гарантии, срок поставки и тесты под его нагрузку.
По прогнозам отрасли, спрос на сложные решения памяти, включая HBF, вырастет примерно к 2030 году. Поэтому параметры HBF уместны в дорожной карте платформы, но для запроса предложений на 2026 год их стоит делать опцией, а не обязательным фильтром. Такой же принцип работает с ещё не вышедшими процессорами: будущую архитектуру отделяют от доступной закупочной позиции.
Спецификация под задачу: что закупать в 2026 году
Исходные данные для решения такие: проект должен стартовать в 2026 году, а анонс стандарта не заменяет коммерческое предложение на сервер. Профиль нагрузки тоже не задан. Поэтому число CPU-ядер, объём ECC-памяти, состав NVMe-массива и сеть нельзя вывести из характеристик HBF. Конфигурация вроде «32 ядра, 512 ГБ RDIMM и четыре NVMe» без числа моделей, размера KV-кэша и целевой скорости была бы догадкой.
Спецификация закупки в этой ситуации выглядит так:
| Позиция | Требование |
|---|---|
| Платформа | Серийный сервер, который поставщик отгрузит в срок проекта |
| Ускоритель | Модель, проверенная на твоей нейросети и целевой длине контекста |
| Быстрая память | Доступная HBM в объёме, подтверждённом тестом нагрузки |
| Оперативная память | ECC RDIMM; объём рассчитывается по хостовой части модели и сопутствующим службам |
| Локальное хранение | Серверные NVMe; число и RAID определяются объёмом моделей, журналов и допустимым простоем |
| Сеть | Пропускная способность рассчитывается по обмену между узлами и хранилищем |
| Питание | Два блока питания; мощность — по конфигурации ускорителей с запасом из документации изготовителя сервера |
| HBF | Опция только при наличии доступной платформы, цены и результатов испытаний |
| Расширение | Свободные слоты, отсеки и доступная мощность под следующий этап проекта |
Практический результат для закупки: базовую конфигурацию считай без обязательной HBF. CPU, RDIMM, NVMe и сеть привязывай к измеренной нагрузке, а поддержку HBF запроси отдельной опцией. Чтобы выбрать накопители, сначала раздели требования к задержке и IOPS и требования к объёму — эта развилка разобрана в материале про SSD, NVMe и HDD в сервере.
Если HBM вмещает модель и рабочий KV-кэш, ожидание HBF не даёт проекту измеримой выгоды. Если памяти не хватает, но задачу можно распределить между доступными ускорителями, сравни цену такого узла со стоимостью переноса запуска. HBF попадает в план испытаний при двух условиях: текущая подсистема хранения ограничивает вывод, а поставщик предлагает сервер для теста с понятными ценой и сроком поставки.
Что записать в запрос поставщику
Формулировка для закупочного решения:
HBF не включаем в обязательные требования к серверу. Для узлов вывода ИИ просим отдельно указать доступные платформы с HBF, сроки поставки, цену и результаты испытаний на сопоставимой нагрузке.
По HBF запроси четыре группы данных:
- Серверную платформу и подтверждённую дату поставки.
- Поддерживаемые xPU и версию интерфейса UCIe.
- Ёмкость стека и класс пропускной способности.
- Измеренные задержку, энергопотребление и скорость на твоей модели.
Обычную серверную нагрузку закупай по текущему расчёту CPU, ECC-памяти, накопителей и сети. Узел ИИ, которому хватает HBM, — тоже. Если модель не помещается в HBM, а подсистема хранения ограничивает вывод, запроси сервер с HBF на испытание. До такого теста HBF остаётся пунктом дорожной карты, а не обязательной строкой спецификации.
