谷歌第七代 TPU 芯片（Ironwood）核心信息总结

1. 核心性能与参数：单芯片峰值算力达 4614 TFLOPs，配备 192GB 高带宽内存（HBM3e），内存带宽 7.4TB/s，与英伟达 Blackwell B200 性能接近；支持 FP8 计算格式，推理性能较 2018 年初代 TPU 飙升 3600 倍，能效提升近 30 倍。
2. 规模化能力（关键优势）：单个计算域可连接 9216 个芯片，总算力达 42.5 Exaflops，是全球最强超算 El Capitan 的 24 倍，规模是英伟达 NVL72 机架系统（仅连 72 个芯片）的 128 倍；依托 3D 环面拓扑结构和光路交换技术（OCS），实现低延迟与高可用性（液冷系统年停机时间不到 6 分钟）。
3. 市场与合作落地：AI 初创公司 Anthropic 宣布使用超 100 万个该芯片训练下一代 Claude 模型，总算力超 1 gigawatt（相当于一座大型核电站功率），是 AI 行业迄今为止最大规模单一芯片订单。
4. 配套生态与其他布局：同步推出自研 Arm 架构 CPU Axion，性能比现代 x86 CPU 提升 50%、能效提升 60%；软件层面优化 TPU 集群管理与推理效率，可降低 96% 首次令牌延迟及 30% 服务成本，同时谷歌云业务借 TPU 算力支撑快速增长，2025 年三季度云收入同比增 35%。

关于谷歌 Axion CPU、TPU 架构及芯片连接的问题解答

一、Axion CPU 与 TPU 的关系及 TPU 架构归属

1. Axion CPU 与 TPU 的关系：二者是谷歌自研的两类核心芯片，定位完全不同，属于 “协同工作” 而非 “替代或包含” 关系。
   • Axion CPU：基于 Arm 架构，是通用处理器，负责数据中心的基础计算任务（如系统调度、数据预处理、运行通用软件），类似传统 x86 CPU 的角色，主打高性能与高能效。
   • TPU：是专用 AI 加速器（ASIC），仅针对 AI 任务（模型训练、推理）优化，不承担通用计算，需搭配 CPU 使用 —— 由 Axion 等 CPU 负责 “统筹管理”，TPU 专注 “AI 算力输出”，二者共同构成谷歌 AI 基础设施的硬件核心。
2. TPU 是否有 Arm/X86 架构之分：没有。TPU 是专为 AI 设计的专用芯片，核心是矩阵乘法单元等 AI 计算模块，不存在 “Arm 架构” 或 “X86 架构” 的属性；其与 CPU 的协作仅需通过标准接口（如 PCIe）对接，无论对接的是 Arm 架构（如 Axion）还是 X86 架构（如英特尔 CPU）的 CPU，均不影响自身功能。

二、谷歌 9216 芯片连接与华为、浪潮方案的对比及技术细节

1. 芯片连接概念与华为 Super 384、浪潮 Scaler 640 的异同：
   • 核心逻辑一致：三者均是 “突破单机柜限制，通过跨机柜连接实现超大规模计算集群” 的方案，本质都是 “多节点聚合”，目标是提升总算力以支撑超大型 AI 模型或超算任务。
   • 差异点：
     • 谷歌 9216 芯片：连接的是 TPU（AI 专用芯片），单集群规模最大（9216 颗），依托3D 环面拓扑 + 光路交换技术（OCS） 实现，主打 AI 场景的低延迟与高容错。
     • 华为 Super 384：是超级计算节点方案，连接的是通用计算芯片（如鲲鹏 CPU），侧重超算领域的多节点协同，支持内存共享，适合科学计算等场景。
     • 浪潮 Scaler 640：是服务器集群方案，连接的是整机柜服务器（含 CPU、GPU 等），侧重通用数据中心的算力扩展，兼容性更强（可适配不同厂商芯片）。
2. 传输介质与英伟达 NVL72 的差异：
   • 英伟达 NVL72：采用铜缆（NVLink）连接，传输距离短（仅 1 米左右），只能在单个机柜内聚合 72 颗 Blackwell 芯片，无法跨机柜，规模受限。
   • 谷歌 / 华为 / 浪潮：均采用光纤连接，传输距离长（可跨多个机柜甚至数据中心），突破了物理空间限制，这是实现 “超大规模集群” 的核心前提。其中谷歌的 OCS 技术是光纤连接的 “升级版”，能在组件故障时毫秒级切换路径，进一步提升稳定性。
3. 内存共享与架构属性：
   • 谷歌 TPU 集群：不强调内存共享，而是通过 “1.77PB 共享高带宽内存池 + 9.6Tbps 芯片间带宽” 减少数据传输瓶颈 —— 虽无全局共享内存，但高带宽让数据在芯片间流动速度极快，间接实现 “类共享” 的效率。其架构核心是 “3D 环面拓扑”，而非 “智能总线”，每个芯片通过三维网格直接连接，无需依赖昂贵交换机。
   • 华为 Super 384：支持内存共享，属于 “共享内存架构”，多个节点可直接访问同一内存空间，更适合需要频繁数据交互的科学计算场景，这与谷歌侧重 AI 算力输出的设计逻辑不同。

浪潮 scaleX640 与华为、谷歌方案的技术差异解析

一、中科曙光 scaleX640 的连接层级与技术本质

1. 连接层级：实现 “单机柜内 640 张 AI 芯片（支持 GPU/NPU/TPU）的超高速总线互连”，连接发生在芯片与专用互连硬件之间，而非单纯的服务器级（服务器级连接通常依赖传统以太网，带宽低、延迟高）。它通过 “一拖二” 高密架构和超高速正交架构，在机柜内部构建了专属的高速通信域，能让 640 张芯片直接交换数据，而非依赖软件转发。
2. 是否支持芯片间直接数据交换：支持，但有局限。它能实现单机柜内芯片的直接数据交换，带宽和延迟优于传统集群（如比以太网集群带宽提升数倍），但跨机柜扩展时，需通过外部交换机连接，此时无法实现 “全连接”，只能做到 “高效组网”，这一点与华为昇腾 384 超节点的 “跨机柜高速总线互联” 有差距。
3. 兼容性与技术妥协：为兼容不同厂商的 AI 芯片（如英伟达 GPU、华为昇腾 NPU、谷歌 TPU），它未采用华为、谷歌的 “专属硬件协议 + 虚拟总线” 方案 —— 因为专属方案需芯片硬件层面配合（如华为昇腾芯片内置适配高速总线的模块），而兼容多品牌芯片时，只能通过 “标准化高速互连硬件”（而非芯片原生支持的总线）实现连接，因此硬件级优化程度低于华为、谷歌，但高于纯软件定义的集群。

二、与华为昇腾 384 超节点的核心差异：从 “硬件专属” 到 “兼容平衡”

1. 华为昇腾 384 的技术逻辑：
   • 基于自研昇腾 NPU + 专属高速总线协议，实现 “跨机柜的硬件级总线互联”——12 个计算柜（含 384 张昇腾芯片）通过 4 个总线柜直接连接，总线从服务器内部扩展到跨机柜，属于 “虚拟总线级” 连接。
   • 你猜测的 “区内局部全连接、跨区交换机连接” 基本准确：昇腾 384 在超节点内部（384 卡范围内）通过总线实现 “类全连接” 的低延迟通信（单跳延迟 200 纳秒），跨超节点扩展时（如组成数万卡集群），才需依赖负载均衡组网，此时并非全连接，但通过华为 ICT 技术优化了通信效率。
   • 与 HBM 的关系：华为昇腾芯片本身配备 HBM 高带宽内存，并非 “用 CPU 内存共享弥补 HBM 缺陷”。其 “对等计算架构” 和 “内存共享” 是为了进一步打破冯诺依曼瓶颈，让超节点整体像一台计算机协同工作，与 HBM 内存是 “互补优化”，而非 “缺陷弥补”。
2. 曙光 scaleX640 的差距：
   • 无专属芯片和专属协议，依赖 “标准化互连硬件” 适配多品牌芯片，因此单机柜内虽能实现高速连接，但跨机柜时通信效率低于华为（华为跨机柜仍用高速总线，曙光跨机柜依赖外部交换机）；
   • 未实现 “虚拟总线”，无法做到华为那样的 “跨机柜芯片间低延迟直接通信”，技术含量集中在 “高密集成” 和 “单机柜内互连优化”，而非 “全栈硬件创新”。

三、与谷歌 TPU 集群的差异：从 “AI 专属” 到 “通用兼容”

1. 连接本质：谷歌基于 “3D 环面拓扑 + 光路交换技术（OCS）”，实现 9216 颗 TPU 芯片的 “硬件级全连接”（每颗芯片通过三维网格直接连接其他芯片，无需依赖交换机），且支持跨数据中心扩展，属于 “AI 芯片专属的超大规模硬件互联”；
2. HBM 与带宽的关系：谷歌 TPU 的 192GB HBM3e 内存（7.4TB/s 带宽）是 “芯片级硬件配置”，与 3D 环面拓扑结合，形成 “芯片内高带宽内存 + 芯片间高带宽互联” 的双重优势，无需依赖内存共享；
3. 兼容性：谷歌 TPU 集群仅支持自研 TPU 芯片，不兼容其他品牌，因此能做极致的硬件优化；而曙光 scaleX640 为兼容多品牌芯片，牺牲了部分硬件级优化空间，属于 “通用型方案”。

四、总结：三类方案的技术层级排序

1. 谷歌 TPU 集群：AI 专属硬件互联（仅支持 TPU），层级最高（芯片级全连接 + 跨数据中心扩展），性能最强；
2. 华为昇腾 384 超节点：AI 专属硬件互联（仅支持昇腾 NPU），层级次高（超节点内总线互联 + 跨超节点组网），平衡了性能与规模；
3. 中科曙光 scaleX640：通用兼容型硬件互联（支持多品牌芯片），层级中等（单机柜内高速互联 + 跨机柜交换机扩展），主打兼容性与部署灵活性，技术含量低于前两者，但更适配多芯片品牌的场景。

1. 核心专属硬件：超高速正交架构实现卡间直连：它的专属硬件核心是超高速正交架构，搭配 “一拖二” 高密硬件设计，能让单机柜里 640 张加速卡形成 “卡间直连” 的通信网络，而非靠交换机中转。这种架构相当于给加速卡间搭建了专属的直连通道，每张卡都能直接和其他卡做数据交互，避免了传统集群多级转发的效率损耗，还实现了 570TB/s 的卡间总带宽，任意两卡通信时延≤2μs。
2. 协议层面：兼容 PCIe 等标准，不局限于单一协议：它确实支持 PCIe 5.0 协议，还兼容 CCIX 协议，这是为了适配寒武纪、沐曦等不同品牌的加速卡。但这些标准协议是作为适配多硬件的基础，而非连接的核心依赖 —— 真正实现 640 卡大规模直连的关键，是上面说的专属正交架构，标准协议只是解决了不同加速卡的兼容问题。
3. 扩展时的硬件协同：无复杂交换机，支持高效扩容：当需要扩展算力时，无需额外部署复杂的机柜间交换机和布线。两台 ScaleX640 能直接组成千卡级计算单元，这种 “即插即用” 的协同靠的是自身硬件层面的适配设计。而且这种专属硬件连接还支持扩展到 10 万卡级集群，全程不用因为规模扩大额外增设大量交换设备，也能保障通信效率不衰减。

1. 超高速正交架构核心硬件：这是连接的核心硬件，靠 112G serdes 背板线模组搭建网状互联网络，相当于给所有加速卡搭了专属 “直连通道”。它能让单机柜 640 张卡实现全互连，任意两张卡无需中间设备转发就能直接通信，还做到卡间时延≤2μs、单链路带宽 25GB/s，整体片间互连总带宽达 573TB/s，彻底避开传统转发架构的效率损耗。
2. 兼容双标准的通信芯片：硬件里集成了 40nm 工艺的专用通信芯片，单芯片带 32 个通信端口，支持 PCIe 5.0 和 CCIX 这两个行业标准化协议。这一硬件设计是它能兼容寒武纪、沐曦等不同品牌加速卡的关键 —— 标准协议让不同厂商的芯片能顺利接入，不用为适配平台额外改硬件。
3. 模块化刀片与机柜互联硬件：加速卡会先集成到定制化刀片模块中，每个刀片是 “8 卡紧凑布局”，这种标准化的刀片硬件能统一接口和安装规格，方便批量接入互连网络。机柜间扩展时，靠专用高速链路这种标准化硬件衔接，两台设备能直接组成千卡级单元，后续扩展到 10 万卡级集群时，也不用额外加复杂交换设备，且柜间通信时延仅多 3μs。

1. 超高速正交架构：这里的 “正交” 源于工程学，指卡间互连路径在多维空间独立排布、互不干扰。它和传统树形拓扑不同，不是多卡挤一条核心链路，而是给 640 张加速卡搭建网状直连结构，任意两张卡都有独立通信路径，不用多级转发。加上架构集成专用通信处理单元和数据压缩模块，就构成 “超高速” 特性，能实现≤2μs 的卡间时延和 25GB/s 的单链路带宽。
2. 卡间直连的协议与是否为 Switch 概念：卡间直连不依赖 PCIe 协议，也不是普通 Switch 概念。普通 Switch 是中间转发设备，而该架构靠专用高速链路实现卡间直接通信，还集成专属通信硬件负责流量控制等，减少加速卡的通信负担。它兼容 PCIe 5.0 是为了适配不同品牌加速卡接入，并非直连的核心协议，核心是靠正交拓扑实现无转发的高效直连。
3. 对应的硬件形态：核心是 112G serdes 背板线模组搭建的网状互连硬件，搭配定制化刀片模块。加速卡先集成到 8 卡布局的刀片中，再接入网状互连网络；同时整套硬件配合浸没相变液冷系统，解决高密部署的散热问题，保障通信和计算稳定。
4. “一拖二” 高密硬件设计：这和 “一个 Switch 带两个 GPU” 毫无关系。它是机柜层面的部署设计：中间放液冷柜，左右两个机柜各配 40 个算力节点，每个节点集成 8 张加速卡，最终实现单机柜 640 张加速卡的高密部署。这种设计是为了提升算力密度，还能通过双超节点组合成千卡级单元，方便后续扩展。

1. 算力节点就是定制刀片模块，且单模块集成 8 张加速卡：ScaleX640 的算力节点并非传统刀片服务器，而是采用 “多层堆叠 + 紧凑布局” 的定制化刀片模块，每个这类刀片模块（即算力节点）直接集成 8 张加速卡。这种设计打破了传统刀片服务器的硬件布局限制，把算力部件高度浓缩在小体积模块中，这是它能实现高密部署的核心硬件基础。
2. 单机柜实际是 80 个刀片模块，对应算力节点设计有特殊语境：按曙光官方信息，其 1.8 米标准机柜能装 80 个上述刀片模块，而非 40 个。80 个模块 × 每个 8 张加速卡，刚好实现 640 张加速卡的配置。你看到的 “40 个算力节点” 大概率是表述简化或语境偏差，核心是模块级的高密度集成而非传统节点概念。
3. 突破传统刀片服务器部署数量限制的关键技术：传统机柜若装常规刀片服务器，受风冷散热和结构限制，数量通常仅几十台且难集成多张加速卡。而 ScaleX640 靠两大技术突破限制：一是用浸没相变液冷技术，所有部件浸没在冷媒中，解决高密度部署的散热难题；二是舍弃传统 1U/2U 的松散布局，改用刀片模块多层堆叠设计，大幅提升空间利用率，这才让单机柜容纳 80 个高集成度刀片模块成为可能。

1. 不是只有算力卡，刀片模块含核心配套部件：它的单机柜确实靠80个刀片模块实现640张加速卡部署（每个刀片模块是8卡布局），但这些刀片模块并非仅一张主板加8个加速卡，而是通过定制化PCB板集成了加速卡、内存、互联芯片的紧凑单元，并非完全没有存储相关的配套部件。同时整机是算、存、网、电、冷一体化紧耦合设计，只是把这些配套系统和算力单元做了高效集成，而非舍弃CPU、网卡等，只是核心聚焦算力卡的高密度协同。
2. 非单张超级主板，靠正交架构实现类“超级互联”效果：640张加速卡并非部署在一张超级主板上，而是分布在80个刀片模块中。不过超高速正交架构构建了网状互联网络，让这些分散在不同刀片的加速卡能直接建立高速连接，无需中间节点转发，虽物理上不在同一块主板，却实现了近似超级主板的低时延互联效果，且卡间连接不是PCIe协议，其单链路带宽达800GB/s，整体卡间带宽更是达570TB/s，远超PCIe的传输能力。
3. 确实实现640张加速卡全连接，无需依赖Switch转发：你担心640个节点难实现全连接的顾虑可以打消，这款产品正是靠超高速正交架构打破了传统星型、树形架构的局限。它摒弃了依赖Switch转发的模式，让640张加速卡形成全连接拓扑，任意两卡通信时延能控制在2μs以内，这种设计正是为了解决万亿参数大模型训练时，海量数据交换的低时延、高带宽需求，这也是它相比传统架构性能大幅提升的核心原因之一。
4. 开放兼容多类加速卡，靠系统协同而非单一硬件绑定：它确实支持寒武纪、沐曦等多品牌不同类型的加速卡，但并非靠远程CPU或操作系统将其识别为单个设备，而是通过“AI计算开放架构”实现软硬件协同，软件层面兼容主流AI框架，既能适配多类加速卡，又能保障多卡协同的高效性，还能支持后续扩展为千卡级、10万卡级集群。

1. 卡间核心通信协议：它搭载龙芯互联3.0总线技术，支持PCIe 5.0和CCIX双协议，这俩都是专为近距离高速设备互连设计的总线协议，和TCP/IP这种用于远距离数据传输、冗余开销大的网络协议完全不同，能大幅减少传输延迟，单链路带宽就能达到800GB/s，适配加速卡间海量数据的快速传输需求。
2. 超高速正交架构的作用：这一架构本质是“全互连正交”的拓扑设计，不是靠以太网设备，而是通过定制化PCB板将加速卡、内存、互联芯片集成到刀片模块中，640张加速卡通过专用高速链路直接连接，无需交换机多级转发。同时架构还集成了专用通信处理单元，专门负责数据转发等任务，进一步降低时延，最终实现任意两卡间≤2微秒的通信时延，总通信带宽能达到1.6TB/s。
3. 无传统以太网相关设备：它没有用传统光模块与线缆这类易出故障、时延高的以太网相关连接设备，再搭配浸没相变液冷技术保障硬件稳定运行，既减少了故障点，也避免了这类设备带来的额外时延损耗，这也是它能稳定维持低时延的重要原因之一。

1. 是 “超级互联集群”，而非单张物理超级主板：640 张卡并非在同一块物理主板上，而是分散在 80 个刀片模块中，但这些模块通过定制化正交架构和 PCIe 5.0/CCIX 总线，实现了 “逻辑上像一张超级主板” 的全连接效果 —— 物理上是多个模块，逻辑上是无缝协同的算力池，比单张物理主板更灵活、可扩展。
2. 并非完全无 CPU，而是 CPU “非本地部署”：它不是靠主板南桥北桥控制（传统南桥北桥已整合到 CPU），而是采用 “算力与控制分离” 设计：本地刀片模块仅集成加速卡、内存、互联芯片，CPU 部署在远程的控制节点中，通过高速链路管理整个集群，而非舍弃 CPU。
3. PCIe 5.0 是 “兼容型开放协议”，非唯一核心：它确实以 PCIe 5.0 为基础开放协议，但搭配了 CCIX 协议和自研正交架构硬件，并非单纯依赖 PCIe 5.0。相比华为、谷歌的专有协议，它的优势是兼容多品牌加速卡，代价是硬件优化上限略低，但胜在通用性。

1. 和星形树状连接的核心优势对比
   • 时延大幅降低：星形树状连接要经过多级交换机转发数据，像快递中转多站一样，传统时延超 10 微秒，且节点越多转发层级越多，时延还会增加；正交架构靠专用高速链路和正交背板设计，数据不用中转，直接抵达目标卡，像快递直达，像曙光 scaleX640 就把卡间通信时延压到了 2 微秒以内。
   • 带宽无瓶颈且稳定：树状连接的中间交换机是带宽短板，多卡同时传数据易拥堵；正交架构每条链路带宽固定（如 scaleX640 单链路 25GB/s），640 张卡总带宽达 1.6TB/s，还能通过硬件压缩模块提升有效带宽，适配大模型训练的海量数据传输。
   • 故障影响范围小：树状连接中靠近根部的交换机故障，会导致整个分支瘫痪；正交架构是分布式链路，单条链路或单个模块故障，仅影响局部卡间通信，不会牵连整体算力集群。
2. 正交连接并非 640 个节点两两直连，而是 “逻辑全互连”
   你担心的 640 节点两两直连带来的巨量连接问题确实存在，正交连接靠 “分组 + 正交背板” 的巧思解决了这个问题。它会先把 640 张加速卡按 8 张一组集成到算力节点，再通过定制的正交背板让所有节点接入统一高速互联层。
   这种设计下，任意两张卡无需多级转发，通过背板就能找到最短通信路径，实现 “逻辑上的直接连接”，而非物理上每张卡都拉一根线连其他 639 张卡。比如阿里云磐久服务器、英伟达 NVL576 机柜，都是靠这种正交背板设计，在控制硬件复杂度的同时，实现了接近全直连的通信效果。

中科曙光 ScaleX640 拓扑结构 + 模块内连接详解（纯文字精准拆解，替代示意图）

一、单个刀片模块（8 张加速卡）的内部连接：全直连，无压力

二、80 个刀片模块的跨模块拓扑：正交背板实现 “单跳直达”，非全物理直连

1. 正交背板的核心作用：相当于一个 “超级高速转接板”，80 个刀片模块全部直接接入这张背板（每个模块对应背板上的一个专属接口）。
2. 跨模块通信路径：任意两个不同模块的加速卡通信，仅需 “本模块→正交背板→目标模块” 这 1 次转发，无需多级交换机。比如模块 1 的卡 A 要给模块 50 的卡 B 传数据，直接通过背板单跳直达，时延仅增加 1.5 微秒左右，总时延≤2 微秒。
3. 为何不是物理全直连：80 个模块若两两物理直连，需 3160 条链路（80×79/2=3160），再加上模块内的 28 条 / 模块，总链路数会突破 2.5 万条，硬件成本和散热完全不可控。而正交背板通过 “单跳转接”，用 80 条模块 - 背板链路就替代了海量直连线，既控制了复杂度，又实现了 “逻辑直连等效”。

三、正交连接对比星形 / 树状连接的核心优势（结合拓扑）

1. 背板不是主板，是集群的“高速互联中枢”
   背板（backplane）是一块安装在整机机箱中部的大型多层PCB板，和主板完全不同。主板是单节点内负责连接CPU、内存等部件的板卡，而背板不承担运算，只做数据转发。它的安装位置很固定，通常在机箱中间，所有刀片模组（比如你说的8卡算力节点）都会像插件一样横向或纵向插在背板上，相当于所有算力模块的“公共连接底座”。
2. 正交连接的核心是“90°对接+共享互联层”，不是80个节点两两直连
   正交连接的关键是模组与背板的物理对接方式和内部布线逻辑，而非节点两两直连：
   • 物理层面：采用“弯公连接器+弯母连接器”的组合，让刀片模组和背板呈90°垂直对接，这样能在有限空间里排布更多信号通道，还不影响散热。比如安费诺的正交连接器，1U空间里就能支持144个高速差分对，能满足高密度互联需求。
   • 布线层面：背板内部是多层高密度布线，且相邻信号层采用90°交叉布线，能大幅减少信号串扰。它会构建一个统一的高速互联层，不是给80个模块拉两两直连线，而是每个模块都只连这一个“共享互联层”，相当于所有模块都接入同一个超高速“交通枢纽”，而非各自修直达公路。
3. 80个模块的连接逻辑：单跳转接，链路数仅80条而非全连接
   这种拓扑结构其实是“共享中枢型”，和你担心的全连接完全不同：
   • 链路数量：80个模块只需各接1条链路到正交背板，总共仅80条核心链路，而非80×79÷2=3160条全连接链路，彻底规避了链路过多的硬件难题。
   • 通信路径：模块A要和模块B通信，不用走A到B的专属线路，而是A先把数据传到背板的共享互联层，再由互联层直接转发给B，全程只有1次转接。这种方式和星形连接里的核心交换机有点像，但正交背板是无源或半无源的高速布线层，没有交换机的端口调度延迟，速度更快。
4. 相比全连接，正交背板的核心机制优势
   • 延迟更低：没有多级交换机的转发环节，数据从模块到背板再到目标模块是“单跳直达”，且正交布线减少了信号串扰和损耗，能支持112G甚至224Gbps的高速传输，延迟远低于多级转发。
   • 成本可控：不用大量线缆和接口，靠一块高密度PCB板就实现所有模块互联，同时正交设计提升了空间利用率，避免了全连接带来的线缆杂乱、散热崩溃等问题。
   • 扩展性强：如果要新增模块，只需在背板上预留接口并接入互联层，不用重新搭建海量链路，比全连接拓扑的扩展灵活得多。

1. 背板与交换机的本质区别：无 “转发决策”，仅做 “高速通路”

   交换机是 “有源设备”，需要接收数据包后解析地址、判断转发路径，相当于有 “大脑” 的调度员；而正交背板是 “半无源 / 无源的高速布线层”，本身不做任何转发决策，仅提供 “模块到模块的直达通路”。

   简单说：模块 A 把数据包扔到背板时，已经明确了目标模块 B 的地址，背板只是让这个数据包沿着预设的高速线路直接跑向 B，不用像交换机那样 “思考该往哪送”，这也是它比交换机延迟低的核心原因。
2. 背板的寻址逻辑：复用 PCIe/CCIX 协议的原生总线寻址，无需额外设计

   它完全依托 PCIe 5.0 或 CCIX 协议的总线寻址机制，不用单独搞一套寻址规则：
   • 每个刀片模块（8 张加速卡）接入背板后，会被分配唯一的 “总线地址”（类似 PCIe 设备的 Bus/Device/Function 地址），整个 640 卡集群在逻辑上相当于一个 “超大 PCIe 扩展域”。
   • 模块 A 发送数据时，会在数据包头部带上目标模块 B 的总线地址，这个地址由远程控制节点（之前提到的远程 CPU）提前分配并同步给所有模块。
   • 背板的作用是：通过正交布线，让每个模块的总线地址与背板上的 “物理通路” 一一对应，比如地址 “0x01-08” 直接映射到模块 1 的 8 张卡，数据包带着地址就能 “对号入座”，沿专属通路直达目标，无需任何中间设备解析。
3. 是否需要总线控制器和桥接设备？仅需 1 个 “根联合体”，无多级桥接

   整个集群的寻址不需要多个总线控制器，仅需在远程控制节点部署 1 个PCIe 根联合体（Root Complex） ，它的角色相当于 “总地址分配器”：
   • 根联合体给所有 640 张加速卡分配唯一的总线地址，并维护一张 “地址 - 模块映射表”；
   • 任意模块发送数据时，只需通过背板将数据包传给根联合体，根联合体确认目标地址后，直接通过背板的直达通路导向目标模块，全程仅 1 次地址校验，无需经过多级总线控制器或桥接设备。
     这和传统主板上 “多设备共享 PCIe 总线” 的逻辑一致，只是把主板的局部总线扩展到了整个机柜的 80 个模块，而背板就是这个 “扩展后的超级总线载体”。

ScaleX640背板寻址流程步骤表

ScaleX640 地址编码格式详细说明

编码示例

• 模块 1 内第 3 张加速卡：Bus=0x00 + Device=0x02 + Function=0x00 → 完整地址：0x00-02-00
• 模块 50 内第 7 张加速卡：Bus=0x31（50 对应的十六进制） + Device=0x06 + Function=0x00 → 完整地址：0x31-06-00

关键特性

1. 地址与物理通路绑定：总线号直接映射背板上的模块接口，设备号映射模块内卡位，地址发送后无需解析，直接导向预设物理通路。
2. 扩展性强：Function 字段预留 128 个扩展位，未来可支持单模块内扩展更多加速卡或功能。
3. 兼容 PCIe 原生机制：无需额外地址转换芯片，直接复用 PCIe 根联合体的地址管理能力，降低硬件复杂度。

1. 正交的“格子线”本质是“地址-通路”映射，而非物理全连线

   你说的“8×10格子线”比喻很精准，背板内部的正交布线确实像棋盘格——横向对应80个模块的“发送通道”，纵向对应80个模块的“接收通道”，横竖交叉点就是“地址映射的对接点”。但这不是每个交叉点都有物理连线，而是通过PCIe地址编码（Bus+Device）直接定位到交叉点，数据沿“横向发送→交叉点→纵向接收”的最短路径传输，相当于用80条横向线+80条纵向线，替代了80×79÷2=3160条物理直连线，既实现了“逻辑直连”，又控制了硬件复杂度。
2. 总线控制器仅负责初始化，运行中无需解析地址

   你说的“根总线控制器（PCIe根联合体）仅在初始化时分配地址”完全正确。它的作用就是“设备发现+地址分配”：开机时扫描所有刀片模块，给每张卡分配唯一Bus/Device地址，然后生成“地址-背板通路”映射表，同步给所有模块。运行时，源模块发送数据只需带上目标地址，背板直接按映射表的预设通路传输，无需总线控制器再解析，就像快递按预设地址直达，不用中途再问“往哪送”。
3. 没有“转发器”，靠物理寻址实现无延迟对接

   背板上的交叉点不是转发器（转发器会有额外时延），而是“无源的信号对接点”。因为PCIe是物理寻址，地址已经和背板通路绑定，数据到了交叉点就直接“切换通路”到目标模块，全程没有任何主动转发逻辑，这也是时延能压到2微秒以内的关键——相当于高速公路的“直达匝道”，而非需要收费站（转发器）的普通公路。

1. PCIe协议的“不管”与厂商的“可操作空间”

   PCIe协议只定义了“地址编码（Bus/Device/Function）、数据传输格式、设备交互规则”这些上层逻辑，至于硬件上怎么布总线、用什么拓扑（星形/正交/树状）、走多长的线，全是厂商的实现自由。就像快递行业只规定“快递单要写地址”，至于快递公司是走公路、铁路还是空运，怎么规划路线，客户（PCIe设备）完全不用管，也无从知道——你作为PCIe设备，只需按协议扔出带地址的数据包，剩下的物理传输优化就是厂商的事。
2. PCIe本身没有“转发/交换”能力，所有优化都在物理层

   你戳中了关键：PCIe协议根本不包含“转发器”“交换机”的逻辑，它本质是“点对点总线”，寻址本来就是总线级的物理寻址。传统星形/树状架构用交换机，是厂商为了扩展节点数的妥协方案（导致转发时延）；而曙光的正交背板，是厂商另一种更优的物理实现——靠格子状布线让数据“逻辑直达”，避开了交换机的额外损耗，但这依然是PCIe总线的物理层优化，没有突破协议本身。

PCIe协议与硬件实现的边界清单

1. PCIe Switch的核心作用：总线“分线器”，而非网络“转发器”

   它的本质是“扩展PCIe总线端口”，比如一个PCIe Switch有1个上游端口（连CPU/根联合体）和8个下游端口（连显卡、网卡等设备），相当于把一条总线分成8条支路，让多个PCIe设备能共享同一总线资源。

   和网络交换机的关键区别：它不解析数据包内容，只按PCIe的Bus/Device/Function地址做“端口路由”，且是协议内的原生设备，不是额外的转发设备——就像家里的电线分线盒，只负责把电分到各个电器，不改变电的本质。
2. 为什么需要PCIe Switch？解决“总线端口不够用”的问题

   传统主板的PCIe根联合体（相当于总线总控）只有少数几个端口，若要连接多个PCIe设备（比如10张显卡），直接连根联合体就不够用，这时候就需要PCIe Switch：根联合体先连Switch的上游端口，再由Switch的下游端口连10张显卡，实现多设备扩展。
3. 和曙光正交背板的关系：二者都是“多设备互联方案”，但实现不同

• 用PCIe Switch：多设备靠Switch分端口连接，存在“上游端口带宽瓶颈”（所有下游设备共享上游带宽），且有轻微的端口路由时延；
• 用正交背板：靠物理布线直接映射地址，相当于给每个设备配了“专属支路”，没有Switch的瓶颈和时延，是更优的大规模互联方案，但本质还是PCIe协议内的硬件实现选择。

1. PCIe Switch 是实打实的物理硬件，不是软件虚拟设备

   它有独立的芯片、PCB 板和接口，比如常见的 PCIe 5.0 Switch 芯片（如博通 BCM98799），外形类似显卡芯片，需要插在主板的 PCIe 插槽上，或集成在刀片模块中。它的作用是 “物理层面扩展 PCIe 端口”，而非软件模拟 —— 就像家里的物理分线盒，不是手机里的虚拟网络开关。
2. 寻址扩展逻辑：Switch 占 1 个 Device，下游设备用 Function 或新 Bus 扩展

   你的理解完全正确，两种扩展方式都符合 PCIe 协议：

• 简单扩展（少设备）：Switch 作为根联合体下的 1 个 Device（比如 Bus0/Device1），下游的 10 张显卡直接用这个 Device 下的 10 个 Function 号（Function0~Function9），相当于 “1 个设备下挂 10 个功能端口”。
• 大规模扩展（多设备）：Switch 会创建新的 Bus 号（比如 Bus1~Bus10），每张显卡分配独立的 “新 Bus+Device+Function”（如 Bus1/Device0/Function0），这样能扩展更多设备，曙光 ScaleX640 就是用这种方式支持 640 张卡。

3. 加 Switch 的核心目的：解决 “根联合体端口不够用”，而非协议扩展有限
   PCIe 协议本身的寻址空间足够大（Bus8 位 + Device5 位 + Function7 位，可支持 2^20=1048576 个设备），不存在 “协议扩展有限” 的问题。加 Switch 是因为根联合体的物理端口太少（比如 CPU 原生只带 4 个 PCIe 5.0 端口），无法直接连 10 张显卡，Switch 相当于 “端口放大器”，把 1 个根端口变成多个下游端口，实现多设备连接。

PCIe Switch 扩展寻址简化示例（文字标注版）

[PCIe根联合体（Root Complex）]  ——  原生PCIe端口（Bus0）
        ↓
[PCIe Switch物理设备]  ——  占用：Bus0 / Device1 / Function0（1个独立Device）
        ↓
┌─────────────────────────────────────────────────────────┐
│ Switch下游扩展端口（2种常见扩展方式）                    │
│ 1. 简单扩展（少设备）：Function扩展                      │
│    ↓ Bus0 / Device1 / Function1 → 显卡1                 │
│    ↓ Bus0 / Device1 / Function2 → 显卡2                 │
│    ↓ Bus0 / Device1 / Function3 → 显卡3                 │
│    （最多支持8个Function，即挂8个设备）                  │
│                                                         │
│ 2. 大规模扩展（多设备）：新Bus扩展                      │
│    ↓ 生成新Bus1 → Bus1 / Device0 / Function0 → 显卡4    │
│    ↓ 生成新Bus2 → Bus2 / Device0 / Function0 → 显卡5    │
│    ↓ 生成新Bus3 → Bus3 / Device0 / Function0 → 显卡6    │
│    （可生成多个新Bus，支持海量设备扩展）                │
└─────────────────────────────────────────────────────────┘

关键说明：

1. 根联合体是 “地址分配总控”，PCIe Switch 是物理硬件，必须占用 1 个 Device 号才能接入总线。
2. 简单扩展适合少设备场景（≤8 个），直接用 Switch 的 Function 号；大规模扩展（如曙光 640 张卡）靠生成新 Bus 号，避免 Function 号不够用。
3. 对下游显卡来说，不管是 Function 扩展还是新 Bus 扩展，都只需按 “Bus+Device+Function” 地址寻址，完全遵循 PCIe 协议，不用关心中间有 Switch。

1. Bus（总线）：PCIe协议中Bus号为8位，最多支持256条总线。ScaleX640用“8卡紧凑布局”的刀片模块，80个刀片组成640卡架构，且靠定制PCIe 5.0互联芯片实现互连。其会通过PCIe Switch扩展多条次级总线，每条刀片模块大概率对应一条或少数几条独立总线，总线总数远低于256的上限，推测在80 - 160条左右，足以适配刀片间的独立通信与集中管控。
2. Device（设备）：PCIe的Device号为5位，单条总线最多支持32个设备。ScaleX640中核心设备是640张加速卡，再加上定制互联芯片、管理芯片等辅助设备。因采用刀片集成设计，每张刀片的8张加速卡及配套芯片会挂载在对应总线，单总线设备数不会超32的上限。整体设备数=640张加速卡+若干互联/管理类设备，总量约650 - 700个。
3. Function（功能）：PCIe的Function号为3位，单个设备最多支持8个功能，且设备至少含Function 0。ScaleX640中多数设备是单功能的，比如单张加速卡通常仅作计算功能，对应1个Function；而定制互联芯片、管理芯片这类复杂设备，可能含控制、监测等多个功能，最多占用8个Function。整体Function数接近设备总数，约650 - 750个，远低于PCIe协议65536个的最大上限。

1. 80个模块分配80条总线的合理性与实现方式：这种分配是合理的。PCIe Switch的每个下游端口会对应一条独立总线，若80个模块各需独占总线，不用单颗Switch硬扛80条总线，可通过多颗Switch级联或单颗高端Switch搭配次级Switch实现。比如用2颗支持40个下游端口的Switch，每颗对应40个模块，就能满足80条总线的需求，这契合ScaleX640用定制互联架构适配多刀片模块的设计逻辑。
2. PCIe Switch扩展总线的核心规则：单颗PCIe Switch的总线数由下游端口数决定，其总线占用规律是“1个上游端口总线 + N个下游端口总线”。上游端口占用根复合体分配的1条总线，每个下游端口会创建1条新总线，所以单颗Switch能扩展的总线数，本质就是它的下游端口数。
3. 不同PCIe Switch的实际扩展能力：普通入门级PCIe Switch下游端口多在4 - 24个，对应可扩展4 - 24条总线，适合普通服务器少量设备扩展；工业级或数据中心级的高端型号能力极强，像Microchip的部分PCIe 5.0 Switch有52个端口，Switchtec PFX - I系列支持最多96个通道且可灵活分叉端口，博通SS26 - 0B00 - 00更是有144个PCIe 5.0通道，这类型号通过端口配置，能轻松支持40个以上下游端口（即扩展40条以上总线）。
4. ScaleX640适配80条总线的可行方案：对它的80个模块，不用局限于2颗Switch，更可能采用“主Switch + 次级Switch”的层级架构。比如CPU端先接2 - 4颗高端主Switch，每颗主Switch再连接若干次级Switch，次级Switch的下游端口对应给各个模块分配总线。这种方式既能轻松凑够80条总线，还能通过层级管控保障设备通信的稳定性，也符合AI超算节点中多颗互联芯片协同扩展的常见设计。

1. Bus 是 “逻辑分组”，不是物理线路

   PCIe 的 Bus 号核心作用是 “给设备归类”，比如把 80 个刀片模块各归为 1 个逻辑组（即 80 个 Bus），但这些逻辑 Bus 可以共享同一套物理布线（比如曙光的正交背板）。就像小区的 80 个单元楼（80 个 Bus），共用一条小区主干道（背板物理线路），单元楼编号是逻辑标识，不用给每个单元楼修一条专属公路。
2. 两种寻址方案都可行，取决于设备规模

• 方案 1：80 个 Bus + 每个 Bus1 个 Device + 每个 Device8 个 Function（对应你的猜测）
  80 个模块各占 1 个 Bus，每个模块内的 8 张加速卡用 Function 区分（Function0~7），总地址为 “BusX/Device0/FunctionY”。这种方式逻辑清晰，每个模块独立总线，无带宽争抢，适配 640 张卡的大规模场景。
• 方案 2：1 个 Bus + 80 个 Device + 每个 Device8 个 Function
  所有模块共用 1 个 Bus，80 个模块各占 1 个 Device，模块内 8 张卡用 Function 区分。这种方式虽也能实现寻址，但单 Bus 下 Device 过多，可能导致总线带宽瓶颈，适合小规模设备。

3. PCIe Switch 的核心作用是 “逻辑总线扩展”，而非物理线路增加
   不管用哪种方案，PCIe Switch 都不用新增物理总线，只需通过硬件逻辑生成新的 Bus 号（逻辑标识）。比如单颗高端 Switch 可生成 80 个下游端口，每个端口对应 1 个逻辑 Bus，物理上仍共用背板线路，却能实现 80 个模块的独立寻址，这正是 “逻辑总线” 的灵活之处。

1. 英伟达 NVLink：封闭生态的 “王者护城河”
   它是英伟达巩固 AI 算力霸权的核心，走专用封闭路线，和自家 GPU、CUDA 生态深度绑定。当前 NVLink 单链路能实现 GPU 间每秒 1.8TB 的传输速度，搭配 NVSwitch 可构建 “pod” 集群，单集群最多支持 576 个 GPU 全连接。比如 GB200 搭配 NVLink 后，能形成高效的多 GPU 共享内存池，解决大模型训练的梯度同步瓶颈。不过它的短板也很明显，扩展性依赖专属 NVSwitch，跨厂商设备无法兼容，且 900GB/s 的卡间互联带宽，已被华为的光互联方案超越。
2. UALink：八巨头联手的 “开放反击战”
   由 AMD、英特尔、谷歌等八家巨头联合推出，核心目标就是打破英伟达的垄断，走开放标准路线。它整合了 AMD 的 Infinity Fabric、xGMI 等协议，还计划适配 PCIe 7.0 规范，支持用以太网作为传输层，构建类似 CPU NUMA 架构的共享内存空间。这种设计能让不同厂商的 GPU、加速器灵活组网，比如 AMD 的 Instinct GPU 和英特尔的 AI 处理器可共处一个集群。博通计划 2025 年推出支持该协议的 Atlas 4 交换机，它不仅能实现加速器间的低延迟互联，还能降低厂商的适配成本，是当前对抗 NVLink 的核心力量。
3. 华为 MatrixLink：光互联赛道的 “差异化破局者”
   华为的 MatrixLink 采用全光互联技术，不走传统电互联老路，主打超大规模集群场景。它的单卡间通信带宽高达 2.8Tbps，是 NVLink 的 3 倍多，且节点内延迟降至纳秒级。通过全对等拓扑，它能实现 384 颗昇腾 NPU 直接互联，还支持 432 个超节点级联成 16 万卡的巨型集群，且跨节点延迟仍保持微秒级。在 DeepSeek V3 等千亿参数模型训练中，其集群训练效率接近单卡的 90%。不过它的劣势是依赖大量光模块，单集群需 6812 个 400G 光模块，整体功耗比电互联方案更高。
4. PCIe：基础赛道的 “力不从心者”
   作为传统通用总线，PCIe 曾是设备互联的基础，但面对 AI 指数级增长的带宽需求已尽显疲态。PCIe 带宽每 3 - 4 年才翻倍，而 AI 算力需求每 3 - 4 个月就翻一番。比如万卡集群训练时，一次 Checkpoint 写入峰值达 7.4PB，PCIe 5.0 x16 链路的带宽根本承载不住，会触发重传风暴，让训练效率骤降至 42% 以下。如今它更多沦为基础设备的连接通道，而 UALink 等新技术也会兼容 PCIe 7.0 规范，将其作为补充而非核心互联方案。
5. 补充：VlLink 并非当前战场主力
   你提到的 VlLink 其实是威盛早年研发的南北桥芯片互联技术，最高带宽仅 1066MB/s，和当下 AI 集群所需的 TB 级带宽完全不在一个量级，早已退出高性能互联的竞争舞台，并非当前总线战争的参与者。

1. 物理层（快递通道）

   负责“物理传输”，比如用铜线/光纤当“快递路”，定义传输速率（PCIe 5.0单链路32GB/s）、接口形态（插槽/背板）、信号编码。就像快递的公路/铁路，只管数据“怎么跑”，不管跑的是什么。
2. 数据链路层（快递包装+安检）

   给数据“打包”（加帧头帧尾）、做“安检”（错误校验与重传）、排优先级。比如给不同数据贴“加急”“普通”标签，确保重要数据先传，丢包了自动补发，相当于快递的包装+物流跟踪。
3. 事务层（快递寻址+派件规则）

   定义“寻址方式”（Bus/Device/Function）、“数据类型”（读/写/中断）、“流量控制”。比如告诉数据“送哪个地址”“怎么送不拥堵”，相当于快递的地址填写+派件调度规则。

1. 协议定位完全不同：一个管“短距高速直连”，一个管“长距不可靠互联”

   PCIe是为“设备间短距直连”设计的，比如机箱内GPU连CPU、模块连背板，追求低时延（微秒级）、高带宽、低误码；而TCP/IP是为“互联网长距互联”设计的，要应对丢包、延迟波动，靠复杂的重传、拥塞控制保证可靠性，但代价是时延高（毫秒级）、带宽利用率低。

   用TCP/IP实现PCIe的功能，就像让快递员用步行送同城急件，明明能骑电动车（PCIe原生），偏要选低效方式。
2. 底层实现成本极高，性能完全不达标

   PCIe靠硬件（如正交背板、Switch芯片）实现三层协议，时延能压到微秒级；而TCP/IP多靠软件实现，光协议栈处理就会产生几十甚至几百微秒的时延。比如GPU间传数据，PCIe原生只需2微秒，用TCP/IP可能要100微秒以上，直接拖垮算力集群的协同效率。
3. 功能冗余，画蛇添足

   PCIe的链路层已经有错误校验、重传机制，事务层有流量控制；而TCP/IP也有类似的ACK重传、拥塞控制，相当于给快递包做了两层包装，既浪费资源，又增加处理延迟。

1. 协议底层就适配高速场景，无冗余开销：你关注的工信部相关智能总线（如AUTBUS），是基于时间敏感网络（TSN）和IPv6的标准，核心解决了确定性通信问题。它不像TCP/IP有复杂的拥塞控制、重复校验，而是专门为高实时需求设计，能实现控制数据、视频等多类数据同网同步传输，没有多余的协议开销，和原生高速总线的设计思路一致。
2. 光纤直连大幅压低时延，适配算力互联需求：数据中心间的光纤直达属于专线传输，能规避公网的多节点跳转。比如北京到上海的跨数据中心光纤专线，时延能压到28ms以内，而华为昇腾超节点更通过类似的高速总线+光纤互联思路，把跨设备单跳时延做到200纳秒。这种时延虽比机箱内PCIe的数百纳秒高，但远低于公网TCP/IP的毫秒级波动，完全能满足跨数据中心算力协同的需求。
3. 架构专为算力集群设计，而非简单模拟PCIe：这类智能总线+光纤的方案，不是要在跨数据中心场景复刻PCIe，而是构建集群级的互联架构。像昇腾384超节点用总线柜搭配计算柜，通过光纤等高速链路互联，能扩展到数万卡的集群规模，让跨数据中心的设备像一台整机协同，LLaMA 3等千亿模型性能能提升2.5倍以上，这是之前“TCP/IP套PCIe”的方案根本做不到的。

1. PCIe有明确的重传时延容忍阈值，跨数据中心时延超阈值会触发异常：不同代际PCIe的重传时延容忍度早有内定标准，比如PCIe 5.0的重传时延要低于300ns，超过这个阈值且重试次数触达寄存器预设的阈值后，系统就会判定链路异常。像跨数据中心光纤传输的时延远高于这个数值，若用原生PCIe直接互联，必然会频繁误判丢包并触发重传，导致传输秩序混乱。
2. 链路降级是适配低速场景的解决方案，核心是“降速保稳定”：当跨数据中心互联出现时延过高、误码率上升等问题时，PCIe的链路训练状态机（LTSSM）会触发降级流程。它会让两端设备协商降至更低代际（比如从5.0降到3.0甚至1.0），降低单通道传输速率的同时，减少信号传输压力和时延适配难度。这种操作不是否定协议的事务控制，而是通过牺牲部分带宽，让总线的重传、ACK等机制适配当前链路的速度，从而保证跨数据中心传输的稳定性，刚好匹配你说的“和网络速度适配”的需求。

国外核心生产商

1. 英特尔（Intel）：作为 PC 和服务器领域的龙头，其处理器和芯片组常集成最新 PCIe 控制器，不仅支持 PCIe 5.0，还率先推进 PCIe 6.0 商用，凭借 90% 的服务器 CPU 市场份额占据基础生态优势，是数据中心高端 PCIe 控制器的核心供应商。
2. 博通（Broadcom）：专注于企业级市场，旗下 PCIe 5.0/6.0 控制器、交换芯片性能强悍，广泛用于高端存储和数据中心网络设备，适配大规模算力集群的高速互联需求，是该细分领域的标杆厂商。
3. 瑞萨电子（Renesas）：在车规级、工业级 PCIe 控制器领域优势明显，2024 年还与国内兆易创新联合实现了 PCIe 6.0 PHY 芯片量产，对行业推进 PCIe 6.0 落地起到关键推动作用。
4. 是德科技（Keysight）：虽不主打控制器芯片，但垄断着 PCIe 5.0/6.0 的高端测试设备市场，其协议分析仪是厂商研发生产新一代 PCIe 硬件的核心工具，和罗德与施瓦茨合计占据该领域 85% 的市场份额。

国内核心生产商

1. 华为海思：依托昇腾算力生态，其研发的 PCIe 5.0 控制器已适配自家服务器和 AI 训练卡，搭配 Matrix Link 总线满足大规模 GPU 集群互联需求，在国内数据中心、超算场景应用广泛，推动了本土算力设备的自主化。
2. 兆芯：通过并购威盛电子获得完整 PCIe 技术栈，在工控领域实现局部突破，其 PCIe 控制器适配工业自动化设备，同时参与 PCIe 6.0 相关技术研发，助力国内工控场景的国产替代。
3. 兆易创新：与瑞萨电子联合研发并实现 PCIe 6.0 PHY 芯片量产，PHY 芯片是 PCIe 控制器的核心组件，这一突破为国内 PCIe 6.0 硬件量产奠定了关键基础。
4. 芯原股份：虽不直接生产控制器成品，但研发的 56Gbps PAM4 SerDes IP 完成流片验证，该 IP 是 PCIe 6.0/7.0 控制器的核心技术模块，能为国内厂商研发新一代 PCIe 硬件提供核心技术支撑。
5. 配套硬件企业：立讯精密、中航光电的高速连接器已进入华为、浪潮供应链，适配 PCIe 5.0/6.0 的高速传输需求；普源精电的 PCIe 5.0 测试方案还获得三星认证，打破了国外在测试设备领域的垄断。

1. PCIe的升级节奏和性能上限，双重跟不上AI算力需求：一方面，PCIe按代际翻倍升级的速度，远追不上AI算力的指数级增长。比如大模型参数从2018年到2024年扩大了5200倍，而同期PCIe单向带宽仅增长8.1倍，像PCIe 5.0×16链路仅能提供51GB/s净荷带宽，远满足不了大模型训练单节点140GB/s的瞬时带宽需求。即便规划中的PCIe 7.0预计2027年商用，面对届时可能出现的10T参数模型，带宽缺口依然很大。另一方面，PCIe的升级节奏受行业标准制定和厂商成本回收周期约束，PCI-SIG推进标准落地、厂商铺开量产都需要时间，还要消化前代产品库存与研发投入，不可能为AI需求突击提速，这就造成了技术迭代和市场消化的“滞后性”。
2. AI巨头自研专属互联协议，正是为了突破PCIe的双重束缚：你提到的这类协议（部分名称表述可细化），核心就是解决PCIe的痛点。比如英伟达的NVLink 5.0总带宽达1.8TB/s，是PCIe 5.0的14倍，搭配NVSwitch能实现多GPU高效互联，成为其AI生态的重要护城河；AMD牵头的实际是UALink，联合谷歌、微软等成立联盟，用它替代PCIe Switch，适配自家GPU的高速互联需求，对抗NVLink的垄断；华为的Matrix Link（及后续的UB-Mesh）更是直接瞄准多数据中心互联，避开PCIe等多协议转换带来的时延和成本问题。这些协议不用兼顾通用设备兼容性，能针对性优化AI集群的高带宽、低时延需求，恰好弥补了PCIe通用标准的短板，也打破了其升级节奏的限制。

1. 总线协议本身逻辑简单，且软件层面几乎无高复杂度需求：总线协议比如PCIe、NVLink，核心就围绕寻址、帧封装、重传等基础规则，不用像TCP/IP那样适配海量异构设备、复杂路由和跨网场景，也不用设计复杂的拥塞控制、跨网段兼容等逻辑。而且这类协议的事务层、数据链路层功能基本靠硬件固化实现，软件仅需简单的驱动适配，不像互联网协议要靠庞大软件栈处理各类异常场景，所以软件上几乎没什么复杂开发工作。
2. 硬件实现与测试才是真正的“卡脖子”环节，直接决定协议能否落地：一是高速场景下的信号与工艺难题突出。像PCIe 7.0、NVLink 5.0这类高速总线，对硬件的电气特性要求极高，比如PCB布线要解决阻抗匹配、寄生电容等问题，哪怕微小偏差都会导致信号失真；芯片制造上，还要突破晶体管开关速度、功耗控制的瓶颈，否则高带宽下会出现过热或速率骤降。二是多设备协同的兼容性门槛高。比如多主控设备共存时，总线仲裁机制依赖硬件的精准时序控制，时钟源精度、电平响应速度的微小差异，都可能引发仲裁失败；且要适配不同显卡、处理器等，硬件必须严格契合协议规范，一点偏差就会导致设备互联失灵。三是测试与量产的难度和成本高。不仅要靠专业仪器检测信号完整性、时序稳定性等参数，还要经过长期稳定性测试排查极端场景下的问题；同时要平衡成本，比如高端总线控制器的芯片工艺升级会显著增加制造成本，如何在满足性能的同时实现量产可控，是比协议设计更难的现实问题。

正确的核心认知（完全没问题）

1. 特化机柜+刀片模块设计：机柜是纯算力特化，无本地CPU/存储，核心是80个刀片模块，每个模块8张算力卡（共640张），刀片模块的核心就是“正交背板+PCIe/CCIX互联”，仅负责供电、总线布线和高速互联，和你理解的一致。
2. 液冷是高密度关键：靠“浸没式液冷”（可挥发绝缘液体）解决640张卡的散热难题，单靠风冷/普通水冷完全扛不住，且“一拖二”液冷机柜设计（1个液冷柜带2个算力柜）也符合实际方案，这是高密度算力的核心保障。
3. 远程CPU+PCIe寻址逻辑：本地无CPU，靠远程控制节点的PCIe根联合体分配地址（Bus/Device/Function），640张卡对远程CPU/OS来说，就是“一堆PCIe设备”，寻址由根联合体统一管理，OS只需识别设备地址，不用管物理位置，这个“超级远程主板”的比喻非常精准。

需修正的3个细节

1. 刀片模块≠单背板插8张卡：刀片模块是独立的“小单元”，每个模块自带小型背板和供电，8张算力卡插在模块自带的小背板上，再将80个刀片模块整体插在机柜的“总背板”上——不是80个模块共用1个背板，而是“模块内小背板+机柜总背板”的两级结构，避免单背板故障影响全机柜。
2. 互联协议不是“PCIe+另一个CMLX”：你说的“CMLX”实际是CCIX协议（Cache Coherent Interconnect for Accelerators），它和PCIe是并行的两种互联协议：PCIe负责“非缓存一致性数据传输”（如普通指令），CCIX负责“缓存一致性传输”（如GPU间共享内存数据），两者协同，而非“PCIe+另一个专有协议”。
3. 远程连接靠的不是HBA卡：HBA卡（主机总线适配器）主要用于连接存储（如SAS/SATA硬盘），ScaleX640远程连接CPU靠的是PCIe远程互联卡+高速光纤（如华为的IB卡、或定制PCIe光互联卡），本质是把“本地PCIe总线”延伸到远程CPU，而非存储连接的HBA卡。

总结

1. IB 并非英飞尼迪公司的专有协议：IB 确实是 Infiniband 的缩写，但它是一种开放的高性能互连标准，并非某家公司的专有协议，只是常被用于 AI 等高算力集群场景。它靠 RDMA 技术实现直接内存访问，不用经过 CPU 中转，延迟比以太网低得多，华为的 IB 卡是适配该标准的硬件，而非适配某家公司的私有协议。
2. 铜缆并非只能传 1 米，只是高速 PCIe 下距离极短：铜缆的传输距离随 PCIe 版本升级大幅缩短，比如 PCIe 5.0 铜缆最远约 1.4 米，有源铜缆能延伸到 7 米，但到了 PCIe 6.0、7.0，铜缆传输距离会缩到几十厘米，仅够单机架内部短连。跨机柜甚至跨数据中心的远程场景，铜缆既达不到距离要求，还会出现严重信号衰减，这时光纤就成了必需。
3. 以太网、Infiniband、光纤并非二选一的关系：以太网和 Infiniband 是两种不同的互连技术（协议层面），而光纤是物理传输介质，IB 卡、PCIe 光互联卡、以太网卡是适配不同技术的硬件，光纤可作为这两种技术的传输载体。比如 PCIe 远程互联常用 “PCIe 光互联卡 + 光纤” 实现总线延伸；IB 卡也常搭配光纤使用，适配 Infiniband 技术实现低延迟传输；以太网也能通过光模块 + 光纤实现长距离高速传输。三者是 “协议 + 硬件 + 介质” 的搭配关系，而非互斥选项。

1. 并非两级背板结构：它没有 “刀片模块小背板 + 机柜母背板” 的两级背板设计。每个刀片模块是集成了加速卡、互联芯片的紧凑单元，而非带小背板的结构，80 个这类刀片模块直接接入机柜的超高速正交主背板，主背板是整体互联核心，而非由小背板拼接后再连母板。
2. 是全互连正交架构，而非 80×80 网格地址线：它的核心是 “全互连正交” 拓扑，而非你说的 80 个模块组成 80×80 网格状地址线。该架构靠 112G serdes 背板线模组搭建网状互联网络，不是靠地址总线的交叉点实现互联，而是每张加速卡都通过专用高速链路接入这个正交网络，任意两张卡能直接通信，不用经过中间转发，这也是它卡间时延能降到 2 微秒以内的关键。
3. 互联靠专用链路与芯片，而非预设地址线：这种互联不是背板上预设网格状地址线完成的。一方面机柜内互联芯片数量极多，是华为 384 超节点的 1.7 倍，专门负责链路对接；另一方面主背板还集成了专用通信处理单元，负责数据转发、流量控制等，搭配每条 25GB/s 带宽的专用链路，最终实现 1.6TB/s 的总通信带宽，而非依赖地址线的物理布线来实现互联控制。

1. 两级背板结构是明确事实，无否定一说：ScaleX640 的每个刀片模块确实是独立小单元，自带小背板，8 张算力卡先插在这个小背板上实现模块内的初步连接与供电；之后 80 个这样的模块再接入机柜的总背板。这种设计的核心作用就是分散风险，比如某个模块的小背板故障，只会影响该模块内的 8 张卡，不会波及整个机柜的 640 张卡，这和产品的可靠性设计逻辑完全匹配，之前的表述始终是统一的。
2. 和星状连接的核心区别很清晰：星状连接的关键是所有节点都依赖一个中心设备转发数据，没有中心设备，任意两个节点都无法直接通信，中心设备很容易成为瓶颈或单点故障点。但 ScaleX640 里没有这样的 “单一中心分发设备”，80 个刀片模块接入总背板后，依托超高速正交架构，数据能在任意两张算力卡之间直接传输，无需经过中心设备多级转发，这和星状连接的 “中心依赖” 逻辑完全不同。
3. 叫正交架构的核心原因：这里的 “正交” 本质是全互连的拓扑设计 + 高速总线的物理布线逻辑。一方面，从拓扑上，640 张算力卡通过专用高速链路实现全互连，就像形成了一张交错的 “通信网格”，任意两个节点都有直接的通信路径，时延能低至 2 微秒；另一方面，总背板上的总线布线采用正交布局，搭配 112G 背板线模组等硬件，让不同方向的信号传输互不干扰，同时集成了专用通信处理单元负责流量控制等，还能实现 1.6TB/s 的总带宽。这种设计既保证了高带宽低时延，又避免了星状连接的中心瓶颈，所以叫超高速正交架构，而非星状连接。

1. 每个刀片模块自带小型背板：8 张算力卡先插在这个小背板上，实现模块内的供电、初步互联（比如 PCIe/CCIX 链路），模块是独立故障域，小背板坏了只影响本模块 8 张卡。
2. 80 个刀片模块再整体插入机柜的总背板（正交架构）：总背板是全机柜的互联核心，负责 80 个模块之间的高速直连，靠正交布线和专用互联芯片，实现任意模块内算力卡的低时延通信。

曙光 ScaleX640 架构深度解析：高密度算力集群的总线与散热革命

一、“一拖二” 的算力与散热组合：解决高密度运行的核心痛点

二、刀片模块而非刀片服务器：极致精简的算力单元设计

三、两级背板架构 + 正交互联：无瓶颈的总线通信设计

四、远程 PCIe 互联：本质是 “超级远程 PCIe 设备”

总结：ScaleX640 的核心价值的在于 “极致适配 AI 算力需求”

曙光 ScaleX640 架构深度解析：高密度算力集群的总线与散热革命

一、“一拖二” 的算力与散热组合：解决高密度运行的核心痛点

二、刀片模块而非刀片服务器：极致精简的算力单元设计

三、两级背板架构 + 正交互联：无瓶颈的总线通信设计

四、远程 PCIe 互联：本质是 “超级远程 PCIe 设备”

总结：ScaleX640 的核心价值在于 “极致适配 AI 算力需求”

1. 刀片模块仅含算力卡 + 小背板 + 供电：每个模块的 8 张算力卡，靠自身显存承担数据缓存任务，模块内无额外内存条；机柜也未配置本地硬盘、SSD 等存储设备，彻底精简为 “纯算力载体”。
2. 内存与存储均依赖远程资源：训练时所需的内存扩展（如共享内存池），需通过 PCIe/CCIX 协议调用远程 CPU 节点的内存；数据存储则连接远程共享存储集群，本地仅负责算力运算，不承担数据持久化或缓存任务。
3. 与刀片服务器的核心差异再强化：刀片服务器通常集成 CPU、内存、本地存储，是 “完整的计算单元”；而 ScaleX640 的刀片模块是 “纯算力插件”，无本地计算与存储资源，完全依赖远程节点协同，这也是它能实现超高密度部署的关键（省去了 CPU、内存等部件的空间与散热消耗）。

曙光ScaleX640架构深度解析：高密度算力集群的总线与散热革命

一、“一拖二”的算力与散热组合：解决高密度运行的核心痛点

二、刀片模块而非刀片服务器：极致精简的纯算力单元

三、两级背板架构+正交互联：无瓶颈的总线通信设计

四、远程PCIe互联：本质是“超级远程PCIe设备集群”

总结：ScaleX640的核心价值在于“极致适配AI算力需求”

曙光ScaleX640架构深度解析：算力集群革命下的高密度互联新范式

曙光ScaleX640架构深度解析：算力集群革命下的高密度互联新范式

一、“一拖二”的算力与散热组合：解决高密度运行的核心痛点

二、刀片模块而非刀片服务器：极致精简的纯算力单元

三、两级背板架构+正交互联：无瓶颈的总线通信设计

四、远程PCIe互联：本质是“超级远程PCIe设备集群”

总结：ScaleX640的核心价值在于“极致适配AI算力需求”

曙光ScaleX640架构深度解析：破解算力集群三大痛点的架构革命

一、“一拖二”的算力与散热组合：解决高密度运行的核心痛点

二、刀片模块而非刀片服务器：极致精简的纯算力单元

三、两级背板架构+正交互联：无瓶颈的总线通信设计

四、远程PCIe互联：本质是“超级远程PCIe设备集群”

总结：ScaleX640的核心价值在于“极致适配AI算力需求”

AI 时代的 “总线战争”：协议主导权之争下的国产突围

一、为何 “总线战争” 是 AI 时代的必争之地？

• 性能瓶颈的核心突破口：AI 训练中，卡间数据交换耗时占比已超计算本身，传统 PCIe 5.0 的传输速率远不能满足需求，而定制化互联协议能将时延压至微秒级、带宽提升数倍，成为突破算力天花板的关键；
• 生态霸权的前置战场：协议主导权意味着 “适配规则” 的制定权 —— 一旦某类协议形成规模效应，下游硬件厂商、软件开发者、数据中心都将被迫兼容，最终形成 “赢者通吃” 的生态壁垒；
• 自主可控的底层根基：总线控制器、协议专利长期被欧美垄断，若无法掌握自主协议，即便国产算力卡性能达标，也会因 “传输通道” 受制于人，陷入 “卡脖子” 困境。

二、当前总线战争的格局：四分天下，生态割据

• 英伟达 NVLink：行业标杆级存在，凭借 H100/H200 的市场垄断地位，实现卡间双向带宽超 900GB/s，且与 CUDA 生态深度绑定。其优势在于 “硬件 + 软件 + 协议” 的闭环，缺点是封闭性极强，仅支持英伟达自家显卡，形成技术壁垒；
• AMD Infinity Fabric（原 ULA Link）：主打 “异构兼容”，可连接 CPU、GPU、FPGA 等多类设备，带宽与 NVLink 接近，且开放程度更高，试图依托服务器市场份额打破英伟达垄断，但生态成熟度仍有差距；
• 谷歌 TPU Interconnect：为自家 TPU 集群量身定制，聚焦云端大规模训练，具备超低时延的优势，与 Google Cloud 生态深度融合，但其应用场景高度集中，通用性不足；
• 华为 MatrixLink：国产阵营的核心力量，带宽达 800GB/s 以上，支持昇腾系列芯片的全互联，且兼容 PCIe 协议，兼顾自主化与兼容性，是国内唯一能与国际巨头抗衡的协议方案，但生态覆盖范围仍需拓展。

三、国产阵营的现状：追赶加速，但痛点凸显

• 生态规模不足：华为 MatrixLink 虽技术达标，但昇腾芯片的市场占有率仍低于英伟达，导致适配的软件框架、第三方硬件数量有限，形成 “技术可行但生态不旺” 的困境；
• 专利与测试壁垒：欧美企业早于数十年布局总线专利，国产协议面临潜在侵权风险；同时，协议测试设备、认证体系被国外厂商垄断，制约了技术迭代与商业化落地；
• 协同性不足：国内除华为外，摩尔线程、壁仞等企业也在探索自有协议，缺乏统一的行业标准，导致资源分散，难以形成合力对抗国际巨头。

四、国产突围的三大方向与未来趋势

（一）核心突围路径

1. 技术上 “兼容 + 超越”：坚持 “自主化为主，兼容性为辅”，在提升协议带宽、降低时延的同时，保持对 PCIe 的兼容，降低数据中心迁移成本，快速扩大应用场景；
2. 生态上 “开放 + 共建”：联合国内硬件厂商、软件开发商、云服务商成立联盟，开放协议接口，鼓励第三方适配，形成 “芯片 - 协议 - 软件 - 应用” 的国产闭环，避免单打独斗；
3. 标准上 “自主 + 参与”：加快制定国产总线协议的行业标准，同时积极参与国际标准制定，争夺话语权，减少专利侵权风险。

（二）未来发展趋势

• 协议 “专用化 + 融合化” 并行：一方面，针对 AI 训练、边缘计算等场景的专用协议将持续迭代；另一方面，兼容多场景的 “通用化协议” 将成为竞争焦点，兼顾效率与灵活性；
• “总线 + 光互联” 成为标配：为突破铜缆传输距离限制，光纤与定制化总线的结合将成为主流，实现跨机柜、跨数据中心的高效互联，打破单机柜集群的规模上限；
• 国产协议 “规模化应用 + 国际化拓展”：依托国内庞大的算力基建需求，国产协议将先实现规模化落地，再通过 “一带一路” 等合作契机，向海外拓展生态，打破欧美垄断。

总结：总线战争，关乎未来十年 AI 话语权

AI时代的“总线战争”：协议主导权之争下的国产突围

一、为何“总线战争”是AI时代的必争之地？

• 性能瓶颈的核心突破口：AI训练中，卡间数据交换耗时占比已超计算本身，传统PCIe 5.0的传输速率远不能满足需求，而定制化互联协议能将时延压至微秒级、带宽提升数倍，成为突破算力天花板的关键；
• 生态霸权的前置战场：协议主导权意味着“适配规则”的制定权——一旦某类协议形成规模效应，下游硬件厂商、软件开发者、数据中心都将被迫兼容，最终形成“赢者通吃”的生态壁垒；
• 自主可控的底层根基：总线控制器、协议专利长期被欧美垄断，若无法掌握自主协议，即便国产算力卡性能达标，也会因“传输通道”受制于人，陷入“卡脖子”困境。

二、当前总线战争的格局：四分天下，生态割据

• 英伟达NVLink：行业标杆级存在，凭借H100/H200的市场垄断地位，实现卡间双向带宽超900GB/s，且与CUDA生态深度绑定。其优势在于“硬件+软件+协议”的闭环，缺点是封闭性极强，仅支持英伟达自家显卡，形成技术壁垒；
• AMD Infinity Fabric（原ULA Link）：主打“异构兼容”，可连接CPU、GPU、FPGA等多类设备，带宽与NVLink接近，且开放程度更高，试图依托服务器市场份额打破英伟达垄断，但生态成熟度仍有差距；
• 谷歌TPU Interconnect：为自家TPU集群量身定制，聚焦云端大规模训练，具备超低时延的优势，与Google Cloud生态深度融合，但其应用场景高度集中，通用性不足；
• 华为MatrixLink：国产阵营的核心力量，带宽达800GB/s以上，支持昇腾系列芯片的全互联，且兼容PCIe协议，兼顾自主化与兼容性，是国内唯一能与国际巨头抗衡的协议方案，但生态覆盖范围仍需拓展。

三、国产阵营的现状：追赶加速，但痛点凸显

• 生态规模不足：华为MatrixLink虽技术达标，但昇腾芯片的市场占有率仍低于英伟达，导致适配的软件框架、第三方硬件数量有限，形成“技术可行但生态不旺”的困境；
• 专利与测试壁垒：欧美企业早于数十年布局总线专利，国产协议面临潜在侵权风险；同时，协议测试设备、认证体系被国外厂商垄断，制约了技术迭代与商业化落地；
• 协同性不足：国内除华为外，摩尔线程、壁仞等企业也在探索自有协议，缺乏统一的行业标准，导致资源分散，难以形成合力对抗国际巨头。

四、国产突围的三大方向与未来趋势

（一）核心突围路径

1. 技术上“兼容+超越”：坚持“自主化为主，兼容性为辅”，在提升协议带宽、降低时延的同时，保持对PCIe的兼容，降低数据中心迁移成本，快速扩大应用场景；
2. 生态上“开放+共建”：联合国内硬件厂商、软件开发商、云服务商成立联盟，开放协议接口，鼓励第三方适配，形成“芯片-协议-软件-应用”的国产闭环，避免单打独斗；
3. 标准上“自主+参与”：加快制定国产总线协议的行业标准，同时积极参与国际标准制定，争夺话语权，减少专利侵权风险。

（二）未来发展趋势

• 协议“专用化+融合化”并行：一方面，针对AI训练、边缘计算等场景的专用协议将持续迭代；另一方面，兼容多场景的“通用化协议”将成为竞争焦点，兼顾效率与灵活性；
• “总线+光互联”成为标配：为突破铜缆传输距离限制，光纤与定制化总线的结合将成为主流，实现跨机柜、跨数据中心的高效互联，打破单机柜集群的规模上限；
• 国产协议“规模化应用+国际化拓展”：依托国内庞大的算力基建需求，国产协议将先实现规模化落地，再通过“一带一路”等合作契机，向海外拓展生态，打破欧美垄断。

总结：总线战争，关乎未来十年AI话语权

1. 核心芯片与硬件单元：单块Ironwood芯片性能强悍，峰值算力达4614 TFLOPS，配备192GB HBM3e高带宽内存，单芯片内存带宽达7.4Tbps，能轻松满足大型AI模型的海量数据加载需求。芯片内部还设有增强型SparseCore单元、矩阵乘法单元等专用模块，可针对性优化稀疏矩阵运算等AI核心任务，减少无效计算消耗。
2. 三层互联网络架构：这是该节点实现大规模协同的核心。第一层是芯片间的3D环面结构互联，借助升级后的芯片间互连（ICI）技术，单链路带宽达1.2Tbps，双向带宽较前代提升50%，让芯片组成的“计算立方体”实现低延迟数据交换；第二层通过动态光电路交换机（OCS）将多个“计算立方体”连接成更大集群，该交换机还能动态重构，避开故障单元保障稳定性；第三层则通过远程直接内存访问技术，让9216块芯片可直接高速交换数据，整个节点的可访问HBM总容量达1.77PB。
3. 整体集群与配套设计：整个超级计算节点包含144个机柜，集成了光交换设备和液冷单元，适配接近10兆瓦的总功率需求，解决大规模集群的散热难题。9216块芯片协同工作时，总算力可达42.5艾级算力（ExaFLOPS，以FP8精度计算），谷歌称该算力是当前最强超级计算机相关系统段的24倍。
4. 软硬协同优化体系：谷歌为该架构搭配了专属软件生态，通过XLA编译器自动融合运算指令，大幅提升执行效率。同时适配JAX框架和PyTorch框架，开发者借助定制内核或Pallas编程语言，可灵活管理内存层级与数据流转，既能发挥硬件最大性能，又能降低超大规模集群的开发适配难度。

1. 算力、功率与算力密度对比
   • 谷歌Ironwood集群：9216颗TPU芯片分布在144个机柜中，单机柜仅64颗芯片，集群总功率10兆瓦，总算力达42.5 ExaFLOPS（FP8精度）。单颗Ironwood TPU算力为4614 FP8 TFLOPS，配备192GB HBM3E内存，单卡HBM带宽约7.37 TB/s。
   • 曙光scaleX640：单机柜就能容纳640张加速卡，算力密度恰好是谷歌Ironwood单机柜的10倍。其单机柜FP16算力达630 PFlops，单机柜功率为0.86兆瓦（支持860kW以上供电），还可通过“一拖二”架构组成1280卡计算单元。若按谷歌集群144个机柜规模换算，曙光集群总功率约123.84兆瓦，但总算力会远超谷歌（仅144个机柜的曙光集群算力就达630PFlops×144=90720PFlops=90.72 ExaFLOPS，且这还是FP16精度，而谷歌42.5 ExaFLOPS是FP8精度，FP8精度算力统计口径本就比FP16易出高值）。
2. 曙光scaleX640无法支持640块Ironwood TPU运行
   这并非供电不足导致（曙光单机柜860kW供电，按单颗Ironwood TPU常规功耗估算，640颗总功耗大概率未超阈值），核心问题在架构和生态不兼容。一是接口与控制逻辑不匹配，曙光scaleX640针对多品牌国产加速卡设计，接口和总线控制器是适配主流PCIe相关规范的开放架构，而Ironwood TPU依赖谷歌自研的Inter-Chip Interconnect（ICI）互连技术和Axion CPU协同控制，并非标准PCIe设备，无法直接插入曙光的插槽使用。二是散热适配性不足，曙光靠浸没相变液冷控制国产加速卡的散热，Ironwood TPU虽也用液冷，但两者的散热回路、芯片封装热设计不同，强行适配会导致散热效率骤降，进而引发硬件故障。
3. 高带宽性能对比
   两者的带宽优势各有侧重，曙光胜在集群整体带宽，谷歌强在单卡HBM带宽，具体对比如下：
   表格

   性能维度	谷歌Ironwood	曙光scaleX640
   单卡HBM带宽	约7.37 TB/s（HBM3E）	未披露单卡数据，整机柜HBM总带宽2304 TB/s，分摊到640张卡后单卡约3.6 TB/s
   片间互连总带宽	未披露集群总量，单芯片间双向带宽1.2 Tbps	单机柜片间互连总带宽573 TB/s，与华为昇腾384超节点持平，支撑多卡协同无压力
   互联架构	3D环面拓扑+光路交换技术，支持芯片群点对点通信，故障可自动绕路	超高速正交架构，构建层次化互连网络，适配万卡级集群扩展，长稳运行能力突出

一、适配前提：找与 Ironwood TPU 算力对等的加速卡及适配限制

1. 对等算力卡的选择：Ironwood 单卡 FP8 峰值算力达 4614 TFLOPs，目前暂无市售公版卡完全持平，但可选用组合或定制方案。比如 2 张英伟达 H20（单卡 FP8 算力约 2400 TFLOPs）并联，单组算力可达 4800 TFLOPs，基本匹配 Ironwood；也可选用国产高端定制 NPU（如华为昇腾 910B 进阶版，通过工艺优化可逼近该算力级）。
2. 曙光 scaleX640 的适配限制：供电上，scaleX640 单柜功耗 860 千瓦，若用上述双 H20 组合等效 1 张 Ironwood 算力，单柜可装 320 组（等效 320 张 Ironwood 级算力），功耗约 800 千瓦（单 H20 功耗约 2.5 千瓦），留有冗余；若有单卡功耗与 Ironwood（按液冷下约 3 千瓦估算）相当的单卡，640 张总功耗 1920 千瓦，远超单柜 860 千瓦上限，需双柜并联。带宽上，其支持 PCIe 5.0 与 CCIX 双协议，单链路带宽 800GB/s，能适配高算力卡的数据传输需求，无明显瓶颈。

二、算力规模：曙光以 15 柜追平谷歌，能效与密度占优

1. 核心算力量化计算
   表格

   架构	核心参数	等效算力规模	所需机柜数	总功耗
   谷歌 Ironwood	单卡 4614 TFLOPs，共 9216 卡	9216×4614 TFLOPs≈42.5 Exaflops	144 柜（64 卡 / 柜）	10 兆瓦
   曙光 scaleX640	单柜 640 张对等算力卡	单柜 640×4614 TFLOPs≈2.95 Exaflops	15 柜（42.5÷2.95≈14.4，取整 15 柜）	15×860 千瓦 = 12.9 兆瓦
2. 结论：曙光用 15 柜就能达到谷歌 144 柜的算力规模，算力密度是谷歌的 9.6 倍。虽总功耗比谷歌高 29%，但考虑到曙光是开放架构，而谷歌是定制化封闭架构，前者在扩展灵活性上的优势可抵消小幅功耗劣势。若曙光采用双柜并联解决单卡功耗超标的问题，达到同等算力需 30 柜，算力密度仍是谷歌的 4.8 倍。

三、总线与内存带宽：谷歌专属总线时延占优，曙光开放架构有兼容优势

1. 总线性能对比
   • 谷歌 Ironwood：用自研 ICI 总线，双向带宽 1.2 Tbps，3D 环形拓扑搭配 Pathways 软件栈，卡间时延可低至数百纳秒（参考前代 TPU v4 单跳时延＜300 纳秒，Ironwood 预计更低）。
   • 曙光 scaleX640：通过超高速正交架构优化，卡间时延≤2 微秒，虽比谷歌高约 3 - 6 倍，但支持开放协议，可兼容多品牌算力卡，而谷歌 ICI 仅适配自家 TPU，扩展性受限。
2. 内存带宽对比
   • 谷歌 Ironwood：单卡 HBM 容量 192GB、带宽 7.2 Tbps，9216 卡总 HBM 带宽约 66.37 Pbps，且 ICI 总线与 HBM 协同优化，无数据传输断层。
   • 曙光 scaleX640：单机柜卡间互联带宽超 570 TB/s，若插 640 张对等算力卡（单卡 HBM 带宽 7.2 Tbps），总 HBM 带宽约 4.61 Pbps，仅为谷歌的 7%，但可通过外置分布式存储补充，适配非极致内存需求的场景。

四、架构优劣总评：谷歌强于极致性能，曙光胜在开放与密度，综合比值 1:0.7

1. 谷歌 Ironwood 优势（得分核心）：自研 ICI 总线 + Pathways 软件栈实现 “算力 - 带宽 - 时延” 的极致协同，适合超大规模 MoE 模型等对通信要求极高的场景，且单卡与集群的能效比领先，10 兆瓦支撑 42.5 Exaflops 算力，能效是曙光的 1.2 倍左右。
2. 曙光 scaleX640 优势（关键加分项）：算力密度是谷歌的 4.8 - 9.6 倍，开放架构可灵活搭配不同品牌算力卡，支持十万卡级扩展，且液冷方案 PUE 低至 1.04，长期运维成本更低，适合需要灵活调整算力配置的企业级场景。
3. 曙光短板：总线时延和集群级总内存带宽与谷歌差距明显，在超大规模推理场景中，数据传输效率可能导致 15% - 25% 的性能损耗，这是其综合得分低于谷歌的核心原因。

1. 单柜算力密度：曙光scaleX640全球第一，谷歌、英伟达差距显著
   曙光scaleX640是全球首个单机柜640卡超节点，单柜算力密度较业界同类产品提升20倍，这个卡量远超谷歌和英伟达的单柜配置。谷歌Ironwood TPU单机柜仅64块芯片，英伟达GB200的NVL72整机架系统也远达不到640卡规模。即便谷歌单颗TPU v7算力约4.61 PFLOPS，英伟达GB200单卡推理算力达20 PFLOPS，二者单卡算力远超普通算力卡，但单柜总算力仍不及曙光。按普通中端算力卡（如英特尔Gaudi3约1.835 PFLOPS）测算，谷歌、英伟达单卡仅能超过普通卡2 - 10倍，没有10倍以上的绝对倍差弥补10倍的卡量差距，所以曙光单柜算力密度当前全球无人能及。
2. 互联延迟与吞吐量：谷歌ICI、英伟达NVLink大幅领先曙光PCIe
   三者的互联性能差距明显，谷歌和英伟达的专属技术在延迟和吞吐量上碾压PCIe，和你“算力密度弱但数据吞吐强”的判断一致。英伟达第五代NVLink延迟仅1.5微秒，双向带宽最高1.8TB/s，而PCIe 5.0 x16带宽仅128GB/s，NVLink带宽是PCIe的14倍。谷歌Ironwood TPU的ICI技术采用3D环形布局，搭配HBM3E内存实现7.37TB/s单卡带宽，其Superpod集群通过1.8PB网络连接，互连密度和可扩展性突出，延迟虽无公开具体数值，但显著低于PCIe。曙光scaleX640虽优化PCIe架构将延迟压至两微秒内，可和NVLink、ICI比仍有明显差距，吞吐量更是相差数倍到十多倍。
3. 能耗比：英伟达GB200最优，曙光次之，谷歌TPU表现中等
   能耗比需结合单柜功耗和单位算力能耗综合看。英伟达GB200单卡功耗2700W，但能效比达1.9，其NVL72整机架系统单柜功耗约120千瓦，在兼顾训练与推理的通用场景中能效顶尖。曙光scaleX640单柜功耗860千瓦，虽功耗偏高，但依托浸没相变液冷技术实现1.04的超低PUE，且针对MoE大模型场景有30%-40%的性能提升，单位算力能耗比在高密度集群中表现优异。谷歌Ironwood TPU集群总功耗10兆瓦（9216卡），单柜功耗约69.4千瓦，单颗TPU能效比低于英伟达GB200，仅比前代提升两倍，在专用推理场景中能效合格，但不及英伟达通用场景的能效优势。

1. 大模型训练中数据吞吐的用途、重要性及瓶颈原因
   • 核心用途：数据吞吐负责支撑模型参数、训练数据和中间结果的传输。比如加载TB级的Checkpoint文件用于故障恢复，训练迭代时传输随机数据供算力卡运算，保存模型状态时聚合分散的参数，这些环节都依赖高吞吐保障效率。
   • 成为瓶颈的关键：大模型参数动辄千亿级，训练时需高频传输海量中间数据。像MoE等架构用3D并行切分模型后，单卡仅存部分参数，聚合时易引发网卡带宽拥塞；且Checkpoint写入时带宽峰值可达200+GBps，若吞吐不足，会导致数千张算力卡长期等待，直接拖慢整体训练进度。这种需求并非贯穿全程，在初始化加载数据、周期性保存Checkpoint、并行训练参数聚合等阶段是高峰，常规迭代计算阶段带宽需求相对较低。
2. 算力卡间数据交换的场景及实现架构
   • 交换场景：核心是配合模型并行、数据并行等训练模式。比如数据并行时，多张卡需同步梯度更新参数；模型并行时，不同卡运算的模型分段结果要汇总；还有Checkpoint保存时，分散在各卡的模型状态需聚合为完整模型，这些都离不开卡间数据交换。
   • GPU自交换数据的架构：靠对等直接通信架构实现，比如NVIDIA的NVLink、PCIe的对等模式，并非改变冯诺依曼模式，而是优化了设备间通信路径。这类架构让算力卡无需经CPU中转，通过硬件链路直接互联，再搭配专用编程框架调度数据传输，并非GPU自身有“智能”，而是架构和软件协同的结果。
3. PCIe能否支持卡间直接交换数据
   PCIe能实现卡间直接交换数据。早期PCIe设备依赖CPU中转，但现代PCIe支持对等（Peer-to-Peer，P2P）通信模式，满足条件的算力卡可通过PCIe链路直接传输数据。不过PCIe的带宽和延迟表现不如NVLink这类专用互联技术，更适合中小规模的卡间通信，大规模训练中常作为辅助互联方案。
4. 非NVIDIA架构的算力卡也能实现卡间交换数据
   这并非NVIDIA CUDA或其架构的专属能力。谷歌TPU靠自研的ICI互联技术实现集群内高速通信，华为昇腾NPU有华为自研的HCCS互联接口，开源领域还有DisTro技术能支持不同型号CPU、GPU的异构设备跨网络协同训练，通信量可降低1000倍以上。只是不同厂商的互联协议和编程框架不同，需针对性适配，不像NVIDIA生态那样统一。
5. 曙光Sky X640集成异构算力卡的意义及协同通信实现方式
   它集成异构卡绝非仅提供供电，而是能实现高效协同，核心靠标准化适配和技术优化解决了通信与编程问题：
   • 通信层面：该设备有超高速正交架构，能将640张加速卡的数据传输时延控制在微秒级，且遵循统一的硬件接口和软件协议标准，可无缝接入寒武纪、沐曦等不同品牌芯片，同类型卡能直接互联，不同类型卡可通过机柜的统一调度层间接传输数据，并非无法通信。
   • 编程与集成意义：软件上兼容TensorFlow、PyTorch等主流AI框架，还优化了对CUDA生态的适配，能降低多架构卡的应用迁移成本。其集成意义在于适配大模型训练、科学计算等多元场景，比如让GPU负责矩阵运算、NPU负责边缘推理相关计算，通过统一平台调度分配任务。
   • 异构卡协同编程：靠统一的算力管理平台和标准化接口实现。开发者无需单独对每种卡编程，而是通过平台将任务拆解后分配给适配的算力卡，再通过机柜的互联架构完成数据流转，比如山东港口项目中，它就实现了海光芯片工作站与自身的“端 - 边 - 云”数据联动，大幅提升了作业效率。

一、卡间数据交换的本质：并行切分后的 “协同更新”

1. 先 “分片”：大模型拆给多卡算

   千亿参数的大模型（比如 7168 维的矩阵），单卡内存装不下、也算不完，就像把一本厚书拆成 3 份给 3 个人抄。常见的切分方式有两种：
   • 你说的 “多头并行（Multi-Head）”：把模型的 “注意力头” 分给不同卡，比如 12 个注意力头拆给 3 张卡，每张卡算 4 个；
   • 模型并行：把超大规模矩阵按维度切分，比如 7168 维的矩阵拆成 3 份（2000+2000+3168），每张卡算自己的分片；
   • 数据并行：多张卡算同一模型，但各自用不同训练数据，最后同步结果。
2. 再 “交换”：结果互相影响，必须聚合更新

   不是简单合并，而是 “你的结果要改我的参数，我的结果也要改你的参数”，比如：
   • 模型并行时，A 卡算完矩阵分片后，需要 B 卡的分片结果才能完成整个矩阵运算（比如矩阵乘法的部分结果要拼接）；
   • 数据并行时，3 张卡各自算完 “梯度”（比如 “这个参数该调大还是调小”），必须把 3 个梯度聚合（比如取平均），再把聚合后的 “最终梯度” 发回每张卡，让所有卡的模型参数同步更新 —— 否则每张卡的模型会越跑越不一样。
3. 流程闭环：分片→计算→聚合→分发→再计算

   这和 MapReduce 的 “Map→Shuffle→Reduce” 逻辑一致，但更紧凑：

   切分任务（Map）→ 各卡并行计算 → 卡间交换数据聚合结果（Reduce，不用回 CPU）→ 聚合后的参数重新分发（再 Map）→ 进入下一轮迭代。

   全程只有 “最终模型保存” 才需要回 CPU，中间交换都在卡间完成，效率大幅提升。

二、卡间直接交换数据：靠 PCIe DMA，无需 CPU 插手

• DMA（直接内存访问）的核心是 “设备绕开 CPU，直接读写其他设备的内存”；
• 现代 PCIe 支持 “对等通信（Peer-to-Peer，P2P）”，只要两张卡都支持 DMA，就能通过 PCIe 链路直接发起数据拷贝请求：比如 A 卡要给 B 卡传数据，A 卡的 DMA 控制器直接通过 PCIe 总线写进 B 卡的显存，全程 CPU 只需要 “发个启动指令”，之后就不用管了。

一、超大显存的核心优势：从根源消除卡间交换

• 所有矩阵运算都在单卡内完成，无需拆分成小矩阵分发，避免了切分和汇总的额外开销；
• 完全不用考虑卡间通信时延和带宽瓶颈，训练效率就是单卡的极限算力，逻辑上最简洁。

二、超大显存的现实瓶颈：物理与成本的双重限制

1. 物理极限不可突破：显存容量受芯片封装、功耗和散热制约。比如 HBM3e 显存的单栈容量有限，要做到 1TB 显存，需在 GPU 芯片上集成数十个 HBM 栈，不仅封装难度极大，还会导致芯片面积暴增、功耗突破千瓦级，现有液冷技术也难以支撑；
2. 成本高到无法承受：显存是 GPU 成本的核心组成部分，192GB HBM3e 的成本已占高端 GPU 的 50% 以上，若要做到 1TB 显存，单卡成本可能突破 10 万美元，大规模部署（如千卡集群）的成本会是天文数字；
3. 算力与显存的 “错配浪费”：大模型训练不仅需要 “装得下”，还需要 “算得快”。单卡显存再大，其算力核心（如 CUDA 核心、Tensor 核心）的并行能力也是有限的，面对万亿参数模型，单卡计算周期可能长达数月，远不如千卡集群并行（几天完成）高效。

三、“分片并行 + 优化通信”：当前最优的平衡方案

1. 计算与通信重叠：在卡间传输数据时，GPU 同时进行下一轮计算（比如 A 卡传数据给 B 卡时，A 卡已经开始算下一个小矩阵），不会让算力卡 “空等”；
2. 通信压缩技术：对传输的梯度、参数进行压缩（比如量化成 FP4 精度），数据量减少 75%，传输时间大幅缩短；
3. 拓扑优化：像曙光 ScaleX640 的正交互联、英伟达的 NVLink 网络，让卡间通信时延压至微秒级，带宽提升至 TB/s 级，通信开销占比可低至 5% 以下；
4. 按需分片：仅对 “装不下的超大规模矩阵” 分片，中小规模矩阵仍在单卡内计算，平衡并行效率与通信成本。

总结：显存大小与并行架构的取舍逻辑

• 短期（1-3 年）：“大显存 + 优化通信” 双轮驱动。比如用 24GB 显存的 GPU 做数据并行（单卡装下完整模型），用 80GB 以上显存的 GPU 做模型并行（减少分片数量），同时靠高速互联降低通信损耗；
• 长期（5 年以上）：若新型存储技术（如 3D 堆叠内存、存算一体芯片）突破，实现 “单卡 1TB + 低功耗 + 低成本”，则 “单卡算全模型” 可能成为主流，卡间通信将不再是瓶颈。

单卡 1TB 显存 vs 100 张 80GB 显存并行：成本与效率对比表

补充说明：

1. 单卡 1TB 显存的成本与功耗为行业预估，基于当前 HBM3e 显存成本（约 500 美元 / GB）和封装技术极限推算，实际量产可能面临更高成本；
2. 并行方案的通信开销占比（10%）基于曙光 ScaleX640 的正交互联架构（时延≤2 微秒）计算，若用普通 PCIe 架构，通信开销可能升至 15%-20%；
3. 训练效率相对值以 “单卡 1TB 显存的训练速度” 为基准，并行方案的总算力为 100 张卡算力总和的 95%（扣除通信损耗）。

一、三角平衡的核心逻辑：谁是瓶颈，就围绕谁优化

1. 显存与带宽互补：显存够大（仓库够大），可一次性存更多任务数据，减少传送带往返次数（带宽压力降低）；反之，带宽够快（传送带够宽），即便仓库小，也能快速补料，避免工人等料。
2. 算力与前两者匹配：工人（算力）效率再高，若仓库小（显存不足）或传送带慢（带宽不够），只能停工等待；若工人效率低，仓库再大、传送带再快，也会造成原料堆积（显存浪费）和传送带闲置（带宽浪费）。
3. 优先级排序：显存＞带宽＞算力（短期）。因为显存不足会直接导致任务分片过多，触发大量卡间通信，进而让带宽拥堵，最终拖慢整体效率；而算力冗余可通过 “计算与通信重叠” 弥补（比如传数据时同步算下一批任务）。

二、针对曙光 ScaleX640 的优化方案：以 PCIe 带宽为锚点，反向适配

1. 显存配置：优先选大显存卡，减少分片与通信

   既然带宽固定，就用大显存减少数据传输次数。比如选 80GB HBM3 显存的卡（而非 40GB），单卡可承载更大模型分片，原本需 2 张卡切分的任务，现在 1 张卡就能完成，卡间通信量直接减半，避免带宽拥堵。

   适配建议：单卡显存≥模型单分片大小的 1.5 倍（预留中间结果空间），尽量让 80% 的任务在单卡内完成，仅 20% 超大规模任务需卡间通信。
2. 算力配置：选 “算力 - 带宽比” 适配的卡，避免算力冗余

   不盲目选顶级算力卡，而是选算力与 PCIe 带宽匹配的型号。比如某卡 FP16 算力 1000 TFLOPS，若其显存带宽 7.2TB/s，与 PCIe 5.0 的 128GB/s 搭配，刚好能让 “计算速度” 与 “数据传输速度” 同步 —— 算完一批数据，下一批数据也正好通过 PCIe 传到位，无空闲等待。

   适配建议：算力卡的 “显存带宽 ÷ 算力”≈任务的 “数据量 ÷ 计算量”（比如大模型训练的 “数据量 ÷ 计算量” 约 0.01 TB/TFLOPS），确保数据供应与计算节奏匹配。
3. 任务分配：按 “带宽阈值” 拆分，避免通信过载

   针对固定带宽，设定 “单卡通信上限”：比如每张卡每秒最多通过 PCIe 传输 100GB 数据（预留 28GB/s 冗余），任务分配时确保所有卡的通信量不超此阈值。

   具体做法：
   • 数据并行：同型号卡按 “显存大小” 分配数据，大显存卡多承担数据量，减少卡间同步次数；
   • 模型并行：仅对超大规模矩阵（如 7168 维以上）切分，且分片大小≥PCIe 单次传输最优值（比如 16GB，避免小数据频繁传输浪费带宽）；
   • 异构协同：让 GPU（算力强、显存大）承担核心计算，NPU/TPU（带宽适配好）承担辅助计算，统一调度层按带宽能力分配数据传输任务。

三、实例验证：固定 PCIe 带宽下的最优匹配

• 显存：单卡 80GB，可承载 125 亿参数分片（1 万亿参数 ÷80 张卡），无需过度切分；
• 带宽：640 张卡同时通信，单卡平均占用带宽≈573TB/s÷640≈900GB/s，远低于 PCIe 单链路上限，无拥堵；
• 算力：640×1000 TFLOPS=640 PFLOPS，计算与通信重叠后，实际效率达 90%（576 PFLOPS），无算力闲置。

总结：平衡的关键是 “让短板变长，而非让长板更长”

1. 你对 PCIe 5.0 128G/s 的认知存在偏差：你提到的 128G/s 大概率是混淆了单位或通道数。PCIe 5.0 单通道（单 lane）单向有效带宽约 4GB/s，而显卡、AI 算力卡这类设备常用 x16 多通道配置，其单向理论有效带宽约 63GB/s（16 通道 ×4GB/s），这个数值远高于 900GB/s 的说法显然不对，推测是原始表述可能存在笔误，合理的单卡占用带宽应是远低于 63GB/s 的数值。
2. 多卡集群常搭配超高速互联方案，非普通 PCIe 链路：640 张卡这种大规模集群场景，不会用普通 PCIe 链路做卡间互联，通常会搭配 NVLink、PCIe 5.0 x16 聚合链路等方案。比如 PCIe 5.0 x16 的单向理论带宽就达 63GB/s，若再结合多链路绑定或 NVLink，单卡对应的互联上限会更高。此时即便单卡占用几十 GB/s 带宽，也会远低于这种高规格链路的上限，自然不会拥堵。
3. 原始数据或存在单位笔误：573TB/s 的总带宽对 640 张卡的集群来说过于夸张，更可能是 573GB/s 这类单位写错。若按 573GB/s 计算，单卡平均占用约 0.9GB/s，这个数值和 PCIe 5.0 单通道 4GB/s、x16 通道 63GB/s 的上限相比，差距极大，完全达不到链路拥堵的阈值。

一、先纠正关键概念：PCIe 5.0 的 “通道” 与 “带宽上限”

1. PCIe 的核心是 “通道（Lane，简称 L）”：
   PCIe 的带宽按 “通道数” 叠加，单条通道（x1）是基础单位，设备可支持 x1、x4、x8、x16 等通道配置（最多 16 通道）。
2. PCIe 5.0 的单通道带宽：
   单条 PCIe 5.0 通道（x1）的双向有效带宽约 8GB/s（单向 4GB/s，含编码损耗）；
   若用 x16 通道（显卡 / 算力卡常用配置），则双向总带宽 = 8GB/s×16=128GB/s—— 这就是之前说的 “单链路 128GB/s” 的本质（这里的 “链路” 实际是 “x16 通道组”）。
3. 结论：PCIe 5.0 单设备最大支持 x16 通道，双向带宽 128GB/s，你的 “128G×16” 是混淆了 “单通道带宽” 与 “通道数”，正确逻辑是 “单通道 8GB/s×16 通道 = 128GB/s（x16 总带宽）”。

二、曙光 ScaleX640 正交互联总带宽 573TB/s 的计算逻辑

1. 正交互联的本质：所有 640 张卡实现 “两两直连”，每对卡之间都有独立的 PCIe 5.0 x16 链路（双向 128GB/s），无需中间转发。
2. 总带宽计算方式：
   集群总带宽 = 单链路带宽 × 直连链路总数；
   直连链路总数 = 组合数 C (640,2)=640×639÷2=204480 条；
   单链路双向带宽 = 128GB/s=0.128TB/s；
   理论总带宽 = 204480×0.128TB/s≈26173TB/s（这是理论值，实际会因硬件设计精简部分链路）。
3. 573TB/s 的实际含义：
   厂商标注的 “573TB/s” 是可用聚合带宽（非理论峰值），即所有卡同时通信时的总数据传输能力。其计算逻辑是 “按实际业务场景精简链路”，比如优先保障同模块、同机柜内卡的直连，跨模块链路按需启用，最终实测可稳定提供的总带宽约 573TB/s，远高于普通 PCIe 集群（通常≤10TB/s）。

总结关键公式与结论