CXL Memory Expansion для AI inference: больше RAM без иллюзии «дополнительной VRAM»

Что именно добавляет CXL в AI-сервер

Compute Express Link — это когерентный interconnect, построенный поверх физического слоя PCIe и рассчитанный на память и ускорители. Для задачи расширения RAM важнее всего протокол CXL.mem: CPU получает доступ к памяти на CXL-устройстве в общем системном адресном пространстве. В актуальной документации Linux Type-3 device описывается как memory expander с Host-Managed Device Memory; память может быть volatile или persistent.

Практический смысл прост: если сервер уже заполнен DIMM по каналам, а модель, embedding index, KV-cache staging или CPU-side preprocessing требуют ещё сотни гигабайт, Type-3 memory expander даёт новый источник ёмкости. Он может появиться как отдельный NUMA node или как DAX-устройство, а затем — в зависимости от конфигурации — быть добавлен в page allocator.

Важно не путать три вещи. Локальная DDR5 подключена к memory controller CPU напрямую. CXL memory находится дальше — за CXL/PCIe fabric. GPU HBM или GDDR — отдельная память ускорителя со своей пропускной способностью и латентностью. CXL расширяет host memory, а не физическую VRAM GPU. Поэтому вопрос «поместится ли модель» нельзя отделять от вопроса «сколько данных придётся гонять между host и GPU на каждом forward pass».

Это особенно заметно в AI inference. Если редкие CPU-side структуры просто должны существовать в памяти, дополнительная ёмкость может быть полезна. Если же горячие веса или KV-блоки постоянно читаются через более медленный уровень, latency и throughput начинают зависеть уже не от объёма, а от memory traffic.

CXL 2.0, 3.x и 4.0: что важно на практике

На бумаге CXL развивается быстро. CXL 2.0 добавил switching и memory pooling, CXL 3.x развил fabric, sharing и маршрутизацию, а CXL 4.0, опубликованный консорциумом 18 ноября 2025 года, поднял data rate с 64 до 128 GT/s, добавил bundled ports и расширил RAS-возможности памяти. Для проектирования нового железа это важно: ecosystem движется к более широким и более масштабируемым memory fabrics.

Но версия спецификации и зрелость production-стека — не одно и то же. Сервер должен поддерживать CXL на уровне CPU, BIOS/UEFI, root ports, topology и конкретного memory expander. Linux должен корректно перечислить memdev, decoders, regions и NUMA topology. А приложение должно уметь извлечь пользу из дополнительной памяти, не превратив её в latency trap.

Типичная ошибка — читать про memory pooling в спецификации и сразу планировать общий пул RAM для нескольких inference-нод. В документации Linux для CXL devices прямо отмечается, что по состоянию на ядро 6.14 формализованного интерфейса для управления non-DCD multi-host devices ещё не было, а DCD также оставался зоной активной разработки. Поэтому direct-attached memory expansion сегодня существенно проще и предсказуемее, чем полноценное динамическое распределение pooled memory между хостами.

Для production-проекта полезно мыслить слоями зрелости: сначала одиночный Type-3 expander и Linux memory hotplug, затем NUMA-aware размещение, и только после этого — switching, pooling и dynamic capacity. Это снижает количество одновременно неизвестных переменных.

Как Linux видит CXL Type-3 memory

Если платформа настроена правильно, CXL subsystem создаёт topology в /sys/bus/cxl/devices/, а memory devices появляются как memN. Далее decoders формируют memory regions. Через DAX слой регион можно оставить доступным как /dev/daxN.Y для явного mmap() либо преобразовать через dax_kmem в обычные hotplug memory blocks, которыми управляет page allocator.

Перед любыми тестами проверьте, что устройство вообще обнаружено на уровне PCIe/CXL и что kernel построил ожидаемую topology. Начинать tuning vLLM, когда BIOS не создал CFMWS или decoder не закоммичен, бессмысленно.

lspci -nn | grep -i -E 'cxl|memory'
ls -la /sys/bus/cxl/devices/
cxl list -M -D -R -T
numactl --hardware

Смотрите не только на общий объём RAM. Зафиксируйте NUMA node для CXL memory и CPU affinity процесса. Если allocator случайно размещает горячие страницы в дальней памяти, вы можете получить регрессию даже при большом запасе capacity.

Для ручной проверки полезно сопоставить memN, region, dax device и NUMA node. В современных kernel docs отдельно описан путь от CXL memdev через DAX до memory-hotplug. Это хороший ориентир: если на каком-то этапе объекта нет, проблема ещё не на уровне AI runtime.

NUMA и memory tiering: CXL надо считать «дальней» памятью

В обычном двухсокетном сервере уже есть NUMA: CPU быстрее обращается к своей локальной DDR5 и медленнее — к памяти другого socket. CXL добавляет ещё один уровень удалённости. Конкретные задержки зависят от CPU, поколения CXL, switch topology, width линка, interleave и самого expander, поэтому универсальную цифру в наносекундах лучше не переносить из чужого бенчмарка.

Полезная модель — не «у нас стало 1,5 ТБ RAM», а «у нас есть несколько классов памяти». Hot working set должен оставаться ближе к CPU или GPU, cold/elastic capacity можно вытеснять дальше. Тогда CXL начинает работать как capacity tier, а не как попытка заменить всю локальную DDR5.

Реальный кейс: inference node держит большой каталог моделей, tokenizer state, retrieval index и staging buffers. Вместо того чтобы раздувать локальную DDR до максимума, часть редко используемых объектов можно держать в CXL memory. Но если NUMA policy разрешит allocator перенести туда latency-critical network buffers или горячие CPU tensors, выигрыш в ёмкости быстро съедается ростом tail latency.

Проверяли ли вы, куда на самом деле попадают страницы процесса после нескольких часов нагрузки? Для tiered setup недостаточно снять один free -h после boot. Нужны NUMA counters, page migration statistics и workload-level latency.

Что CXL меняет для vLLM weight offload и KV offload

Актуальная документация vLLM поддерживает два релевантных механизма. --cpu-offload-gb позволяет держать часть весов модели в CPU memory и логически увеличить доступный объём памяти для модели, но данные приходится передавать к GPU во время forward pass. Для KV-cache доступны kv_offloading_size и backend native или lmcache, то есть часть KV capacity можно вынести в CPU-side memory.

CXL в таком дизайне интересен именно как расширение CPU-side capacity. Он может позволить увеличить offload buffer или обслуживать больше контекста, не набивая сервер экстремальным количеством локальной DDR5. Но физику это не отменяет: GPU всё равно работает быстрее со своей HBM, а host-side offload требует interconnect traffic.

vllm serve /models/your-model \
  --tensor-parallel-size 1 \
  --cpu-offload-gb 32 \
  --gpu-memory-utilization 0.90

vllm serve /models/your-model \
  --kv-offloading-size 64 \
  --kv-offloading-backend native \
  --gpu-memory-utilization 0.90

Эти команды — отправная точка, а не рецепт производительности. Если offloaded pages оказываются в CXL node, измеряйте TTFT, ITL, tokens/s и p95/p99 latency отдельно. Сценарий может быть выгодным для длинного контекста или редких запросов, но провальным для плотного decode, где одни и те же данные постоянно пересекают host-GPU boundary.

Почему CXL memory — не «дешёвая VRAM»

Фраза «виртуально увеличить GPU memory» встречается даже в документации runtimes, но её важно понимать буквально как software abstraction. Физически CXL Type-3 memory остаётся host-managed memory. Она не становится HBM и не получает её bandwidth только потому, что runtime умеет читать веса с CPU.

Представьте склад рядом с производственной линией. HBM — детали прямо у станка. Локальная DDR5 — склад в том же здании. CXL memory — дополнительный склад через коридор и пропускной пункт. Если деталь нужна раз в минуту, удалённый склад отлично увеличивает общий запас. Если станок требует новую деталь каждую микросекунду, логистика становится bottleneck.

Поэтому CXL особенно разумен для capacity-bound частей pipeline: large embedding tables, model repository cache, preprocessing buffers, spillover KV tiers, CPU inference stages, аналитика и большие memory-mapped datasets. Для bandwidth-bound tensor kernels он не заменяет локальную память ускорителя.

Есть и второй нюанс: GPU-direct access к конкретной CXL memory зависит от platform topology и software stack. Не следует автоматически считать, что любое CXL устройство можно эффективно читать с GPU как локальный BAR-mapped ресурс. Планируйте архитектуру вокруг поддерживаемого CPU-visible memory path, пока не доказано обратное на вашей платформе.

Memory pooling и Dynamic Capacity: перспективно, но проверяйте зрелость

Самая привлекательная идея CXL — не отдельная плата памяти в одном сервере, а пул, который можно распределять между несколькими хостами. В AI-кластере это звучит особенно красиво: inference-ноды получают дополнительную RAM по требованию, без физической перестановки DIMM и без постоянного overprovisioning.

Спецификация действительно движется в эту сторону. CXL 2.0 принёс switching и pooling, CXL 3.x расширил fabric/sharing, а Dynamic Capacity Device позволяет мыслить память как extents, которые fabric manager может назначать хостам. Но Linux support для multi-host management и DCD развивается постепенно. Поэтому дата лист оборудования с красивой схемой fabric ещё не означает готовый operational workflow в вашей ОС и orchestration stack.

Если вы строите production сейчас, отделите два проекта. Первый — direct-attached CXL memory expansion на одной ноде с понятным NUMA placement. Второй — лабораторный стенд для fabric, pooled memory и dynamic capacity. Так regression в одном новом слое не блокирует базовый inference service.

В roadmap это стоит держать: shared capacity может снизить stranded memory и улучшить utilization на уровне rack. Но закупать сложный switch fabric только ради идеи «когда-нибудь Kubernetes сам раздаст RAM» без конкретного kernel/firmware/tooling плана рискованно.

Как честно бенчмаркать CXL для AI inference

Не начинайте с общего memory bandwidth теста и вывода «CXL медленнее DDR, значит не подходит». Вопрос должен звучать иначе: какую часть working set мы можем вынести в более ёмкий tier, сохранив SLO приложения?

Сделайте три профиля: только локальная DDR5; DDR5 + CXL с явным размещением cold buffers; DDR5 + CXL с тем offload, который реально планируете в vLLM или другом runtime. Для каждого снимайте не только synthetic bandwidth, но и TTFT, ITL, tokens/s, concurrency при фиксированном SLO, CPU utilization, PCIe/CXL traffic и NUMA misses.

numastat -p $(pidof python)
cat /proc/$(pidof python)/numa_maps | head -n 50
perf stat -e cycles,instructions,cache-misses -p $(pidof python) sleep 30

Если runtime позволяет pinning или allocator policy, прогоните controlled A/B. Нужен ответ не «на сколько процентов CXL медленнее», а «сколько дополнительной concurrency/контекста мы получили и какой ценой в p99 latency».

Ещё одна ловушка — тестировать только cold start. CXL может помочь загрузить больше state, но steady-state decode способен вести себя иначе. Снимайте длительный профиль с реальным распределением prompt lengths и output lengths.

Где CXL Memory Expansion окупается лучше всего

Первый хороший сценарий — сервер с большим CPU-side working set, где локальные memory channels уже заполнены или дальнейшее увеличение DIMM ухудшает экономику конфигурации. Здесь CXL даёт capacity без полной смены платформы, если CPU и board уже поддерживают нужный generation и topology.

Второй — смешанный inference pipeline: GPU занимается матричными операциями, а CPU держит retrieval index, tokenizer/cache, metadata, feature store fragments и staging buffers. Если эти данные не обязаны иметь минимальную latency каждого доступа, CXL tier может быть полезнее, чем дорогая локальная DDR максимальной плотности.

Третий — эксперимент с KV/offload для длинных контекстов. Когда сервис упирается не в compute, а в объём кэша и число одновременных sessions, дополнительная host memory может расширить рабочий диапазон. Но здесь нужно особенно строго следить за PCIe/CXL traffic и latency.

А вот для небольшой модели, которая целиком помещается в HBM и обслуживает короткие запросы, CXL часто не решает реальной проблемы. Аналогично, если сервер имеет свободные DIMM slots и обычная DDR дешевле и быстрее, сначала заполните локальные memory channels. Новая технология оправдана не самим фактом поддержки, а устранением конкретного capacity bottleneck.

Чек-лист перед закупкой CXL-памяти для GPU-сервера

Начните с платформы, а не с memory card. Уточните у производителя сервера и CPU, какие CXL generations поддерживаются конкретными root ports, какие form factors допустимы, есть ли ограничения по bifurcation, retimers и совместимости BIOS. «PCIe 5.0 slot» сам по себе не гарантирует рабочий CXL.mem path.

Дальше проверьте firmware matrix: версия BIOS, BMC, CXL device firmware и рекомендованное ядро Linux. Для production полезно иметь документированный recovery path после firmware update и возможность посмотреть health/RAS telemetry устройства.

Затем определите software mode. Нужен DAX для явного mmap()? Или память должна стать обычным NUMA node через dax_kmem и memory hotplug? Как allocator будет различать local DDR и CXL? Кто отвечает за placement — приложение, libnuma, cgroup policy или kernel tiering?

Наконец, сформулируйте KPI до закупки. Например: увеличить поддерживаемый контекст и concurrency без роста p99 выше заданного порога; разместить крупный retrieval index в памяти; снизить стоимость capacity на node. Если KPI нельзя измерить, CXL легко превратить в дорогую лабораторную функцию.

Для смежных тем пригодятся материалы King Servers про метрики AI inference, Kubernetes для AI inference, GPU scheduling и проектирование AI-инфраструктуры.

Итог: CXL — новый tier памяти, а не магическое расширение GPU

CXL Memory Expansion полезно рассматривать как ещё один управляемый уровень памяти между локальной DDR и более медленным storage. Он способен снять capacity bottleneck на CPU-side части AI inference, дать пространство для offload и подготовить платформу к более гибким memory fabrics. Но ценность появляется только тогда, когда hot data остаётся близко к compute, а CXL используется осознанно для менее чувствительной к latency части working set.

В 2026 году спецификация уже дошла до CXL 4.0, тогда как production maturity отдельных pooling и dynamic-capacity сценариев всё ещё зависит от конкретного kernel, firmware и vendor stack. Поэтому практичный путь — начать с direct-attached Type-3 expander, проверить Linux topology и NUMA, затем провести workload-level A/B на реальном inference.

Если после теста вы получаете больше контекста, больше одновременных запросов или более крупный CPU-side dataset при приемлемом p99 — CXL решил задачу. Если вырос только объём в free -h, а SLO ухудшился, вы просто добавили более дальнюю память. Начните с измеримого bottleneck и тестового стенда, а уже затем переносите схему в production.