当前位置: 首页 > news >正文

NVIDIA IMEX Service for NVLink Networks-Overview

Overview

Today’s mainstream AI models contain billions of parameters, which require tremendous amounts of compute, memory storage, and system connectivity for model training and deployment. Moore’s Law has not kept pace with these exponential increases in computing demand. To overcome Moore’s law, enterprises adopt AI the NVIDIA way, which involves scaling up and out their diverse AI and data analytics applications with NVIDIA GPU computing capabilities. At the core of every NVIDIA® DGX™ and NVIDIA HGX™ system is NVIDIA NVLink™-connected GPUs that access each other’s memory at NVLink speed.

Over the years, NVLink has become the de facto high-speed, direct GPU-to-GPU interconnect for single node multi-GPU systems. Many of these systems are now interconnected with high-speed networking, like InfiniBand, to form supercomputers. With an NVLink Network (also known as the NVLink Multi-Node), these supercomputer systems are inter-connected using NVLink, which acts like a gigantic accelerator with shared memory.

Definitions, Acronyms, and Abbreviations

Abbreviations

Definitions

Node or Compute Node

An OS instance with at least one GPU.

NVLink Domain or cluster

A set of nodes that can communicate over NVLink.

L1 NVSwitch Tray

First level of NVIDIA NVSwitch™, for example, the NVSwitches to which the GPU NVLinks connect.

NVLink Domain

A set of nodes that can communicate over NVLink

FM

Fabric Manager. NVLink Network control plane service is provided by the FM service

GFM

Global Fabric Manager. An instance of FM with a specific set of features enabled. There is one GFM per NVLink domain (cluster).

LFM

Local Fabric Manager. An instance of FM with specific set of features enabled and that runs on each L1 NVSwitch tray or compute tray.

NVLSM

NVLink Subnet Manager A service that originates from NVIDIA InfiniBand switches and has the necessary modifications to effectively manage NVSwitches.

Access NVLink

An NVLink between a GPU and an NVSwitch.

Trunk NVLink

An NVLink between NVSwitches.

NVOS

NVIDIA Networking OS, which was previously known as MLNX-OS. NVOS is used as the Switch OS for L1 NVSwitch Trays.

NVLink ALI

Autonomous Link Initialization. A feature, which was introduced in NVL4, enables NVLink training to be performed asynchronously by both sides of the link without an increase in software stack coordination.

IMEX Domain

A set of compute nodes connected by NVLink on which the nvidia-imex service has been installed and configured to communicate with each other via the nodes_config.cfg

About NVLink Networks

The NVLink multi-node architecture extends the Multi-GPU NVLink Peer-to-Peer (P2P) programming model from a Compute Node (or OS domain) to include multiple compute nodes, where each node operates with an independent operating system. NVLink P2P allows multiple systems to access each others GPU memory directly over NVLink. In the most general form, the goal is to connect multiple compute nodes using a set of independent L1 NVSwitch Switch Trays.

Figure 1‑1. L1 NVSwitch Domain only NVLink Network

Figure 1-1

Compute Trays

The compute node (or compute tray) has at least one NVIDIA Data Center GPU that is connected to NVIDIA Grace™ CPUs or an x86 CPU. The GPU NVLinks will connect to a set of L1 NVSwitch switch trays, and the NVIDIA CUDA® software stack and NVIDIA Internode Memory Exchange/Management Service (IMEX) service run on the compute nodes. After creating NVLink partitions, the compute node can operate in the bare metal mode or the virtualized mode.

L1 NVLink Switch Tray

The L1 NVSwitch Switch Tray is a stand-alone, NVSwitch-based unit that is designed to construct more extensive NVLink network topologies. Depending on your NVLink network configuration requirements, this unit offers various versions, where each version features a specific number of port specifications. For example, in a network domain that is dedicated to single level of L1 NVLink connections, all NVLink ports are exclusively used for GPU NVLink connections. On the other hand, in a NVLink network domain that combines two racks (back-to-back), with L1-to-L1 connections, half of the available ports are designated for GPU NVLink connections, and the other half is dedicated to linking with the L1 NVSwitch tray on the other rack.

The NVLink rack switch also includes the following features:

  • Is equipped with a management CPU.

  • Uses the NVIDIA Switch OS (NVOS).

  • Offers conventional network appliance-style interfaces such as a command-line interface (CLI), JSON, RESTful , and so on to facilitate life cycle management and configuration tasks.

NVLink Control Plane Services

This section provides information about the NVLink control plane services.

Systems Using Earlier than Fourth-Generation NVSwitches

For systems that use NVIDIA third-generation NVSwitches, the NVLink Network control plane (SDN) service is provided by the Fabric Manager (FM) service. In this model, the FM service is split into the Global Fabric Manager (GFM) and Local Fabric Manager (LFM) roles. One of the L1 NVSwitch switch trays runs a GFM instance and rest of the L1 NVSwitch switch trays run an LFM instance in this mode.

Systems Using Fourth-Generation NVSwitches

With the fourth-generation NVSwitches, NVIDIA has implemented a unified architecture that spans across NVLink, InfiniBand, and Ethernet switches. As a result of this integration, a new control plane entity called NVLink Subnet Manager (NVLSM) is introduced with Fabric Manger (FM). The NVLSM service originates from NVIDIA IB Switches and has the necessary modifications to effectively manage NVSwitches.

At a higher level, the NVLSM service configures NVSwitch routing tables, and FM handles GPU-side routing, NVLink configuration, and provides APIs for partition management. The interaction between NVLSM and FM is facilitated through an Inter-Process Communication (IPC) interface.

Global Fabric Manager

FM configures the NVSwitch memory fabrics to form one memory fabric among all participating GPUs and monitors the NVLinks that support the fabric. At a high level, FM has the following responsibilities:

  • Configures routing (earlier than the fourth-generation NVSwitch) among NVSwitch ports.

  • Sets up GPU side routing/port map if applicable.

  • Coordinates with the GPU driver to initialize GPUs.

  • Manages and assigns address space to GPUs for memory sharing.

  • Monitors the fabric for NVLink and NVSwitch errors.

For systems earlier than fourth-generation NVSwitches, the GFM takes the IP address information of all the Local Fabric Manger (LFM) nodes and establishes a TCP I/P network connection with each LFM instance. This out-of-band socket connection is used by GFM to push routing information to each LFM instances.

Local Fabric Manager

For systems earlier than fourth-generation NVSwitches. an instance of the LFM runs on each L1 NVSwitch tray. The LFM instances interact with the underlying NVSwitch ASIC through the NVSwitch driver and program the switch address map and the routing information as directed by the GFM. At run time, the LFM maintains the access control bits based on the NVLink partitions that were created by GFM, reads the NVLink and NVSwitch error information, and relays this information to the GFM.

NVLink Subnet Manager

NVLink Subnet manager (NVLSM) originated from the IB networking and added additional logic to program NVSwitches and NVLinks. At a high level, in NVSwitch-based systems, the NVLSM provides the following functionality:

  • Discovers the NVLink network topology.

  • Assigns a local identifier (LID) to all the GPU and NVSwitch NVLink ports.

  • Calculates and programs switch forwarding tables.

  • Programs the Partition Key (PKEY) for NVLink partitions.

  • Monitors changes in the NVLink fabric.

NVIDIA Switch OS

The L1 NVSwitch switch tray comes with NVOS, which is equipped with an industry-standard CLI that is accessible using SSH or Telnet sessions.

On L1 NVSwitch switch trays that use earlier than fourth-generation NVSwitches, the NVOS image includes the LFM, the GFM service, and NVSwitch drivers to manage the switches.

On L1 NVSwitch switch trays that use fourth-generation NVSwitches, the NVOS image includes NMX-Controller (NMX-C), which is a fabric SDN controller application to manage the switches. This NMX-C image includes the GFM and NVSM services. As part of the rack onboarding process, the administrator must enable and configure NMX-C to run on only one of the L1 NVSwitch switch trays to manage all the switch trays in the same NVLink fabric.

NVIDIA NVLink Network Servers

This section provides information about the NVLink network servers.

NVIDIA GB200 NVL72

The NVIDIA GB200 NVL72 rack scale architecture is an Open Compute Project (OCP) Open Rack v3 (ORv3) rack with two configurations that support up 72-GPUs . The NVIDIA reference design provides options for 36-GPUs in a single rack, 72-GPUs in two racks, or 72-GPUs in a single rack.

A 36-GPU rack contains the following:

  • 9x 2RU compute trays, each with 2 Grace CPUs and 4 Blackwell GPUs.

  • 9x 1RU NVLink switch trays with 18 OSFP front panel interfaces.

  • TOR Switches for management.

  • Power shelves for supplying power to all trays and switches.

Figure 1‑2 shows the configuration of a single rack 36-GPU configuration and a dual rack 72-GPU configuration

Figure 1‑2. GB200 NVLink Rack Configuration

GB200 NVLink Rack Configuration

A 72-GPU rack contains the following:

  • 18x 1RU compute trays, each with two Grace CPUs and four Blackwell GPUs.

  • 9x 1RU NVLink switch trays (with no OSFP front-panel interfaces).

  • TOR Switches for management.

  • Power shelves to supply power to all trays and switches.

Figure 1‑4 shows the configuration of a single-rack, 72-GPU configuration.

Figure 1‑4. A Single-Rack, 72-GPU Configuration

Single rack, 72 GPU Configuration

The NVIDIA Import/Export Service for Internode Memory Sharing

The IMEX service supports GPU memory export and import (NVLink P2P) and shared memory operations across OS domains in an NVLink multi-node deployment.

Multi-Node Memory Sharing Model

This section provides information about the multi-node memory sharing model.

Figure ‑. Multi-Node Memory Sharing Model

Multi-Node Memory Sharing Model

At a high level, the job entails coordinating CUDA processes that are running on each compute node in its own OS domain. On one node, the CUDA process allocates GPU memory and obtains the corresponding sharable memory handle. This allocation and handle creation trigger the establishment of a Virtual Address (VA) to Physical Address (PA) to Fabric Address (FA) mapping on the exporting node. Here is an overview of the process:

  1. For importing, the process shares the memory handle with the coordinating process on other nodes using MPI/NCCL.

  2. On these nodes, the CUDA processes prompt the GPU driver to import the relevant memory using the received handle.

  3. The GPU driver on the importing node creates the requisite memory objects and establishes the VA-to-FA mapping.

  4. When the importing process accesses the VA address space, the GPU memory system on the importing nodes recognizes the corresponding physical page tables by leveraging a foreign GPU and generates NVLink packets to access the pertinent memory.

To facilitate the importing node’s establishment of the VA-to-FA mapping, a privileged entity capable of communicating across OS/Node domains is essential to retrieve the necessary memory mapping information from the exporting node. Operating at a higher level, the IMEX service serves this function by acting as an orchestrator for memory export and import across compute nodes.

Here are some key features of the IMEX service:

  • Facilitates memory sharing between compute nodes.

  • Manages the life cycle of the shared memory.

  • Registers for memory import/unimport events with the GPU Driver.

  • Does not directly communicate with CUDA or user applications.

  • Communicates across nodes using the compute node’s network by using TCP/IP and gRPC connections.

  • Runs exclusively on compute nodes.

This guide provides an overview of various IMEX features and is intended for multi-node system administrators.

Note: In an NVLink multi-node cluster, before jobs are launched, start the IMEX service. NVLink multi-node jobs will fail if the IMEX service is not properly initialized. |

http://www.jsqmd.com/news/1340775/

相关文章:

  • 英雄联盟玩家的终极智能助手:Seraphine如何帮你轻松赢在起跑线
  • ADC量化误差:从原理到实战,全面解析与系统设计指南
  • 上海报废物资销毁环保合规要求解读,企业做产品文件食品销毁需要注意什么 - 甄选测评官
  • 2026佛山哪家输送带厂家综合实力强?头部厂商测评**出炉 - 互联网科技品牌测评
  • Honey Select 2终极汉化去码补丁:从新手到专家的完整指南
  • 2026 海南 TK 跨境电商个体户注册攻略|海口三亚办理条件与本土代办服务商怎么选 - 全域品牌推荐
  • 口腔癌预测数据集:用于分析风险因素、诊断和生存情况的综合数据集
  • 【爱马仕】Hermes Agent Windows 部署教程 整合安装包快速完成本地搭建
  • 2026年湖北省蛙人打捞服务**,水下救援电话**整理 - GrowthUME
  • 利用AI智能体Workbuddy自动化部署GIS软件环境实践指南
  • 生命涌现的小龙虾技能之【Student Classroom Engagement Analysis | 学生课堂情绪参与度分析】简介
  • 温州装修公司怎么选?深耕本土 15 年|康居装饰,用全案家装打造省心好家 - 甄选测评官
  • 2026南平房屋渗水隐患大全|防水修缮工艺+报价明细,全域上门维修 - 筑宅安
  • 什么是PVC管加工定制厂家?一篇读懂其定义、价值与实现路径 - 汇聚至此
  • 2026公共马桶卫生垫代工生产商家大盘点:正规合规实力强口碑佳,附选型避坑指南 - 产业观察报
  • 高速电路地弹现象:原理、危害与PCB设计实战应对策略
  • 【建立个人知识库】
  • Source Insight高效配置指南:解决代码解析与视觉优化难题
  • Tableau Desktop数据可视化全流程指南与实战技巧
  • 浙江润鑫便携式称重仪质量稳定,适应野外工况,路政矿山车辆称重通用设备 - 品牌速递
  • 2026 岳麓区厨卫屋面地下室漏水测评,靠谱防水商家对比参考 - 超人防水
  • Elasticsearch三节点集群部署与调优实战指南
  • FantiaDL终极指南:如何高效备份你的Fantia数字收藏
  • C/C++底层原理深度解析:从源码到硬件,掌握系统级编程核心
  • 河南省温县少林功夫文武学校-主页 - 全国文武学校招生
  • python-zip-解包-format输出
  • RabbitMQ生产者确认机制原理与实践指南
  • 食品PLM如何破解研发痛点?看爱研PLM精准破局
  • 8.5 未做出题。
  • 2026年PVC管加工定制厂家:解读行业三大核心趋势 - 汇聚至此