Проблема: «Невидимые» потери производительности
В блоге NVIDIA Developer опубликован отчет о проверке инфраструктуры по стандарту NVIDIA Exemplar Cloud. Ключевой вывод: два кластера на одинаковом оборудовании (H100, GB200 NVL72, GB300 NVL72) могут показывать разницу в пропускной способности обучения на 8–12%. Главная причина — не дефекты железа, а кумулятивный эффект ошибок конфигурации на уровнях ядра, гипервизора, BIOS и библиотеки NCCL. Эти микроскопические потери суммируются, и кластер не проходит валидацию, требующую достижения 95% от референсной архитектуры (RA).
Кейс 1: GB200 NVL72 и виртуализация (потеря 12–14%)
При обучении модели DeepSeek-V3 (MoE, FP8) в виртуальной машине время итерации было на 12–14% выше, чем на bare-metal. Анализ через perf показал, что 24% циклов CPU тратились на функцию arm_smmu_cmdq_issue_cmdlist. Это означает, что гостевая ОС постоянно прерывала хост для инвалидации таблиц страниц через единую очередь команд SMMU, создавая узкое место.
Решение: Включение поддержки CMDQV/VCMDQ (Command Queue Virtualization) в ядре хоста и передача этой возможности гостю. После настройки задержка исчезла, а производительность MoE-моделей вернулась к уровню bare-metal.
Кейс 2: H100 и проблемы с NUMA/питанием (потеря 12%)
В кластере H100 SXM5 обучение Llama 3 70B шло медленнее референса на 12%. Проблема оказалась не в ядре, а в управлении питанием и привязке процессов. Ядра CPU работали ниже ожидаемой турбо-частоты из-за неправильных настроек C-states, а потоки обучения были привязаны к ядрам, не соответствующим топологии NUMA GPU. Это создавало задержки при доступе к памяти.
Кейс 3 и 4: NCCL и скрытые дефекты
Два других кейса выявили проблемы с конкурентностью очередей NCCL на высокоскоростных сетях ConnectX-8 (1.6 Tbps) и отсутствие файлов топологии внутри контейнеров. В последнем случае AllGather/ReduceScatter операции замедлялись «тихо», так как контейнер не видел реальной физической топологии сети.
Сводная таблица проблем и решений
| Компонент | Симптом / Метрика | Причина | Решение |
|---|---|---|---|
| GB200 NVL72 (VM) | Потеря 12-14% производительности MoE | Конкуренция в очереди SMMU (arm_smmu_cmdq_issue_cmdlist) |
Включить CMDQV/VCMDQ в ядре хоста и передать гостю |
| H100 Cluster | Потеря 12% производительности | Низкая турбо-частота CPU, неверная привязка к NUMA | Оптимизация C-states и привязки процессов (process binding) |
| ConnectX-8 | Низкая пропускная способность коллективных операций | Недостаточная конкурентность очередей NCCL | Настройка NCCL_ALGO и параметров очередей под ширину канала |
| Контейнеры | Скрытое замедление AllGather/ReduceScatter | Отсутствие файлов топологии NCCL внутри контейнера | Монтирование топологических файлов и переменных окружения |
Почему это важно
Для инженеров инфраструктуры это сигнал: простое наличие GPU H100/GB200 не гарантирует пиковой производительности. Необходимо проводить аудит стека: проверять perf на наличие спинлоков SMMU, настраивать BIOS для максимальных турбо-частот в рамках NUMA-узлов и гарантировать, что контейнеры с NCCL видят полную физическую топологию сети и памяти.
Источник: NVIDIA dev blog ↗