Бенчмаркинг LLM на AMD MI300X vs H100: различия в архитектуре и оптимизации?
Краткий тезис
Сравнение MI300X|AMD MI300X и NVIDIA H100 для LLM — это выбор между большим объёмом памяти (192 ГБ HBM3 у MI300X) и высокой вычислительной плотностью (Tensor Cores, Transformer Engine у H100). MI300X выигрывает в задачах с длинным контекстом и крупными батчами, где узким местом становится пропускная способность памяти. H100 остаётся лидером для compute-heavy операций (attention, GEMM) и имеет более зрелую программную экосистему (CUDA, NCCL, TensorRT). Оптимизации под каждую архитектуру (FlashAttention, kernel fusion, коммуникационные библиотеки) критически влияют на реальную производительность.
1. Архитектура AMD MI300X (CDNA3)
MI300X — это ускоритель на архитектуре CDNA3, построенный по чиплетной технологии. Он состоит из нескольких кристаллов (чиплетов), соединённых через Infinity Fabric.
- Чиплеты: 8 вычислительных кристаллов (XCD) с 40 вычислительными блоками (CU) каждый, итого 304 CU (активных). Каждый CU содержит 64 потоковых процессора (SP) — всего около 19 456 SP.
- Память: 192 ГБ HBM3 с пропускной способностью 5,2 ТБ/с. Это в 2,4 раза больше объёма, чем у H100, и на 55% выше пропускная способность.
- Вычислительная мощность: 1307 TFLOPS FP16 (с накоплением в FP32), 2614 TFLOPS FP16 (с накоплением в FP16). Для сравнения: 653 TFLOPS FP32, 326 TFLOPS FP64.
- Программная модель: ROCm (Radeon Open Compute) — открытый стек, включающий компилятор HIP, библиотеки rocBLAS, MIOpen, RCCL. Поддерживает PyTorch, TensorFlow, JAX через адаптеры.
Ключевая особенность — большой объём памяти позволяет загружать модели с сотнями миллиардов параметров (например, Llama 3 405B) целиком, без необходимости тензорного параллелизма для размещения весов.
2. Архитектура NVIDIA H100 (Hopper)
H100 построен на архитектуре Hopper и является монолитным кристаллом (один чип).
- SM (Streaming Multiprocessors): 132 SM, каждый содержит 128 ядер CUDA и 4 Tensor Core четвёртого поколения.
- Tensor Cores: поддерживают форматы FP8, FP16, BF16, TF32, INT8. Специализированные блоки для матричных умножений, критически важных для LLM.
- Transformer Engine: аппаратный блок, автоматически выбирающий точность (FP8/FP16) для каждого слоя трансформера, ускоряя обучение и инференс.
- Память: 80 ГБ HBM3 с пропускной способностью 3,35 ТБ/с. Также доступна версия H100 NVL с 188 ГБ (два GPU через NVLink).
- Вычислительная мощность: 1979 TFLOPS FP16 (с накоплением в FP32), 3958 TFLOPS FP8 (sparse).
- Программная модель: CUDA — зрелая экосистема с библиотеками cuBLAS, cuDNN, NCCL, TensorRT, Triton Inference Server. Широкая поддержка фреймворков.
Ключевая особенность — Tensor Cores и Transformer Engine дают огромное преимущество в операциях attention и feed-forward, особенно при малых и средних батчах.
3. Сравнение характеристик
| Параметр | AMD MI300X | NVIDIA H100 |
|---|---|---|
| Архитектура | CDNA3 (чиплеты) | Hopper (монолит) |
| Память (HBM3) | 192 ГБ | 80 ГБ |
| Пропускная способность памяти | 5,2 ТБ/с | 3,35 ТБ/с |
| FP16 TFLOPS (dense) | 1307 | 1979 |
| FP8 TFLOPS (dense) | 2614 | 3958 |
| Tensor Cores | Нет (матричные операции на SP) | Есть (4-го поколения) |
| Трансформер-движок | Нет | Есть |
| Межсоединение | Infinity Fabric (4-я гениция, 896 ГБ/с на GPU) | NVLink 4 (900 ГБ/с на GPU) |
| Программный стек | ROCm (HIP, RCCL, MIOpen) | CUDA (NCCL, cuBLAS, TensorRT) |
| Поддержка FP8 | Да (через ROCm) | Да (нативная) |
| TDP | 750 Вт | 700 Вт |
| Цена (ориентир) | ~$15 000 (зависит от OEM) | ~$30 000 |
4. Влияние на инференс LLM
4.1. Пропускная способность памяти vs вычислительная мощность
Инференс LLM (особенно авторегрессивная генерация) часто упирается в пропускную способность памяти (memory-bound), а не в вычисления (compute-bound). Причина: каждый шаг генерации требует загрузки весов модели из HBM в регистры, а вычисления (одно матричное умножение) относительно малы.
- MI300X с 5,2 ТБ/с памяти даёт более высокую скорость загрузки весов → выше throughput (токенов/с) при больших батчах.
- H100 с 3,35 ТБ/с уступает по пропускной способности, но Tensor Cores ускоряют сами вычисления, что даёт преимущество при малых батчах (batch size = 1), где latency важнее throughput.
4.2. Длинный контекст
Для long context (например, 128K токенов) ключевой ресурс — объём памяти для хранения KV-кэша. MI300X с 192 ГБ позволяет обслуживать больше параллельных запросов с длинным контекстом без выгрузки на CPU. H100 с 80 ГБ быстрее заполняется, требуя либо меньший batch size, либо использование FlashAttention (экономит память, но не увеличивает объём).
4.3. Батч-обработка
- Small batch (1–4): H100 быстрее за счёт Tensor Cores и меньшей задержки на коммуникации.
- Large batch (32–128): MI300X догоняет и может обогнать H100 благодаря большей пропускной способности памяти, так как вычисления становятся менее доминирующими.
5. Влияние на обучение LLM
5.1. Распределённое обучение
Обучение больших моделей требует тензорного параллелизма (разбиение слоёв между GPU) и конвейерного параллелизма (разбиение слоёв по стадиям). Здесь важны:
- Коммуникационная пропускная способность: NVLink 4 (900 ГБ/с) у H100 vs Infinity Fabric (896 ГБ/с) у MI300X — примерно одинаково.
- Программная поддержка: NCCL (NVIDIA Collective Communications Library) оптимизирована для H100 и широко используется в Megatron-LM, DeepSpeed. RCCL (AMD) — аналог, но с меньшим сообществом и иногда менее зрелыми оптимизациями.
- Параллелизм данных: H100 с Tensor Cores быстрее обрабатывает микро-батчи, что даёт преимущество в throughput при обучении.
5.2. Поддержка FP8
Обе архитектуры поддерживают FP8 (8-битные числа с плавающей точкой), что ускоряет обучение и инференс. Однако H100 имеет аппаратный Transformer Engine, который автоматически выбирает точность для каждого слоя, снижая потери качества. На MI300X FP8 реализован через программные библиотеки (ROCm), что может давать меньший прирост скорости.
6. Программный стек и оптимизации
6.1. CUDA vs ROCm
CUDA — де-факто стандарт для ML. Большинство библиотек (vLLM, TensorRT-LLM, Hugging Face Accelerate) изначально оптимизированы под NVIDIA. ROCm — открытая альтернатива, совместимая с HIP (аналог CUDA). Однако:
- Не все фичи CUDA перенесены в ROCm (например, некоторые kernel fusion).
- Производительность ROCm-библиотек (rocBLAS, MIOpen) может отставать от cuBLAS/cuDNN на 10–30% в некоторых операциях.
- Инструменты профилирования (Nsight vs ROCProfiler) менее развиты.
6.2. Оптимизации для MI300X
- FlashAttention: портирован под ROCm, но может требовать дополнительной настройки.
- Kernel fusion: объединение операций (например, attention + softmax) для уменьшения обращений к памяти. На MI300X это особенно важно из-за отсутствия Tensor Cores.
- Использование Infinity Fabric: для multi-GPU конфигураций нужно явно указывать топологию (например, через
ROCR_VISIBLE_DEVICES).
6.3. Оптимизации для H100
- TensorRT-LLM: фреймворк для инференса, использующий Tensor Cores и FP8. Даёт прирост до 2x по сравнению с PyTorch.
- FlashAttention-2: нативная поддержка через CUDA, работает «из коробки».
- NCCL с NVLink: автоматическая оптимизация коммуникаций для распределённого обучения.
7. Бенчмарки и реальные результаты
7.1. MLPerf Inference
В раунде MLPerf 3.1 (2024) H100 показал лучшие результаты в инференсе LLM (GPT-J, BERT-Large) по latency и throughput. MI300X участвовал в категории «Offline» (большие батчи) и показал конкурентоспособные цифры, но уступил H100 в «Server» (малые батчи).
7.2. Независимые тесты
- AMD: заявляет, что MI300X превосходит H100 в инференсе Llama 2 70B при batch size 32+ (на 20–30% выше throughput).
- NVIDIA: контраргумент — при batch size 1 H100 быстрее на 40–50% из-за Tensor Cores.
- Реальные сценарии: для RAG-систем с длинным контекстом (например, обработка 100K токенов) MI300X позволяет обслуживать больше одновременных запросов без OOM.
7.3. Пример кода для замера (PyTorch)
import torch
import time
# Предположим, модель загружена на GPU (device = 'cuda' или 'hip')
model = ... # Llama-2-7B
input_ids = torch.randint(0, 32000, (1, 512)).to(device)
# Warmup
for _ in range(10):
_ = model.generate(input_ids, max_new_tokens=1)
# Замер latency
start = time.time()
for _ in range(100):
_ = model.generate(input_ids, max_new_tokens=1)
latency = (time.time() - start) / 100
print(f"Latency per token: {latency*1000:.2f} ms")
# Замер throughput (batch size = 32)
batch = torch.randint(0, 32000, (32, 512)).to(device)
start = time.time()
_ = model.generate(batch, max_new_tokens=128)
throughput = 32 * 128 / (time.time() - start)
print(f"Throughput: {throughput:.2f} tokens/s")
На MI300X нужно использовать device='hip' и убедиться, что установлен ROCm-совместимый PyTorch.
8. Выводы и рекомендации
| Сценарий | Рекомендуемая архитектура | Причина |
|---|---|---|
| Инференс с малым батчем (1–4) | H100 | Tensor Cores, низкая latency |
| Инференс с большим батчем (32+) | MI300X | Больше памяти, выше пропускная способность |
| Длинный контекст (128K+) | MI300X | 192 ГБ позволяют держать KV-кэш |
| Обучение больших моделей (70B+) | H100 (или H100 NVL) | Зрелый софт, Tensor Cores, FP8 Transformer Engine |
| Бюджетное решение | MI300X | Ниже цена за гигабайт памяти |
| Экосистема и поддержка | H100 | CUDA, TensorRT, широкая совместимость |
Ключевой вывод: MI300X — сильный конкурент в задачах, где память является узким местом (long context, large batch). H100 остаётся лучшим выбором для compute-heavy сценариев и production-систем, где важна стабильность и зрелость софта.
Пет-проект для закрепления
Задача: Сравнить производительность инференса Llama 2 7B на AMD MI300X и NVIDIA H100 (или симуляция на CPU с эмуляцией характеристик).
Инструменты:
- PyTorch с поддержкой ROCm (для MI300X) и CUDA (для H100).
- Библиотеки: transformers, accelerate, flash-attn (если доступны).
- Профилировщики: PyTorch Profiler, ROCProfiler, Nsight Systems.
Шаги:
- Развернуть инференс-скрипт на обеих платформах (или использовать облачные инстансы: AWS p5 (H100) и AMD Instinct (MI300X через AMD Cloud)).
- Замерить latency (ms/token) при batch size = 1, 4, 16, 32.
- Замерить throughput (tokens/s) при batch size = 32, 64, 128.
- Повторить для разной длины контекста (512, 4096, 16384 токенов).
- Построить графики зависимости latency/throughput от batch size и длины контекста.
- Сравнить с теоретическими ожиданиями (пропускная способность памяти vs compute).
Ожидаемый результат: Таблица и графики, демонстрирующие, при каких условиях каждая архитектура выигрывает. Вывод о том, какую платформу выбрать для конкретного RAG-приложения.
Связь с другими вопросами
| Вопрос | Тема |
|---|---|
| 705 | Оптимизация инференса LLM (batch size, quantization) |
| 706 | Распределённое обучение и параллелизм |
| 708 | Выбор оборудования для RAG-системы |
| 712 | Сравнение GPU для обучения больших моделей |
| 715 | Профилирование и бенчмаркинг LLM |
| 720 | Энергопотребление и стоимость владения (TCO) |
Навигация
- Предыдущий: 709
- Следующий: 711
- Индекс: 00. Индекс разборов