手册 — NCA-AIIO NVIDIA-Certified Associate: AI Infrastructure and Operations

最后审核：2026年6月

NCA-AIIO 考试涉及的架构模式快速参考。从头到尾阅读，或跳转到任意章节。

AI基础设施

决定工作负载应在GPU还是CPU上运行。

大规模并行计算（深度学习训练/推理、矩阵运算、模拟）→ GPU。串行、分支密集型控制逻辑、操作系统任务、轻量级I/O → CPU。

原因: GPU拥有数千个核心，针对并行SIMT工作的吞吐量进行了优化；CPU在对延迟敏感的串行逻辑方面表现出色。大多数AI系统都将两者结合使用。

选择 NVIDIA 积木：完整的设备与用于 OEM 系统的板卡。

交钥匙集成式AI服务器（GPU + CPU + NVLink + 网络 + 软件）→ DGX。OEM/云提供商围绕其构建服务器的GPU基板 → HGX。

原因: DGX 是 NVIDIA's 的即用型参考系统；HGX 是超大规模企业自行集成的多GPU板卡。

参考

一台服务器中的GPU需要比总线提供的更快的GPU到GPU带宽。

使用 NVLink（以及用于全连接的 NVSwitch）实现高带宽节点内 GPU 互连；当 NVLink 不可用时，PCIe 是备用方案。

原因: NVLink 提供远高于 PCIe 的 GPU 到 GPU 带宽和更低的延迟，这对于节点内的模型并行和大型批量训练至关重要。

参考

节点中的所有8个GPU必须同时以完整的 NVLink 带宽相互通信。

NVSwitch — 一种无阻塞交换架构，以完整的 NVLink 速度将每个 GPU 连接到其他所有 GPU。

原因: 仅凭点对点 NVLink 无法提供全连接带宽；NVSwitch 为全网状 GPU 通信提供了交叉开关。

参考

区分纵向扩展（服务器内部）与横向扩展（跨服务器）互连。

节点内 GPU 纵向扩展互连 → NVLink/NVSwitch。集群中跨节点横向扩展 → InfiniBand（或 RoCE Ethernet）。

原因: NVLink 是节点内互连；InfiniBand 将节点连接成集群，用于多节点分布式训练。

参考

为大规模分布式训练选择集群网络，其中集合操作延迟最重要。

最低延迟、网络内计算 (SHARP)、原生 RDMA → InfiniBand。熟悉、成本更低、生态系统广泛 → Spectrum-X Ethernet 上的 RoCE。

原因: 带有 SHARP 的 InfiniBand 将 all-reduce 操作卸载到交换机，从而降低了集合延迟；Spectrum-X 是 NVIDIA 针对 AI 网络推出的 Ethernet 解决方案。

参考

将网络、存储和安全处理从CPU卸载，从而释放核心用于AI计算。

NVIDIA BlueField DPU — 可编程数据处理单元，可将基础设施服务从主机 CPU/GPU 卸载并隔离。

原因: DPU 加速东西向网络、NVMe-oF 存储和零信任安全，提高 GPU/CPU 有效利用率和租户隔离。

参考

对于没有完整 DPU 卸载的 GPU 节点，需要高速 RDMA 网卡。

NVIDIA ConnectX SmartNIC — 支持 RDMA 和 GPUDirect 的高吞吐量 InfiniBand/Ethernet 适配器。

原因: ConnectX 提供线速 RDMA；BlueField 在其之上增加了可编程的 Arm 子系统，用于完整的Infrastructure卸载。

参考

通过将数据直接移至 GPU 内存，而无需经过 CPU/主机内存暂存，从而降低延迟。

GPUDirect RDMA — 网卡直接读写 GPU 内存；GPUDirect Storage 对 NVMe 存储执行相同操作。

原因: 绕过 CPU 弹跳缓冲区可消除数据路径上的复制和延迟，这对于多节点训练吞吐量至关重要。

参考

为大型模型训练选择当前一代数据中心 GPU 架构。

Hopper (H100/H200) 是成熟一代，拥有 Transformer Engine + FP8；Blackwell (B200/GB200) 是更新一代，具有更高的吞吐量和 FP4，适用于最大的模型。

原因: 两者都针对 transformer 工作负载；Blackwell 进一步推动了规模和更低精度 (FP4) 推理。根据预算和模型大小进行匹配。

参考

识别加速深度学习矩阵运算的硬件。

Tensor Cores — 专用单元，以混合精度（FP16/BF16/FP8/FP4）执行融合矩阵乘积累加操作。

原因: 它们在 GEMM/卷积上的吞吐量比标准 CUDA 核心高出几个数量级，从而提升了 DL 性能。

参考

大型模型无法适配；内存带宽而非计算是瓶颈。

选择具有更多、更快 HBM 的 GPU（例如带 HBM3e 的 H200/B200）；当一个 GPU 的内存不足时，使用多 GPU 模型并行。

原因: 大型模型的训练/推理通常受限于内存容量和带宽；HBM 提供了 GPU 所需的高带宽。

为企业训练部署交钥匙、经过验证的多机架 AI 超级计算机。

NVIDIA DGX SuperPOD — DGX 节点、InfiniBand 网络、存储和 Base Command 软件的参考架构。

原因: SuperPOD 是预验证的全栈设计；它消除了大规模连接网络、存储和编排的猜测。

参考

无需拥有硬件即可获得 DGX 级别的训练能力。

NVIDIA DGX Cloud — 在主要云提供商上托管的托管式 AI 训练基础设施，作为服务访问。

原因: 运营支出与资本支出：DGX Cloud 适用于突发性或短期训练；本地 DGX/SuperPOD 适用于持续高利用率和数据引力约束。

参考

为 AI 工作负载选择本地 GPU 集群或云端 GPU。

持续高利用率、数据主权、可预测支出 → 本地 DGX/SuperPOD。可变/突发性需求、快速启动、无数据中心足迹 → 云端或 DGX Cloud。

原因: 自有 GPU 仅在持续高利用率下才能很好地摊销；闲置的自有硬件纯粹是成本。

新的 GPU 集群超出了现有数据中心的机架功耗和散热预算。

为最新的 GPU 规划高密度电源（数十千瓦/机架）和液体冷却；在安装前确定 PDU、母线槽和散热能力的大小。

原因: 现代 GPU 节点（和 GB200 机架）消耗的功率和散发的热量远超传统服务器；空气冷却和标准 PDU 通常无法满足需求。

训练停滞，因为数据管道无法足够快地向 GPU 供数据。

使用支持 GPUDirect Storage 的高吞吐量并行/NVMe 存储；根据持续读取带宽进行规划，以保持 GPU 饱和。

原因: 存储 I/O 配置不足会导致昂贵的 GPU 闲置等待数据；存储层必须与 GPU 的总读取需求匹配。

一个模型过大，无法在单个节点上于可接受的时间内完成训练。

通过 InfiniBand 使用数据/张量/流水线并行扩展到多个节点；NCCL 处理 GPU 集合通信。

原因: 多节点扩展需要低延迟网络和优化的集合库 (NCCL)；缓慢的网络会降低扩展效率。

参考

对于小型推理任务，单个 A100/H100 过于强大；您需要硬件隔离的切片。

Multi-Instance GPU (MIG) — 将一个 GPU 划分为最多 7 个隔离实例，每个实例拥有专用计算和内存。

原因: MIG 为多租户推理提供了真正的硬件隔离和可预测的 QoS，这与软时间切片不同。

参考

AI基础知识

区分 AI、机器学习与深度学习。

AI 是广阔的目标；ML 是从数据中学习的子集；DL 是使用多层神经网络的 ML 子集。

原因: 它们是嵌套关系：DL ⊂ ML ⊂ AI。DL 推动了现代 GPU 需求，因为神经网络是大规模并行的。

区分训练与推理的计算特征。

训练 = 计算和内存密集型、长时间运行、批处理、使用多个 GPU。推理 = 延迟敏感型、较轻量、通常使用单个/部分 GPU、在生产中持续运行。

原因: 它们具有不同的硬件和扩展需求；集群的规模设计需要区分这两种工作负载。

选择一种学习范式：标记数据、未标记数据或奖励驱动的试错法。

标记数据 → 监督学习。未标记数据聚类/结构 → 无监督学习。agent 从奖励中学习 → 强化学习。

原因: 您拥有的数据（和目标）决定了范式；RLHF 是由人类反馈引导的强化学习，用于对齐 LLM。

解释为什么神经网络与 GPU 结合良好。

它们是加权矩阵乘法和非线性激活层——GPU 可以高效执行的密集并行线性代数运算。

原因: 前向/反向传播是 GEMM 密集型操作；Tensor Cores 正是加速了这一点，这就是 DL 在 GPU 上运行的原因。

识别现代 LLM 和生成式 AI 背后的架构。

transformer — 基于注意力机制的架构，可随数据和参数扩展；基础模型和 LLM 都构建于其之上。

原因: Transformers 具有高度并行性，这就是它们推动大型 GPU 集群和 Transformer Engine 硬件需求的原因。

在不实质性损害准确性的前提下，加快训练速度并减少内存使用。

使用混合精度 — FP16/BF16（以及 Hopper/Blackwell 上的 FP8）进行计算，FP32 用于累积；Tensor Cores 加速低精度操作。

原因: 更低的精度可将内存减半并使吞吐量成倍增加；损失缩放/BF16 保持数值稳定性。

说出使软件能够在 NVIDIA GPU 上运行的基础。

CUDA — NVIDIA's 的并行计算平台和编程模型；CUDA-X 是库层（cuDNN、cuBLAS、NCCL、RAPIDS 等）。

原因: PyTorch/TensorFlow 等框架在底层调用 CUDA-X 库；CUDA 是将 AI 软件与 NVIDIA GPU 绑定的护城河。

参考

在框架内加速深度学习原语（卷积、注意力）。

cuDNN 提供 GPU 优化的 DL 原语；cuBLAS 处理密集线性代数；两者都位于 PyTorch/TensorFlow 之下。

原因: 这些库是框架无需您编写 CUDA 内核即可获得 GPU 速度的原因。

参考

获取 NVIDIA 优化、GPU 就绪的容器、模型和 Helm chart。

NGC (NVIDIA GPU Cloud) catalog — 优化容器（框架、NIM、Triton）、预训练模型和 SDK 的精选注册表。

原因: NGC 容器经过 NVIDIA GPU 调优和测试，消除了依赖性和驱动兼容性的猜测。

参考

通过一个标准化、GPU 高效的端点，从多个框架提供多个模型服务。

NVIDIA Triton Inference Server — 多框架模型服务，支持动态批处理、并发模型执行和 GPU 共享。

原因: Triton 通过批处理和模型并发，而不是每个模型一个进程，最大限度地提高 GPU 推理利用率。

参考

快速将基础模型部署为生产就绪、优化的推理微服务。

NVIDIA NIM — 预构建的容器化推理微服务，为流行模型提供优化的引擎和标准 API。

原因: NIM 将模型 + 优化运行时 (TensorRT-LLM/Triton) + API 打包成一个可部署单元，缩短了上市时间。

参考

降低训练模型的推理延迟并提高吞吐量。

使用 TensorRT（或用于 LLM 的 TensorRT-LLM）编译模型 — 包括层融合、精度校准 (INT8/FP8) 和内核自动调优。

原因: TensorRT 为目标 GPU 生成优化的推理引擎，通常与原始框架相比，吞吐量成倍增长。

参考

在 GPU 上加速 pandas/scikit-learn 风格的数据准备和传统 ML。

NVIDIA RAPIDS — cuDF (DataFrames)、cuML (ML)、cuGraph (graphs) 在 GPU 上运行数据科学工作流。

原因: RAPIDS 将表格 ETL 和传统 ML 保留在 GPU 上，避免了管道中的 CPU 瓶颈。

参考

管理 DGX/SuperPOD 集群中的 AI 工作负载、作业和用户。

NVIDIA Base Command — 用于 DGX 基础设施的作业调度、集群管理和工作负载编排。

原因: Base Command 是 DGX 系统的运营控制平面；它处理多用户作业提交和资源跟踪。

参考

需要支持的、安全的、生产级的、具有企业级 SLA 的 AI 软件。

NVIDIA AI Enterprise — 支持的软件套件（框架、NIM、Triton、RAPIDS、GPU Operator），带有安全补丁和企业支持。

原因: 它将经过验证的堆栈与支持和生命周期保证捆绑在一起，这是受监管/生产环境所必需的。

参考

定义基础模型以及团队如何对其进行调整。

在广泛数据上预训练的大型模型，可通过提示、RAG 或微调适应多种任务，而无需从头开始训练。

原因: 适应（提示/RAG/微调）比预训练便宜得多；大多数企业使用基础模型，而不是构建它们。

向基于 LLM 的应用程序添加私有/最新知识。

频繁变化的事实 → RAG（在推理时从向量存储中检索）。教授新行为/风格/领域技能 → 微调。

原因: RAG 使数据外部化且无需重新训练即可更新；微调将行为固化到权重中，更新成本更高。

判断昂贵的 GPU 是否被高效利用。

跟踪 GPU 利用率、内存使用情况和 SM/Tensor-Core 活动；低利用率表明数据管道、批量大小或调度瓶颈。

原因: 高时钟 GPU “忙碌” 仍然可能掩盖低效的实际计算；应查看 Tensor-Core/SM 占用率，而不仅仅是利用率指示器。

AI运营

监控集群中的 GPU 健康状况、利用率、温度、功耗和错误。

NVIDIA DCGM (Data Center GPU Manager) — 遥测、健康检查和诊断；将指标导出到 Prometheus/Grafana。

原因: DCGM 是标准 GPU 遥测源；DCGM Exporter 为 Prometheus 提供数据，用于集群范围的仪表板和警报。

参考

在 Kubernetes 集群上配置 GPU 驱动程序、容器工具包和监控，无需逐节点手动设置。

NVIDIA GPU Operator — 在 Kubernetes 上自动化驱动程序、容器运行时、设备插件、DCGM 和 MIG 配置。

原因: 它以声明方式管理完整的 GPU 软件生命周期，消除了脆弱的逐节点驱动程序安装。

参考

为 GPU 工作负载选择一个编排器。

微服务/推理、云原生、混合工作负载 → Kubernetes。批处理 HPC 风格训练作业、gang 调度、传统集群 → Slurm。

原因: Kubernetes 擅长长时间运行的服务和弹性；Slurm 擅长带有 MPI 风格调度的排队批处理作业。

Kubernetes pod 需要请求并调度到 GPU 上。

NVIDIA 设备插件将 GPU 声明为可调度资源；pod 请求 `nvidia.com/gpu`，调度器将其放置。

原因: 没有设备插件，Kubernetes 无法看到或分配 GPU；正是它使 GPU 成为一等资源。

参考

高优先级训练必须抢占共享集群上的低优先级实验。

在调度器中使用优先级/抢占和队列（Slurm 分区或带有配额的 Kubernetes PriorityClasses）；对多 GPU 作业进行 gang 调度。

原因: Gang 调度可防止部分分配死锁；优先级类在竞争 GPU 上强制执行业务顺序。

保持 GPU 驱动程序、CUDA 和容器工具包版本在节点间一致和兼容。

通过 GPU Operator (Kubernetes) 或 NGC 容器进行标准化；将驱动程序与您的框架所需的 CUDA 版本匹配，并在维护窗口中进行更新。

原因: 驱动程序/CUDA/框架不匹配是集群故障的首要原因；容器绑定的 CUDA 在支持范围内将应用程序与主机驱动程序解耦。

根据预测的训练和推理需求规划 GPU 集群规模。

将训练（峰值、批处理）与推理（持续、延迟受限）分开；规划电源/冷却/网络余量，并以高稳定利用率为目标。

原因: 过量配置会在闲置 GPU 上浪费资本支出；配置不足会限制交付。根据工作负载组合而非单一峰值进行规划。

GPU 在持续重负载下会降频或失败。

通过 DCGM 监控温度和功耗；确保充足的冷却（密集机架使用液体冷却），设置合理的功耗限制，并在达到热阈值时发出警报。

原因: 热节流会悄无声息地降低吞吐量；主动遥测和冷却设计可同时保护性能和硬件寿命。

参考

从共享硬件向多个虚拟机或 VDI 用户提供 GPU 加速。

NVIDIA vGPU 软件通过调度和隔离将物理 GPU 划分给多个虚拟机；MIG 可以支持 vGPU 配置，用于硬分区。

原因: vGPU 实现了虚拟化/多租户 GPU 访问（VDI、云），而裸机直通无法共享。

参考

节点返回 Xid 错误或作业失败；您必须在不良 GPU 损坏更多运行之前将其隔离。

运行 DCGM 诊断和主动健康检查；隔离/清空节点，更换或重置 GPU，然后才将其返回到池中。

原因: Xid 错误和 ECC 故障标志着 GPU 正在失效；自动健康门控可防止有问题的 GPU 污染调度池。

参考