尧图网页设计 
1. 如何构成单个设备先明确「构成单个设备」到底需要什么两个 die 对软件呈现为一个GPU需要同时满足四个条件统一物理地址空间——两个 die 的 HBM 编进同一张地址地图对称的硬件缓存一致性——die A 的 L2 能 snoop die B 的 L2cacheline 粒度双方地位对等细粒度地址交织——地址按 256B/2KB 之类的粒度打散到两边 HBM带宽和容量透明地翻倍调度器不用感知 NUMA单次枚举——对主机只暴露一个 PCIe function、一组 BAR、一个命令队列。注意 UCIe 在这里只是「公路」——UCIe 规范本身就支持承载 CHI、CXL、PCIe 或私有 streaming 协议。**决定能不能拼成一个设备的是公路上跑的协议的一致性模型不是物理层。**所以「UCIe CXL」物理上完全合法问题在于 CXL 的协议语义做不到上面第 2、3 条。CHI-C2C 为什么可以它是「片内 fabric 的延伸」CHI 本来就是片上一致性总线协议Arm CMN mesh 跑的就是它CHI-C2C 做的事情本质上是把同一个一致性 mesh 拉过 die 边界两个 die 上的 RN-F全一致性请求节点比如计算簇 L2 slice和 HN-Fhome 节点带 snoop filter/目录在同一个一致性域里协议层只是多了 C2C 打包/解包一跳跨 die 访问对协议来说和片内跨 mesh 一跳没有区别——延迟是几十纳秒量级与本地 L2 未命中同数量级CHI 原生支持 HN-F 哈希交织地址按 cacheline 倍数粒度散到两个 die 的 HBM 控制器上带宽池化对软件完全透明支持完整的一致性操作集snoop、Direct Cache Transfer、原子操作、cache maintenance——两个 die 的缓存是对等公民。于是 die 边界被移到了「设备边界之内」主机看到的永远是封装外面的那一个 PCIe 端点。这和 NVIDIA 用 NV-HBI 合并两个 Blackwell die、AMD 用 Infinity Fabric 拼 MI300 是同一种架构范式——都是用原生 fabric 一致性协议跨 die只是 Arm 把它标准化了。CXL 为什么不行它是「主机中心的外设一致性」CXL 的一致性模型从设计第一天起就是非对称的这跟它要解决的问题主机 CPU 和外挂内存/加速器之间的池化匹配但和「合并两个对等 die」恰好相反1. 一致性主从结构CXL 1.1/2.0 里主机是唯一的一致性管理者CXL.cache 允许设备缓存主机的内存由主机反向 snoop 设备CXL.mem 允许主机访问设备内存——但设备自己的内存对其他设备不一致两个设备之间根本不能互相 snoop。两台 GPU 用 CXL 连起来A 永远看不到 B 缓存里改过的 cacheline。第 2 条直接不满足。2. 延迟量级错了CXL 是面向 PCIe 级链路设计的跨链访问延迟在数百纳秒量级。而「两个 die 一个设备」要求跨 die 的 L2 访问和本地 L2 未命中相当几十纳秒否则每次跨 die 命中都比本地慢一个数量级两个 die 实际上成了两个 NUMA 节点——GPU 的编程模型和驱动根本没有「设备内 NUMA」这个概念性能扩展性会崩掉「单设备幻象」不攻自破。3. 没有对等设备间交织和合并语义两个 CXL 设备在主机的设备树里就是两个设备两次枚举、两组 BAR。CXL 3.0 确实补了不少东西——fabric、P2P、back-invalidation设备内存可以被一致性共享、多级交换——但它的方向是「多个主机/设备共享池化内存」一致性依然由主机或 fabric 目录居中仲裁粒度是内存池和页不是两个对等 L2 之间的 cacheline 级对称 snoop。它提供的是「设备间共享」不是「设备内合并」。总结UCIe CHI-C2CUCIe CXL协议定位片上 fabric 跨 die 延伸主机↔设备的 I/O 一致性接口一致性结构对称多 RN-F/HN-F 同域非对称主机为一致性主节点设备间互相 snoop原生支持1.1/2.0 不支持3.0 经主机/fabric 目录中转跨 die 延迟~几十 ns与片内同量级~数百 ns细粒度地址交织HN-F 哈希透明无设备级/页级软件可见对主机呈现一个设备die 边界在封装内两个设备需软件虚拟化才像一个CHI-C2C 把 die 边界藏在设备边界里面CXL 本身就是一条设备边界。用 CXL 拼两个 die得到的永远是「两台通过一致性网络相连的加速器」要得到「一台加速器」必须用本来就是设备内部语言的一致性 fabric 协议——CHI、Infinity Fabric、NV-HBI 都是这个角色CXL 的角色在封装外面。2. UCIeC2C 与 NV-HBI 速率对比先把两个数字的口径摆清楚这两个数字其实不在同一个度量维度上直接对比会产生错觉UCIe 标称的是「每通道速率」UCIe 2.0 最高 32 GT/s per lane2025 年发布的 UCIe 3.0 通过 QDR 信令做到 48/64 GT/s。CHI-C2C 本身不定义物理层速率——它是 Arm 在 2024 年发布的片间一致性协议只定义协议层和打包层跑在 UCIe 的 streaming 协议之上容器格式兼容 UCIe 256 字节延迟优化模式。NV-HBI 的 10 TB/s 是「整个 die 边缘的聚合带宽」Blackwell 两颗 reticle 极限 die 之间通过定制、低功耗的 NV-HBI 互连共享 L2、保持完全一致对外表现为单一 CUDA GPU。NVIDIA 未公开其 SerDes 速率和链路数业界推断是宽并行总线加一致性协议引擎的实现。换句话说一个是「一根线跑多快」另一个是「一整排上万根线加起来多少」。如果换算成可比的带宽密度TB/s per mm beachfront商用 UCIe PHY IP 在 64 Gbps 下已能做到约 21 Tbps/mm和 NV-HBI 推算的密度在同一量级——差距远没有 32 Gbps vs 10 TB/s 看起来那么夸张。真正的差距来源1. 封装层级不同最根本NV-HBI 跑在 2.5D 硅桥/中介层上Blackwell 采用台积电先进封装die 边到边距离只有毫米级可以用极小的 bump 间距、极短的走线、很低的电压摆幅。UCIe 作为标准必须同时兼容有机基板的标准封装bump 间距大、走线长、损耗高和先进封装两种场景速率和密度只能取保守值以保证互操作和良率。2. 开放标准 vs 私有垂直整合NVIDIA 自己控制 die 设计、协议、封装和拓扑永远是两颗同构 die 合并 L2PHY 可以针对这个唯一场景做极致裁剪。UCIe 要跨厂商、跨工艺互操作必须带训练、校准、sideband 管理、CRC/retry 等通用性机制。事实上 NVIDIA 虽在 UCIe 董事会但自家创收产品用的就是私有接口。3. 协议开销CHI-C2C 是通用一致性协议在 CHI 的 REQ/RSP/DAT/SNP 四通道外增加了 MISC 通道做初始化和 credit 流控还要做片上 CHI 到片间格式的协议转换和定长容器打包。这些开销换来的是任意 Arm 生态 chiplet 的互操作能力——CHI-C2C 面向多芯片 SMP 和一致性加速器挂载等开放拓扑。NV-HBI 只需服务一种固定拓扑协议和物理层可以联合优化。4. 能耗预算的再分配die-to-die 的真正货币是 pJ/bit。超短距让 NV-HBI 每比特能耗压得很低省下的功耗预算全部用来堆并行线数——「不以单线速率取胜而以规模取胜」。总结差距的大头是统计口径单通道 vs 整排聚合和封装代际有机基板兼容 vs 2.5D 硅桥专用剩下的是开放标准的通用性税。如果 UCIe 3.0 也部署在同等级别的先进封装上、按同样宽度聚合带宽密度可以接近 NV-HBI 的水平——你付给标准的溢价换来的是跨厂商互操作的生态NVIDIA 放弃的正是这一点。3. 问题量化先把两边的「官方数字」钉死NV-HBI一颗 Blackwell GPU 内部两个 die 之间的整条链路10 TB/s 双向总量约 5 TB/s 单向两颗 reticle 极限 die 之间通过 CoWoS-L 硅桥边对边互连NVIDIA 从未公开过 per-pin 速率、线数和协议开销业界只能推断是「宽并行总线 一致性引擎」的实现。UCIeCHI-C2C 没有自己的速率它跑在 UCIe streaming 之上速率就是 UCIe 的口径UCIe 2.0UCIe 3.02025 年 8 月发布单通道速率最高 32 GT/s48 / 64 GT/s单个 x64 先进封装模块单向raw256 GB/s512 GB/s4 模块聚合链路单向raw1 TB/s~2 TB/s带宽密度先进封装上限约 1.3 TB/s/mm商用 IP 已流片到 21 Tbps/mm 双向≈2.6 TB/s/mm差多少取决于你用哪把尺子尺子一单模块 vs 整链路最常见的误读口径一个 UCIe 2.0 x64 模块双向约 0.5 TB/s对比 NV-HBI 的 10 TB/s——差约 20 倍。这就是32 GT/s vs 10 TB/s那种说法的来源但这是拿「一根车道」比「整座桥」。尺子二同等聚合规模UCIe 3.0 允许 2/4 模块聚合4×x64 64 GT/s 双向约 4 TB/s——NV-HBI 领先收窄到约 2.5 倍。要追平 10 TB/s需要沿 die 边缘铺 10 个左右 x64 模块占用宝贵的 shoreline。尺子三带宽密度真正公平的口径UCIe 3.0 的 64G IP 已做到约 2.6 TB/s/mm 双向。NV-HBI 这边 NVIDIA 不公开占用的 die 边缘长度但 Blackwell die 约 800 mm²共享边长约 30 mm 量级——就算只用其中一部分10 TB/s 摊下来的密度大概率低于 UCIe 3.0 的密度指标。这揭示了一个反直觉的事实NV-HBI 的 10 TB/s 主要靠「宽」不是靠「快」——成千上万根中速并行走线电压摆幅压得极低换取的是功耗pJ/bit和延迟而不是单线速率。为什么 NVIDIA 要这么设计设计目标其实很清晰Blackwell 单 die 的 HBM 带宽是 4 TB/s整颗 8 TB/sNV-HBI 的 10 TB/s刻意超过单 die 内存带宽使得跨 die 读取远端 HBM 时互连不再是瓶颈数据可以按细粒度打散到两边、对 CUDA 完全透明。10 TB/s 不是能做到的上限而是让双 die 幻象成立的最低配置。答案NV-HBI 10 TB/s 双向整条链UCIe CHI-C2C 单通道 32/64 GT/s单 x64 模块 0.25/0.5 TB/s 单向4 模块聚合约 2 TB/s 单向。名义差距 10–20 倍是口径错位同密度同宽度对比实际差距约 2.5–5 倍而这部分差距买的主要不是带宽本身而是私有方案在功耗、延迟和协议-物理层联合优化上的自由度。 NPU 两个计算 die 构成单个 gpu 设备
1. 如何构成单个设备先明确「构成单个设备」到底需要什么两个 die 对软件呈现为一个GPU需要同时满足四个条件统一物理地址空间——两个 die 的 HBM 编进同一张地址地图对称的硬件缓存一致性——die A 的 L2 能 snoop die B 的 L2cacheline 粒度双方地位对等细粒度地址交织——地址按 256B/2KB 之类的粒度打散到两边 HBM带宽和容量透明地翻倍调度器不用感知 NUMA单次枚举——对主机只暴露一个 PCIe function、一组 BAR、一个命令队列。注意 UCIe 在这里只是「公路」——UCIe 规范本身就支持承载 CHI、CXL、PCIe 或私有 streaming 协议。**决定能不能拼成一个设备的是公路上跑的协议的一致性模型不是物理层。**所以「UCIe CXL」物理上完全合法问题在于 CXL 的协议语义做不到上面第 2、3 条。CHI-C2C 为什么可以它是「片内 fabric 的延伸」CHI 本来就是片上一致性总线协议Arm CMN mesh 跑的就是它CHI-C2C 做的事情本质上是把同一个一致性 mesh 拉过 die 边界两个 die 上的 RN-F全一致性请求节点比如计算簇 L2 slice和 HN-Fhome 节点带 snoop filter/目录在同一个一致性域里协议层只是多了 C2C 打包/解包一跳跨 die 访问对协议来说和片内跨 mesh 一跳没有区别——延迟是几十纳秒量级与本地 L2 未命中同数量级CHI 原生支持 HN-F 哈希交织地址按 cacheline 倍数粒度散到两个 die 的 HBM 控制器上带宽池化对软件完全透明支持完整的一致性操作集snoop、Direct Cache Transfer、原子操作、cache maintenance——两个 die 的缓存是对等公民。于是 die 边界被移到了「设备边界之内」主机看到的永远是封装外面的那一个 PCIe 端点。这和 NVIDIA 用 NV-HBI 合并两个 Blackwell die、AMD 用 Infinity Fabric 拼 MI300 是同一种架构范式——都是用原生 fabric 一致性协议跨 die只是 Arm 把它标准化了。CXL 为什么不行它是「主机中心的外设一致性」CXL 的一致性模型从设计第一天起就是非对称的这跟它要解决的问题主机 CPU 和外挂内存/加速器之间的池化匹配但和「合并两个对等 die」恰好相反1. 一致性主从结构CXL 1.1/2.0 里主机是唯一的一致性管理者CXL.cache 允许设备缓存主机的内存由主机反向 snoop 设备CXL.mem 允许主机访问设备内存——但设备自己的内存对其他设备不一致两个设备之间根本不能互相 snoop。两台 GPU 用 CXL 连起来A 永远看不到 B 缓存里改过的 cacheline。第 2 条直接不满足。2. 延迟量级错了CXL 是面向 PCIe 级链路设计的跨链访问延迟在数百纳秒量级。而「两个 die 一个设备」要求跨 die 的 L2 访问和本地 L2 未命中相当几十纳秒否则每次跨 die 命中都比本地慢一个数量级两个 die 实际上成了两个 NUMA 节点——GPU 的编程模型和驱动根本没有「设备内 NUMA」这个概念性能扩展性会崩掉「单设备幻象」不攻自破。3. 没有对等设备间交织和合并语义两个 CXL 设备在主机的设备树里就是两个设备两次枚举、两组 BAR。CXL 3.0 确实补了不少东西——fabric、P2P、back-invalidation设备内存可以被一致性共享、多级交换——但它的方向是「多个主机/设备共享池化内存」一致性依然由主机或 fabric 目录居中仲裁粒度是内存池和页不是两个对等 L2 之间的 cacheline 级对称 snoop。它提供的是「设备间共享」不是「设备内合并」。总结UCIe CHI-C2CUCIe CXL协议定位片上 fabric 跨 die 延伸主机↔设备的 I/O 一致性接口一致性结构对称多 RN-F/HN-F 同域非对称主机为一致性主节点设备间互相 snoop原生支持1.1/2.0 不支持3.0 经主机/fabric 目录中转跨 die 延迟~几十 ns与片内同量级~数百 ns细粒度地址交织HN-F 哈希透明无设备级/页级软件可见对主机呈现一个设备die 边界在封装内两个设备需软件虚拟化才像一个CHI-C2C 把 die 边界藏在设备边界里面CXL 本身就是一条设备边界。用 CXL 拼两个 die得到的永远是「两台通过一致性网络相连的加速器」要得到「一台加速器」必须用本来就是设备内部语言的一致性 fabric 协议——CHI、Infinity Fabric、NV-HBI 都是这个角色CXL 的角色在封装外面。2. UCIeC2C 与 NV-HBI 速率对比先把两个数字的口径摆清楚这两个数字其实不在同一个度量维度上直接对比会产生错觉UCIe 标称的是「每通道速率」UCIe 2.0 最高 32 GT/s per lane2025 年发布的 UCIe 3.0 通过 QDR 信令做到 48/64 GT/s。CHI-C2C 本身不定义物理层速率——它是 Arm 在 2024 年发布的片间一致性协议只定义协议层和打包层跑在 UCIe 的 streaming 协议之上容器格式兼容 UCIe 256 字节延迟优化模式。NV-HBI 的 10 TB/s 是「整个 die 边缘的聚合带宽」Blackwell 两颗 reticle 极限 die 之间通过定制、低功耗的 NV-HBI 互连共享 L2、保持完全一致对外表现为单一 CUDA GPU。NVIDIA 未公开其 SerDes 速率和链路数业界推断是宽并行总线加一致性协议引擎的实现。换句话说一个是「一根线跑多快」另一个是「一整排上万根线加起来多少」。如果换算成可比的带宽密度TB/s per mm beachfront商用 UCIe PHY IP 在 64 Gbps 下已能做到约 21 Tbps/mm和 NV-HBI 推算的密度在同一量级——差距远没有 32 Gbps vs 10 TB/s 看起来那么夸张。真正的差距来源1. 封装层级不同最根本NV-HBI 跑在 2.5D 硅桥/中介层上Blackwell 采用台积电先进封装die 边到边距离只有毫米级可以用极小的 bump 间距、极短的走线、很低的电压摆幅。UCIe 作为标准必须同时兼容有机基板的标准封装bump 间距大、走线长、损耗高和先进封装两种场景速率和密度只能取保守值以保证互操作和良率。2. 开放标准 vs 私有垂直整合NVIDIA 自己控制 die 设计、协议、封装和拓扑永远是两颗同构 die 合并 L2PHY 可以针对这个唯一场景做极致裁剪。UCIe 要跨厂商、跨工艺互操作必须带训练、校准、sideband 管理、CRC/retry 等通用性机制。事实上 NVIDIA 虽在 UCIe 董事会但自家创收产品用的就是私有接口。3. 协议开销CHI-C2C 是通用一致性协议在 CHI 的 REQ/RSP/DAT/SNP 四通道外增加了 MISC 通道做初始化和 credit 流控还要做片上 CHI 到片间格式的协议转换和定长容器打包。这些开销换来的是任意 Arm 生态 chiplet 的互操作能力——CHI-C2C 面向多芯片 SMP 和一致性加速器挂载等开放拓扑。NV-HBI 只需服务一种固定拓扑协议和物理层可以联合优化。4. 能耗预算的再分配die-to-die 的真正货币是 pJ/bit。超短距让 NV-HBI 每比特能耗压得很低省下的功耗预算全部用来堆并行线数——「不以单线速率取胜而以规模取胜」。总结差距的大头是统计口径单通道 vs 整排聚合和封装代际有机基板兼容 vs 2.5D 硅桥专用剩下的是开放标准的通用性税。如果 UCIe 3.0 也部署在同等级别的先进封装上、按同样宽度聚合带宽密度可以接近 NV-HBI 的水平——你付给标准的溢价换来的是跨厂商互操作的生态NVIDIA 放弃的正是这一点。3. 问题量化先把两边的「官方数字」钉死NV-HBI一颗 Blackwell GPU 内部两个 die 之间的整条链路10 TB/s 双向总量约 5 TB/s 单向两颗 reticle 极限 die 之间通过 CoWoS-L 硅桥边对边互连NVIDIA 从未公开过 per-pin 速率、线数和协议开销业界只能推断是「宽并行总线 一致性引擎」的实现。UCIeCHI-C2C 没有自己的速率它跑在 UCIe streaming 之上速率就是 UCIe 的口径UCIe 2.0UCIe 3.02025 年 8 月发布单通道速率最高 32 GT/s48 / 64 GT/s单个 x64 先进封装模块单向raw256 GB/s512 GB/s4 模块聚合链路单向raw1 TB/s~2 TB/s带宽密度先进封装上限约 1.3 TB/s/mm商用 IP 已流片到 21 Tbps/mm 双向≈2.6 TB/s/mm差多少取决于你用哪把尺子尺子一单模块 vs 整链路最常见的误读口径一个 UCIe 2.0 x64 模块双向约 0.5 TB/s对比 NV-HBI 的 10 TB/s——差约 20 倍。这就是32 GT/s vs 10 TB/s那种说法的来源但这是拿「一根车道」比「整座桥」。尺子二同等聚合规模UCIe 3.0 允许 2/4 模块聚合4×x64 64 GT/s 双向约 4 TB/s——NV-HBI 领先收窄到约 2.5 倍。要追平 10 TB/s需要沿 die 边缘铺 10 个左右 x64 模块占用宝贵的 shoreline。尺子三带宽密度真正公平的口径UCIe 3.0 的 64G IP 已做到约 2.6 TB/s/mm 双向。NV-HBI 这边 NVIDIA 不公开占用的 die 边缘长度但 Blackwell die 约 800 mm²共享边长约 30 mm 量级——就算只用其中一部分10 TB/s 摊下来的密度大概率低于 UCIe 3.0 的密度指标。这揭示了一个反直觉的事实NV-HBI 的 10 TB/s 主要靠「宽」不是靠「快」——成千上万根中速并行走线电压摆幅压得极低换取的是功耗pJ/bit和延迟而不是单线速率。为什么 NVIDIA 要这么设计设计目标其实很清晰Blackwell 单 die 的 HBM 带宽是 4 TB/s整颗 8 TB/sNV-HBI 的 10 TB/s刻意超过单 die 内存带宽使得跨 die 读取远端 HBM 时互连不再是瓶颈数据可以按细粒度打散到两边、对 CUDA 完全透明。10 TB/s 不是能做到的上限而是让双 die 幻象成立的最低配置。答案NV-HBI 10 TB/s 双向整条链UCIe CHI-C2C 单通道 32/64 GT/s单 x64 模块 0.25/0.5 TB/s 单向4 模块聚合约 2 TB/s 单向。名义差距 10–20 倍是口径错位同密度同宽度对比实际差距约 2.5–5 倍而这部分差距买的主要不是带宽本身而是私有方案在功耗、延迟和协议-物理层联合优化上的自由度。