На FMS 2026 показали Kioxia XL1 ёмкостью 512 ГБ. Задержка на демонстрации составила 755 нс, пропускная способность — меньше 1 ГБ/с. Для сравнения: локальная память типового одно- или двухсокетного сервера даёт около 100 нс и сотни гигабайт в секунду. По задержке XL1 уступает DRAM в 7,55 раза: 755 / 100 = 7,55.

Вердикт для закупки в 2026 году: XL1 пока не включаем в рабочую спецификацию. Сервер под 1С, терминальные сессии, файловое хранилище или обычную виртуализацию комплектуем ECC RDIMM на весь расчётный объём. Для AI и аналитики можно оставить платформенный запас под CXL, но сам модуль вынести в отдельное испытание.

Причина не только в скорости. Kioxia отправляет XL1 партнёрам как оценочные образцы. Производитель не назвал цену, энергопотребление, ресурс и дату серийных поставок. Сокращать объём DRAM ради такого устройства рано.

XL1 добавляет второй ярус памяти, а не заменяет DRAM

CXL — интерфейс поверх физического слоя PCIe, через который процессор получает доступ к внешней байт-адресуемой памяти. XL1 соединяет его с XL-FLASH: энергонезависимой памятью Kioxia с меньшей задержкой, чем у TLC- и QLC-NAND.

Схема рассчитана на два яруса. Часто используемые страницы остаются в DRAM, редко используемые переходят на XL1. Процессор получает больший адресуемый объём, но обращается к нему с разной скоростью.

Поэтому XL1 не ускорит сервер сам по себе. Результат зависит от доли запросов, которые приложение отправит в медленный ярус. Если туда попадут данные из критического пути, выигрыш в ёмкости обернётся ожиданием памяти.

Kioxia называет среди целевых задач обучение и инференс AI, графовые вычисления, аналитику больших данных, базы in-memory и плотную виртуализацию. Для этих нагрузок сотни гигабайт дополнительной памяти могут сократить обращения к накопителям или позволить держать модель и рабочий набор рядом с процессорами и ускорителями. Для 1С, терминального сервера и файлового хранилища таких испытаний XL1 пока нет.

У XL1 есть демонстрационные показатели, но нет финальной спецификации

Официальный анонс Kioxia подтверждает три вещи: модуль использует XL-FLASH и CXL, рассчитан на требовательные к памяти AI-нагрузки, а образцы поступают партнёрам для оценки в августе 2026 года. Kioxia отдельно предупреждает, что часть функций образцов ещё не проверена, а характеристики могут измениться.

Остальные подробности появились после показа. ServeTheHome увидел устройство E3.S на 512 ГБ с CXL 2.0 Type 3. В демонстрации оно показало 755 нс, почти 2 млн IOPS на блоках 512 байт и пропускную способность ниже 1 ГБ/с.

Эти значения годятся как ориентир для лаборатории, но не для закупочной ведомости. Официальный анонс Kioxia не закрепляет ёмкость 512 ГБ, форм-фактор E3.S, поколение CXL и тип устройства. Производитель также не опубликовал результаты XL1 на реальных AI-приложениях.

Пропускная способность ниже 1 ГБ/с требует особой осторожности. Устройство с таким показателем нельзя оценивать по тем же правилам, что массив из одних SSD для баз и виртуализации: XL1 работает как ярус памяти, а не как обычное блочное хранилище. Для решения о покупке нужен тест конечного приложения, а не сравнение паспортных IOPS.

Без испытания нельзя угадать, сколько DRAM заменит XL1

Исследование Virginia Tech и Microsoft SupMario показывает, насколько результат зависит от конкретной нагрузки. Авторы проверили 265 нагрузок, четыре CXL-устройства и семь конфигураций с задержкой от 140 до 410 нс. Модель прогнозировала результат с ошибкой до 10% для 91–94% CXL-нагрузок.

Показанные у XL1 755 нс лежат за пределами этого диапазона. Переносить выводы SupMario на модуль Kioxia напрямую нельзя. Удалённый процессорный сокет и CXL-коммутатор добавляют задержку, а для flash-памяти через несколько переходов исследователи допускают уже микросекундный уровень.

Пилот имеет смысл, если рабочий набор AI или аналитической системы не помещается в доступный объём DRAM. Во время испытания сравнивают не синтетические IOPS, а время выполнения задачи, загрузку ускорителей, долю обращений к XL1 и хвостовые задержки. Один и тот же модуль может помочь графовой обработке и замедлить приложение с частыми случайными обращениями к памяти.

Спецификация под задачу: сервер покупаем без расчёта на XL1

Возьмём типовой хост виртуализации, который нужно заказать сейчас. Допущение: на нём работают 12 виртуальных машин — две базы по 64 ГБ, восемь серверов приложений по 24 ГБ и две инфраструктурные машины по 16 ГБ.

Память считаем открыто:

базы: 2 × 64 = 128 ГБ;
серверы приложений: 8 × 24 = 192 ГБ;
инфраструктурные машины: 2 × 16 = 32 ГБ;
всего гостевым системам: 352 ГБ;
гипервизору и служебным процессам: 32 ГБ;
исходная потребность: 384 ГБ;
запас 25%: 384 × 1,25 = 480 ГБ.

Ближайшая практичная конфигурация — 512 ГБ ECC RDIMM. XL1 в эти 512 ГБ не засчитываем: серийного устройства и подтверждённых показателей ещё нет.

Спецификация для такого сценария:

Процессоры: 32 физических ядра с базовой частотой от 2,8 ГГц. Если виртуальным машинам назначено суммарно 96 vCPU, переподписка 3:1 даёт 32 физических ядра. Для тяжёлых баз часть ядер резервируем без переподписки.
Память: 512 ГБ ECC RDIMM с установкой, которая оставляет свободные каналы или слоты. При удвоении расчётной памяти до 960 ГБ переходи на 1 ТБ, а не рассчитывай закрыть разницу будущим XL1.
Диски: четыре NVMe по 3,84 ТБ в RAID 10 под виртуальные машины. Получаем около 7,68 ТБ полезной ёмкости; при расчётных 4 ТБ данных остаётся место под рост, снимки и служебные операции.
Загрузочный массив: два отдельных SSD в зеркале. Отказ системного накопителя не должен занимать рабочий массив и останавливать все гостевые машины.
Сеть: два порта 25 Гбит/с под рабочий трафик и перенос виртуальных машин плюс отдельный порт управления. Если инфраструктура пока работает на 10 Гбит/с, сервер можно подключить на этой скорости, сохранив 25-гигабитные адаптеры под следующий этап.
Питание: два блока питания с горячей заменой, каждый рассчитан на работу сервера без второго блока.
Корпус: 2U с запасом минимум в четыре отсека и одним доступным слотом расширения. Для будущего испытания XL1 одной механической совместимости мало: платформа, процессор, прошивка и операционная система должны поддерживать нужный режим CXL.

Компромисс здесь прямой: 512 ГБ DRAM придётся оплатить сразу. Зато конфигурация не зависит от оценочного модуля без цены и даты массовых поставок. Если серверная платформа уже упёрлась в предел памяти или свободных слотов, сравнивай расширение с условиями, при которых выгоднее заменить сервер целиком.

Когда платформу всё же стоит брать с CXL

Для обычного корпоративного сервера поддержка CXL не должна определять закупку. Сначала закрываем расчёт по ядрам, DRAM, дискам, сети и отказоустойчивости. Возможность поставить XL1 потом — дополнительный запас, а не основание урезать память сейчас.

Для AI-кластера логика другая. Если рабочий набор уже выходит за экономически приемлемый объём DRAM, выбирай платформу с поддержкой CXL и свободными слотами. Сам XL1 всё равно оставляй за пределами рабочей спецификации до появления серийного модуля.

Формулировка для закупочного обоснования:

Kioxia XL1 не включаем в рабочую конфигурацию 2026 года: производитель поставляет оценочные образцы и не опубликовал цену, ресурс, энергопотребление и финальные показатели. Сервер комплектуем ECC RDIMM под весь расчётный рабочий набор. XL1 допускаем только в отдельный пилот для AI или аналитики после выхода серийного устройства.

Условие перехода из пилота в эксплуатацию — конечное приложение укладывается в требуемое время при отказе одного модуля и при пиковой нагрузке. Показанные 512 ГБ, 755 нс и менее 1 ГБ/с остаются ориентирами демонстрации, а не обещанием для будущего серийного XL1.