# SK hynix FMS: Расширение CXL добавляет место хранения, а не эквивалент локальной памяти

Как переход от поставок HBM к демонстрациям иерархии на FMS изменил разговор о CXL: дополнительная ёмкость стала вопросом размещения данных под конкретную нагрузку.

Автор: Редакция Retrivium
Language: ru
Разбор опубликован: 2026-11-03
Дата события: 2026-08-07
Первоисточник новости: https://news.skhynix.com/en/fms-2026/
Канонический URL: https://retrivium.ai/ru/retrospectives/retro-fms-cxl-capacity-latency/

Материал о CXL в отчёте SK hynix о FMS относится к более широкому изменению планирования памяти ИИ. Ёмкость всё чаще обсуждают как место, куда ПО размещает состояние, а не как единый взаимозаменяемый запас. Более ранние новости о стойках и HBM объясняют этот сдвиг, не устанавливая производительность любого развёртывания CXL.

## Датированный путь

- 2026-01-05: [NVIDIA Kicks Off the Next Generation of AI With Rubin](https://nvidianews.nvidia.com/news/rubin-platform-ai-supercomputer).

- 2026-07-29: [SK hynix Announces 2Q26 Financial Results](https://news.skhynix.com/en/q2-2026-business-results/).

- 2026-08-07: [SK hynix представила многоуровневую архитектуру памяти на FMS 2026](https://news.skhynix.com/en/fms-2026/).

## Почему в истории появляется расширение ёмкости

Дорожная карта платформы задала системный взгляд на вычисления ИИ. Последующий отчёт о поставках HBM показал прогресс в особенно ценной части этой системы. К FMS в обсуждении появилась более широкая иерархия, включающая CXL. Редакционная связь состоит в том, что растущие рабочие нагрузки создают причины искать несколько мест для состояния. Это не доказывает, что CXL появилась из-за нехватки памяти у конкретного продукта или что все показанные решения имеют одинаковую топологию. Даты устанавливают контекст развития, но не раскрывают внутренние причины каждого инженерного выбора.

## Дополнительный путь меняет задачу размещения

Память, доступная через дополнительное соединение, имеет путь, которым должны управлять платформа и ПО. Номинальная ёмкость не определяет поведение доступа под конкретной нагрузкой. Условное приложение может держать часто используемое состояние ближе к вычислениям, а редко запрашиваемые данные размещать дальше. Если классификация ошибочна, запрос будет ждать обращения по другому пути. Поэтому оценка должна объяснять, какие объекты находятся на каждом уровне и как размещение меняется вместе с частотой доступа во время работы. Одного перечня установленных компонентов для такой оценки недостаточно.

## Сравнение ёмкости может скрывать решение о задержке

Представим сравнение серверов только по общему объёму установленной памяти. Более ёмкая конфигурация способна хранить больше состояния, но при этом медленнее обслуживать определённый интерактивный запрос. Это возможный сценарий, а не измеренный результат оборудования FMS. Он показывает необходимость отдельных доказательств для ёмкости и поведения сервиса. Полезные измерения сохраняли бы одинаковое определение нагрузки, учитывали параллельный трафик и показывали время ожидания доступа к состоянию. Без этих условий большее число байтов не подтверждает преимущество в инференсе и не объясняет, каким запросам оно могло бы помочь.

## Вывод для неоднородного парка

Распределённый парк может содержать разные пути доступа к памяти даже при похожих заявленных объёмах серверов. Если считать такие узлы взаимозаменяемыми, планировщик способен принять работу, требования которой к состоянию не соответствуют доступному пути. Анонс FMS напоминает о необходимости точного описания возможностей, но не предоставляет готовую политику размещения для такого парка. Разумная следующая оценка связала бы резидентность модели, повторно используемый контекст и локальность обращений с определённой целью запроса. После этого можно документировать случаи, где расширение ёмкости действительно помогает, и условия, в которых эффект отсутствует.

## Технический контекст

Связанный инженерный контекст: [Хостинг с приоритетом памяти](/ru/journal/vector-database-memory-hosting/); [Компромисс пропускной способности и задержки](/ru/journal/throughput-latency-tradeoff/).