Последняя проверка: июнь 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене NCA-AIIO. Читайте сверху вниз или переходите к нужному разделу.
Определите, должна ли рабочая нагрузка выполняться на GPU или CPU.
Массово параллельные вычисления (обучение/инференс глубокого обучения, матричные операции, симуляция) → GPU. Последовательная, сильно разветвленная логика управления, задачи ОС, легкий ввод/вывод → CPU.
Почему: GPU имеют тысячи ядер, оптимизированных для пропускной способности при параллельной работе SIMT; CPU выигрывают в чувствительной к задержкам последовательной логике. Большинство систем ИИ используют оба.
Выберите строительный блок NVIDIA: готовое устройство или плату для OEM-систем.
Интегрированный сервер ИИ "под ключ" (GPU + CPU + NVLink + сеть + программное обеспечение) → DGX. Базовая плата GPU, вокруг которой OEM-производители/облачные провайдеры строят серверы → HGX.
Почему: DGX — это готовая к работе референсная система NVIDIA; HGX — это многопроцессорная плата, которую интегрируют гиперскейлеры.
GPU в одном сервере требуют более высокой пропускной способности между GPU, чем предоставляет шина.
Используйте NVLink (и NVSwitch для связи "все со всеми") для высокоскоростного внутриузлового соединения GPU; PCIe является запасным вариантом, когда NVLink недоступен.
Почему: NVLink обеспечивает значительно более высокую пропускную способность между GPU и меньшую задержку, чем PCIe, что критически важно для параллельного обучения моделей и обучения больших пакетов внутри узла.
Все 8 GPU в узле должны обмениваться данными друг с другом на полной пропускной способности NVLink одновременно.
NVSwitch — это неблокирующая коммутирующая структура, которая соединяет каждый GPU с каждым другим GPU на полной скорости NVLink.
Почему: Только лишь NVLink "точка-точка" не обеспечивает пропускную способность "все со всеми"; NVSwitch предоставляет кроссбар для полнофункциональной GPU-коммуникации.
Различайте наращивание производительности (внутри сервера) и масштабирование (между серверами) межсоединений.
Наращивание производительности GPU внутри узла → NVLink/NVSwitch. Масштабирование между узлами в кластере → InfiniBand (или RoCE Ethernet).
Почему: NVLink — внутриузловой; InfiniBand соединяет узлы в кластер для распределенного обучения на нескольких узлах.
Выберите фабрику кластера для крупномасштабного распределенного обучения, где задержка коллективных операций имеет наибольшее значение.
Минимальная задержка, вычисления в сети (SHARP), RDMA-native → InfiniBand. Привычная, более низкая стоимость, широкая экосистема → RoCE на Spectrum-X Ethernet.
Почему: InfiniBand с SHARP выгружает all-reduce в коммутатор, сокращая задержку коллективных операций; Spectrum-X — это ответ NVIDIA на Ethernet для ИИ-фабрик.
Передача сетевых, дисковых и безопасностных операций с CPU, чтобы ядра освободились для вычислений ИИ.
NVIDIA BlueField DPU — программируемый блок обработки данных, который разгружает и изолирует инфраструктурные службы от хост-CPU/GPU.
Почему: DPU ускоряют "восток-запад" сетевые операции, хранилище NVMe-oF и безопасность с нулевым доверием, повышая эффективную утилизацию GPU/CPU и изоляцию арендаторов.
Требуется высокоскоростной RDMA NIC для узлов GPU без полной разгрузки DPU.
NVIDIA ConnectX SmartNIC — высокопроизводительный адаптер InfiniBand/Ethernet с поддержкой RDMA и GPUDirect.
Почему: ConnectX обеспечивает RDMA на скорости линии; BlueField добавляет программируемую подсистему Arm сверху для полной разгрузки инфраструктуры.
Сокращение задержки путем перемещения данных в память GPU без промежуточного хранения в памяти CPU/хоста.
GPUDirect RDMA — сетевые адаптеры напрямую читают/записывают память GPU; GPUDirect Storage делает то же самое для NVMe-хранилищ.
Почему: Обход буфера отскока CPU устраняет копирование и задержку на пути данных, что крайне важно для пропускной способности многоузлового обучения.
Выберите архитектуру GPU текущего поколения для центров обработки данных для обучения больших моделей.
Hopper (H100/H200) — это устоявшееся поколение с Transformer Engine + FP8; Blackwell (B200/GB200) — это новое поколение с более высокой пропускной способностью и FP4 для самых больших моделей.
Почему: Обе архитектуры нацелены на трансформаторные рабочие нагрузки; Blackwell продвигает масштабирование и инференс с более низкой точностью (FP4) дальше. Сопоставляйте с бюджетом и размером модели.
Определите аппаратное обеспечение, которое ускоряет матричные вычисления глубокого обучения.
Tensor Cores — специализированные блоки, которые выполняют совмещенные операции умножения-накопления матриц со смешанной точностью (FP16/BF16/FP8/FP4).
Почему: Они обеспечивают на порядок более высокую пропускную способность для GEMM/сверток, чем стандартные ядра CUDA, что значительно повышает производительность DL.
Большая модель не помещается; узким местом является пропускная способность памяти, а не вычисления.
Выбирайте GPU с большим и быстрым HBM (например, H200/B200 с HBM3e); используйте многопроцессорный параллелизм моделей, когда памяти одного GPU недостаточно.
Почему: Обучение/инференс больших моделей часто ограничены объемом памяти и пропускной способностью; HBM обеспечивает высокую пропускную способность, необходимую GPU.
Разверните готовый, проверенный многостоечный суперкомпьютер ИИ для корпоративного обучения.
NVIDIA DGX SuperPOD — референсная архитектура узлов DGX, фабрики InfiniBand, хранилища и программного обеспечения Base Command.
Почему: SuperPOD — это предварительно проверенная полнофункциональная конструкция; она устраняет догадки при подключении фабрики, хранилища и оркестрации в масштабе.
Получите вычислительную мощность DGX-класса для обучения без владения оборудованием.
NVIDIA DGX Cloud — управляемая инфраструктура для обучения ИИ, размещенная у крупных облачных провайдеров, доступная как услуга.
Почему: OpEx против CapEx: DGX Cloud подходит для пиковых или краткосрочных тренировок; локальные DGX/SuperPOD подходят для постоянного высокого использования и ограничений, связанных с гравитацией данных.
Выберите между локальным GPU-кластером и облачными GPU для рабочих нагрузок ИИ.
Постоянное высокое использование, суверенитет данных, предсказуемые расходы → локальный DGX/SuperPOD. Переменный/пиковый спрос, быстрый старт, отсутствие следа ЦОД → облако или DGX Cloud.
Почему: Приобретенные GPU хорошо окупаются только при постоянной высокой загрузке; простаивающее собственное оборудование — это чистые затраты.
Новый GPU-кластер превышает бюджет мощности и охлаждения стойки существующего центра обработки данных.
Планируйте высокую плотность питания (десятки кВт/стойка) и жидкостное охлаждение для новейших GPU; рассчитывайте блоки распределения питания (PDU), шинопроводы и тепловую мощность перед установкой.
Почему: Современные узлы GPU (и стойки GB200) потребляют гораздо больше энергии и выделяют больше тепла, чем устаревшие серверы; воздушное охлаждение и стандартные PDU часто не справляются.
Обучение прерывается, потому что конвейер данных не может достаточно быстро подавать данные на GPU.
Используйте высокопроизводительное параллельное/NVMe хранилище с GPUDirect Storage; рассчитывайте на постоянную пропускную способность чтения, чтобы GPU оставались насыщенными.
Почему: Недостаточное выделение ресурсов ввода/вывода хранилища приводит к простою дорогих GPU в ожидании данных; уровень хранилища должен соответствовать совокупному спросу на чтение GPU.
Модель слишком велика для обучения на одном узле в приемлемое время.
Масштабируйте до нескольких узлов через InfiniBand, используя параллелизм данных/тензоров/конвейеров; NCCL обрабатывает коллективную связь GPU.
Почему: Для многоузлового масштабирования требуется низкоlatency фабрика и оптимизированная библиотека коллективных операций (NCCL); медленная фабрика убивает эффективность масштабирования.
Одиночный A100/H100 избыточен для небольших задач инференса; нужны аппаратно изолированные срезы.
Multi-Instance GPU (MIG) — разделение одного GPU на до 7 изолированных экземпляров, каждый со своей выделенной вычислительной мощностью и памятью.
Почему: MIG обеспечивает истинную аппаратную изоляцию и предсказуемое качество обслуживания для многопользовательского инференса, в отличие от мягкого разделения по времени.
Разграничьте ИИ, машинное обучение и глубокое обучение.
ИИ — это общая цель; ML — это подмножество, которое учится на данных; DL — это подмножество ML, использующее многослойные нейронные сети.
Почему: Они вложены: DL ⊂ ML ⊂ AI. DL стимулирует современный спрос на GPU, потому что нейронные сети массово параллельны.
Разграничьте вычислительный профиль обучения и инференса.
Обучение = ресурсоемкое по вычислениям и памяти, длительное, пакетное, много GPU. Инференс = чувствительный к задержкам, более легкий, часто одно/частичное GPU, непрерывно работает в продакшене.
Почему: У них разные потребности в оборудовании и масштабировании; расчет размера кластера требует разделения этих двух рабочих нагрузок.
Выберите парадигму обучения: размеченные данные, неразмеченные данные или обучение на основе проб и ошибок с вознаграждением.
Размеченные → обучение с учителем. Неразмеченная кластеризация/структура → обучение без учителя. Агент учится на вознаграждении → обучение с подкреплением.
Почему: Имеющиеся у вас данные (и цель) определяют парадигму; RLHF — это обучение с подкреплением, управляемое обратной связью от человека для выравнивания LLM.
Объясните, почему нейронные сети хорошо подходят для GPU.
Это слои взвешенных матричных умножений и нелинейных активаций — плотная параллельная линейная алгебра, которую GPU эффективно выполняют.
Почему: Прямые/обратные проходы сильно зависят от GEMM; Tensor Cores ускоряют именно это, поэтому DL работает на GPU.
Определите архитектуру, лежащую в основе современных LLM и генеративного ИИ.
Трансформер — архитектура, основанная на механизме внимания, которая масштабируется с данными и параметрами; на ней строятся базовые модели и LLM.
Почему: Трансформеры хорошо поддаются распараллеливанию, поэтому они стимулируют спрос на большие кластеры GPU и аппаратное обеспечение Transformer Engine.
Ускорить обучение и сократить использование памяти без существенного ущерба для точности.
Используйте смешанную точность — FP16/BF16 (и FP8 на Hopper/Blackwell) для вычислений, FP32 для накопления; Tensor Cores ускоряют операции с более низкой точностью.
Почему: Более низкая точность вдвое сокращает память и многократно увеличивает пропускную способность; масштабирование потерь / BF16 сохраняет численную стабильность.
Назовите основу, которая позволяет программному обеспечению работать на GPU NVIDIA.
CUDA — это платформа параллельных вычислений и модель программирования от NVIDIA; CUDA-X — это уровень библиотек (cuDNN, cuBLAS, NCCL, RAPIDS и т.д.).
Почему: Фреймворки, такие как PyTorch/TensorFlow, используют библиотеки CUDA-X; CUDA является краеугольным камнем, который связывает программное обеспечение ИИ с GPU NVIDIA.
Ускорить примитивы глубокого обучения (свертки, внимание) внутри фреймворка.
cuDNN предоставляет оптимизированные для GPU примитивы DL; cuBLAS обрабатывает плотную линейную алгебру; оба используются PyTorch/TensorFlow.
Почему: Эти библиотеки позволяют фреймворкам достигать скорости GPU без необходимости писать CUDA-ядра вручную.
Получите оптимизированные для NVIDIA, готовые для GPU контейнеры, модели и Helm-чарты.
Каталог NGC (NVIDIA GPU Cloud) — тщательно подобранный реестр оптимизированных контейнеров (фреймворки, NIM, Triton), предварительно обученных моделей и SDK.
Почему: Контейнеры NGC поставляются настроенными и протестированными для GPU NVIDIA, устраняя неопределенность с зависимостями и совместимостью драйверов.
Обслуживайте множество моделей из различных фреймворков за одной стандартизированной, эффективной для GPU конечной точкой.
NVIDIA Triton Inference Server — сервис обслуживания моделей с поддержкой нескольких фреймворков, динамической пакетизацией, параллельным выполнением моделей и совместным использованием GPU.
Почему: Triton максимизирует использование GPU для инференса посредством пакетизации и параллелизма моделей вместо одного процесса на модель.
Быстро разверните базовую модель в качестве готового к производству, оптимизированного микросервиса инференса.
NVIDIA NIM — предварительно созданные, контейнеризированные микросервисы инференса с оптимизированными движками и стандартными API для популярных моделей.
Почему: NIM упаковывает модель + оптимизированную среду выполнения (TensorRT-LLM/Triton) + API в единый развертываемый блок, сокращая время вывода в производство.
Уменьшить задержку инференса и увеличить пропускную способность для обученной модели.
Скомпилируйте модель с помощью TensorRT (или TensorRT-LLM для LLM) — объединение слоев, калибровка точности (INT8/FP8) и автоматическая настройка ядра.
Почему: TensorRT создает оптимизированный движок инференса для целевого GPU, часто многократно увеличивая пропускную способность по сравнению с использованием необработанного фреймворка.
Ускорить подготовку данных в стиле pandas/scikit-learn и классическое ML на GPU.
NVIDIA RAPIDS — cuDF (DataFrames), cuML (ML), cuGraph (graphs) выполняют рабочий процесс анализа данных на GPU.
Почему: RAPIDS сохраняет табличные ETL и классическое ML на GPU, избегая узких мест CPU в конвейере.
Управляйте рабочими нагрузками ИИ, заданиями и пользователями в кластере DGX/SuperPOD.
NVIDIA Base Command — планирование заданий, управление кластерами и оркестрация рабочих нагрузок для инфраструктуры DGX.
Почему: Base Command — это операционная панель управления для систем DGX; она обрабатывает отправку многопользовательских заданий и отслеживание ресурсов.
Требуется поддерживаемое, безопасное, готовое к производству программное обеспечение ИИ с корпоративными SLA.
NVIDIA AI Enterprise — поддерживаемый набор программного обеспечения (фреймворки, NIM, Triton, RAPIDS, GPU Operator) с исправлениями безопасности и корпоративной поддержкой.
Почему: Он объединяет проверенный стек с поддержкой и гарантиями жизненного цикла, что требуется регулируемым/производственным средам.
Определите базовую модель и способы ее адаптации командами.
Большая модель, предварительно обученная на обширных данных, адаптируемая к множеству задач через prompting, RAG или тонкую настройку, а не обучение с нуля.
Почему: Адаптация (prompt/RAG/fine-tune) значительно дешевле предварительного обучения; большинство предприятий используют базовые модели, а не создают их.
Добавить частные/актуальные знания в приложение на базе LLM.
Часто меняющиеся факты → RAG (извлечение из векторного хранилища во время инференса). Обучение новому поведению/стилю/навыкам в домене → тонкая настройка.
Почему: RAG сохраняет данные внешними и обновляемыми без переобучения; тонкая настройка "запекает" поведение в веса и дороже в обновлении.
Оцените, насколько эффективно используются дорогие GPU.
Отслеживайте утилизацию GPU, использование памяти и активность SM/Tensor-Core; низкая утилизация сигнализирует о проблемах с конвейером данных, размером пакета или планированием.
Почему: Высокая загрузка GPU по часам может скрывать низкую эффективную вычислительную мощность; смотрите на занятость Tensor-Core/SM, а не только на индикатор утилизации.
Мониторинг состояния GPU, утилизации, температуры, мощности и ошибок в кластере.
NVIDIA DCGM (Data Center GPU Manager) — телеметрия, проверки состояния и диагностика; экспорт метрик в Prometheus/Grafana.
Почему: DCGM — это стандартный источник телеметрии GPU; DCGM Exporter передает данные в Prometheus для общекластерных панелей мониторинга и оповещений.
Предоставьте драйверы GPU, инструментарий контейнера и мониторинг в кластере Kubernetes без ручной настройки для каждого узла.
NVIDIA GPU Operator — автоматизирует настройку драйвера, среды выполнения контейнеров, плагина устройств, DCGM и MIG в Kubernetes.
Почему: Он управляет полным жизненным циклом программного обеспечения GPU декларативно, устраняя хрупкие установки драйверов для каждого узла.
Выберите оркестратор для рабочих нагрузок GPU.
Микросервисы/инференс, облачные, смешанные рабочие нагрузки → Kubernetes. Пакетные задания обучения в стиле HPC, групповое планирование, традиционные кластеры → Slurm.
Почему: Kubernetes превосходно справляется с долгосрочными сервисами и эластичностью; Slurm — с пакетными заданиями в очереди с планированием в стиле MPI.
Поды Kubernetes должны запрашивать GPU и быть запланированы на них.
Плагин устройств NVIDIA объявляет GPU как планируемые ресурсы; поды запрашивают `nvidia.com/gpu`, и планировщик размещает их.
Почему: Без плагина устройств Kubernetes не может видеть или выделять GPU; именно он делает GPU первоклассным ресурсом.
Множество мелких заданий/пользователей должны совместно использовать GPU для повышения утилизации.
Аппаратная изоляция → MIG. Мягкое совместное использование одного GPU → разделение по времени или MPS. Сочетайте с квотами пространств имен для справедливости.
Почему: MIG предоставляет гарантии QoS; разделение по времени/MPS переподписывают GPU без изоляции. Выбирайте в соответствии с требованиями к изоляции.
Высокоприоритетное обучение должно вытеснять низкоприоритетные эксперименты в общем кластере.
Используйте приоритет/вытеснение и очереди в планировщике (разделы Slurm или Kubernetes PriorityClasses с квотой); групповое планирование многопроцессорных заданий.
Почему: Групповое планирование предотвращает тупики частичного выделения ресурсов; классы приоритета обеспечивают бизнес-порядок на оспариваемых GPU.
Поддерживайте согласованность и совместимость версий драйверов GPU, CUDA и инструментария контейнеров на всех узлах.
Стандартизируйте с помощью GPU Operator (Kubernetes) или контейнеров NGC; сопоставьте драйвер с версиями CUDA, необходимыми вашим фреймворкам, и развертывайте обновления в периоды обслуживания.
Почему: Несоответствия драйверов/CUDA/фреймворков являются основной причиной сбоев кластера; CUDA, привязанная к контейнеру, отвязывает приложение от хост-драйвера в пределах поддерживаемых диапазонов.
Определите размер GPU-кластера для прогнозируемого спроса на обучение и инференс.
Разделите обучение (пиковое, пакетное) от инференса (постоянное, ограниченное задержкой); планируйте запас по мощности/охлаждению/фабрике и стремитесь к высокой постоянной утилизации.
Почему: Превышение размера приводит к растрате CapEx на простаивающие GPU; недостаточный размер замедляет доставку. Планируйте исходя из сочетания рабочих нагрузок, а не одного пика.
GPU дросселируют или выходят из строя при длительной высокой нагрузке.
Мониторинг температуры и мощности через DCGM; обеспечьте адекватное охлаждение (жидкостное для плотных стоек), установите разумные ограничения мощности и оповещайте о превышении температурных порогов.
Почему: Термическое дросселирование незаметно снижает пропускную способность; проактивная телеметрия и проектирование охлаждения защищают как производительность, так и срок службы оборудования.
Предоставьте ускорение GPU нескольким виртуальным машинам или пользователям VDI с общего оборудования.
Программное обеспечение NVIDIA vGPU разделяет физический GPU между виртуальными машинами с планированием и изоляцией; MIG может поддерживать профили vGPU для жесткого разделения.
Почему: vGPU обеспечивает виртуализированный/многопользовательский доступ к GPU (VDI, облако), который не может быть совместно использован прямым доступом к физическому оборудованию.
Узел возвращает ошибки Xid или сбойные задания; необходимо изолировать неисправные GPU, прежде чем они повредят другие запуски.
Запустите диагностику DCGM и активные проверки состояния; отсоедините/осушите узел, замените или сбросьте GPU, и только затем верните его в пул.
Почему: Ошибки Xid и сбои ECC указывают на неисправные GPU; автоматическое управление состоянием предотвращает попадание неисправного GPU в пул планирования.