当前时间: 2026-06-06 20:56:23
分类:办公文件
评论(0)
OFC 2026: OCS在AI集群中的应用自从Google在其TPU集群中大规模部署OCS,OCS便受到了学界和产业界的广泛关注。在本届OFC大会上,有一个关于OCS应用的专题研讨会“Optical Networking for AI Data Centers: Technology Enablers and Key Applications”。小豆芽这里对相关的报告做一个整理总结,方便大家参考。顾名思义,OCS(optical circuit switching)的主要功能是实现对光路的动态切换。与电交换(EPS,electronic packet switching)相比,OCS工作在物理层,物理信道一旦建立,光信号即可在源端与宿端之间实现全光的物理透传,无需经过任何中间节点的光电转换,也不涉及协议层,因而具备极低的延迟与功耗。而EPS工作在数据链路层和网络层,它需要将连续的数据流拆分为Packet,并基于报头地址进行逐包查找与转发,如下图所示。高速光信号进行光电转换后,电信号通过EPS进行分发,需重新调制回光域进行传输。EPS需要完成报文解析、查表和转发等操作,其交换时延通常为数百纳秒至数微秒。EPS的灵活性较大,可以应对突发流量,并进行快速的动态切换。而OCS的重构时间较长(毫秒级),更适用于流量确定的网络拓扑结构,例如当前大模型的分布式训练中,AI集群的数据流展现出极强的周期性与可预测性。OCS并非用于完全取代EPS,而是作为对EPS网络的重要补充。未来超大规模AI集群更有可能采用“EPS+OCS”的混合交换架构,如下图所示,其中EPS负责灵活的数据包转发与网络可达性(network reachability),OCS则负责承载大象流(Elephant Flow)和周期性通信流量,从而兼顾网络灵活性与系统能效。OCS工作在光域,数据传输过程中无需进行光-电-光(O-E-O)转换,光信号可直接在发送端和接收端之间传输,从而显著降低系统功耗和传输时延,链路中的光模块数目也因此减半。OCS仅负责光通道的建立、维护和切换,不对承载业务的数据格式、协议类型以及信号速率进行处理或解析。因此,OCS对上层协议具有天然的透明性,能够兼容以太网、InfiniBand以及其他高速互连协议,并支持不同带宽和速率的业务灵活接入。OCS能够根据业务流量分布和通信需求动态调整光路连接关系,实现网络拓扑的动态重构,从而提高网络资源利用率和系统整体效率。此外,当链路或设备发生故障时,OCS可以通过重新配置光路建立新的通信路径,实现网络重构和故障绕行,降低单点故障对AI集群运行的影响,提升系统的可靠性和长期稳定运行能力。OCS的端口数较多,支持high-radix应用,能够以更少的交换层级和更少的交换平面完成大规模超节点互联,构建扁平化网络结构,从而有效简化网络拓扑结构。对于超大规模AI集群而言,这不仅有助于降低网络复杂度和部署成本,还能够减少多跳转发带来的额外时延和功耗。在Nvidia的报告中,列举了OCS在AI集群不同网络节点处的应用场景,如下图所示。对于scale-across场景,由于其覆盖跨集群的长距离链路,允许引入光放大技术来补偿光功率衰减,并且其时延要求低于机架内互联,因此该层级对OCS插入损耗的容忍度相对较高,OCS可以实现跨集群的灵活互联。对于scale-out场景,OCS可以与EPS协同工作,构建更加扁平化的网络结构,动态调整AI集群的拓扑,并且可以在链路或设备故障时快速建立新的通信路径,增加网络的弹性(resilience)和可靠性。对于scale-up场景, OCS能够根据不同AI训练任务的通信需求,动态调整GPU之间的互连拓扑,提高硬件资源的利用率。对于OCS在AI集群的规模化部署与广泛应用,Nvidia从四个关键维度提出了要求,如下图所示。OCS的插入损耗需控制在4dB以内,端口规模至少达到64*64,支持机架内的高密度互联需求,具备较高的可靠性和可维护性,支持热插拔,并且需要进一步降低成本。Lumentum对OCS的不同实现方案做了对比,如下图所示。主要包括MEMS方案、压电陶瓷方案(piezo-electric)、机械臂方案、液晶方案和硅光方案。MEMS方案凭借低插入损耗、大端口数目以及较高的技术成熟度,已成为当前应用最广泛的技术路线,其光路切换时间为毫秒级。压电陶瓷方案的性能与MEMS方案接近,Polatis公司是该技术的主要供应商。机械臂方案通过机械臂移动实现光纤的重新连接和切换,虽然可以支持大端口的光路配置,但其切换时间为秒级,有一定的应用限制。液晶方案主要是Coherent公司在推动,其不依赖于机械部件的运动,可靠性较高,目前已经支持300*300的光路切换。
对于硅光OCS方案,其主要优势为光路切换速度快,热光光开关的典型切换时间为几十微秒,显著快于MEMS和压电陶瓷等机械式方案。但受限于光器件的片上插损和光纤耦合损耗等,系统插入损耗较大,导致其端口规模的扩展性受限。为了克服插损的link budget限制,需要引入光放大器进行补充,但是光放大器会引入额外的ASE噪声,影响SNR,也增加了功耗与成本。此外,在硅光芯片内部还需要对偏振进行处理,进一步增加芯片设计和控制的复杂度。硅光OCS方案在端口数、链路插损等指标上面临较大的工程实现挑战,需要充分发挥其光路切换速度快的优势,找到对应的应用场景,从而形成差异化竞争优势。当前硅光OCS方案的代表公司主要有iPronics、Salience Labs和nEye等。iPronics与Salience Labs都采用的是传统MZI阵列方式,目前推出的OCS产品规模都为32*32。nEye的技术方案介于硅光和MEMS之间,在硅光晶圆中加工出MEMS结构,利用波导结构纵向的移动,实现光路的切换。nEye推出的OCS端口数可以达到240*240。关于OCS的端口规模,NTT提出了一个有启发性的技术方案,使用小端口数的1*N(N=2/4/8等)OCS构建网络,替代单个大端口数OCS,可以降低系统复杂度和成本,如下图所示,大规模OCS被拆分为多个小规模光交换单元。对于硅光OCS而言,该方案可以规避大规模硅光OCS的链路插损问题,扬长避短,更好地发挥硅光集成度高、切换速度快等优势,是一个值得关注和探索的技术方向。在Lumentum的报告中,提出将OCS和CPO组合在一起应用,如下图所示。OCS和CPO均是当前AI数据中心光互联领域最受关注的技术方向。对于"CPO+OCS"架构,数据从GPU发出后,通过CPO光引擎转换为光信号后,再传递到OCS, 随后再传递到另一颗GPU芯片。整个链路不涉及EPS, 系统的功耗与延迟有望达到最优。以上是对OCS workshop的简单整理,当前谷歌的TPU集群中已经大范围部署OCS,其他云厂商则在积极评估OCS在下一代AI网络中的应用价值,但整体仍处于探索验证阶段。在智算中心“计算-存储-网络”统一调度的发展趋势下,OCS有望成为连接GPU、交换机和存储节点的重要基础设施,实现网络拓扑按任务需求动态重构,提升整个AI集群的资源利用率。对于OCS本身而言,其未来发展方向也比较明确,包括增大端口规模,降低链路插损,提高可靠性,降低成本。基于硅光方案的OCS,能否在AI集群中找到适配的killer app,发挥其集成度高、调节速度快、高可靠性的优势,还需要产业界进一步的探索与验证。
文章中如果有任何错误和不严谨之处,还望大家不吝指出,欢迎大家留言讨论。目前三个微信群都已经满员,小豆芽已经新开了微信讨论群4,有需要技术讨论或者商务咨询合作的朋友可以直接添加我的个人微信photon_walker。
基本
文件
流程
错误
SQL
调试
- 请求信息 : 2026-06-07 09:54:33 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/721373.html
- 运行时间 : 0.172718s [ 吞吐率:5.79req/s ] 内存消耗:4,724.85kb 文件加载:145
- 缓存信息 : 0 reads,0 writes
- 会话信息 : SESSION_ID=2ede83bec981f57a6d1c707067d381ff
- CONNECT:[ UseTime:0.000861s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
- SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.001545s ]
- SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000772s ]
- SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.000724s ]
- SHOW FULL COLUMNS FROM `set` [ RunTime:0.001259s ]
- SELECT * FROM `set` [ RunTime:0.000622s ]
- SHOW FULL COLUMNS FROM `article` [ RunTime:0.001560s ]
- SELECT * FROM `article` WHERE `id` = 721373 LIMIT 1 [ RunTime:0.003356s ]
- UPDATE `article` SET `lasttime` = 1780797273 WHERE `id` = 721373 [ RunTime:0.011814s ]
- SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.000605s ]
- SELECT * FROM `article` WHERE `id` < 721373 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.001025s ]
- SELECT * FROM `article` WHERE `id` > 721373 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.001027s ]
- SELECT * FROM `article` WHERE `id` < 721373 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.002217s ]
- SELECT * FROM `article` WHERE `id` < 721373 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.007907s ]
- SELECT * FROM `article` WHERE `id` < 721373 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.002112s ]
0.174615s