1. UALink 多个 gpu 之间的 缓存一致性是靠软件维护UALink 1.0 在加速器之间跨 GPU、跨 System Node明确采用软件一致性而非硬件 snoop。规范原文的核心说法UALink_200 Rev 1.0 §1.5UALink不支持在加速器之间传输 snoop 事务来做硬件一致性。理由是 AI/ML 负载通常由大量加速器协同跑同一个 kernel同步点天然清晰在 kernel 边界清缓存就够了为少量场景引入 snoop 消息会显著增加链路/交换机的复杂度得不偿失。具体语义是 I/O 一致性模型从 peer 内存读会拿到该数据在目标 System Node 内最新的 coherent 副本写 peer 内存会使目标 System Node 内所有缓存副本失效部分写会先取回缓存数据合并再写回。注意失效范围止步于 System Node 边界Node 之间的一致性靠软件保证——即缓存了 peer 数据的加速器应当在合适的 kernel 边界清缓存clean/invalidate cache。加速器 ↔ Host 之间的硬件一致性也不归 UALink 管System Node 内部Host CPU 本节点加速器若要保持缓存一致走 PCIe/CXL/CHI C2C 等宿主侧互连实现UALink 规范不做规定可由实现者用硬件或软件方式处理。所以整体图景是范围一致性方式System Node 内Host ↔ 本节点 GPU硬件一致CXL.cache / CHI C2C / PCIe 等宿主侧互连非 UALink 规定UALink fabric 上 GPU ↔ GPU跨 Node软件一致性kernel 边界清 cacheUALink 提供 load/store/atomic 内存语义 地址转换支持这也是 UALink 与 NVLink/NVSwitch、AMD Infinity Fabric 的关键区别——后两者在域内提供硬件缓存一致性MESI 类协议代价是 snoop 流量和交换机复杂度UALink 选择用软件换简单和可扩展单域最多 1024 加速器。UML 主席 Kurtis Bowman 的说法是把硬件一致性塞进互连接口会导致性能下降软件一致性反而更高效。另外值得注意的是UALink 官方路线图已把内存一致性列为未来版本的功能即 1.0/2.0 目前是软件一致性后续版本可能引入更强的硬件一致性支持。2. 反驳nvlink/nvswitch 是硬件一致性的但是效率比 UALink 低么质疑是对的拆开说1. Bowman 说的是接口/硅片效率不是系统性能他的论点是把 snoop-based 一致性塞进互连接口端口逻辑、交换机会增加硅片面积、功耗和协议复杂度而对 AI 负载kernel 边界同步天然清晰没有回报。这是设计哲学层面的取舍论证不是实测结论。目前 UALink 1.0 刚有早期硬件落地根本不存在 NVLink vs UALink 在同负载下的对标数据UALink 效率更高无从谈起——而且恰恰相反现有证据NVL72 单柜 130 TB/s、AllReduce 近线性扩展表明 NVLink 系统在系统级效率上是目前的天花板。2. 更关键的一点NVLink 的硬件一致性其实用得很少和 UALink 的模型高度趋同NVIDIA 官方论坛的多次澄清指出NVLink 上 GPU↔GPU 的普通显存访问并不传播 MESI 类一致性消息managed memory 的一致性是靠按需数据迁移实现的任一时刻只有一个处理器持有数据GPU 间 P2P 访问的同步照样是程序员/运行时的责任NCCL 就是如何在 NVLink 上做显式同步数据传输的开源示范。 换句话说NVLink 上占绝对大头的 GPU-GPU 通信流量走的就是软件同步模型——和 UALink 一样。NVLink 真正的硬件一致性主要体现在NVLink-C2CGrace CPU ↔ GPU 片间共享统一一致地址空间以及 NVL72 把一致域扩到整柜 72 GPU——而这个域到机柜边界为止跨柜立刻跌回 50 GB/s 级 IB/Ethernet靠 NCCL 显式同步。 所以 NVIDIA 自己的多机扩展故事本质也是域内硬件一致、域间软件一致——只是它的域是 72 GPUUALink 的域概念是 1024 加速器的 Pod。3. 所以公平的结论是NVLink/NVSwitchUALinkGPU↔GPU 主流量软件同步NCCL一致域内靠地址映射软件同步kernel 边界清 cache硬件一致性范围NVLink-C2CCPU↔GPU、NVL72 整柜域System Node 内CXL/CHI C2C非 UALink 规定效率之争的实质已验证的系统级效率标杆Bowman 主张的是端口硅片/功耗/协议复杂度更省、扩展域更大1024属于理论取舍未经实测Bowman 那句话准确的读法是“为 AI 负载把硬件一致性做进交换 fabric 是得不偿失的复杂度”而不是NVLink 效率低。真正的取舍在于UALink 用软件一致性换来更大的一致寻址域Pod 级 1024 加速器统一 load/store 寻址无需像 NCCL 那样显式搬数和更简单的交换机代价是把同步责任推给编程模型。谁更优要看负载——对 kernel 边界清晰的训练/推理两者实际行为差别不大对细粒度共享、生产者-消费者异步并发这类场景硬件一致的域内编程会轻松得多。3. NVL72 整柜域 如何实现所谓 硬件一致性关键先强调一点NVL72 的硬件一致性不是像 CPU MESI 那样在 72 个 GPU 之间广播 snoop。它是以每个 GPU 的 L2 为一致性锚点 地址路由 fabric的架构机制可以拆成四层1. 全柜统一物理地址空间一致性成立的前提Fabric Manager 把 72 个 GPU 的 HBM 和 36 个 Grace CPU 的 LPDDR 配置成一个统一的 fabric 地址空间Blackwell 的 NVLink 地址空间达 4 PB每个物理地址在全局唯一映射到某个home 节点owner GPU 的 HBM。 这就是memory fabric的含义——交换的不是消息而是带全局物理地址的内存事务。2. 一致性锚点home GPU 的 L2而不是广播 snoopGPU 的 L2 cache 是物理地址寻址的且每个物理地址只有一个 home。任何 GPU包括跨 NVSwitch 的远端 GPU对 peer HBM 发 load/store/atomicNVSwitch 按地址路由到 home GPUhome GPU 的 L2 控制器作为该地址的唯一串行化点serialization point处理所有请求——远端读命中 home 的 L2 或透传到 HBM远端写由 home L2 更新/失效。因为所有对同一地址的访问都汇聚到同一个 L2天然保证一致fabric 上根本不需要传播 MESI 状态。学术界的归纳是NVLink 提供的是NVL 域内跨 GPU L2 的硬件一致性NVL72 是当前硬件一致性的规模上限。代价远端 HBM 访问延迟约 5–10 μs本地 HBM 100 ns但带宽保持 1.8 TB/s 级。3. NVSwitch 的 fabric 内加速分担 home 节点的活按地址路由的 non-blocking crossbar每 GPU 18 条 NVLink 分到 9 个 NVSwitch tray任意 GPU 对之间全带宽直达multicast一次写由交换机在 fabric 内复制到多个目的 GPU对 TP/AllReduce 的梯度广播是关键优化在 Hopper/Blackwell 上需配合 UVM 暴露给软件in-switch 计算SHARP 归约、Blackwell 起的 FP8/FP16 reduction 直接在交换机内做减少 all-reduce 的数据搬动fabric 内同步NVLink barrier 等多播同步原语配合 atomic 完成跨 GPU 的硬件级同步。软件侧通过 PTX 的 multimem 地址把 multicast 区域映射成特殊地址GPU kernel 直接对多内存地址发操作看起来像普通内存操作实际由交换机完成分发/归约。4. CPU 侧一致性NVLink-C2C 走 AMBA CHI每个 compute tray 内 Grace CPU ↔ 2 个 Blackwell GPU 用 NVLink-C2C900 GB/s这条链路承载的是 ARM 的AMBA CHI 一致性协议所以 CPU 能以硬件一致的方式直接读写 GPU HBM、GPU 也能读 LPDDR无需页迁移。 跨 tray 的 CPU-GPU 一致性则延伸过 NVSwitch fabric由同一套统一地址 home L2机制支撑。总结成一句话NVL72 的硬件一致性 全局统一地址空间谁拥有哪个地址由 fabric 静态配置home GPU L2 作为每个地址的唯一串行化点替代 snoop 广播NVSwitch 的 multicast/原子/归约 offloadC2C 上的 CHI 处理 CPU 侧。它本质是 NUMA 化的共享内存机器一致性边界由地址的 home 归属硬件保证所以 72 GPU 对软件呈现为一个 load/store 一致的域而这个域跨出机柜IB/Ethernet后机制无法跟随立刻退回软件同步。4. home GPU 的 L2 控制器作为该地址的唯一串行化点的实现NVSwitch 按地址路由到 home GPUhome GPU 的 L2 控制器作为该地址的唯一串行化点serialization point处理所有请求NV 是如何做到的呢这套机制 NVIDIA 并没有公开完整协议细节但把公开资料Hot Chips 演讲稿、NVIDIA 白皮书、Stanford 的实测逆向拼起来链条是这样的第 0 步先由软件把地图画好Fabric Manager一致性不是交换机上跑出来的动态协议而是开机时静态配置出来的。Fabric Manager 在 fabric 初始化阶段完成三件事给 72 个 GPU 的 HBM和 36 个 Grace 的 LPDDR在统一 NVLink 地址空间里分配地址段、确定每个地址段的 home GPU把路由表写进每个 NVSwitch把多播组、SHARP 组、隔离分区partitioning配置好。 Hot Chips 的 NVSwitch 框图里专门有 Security Processor 保护这些芯片配置不被篡改。之后 fabric 上的所有事务都是带物理地址的内存请求连接在运行期由硬件维持不需要像 NVLink Network跨节点 OSFP 电缆那种那样靠运行时 API 建连。第 1 步发起方 GPU——地址译码决定走本地还是走 fabricSM 发出 load/store 后请求沿 GPU 内存流水线crossbar走到地址译码逻辑。每个 GPU 内存控制器里有一张 fabric 地址解码表由 Fabric Manager 写入落在本 GPU HBM 地址段的 → 交给本地 L2 slice 哈希定位物理地址哈希到 64/96 个 L2 slice 之一落在 peer 段的 → 直接转到 NVLink 出站端口。关键细节远端地址的请求不会在本 GPU 的 L1/L2 里分配缓存行——Stanford 对数据路径的实测确认 peer data never cached in the local L2每次远端访问都完整走源 L2仅作传输管道→ NVLink → 目的 GPU。 NVLink 端口把请求封装成内存语义事务包地址 命令类型 长度用 credit 流控发到 SerDes。第 2 步NVSwitch——按地址查表的单跳 cut-through 交换GB200 NVL72 里是 18 颗 NVSwitch 4.0 芯片9 个 tray × 2每颗 72 个 200 GB/s 端口、14.4 TB/s每个 GPU 的 18 条 NVLink 恰好一条接到一颗 switch——所以是单跳、无阻塞拓扑任意 GPU 对之间只过一颗交换机。 交换芯片内部就是一张地址路由表 cut-through crossbar收到包后查地址段 → 出端口直通转发。同一地址段永远路由到同一个 home GPU 的端口——路由表本身就把同一地址的请求汇聚到同一节点这件事硬件化了这是唯一串行化点能在物理上成立的前提。交换机上还有三块为一致性/集合通信服务的硅multicast 复制引擎一次写入由交换机在 fabric 内复制到组内所有 GPU“NVSwitch-internal duplication of data”不用源 GPU 发 N 份SHARP 归约 ALUALU 与 Hopper 运算单元对齐支持 add/min/max/logical格式覆盖 FP16/32/64、BF16、整型最多 128 个 SHARP 组并行——AllReduce 时各 GPU 只发 1/N 部分和交换机归约后回发结果省一半 fabric 流量遥测/分区和安全处理器前面已述。第 3 步home GPU——把 fabric 请求混进本地内存流水线这是最核心也最不为人知的一步从 NVLink 端口进来的远端请求并不走一条特殊路径而是被注入 home GPU 与 SM 请求相同的内存流水线入口然后和本地请求一样做地址哈希、定位到唯一那个 L2 slice。L2 slice 控制器是物理地址的 owner它有 per-line 的状态和仲裁逻辑无论请求来自本 GPU 的 SM 还是 71 个远端 GPU 中的任何一个对同一 cache line 的请求都排队由它顺序处理——hit 则回数据miss 则发 HBM 读write 则更新行并置脏atomic 由 L2 内的原子单元就地执行。 返回数据封装成响应包沿原路交换机的路由表同样对响应生效回到请求方。为什么这样就够了——因为没有第二份副本传统 MESI 需要 snoop是因为同一数据可能同时存在于多个 cache 里。这里三个设计把多副本从源头消灭了①远端请求在请求方不分配缓存行第 1 步②每个物理地址有唯一 home所有请求物理上汇聚到同一 L2 slice第 2、3 步③对共享数据的一对多流量由交换机多播而非各点缓存SHARP 更进一步连多份数据都不传。协议上因此只需要 request/response 两种包没有 Probe/Invalidate 广播。Hot Chips 材料里 NVLink 域的地址空间就是1 (shared)模式请求直接用 GPU 物理地址寻址。两个必要的澄清这套硬件一致性的边界是L2远端一致性由 home L2 保证但 GPU 自己的 L1 对全局内存本来就不是一致的CUDA 内存模型如此kernel 内跨 SM 同步仍要靠 fence/atomic——这一点在 NVL72 里没有变。CPU 侧是另一条路径Grace 的 NVLink-C2C 承载 AMBA CHIGrace 内部的一致性引擎目录在 CPU 侧负责让 CPU cache 和 GPU HBM 互相一致跨 tray 的 CPU→远端 GPU 访问则仍走第 2、3 步的 fabric 机制。总结NVIDIA 的做法不是发明了一种新一致性协议而是修改了系统的三个交通规则——请求方不许缓存远端数据、交换机按静态表把地址钉死在 home GPU、home GPU 用本来就有的 L2 slice 仲裁器顺带把远端请求排队。一致性是这三个硬件约束的副产品协议反而比 MESI 更简单。这也是为什么它端到端可控但离不开 NVIDIA 全家桶解码表、路由表、L2 行为、交换机语义必须同一家设计换任何一环天然一致就漏了。5. UALink 缓存一致性的实现及其与nvlink性能的对比先纠正一下前提因为其中有一半对、一半需要精确化——这个区别正是答案的关键。前提修正NVLink 侧准确说不是这部分显存被取消了 L1而是对远端地址的访问不在请求方 GPU 的 L1/L2 分配缓存行——数据路径上本 GPU 自己的显存照常过 L1/L2但 peer 显存进来的数据物理上不会被缓存Stanford 实测确认 peer data never cached in local L2。所以确实请求方无副本主机内 GPU 之间的 L1 一致性问题不存在。UALink 侧必须在主机内维护 L1 硬件一致性这个推断其实过头了。UALink 规范承诺的是目标 System Node 内的 I/O 一致性读拿到节点内最新副本、写使节点内缓存副本失效它并没有要求主机内各 GPU 的 L1 互相 snoop。请求方 GPU 如果缓存了 peer 数据软件在 kernel 边界清——这正是我们第一轮说的软件一致性。那么在 UALink 类主机里目标节点内一致具体怎么做到靠拼三种已有机制而不是发明新协议home GPU 的 L2 做串行化点与 NVL72 相同的一招fabric 写入请求到达目标 GPU 后注入它的内存流水线由该地址哈希到的 L2 slice 失效/更新缓存行。L2 天然一致GPU 的 L1 对全局内存本来就不跨 SM 一致CUDA 内存模型如此跨 kernel 的 L1 陈旧由 GPU 自身的 fence/启动边界语义处理不需要 UALink 操心。host CPU 的 cache 走标准 DMA 一致性入向写以 PCIe/CXL 事务进入主机一致性域由 PCIe/CXL 的 snoop 机制或 C2C 上的 CHI失效 CPU 侧缓存副本。这是主机 fabric 的既有能力UALink 只是借用。设备 cache 参与 host snoop可选、实现相关规范把 System Node 内一致性列为实现者的事CXL/PCIe/CHI C2C硬件或软件皆可。APU 形态如 MI300A 那种 CPUGPU 单封装、片上一致互连可以做到全硬件纯 PCIe 插卡形态的 GPU 做不到就退回软件边界。所以两家的 home 侧机制殊途同归真正的分野只在请求方NVLink 禁止缓存远端行协议最简、每次访问全付 fabric 延迟UALink 允许缓存换重复访问的本地命中代价是 kernel 边界 flush。性能与计算能力对比先给结论一致性模型的选择本身对 FLOPS 没有任何影响它影响的是通信效率和编程负担而今天的实测差距主要来自别处。维度GB200/GB300 NVL72NVLink 5HeliosMI455XUALink/UALoE单 GPU scale-up 带宽1.8 TB/s 双向AMD 宣称 3.6 TB/s对标 Vera Rubin 的 NVLink 6 水平机柜聚合带宽~130 TB/s宣称 260 TB/s一致性开销硬件零软件负担但重复远端读浪费 fabric 带宽软件 flush允许本地缓存复用网内计算SHARP 归约、multicast、NVLS硅片成熟UALink 1.0 无In-Network Compute 是后续版本加入的交换芯片自研 NVSwitch私有博通 Tomahawk 6 外采开放、便宜但属过渡性 UALoE出货状态2026 年 7 月起量产交付H2 2026 起小批量爬坡量产生要 2027具体影响分负载看训练以 AllReduce/AllToAll 为主同步点本来就落在 kernel 边界UALink 的软件 flush 摊进去几乎零额外成本。此时一致性模型打平差距在别处NVLink 的 SHARP 网内归约能省一半集合通信流量multicast 直接硬件复制——这是 NVIDIA 多年迭代的硅片红利UALink 1.0 没有这些 offloadHelios 初期要用交换机做透明转发集合通信得走 GPU 软件路径。这就是为什么分析师的评价是Helios 纸面规格漂亮但尚未证明其开放 fabric 在关键负载上能匹配 NVLink要等拓扑、跳数、bisection、collective offload 数据披露。推理/细粒度共享EP 热专家、KV 跨 GPU 复用这是 UALink允许缓存 peer 数据理论上占优的场景——重复读共享数据可命中本地 L2省 fabric 流量。但这只是理论选项实际上今天的推理栈也是显式拷贝/RDMA 服务这类访问且这方面的胜负手同样被网内计算和软件栈成熟度盖过。延迟UALink 规范目标是 cable 4m、Req-to-Resp RTT 1μs与 NVLink 同量级但 Helios 首代用的是 UALinkover EthernetUALoE过渡方案以太网 PHY 的延迟和确定性有固有代价Tom’s Hardware 直接以以太网的缺点可能拖累性能为题报道。厂商宣称 vs 实测AMD 宣称 Helios 对 Vera Rubin NVL72 有 15% 更多 FP4 算力、50% 更多 HBM 容量、30% 更高 tokens/$——但均为 AMD 自家建模数字双方口径还故意不对齐dense vs sparse。截至 2026 年 8 月Rubin NVL72 已量产发货而 Helios 仍是参考设计状态第三方同负载 benchmark 预计 2027 年才出现。总结在 home 侧UALink 类主机靠home GPU 的 L2 串行化 PCIe/CXL 对 CPU cache 的标准 snoop 可选的 C2C 硬件一致拼出目标节点内一致性与 NVLink 机制同源分歧仅在请求方缓存策略而这个分歧对当前负载训练的性能影响远小于网内计算 offload 和软件栈成熟度——目前这两项都是 NVIDIA 的存量优势UALink 阵营的胜负手在开放供应链和 1024 加速器的扩展域需要用 2027 年的实测来证明。6. fabric 内同步NVLink barrier 等多播同步原语配合 atomic 完成跨 GPU 的硬件级同步。这块是 Blackwell 代际里最被低估的改动之一。先给全景再拆机制。为什么需要 fabric 内同步NVL72 出现之前跨 GPU 同步的标准做法只有一个回软件。数据靠 NVLink/RDMA 传完然后每个 GPU 的 kernel 结束 → CUDA event 流同步 → host 端 barrier → 再发下一个 kernel。一次跨 GPU 握手走下来是~10μs 级的延迟而且 CPU 全程参与调度。但 NVL72 的卖点是72 卡一个一致性域、kernel 内直接访问 peer 显存。如果你好不容易做到了 kernel 内 load/store 直达对端 HBM结果每次同步还要退出 kernel 让 CPU 仲裁——fabric 的低延迟优势就被同步开销吃掉了。所以 Blackwell 把同步本身也下沉到了 fabric 里目标是把跨 GPU 的握手压到~1μs 以内并且不占 CPU。三层机制从轻到重第一层multicast 写 本地轮询纯数据面技巧Hopper 就有这是 NCCL NVLSNVLink SHARP路径的基础。机制是利用 multicast 地址的一个不对称特性写 multimem 地址交换机把这次写复制到组内所有GPU 的物理显存——一次写N 份落地读 multimem 地址读的是本 GPU 自己的那一份读不聚合。于是软件 barrier 可以这样做组内每个 GPU 往同一个 multicast 地址写一个我已到达标志 → 交换机复制到所有人 → 每个 GPU 轮询自己本地的那份副本本地 HBM 读亚微秒直到凑齐 N 个到达位 → 放行。巧妙的点在于轮询不发生在远端显存上而是发生在被 multicast 复制过来的本地副本上把跨 fabric 的反复轮询变成了本地读。NCCL 里 NVLS 的 barrier 和 AllReduce 同步段就是这么实现的。第二层sys-scope atomicNVSwitch 内的原子单元CUDA 内存模型的 scope 体系里.sys层级的原子操作atom.add.sys、red.release.sys等语义上要对整个系统可见——在 NVL72 里就是整个 rack 的 fabric。Blackwell 的 NVSwitch 里有专门的原子执行单元sys-scope atomic 不会在 home GPU 的 L2 里做读-改-写而是在交换机上就地执行请求上到 switchALU 改完计数器直接返回少一次到对端 HBM 的往返。这层解决的是跨 GPU 的信号量/计数器问题生产者 GPU 发完数据后执行一条red.release.sysrelease 语义保证数据写在 flag 之前完成并全局可见消费者 GPU 对同一地址ld.acquire.sys或 atomic 读拿到最新值就知道数据到了。atomic 的落地位置switch 而非远端 L2把一次跨 GPU 信号从两次 NVLink 往返 L2 访问压成一次到 switch 的往返。DeepEP、NVSHMEM 这类 kernel 内通信栈的 dispatch/combine 同步本质上就是大量复用这一层buffer 指针交换走 atomic数据面走普通 store/load配fence.sys保证顺序。第三层NVLink barrierBlackwell 新增的硬件 barrier 原语前两层都是用内存语义拼出来的同步Blackwell 则把 barrier 做成了 fabric 的一等公民指令每个 GPU 执行 barrier arrive 指令产生一个 arrive 消息带 barrier ID发给所连的 NVSwitchswitch 内的 barrier 状态机跟踪该 barrier 的到达计数凑齐组成员数后向组内所有 GPU 广播 release等待侧的 warp 挂起在 barrier wait 上收到 release 后由硬件唤醒继续执行。对比第一层的软件 multicast barrier软件方案要写标志 → 复制 → 本地轮询 N 次是多个内存事务的序列硬件 barrier 是交换机里一个计数器 一次组播延迟和 fabric 往返同量级而且不占显存带宽、不需要本地轮询循环。DeepGEMM 的 SM100 kernel 和 NCCL 的新传输层都在用这一层做 grid 级/跨 GPU 的 barrier。配置方式与 multicast/SHARP 组同构Fabric Manager 初始化时定义 barrier 组哪些 GPU 参加、组内计数运行期 kernel 内直接按 ID 使用。三层如何配合一个典型的跨 GPU 生产者-消费者以 MoE 的 EP dispatch 为例一次完整的跨 GPU 握手是这样的生产者 GPU 的 TMA/SM 把 token 数据store 到消费者 GPU 的显存远端写经 NVSwitch 路由home L2 落地数据写完后生产者对消费者显存里的计数器发一条red.release.sys——release 语义保证第 1 步的所有写在此 atomic 之前全局可见atomic 在 switch 内执行计数器 1消费者的 SM 轮询自己显存里的计数器本地读或直接被 NVLink barrier 的 release 唤醒凑齐后消费者开始读数据——读的时候对源数据地址用ld.acquire.sys或直接普通读因为一致性由 home L2 保证。如果是 AllReduce 这类集合操作还要叠加 SHARP各 GPU 把部分和作为multicast atomic add发出switch 内的 SHARP ALU 做归约结果 multicast 回所有成员——数据只上 fabric 一次NVLS 把 AllReduce 流量减半的关键。效果同步从边界事件变成流水线节拍这套机制的实际意义可以用一个数字概括软件路径的跨 GPU 同步kernel 退出 host barrier kernel 重入是10μs 级三层 fabric 内同步把单次握手压到1μs 上下于是跨 GPU 依赖第一次可以作为流水线内部节拍来使用而不是只能放在 kernel 边界——EP/TP 的通信-计算重叠不再靠多 stream 冒险producer 发完 64KB tile 就 arrive barrierconsumer 的下一个 warp 已经在等细到 tile 粒度的流水Prefill/Decode 分离PD 分离prefill 节点把 KV 块写完 releasedecode 节点 acquire 后直接读免去了 host 端的事件链X-Stage 这类 DiT 工作负载里测到用远端 store fabric barrier 替代本地 stage单步延迟的通信占比能压到可忽略。一个值得注意的演进方向本节起初引用的这句其实还停在 Blackwell 的描述。RubinNVLink 6在这个方向上又进了一步counted writes——接收侧维护一个写入字节计数器发送侧发完数据后不再需要 memory barrier atomic flag 两步接收侧看到计数达标即知数据完整把同步从独立的消息进一步折叠进数据流本身。NVIDIA 披露这一点时的定位很直白Blackwell 上跨 GPU 传输需要 store fence atomic 三步协调Rubin 将其收敛为接收侧一次计数器更新。这说明 fabric 内同步不是一次性的 feature而是 NVIDIA 明确在逐代削减的 tax——每一代都在问跨 GPU 确认一次数据就绪最少需要几个消息从软件 barrier 的十几个消息到 multicast flag 的几个到 NVLink barrier 的两个arrive/release再到 counted writes 的数据面捎带——这条收敛曲线本身就是 rack-scale 架构竞争的主线之一。7. nvlink 协议简单么User: 听上去nvswitch 背后的协议并不复杂Kimi: 对一半。简单的是一致性协议的状态空间难的全在别处。这其实是理解 NVL72 设计哲学最好的一扇窗确实简单的部分对比 CXL.cache要定义 agent 间几十种消息、行状态机、deadlock 规避几千页规格NVLink fabric 的语义薄得像一张餐巾纸读、写、原子request/response按地址查表路由。没有 snoop、没有目录、没有 MESI。这份简单不是没能力做复杂而是主动用架构约束把复杂性消灭了——禁止请求方缓存远端行等于把一致性问题的定义本身删掉了。但复杂性守恒只是搬了家1. 物理层这可能是全球最难做的数字芯片之一。每颗 NVSwitch 是 72 端口 × 200 Gb/s 14.4 TB/s 的 cut-through crossbar。 224G PAM4 SerDes 在背板上的信号完整性、72 路同时满速仲裁不阻塞、cut-through 延迟——这颗芯片的面积、功耗、封装难度不亚于 GPU 本身。协议简单≠硅片简单。2. 排序multicast 和点对点混在一起时的正确性。fabric 里同时存在三类流量点对点读写、multicast 复制、barrier 释放。硬性规则是barrier 的 release 绝不能越过之前的数据写到达。这要求交换机在支持 fan-out一份数据复制 N 份、各走不同出端口的同时维持 per-address 的顺序保证又不能让所有流量被 fan-out 堵住head-of-line blocking——虚通道分配、多播排序树每个都是交换机里的实打实的硬件逻辑。3. 无损与错误处理。整个 fabric 是无损的credit 流控但 flit 可能在 9 个 tray 的路径上任一段出错。CRC 检出后要做端到端重传而重传必须不破坏排序语义——“简单协议配上必须绝对可靠”组合起来就不简单了。还要加 ECC、链路降级、RAS 遥测。4. 网内计算的正确性是被低估的硬骨头。SHARP 在交换机里做浮点归约浮点加法不可结合——abc ≠ abc。要保证 72 卡 allreduce 的结果 bit 级确定、且与 software reduce 语义对齐交换机内归约的顺序必须是固定的、可复现的这在并行 fan-in 流上很伤脑筋。同理交换机上执行的原子操作要和 home L2 对同一地址的串行化关系自洽。5. 系统管理层的软件复杂度。Fabric Manager 要在开机时给 72 GPU × 多实例计算切片分配地址段、生成路由表、配好多播组/SHARP 组/barrier 组、做分区隔离把 72 口切成多个独立 NVLink 网络和安全策略NVSwitch 里那颗安全处理器就是干这个的。 GPU 故障时的 fabric 重映射、固件升级、机密计算模式下的隔离——这些没有一项简单只是它们不算协议。简单的另一份代价协议简单还依赖一个前提GPU 的内存流水线把入向 fabric 请求当成一等公民处理注入本地 L2 仲裁且 Fabric Manager、NVSwitch、GPU、驱动全部同一家设计。这个简单是端到端私有才能维持的简单——把其中任何一环换成第三方简单协议立刻漏出无数个未定义行为。侧面证据如果这套东西真的简单UALink 阵营不会到今天还在用交换机做透明转发 GPU 软件做集合通信的过渡方案——带多播复制、网内归约、fabric barrier 的原生 UALink 交换芯片Astera Labs 等要到 2026 年底以后才出现。NVIDIA 自己从第一颗 NVSwitch2018 年 DGX-2到 NVL72 的单跳 72 口 fabric也迭代了三代芯片、用了七年。一句话总结NVLink fabric 是簿记极简、物理极难——它把 MESI 那种状态机复杂度换成了 14 TB/s 无损有序交换机的工程复杂度。前者难在正确性证明后者难在硅片和系统工程而对一家同时握着 GPU、交换芯片、封装和软件的垂直整合公司来说后者恰好是它最擅长、别人最没法跟的战场。