Архитектуры для расширения памяти GPU через высокоскоростные сетевые фабрики: обзор исследований

Раздел 1: Введение: необходимость расширения памяти GPU за пределы монолитного сервера

Современные вычислительные задачи, особенно в области искусственного интеллекта, анализа больших данных и научных симуляций, предъявляют беспрецедентные требования к ресурсам графических процессоров (GPU). Экспоненциальный рост вычислительной мощности GPU значительно опережает темпы увеличения емкости их встроенной памяти. Этот дисбаланс приводит к возникновению так называемой «стены памяти», которая становится основным ограничивающим фактором для производительности и масштаба решаемых задач. В ответ на этот вызов архитектура центров обработки данных (ЦОД) переживает фундаментальный сдвиг от традиционных монолитных серверов к более гибким, дезагрегированным моделям. В данном разделе рассматриваются предпосылки этого сдвига, анализируется проблема «стены памяти» и определяются экономические и производительные стимулы для дезагрегации ресурсов, а также классифицируются подходы к расширению памяти GPU.

1.1. Анализ «стены памяти» в современных архитектурах GPU

Основная проблема современных высокопроизводительных вычислений заключается в растущем разрыве между скоростью обработки данных и скоростью их доставки к вычислительным ядрам. В то время как производительность GPU, измеряемая в терафлопсах (TFLOPS), удваивается каждые несколько лет, емкость встроенной высокоскоростной памяти (High-Bandwidth Memory, HBM) растет значительно медленнее.¹ Этот разрыв создает «стену памяти»: приложения становятся ограничены не вычислительной мощностью, а объемом данных, которые могут быть размещены непосредственно в локальной памяти GPU.³

Объемы наборов данных в таких областях, как обучение глубоких нейронных сетей, геномный анализ и гидродинамическое моделирование, часто измеряются терабайтами, что значительно превышает емкость памяти даже самых современных GPU, составляющую десятки гигабайт.⁴ Это вынуждает разработчиков прибегать к сложным и трудоемким методам ручного управления данными, таким как «тайлинг» (разделение данных на небольшие блоки) и организация многоэтапных миграций данных между памятью хоста и GPU.⁶ Такие подходы не только усложняют процесс разработки и снижают производительность труда программистов, но и вносят существенные задержки, сводя на нет преимущества параллельной архитектуры GPU. Когда вычислительные ядра простаивают в ожидании данных, производительность системы резко падает, и инвестиции в мощное оборудование не окупаются.¹

1.2. Экономические и производительные стимулы для дезагрегации ресурсов

Проблема «стены памяти» на уровне одного GPU является частным случаем более общей проблемы неэффективности ресурсов в масштабе всего ЦОД. Традиционная архитектура монолитного сервера, в которой вычислительные ресурсы (CPU, GPU), память (DRAM) и хранилища данных жестко связаны в одном корпусе, приводит к системной неэффективности. Исследования, проведенные в гипермасштабируемых ЦОД, показывают, что средняя утилизация оперативной памяти часто колеблется в диапазоне 40-60%.⁷ Это означает, что значительная часть дорогостоящих модулей памяти простаивает, что приводит к «застрявшим» ресурсам (stranded resources) и неоправданно высокой совокупной стоимости владения (Total Cost of Ownership, TCO).

В многопроцессорных серверах возникает еще одна проблема — «фрагментация ресурсов». Например, сервер может иметь свободные GPU, но исчерпанные ресурсы CPU или оперативной памяти хоста, что делает невозможным запуск новых задач на этих свободных GPU. Система Prism, развернутая в производственной среде, была разработана специально для решения этой проблемы путем разделения пулов CPU и GPU.⁸

В ответ на эти вызовы формируется новая парадигма архитектуры ЦОД — дезагрегация ресурсов.⁹ Эта концепция предполагает разделение сервера на независимые пулы ресурсов — вычислений, памяти, хранилищ, ускорителей, — соединенных высокоскоростной сетевой фабрикой. Такой подход позволяет динамически и по требованию компоновать логические серверы с необходимой конфигурацией, что значительно повышает гибкость и эффективность использования оборудования.

Возможность независимо масштабировать пулы памяти и вычислений позволяет точно соответствовать требованиям рабочих нагрузок и, по оценкам, может снизить TCO на величину до 25% без ущерба для производительности приложений.⁷ Таким образом, технические решения для удаленного доступа к памяти, рассматриваемые в данном отчете, являются не просто способом ускорить одно приложение, а ключевым элементом для построения более экономически эффективной архитектуры ЦОД нового поколения.

1.3. Определение спектра расширения памяти: от локальной памяти хоста до сетевых удаленных пулов

Подходы к расширению памяти GPU можно классифицировать по уровням, образующим иерархию с компромиссом между емкостью, пропускной способностью и задержкой.

• Уровень 1: Встроенная память HBM. Это самый быстрый, но и самый ограниченный по объему уровень памяти, расположенный на одной подложке с кристаллом GPU. Она обеспечивает пропускную способность в несколько терабайт в секунду, но ее емкость обычно не превышает нескольких десятков гигабайт.
• Уровень 2: Оперативная память хост-системы. Этот уровень использует основную память CPU в качестве пространства для подкачки (swap) для GPU. Доступ к ней осуществляется через шины PCIe или более быстрые интерконнекты, такие как NVLink. Технологии, подобные NVIDIA Unified Memory (UVM), автоматизируют миграцию данных между HBM и памятью хоста, упрощая программирование.¹³
• Уровень 3: Оперативная память удаленных систем. Это основной предмет данного исследования. Данный уровень предполагает использование оперативной памяти других серверов в кластере, доступ к которой осуществляется через высокоскоростную сетевую фабрику (например, InfiniBand или Ethernet со скоростью 400, 800 Гбит/с и выше) с использованием протоколов, таких как RDMA.⁷ Этот уровень предлагает практически неограниченную емкость, но вносит дополнительные сетевые задержки.

Запрос инженера, послуживший поводом для данного исследования, находится в области перехода от Уровня 2 к Уровню 3. Цель состоит в том, чтобы сделать удаленную память Уровня 3 настолько быстрой и доступной, чтобы она могла служить эффективным расширением для локальной памяти GPU, преодолевая ограничения как по емкости, так и по производительности традиционных подходов.

Раздел 2: Фундаментальные парадигмы: от унифицированной памяти к полной дезагрегации

Для реализации доступа GPU к удаленной памяти существуют две основные системные парадигмы, которые определяют, как эта память представляется приложению и как осуществляется управление данными. Эти подходы — унифицированная виртуальная память (UVM) и модель дезагрегированной памяти (DM) — представляют собой фундаментальный компромисс между простотой программирования и максимальной производительностью. Выбор между ними определяет, где находится «интеллект» системы управления памятью: в драйвере и аппаратном обеспечении или в приложении и его среде выполнения.
2.1. Модель унифицированной виртуальной памяти (UVM): программная абстракция для интеграции гетерогенной памяти
Модель унифицированной виртуальной памяти, наиболее известным представителем которой является технология NVIDIA CUDA Unified Memory, предлагает программистам элегантное решение проблемы управления гетерогенной памятью. Ее суть заключается в создании единого когерентного виртуального адресного пространства, которое охватывает как физическую память GPU (HBM), так и память хост-системы (DRAM).5 Благодаря этому программисту больше не нужно вручную вызывать функции копирования данных, такие как

cudaMemcpy, между хостом и устройством.14

Механизм страничной подкачки по требованию (On-Demand Paging):

Основой работы UVM является механизм страничной подкачки по требованию. Когда поток GPU пытается получить доступ к данным по виртуальному адресу, физическая страница которого отсутствует в его локальной памяти, генерируется аппаратное прерывание — ошибка страницы (page fault). Это прерывание перехватывается драйвером GPU, который совместно с аппаратным обеспечением организует миграцию требуемой страницы из памяти хоста (или, теоретически, из удаленной памяти) в локальную память GPU.5 После завершения миграции и обновления таблиц страниц выполнение потока возобновляется.

Последствия для производительности:

Несмотря на очевидное удобство, такая прозрачность имеет высокую цену. Обработка ошибки страницы, особенно если данные находятся на удаленном узле и должны быть переданы по сети, вносит значительные задержки, измеряемые микросекундами. Это на несколько порядков больше, чем задержка доступа к локальной памяти HBM (наносекунды).7 В сценариях, где объем используемых данных превышает емкость памяти GPU (memory oversubscription), система начинает постоянно перемещать страницы туда и обратно. Этот процесс, известный как «пробуксовка» (thrashing), приводит к катастрофическому падению производительности, поскольку GPU большую часть времени тратит на ожидание данных, а не на вычисления.5

Научные исследования в этой области сосредоточены на методах смягчения этих накладных расходов. Предлагаются различные стратегии интеллектуальной предварительной выборки (prefetching), которые пытаются предсказать будущие обращения к памяти и заранее загрузить необходимые страницы, а также усовершенствованные политики вытеснения (eviction policies), которые стремятся сохранить в памяти GPU наиболее востребованные данные.6 Тем не менее, наивная реализация UVM поверх сетевого соединения для критичных к производительности приложений часто оказывается нежизнеспособной.

2.2. Модель дезагрегированной памяти: разделение вычислительных ресурсов и памяти

Модель дезагрегированной памяти (DM) представляет собой более радикальный подход, в рамках которого память становится первоклассным, независимым ресурсом, доступным по сети.9 Вместо того чтобы просто расширять память одного сервера, эта модель создает общий пул памяти для всего кластера.

Логическая и физическая дезагрегация:

Существуют две основные архитектуры реализации DM:

• Логическая дезагрегация: Этот программно-ориентированный подход использует неиспользуемую оперативную память стандартных монолитных серверов для создания общего пула. Он не требует изменений в аппаратном обеспечении. Ярким примером является исследовательская система Infiniswap, которая представляет удаленную память операционной системе как очень быстрое устройство подкачки.7
• Физическая дезагрегация: Этот аппаратно-ориентированный подход предполагает создание специализированных систем с отдельными «лезвиями» вычислений и «лезвиями» памяти, соединенными высокоскоростной фабрикой. Такая архитектура обеспечивает максимальную производительность, но требует специального оборудования.7

Для инженера, исследующего возможность использования удаленной RAM, модель логической дезагрегации представляет наибольший интерес, поскольку она может быть реализована на существующей инфраструктуре. Семилетняя история развития проекта SymbioticLab, в рамках которого были созданы системы Infiniswap, Leap и Hydra, демонстрирует как потенциал, так и сложность создания комплексного программного стека для управления дезагрегированной памятью на базе RDMA. Этот стек решает проблемы производительности, отказоустойчивости и изоляции в многопользовательской среде.7

Выбор между UVM и DM — это, по сути, выбор места, где принимаются решения об управлении данными. UVM делегирует эту задачу системе (драйверу и аппаратному обеспечению), обеспечивая прозрачность для программиста, но жертвуя производительностью из-за универсальности и реактивности своих механизмов. Модель DM, особенно при явном управлении, переносит эту ответственность на уровень приложения или среды выполнения. Это требует от разработчика больших усилий по пониманию локальности данных и оркестрации их перемещений, но взамен предоставляет полный контроль и возможность достичь максимальной производительности. Интерес к низкоуровневым фреймворкам, таким как DPDK, указывает на явное предпочтение второй модели, где производительность и контроль ставятся выше удобства «черного ящика» UVM.

Таблица 1: Сравнение парадигм расширения памяти GPU

Эта таблица наглядно демонстрирует компромиссы. Хотя UVM может теоретически работать поверх удаленной памяти, высокая задержка и риск «пробуксовки» делают этот подход непрактичным для большинства высокопроизводительных задач. Явное управление, несмотря на свою сложность, является единственным жизнеспособным путем для создания производительных систем, использующих удаленную RAM в качестве расширения памяти GPU. Это обосновывает необходимость изучения низкоуровневых технологий, таких как RDMA и DPDK.

Раздел 3: Аппаратные средства и протоколы для удаленного доступа к памяти

Для того чтобы концепция расширения памяти GPU за счет удаленных ресурсов стала реальностью, необходима технологическая основа, способная обеспечить передачу данных с минимальными задержками и высокой пропускной способностью. В этом разделе рассматриваются ключевые аппаратные и протокольные решения, которые лежат в основе высокопроизводительного удаленного доступа к памяти, начиная с сетевого уровня и заканчивая спецификой интеграции с GPU.

3.1. Remote Direct Memory Access (RDMA): краеугольный камень низколатентных сетей

Технология Remote Direct Memory Access (RDMA) является фундаментальной для всех современных систем дезагрегации памяти. Ее ключевое преимущество заключается в возможности прямого доступа к памяти удаленного сервера без участия операционной системы и центрального процессора на удаленной стороне. Это кардинально снижает задержки и нагрузку на CPU по сравнению с традиционными сетевыми стеками, такими как TCP/IP.19

Обзор InfiniBand и RoCE:

RDMA реализуется через несколько сетевых технологий, из которых наиболее распространены две:

• InfiniBand (IB): Это специализированная сетевая технология, изначально разработанная для высокопроизводительных вычислений (HPC). Она обеспечивает гарантированно низкие задержки и высокую пропускную способность благодаря аппаратному управлению потоком и отсутствию потерь. Однако специализированное оборудование (коммутаторы, адаптеры) делает ее более дорогостоящим решением.19
• RDMA over Converged Ethernet (RoCE): Эта технология позволяет использовать протоколы RDMA поверх стандартной сети Ethernet. Она является более экономически выгодной альтернативой InfiniBand, но требует тщательной настройки сети (например, Priority Flow Control), чтобы обеспечить передачу без потерь, что критически важно для производительности RDMA.19

Обход ядра (Kernel Bypass) и копирование с нулевым копированием (Zero-Copy):

Высокая производительность RDMA достигается за счет двух основных принципов:

1. Обход ядра: Приложения, использующие RDMA, взаимодействуют напрямую с сетевым адаптером (NIC), минуя ядро операционной системы. Это устраняет дорогостоящие системные вызовы и переключения контекста, которые являются основным источником задержек в традиционном стеке TCP/IP.19

Нулевое копирование: Сетевой адаптер с поддержкой RDMA может самостоятельно считывать данные непосредственно из буфера приложения и отправлять их в сеть (для операций записи) или записывать входящие данные напрямую в буфер приложения (для операций чтения). Это исключает промежуточные этапы копирования данных в буферы ядра, что значительно экономит циклы CPU и пропускную способность системной шины.19

3.2. NVIDIA GPUDirect RDMA: создание прямого пути к памяти GPU

Хотя стандартный RDMA эффективно решает задачу быстрой передачи данных между оперативной памятью двух серверов, для задач, связанных с GPU, этого недостаточно. Традиционный путь данных в такой системе все еще содержит узкое место: данные, полученные сетевым адаптером, сначала должны быть помещены в оперативную память хоста (часто во временный «bounce buffer»), а затем центральный процессор должен инициировать их копирование в видеопамять (VRAM) GPU. Этот путь включает несколько операций копирования и активно задействует CPU, что сводит на нет многие преимущества RDMA.4

Технология NVIDIA GPUDirect RDMA решает эту проблему, создавая прямой аппаратный путь для данных между сетевым адаптером и памятью GPU.

Архитектурный анализ:

• Традиционный путь: Сеть → NIC → RAM хоста → CPU → VRAM GPU. Этот путь неэффективен и создает узкое место на шине памяти хоста и CPU.4
• Путь GPUDirect RDMA: Сеть → NIC → VRAM GPU. Данные передаются напрямую между сетевым адаптером и памятью GPU по шине PCIe, полностью минуя CPU и системную память. Это обеспечивает минимальные задержки, максимальную пропускную способность и нулевую нагрузку на CPU в процессе передачи данных.4

Механизм работы GPUDirect RDMA основан на способности GPU отображать часть своей видеопамяти в адресное пространство шины PCI Express через так называемые базовые адресные регистры (Base Address Register, BAR). Это делает память GPU напрямую видимой и адресуемой для других устройств на той же шине PCIe, включая сетевой адаптер.23 На программном уровне эта функциональность поддерживается специальными драйверами, такими как

nvidia-peermem, которые обеспечивают необходимую координацию между драйвером GPU и драйвером сетевого адаптера для установления прямого пирингового (peer-to-peer) соединения.22

Системные требования:

Для достижения максимальной производительности с GPUDirect RDMA критически важна физическая топология системы. В идеале, GPU и сетевой адаптер должны быть подключены к одному и тому же коммутатору PCIe и находиться под управлением одного корневого комплекса (root complex). Это минимизирует путь данных и позволяет избежать прохождения трафика через межпроцессорные соединения (например, QPI/UPI), которые могут стать узким местом.25

Внедрение GPUDirect RDMA представляет собой фундаментальный сдвиг в архитектуре распределенных систем. Оно превращает GPU из простого вычислительного сопроцессора, управляемого CPU, в первоклассную сетевую конечную точку. Это означает, что GPU может самостоятельно, без вмешательства CPU в путь данных, отправлять и получать данные по сети. Такая архитектура позволяет проектировать распределенные приложения как систему напрямую взаимодействующих друг с другом GPU, а не как набор хостов с подключенными к ним ускорителями. Для задачи расширения памяти это означает, что GPU-ядро может оперировать данными, поступающими из удаленной RAM, с минимально возможной задержкой, фактически рассматривая удаленный пул памяти как прямое, хотя и более медленное, продолжение своей локальной памяти.

Раздел 4: Архитектурные шаблоны для удаленного расширения памяти GPU

На основе фундаментальных технологий, рассмотренных в предыдущем разделе, исследователи и инженеры разрабатывают конкретные системные архитектуры для практической реализации удаленного расширения памяти GPU. Эти архитектуры варьируются от комплексных производственных систем до различных программных стеков, управляющих удаленной памятью. В этом разделе анализируются примеры таких архитектур, исследуются программные подходы к управлению данными и обсуждаются проблемы, связанные с программированием и обеспечением когерентности в распределенной среде.

4.1. Проектирование на системном уровне: исследование архитектуры Prism

Система Prism является ярким примером производственного внедрения дезагрегации ресурсов GPU в гипермасштабируемой среде. Хотя ее основной задачей является дезагрегация вычислений, ее архитектура и принципы работы служат мощным доказательством жизнеспособности использования RDMA для связи между разделенными компонентами системы.8

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

Prism построена на разделенной инфраструктуре, состоящей из двух типов узлов, соединенных высокоскоростной сетью RDMA:

• Вычислительные узлы (CPU Nodes, CNs): Серверы с большим количеством ядер CPU и большим объемом оперативной памяти, но без GPU.
• Гетерогенные узлы (Heterogeneous Nodes, HNs): Серверы с мощными GPU, но со скромными ресурсами CPU и памяти.
  Такое разделение создает два независимых, масштабируемых пула ресурсов, которые могут быть скомпонованы в соответствии с требованиями конкретной задачи.8

Рабочий процесс:

Система автоматически анализирует вычислительный граф задачи, например, модели глубокого обучения для рекомендаций (DLRM), и разделяет его на две части: подграф, интенсивно использующий CPU и память, и подграф, требующий вычислений на GPU. Первый выполняется на узле CN, второй — на узле HN. Промежуточные данные, необходимые для связи между подграфами, передаются по сети RDMA.8

Значение:

Prism демонстрирует, что сеть RDMA обладает достаточной производительностью, чтобы соединять дезагрегированные компоненты, выполняя при этом строгие требования к задержкам (SLO) в реальной производственной среде. Эффективное использование удаленных GPU в этой архитектуре неявно подразумевает доступ к удаленной памяти, в которой находится контекст выполнения и данные для этих GPU. Это подтверждает, что высокоскоростная сеть может служить «позвоночником» для распределенных гетерогенных систем.

4.2. Программные стеки для управления удаленной памятью

Помимо высокоуровневого системного дизайна, ключевую роль играет программный стек, который управляет удаленным пулом памяти и представляет его приложению.

Подкачка и свопинг через RDMA:

Один из подходов заключается в том, чтобы сделать удаленную память прозрачной для приложения, интегрировав ее на уровне операционной системы. Система Infiniswap реализует этот подход, представляя пул удаленной памяти как очень быстрое блочное устройство для подкачки (swap). Когда приложению не хватает локальной памяти, ОС автоматически выгружает неактивные страницы в удаленную память через RDMA.7 Преимущество этого метода в его прозрачности для приложений — не требуется никаких изменений в коде. Однако он страдает от значительных накладных расходов программного стека ОС на пути обработки страничных прерываний.

Прямой доступ к кэшу и управление удаленными объектами:

Альтернативная модель избегает дорогостоящей миграции целых страниц (обычно 4 КБ или больше). Вместо этого данные на удаленном узле доступны с гранулярностью строки кэша (например, 64 или 128 байт) без перемещения всей страницы. Этот механизм, как правило, реализуется аппаратно через RDMA-движок и используется в многопроцессорных системах для доступа к памяти соседнего GPU.16 Этот подход позволяет избежать больших единовременных затрат на миграцию страницы, но взамен каждая операция доступа к удаленным данным несет на себе задержку сетевого обхода. Выбор между этими двумя моделями — «миграция страниц» и «прямой доступ» — зависит от шаблона доступа к памяти приложения. Для приложений с высокой пространственной локальностью (последовательный доступ к большим блокам данных) миграция страниц может быть более эффективной. Для приложений с разреженным, непредсказуемым доступом предпочтительнее может оказаться прямой доступ.

Низкоуровневое управление виртуальной памятью:

Современные API, такие как низкоуровневые функции управления виртуальной памятью, появившиеся в CUDA 10.2 (cuMemMap, cuMemAddressReserve), отражают тенденцию к предоставлению разработчикам большего контроля.28 Эти функции позволяют отделить резервирование диапазона виртуальных адресов от его сопоставления с физической памятью. Это является критически важным строительным блоком для создания пользовательских менеджеров памяти. С помощью таких API можно разработать сложную среду выполнения, которая будет динамически сопоставлять виртуальные адреса в пространстве GPU с физической памятью, находящейся на удаленных узлах и доступной через RDMA.

4.3. Модели программирования и проблемы когерентности
Программирование в среде с распределенной памятью сопряжено со значительными трудностями, в первую очередь связанными с обеспечением когерентности данных. Когда структуры данных разделены между памятью нескольких GPU, находящихся на разных узлах, изменения, сделанные одним GPU, должны быть корректно видны другим.29

Модели программирования GPU, такие как CUDA, используют слабую модель когерентности памяти. В рамках одного GPU когерентность между различными потоковыми мультипроцессорами (SM) обеспечивается на уровне кэша L2. Однако между потоковыми блоками, выполняющимися на разных GPU (особенно на разных сетевых узлах), никакой автоматической когерентности не предусмотрено. Это означает, что вся синхронизация и обеспечение видимости данных ложатся на плечи программиста, который должен использовать явные барьеры и операции передачи данных, что значительно усложняет разработку.29

Успешная архитектура удаленного расширения памяти — это не просто отдельный компонент, а целостная, совместно спроектированная система. Она требует тщательного согласования аппаратной топологии (расположение GPU и NIC на шине PCIe), сетевого протокола (RDMA), механизмов на уровне ОС и сложной среды выполнения (runtime). Опыт систем, таких как Prism и Infiniswap, показывает, что не существует универсального решения. Prism добивается успеха за счет глубокого понимания графа вычислений приложения, что позволяет ей эффективно его разделять. Infiniswap предлагает универсальный подход, но требует многолетних исследований для решения проблем производительности и надежности. Выбор инженером низкоуровневого фреймворка, такого как DPDK, указывает на намерение создать специализированную среду выполнения, которая, подобно Prism, будет принимать интеллектуальные решения о размещении данных и способах доступа к ним, основываясь на характеристиках конкретной рабочей нагрузки.

Раздел 5: Подход с использованием DPDK: фреймворк для высокопроизводительной интеграции GPU и сети

Данный раздел посвящен непосредственному рассмотрению технологии, представляющей особый интерес для инженера, — Data Plane Development Kit (DPDK). Анализируется, как DPDK в сочетании с GPUDirect RDMA может быть использован для построения высокопроизводительного конвейера для доступа к удаленной оперативной памяти. DPDK предоставляет не просто набор инструментов, а целостный шаблон проектирования для создания систем ввода-вывода для GPU, который формализует разделение между плоскостью данных (data plane) и плоскостью управления (control plane).

5.1. Введение в Data Plane Development Kit (DPDK) и библиотеку gpudev

DPDK — это набор библиотек и драйверов для ускорения обработки сетевых пакетов. Его ключевые принципы — работа в пространстве пользователя (userspace) и обход сетевого стека ядра ОС. Это позволяет приложениям напрямую взаимодействовать с сетевым оборудованием, избегая накладных расходов на системные вызовы и копирование данных в ядре, что обеспечивает чрезвычайно низкие задержки и высокую пропускную способность.30

Начиная с версии 21.11, в состав DPDK была включена библиотека gpudev. Ее цель — интегрировать GPU в экосистему DPDK в качестве полноправного участника. Библиотека gpudev решает следующие задачи 30:

• Абстрагирование от специфики конкретной реализации GPU, предоставляя универсальный API.
• Реализация базовых операций с памятью GPU (выделение, освобождение).
• Упрощение взаимодействия между сетевым адаптером, CPU и GPU.
• Предоставление доступа к специфичным для драйвера GPU функциям через общий интерфейс.

Для GPU NVIDIA функциональность gpudev реализуется через специальный бэкенд-драйвер, который использует CUDA. Для активации всех возможностей, включая прямую передачу данных, DPDK должен быть скомпилирован с поддержкой библиотек CUDA и GDRCopy.30

5.2. Реализация плоскости данных: создание пулов памяти DPDK в памяти GPU

Плоскость данных отвечает за эффективное перемещение информации. В контексте задачи расширения памяти это означает создание пути, по которому данные из удаленной RAM (полученные по сети) попадают в память GPU с минимальными накладными расходами. DPDK и gpudev позволяют реализовать это через создание пулов памяти (mempool) непосредственно в видеопамяти GPU.30

Процесс настройки такого конвейера данных включает следующие шаги, использующие функции gpudev 30:

1. Выделение памяти на GPU: С помощью функции rte_gpu_mem_alloc() в памяти целевого GPU выделяется большой непрерывный блок памяти.
2. Регистрация памяти в DPDK: Функция rte_extmem_register() сообщает фреймворку DPDK об этом внешнем (по отношению к RAM хоста) блоке памяти, делая его доступным для использования.
3. Создание DMA-отображений: Ключевой шаг, на котором активируется GPUDirect RDMA. Функция rte_dev_dma_map() создает необходимые отображения в сетевом адаптере, которые позволяют ему осуществлять операции прямого доступа к памяти (DMA) непосредственно в выделенный регион памяти GPU.
4. Создание пула mbuf: Наконец, функция rte_pktmbuf_pool_create_extbuf() создает стандартный для DPDK пул mbuf (структур, описывающих сетевые пакеты), но в качестве хранилища для самих данных пакетов использует ранее выделенную и зарегистрированную память GPU.

В результате этой последовательности действий создается конвейер с нулевым копированием. Входящие сетевые пакеты, содержащие данные из удаленной RAM, принимаются сетевым адаптером и без какого-либо участия CPU или оперативной памяти хоста помещаются напрямую в память GPU, где они становятся немедленно доступны для обработки CUDA-ядрами.

5.3. Проектирование плоскости управления: синхронизация CPU-GPU с помощью списков обмена данными

После того как путь для данных создан, возникает вторая, не менее важная задача: как сообщить GPU о том, что новые данные прибыли, не прибегая к дорогостоящим операциям синхронизации (например, блокировкам или прерываниям)? Для решения этой задачи gpudev предлагает механизм, называемый «списком обмена данными» (rte_gpu_comm_list).30

Этот механизм представляет собой структуру данных в разделяемой памяти, которая функционирует как кольцевой буфер без блокировок с одним производителем (CPU) и одним потребителем (GPU).

• Роль CPU: Поток CPU, выполняющий цикл опроса DPDK (rte_eth_rx_burst), принимает пакеты в mempool, расположенный в памяти GPU. Затем он заполняет следующую свободную ячейку в comm_list информацией о полученных пакетах (например, указателями на mbuf) и атомарно обновляет флаг состояния этой ячейки, устанавливая его в значение RTE_GPU_COMM_LIST_READY.30

Роль GPU: На GPU запускается так называемое «постоянное ядро» (persistent kernel) CUDA, которое находится в цикле и непрерывно опрашивает (poll) флаг состояния в своей ячейке comm_list. Такое активное ожидание (busy-wait) на GPU очень эффективно, так как не блокирует вычислительные ресурсы. Как только ядро обнаруживает флаг READY, оно понимает, что в соответствующих адресах памяти GPU находятся новые данные, и приступает к их обработке. После завершения обработки ядро обновляет флаг в DONE, сигнализируя CPU, что данный буфер можно использовать повторно.30

5.4. Анализ асинхронного конвейера для потоковой обработки пакетов

Сочетание плоскости данных на базе GPUDirect RDMA и плоскости управления на базе comm_list позволяет создать полностью асинхронный и конвейеризированный процесс обработки. Этот архитектурный шаблон, описанный в исследованиях NVIDIA, напрямую применим к задаче использования удаленной RAM.30 В этом сценарии «пакеты», получаемые DPDK, — это блоки данных, запрошенные из удаленной RAM с помощью операций RDMA READ, инициированных управляющим потоком на CPU.

Преимущества такого асинхронного конвейерного подхода очевидны:

• Минимизация задержек: Устраняются все промежуточные копии данных и дорогостоящие операции синхронизации между CPU и GPU.
• Максимизация пропускной способности: CPU, GPU и сетевой адаптер работают параллельно, непрерывно передавая данные по конвейеру, что позволяет полностью утилизировать пропускную способность оборудования.

Таким образом, DPDK и его библиотека gpudev предоставляют не просто API, а готовую архитектурную модель для построения высокопроизводительных, явно управляемых систем ввода-вывода для GPU. Эта модель идеально подходит для реализации концепции расширения памяти GPU за счет удаленных ресурсов, обеспечивая необходимый низкоуровневый контроль для достижения максимальной производительности.

Раздел 6: Анализ производительности: количественная оценка компромиссов между задержкой и пропускной способностью

Реализация архитектуры расширения памяти GPU с использованием удаленной RAM требует глубокого понимания компромиссов в производительности. Хотя современные сети обеспечивают огромную пропускную способность, задержка остается фундаментальным вызовом. Успех такой системы зависит не столько от скорости сети, сколько от способности программного обеспечения эффективно скрывать эту задержку. В данном разделе проводится количественный анализ различных уровней памяти, выявляются потенциальные узкие места в системе и обсуждаются стратегии для смягчения влияния задержки на производительность приложений.

6.1. Количественное сравнение уровней памяти

Для принятия обоснованных архитектурных решений необходимо четко представлять иерархию производительности доступных для GPU уровней памяти.

• Локальная память HBM: Обеспечивает пиковую пропускную способность в диапазоне нескольких терабайт в секунду (например, до 8 ТБ/с для HBM3e) при задержках доступа порядка сотен наносекунд.1
• Системная память хоста (DRAM): Доступ через NVLink C2C может обеспечивать пропускную способность до 900 ГБ/с.33 При доступе через стандартную шину PCIe 5.0 x16 пропускная способность ограничена примерно 64 ГБ/с.34 Задержка здесь выше, чем у HBM, и измеряется десятками-сотнями наносекунд.
• Удаленная память (DRAM через RDMA): Пропускная способность определяется скоростью сетевой фабрики. Например, сеть 400 Гбит/с обеспечивает теоретическую пропускную способность 50 ГБ/с, а 800 Гбит/с — 100 ГБ/с, что сопоставимо с PCIe.35 Однако задержка здесь кардинально отличается. Она определяется временем кругового обхода сети (Round-Trip Time, RTT), которое для RDMA обычно составляет несколько микросекунд (например, 2-5 мкс).12

Это сравнение показывает, что хотя удаленная RAM может предложить пропускную способность, сравнимую с локальными интерконнектами, ее задержка как минимум на порядок выше. Этот факт является центральным вызовом при проектировании системы.

Таблица 2: Характеристики производительности локальных и удаленных уровней памяти

6.2. Выявление узких мест в системе за пределами сети

Хотя сетевая задержка является основной проблемой, производительность системы может быть ограничена и другими факторами.

• Пропускная способность PCIe: Даже при использовании GPUDirect RDMA все данные, перемещаемые между сетевым адаптером и GPU, должны пройти через шину PCIe. Если пропускная способность слота PCIe (например, 64 ГБ/с для PCIe 5.0 x16) меньше пропускной способности сети (например, 100 ГБ/с для 800G), шина PCIe станет узким местом.1
• Конкуренция за ресурсы NIC: В многопользовательской среде или при одновременном запуске нескольких приложений, активно использующих сеть, может возникнуть конкуренция за внутренние ресурсы сетевого адаптера, такие как пары очередей (Queue Pairs) или регистры doorbell. Это может привести к снижению производительности и увеличению задержек даже при наличии свободной пропускной способности в сети.37

Накладные расходы программного обеспечения: Эффективность самого программного стека, будь то цикл опроса DPDK или логика обработки в CUDA-ядре, может вносить собственные задержки. Неоптимальный код может помешать приложению полностью насытить аппаратные ресурсы.38

6.3. Влияние на производительность приложений: характеристика рабочих нагрузок

Эффективность использования удаленной памяти сильно зависит от характера рабочей нагрузки.

• Нагрузки, ограниченные пропускной способностью памяти (Memory-Bound): Приложения, которые обрабатывают большие объемы данных последовательно и могут переносить более высокие задержки, получат наибольшую выгоду. Они смогут работать с наборами данных, которые ранее просто не помещались в локальную память GPU.1
• Нагрузки, ограниченные задержкой (Latency-Bound): Приложения с мелкозернистым, случайным доступом к памяти (например, обход графов или работа с разреженными структурами данных) будут сильно страдать от производительности. Высокая стоимость каждой отдельной операции удаленного доступа сделает такую архитектуру неэффективной.39

Ключевым фактором является шаблон доступа к памяти. Большие последовательные передачи данных идеально подходят для амортизации высокой начальной задержки, связанной с удаленным доступом.

6.4. Стратегии сокрытия и смягчения задержек

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

• Предварительная выборка (Prefetching): Это наиболее важная стратегия. Интеллектуальная предварительная загрузка данных из удаленной памяти в локальную память GPU до того, как они понадобятся, может кардинально изменить картину производительности. Исследования показывают, что даже простой программный механизм предварительной выборки способен превратить двукратное замедление от подкачки по требованию в 12% ускорение по сравнению с ручным копированием данных.17
• Совмещение вычислений и коммуникаций: Архитектура приложения должна быть спроектирована таким образом, чтобы перекрывать время ожидания удаленных данных полезными вычислениями. С помощью инструментов, таких как CUDA Streams, можно асинхронно запускать операции передачи данных и вычислительные ядра, позволяя им выполняться параллельно.40
• Увеличение параллелизма: GPU по своей природе являются машинами, скрывающими задержки. Имея огромное количество активных потоков (варпов), планировщик GPU может мгновенно переключиться на выполнение готовых к работе варпов, пока другие ожидают данных из удаленной памяти. Поэтому для эффективного сокрытия сетевой задержки критически важно, чтобы архитектура GPU и программный стек позволяли иметь множество одновременных активных запросов к удаленной памяти на каждое вычислительное ядро.2

Таким образом, достижение высокой пропускной способности при удаленном доступе к памяти — это в основном решенная аппаратная задача (требуется покупка более быстрых сетевых карт). Однако достижение высокой производительности — это программная задача, сосредоточенная на сокрытии задержек. Успех проекта по расширению памяти GPU будет в меньшей степени зависеть от скорости сети (400G против 800G) и в большей — от изощренности среды выполнения, управляющей данными. Эта среда должна понимать шаблоны доступа приложения и проактивно управлять размещением и перемещением данных, чтобы вычислительные конвейеры GPU никогда не простаивали.

Раздел 7: Сравнительный анализ и будущие траектории

После детального рассмотрения архитектур на базе RDMA и DPDK необходимо поместить их в более широкий контекст современных технологий и определить будущие направления развития. В этом заключительном разделе проводится сравнение с набирающим популярность стандартом Compute Express Link (CXL), обобщаются ключевые проблемы и предлагаются рекомендации для системных архитекторов.

7.1. Сравнение подходов на базе RDMA и CXL: семантика ввода-вывода против семантики памяти

Хотя и RDMA, и CXL позволяют расширять память, они представляют собой принципиально разные парадигмы, основанные на разной семантике.

• CXL (Compute Express Link): Это когерентный интерконнект с семантикой памяти. Он работает поверх физического уровня PCIe и фактически расширяет набор инструкций процессора (load/store) для работы с подключенными устройствами. Доступ к памяти, подключенной по CXL, для системы выглядит как доступ к удаленному узлу NUMA (Non-Uniform Memory Access).6 Важнейшей особенностью является то, что данные, полученные из CXL-памяти, могут кэшироваться в иерархии кэшей процессора или GPU, что позволяет использовать пространственную и временную локальность данных.
• RDMA (Remote Direct Memory Access): Это протокол с семантикой ввода-вывода (I/O), основанный на передаче сообщений. Он использует явные команды (verbs), такие как READ, WRITE, SEND, RECEIVE, для инициирования передачи данных. Данные, передаваемые через RDMA, как правило, не попадают в кэши процессора, а записываются напрямую в основную память.42

Сравнение:

CXL предлагает значительно меньшую задержку для мелкозернистого, когерентного доступа к памяти, что делает его идеальным решением для объединения (pooling) и расширения памяти в пределах одной серверной стойки. RDMA, в свою очередь, является более зрелой и масштабируемой технологией для передачи больших объемов данных между узлами в крупномасштабной распределенной системе. В будущем, вероятно, появятся гибридные системы, где CXL будет использоваться для создания фабрики памяти внутри стойки, а RDMA — для связи между стойками.43 Для задачи расширения памяти GPU CXL может предложить более низкую задержку, но RDMA-подходы уже сегодня могут быть реализованы с использованием стандартного сетевого оборудования и фреймворков, таких как DPDK.

7.2. Обобщение ключевых проблем

На основе проведенного анализа можно выделить четыре основные группы проблем, которые необходимо решить при создании систем удаленного расширения памяти GPU.

• Задержка: Фундаментальная и наиболее сложная проблема. Даже самые быстрые сети вносят задержку на уровне микросекунд, что на порядки выше, чем у локальной памяти. Все архитектурные решения должны быть направлены на сокрытие этой задержки.
• Изоляция производительности: В многопользовательской среде необходимо гарантировать, что приложения, совместно использующие удаленный пул памяти, не будут негативно влиять на производительность друг друга (проблема «шумного соседа»).7
• Отказоустойчивость: Выход из строя удаленного узла памяти или сетевого соединения создает новые сценарии отказа, которые отсутствуют в монолитных системах. Архитектура должна предусматривать механизмы для обеспечения надежности (например, репликацию или кодирование с исправлением ошибок).7
• Безопасность: Данные, хранящиеся в удаленной памяти, особенно в облачных средах, уязвимы для несанкционированного доступа. Необходимо обеспечить конфиденциальность и целостность данных при передаче по сети и хранении на удаленных узлах.7

Сложность программного обеспечения: Создание и использование систем с явным управлением удаленной памятью требует значительных усилий от программистов и системных архитекторов.

7.3. Рекомендации для системных архитекторов

На основе обобщенного исследовательского опыта можно сформулировать следующие практические рекомендации:

• Анализ рабочей нагрузки является первостепенным: Выбор архитектуры (прозрачная подкачка или явное управление) и дизайн политики управления данными должны полностью определяться шаблонами доступа к памяти целевых приложений. Универсального решения не существует.
• Совместное проектирование (Co-Design) обязательно: Аппаратная топология (особенно разводка PCIe), сетевая фабрика и программная среда выполнения должны проектироваться как единая, интегрированная система. Оптимизация только одного компонента не даст желаемого результата.

Начинать с модели явного управления: Для приложений, критичных к производительности, наиболее перспективной отправной точкой является модель явного управления (например, на базе DPDK). Она предоставляет необходимый низкоуровневый контроль для реализации сложных техник сокрытия задержек, таких как префетчинг и планирование с учетом данных.

7.4. Перспективы: конвергенция фабрик памяти и программно-аппаратного co-design

В заключение, можно отметить несколько ключевых тенденций, которые будут определять развитие этой области в будущем.

• Стирание границ между сетями и фабриками памяти: С появлением технологий, таких как CXL 3.0, которые позволяют создавать коммутируемые фабрики памяти на уровне стойки, грань между сетевыми и процессорными интерконнектами будет размываться.43 Это приведет к появлению новых, более интегрированных архитектур ЦОД.
• Рост значения программно-аппаратного co-design: Будущее аппаратное обеспечение, вероятно, будет включать больше функций для поддержки эффективного удаленного доступа к памяти (например, аппаратную поддержку предварительной выборки или обработку большого числа одновременных удаленных запросов). В свою очередь, программное обеспечение станет еще более сложным, управляя многоуровневыми, гетерогенными иерархиями памяти.7
• Появление унифицированных сред выполнения: Конечной целью является создание унифицированной среды выполнения для дезагрегированного кластера, которая сможет интеллектуально и динамически размещать как вычисления, так и данные, чтобы максимизировать общую производительность и эффективность использования ресурсов ЦОД.7

Таким образом, идея расширения памяти GPU с использованием удаленной RAM через высокоскоростные сети является не только технически осуществимой, но и соответствует магистральному направлению развития архитектур центров обработки данных. Хотя на этом пути существует множество сложных проблем, прежде всего связанных с задержкой и сложностью программного обеспечения, существующие технологии, такие как RDMA и DPDK, предоставляют мощный инструментарий для их решения.

Источники

1. GPU Memory Bandwidth and Its Impact on Performance — DigitalOcean, дата последнего обращения: сентября 10, 2025, https://www.digitalocean.com/community/tutorials/gpu-memory-bandwidth
2. A Study of Performance Programming of CPU, GPU accelerated Computers and SIMD Architecture — arXiv, дата последнего обращения: сентября 10, 2025, https://arxiv.org/html/2409.10661v1
3. How to Make Unified GPU Memory/Storage Architectures Truly Usable for AI? — Jian Huang, дата последнего обращения: сентября 10, 2025, https://jianh.web.engr.illinois.edu/g10.html
4. GPUDirect Storage: A Direct Path Between Storage and GPU Memory — NVIDIA Developer, дата последнего обращения: сентября 10, 2025, https://developer.nvidia.com/blog/gpudirect-storage/
5. Shared Virtual Memory: Its Design and Performance Implications for Diverse Applications, дата последнего обращения: сентября 10, 2025, https://arxiv.org/html/2405.06811v1
6. Synergizing CXL with Unified Memory for Scalable GPU Memory Expansion — ResearchGate, дата последнего обращения: сентября 10, 2025, https://www.researchgate.net/publication/379095770_Synergizing_CXL_with_Unified_Memory_for_Scalable_GPU_Memory_Expansion
7. [2305.03943] Memory Disaggregation: Advances and Open …, дата последнего обращения: сентября 10, 2025, https://ar5iv.labs.arxiv.org/html/2305.03943
8. GPU-Disaggregated Serving for Deep Learning … — USENIX, дата последнего обращения: сентября 10, 2025, https://www.usenix.org/system/files/nsdi25-yang.pdf
9. Survey of Disaggregated Memory: Cross-layer Technique Insights for Next-Generation Datacenters — arXiv, дата последнего обращения: сентября 10, 2025, https://arxiv.org/html/2503.20275v1
10. SC21 Panel: Resource Disaggregation in High Performance Computing — YouTube, дата последнего обращения: сентября 10, 2025, https://www.youtube.com/watch?v=ejgFLSspXc8
11. Network Requirements for Resource Disaggregation — USENIX, дата последнего обращения: сентября 10, 2025, https://www.usenix.org/system/files/conference/osdi16/osdi16-gao.pdf
12. The Case for Distributed Shared-Memory Databases with RDMA-Enabled Memory Disaggregation — VLDB Endowment, дата последнего обращения: сентября 10, 2025, https://www.vldb.org/pvldb/vol16/p15-wang.pdf
13. GPU-Assisted Memory Expansion, дата последнего обращения: сентября 10, 2025, https://par.nsf.gov/servlets/purl/10328748
14. Efficient Use of GPU Memory for Large-Scale Deep Learning Model Training — MDPI, дата последнего обращения: сентября 10, 2025, https://www.mdpi.com/2076-3417/11/21/10377
15. Pushing GPU Memory Boundaries with the Integration of CXL Technologies — arXiv, дата последнего обращения: сентября 10, 2025, https://arxiv.org/html/2506.15601v1
16. Note: Virtual Memory System in Multi-GPUs architecture | by ztex, Tony, Liu | Medium, дата последнего обращения: сентября 10, 2025, https://ztex.medium.com/virtual-memory-system-in-multi-gpus-architecture-384ef0cb1763
17. Towards High Performance Paged Memory for GPUs — UT Computer Science, дата последнего обращения: сентября 10, 2025, https://www.cs.utexas.edu/~skeckler/pubs/HPCA_2016_Paged_Memory.pdf
18. Towards high performance paged memory for GPUs | Request PDF — ResearchGate, дата последнего обращения: сентября 10, 2025, https://www.researchgate.net/publication/299642825_Towards_high_performance_paged_memory_for_GPUs
19. RDMA Technologies Power High-Speed Memory Access — ALLPCB, дата последнего обращения: сентября 10, 2025, https://www.allpcb.com/allelectrohub/rdma-technologies-power-highspeed-memory-access
20. Testing RDMA to GPU communication on fabric : r/homelab — Reddit, дата последнего обращения: сентября 10, 2025, https://www.reddit.com/r/homelab/comments/1j5scbz/testing_rdma_to_gpu_communication_on_fabric/
21. # The Evolution of Memory Architecture: The Synergistic Development of CXL and RDMA | Glasp, дата последнего обращения: сентября 10, 2025, https://glasp.co/hatch/lonelygo/p/a6ej84t7gudqjGsPkwv5
22. The Evolution and Implementation of GPUDirect RDMA | by DatenLord — Medium, дата последнего обращения: сентября 10, 2025, https://medium.com/@datenlord/the-evolution-and-implementation-of-gpudirect-rdma-19751f7b9413
23. 1. Overview — GPUDirect RDMA 13.0 documentation, дата последнего обращения: сентября 10, 2025, https://docs.nvidia.com/cuda/gpudirect-rdma/
24. Optimizing Data Movement for GPU-Based In-Situ Workflow Using GPUDirect RDMA — OSTI, дата последнего обращения: сентября 10, 2025, https://www.osti.gov/servlets/purl/2000374
25. GPUDirect Benchmarking — HPC-Works — Confluence, дата последнего обращения: сентября 10, 2025, https://hpcadvisorycouncil.atlassian.net/wiki/spaces/HPCWORKS/pages/2791440385/GPUDirect+Benchmarking
26. Benchmark NVIDIA GPUDirect RDMA with InfiniBand Write Bandwidth — Oracle Help Center, дата последнего обращения: сентября 10, 2025, https://docs.oracle.com/en/learn/gpudirect-rdma-ib-write-bw/
27. GPUDirect Storage Benchmarking and Configuration Guide — NVIDIA Documentation, дата последнего обращения: сентября 10, 2025, https://docs.nvidia.com/gpudirect-storage/configuration-guide/index.html
28. Introducing Low-Level GPU Virtual Memory Management | NVIDIA Technical Blog, дата последнего обращения: сентября 10, 2025, https://developer.nvidia.com/blog/introducing-low-level-gpu-virtual-memory-management/
29. GPU-SM: Shared Memory Multi-GPU Programming — IMPACT, дата последнего обращения: сентября 10, 2025, http://impact.crhc.illinois.edu/shared/Papers/gpusm_gpgpu8.pdf
30. Boosting Inline Packet Processing Using DPDK and GPUdev with …, дата последнего обращения: сентября 10, 2025, https://developer.nvidia.com/blog/optimizing-inline-packet-processing-using-dpdk-and-gpudev-with-gpus/
31. Implementing and Comparing Static and Machine-Learning Scheduling Approaches using DPDK on an Integrated CPU/GPU — DiVA portal, дата последнего обращения: сентября 10, 2025, http://www.diva-portal.org/smash/get/diva2:1373336/FULLTEXT01.pdf
32. 11. General-Purpose Graphics Processing Unit (GPU) Library — Documentation, дата последнего обращения: сентября 10, 2025, https://doc.dpdk.org/guides-25.07/prog_guide/gpudev.html
33. Towards Memory Disaggregation via NVLink C2C: Benchmarking CPU-Requested GPU Memory Access | Request PDF — ResearchGate, дата последнего обращения: сентября 10, 2025, https://www.researchgate.net/publication/392803359_Towards_Memory_Disaggregation_via_NVLink_C2C_Benchmarking_CPU-Requested_GPU_Memory_Access
34. CXL: Slot RAM into your PCIE slot, great for running Deepseek on your CPU — Reddit, дата последнего обращения: сентября 10, 2025, https://www.reddit.com/r/LocalLLaMA/comments/1jm36yg/cxl_slot_ram_into_your_pcie_slot_great_for/
35. Networking and GPU machines | Compute Engine Documentation — Google Cloud, дата последнего обращения: сентября 10, 2025, https://cloud.google.com/compute/docs/gpus/gpu-network-bandwidth
36. Characterizing Network Requirements for GPU API Remoting in AI Applications — arXiv, дата последнего обращения: сентября 10, 2025, https://arxiv.org/html/2401.13354v1
37. Scaling Up Memory Disaggregated Applications with Smart — MADSys, дата последнего обращения: сентября 10, 2025, https://madsys.cs.tsinghua.edu.cn/publication/scaling-up-memory-disaggregated-applications-with-smart/ASPLOS24-ren.pdf
38. Performance Analysis of Distributed GPU-Accelerated Task-Based Workflows — OpenProceedings.org, дата последнего обращения: сентября 10, 2025, https://openproceedings.org/2024/conf/edbt/paper-161.pdf
39. Page Placement Strategies for GPUs within Heterogeneous Memory Systems, дата последнего обращения: сентября 10, 2025, https://courses.grainger.illinois.edu/ece598ms/fa2019/papers/paper234.pdf
40. Disaggregated Design for GPU-Based Volumetric Data Structures — arXiv, дата последнего обращения: сентября 10, 2025, https://arxiv.org/html/2503.07898v1
41. A Comprehensive Simulation Framework for CXL Disaggregated Memory — arXiv, дата последнего обращения: сентября 10, 2025, https://arxiv.org/html/2411.02282v1
42. Exploring and Evaluating Real-world CXL: Use Cases and System Adoption — arXiv, дата последнего обращения: сентября 10, 2025, https://arxiv.org/html/2405.14209v1
43. CXL Switch vs RDMA: A Technical Comparison for High-Performance Interconnects | by Anand Mirji | Medium, дата последнего обращения: сентября 10, 2025, https://medium.com/@anan.mirji/cxl-switch-vs-rdma-a-technical-comparison-for-high-performance-interconnects-6aaa031cde31

An Examination of CXL Memory Use Cases for In-Memory Database Management Systems using SAP HANA — VLDB Endowment, дата последнего обращения: сентября 10, 2025, https://www.vldb.org/pvldb/vol17/p3827-ahn.pdf

Андрей Гантимуров
andrey_gantimurov@baum.ru