Представьте ситуацию: вы развернули два идентичных кластера на базе новейших систем NVIDIA H100, GB200 NVL72 или GB300 NVL72. Аппаратное обеспечение, сетевая инфраструктура и даже версии ПО совпадают. Однако один кластер показывает эталонную скорость обучения моделей, а второй заметно отстает. В индустрии искусственного интеллекта такие расхождения кажутся неприемлемыми, особенно когда речь идет о многомиллионных инвестициях в вычислительные мощности. Оказывается, причина кроется не в «железе», а в тонкой настройке стека: от уровня ядра Linux и гипервизора до BIOS и библиотеки NVIDIA Collective Communications Library (NCCL). Именно эти скрытые конфигурационные разрывы часто не позволяют развертываниям достичь порога в 95% эффективности, требуемого для сертификации NVIDIA Exemplar Cloud.
Эта статья — не просто пересказ новости, а глубокое техническое руководство, основанное на реальных расследованиях инженеров NVIDIA. Мы подробно разберем четыре кейса из практики, где были выявлены и устранены критические узкие места. Вы узнаете, как ошибки в настройке SMMU на процессорах NVIDIA Grace, неправильное управление питанием CPU, недостаточная конкурентность очередей NCCL и «тихие» ошибки монтирования файлов топологии внутри контейнеров могут сводить на нет мощность самых передовых GPU. Если вы инженер инфраструктуры, архитектор производительности или DevOps-специалист, работающий с крупными языковыми моделями (LLM), этот материал поможет вам провести аудит собственного кластера до начала масштабных тренировок моделей.
01Почему идентичное железо дает разную производительность?
Часто возникает заблуждение, что производительность AI-кластера определяется исключительно мощностью GPU. Однако современные системы, такие как GB200 NVL72 или GB300 NVL72, представляют собой сложные гетерогенные системы, где CPU, память, сеть и GPU работают в тесной синхронизации. Разрыв в производительности между партнерскими развертываниями и эталонной архитектурой NVIDIA (Reference Architecture, RA) редко вызван одной фатальной ошибкой. Чаще всего это «эффект домино» из множества мелких конфигурационных решений.
Каждый уровень стека — ядро, гипервизор, BIOS, NCCL — может «стоить» вам несколько процентов производительности. В сумме эти потери складываются в значительное отставание, из-за которого кластер не проходит валидацию Exemplar Cloud. Например, отсутствие поддержки определенных возможностей SMMU (System Memory Management Unit) или неправильная привязка процессов к NUMA-узлам могут привести к тому, что GPU простаивает, ожидая данные от CPU, или что сетевые коллективные операции (AllGather, ReduceScatter) занимают заметно больше времени, чем необходимо.
В следующих разделах мы детально разберем четыре конкретных случая, которые NVIDIA выявила при работе с партнерами. Каждый кейс изолирует определенный слой стека и показывает, какие инструменты профилирования (perf, Nsight Systems, nccl-tests) помогли найти корень проблемы и какие именно изменения закрыли разрыв в производительности.
02Кейс 1: GB200 NVL72 в виртуальной машине — заметная потеря производительности из-за SMMU
Первый кейс касается развертывания на базе NVIDIA GB200 NVL72, где модель DeepSeek-V3 (Mixture-of-Experts, MoE) в формате FP8 обучалась внутри виртуальной машины (VM). Результаты показали, что время одной итерации обучения было заметно дольше, чем на «голом железе» (bare metal). При этом для плотных моделей, таких как Llama 3 70B, отставание было менее выраженным. Почему MoE-модели оказались в зоне риска?
MoE-архитектуры генерируют множество мелких ядер выполнения (kernels) за одну итерацию. Это создает высокую нагрузку на подсистему управления памятью. Инженеры NVIDIA использовали профилировщик Nsight Systems и команду perf record -a -g для захвата трассировки хоста. Анализ через perf report выявил неожиданную картину: значительная часть циклов процессора тратилась на функцию arm_smmu_cmdq_issue_cmdlist.
Эта функция отвечает за отправку команд инвалидации в очередь команд Arm SMMU. В условиях виртуализации каждая операция маппинга/размаппинга памяти гостевой ОС вызывает прерывание (VM exit), которое сериализуется через единственную очередь команд хоста. Это создает конкуренцию за спинлок и блокирует выполнение. Решение оказалось в использовании расширения виртуализации очереди команд (CMDQV/VCMDQ), которое позволяет гостевой системе отправлять команды инвалидации напрямую в железо, минуя лишние переходы в режим хоста.
Для исправления ситуации требовалось ядро с драйвером tegra241-cmdqv и поддержка гипервизора. В современных версиях QEMU/libvirt появилась возможность экспортировать атрибут IOMMU cmdqv гостевым системам. После включения этой опции функция arm_smmu_cmdq_issue_cmdlist исчезла из топ-списка затрат процессора, а частота промахов dTLB вернулась к уровню bare metal. Разрыв в производительности MoE-модели сузился до приемлемых значений.
03Кейс 2: H100 кластер — заметная потеря производительности из-за питания CPU и NUMA
Второй кейс демонстрирует, что проблемы могут лежать не в ядре, а в BIOS и управлении питанием. Кластер H100 SXM5, использующий тот же NCCL и контейнер NeMo, что и эталонная
Источник: NVIDIA Developer ↗