NVIDIA CFT（Compute Fabric Transport）特性分析
版本：2026-10 ｜ 素材来源：NVIDIA 官方文档（NCCL 2.32.3 Device API / Usage Guide、CUDA Toolkit 13.4 官方博客）、NCCL Release Notes、PyTorch SymmetricMemory 文档
定位：面向通信库/高级应用开发者的"传输为中心"（transport-centric）设备端数据移动机制
0. 一句话概述
CFT（Compute Fabric Transport，计算织物传输） 是 NVIDIA 从 NCCL 2.31 / CUDA 13.3 开始提供的设备端通信能力：它把 CUDA fabric 的 逻辑端点（logical endpoint） 暴露给 GPU 内核，让内核直接用 fabric 指令发起 异步 put / get / 归约 / barrier 操作，跨 NVLink 织物（fabric）移动数据，而无需把远端 GPU 内存映射进本地进程的虚拟地址空间。
- 硬件要求：Blackwell（SM_100）及更新架构
- 软件要求：CUDA Toolkit 13.3+、驱动 ≥ 610.43.02、NCCL 2.31+
- 定位：仅通过 CUDA Driver API 使用，面向通信库开发者（NCCL / NVSHMEM / PyTorch 等），普通应用层开发者应使用 NCCL / NVSHMEM 等高阶库
1. 背景与动机
1.1 规模扩展带来的地址空间压力
AI 工厂（AI factory）时代，超节点规模持续扩大：以 72-GPU Vera Rubin NVL72 为例，单域 NVLink 提供每 GPU 3.6 TB/s 双向带宽、机架级 260 TB/s。GPU 数量越多，"每个进程都把参与通信的远端 GPU 分配映射进自己的虚拟地址空间"的传统做法就越难以为继：
- 虚拟地址（VA）压力：多 GPU + 多进程 + 大显存（HBM3e 上百 GB/卡），peer 映射 / IPC 映射数量随 rank 数平方增长，64 位 VA 空间也会被吃紧；
- 映射管理开销：每次分配/映射、IPC 句柄交换都需要 host 参与，且映射粒度粗、无法精细控制；
- 通信与计算分离：传统 NCCL 集合通信是独立的 kernel/库调用，难以在自定义内核内部直接"算完就发"，计算-通信重叠依赖库层调度。
1.2 硬件前提：NVLink + NVSwitch + NVLink SHARP
- NVLink 是 NVIDIA 专为 AI 工厂打造的 scale-up 网络，第 4 代 NVSwitch（Hopper）开始内置 SHARP（Scalable Hierarchical Aggregation and Reduction Protocol）引擎 ，即 NVLink SHARP（NVLS）：GPU 可发出 multimem PTX load/store 指令访问多播地址，交换机在转发的同时完成数据复制与归约；
- Blackwell 延续并强化了该能力（multimem 指令、多播归约、fabric 指令集），CFT 正是建立在"fabric 指令 + logical endpoint"这套硬件抽象之上。
1.3 软件演进路线
传统 IPC / peer mapping（映射每个远端分配）
↓
NVLS / SymmetricMemory window（多播 + 交换机内归约，仍需 window 地址空间）
↓
NCCL Device API（ncclDevComm，内核内集合通信原语）
↓
CFT（transport-centric：logical endpoint + fabric 指令，内核直接 put/get/red/barrier）2. 核心原理
2.1 transport-centric 模型
CFT 的核心转变是从"内存映射为中心"到"传输为中心"：
| 维度 | 传统方式（映射为中心） | CFT（传输为中心） |
|---|---|---|
| 寻址 | 远端内存映射成本地 VA 指针 | 命名逻辑端点 (le_id, le_offset) |
| 数据移动 | load/store / 拷贝 | fabric 指令异步 put/get/red |
| 通信方 | host 编排 + kernel 参与 | 内核直接发起，无需 host 逐次介入 |
| 地址空间 | 每个远端分配占一份 VA | 不占本地 VA，压力大幅下降 |
| 模式 | 单播为主 | 单播 + 多播（multicast） |
2.2 三个关键抽象
- 对称内存窗口（Symmetric Memory Window）：参与通信的 rank 各自分配、大小一致、对齐一致的缓冲区，注册为 window 后，所有 rank 看到的是同一份"对称"地址布局------这是 CFT 寻址的基础；
- 逻辑端点（Logical Endpoint） ：CFT 数据移动操作都作用在"端点 ID + 端点内偏移"上。
(le_id, le_offset)是不透明对，由 NCCL 提供 host/device 两侧的查询 API，把(window, offset, peer)翻译成(le_id, le_offset)； - CFT Team：用 team（单播组 / 多播组）而不是 world rank 来寻址对端，支持构建层级化通信模式（flat / hierarchical）。
2.3 操作原语
| 操作 | 方向 | 说明 |
|---|---|---|
put / putMultimem |
本地 smem → 远端 | 异步写；multimem 为多播变体 |
get |
远端 → 本地 smem | 异步读 |
red / redMultimem |
本地 smem → 远端（归约） | 归约在 fabric 路径上完成（复用 SHARP 能力） |
pullRed |
多播端点 → 本地 smem | 拉取 + 归约，需 warp 级 coop |
barrier |
全 team | 跨 CFT team 的设备线程同步 |
putCounted / redCounted / waitCounted |
带计数器 | 去掉"数据 + fence + flag"模式，用用户管理的计数器做完成通知，降低同步延迟 |
- 归约操作类型：
Sum/And/Xor/Or/Min/Max（具体数据类型的支持以 CFT PTX 文档为准）； - 支持 unicast 与 multicast 两种端点；multicast 需在创建 device communicator 时请求
NCCL_CFT_MULTIMEM； - 完成与错误上报 ：
flush可返回错误报告（cudaFabricOpErrorStatusGet/Count解码），应用可据此检测、重试或改道失败的 fabric 传输。
2.4 与既有方案的关系
- vs NVLS（NVLink SHARP）：NVLS 是 NCCL 内基于 symmetric window + multimem PTX 的集合通信实现；CFT 更底层，直接暴露 logical endpoint 与设备端操作 API，可被 NVLS 以外的自定义内核使用；
- vs IPC / peer mapping：CFT 不需要远端内存映射进本地 VA，解决大规模多 GPU 的 VA 压力；
- vs NVSHMEM：NVSHMEM 是更上层的 PGAS 编程模型；CFT 是其可依赖的更底层传输原语（NCCL 2.31.2 已提供 nccl4rust / NIIN 等 NVSHMEM 兼容接口，构建在 Device API 原语之上）。
3. 如何实现（API 流程）
3.1 前置条件
- 硬件：Blackwell 或更新（SM_100+），所有参与 rank 都能创建兼容的 CUDA fabric logical endpoints；
- 软件：CUDA Toolkit 13.3+（编译 fabric PTX 指令）、驱动 ≥ 610.43.02、NCCL 2.31+；
- 内核必须为支持 fabric 指令的架构编译。
关键约束：如果某个 communicator 上并非所有 rank 都支持 CFT，
ncclDevCommCreate()直接失败（全有或全无）。
3.2 Host 端设置流程
c
// 1) 分配并注册对称内存窗口
ncclMemAlloc(&buffer, memSize);
ncclCommWindowRegister(comm, buffer, memSize, &win,
NCCL_WIN_COLL_SYMMETRIC); // 可加 NCCL_WIN_CFT_COUNTED
// 2) 创建带 CFT 能力的 device communicator
ncclDevComm devComm;
ncclDevCommRequirements reqs = NCCL_DEV_COMM_REQUIREMENTS_INITIALIZER;
reqs.cftCaps = NCCL_CFT | NCCL_CFT_MULTIMEM; // 单播 + 多播
reqs.cftBarrierCount = nCTAs; // barrier slot 数（每 CTA 一个）
NCCLCHECK(ncclDevCommCreate(comm, &reqs, &devComm));3.3 Team 与 Endpoint 查询
c
// device 侧：取单播 CFT team，并按模式过滤（FLAT / HIER_MULTIMEM / HIER_LSA）
ncclTeam cftTeam = ncclTeamCft(devComm, NCCL_CFT_TEAM_FLAT);
// 把 (window, offset, peer) 翻译成逻辑端点
ncclCftLeId leId; size_t leOffset;
ncclGetCftLeInfo(win, byteOffset, peerCft, cftTeam, devComm, &leId, &leOffset);host 侧对应：ncclGetCftDeviceLeInfo() / ncclGetPeerDeviceLeInfo() / ncclGetMultimemDeviceLeInfo()；若需在创建 CFT device communicator 之前 查询端点，可在初始化 communicator 时配置 hostCftMode。
3.4 内核内操作：典型 put 流程
stage 数据到共享内存 (smem, 16B 对齐)
→ 构造 ncclCft<ncclCoopCta> 对象（共享 ncclCftSmem 状态）
→ cft.put(coop, leId, leOffset, smem, bytes)
→ cft.submit(coop) // 提交，使操作开始推进
→ cft.flushSmem(coop) // 等待 smem 被消费后可复用（更早的回收点）
→ cft.flush(coop) // 等待所有操作完成（含错误报告）
cuda
__global__ void cftPutKernel(ncclDevComm devComm, ncclWindow_t win) {
__shared__ ncclCftSmem cftSmem;
__shared__ alignas(16) char smem[128];
ncclCoopCta coop;
ncclCft<ncclCoopCta> cft{coop, cftSmem};
ncclTeam cftTeam = ncclTeamCft(devComm);
int peer = (cftTeam.rank + 1) % cftTeam.nRanks;
ncclCftLeId leId; size_t leOffset;
ncclGetCftLeInfo(win, 0, peer, cftTeam, devComm, &leId, &leOffset);
cft.put(coop, leId, leOffset, smem, sizeof(smem));
cft.submit(coop);
cft.flush(coop);
}3.5 Barrier
cuda
__global__ void cftBarrierKernel(ncclDevComm devComm) {
ncclCoopCta coop;
ncclCftBarrierSession<ncclCoopCta> bar{coop, devComm, blockIdx.x};
bar.sync(coop, cuda::memory_order_acq_rel,
ncclMemProxyType::Generic, ncclMemProxyType::Fabric);
}多播 barrier 需在创建 communicator 时带 NCCL_CFT_MULTIMEM 并传 multimem=true。
3.6 Counted 操作（延迟优化）
Counted 操作把传统的"数据 + 内存 fence + flag 更新"同步模式替换为用户管理的计数器：
- 窗口用
NCCL_WIN_CFT_COUNTED注册，计数器的更新被硬件保证排在数据落盘之后； - 发送方：
cft.putCounted(coop, leId, dataOffset, counterOffset, smem, bytes)； - 接收方：
cft.waitCounted(coop, acquire, Generic, counterPtr, expectedBytes, nullptr)，poll 计数器达到期望值即返回； waitCounted封装了协作线程同步、内存序、abort/timeout（目前 abort 传nullptr）。
3.7 内存序：Cross-proxy Fence
数据与 flag 之间需要建立 happens-before 关系时，使用跨 proxy 的 fence：
cuda
// 发送数据后，用 Fabric→Generic 的 release fence 保证 flag 在数据之后可见
ncclMemFence(coop, cuda::memory_order_release,
ncclMemProxyType::Fabric, ncclMemProxyType::Generic,
ncclMemFenceScope::Sys);
cft.put(coop, leId, leOffset + flagOffset, flag, 16);
cft.submit(coop); cft.flush(coop);另一个典型场景：Generic proxy 写入 smem 后，用 fence 让 Fabric proxy 可见再发起 put。
4. 已知问题与限制
| 类别 | 限制 |
|---|---|
| 硬件/软件门槛 | 仅 Blackwell（SM_100）+、CUDA 13.3+、驱动 ≥ 610.43.02、NCCL 2.31+；内核需为支持 fabric 指令的架构编译 |
| 全有或全无 | 任一 rank 不支持 CFT，ncclDevCommCreate() 即失败，无法降级 |
| 对齐/尺寸 | smem 源/目标必须 16B 对齐，传输字节数必须是 16 的倍数 |
| 中转要求 | 数据必须经共享内存中转（smemSource/smemDestination），不适合直接 global→global 的原生路径 |
| in-flight 上限 | 单个 ncclCftSmem 最多跟踪 16MB 非 fetching 操作（put/red 及多播变体）、1MB fetching 操作（get/pullRed） |
| counter 约束 | 每 GPU 并发活跃 counter ≤ 32 个为最佳性能，counter 建议 256B 对齐 |
| 同步易错 | submit / flushSmem / flush、cross-proxy fence、counted 的 memory order 全部需要手工正确编排，错误使用会导致数据竞争或悬挂 |
| barrier 配额 | cftBarrierCount 必须覆盖内核用到的全部 barrier index（通常每 CTA 一个） |
| 生态成熟度 | 新特性（2026 年随 CUDA 13.4 正式宣传），官方示例目前仅 barrier 示例，文档/工具链仍在完善 |
| 使用面 | 仅 Driver API、面向通信库作者；普通应用无直接收益，应走 NCCL/NVSHMEM |
| abort 支持 | waitCounted 的 abortFlag 目前需传 nullptr，无运行时中止路径 |
| 归约类型 | 受 CFT PTX 指令集约束（Sum/And/Xor/Or/Min/Max），类型覆盖以 PTX 文档为准 |
5. 生态与展望
- NCCL 2.31.2：新增 CFT host/device API，支持 window 内存注册到 CUDA logical endpoints，以及 device 侧 Put / Get / Red / NVLS 操作；
- PyTorch SymmetricMemory ：已把 CFT 作为底层传输之一------CFT 把 peer 的 window 注册内存暴露为
(le_id, le_offset)，自定义内核可直接用它发起 put/get/reduce，无需构造nccl内核； - CUDA Toolkit 13.4：正式把 CFT 列为新特性（与 locality domain、CDMM、Rubin 预览等并列），并明确"reports completion and error status so applications can detect, retry, or reroute failed fabric transfers"；
- 方向：CFT 是 NVIDIA"GPU 即网络端点"路线的底层基石之一，未来 Rubin（compute capability 107）与 NVLink 6 上，logical endpoint + fabric 指令这套抽象预计会成为 in-kernel 通信、计算-通信重叠、集合通信卸载的主要通道。
6. 参考链接
- NCCL Device API - CFT：https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/api/device_cft.html
- NCCL Usage - Compute Fabric Transport：https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/cft.html
- NCCL Release 2.31.2 Notes：https://docs.nvidia.com/deeplearning/nccl/release-notes/rel_2-31-2.html
- CUDA Toolkit 13.4 官方博客（CFT 章节）：https://developer.nvidia.com/blog/?p=121255
- NVIDIA NVLink: The Scale-Up Network for AI Factories：https://developer.nvidia.com/blog/nvidia-nvlink-the-scale-up-network-for-ai-factories/
- PyTorch Symmetric Memory（CFT 说明）：https://docs.pytorch.org/docs/main/symmetric_memory.html
- NVLS / NVLink SHARP 背景（TokenWeave，arXiv）：https://arxiv.org/html/2505.11329v1/
本文为技术分析文档，所有功能描述与版本信息以 NVIDIA 官方文档为准；未声明处不构成对 CFT 可用性、性能或兼容性的承诺。