Технология CXL 3.0 и вычислительная память XCENA MX1 RISC-V

256 гигабайт в секунду на одном x16-линке — такую пропускную способность обеспечивает CXL 3.0. Цифра впечатляет, пока не задумаешься: зачем такой канал, если данные всё равно нужно тащить из памяти к процессору, обработать и вернуть обратно? Именно тут архитектура Compute Express Link третьего поколения начинает играть совсем другую роль. А вместе с ней — появляются устройства вроде XCENA MX1, где тысячи RISC-V ядер обрабатывают данные прямо у памяти, не перемещая их к CPU.

Разберёмся, что изменилось в CXL 3.0, почему расширение памяти сервера через CXL уже не выглядит как экзотика, и как корейский стартап с RISC-V ускорителями собирается перевернуть подход к memory-intensive нагрузкам.

CXL 3.0: что поменялось под капотом

CXL — открытый стандарт межсоединения, построенный поверх физического уровня PCIe. Первая версия появилась в 2019 году, вторая — в 2020-м. К августу 2022 года консорциум выпустил спецификацию CXL 3.0, и с ней всё стало заметно интереснее.

Скорость передачи данных удвоилась — с 32 GT/s до 64 GT/s. Это базовый rate PCIe 6.0, и CXL 3.0 наследует его без дополнительных задержек относительно CXL 2.0. Для x16-линка это даёт те самые 256 ГБ/с агрегированной сырой пропускной способности.

Но скорость — лишь часть истории. CXL 3.0 перешёл на 256-байтные flit'ы с PAM-4 сигнализацией. Для снижения задержки введён latency-optimized flit variant: CRC разбивается на 128-байтные sub-flit'ы, что убирает store-and-forward overhead на физическом уровне и экономит 2-5 наносекунд. Звучит немного, но когда речь идёт о когерентном доступе к памяти в кластере — каждая наносекунда на счету.

Обратная совместимость сохранена: 256-байтный flit работает и на скоростях 8, 16, 32 GT/s. Это позволяет внедрять CXL 3.0 в существующую инфраструктуру без полной замены оборудования. Дизайнеры серверных платформ могут использовать CXL 3.0 на пониженных скоростях, задействуя новые фичи протокола (sharing, fabric) даже до появления PCIe Gen6-ready компонентов по всей цепочке.

Три протокольных субстандарта — CXL.io (блочный I/O на базе PCIe), CXL.cache (когерентное кэширование) и CXL.mem (доступ к памяти устройства) — по-прежнему мультиплексируются на одном физическом линке. Но в третьей версии enhanced coherency позволяет Type-2 и Type-3 устройствам инвалидировать данные в кэше хоста (back-invalidation), когда устройство изменило локальную память. Без этого механизма хост мог работать с устаревшими данными — и для кластерных нагрузок это был серьёзный ограничитель.

Fabric, 4096 узлов и новый уровень масштабирования

CXL 2.0 поддерживал одноуровневые switch'и с древовидной топологией. Достаточно для простых конфигураций с memory pooling, но масштабировать такую схему на крупный кластер — задача с жёсткими ограничениями. Древовидная структура не допускает peer-to-peer между устройствами: всё проходит через корень иерархии, и latency растёт с каждым уровнем.

CXL 3.0 вводит полноценную fabric-архитектуру. Многоуровневая коммутация, не-древовидные топологии (mesh, ring, spine/leaf) и механизм адресации Port Based Routing (PBR), поддерживающий до 4096 узлов. Узлом может быть CPU-хост, CXL-ускоритель, PCIe-устройство или GFAM — Global Fabric Attached Memory.

GFAM — это тип CXL Type-3 устройства, подключённого к switch-ноде без привязки к конкретному хосту. К нему могут обращаться до 4095 узлов fabric'а. Для тех, кто проектирует composable-инфраструктуру, — это тот элемент, которого не хватало: разделяемая CXL память, доступная кластеру без программной координации. Представьте пул в десятки терабайт, к которому обращаются все вычислительные узлы как к локальной памяти — и аппаратная когерентность гарантирует, что никто не читает устаревшие данные.

CXL 3.0 снижает задержку на 2-5 нс за счёт sub-flit передачи — 128-байтные фрагменты CRC убирают store-and-forward overhead на физическом уровне.

И здесь принципиальный сдвиг: CXL 3.0 разграничивает memory pooling и memory sharing. В CXL 2.0 пул памяти делился на сегменты — один хост, один сегмент, одновременный доступ невозможен. Sharing в CXL 3.0 — это когерентный одновременный доступ нескольких хостов к одной области памяти с аппаратной гарантией актуальности данных. Программная координация (lock'и, барьеры) уходит на уровень ниже — в железо.

Для задач высокой доступности и кластеризации это означает: общий пул памяти между нодами, где каждая видит актуальное состояние данных без накладных расходов на синхронизацию через сеть. Peer-to-peer доступ между устройствами без участия хоста дополняет картину — RISC-V ускорители, GPU и NIC могут обмениваться данными напрямую через CXL fabric.

XCENA MX1: тысячи RISC-V ядер рядом с DRAM

Расширение памяти сервера через CXL — уже рабочая история. Samsung, Micron, SK hynix выпускают CXL-модули памяти. XCENA пошла дальше: их MX1 — это не просто расширитель, а вычислительная память (computational memory).

Идея: вместо того чтобы перемещать гигабайты данных из CXL-памяти к CPU для обработки, можно выполнить вычисления прямо там, где данные находятся. Near-data processing — подход, при котором тысячи встроенных RISC-V ядер обрабатывают запросы к векторным базам данных, аналитические операции и memory-intensive задачи без трафика по шине к процессору.

XCENA — fabless-стартап из Южной Кореи, основанный в 2022 году (ранее MetisX). Компания привлекла около $50 млн финансирования и оценена примерно в $167 млн. MX1 — их первый продукт, представленный на FMS 2025 (Future of Memory and Storage).

Архитектура MX1:

• Контроллеры DDR5-8400, четыре канала памяти

• До 1 ТБ на карту (4 × 256 ГБ DIMM)

• Тысячи кастомных RISC-V ядер со встроенным векторным движком (TFLOPS-класс)

• Поддержка CXL 3.2 и PCIe 6.0

• SSD RAID tier — расширение ёмкости до петабайтного масштаба с использованием SSD как вспомогательного уровня

• Аппаратная компрессия данных для увеличения эффективной ёмкости

• Полный SDK: драйверы, runtime-библиотеки, инструменты для интеграции

SSD-tiering заслуживает отдельного пояснения. MX1 использует SSD как дополнительный уровень хранения — медленнее DRAM, но ёмкость выходит на PB-масштаб. Для рабочих нагрузок, где горячие данные помещаются в DRAM, а холодные хранятся на SSD с минимальным overhead при подкачке — это разумный компромисс между скоростью и стоимостью за терабайт. Механизм напоминает tiered storage в классических СХД, но реализован на уровне контроллера памяти, а не на уровне ОС или гипервизора.

Софтверная экосистема — отдельная тема. XCENA поставляет SDK с многоуровневыми API: высокоуровневые интерфейсы позволяют запускать существующие AI- и аналитические нагрузки без переписывания кода, а низкоуровневые дают контроль над размещением данных и управлением вычислительными задачами на RISC-V ядрах. Драйверы совместимы с Linux (поддержка CXL в ядре начиная с 6.5) и стандартными средами разработки. Это снимает барьер входа: не нужно осваивать новый programming model или привязываться к проприетарной экосистеме.

MX1P и MX1S: два варианта для разных задач

XCENA готовит два чипа, и их интерфейсы отличаются.

MX1P с единственным x16-линком — вариант для прямого подключения к хосту с полной пропускной способностью одного порта. Типичный сценарий: расширение памяти конкретного сервера с аналитической или AI-нагрузкой, где важна полоса пропускания между хостом и CXL-устройством.

MX1S с двумя x8-линками — для конфигураций с CXL-свитчами и fabric-топологиями, где два канала обеспечивают гибкость подключения к разным доменам. Два линка позволяют подключить устройство одновременно к двум switch-доменам или обеспечить отказоустойчивость через мультипатинг — схема, знакомая всем, кто работал с FC SAN и multipath I/O.

Совместимость с Intel и AMD серверными платформами следующего поколения подразумевается поддержкой PCIe Gen6 и CXL 3.2 на уровне стандарта. XConn Tech уже показал PCIe Gen6 / CXL 3.0 switch-чипы, NVIDIA использует Gen6 в своих B300-платформах. Инфраструктурный пазл складывается: свитчи готовы, CPU-платформы на подходе, устройства типа MX1 выходят в production.

XCENA получила награду «Most Innovative Memory Technology» на FMS 2025 — второе признание подряд после «Most Innovative Startup» в 2024 году.

Куда вписывается near-data processing

Чтобы понять ценность вычислительной CXL памяти, достаточно посмотреть на типичные нагрузки, где CPU тратит время не на вычисления, а на ожидание данных.

Векторные базы данных — основа RAG-пайплайнов и семантического поиска. Операция поиска ближайших соседей (ANN) по миллиардному индексу требует десятков гигабайт памяти и генерирует хаотичные паттерны чтения. CPU нагружен минимально — он просто ждёт, пока данные доберутся из памяти. RISC-V ядра MX1 выполняют поиск и фильтрацию прямо рядом с DRAM, не создавая трафика на шине.

Аналитика на больших датасетах — сканирование колоночных данных, агрегации, join'ы. Тот же паттерн: данных много, вычислений на единицу данных мало, а bottleneck — перемещение между памятью и CPU.

KV-cache для LLM-инференса — GPU-память ограничена, а KV-cache растёт линейно с длиной контекста. CXL-расширение памяти с вычислительным ускорением позволяет разместить KV-cache в CXL-памяти и обращаться к нему без полного round-trip через хост.

Data preparation для ML-пайплайнов — ETL-операции, генерация эмбеддингов, трансформация таблиц. Фреймворки типа Apache Spark или Velox создают серьёзное давление на память, и MX1 может снять часть этой нагрузки.

Для сред виртуализации (Proxmox, VMware ESXi) расширение памяти через CXL с вычислительным ускорением открывает ещё одну плоскость: плотность виртуальных машин ограничена физической памятью хоста. CXL-расширение позволяет добавить терабайты памяти без замены платформы, а near-data processing снижает нагрузку на CPU хоста при операциях с памятью VM — деduplication, компрессия, zero-page detection. Это не замена DIMM'ам, а дополнительный tier с собственными вычислительными ресурсами.

Экономика: data movement как статья расходов

По данным CEO XCENA Джина Кима, значительная доля энергопотребления и времени в AI- и аналитических нагрузках уходит не на сами вычисления, а на перемещение данных между памятью, CPU и GPU. Memory pooling решает проблему ёмкости, но не устраняет этот трафик.

Вычислительная память меняет уравнение TCO в нескольких точках: снижение трафика по шине — меньше энергии, меньше задержка. Аппаратная компрессия — эффективная ёмкость растёт без добавления DIMM'ов. SSD-tiering — стоимость петабайта падает, горячие данные остаются в DRAM. Меньше зависимость от CPU — можно использовать серверы с меньшим количеством сокетов для тех же рабочих нагрузок.

Здесь есть и edge computing-аспект. На границе сети серверы часто ограничены по форм-фактору и энергобюджету. CXL-карта с вычислительной памятью позволяет обрабатывать аналитику локально, не отправляя потоки данных в центральный ЦОД. Для сценариев реального времени — видеоаналитика, IoT-агрегация, предиктивное обслуживание — это сокращает и задержку, и трафик по WAN-каналам.

Для IT-руководителей, принимающих решения о закупке серверного оборудования, это потенциальная точка оптимизации: вместо масштабирования количества серверов — масштабирование памяти с вычислениями на одном узле.

Что дальше

CXL 4.0 уже анонсирован (ноябрь 2025) с удвоением пропускной способности до 128 GT/s. Intel и AMD готовят серверные платформы с поддержкой CXL 3.x. PCIe Gen6-свитчи от XConn Tech выходят на рынок. Экосистема формируется — и вычислительная CXL память от XCENA попадает в окно, когда инфраструктура уже готова, а рабочие нагрузки (AI-инференс, векторные БД, real-time аналитика) требуют именно такого подхода.

XCENA предлагает рабочие сэмплы MX1 с октября 2025 года, production-версия запланирована на 2026-й. Пока это proof-of-concept, а не массовый продукт. Но сам факт, что near-data processing на RISC-V ядрах добрался до конкретного железа с SDK, говорит о том, что расширение памяти сервера выходит из стадии «просто больше DIMM'ов» в стадию «умная память, которая считает».

Остаётся вопрос: примет ли рынок вычислительную память как отдельную категорию — или она останется нишевым продуктом для специфичных нагрузок? Ответ будет зависеть от бенчмарков на реальных workloads и готовности софтверного стека. CXL 3.0 как стандарт уже состоялся. Теперь дело за теми, кто наполнит его продуктами.