铜缆支撑 AI 算力扩容的时代正在落幕
加入技术交流群
随着 AI 集群突破单机柜算力边界，光互连与电路交换正在重塑数据中心扩容模式
核心要点
横向扩展（Scale-up）的边界将突破单机柜，长距离链路将采用光互连。
光电路交换（OCS）技术的应用范围或将不再局限于谷歌。
板级扩展（Scale-in） 是全新扩容术语，特指单台服务器板卡内部的算力互联规模。
随着光互连在 AI 集群互联中承担愈发重要的角色，并延伸至横向扩展域、影响整体网络拓扑设计，数据中心网络架构正迎来新一轮变革。
过去，横向扩展（Scale-up）一般定义为单机柜内依靠铜缆互连，开发者可使用内存语义进行编程。但如今这套定义已经变得模糊。
Rambus 院士、杰出发明家 Steven Woo 表示：“‘横向扩展用铜缆、向外扩展用光互连’这条旧界限正在消融。机柜内部数据速率持续攀升，铜缆在信号损耗、传输距离与功耗方面遭遇物理瓶颈，即便机柜内部链路也感受到明显约束。从信号传输角度，在高速率场景下光互连具备更可持续的扩容路径，但前提是在相对短距离内实现可控功耗与可靠运行。”
降低时延是所有变革的核心驱动力。GPU 会因等待数据而无法充分发挥算力。Omnitron 联合创始人兼首席执行官 Eric Aguilar 谈道：“大量报告显示，很多 GPU 算力利用率仅有 25%，大量算力闲置，只是在等待数据抵达。”
与此同时，谷歌部署了采用环面（Torus）拓扑的光电路交换（OCS）网络，其他企业也开始考虑将 OCS 引入各类网络架构。
架构变革之下，业界需要重新厘清 AI 数据中心网络各类扩容术语的演变。
扩容理念持续迭代
面向 AI 负载，数据中心形成了层级不断演变的扩容体系，分为横向扩展（Scale-up）、向外扩展（Scale-out）、跨域扩展（Scale-across）。 近期，板级扩展（Scale-in） 这一新概念正式出现。Ayar Labs 产品负责人 Vishal Chandrasekar 解释：“这个术语诞生仅三个月，特指 GPU 输出带宽中，保留在同一机箱内部的互联流量。”
此前各类扩容模式的定义总结如下：
板级扩展（Scale-in）：单台服务器、单块板卡内部处理器之间的互联。
横向扩展（Scale-up）：机柜内部，依靠铜缆布线，支持内存语义编程。（注：该定义现已过时）
向外扩展（Scale-out）：机柜与机柜之间互联，采用以太网 RDMA 语义，越来越多地使用光互连。
跨域扩展（Scale-across）：不同数据中心园区之间，依靠光纤传输。
除新增 Scale-in 概念外，Scale-up 自身定义也在演变。计算集群规模突破单机柜边界，纳入相邻机柜服务器。互联距离拉长后，铜缆不再是最优介质，光纤开始渗透进入 Scale-up 域。
Chandrasekar 分析：“链路局限在单机柜内，大概率继续使用铜缆；连接相邻机柜则处于临界点，部分方案仍沿用铜缆；一旦跨越相邻机柜，就必须采用光互连。”
关于光互连的距离阈值：“假设信号速率 200Gbps，铜缆适用上限大约 5 米；极限优化条件下最多支撑 7 米。一旦达到 10 米及以上，就必须使用光互连。”
传统 Scale-up 三大特征：单机柜、铜缆、内存语义。如今前两项逐步被打破，仅剩内存语义作为核心判定标准。
新思科技接口 IP 产品总监 Priyank Shukla 表示：“软件工程师定义的 Scale-up，是单个操作系统域共享统一地址空间。程序发起写入操作时，处理器能够访问统一内存地址，无论这块内存物理位置在哪里。”
经典 Scale-up 与 Scale-out 架构都会尽量减少网络跳数。Chandrasekar 介绍：“在 Scale-up 域中，任意两块 GPU 之间仅一跳可达；而 Scale-out 场景普遍需要两跳。”
全新 UALink 标准固化了 Scale-up “单跳” 设计目标。Shukla 解释：“UALink 横向扩展互联架构，保证加速器之间仅经过一台交换机一跳连通。即便 Scale-up 域扩展到多个机柜，加速器之间通信依旧只经过一台 UALink 交换机。 交换机可以部署在机柜顶部（ToR）或者机柜中部（MoR），核心是两端加速器流量仅经过一次交换机转发。”
当 Scale-up 域跨越多机柜后，时延与跳数约束让行业关注点从传输介质，延伸至连接加速器、交换机、服务器的整体网络拓扑。
网络架构
服务器互联方式直接影响功耗与性能，但不存在万能拓扑，不同负载适配不同架构。
最主流方案是克洛斯网络，也常称为叶脊网络（Leaf-Spine）。两台服务器之间路径简短。尽管该架构应用广泛，但头部企业的 AI 网络采用了完全不同的方案。
Chandrasekar 指出：“谷歌没有使用叶脊网络，而是采用环面（Torus）网络。每一颗 TPU 与相邻 TPU 互连，具备上、下、右三个方向连接，形成类似脉动阵列的互联特征。”
图 1：两种网络架构。上图为叶脊网络，任意服务器之间一跳可达；下图为环面网络，两端服务器之间通常需要多跳。 来源：Bryon Moyer / Semiconductor Engineering
两类架构核心差异在于服务器互通所需跳数：叶脊网络仅一跳；环面网络路径取决于节点位置，示例链路需要四跳。
Chandrasekar 表示：“如果数据需要从集群一端 GPU 传输至另一端 GPU，中间会经过大量转发跳数。足够长的链路可以采用光互连优化功耗与性能。但数据包交换模式带来天然损耗：每一跳都需要解析数据包。交换机、路由器必须读取报文头部信息。”
光器件无法识别数据包。上述四跳链路中，每一跳都需要完成光信号→电信号转换；解析路由后，再次转回光信号继续传输。
节点上反复进行光电转换，推高时延、消耗大量电能。我们是否拥有更理想的光网络实现方案？
电路交换：回归经典思路
如今数据包交换早已深入人心，但它并非最早的网络技术。早期全国电话网使用的就是电路交换。电路交换会预先搭建一条源端直达目的端的完整通路，专属分配给单一数据流。早年通话场景中，线路接通后，整条链路独占，通话结束前其他用户无法占用。
可以用公路出行类比：假设从洛杉矶驱车前往波士顿。现实中道路由所有车辆共享，每个路口都可以重新规划路线。所有人都清楚，交通信号灯会造成拥堵。如果整条公路全程为你单独预留，无需任何等待，通行效率将大幅提升。这正是电路交换网络的特点。 一套后台控制网络会在数据流传输前完成通路配置。传统电话网络中，对应的标准为七号信令系统（SS7）。
电路交换的短板显而易见：即便你的车辆还行驶在加州，波士顿附近的路段也被全程锁定，无法分配给其他传输任务，资源利用率看起来很低。
数据包交换：适配碎片化流量
数据包交换很好地解决了上述问题。可以理解为道路系统配备红绿灯、互通立交，允许多股车流同时前往不同目的地。将路口替换为路由器、道路替换为传输线缆，就是数据包交换网络的核心原理，也是当前网络领域的主流标准。
当下数据中心面临的独特难题，正是数据包路由引发的反复光电转换。Aguilar 解释：“数据传输流程大致为：信号进入光纤，抵达电交换机，光信号转为电信号，解析数据包，再路由转发至另一块 GPU。这套光电 - 电光转换循环消耗巨额功耗、增加时延，抬高数据中心运营成本。大约 15 年前谷歌启动相关研究，十年前落地基于微机电系统（MEMS）的光电路交换机（OCS）。”
谷歌方案的核心是路由器内部可调 MEMS 微镜。微镜将源光纤入射激光反射至目标光纤。所有节点提前完成光路配置，数据传输全程无需光电转换，这套技术即为光电路交换（OCS）。
谷歌落地实践
谷歌验证了 OCS 的价值。谷歌 AI 与基础设施高级副总裁、首席技术官 Amin Vahdat 在 2022 年论文中提到：“过去八年，我们将 OCS 与波分复用（WDM）深度集成至 Jupiter 网络。 OCS 结合软件定义网络（SDN）架构带来多项能力：支持异构设备分阶段扩容；性能提升、时延、功耗与成本同步优化；支持基于应用优先级、通信流量特征实时调度；支持业务零中断升级。 对比传统方案，Jupiter 网络数据流完成时间缩短 10%，吞吐提升 30%，功耗降低 40%，成本下降 30%，网络中断时长减少 50 倍。”
功耗降低来自多重优化。Aguilar 说明：“方案减少一半光模块，省去配套液冷设施，同时移除交换机内部 ASIC 与相关电路，全部由光学器件替代。”
在 OCS 网络中，两台服务器之间需要传输海量数据时，后台网络先配置整条链路所有微镜，搭建直通光路，随后数据流持续传输，中途不再路由、无需信号转换。 但该模式有明确限制：同一数据流全部源自同一节点、流向单一目标，不能拆分转发至多个节点。因此 OCS 属于面向特定负载的优化方案。
如果用来承载大量短脉冲数据流，通路建立、拆除消耗的时间甚至超过数据传输时长。沿用公路类比：全程预留道路适合超长车队通行。道路全程被占用、不存在闲置路段，对应适合 OCS 的长数据流。
Aguilar 表示：“业内常把这类持续大流量称为‘大象流’。OCS 对大象流适配性极佳，远优于大量零散‘老鼠流’，非常适合 AI、大模型训练与推理业务。”
OCS 需要在有效载荷传输前预留端到端光路，因此控制平面的通路配置能力直接决定方案效果。
新一代信令控制网络
数据流发起传输前，后台网络负责配置光路微镜。类似传统七号信令系统，一套低速以太网控制网络与光网络并行运行。 “依靠低带宽以太网网络下发指令，重新配置交换机与数据通路。”Aguilar 说道。
通路重配置耗时不长，但依旧存在延迟，这也是它仅适合长数据流的原因。不过，网络配置本身并非瓶颈。“真正的瓶颈在于光模块信号锁定（transceiver lock）。”
用两套网络替代一套看似更加复杂，但控制网络架构十分简洁。“我们依旧依靠以太网实现机柜互联，调度光路资源，整体方案简洁优雅，资本投入增幅有限。以太网交换机成本低廉，仅作为低带宽指令调度中心。”
数据包交换与电路交换混合部署
图 1 中的环面网络采用点对点连接，多跳链路可以受益于电路交换。叶脊网络架构存在大量交换机与路由器，这套拓扑是否同样能够引入 OCS？
环面网络的数据流为端到端传输。叶脊架构同样可以实现，但跳数更少，功耗优化空间相对有限。不少企业正在评估一种方案：叶脊网络上层采用 OCS，源路由器将多个数据包打包，通过光通路传输至目的路由器；到达后解包，再通过电交换转发至最终节点。
新思科技 Shukla 解释：“OCS 光链路终止于交换机，后续传输恢复电信号交换。”
图 2：电路交换与数据包交换混合架构。上图展示树形网络内端到端光路；若光路仅覆盖路由器之间链路，数据包可在源路由器聚合，抵达目的路由器后解包，通过电交换完成最终转发。 来源：Bryon Moyer / Semiconductor Engineering
只要流量足够稳定，并且源路由器内多个数据包的目标节点都连通至同一台末端路由器，两台交换机之间就值得搭建专属光路。如图 2 所示，架构表面看似简单，但当路由器之间链路复杂、途经大量节点时，混合方案具备显著价值。
谷歌 OCS 已经落地，并且其网络正在从环面拓扑升级为蜻蜓（Dragonfly）拓扑。其他厂商尚未大规模部署环面或树形 OCS 网络，但行业消息显示，多家企业正在评估 OCS 适配各类网络架构。
Chandrasekar 表示：“业界正在探讨：能否在叶脊架构中，第二层网络采用 OCS，第一层保留传统数据包交换？”
向光网络过渡具备可行性。Aguilar 谈道：“改造现有数据中心无需大规模重建。可通过改造部署这套方案，既能降低功耗，也能在现有机房内提升算力容量。”
光网络一旦建成，具备长期兼容能力。光纤本身不区分光模块、内存、处理器代际。后端芯片迭代升级，不需要重新铺设网络。
但整套思路仍处于行业研讨阶段。Chandrasekar 补充：“目前更多处于探索阶段，暂无大规模商用部署案例。”
光互连持续渗透
上述两大方向都意味着光互连在数据中心的占比持续提升。在 Scale-up 域，光纤与铜缆共存，长距离链路逐步切换为光方案。
统一标准将加速落地进程。Aguilar 称：“OCP 正在推进相关标准制定，构建开放生态。谷歌现有大量自研私有技术，想要普及 OCS，必须完成标准化，否则难以大规模推广。”
如果 OCS 迎来规模化落地，光器件厂商是否会面临需求暴增？Aguilar 认为不必担忧。依托产能规划与行业并购，未来五年供给充足。“我们的晶圆合作伙伴已经提前扩产应对需求增长；英伟达宣布分别向 Lumentum、Coherent 各投入 20 亿美元，布局 OCS 相关产业链。”
OCS 为长距离端到端大流量提供高效光传输方案，丰富数据中心光互连部署方式。Aguilar 提到：“处理各类对内存时延敏感的业务时，降低转发跳数至关重要，全程光域传输能够带来明显增益。”
同时，行业联盟不断涌现。例如 Lightmatter 近期加入英伟达 NVLink 生态，但完整落地仍有大量工作待完成。
SignatureIP 销售与业务拓展高级副总裁 Ewald Liess 总结：“众多企业正在评估该技术，从原理层面优势突出。但量产成本、长期可靠性等挑战仍有待解决。”
评论