NVIDIA Grace Hopper: CPU-GPU unified memory, как это меняет LLM serving?

Краткий тезис

Hopper|NVIDIA Hopper|Grace Hopper (GH200) объединяет CPU Grace и GPU H100 через высокоскоростной интерконнект NVLink-C2C (900 ГБ/с), создавая единое адресное пространство до 1.2 ТБ. Для LLM serving это означает, что KV cache может размещаться в дешёвой CPU-памяти с почти такой же скоростью доступа, как в GPU HBM, что позволяет обслуживать модели с контекстом в миллионы токенов на одном узле без распределённых систем и swapping. Это кардинально упрощает инфраструктуру, снижает latency и открывает путь к truly long-context RAG|agentic RAG.

1. Термины: Grace Hopper, unified memory, NVLink-C2C, LLM serving, KV cache

Grace Hopper — суперчип NVIDIA, объединяющий процессор Grace (ARM Neoverse V2) и ускоритель H100 (Hopper) в одном пакете. memory|Unified memory — технология, при которой CPU и GPU разделяют единое виртуальное адресное пространство; данные не нужно явно копировать между устройствами. NVLink-C2C — чип-к-чипу интерконнект с пропускной способностью 900 ГБ/с (в 7 раз быстрее PCIe 5.0 x16). LLM serving — процесс развёртывания и обслуживания запросов к большой языковой модели в реальном времени. KV cache — кэш ключей и значений внимания, который растёт линейно с длиной контекста и является основным потребителем памяти при генерации.

2. Традиционная архитектура CPU-GPU: узкое место PCIe

В классических серверах (x86 + GPU через PCIe) CPU и GPU имеют отдельные физические памяти: CPU DRAM (DDR5) и GPU HBM (High Bandwidth Memory). Для передачи данных между ними используется шина PCIe (типично 32–64 ГБ/с). Это создаёт несколько проблем:

• Копирование данных: каждый шаг генерации требует копирования KV cache из GPU в CPU (если нужно освободить HBM) — latency ~10–50 мкс.
• Ограниченный HBM: H100 имеет 80 ГБ HBM3 — этого хватает для модели 70B (4-bit quant) + KV cache на ~32K токенов. Для контекста >100K токенов приходится использовать offloading (сброс KV cache в CPU DRAM через PCIe), что резко замедляет serving.
• Swapping: при превышении HBM модель или кэш выгружаются на диск — latency возрастает до секунд.

3. Архитектура Grace Hopper: unified memory и NVLink-C2C

GH200 решает эти проблемы на аппаратном уровне:

• Единое адресное пространство: CPU и GPU видят одну и ту же память. Программист может выделить буфер, и он будет доступен обоим устройствам без явного cudaMemcpy.
• NVLink-C2C: 900 ГБ/с — почти в 7 раз быстрее PCIe 5.0. Это позволяет CPU и GPU обмениваться данными с latency ~1–2 мкс.
• Большой объём: до 480 ГБ LPDDR5X на CPU (Grace) + 80 ГБ HBM3 на GPU = до 560 ГБ unified memory. В версии Superchip (два GH200) — до 1.2 ТБ.

Ключевое отличие: CPU DRAM становится почти такой же быстрой, как GPU HBM, если данные передаются через NVLink-C2C. Это меняет иерархию памяти: HBM — L1/L2 кэш, CPU DRAM — L3 кэш, а не медленный "дальний" storage.

4. Как это меняет LLM serving

4.1 KV cache в CPU-памяти

Теперь KV cache можно разместить в LPDDR5X (CPU), а модель — в HBM. При генерации каждый шаг требует доступа к KV cache для вычисления внимания. На GH200 этот доступ происходит через NVLink-C2C с latency ~1–2 мкс, что лишь незначительно медленнее, чем из HBM (0.5–1 мкс). В сравнении с PCIe (10–50 мкс) — выигрыш в 5–10 раз.

4.2 Long context без распределённых систем

Модель 70B в 4-bit занимает ~35 ГБ HBM. Остаётся ~45 ГБ HBM для KV cache. При контексте 1M токенов KV cache занимает ~200 ГБ (для 70B, FP16). На GH200 эти 200 ГБ можно разместить в CPU-памяти (доступно 480 ГБ). Таким образом, один GH200 может обслуживать модель 70B с контекстом 1M токенов без offloading и без распределения на несколько GPU.

4.3 Упрощение инфраструктуры

• Не нужно собирать кластер из 4–8 GPU для long context.
• Нет необходимости в сложных стратегиях pipeline parallelism и tensor parallelism для размещения KV cache.
• Снижается latency: нет межузловых коммуникаций (NVLink внутри чипа быстрее, чем InfiniBand между узлами).
• Упрощается batching: можно объединять запросы с разной длиной контекста, не боясь нехватки HBM.

4.4 Пример: serving с vLLM на GH200

# vLLM поддерживает unified memory через переменные окружения
import os
os.environ["VLLM_USE_UNIFIED_MEMORY"] = "1"  # включить unified memory

from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    tensor_parallel_size=1,  # один GPU
    max_model_len=1_000_000,  # 1M токенов
    gpu_memory_utilization=0.5,  # оставить место для KV cache в HBM
)

# KV cache будет автоматически размещён в CPU-памяти при превышении HBM
sampling_params = SamplingParams(max_tokens=100)
output = llm.generate("Расскажи о квантовых вычислениях", sampling_params)

5. Влияние на agentic RAG

Agentic RAG — системы, где агент (LLM) многократно обращается к внешним инструментам (retrieval, код, API) и накапливает контекст. Ключевые требования:

• Долгий контекст: агент может сделать 10–20 шагов, каждый добавляет ~2K токенов (результат retrieval, код, ответ). Итоговый контекст — 50–100K+ токенов.
• Быстрый retrieval: агент вызывает поиск, результаты нужно быстро добавить в KV cache.
• Память: агент может хранить историю диалога и извлечённые документы.

GH200 позволяет:

• Держать весь контекст агента (включая историю и результаты retrieval) в unified memory без сброса.
• Выполнять retrieval (CPU) и генерацию (GPU) параллельно, обмениваясь данными через NVLink-C2C.
• Использовать CPU-память как долговременную память агента, а HBM — как рабочую область для текущего шага.

6. Сравнительная таблица: традиционная архитектура vs Grace Hopper

7. Ограничения и нюансы

• Цена и доступность: GH200 дороже обычного H100 сервера, и пока не все облачные провайдеры предлагают его.
• Программная поддержка: не все фреймворки (vLLM, TensorRT-LLM) полностью оптимизированы под unified memory. Требуется явная настройка (например, VLLM_USE_UNIFIED_MEMORY=1).
• ARM-архитектура: Grace — ARM, а не x86. Некоторые библиотеки (например, для retrieval) могут требовать перекомпиляции.
• Тепловыделение: 700 Вт TDP на один суперчип — нужно эффективное охлаждение.
• Не панацея: для моделей >300B параметров всё равно потребуется несколько GH200, но с unified memory можно использовать NVLink-C2C между чипами (NVLink Switch).

8. Пет-проект для закрепления

Задача: Развернуть LLM serving с long context (1M токенов) на GH200 и сравнить latency с традиционным сервером (H100 + PCIe).

Инструменты:

• NVIDIA GH200 (можно арендовать в Lambda Labs или Azure ND H100 v5 с поддержкой Grace Hopper).
• vLLM (последняя версия с unified memory).
• Бенчмарк: vllm.entrypoints.openai.api_server + locust для нагрузки.

Шаги:

1. Установить vLLM на GH200: pip install vllm.
2. Запустить сервер с --max-model-len 1000000 и --gpu-memory-utilization 0.5.
3. Отправить запрос с длинным контекстом (например, загрузить документ на 500K токенов и задать вопрос).
4. Измерить time-to-first-token (TTFT) и throughput (токенов/с).
5. Повторить на обычном H100 с PCIe (без unified memory) — при контексте >32K токенов будет offloading.
6. Сравнить результаты.

Ожидаемый результат: На GH200 TTFT для контекста 500K токенов будет ~2–3 с, на H100 с PCIe — >10 с (из-за offloading). Throughput на GH200 будет в 3–5 раз выше.

9. Связь с другими вопросами

10. Навигация

• Предыдущий: 708
• Следующий: 710
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 708
• Следующий: 710
• Индекс: 00. Индекс разборов