数据中心 on 红旗下的蛋

Scale-Across 学习笔记：当 AI 算力开始"跨数据中心协作"

Sat, 17 Oct 2026 08:40:00 +0800

最近学习 AI 基础设施相关资料时，发现 Scale-Across 被提及的频率越来越高。2025 年，NVIDIA 发布 Spectrum-XGS Ethernet，探索如何通过专用网络连接分散的数据中心；2026 年，中国移动推出 GSE-DCI，烽火通信也在推进 800G 与空芯光纤等技术的用于 Scale-Across 应用。

这些进展背后，是要解决一个共同的问题：当电力、机房空间和散热条件限制了单个园区的扩容，能不能把不同地点的算力组织起来，让它们共同完成 AI 任务？

这就是我理解的 Scale-Across。它把数据中心连接起来，其重点在于判断哪些任务适合跨域执行，如何选择算力和网络路径，以及新增的算力能否真正转化为任务效率。

这篇笔记先聚焦概念本身。Scale-Across 是什么，和 Scale-Up、Scale-Out 有什么区别，它要解决什么问题，以及有哪些不能忽略的限制。

三个 Scale：从单机扩展到跨域协同

要理解 Scale-Across，最好的方式是把它放在 AI 算力扩展的全景视图里看。

目前，AI 数据中心的扩展方式大致可以分成三个层次。

Scale-Up ：扩大单个计算系统。

通过高带宽、低时延互联连接多颗 GPU，让它们对外尽可能表现得像一个更大的计算单元。核心追求是极低延迟，减少计算单元之间的通信开销。距离通常很短，铜缆互联仍是主流。

Scale-Out ：扩大集群规模。

单个系统塞不下更多 GPU，就在同一个数据中心内增加服务器和计算节点，通过数据中心网络承载节点间通信。核心关注的是带宽、拥塞、抖动和资源调度。

Scale-Across ：跨数据中心组织算力。

单个园区受到电力、空间、散热或其他基础设施条件限制，就让不同地点的算力共同承担合适的任务。跨园区、跨城市，甚至跨州、跨国。

这个类比不严谨，但好记。

Scale-Up 像是"把一台电脑的多个 GPU 插在一起"；
Scale-Out 像是"把同一个机房里几台算力服务器组合在一起"；
Scale-Across 则是"把分布在不同地域机房的算力服务器连成一台超级计算机"。

Scale-Across 面临的问题在于不仅要处理更多计算节点，还要面对更长的通信距离、不同地点的资源状态，以及算力、数据和网络之间的协调问题。

把两地的 GPU 连起来，并不意味着它们就能像同一机房里的 GPU 一样工作。物理距离带来的传播时延不会消失，网络拥塞和数据搬迁也可能抵消一部分算力收益。

因此，Scale-Across 首先要解决的不是"能不能连接"，而是 “什么任务值得跨域，以及怎样跨域才划算” 。

为什么需要"跨出去"？

答案很直接：一个数据中心装不下了，没法扩容了。

AI 模型的规模在指数级增长。训练这些模型需要数万甚至数十万张 GPU 协同工作。但物理世界有硬约束。

传统云数据中心的功率通常在几十到几百兆瓦之间，而新一代 AI 集群对电力的需求正在向吉瓦级迈进。单个地区的电网容量、土地资源和散热条件，很难支撑如此大规模的算力集中。

能源分布也并不均衡。有些地区电力资源丰富，有些地区气候适合散热，有些地区土地成本更低。把所有算力都集中在一个园区，虽然有利于统一管理和缩短通信路径，但也会集中供电压力和扩容风险。

跨地域部署能够利用不同地区的资源条件，为后续扩容提供空间。但分散部署之后，原本在本地完成的通信需要经过更长的网络路径，系统组织方式也随之变复杂。

不得不跨出去。 单一数据中心正在触及物理环境的天花板，而 AI 对算力的需求还在往上冲。Scale-Across 就是在这样的矛盾中诞生的架构方向。

Scale-Across 到底要解决什么？

跨域算力协同，至少要解决三个问题。

第一，任务调度：哪些任务适合跨域？

不同任务对网络的依赖程度并不一样。需要频繁同步参数的分布式训练，对通信时延和稳定性比较敏感；批量推理、离线计算和部分可独立执行的任务，则更有机会利用异地闲置算力。

第二，算力分配与路由：任务放在哪里，数据走哪条路？

调度系统不能只看哪里有空闲 GPU，还要考虑模型和数据的位置、任务的通信特征，以及目标算力节点的网络条件。网络路径也不能只追求物理距离最短，还需要综合考虑可用带宽、拥塞、可靠性和任务时限。

第三，网络承载：怎样让跨域通信尽可能高效？

光层负责大容量传输和光路资源，IP 层负责路由、流量工程、业务隔离和可达性。两层需要协同提供适合任务需求的网络能力，并把必要的网络状态反馈给上层调度系统。

这三个问题是连在一起的：任务特征影响算力选择，算力位置影响通信路径，网络状态又会反过来影响任务执行效果。

因此，Scale-Across 的核心是 让合适的任务找到合适的算力和网络 。

它和 Scale-Out 的本质区别

从表面看，Scale-Across 和 Scale-Out 都是"用网络连接更多计算节点"。但距离一变，问题性质就变了。

首先是传播时延。同一数据中心内，节点间距离通常在几十米到几百米，传播时延可以忽略。但跨域场景下，100 公里光纤路径的单向纯传播时延就约为 0.5 毫秒，往返约 1 毫秒。实际网络还会叠加设备处理、排队和路径绕行等开销。

其次是抖动和拥塞。广域网络的流量环境更复杂，路径更长，经过的设备更多。跨域通信的抖动和拥塞控制，比数据中心内部更难。

第三是数据位置。跨域调度时，模型、输入数据和中间状态可能分布在不同的存储系统中。数据搬迁的时间和成本，可能抵消远端算力带来的收益。

第四是运维边界。跨域网络往往涉及多个管理域、多个运营商、多套运维体系。故障定位、服务等级和计费方式都更复杂。

所以，Scale-Across 不是简单地把 Scale-Out 的网络拉长。它需要针对长距离、跨域、算网协同的特点，重新考虑网络架构、调度策略和业务适配。

几个不能忽略的技术限制

Scale-Across 可以改善分散算力的组织方式，但无法消除分布式计算本身的约束。

第一，传播时延存在物理限制。

100 公里光纤路径往返传播时延约为 1 毫秒。评估跨域算力协同时，需要关注真实网络路径和往返时延。因此，Scale-Across 不存在统一的距离限制，和其算力任务类型有关，训练类业务、推理类业务、数据类业务对时延有不同的要求，也就限制了 Scale-Across 的业务类型。采用空芯光纤，能使Scale-Across的可选业务类多一些。

第二，带宽高不代表训练一定快。

频繁同步参数或交换中间结果的任务，对时延和通信轮次较为敏感。即使链路带宽很高，新增的传播时延仍可能限制任务效率。

对于大块数据传输、批量推理或对时延不敏感的任务，增加带宽则更容易带来收益。网络方案必须结合任务的通信模式来判断。

第三，数据搬迁可能抵消算力收益。

远端有空闲 GPU，不代表把任务迁过去一定划算。如果模型、输入数据或中间状态需要大量搬迁，传输耗时和成本可能超过新增算力带来的收益。数据还可能受到隐私、合规或业务边界约束。

因此，算力调度需要同时考虑算力位置和数据位置，减少不必要的数据移动。

第四，并非所有训练任务都适合跨域。

不同模型、并行策略和通信模式对网络的依赖程度不同。可以拆分、通信较少的任务，更容易利用异地资源；需要频繁同步的训练，则必须更谨慎地评估跨域通信开销。

第五，算网协同也会增加系统复杂度。

跨域调度涉及算力管理、任务编排、网络控制、数据管理、安全和故障恢复。如果各系统缺少一致的状态定义和协同接口，可能出现调度与网络状态不匹配、故障定位困难等问题。

因此，算网协同不只是网络技术问题，也是系统集成、运营管理和服务设计问题。

小结

Scale-Across 不是某一种设备或协议，而是一种跨域组织 AI 算力的架构方向。它的价值在于让适合的任务使用合适的资源和传输路径。

从概念上看，它至少包含三层含义。

・连接层：把分散的数据中心通过高性能网络连接起来；・调度层：判断哪些任务适合跨域，选择算力和网络路径；・协同层：让网络状态参与算力调度，让任务执行效果反馈网络优化。

网络连接是基础，算网协同是手段，任务效率与综合收益是最终目标。 对 Scale-Across 更合适的态度或许是，积极探索，谨慎部署，场景验证，逐步演进。

它能不能真正创造价值，最终要看它是否让任务完成得更快、更稳定，或者以更低的综合成本使用算力。连接了多少数据中心、提供了多高的带宽、汇聚了多少 GPU， 这些数字本身说明不了价值 。

说明：本文为个人技术学习笔记，主要是用于理解 Scale-Across 的概念。错误之处，欢迎留言指正。

OLT 能不能成为算力边缘节点（二）？把 GPU 放到 OLT 旁边就行了吗？

Tue, 22 Sep 2026 07:45:00 +0800

上一篇文章最后留下了一个问题：

如果真的把 GPU 放到 OLT 旁边，用户到底怎么才能用上这份算力？

这问题比"能不能放"更值得琢磨。

算力部署过去，只说明那儿有了计算资源。用户要真用上，还得解决几个事：

AI 请求从哪进来？
网络咋知道这是 AI 请求？
用户面在哪？
业务怎么被引到合适的算力？
不同 AI 业务，该用哪儿的算力？

上一篇从地理、网络、服务三个维度看 Edge。这篇往下具体看，落在三个部署要素上：

算力放哪？（地理维度）
用户面在哪？（网络维度）
服务入口在哪？（服务维度）

这三个要素如果能协同一致，Edge 才有意义。否则 GPU 再近，也只是机房里的一堆铁疙瘩。

GPU 有了，用户从哪进门？

假设 OLT 机房真放了一组 GPU（算力资源）。物理距离上，它离用户很近。

但用户不会因为 OLT 旁边多了几台 GPU，就知道这儿有 AI 服务。用户访问的是 AI 服务，不是 GPU。

一份能被用户用的 AI 服务，除了 GPU，还得有模型、推理服务、数据、服务入口。这个入口，可以叫 AI Gateway。

它负责接用户的 AI 请求，再把请求送到合适的 AI 服务和算力节点。

简单说就是：

用户请求 → AI Gateway → 服务选择 → Edge GPU

GPU 是底层算力。AI Gateway 更像用户进 AI 服务的一扇门。没这扇门，GPU 就算在用户隔壁，也只是机房里一组计算设备。

AI Gateway 不一定是台单独设备，也不一定非得部署在 OLT 上。它可以集中，也可以分层。比如部署在核心管全局调度，部署在区域或接入侧管本地服务发现。

问题就变成了：用户的请求，怎么找到这扇门？

从部署三要素来看，AI Gateway 主要解决服务入口的事：

用户请求从哪进入AI 服务
服务怎么被发现和选
请求怎么被引到合适的算力节点

网络怎么知道这是 AI 请求？

这事儿比想的复杂。

现在大量业务跑在 HTTPS 上。网络通常看不到应用层内容，也就不能简单通过读报文判断：“这是个 AI 请求。”

这里要分两种情况。

运营商自己的 AI 服务，相对简单。AI Gateway 本身就是入口，用户访问这入口，请求自然进运营商自己的 AI 服务体系。

第三方 AI 服务就不一样了。运营商通常没第三方服务的 DNS 控制权，也看不见 HTTPS 里面的具体内容。这时候只能用 SNI、IP 地址、流量特征判断是否是AI请求，但最好是能跟服务商合作拿到更明确的业务信息。

所以 AI 业务识别，不只是网络设备加个"AI 识别功能"这么简单。有效正确的识别，往往要应用、DNS、服务入口、网络策略一起配合。

应用知道自己在调什么服务。网络负责把请求引向合适入口。AI Gateway 再根据用户、业务、资源情况选具体服务和算力。

网络其实不需要知道用户给大模型输的每句话。它要解决的是：这个请求该去哪。

但这儿有个容易被忽略的问题。

AI Gateway 解决的是"业务该去哪"，网络还得解决"报文怎么来的"。

AI业务的HTTP/HTTPS 请求最终还是承载在用户的 IP 会话上，在运营商广泛采用 PPPoE 宽带接入方式下，如果要在用户接入侧完成三层业务分流，得先由用户面完成 PPPoE 会话终结，建立相应的三层业务上下文。

这就引出下一个问题： 用户面到底在哪？

GPU 在 OLT 旁边，BNC-UP 还在核心，咋办？

以固网宽带为例。传统 PPPoE 接入下，用户 PPP 会话在 BNG/BRAS 终结。联通 BNC 架构里，由 BNC-UP 承担用户面功能。

典型业务路径：

用户 → ONU/ONT → OLT → 承载网 → BNC-UP → Internet/云

AI Gateway 和 GPU 都部署在 OLT 局所，但 BNC-UP 还在远端本地核心，这就有问题了。

用户的 AI 请求虽然从 OLT 进了网，但还得先到核心的 BNC-UP 完成用户面处理，再被转发回 OLT 附近的 AI Gateway 和 GPU。

也就是说： GPU 已经很近了，用户面却还在远处。流量走的路反而变长了。

一个完整的交互路径成了这样：

用户 → OLT → 核心 BNC-UP → OLT 附近 AI Gateway / GPU → 核心 BNC-UP → 用户

这就是典型的流量折返（Trombone），也可以叫"迂回路由"“折返路由"或"流量绕行”。

GPU 本来是为了靠近用户而下沉的。如果用户面留在核心，业务流量却要先上核心、再回接入侧，GPU 位置带来的低时延优势，就可能被网络路径上的折返抵消。

从部署三要素来看：

地理上，GPU 已在 OLT 附近，离用户很近
网络上，用户面（BNC-UP）仍在远端核心，流量路径没真下沉
服务上，AI Gateway 和 AI 服务逻辑虽在 OLT 侧，但得等流量从核心绕回来才能发挥作用

三要素没协同，地理上的"近"，很难变成真正的 Edge 体验。

所以我越来越觉得： 算力离用户近，不等于 AI 服务离用户近。用户面的位置同样重要。

如果用户面不能和算力、服务入口在路径上对齐，“算力下沉"很容易变成"资源下去了，业务路径没下去”。

BNC-UP 到底该在哪？

现在 BNC-UP 主要集中部署在本地核心。对传统互联网业务，这有合理性——大量的流量是访问IDC的，IDC一般位于本地的核心位置或本地外的互联网其他位置，总体来说是个南北汇聚性业务，用户面在核心，距离业务近，建设运维也方便。

但后期大概会有越来越多 AI 服务向边缘靠近，新问题出来了：用户面是不是也该有更灵活的部署方式？是否像之前的IP城域网将BNG部署在汇聚节点就可以了？

但别简单理解成"以前在核心，现在退回汇聚"。这不是回到过去的问题。

不同业务，对位置要求不一样。

普通互联网业务、一般大模型问答，对极低时延不敏感。用户面集中在本地核心，没大问题。

区域性 AI 业务，比如区域视频分析、智慧城市，算力可能在区域节点。这时候用户面也可以考虑更靠近区域侧。

再往下，工业视觉、实时云渲染、车路协同这类对时延敏感的业务，算力可能就在接入局所或附近。那用户面也得考虑能不能再靠近。

还有一类是企业自己的 AI。企业可能希望数据和模型留在园区或内部。这时候用户面、AI Gateway、算力的位置，可能围绕企业自身业务位置来设计。

与其说 BNC-UP 要"下沉"，不如说： BNC-UP 的位置不该永远只有一个答案。面向不同业务，它可能需要更灵活的分布式部署能力。

这也是 AI 时代网络架构变化里，我觉得值得继续研究的点。从工程三要素来看，这是在调整网络维度（用户面位置）来协同地理维度（算力位置）和服务维度（业务类型）的差异。

用户面下沉了，也不等于 AI 服务就近了

假设 BNC-UP 真下沉到 OLT 附近。Edge AI 就自然成立了？还是不一定。

比如用户面下沉了，但 AI Gateway 和 GPU 还在核心：

用户 → OLT → Edge BNC-UP → 核心 AI Gateway → 核心 GPU

用户面近了，AI 服务本身没下沉。

反过来，算力下沉了，用户面还在核心：

用户 → OLT → 核心 BNC-UP → OLT 附近 GPU → 核心 BNC-UP → 用户

又是前面说的流量折返。

真正值得关注的不是"哪个设备一定要下沉"，而是： 业务路径上的几个关键环节，能不能形成合理的配合。

回到 PPPoE。为什么不能让 OLT 看到 AI 流量后，直接扔给旁边的 GPU？因为传统 PPPoE 架构下，OLT 主要管接入和二层转发。PPPoE 会话终结、用户地址分配、用户业务处理，都在用户面完成。OLT 本身没有完整的用户三层业务上下文。

所以如果想在接入侧真完成三层业务分流，分流位置得具备相应的用户面功能。这正是分布式 BNG 解决的问题之一：控制面可以集中，用户面根据业务需要向边缘部署。它不是绕过用户面，而是把用户面放到更合适的位置。

从三要素来看，这在强调：

地理层：算力可部署在 OLT 附近或区域节点
网络层：用户面需能根据业务类型，在核心、区域或接入侧灵活终结
服务层：AI Gateway 和服务编排要能和用户面、算力形成一致的业务路径

再往下，还得考虑两个问题：服务怎么选、流量怎么过。AI Gateway 不只是找台 GPU，还得找到合适的服务和算力。用户面得能把相应业务真正送到那个服务和算力节点。

这样看，Edge 不是把某个设备搬到用户身边就完了，而是要让用户面、服务入口、算力之间形成一条合理的业务路径。

Edge 不是某台设备的位置，而是一条由服务入口、用户面、算力共同构成的业务路径。

只有这条路径在地理、网络、服务三个要素都"对得上"，用户才能真感受到"算力就在身边"。

算力不一定跟着用户走，服务应该按需下沉

一路追求"离用户越近越好"，容易得出简单结论：给每个 OLT 都放 GPU。

不现实。GPU 不只是买台服务器的事。还有电力、散热、空间、运维，更重要的是算力利用率。一个 OLT 覆盖的用户很多，不意味着这些用户会持续产生足够多的 AI 请求。

我更倾向这样理解： 算力适度集中，服务按需下沉，流量精细引导。

核心的云池仍承担大量通用 AI 服务。汇聚节点的Edge 承担一些对时延和数据位置敏感的业务。更靠近接入侧的算力，服务于少数真正需要本地处理的场景。

重点不是让每个 OLT 都拥有一份算力，而是：用户请求到来后，网络能找到距离、能力、负载都合适的算力。这可能比"每个 OLT 放多少 GPU"更重要。

这就是地理、网络、服务三个要素协同后的结果。

从 OLT 到 Cloud CO：接入局所会发生什么变化？

再回头看 OLT，觉得它的角色会变得有些不同。

OLT 仍是接入设备。计算可以放在附近的通用服务器上。用户面根据业务需要部署。AI Gateway 负责服务入口和业务引导。再往上，还有统一的服务、算力及资源管理。

真正变的可能不是 OLT 本身，而是： OLT 所在的这个局所，未来能不能承载更多东西？

类似思路早有人探索过。CORD 就是代表项目之一。它提出把传统 Central Office（端局）重新改造成能承载数据中心能力的环境，通过虚拟化承载包括 vOLT 在内的网络功能。后来 ONF 又发展出 SEBA 等方案。具体技术路线变了，但有个思路今天仍值得回头看：

传统端局不一定永远只是放网络设备的地方。

如果未来一个接入局所同时具备网络接入、用户面、一定计算能力、服务编排能力，它就可能在地理、网络、服务维度上都具备 Edge 特征。如果未来一个接入局所同时具备这些，它就可能逐渐成为连接用户、网络、算力的近端基础设施。

至于 GPU 是放在 OLT 旁边，还是同机房服务器机柜，甚至附近的小型 Edge DC，反而只是具体实现方式。

回到最初的问题

现在再看最开始的问题：把 GPU 放到 OLT 旁边，用户就能用上算力了吗？

答案显然没这么简单。

用户首先需要一个服务入口。网络需要知道请求该去哪。用户面需要能把业务送到合适的地方。AI Gateway 还得找到合适的服务和算力。最后，算力才真正完成 AI 处理。

上一篇从地理、网络、服务三个维度讨论 Edge，这篇思考到现在，可以得到个比较简单的认识：

Edge 不是某台设备的位置，而是一条业务路径。

这条路径能不能真正靠近用户，取决于服务入口、用户面、算力之间能不能配合起来。

也正因为如此，我现在越来越觉得：“OLT + GPU"只是个设备部署问题。真正值得研究的，是运营商这些遍布用户身边的接入局所，未来能不能逐步成为连接用户、网络、算力和 AI 服务的近端基础设施。

过去，接入网络主要解决：用户怎么接入网络。

以后可能还要继续解决：

用户的 AI 请求怎么找到合适的服务
服务怎么找到合适的算力
算力怎么真正通过网络被用户使用

这样再回头看"OLT 能不能成为算力边缘节点”，答案似乎变了点。

也许真正值得讨论的，不是"要不要给 OLT 旁边放块 GPU？“而是： 当算力进入网络以后，原来的接入网络，会不会逐渐变成连接用户、服务和算力的一部分？

换句话说，接入网络是不是也能在地理、网络、服务维度上，一起向 Edge 演进？

这个问题，可能比 OLT 本身是不是个"算力节点”，更值得继续往下想。

至此，《OLT 能不能成为算力边缘节点》系列文章告一段落，片面之见，欢迎讨论指正。随着 AI 应用的逐渐普及深入，AI所带来的业务和流量的变化对本地网络的发展会产生什么样的影响，也是值得下一步研究。

从 POL 到 DC-POL：PON 正在进入数据中心基础设施网络——从 Hyperscale OOBM 到 Infrastructure Connectivity 的一次架构迁移

Tue, 01 Sep 2026 08:23:00 +0800

引言

PON（Passive Optical Network，无源光网络）通常被认为是典型的"接入网技术"。过去二十多年，它最主要的应用场景是 FTTH、企业接入以及后来逐渐发展的 POL（Passive Optical LAN，无源光局域网）。在传统认知中，数据中心则属于完全不同的世界：服务器、交换机、GPU、RoCE、400G、800G 乃至 1.6T，构成了一个追求极致带宽和低时延的高速网络体系。PON 似乎与这样的环境格格不入。

但这种认知正在发生变化。2026 年 8 月，Dell’Oro Group 首次针对数据中心和企业场景中的 PON 建立独立市场研究，并预计 2026 年 Data Center PON 设备收入同比增长 844%，2026—2030 年累计设备支出超过 30 亿美元，年复合增长率达到 52%。 Dell’Oro 明确指出，这一增长主要来自 Hyperscaler 利用 PON 降低数据中心 OOBM（Out-of-Band Management，带外管理）网络的布线和功耗需求。需要说明的是，844% 的同比增长反映的是一个新兴市场从很小基数快速形成的过程，而非 PON 已经大规模替代传统 OOB 网络。52% 的 CAGR 意味着这一市场正在快速扩张，但当前规模仍远小于传统数据中心网络设备市场。

这意味着，一个过去主要服务于家庭和企业及园区接入的技术，正处在进入数据中心的早期产业化阶段。问题随之而来：为什么是 PON？答案并不是 PON 突然拥有了比 400G、800G Ethernet 更高的性能，也不是 PON 准备进入 GPU 之间的高速计算网络。恰恰相反，PON 进入数据中心，是因为它解决的是一个完全不同的问题。

AI 数据中心正在产生一个不同于计算互联矩阵Compute Fabric 的基础设施互通Infrastructure Connectivity 问题，而 PON 可能成为解决这一问题的一种新型底层连接架构。目前最明确的应用是 OOBM 和 Console，向 PDU、Facility 等更广泛基础设施网络扩展仍属于潜在方向。

因此，PON 进入 IDC 并不是"接入网技术入侵数据中心"，而更像是一次架构上的自然迁移：过去 PON 通过 POL 解决建筑和园区中的海量低速终端连接，如今它开始尝试解决数据中心中海量 Rack 基础设施设备的连接问题。从这个角度看，Data Center PON 并不是一个突然出现的新技术，而可能是 POL 从 Building/Campus 向 AIDC Infrastructure Connectivity 的一次延伸。

从 Meta 到 Dell’Oro：Data Center PON 正在形成新的产业赛道

Data Center PON 最值得关注的地方，不是某一家设备商突然推出了一个新产品，而是过去两年产业链已经出现了一条相对完整的演进路径：Hyperscaler 验证 → 设备商跟进 → 产品化 → 市场机构建立独立市场统计。这条路径意味着，PON 在数据中心已经开始从技术探索走向产业化早期。

Meta：从概念走向实际工程架构

2025 年，Meta 在 NANOG 94 公开介绍了其 PON-based Data Center Management/Console 架构和工程实践。其基础出发点非常明确：Meta 基础设施网络团队负责全球数据中心每个 Rack 的网络设备管理连接，包括 Ethernet、Serial、OOB 以及灾备网络。传统架构主要依靠部署在每个 Row 末端的 Ethernet Switch 和 Terminal Server，为 Rack 提供管理连接。

随着数据中心规模扩大，这种架构开始暴露出明显问题：每个 Rack 的 Ethernet 和 Serial 连接数量受到固定设备限制；不同 Rack 类型需要进行 Row 级协调；需要维护大量 Row 级网络设备；同时还需要在 Goalpost 与 Rack 之间铺设大量铜缆。Meta 给出的解决方案不是继续增加管理交换机，而是引入 PON。

其架构可以简单概括为：中心 OLT → ODN → Splitter → Rack ONU → Ethernet/Console。PON 由此承担数据中心 Management 和 Console 连接。Meta 公开的数据尤其值得关注。在其当前方案中，一个 Rack 可以提供最多 20 个 Ethernet 和 20 个 Console 连接，或者 32 个 Ethernet 和 8 个 Console 连接；一个 Row 可以提供最多 1280 个 Ethernet 连接和 800 个 Console 连接，而 12 个 Row 可以由两个集中式路由设备承担 OLT 聚合功能。

更重要的是，Meta 并没有把 PON 简单理解成"用光纤替换铜缆"。它利用 PON 的集中式管理和无状态 ONU 设计，将 Rack 与数据中心 PON 拓扑解耦。ONU 部署到 Rack 之后，可以通过自动化资产管理系统进行识别和配置；当 ONU 发生故障时，只需要扫描新的设备即可完成替换。在布线方面，Meta 甚至表示，其 PON 方案使数据机房内部的网线走线架和网线分配单元得以完全取消，Rack 只需要标准化的 2 芯或 4 芯光纤连接，Rack 内部的网线则被限制在机架内部。

这已经不是简单的技术验证，而是一种针对 Hyperscale 数据中心运行方式重新设计的网络架构。

Ciena：从 Hyperscaler 实践走向产业方案

Meta 之后，Ciena 已经将 PON 用于 Data Center Out-of-Band Management，并形成面向客户的解决方案。 Ciena 目前已经将 Data Center Out-of-Band Management（DCOM）定义为一种基于 PON 的解决方案，明确是解决针对传统 OOB 网络中存在的铜缆、设备数量、机架空间以及功耗和散热问题。其方案采用 XGS-PON 相关产品，并结合路由平台、PON 系统、控制软件、ONU 和 Console Server 构建数据中心 OOB 网络。

Ciena 特别强调，AI 和云计算驱动的数据中心规模扩张正在使传统 OOB 架构越来越难以扩展，而 PON 能够通过集中式架构降低设备数量和布线复杂度。这说明 PON 已经不再只是 Hyperscaler 内部的一项架构创新，而开始形成可以向其他数据中心客户提供的产业解决方案。

Nokia：PON 开始成为正式的数据中心产品

2026 年 3 月，Nokia 正式推出 Aurelis for Data Centers，将 PON 明确用于数据中心 OOBM。 Nokia 表示，其 Aurelis 方案在特定数据中心 OOBM 架构中可以减少最多 90% 的交换机、节省 50% 以上功耗，并将运维工作量降低最多 80%。需要说明的是，这些数字是 Nokia 对其特定 PON-based OOBM 方案与传统架构进行比较后给出的目标性指标，而非行业普遍规律。

但从产业角度看，数字本身并不是最重要的。真正重要的是：传统数据中心 OOB 网络已经开始被设备厂商视为一个可以由 PON 重新架构的独立市场。Nokia 甚至进一步把 PON 描述为一种面向 AI 和云数据中心的高效、可扩展、低功耗 OOBM 基础设施。

Dell’Oro：从产品市场进入产业市场

如果说 Meta 解决的是"能不能做"，Ciena 和 Nokia 解决的是"能不能产品化"，那么 Dell’Oro 在 2026 年的动作则解决了第三个问题：这个市场是否足够大，值得单独研究？答案已经非常明确。Dell’Oro 预计 2026 年 Data Center PON 设备收入同比增长 844%，2026—2030 年累计设备支出超过 30 亿美元，年复合增长率达到 52%。同时，其市场定义已经明确覆盖 Data Center OOBM 以及 DCIM（Data Center Infrastructure Management）相关 PON 设备。

因此，从产业生命周期来看，Data Center PON 已经完成了最初的几个关键阶段：Hyperscaler 工程验证 → 设备商产品化 → 产业方案形成 → 市场研究机构独立统计。这意味着 Data Center PON 已经进入产业化早期。但必须注意，这仍然是一个新兴市场。52% 的 CAGR 并不意味着 PON 已经大规模替代传统 OOB 网络，而是意味着一个此前规模很小甚至没有被单独统计的市场正在快速形成。

AIDC 真正改变的不是网络速度，而是连接结构

理解 PON 为什么进入数据中心，不能只看 PON 本身，而必须重新观察 AI 数据中心的网络结构。过去谈数据中心网络，人们最容易想到的是交换机、服务器、GPU 和高速互联。AI 出现之后，这部分网络确实发生了剧烈变化。GPU 集群推动网络从 100G、200G 快速走向 400G、800G，并继续向 1.6T 演进。对于大规模 AI 训练而言，网络的核心指标是吞吐、时延、拥塞控制、无损传输以及集合通信效率。这构成了典型的 Compute Fabric。它解决的是 GPU 之间如何尽可能快地交换数据。在这个网络中，PON 几乎没有竞争优势。

但是，如果把视野从 GPU 之间拉开，就会发现 AIDC 还有另外一个正在快速膨胀的网络。AI 数据中心不只有 GPU，还有大量"基础设施设备"。每一个 GPU 服务器都需要被管理。每一个 Rack 都需要电源管理。越来越复杂的液冷系统需要 CDU、泵、阀门和传感器。数据中心还存在大量 BMC、Console、PDU、UPS、CDU、HVAC、温湿度传感器、环境监测设备、安防与门禁设备以及其他 DCIM 基础设施。这些设备有一个共同特点：它们绝大多数并不需要 400G、800G 甚至 10G 网络。它们真正需要的是足够的带宽、可靠的连接、较低的成本、较低的功耗，以及能够支撑数万甚至数十万设备的统一运维体系。这与 GPU 网络形成鲜明对比。

需要区分的是，BMC 和 Console 属于非常典型的 OOBM 网络，PDU 可以接入管理网络，而 CDU、HVAC 通常属于 BMS/DCIM/Facility Management 体系，Sensor 可能使用完全不同的协议和网络。因此，本文使用 Infrastructure Connectivity 这一更宽泛的概念来描述这些设备的连接需求，而非声称它们属于同一个网络域。

从功能和工程需求看，AIDC 可以抽象为两个具有不同优化目标的网络域。本文将其分别称为 Compute Fabric 和 Infrastructure Fabric。需要说明的是，这一划分是本文的分析模型，而非行业已统一定义的标准架构。

表 1：AIDC 二元网络结构对比

网络类型	主要连接对象	核心需求	典型技术
Compute Fabric	GPU、CPU、NIC、DPU	极高带宽、极低时延	Ethernet/RoCE/InfiniBand
Infrastructure Fabric	BMC、Console、PDU、CDU、Sensor 等	海量连接、低成本、低功耗、易运维	Ethernet / PON 等

从"高速网络"转向"海量连接"，传统数据中心网络的核心问题可以概括为"如何让每一条连接越来越快"，而 AI 数据中心越来越需要回答另一个问题：“如何用更低的成本连接越来越多的设备”。这两个问题并不矛盾。恰恰相反，它们构成了 AIDC 网络结构的两个不同维度。Compute Fabric 负责"高速计算"，Infrastructure Fabric 负责"海量基础设施连接"。这正是理解 Data Center PON 的关键。

从架构上看，AIDC 的网络需求可以抽象为：

这一模型有助于理解 PON 在 AIDC 中的定位：它不是要替代 Compute Fabric，而是为 Infrastructure Connectivity 提供一种新的架构选择。

传统 OOB 网络的问题正在被 AIDC 放大。传统 OOB 网络通常以 Ethernet Management Switch 和 Console Server 为基础。当 Rack 数量较少时，这种架构非常合理。问题出现在规模。当一个数据中心从几百个 Rack 扩展到数千、数万 Rack 时，OOB 网络本身也需要大量交换机、Console 设备、铜缆、配线和电源。网络设备数量增加，又意味着更多机架空间、更多电源、更多散热、更多线缆、更多故障点和更多运维对象。Meta 在公开材料中描述的正是这个问题：传统架构存在大量 Row 级设备和铜缆分配，同时 Rack 连接能力受到固定设备限制。

因此，AIDC 带来的真正变化不是"管理网络也需要更高带宽"，而是管理网络本身开始成为一个需要重新架构的超大规模基础设施网络。这恰好为 PON 创造了机会。

PON 进入 IDC：其实是 POL 的一次自然延伸

如果把 PON 放回它过去二十年的发展历史，会发现 Data Center PON 并没有那么"离经叛道"。事实上，它与 POL 存在非常明显的架构同构。POL 解决的本来就是"海量低速连接"问题。Passive Optical LAN 的基本思想，是把传统企业 LAN 中的大量主动交换节点替换为 OLT + Passive Optical Distribution Network + Splitter + ONU/ONT。TIA Fiber Optics Technology Consortium 对 POL 的定义，本身就是将 GPON 等 PON 技术适配到企业 LAN 环境中，其主要特点包括更少的设备和布线、集中式管理以及较低的能源需求。

传统企业 LAN 通常是 Core → Aggregation → Access Switch → Copper → Terminal，而 POL 则变成 OLT → Passive ODN → Splitter → ONU → Terminal。PON 最重要的价值并不是"光纤比铜缆快"。真正的价值在于：把大量终端的接入复杂度，从分布式主动交换设备重新集中到网络中心。这正是 Data Center OOBM 现在面临的问题。

需要特别说明的是，PON 的价值并不只是把铜缆换成光纤。如果只是传输介质由铜缆改为光纤，仍然可以保留大量交换机，只不过是将互联口改为光模块。PON 真正改变的是网络的主动/被动分工以及设备部署方式：将大量中间连接变成无源光网络，把网络智能集中到 OLT，从而减少有源设备数量、降低功耗和运维复杂度。

从 Building 到 Rack，POL 架构发生了一次空间映射。传统 POL 的连接对象是 Building/Floor/Room/Terminal，而 Data Center PON 的连接对象变成 Data Hall/Row/Rack/Infrastructure Device。两者的逻辑关系高度相似。

表 2：传统 POL 与 Data Center PON 架构对比

传统 POL 元素	Data Center PON 对应物	功能说明
Building/Campus	Data Center	物理空间范围
Floor/Room	Row/Rack	细分连接单元
OLT	OLT	核心控制设备
ODN	DC Optical Distribution Network	光纤分配网络
Passive Splitter	Passive Splitter	光信号分配
ONU/ONT	Rack ONU	终端设备
PC/AP/Phone/Camera	BMC/Console/PDU 等	被连接设备
Enterprise LAN	OOBM/Infrastructure Management	网络类型
Copper LAN	Rack 内部铜缆	末端连接
Fiber backbone	Fiber-to-Rack	主干连接

因此，与其说 PON 进入了一个完全陌生的数据中心领域，不如说 POL 已经证明了 PON 在建筑和园区中进行大规模终端连接的可行性，而 Data Center PON 只是把"终端"从办公室设备变成了 Rack 基础设施设备。本文将这种从 POL 向数据中心基础设施连接延伸的架构思路称为"DC-POL"（Data Center Passive Optical LAN）。需要说明的是，DC-POL 并非行业已统一定义的标准术语，而是本文用于理解 POL 架构向数据中心延伸的分析框架。它描述的是将 POL 的被动光接入架构思想延伸到数据中心 Rack 级 Infrastructure Connectivity。

PON 真正改变的是"主动设备的位置"。传统 OOB 网络的核心逻辑是在距离被管理设备较近的位置部署主动交换设备。而 PON 的逻辑恰好相反：尽可能把网络智能集中到 OLT，将中间大量连接变成无源光网络。这也是为什么 PON 能够产生明显的规模效应。在传统架构中，Rack 数量增加意味着 Rack 增加 → Switch 增加 → 铜缆增加 → 电源增加 → 运维对象增加。而 PON 架构更接近 Rack 增加 → ONU 增加 → ODN 扩展。大量中间连接本身不再需要主动电子设备。这也是 PON 最核心的经济学基础。

经济性并不来自"单端口更便宜"，而来自网络结构变化。Nokia 表示，其 Aurelis 方案在特定数据中心 OOBM 架构中可以减少最多 90% 的主动交换设备、节省 50% 以上功耗，并将运维工作量降低最多 80%。这些数字的真正含义，不应该简单理解为"PON 设备比交换机便宜"。更准确的理解是：PON 改变了数据中心基础设施网络中有源设备与无源基础设施的比例。传统网络需要在大量位置布置有源设备。PON 则把大量复杂度集中到少数 OLT，同时使用无源 ODN 完成大规模分配。于是，成本结构发生变化：有源设备 CAPEX 下降；设备功耗下降；散热需求下降；铜缆与配线复杂度下降；网络设备数量下降；维护对象数量下降。这才是 PON 进入 AIDC 最值得关注的地方。

Meta 案例进一步说明了这种结构性变化。Meta 公开资料显示，其 PON 架构不仅减少铜缆，而且通过标准化 Rack 光纤 Handoff，将 Rack 本身与数据中心 PON 拓扑解耦。每个 Rack 只需要标准化的 2 芯或 4 芯光纤连接，而 Rack 内部的 ONU、Splitter 和 Console 组件则封装在 Rack 级 Canopy 中。这种设计带来一个非常重要的工程价值：数据中心网络拓扑不再需要随着 Rack 类型变化而频繁变化。对于 AI 数据中心而言，这一点尤其重要。因为 AI 基础设施正在快速变化：GPU 服务器不断更新；Rack 功率不断变化；液冷方案不断变化；Server SKU 不断变化；Rack 密度不断变化。如果基础设施网络能够与 Rack 内部设备解耦，那么数据中心的网络拓扑就不必跟随每一次硬件迭代重新设计。因此，PON 的价值最终不仅是少几台交换机，而是建立一种更加稳定的基础设施连接底座。这正是 POL 架构进入 AIDC 之后可能产生的更深层价值。

在工程落地层面，将 PON 引入数据中心也带来了物理层与运维特性的变革。将铜缆替换为光纤虽然大幅简化了机柜间布线，但光纤对弯折半径的敏感性以及光接口的防尘防污染要求，对高频插拔维护提出了新挑战，通常需要依赖标准化 Canopy 与预连接光缆来降低现场损伤率。同时，PON 网络改变了故障隔离边界（Blast Radius）——传统以太网交换机故障通常仅影响单个端口或特定设备，而无源光分配网（ODN）主干光纤或关键分光器的物理损坏可能导致整个机架排（Row）甚至整个数据中心的带外管理瞬间失联，这对 OLT 的冗余保护机制（如 Type B/Type C ）提出了极高的工程可靠性要求。

PON 在 AIDC 还能走多远？

如果 Data Center PON 已经能够承担 OOBM 和 Console，那么下一个问题自然是：它能不能继续向 AIDC 其他基础设施扩展？这里需要保持克制。目前最明确、最成熟的应用仍然是 OOBM、Management 和 Console。Dell’Oro 目前对 Data Center PON 的市场定义也主要覆盖 OOBM 和 DCIM。因此，可以把潜在应用划分为不同层次。

表 3：PON 在 AIDC 中的应用场景与适配度

应用场景	PON 适配度	当前状态	说明
OOBM	★★★★★	已验证	已经出现明确产业实践
Console	★★★★★	已验证	已经验证
BMC/设备管理	★★★★☆	潜在	与 OOBM 高度相关
PDU/电源管理	★★★★☆	潜在	具有扩展潜力
CDU/HVAC/环境监控	★★★☆☆	潜在	潜在 Infrastructure Connectivity
Sensor/IoT	★★★☆☆	潜在	需要结合具体设备模型
Facility Management	★★★☆☆	潜在	更长期的扩展方向
GPU Compute Fabric	★☆☆☆☆	不适合	不属于 PON 优势领域
高速 Storage Fabric	★☆☆☆☆	不适合	不属于 PON 优势领域

OOBM 和 Console 是目前 PON 最明确的切入点，BMC/设备管理和 PDU/电源管理与 OOBM 高度相关，具有扩展潜力。CDU/HVAC/环境监控、Sensor/IoT 以及 Facility Management 属于潜在 Infrastructure Connectivity，是更长期的扩展方向，但需要结合具体设备模型和网络协议进一步验证。因此，PON 未来在 AIDC 中的合理演进路径，并不是 OOBM → 取代整个 Data Center Network，而更可能是 OOBM → Infrastructure Management → 更广泛的 Infrastructure Connectivity。这是一条完全不同的路线。

PON 不会进入 Compute Fabric。这是理解整个产业趋势时必须划出的边界。GPU 之间的网络追求的是极高吞吐、极低时延、高带宽密度、高性能拥塞控制以及大规模集合通信效率。PON 的点到多点共享介质架构并不是为这个问题设计的。因此，没有必要把 Data Center PON 理解成"PON 挑战 800G Ethernet"。这其实是一个错误的问题。真正的问题应该是：当 GPU 网络越来越快、AI 数据中心越来越大之后，管理和基础设施网络是否仍然需要沿用传统的逐级 Ethernet 交换架构？如果答案是否定的，那么 PON 就有了自己的位置。

对于这一架构何时能跨越经济临界点，取决于几个核心要素的挤压：首先是机房的物理密度与节点规模，只有当单个 Data Hall 内的带外管理节点与基础设施连接数达到特定阈值（如千级以上连接点）时，OLT 的集中式端口 CAPEX 优势才能完全抵消 ODN 的首次铺设成本；其次是自动化与无状态运维（Stateless Operation）能力，PON 架构依赖“即插即用、扫码替换”的自动化控制器与 IPAM 体系来释放 OPEX 优势，若缺乏强有力的软件支撑，其初始配置门槛反而高于传统以太网交换机。

结语

过去，人们很容易把 PON 理解成一种"接入网技术"。因为它诞生于运营商网络，长期服务于家庭和企业接入，因此形成了一个根深蒂固的认知：PON 属于接入网，Ethernet 属于数据中心。但技术的边界从来不是由历史决定的，而是由问题决定的。工业PON，POL以及定义的DC-PON，也就反映了这种边界的调整。当数据中心只有几百个 Rack 时，传统 OOB Ethernet 可能已经足够简单。当数据中心进入 Hyperscale 和 AI 时代，Rack 数量不断增加，管理设备、基础设施设备和传感器数量不断增长，传统 OOB 网络本身也开始成为一个需要优化的基础设施。这时，PON 所擅长的事情突然变得重要：集中式管理、点到多点连接、无源光分配、较少主动设备、较低功耗，以及面向海量终端的规模化接入。

所以，PON 进入 IDC 并不是"接入网技术入侵数据中心"。它更像是 POL 的一次自然延伸：从连接 Building 中的大量终端，走向连接 Data Center 中的大量 Rack 基础设施。AIDC 正在产生一个不同于 Compute Fabric 的 Infrastructure Connectivity 问题，而 PON 可能成为解决这一问题的一种新型底层连接架构。目前最明确的应用是 OOBM 和 Console，向 PDU、Facility 等更广泛基础设施网络扩展仍属于潜在方向。

综合来看，本文的核心判断可以概括为三句话：

第一，事实判断： PON-based OOBM 已经从 Hyperscaler 的工程实践进入设备商产品化和产业研究阶段，Data Center PON 正在成为一个新兴市场。这对目前运营商大量的PON网络技术人员是一个利好的信息。

第二，产业判断： 其核心驱动力并不是数据中心对更高速网络的需求，而是 AI 数据中心规模扩大后，对海量低带宽基础设施设备进行低成本连接和运维的需求。

第三，前瞻判断： 从架构上看，这可以视为 POL 从 Building/Campus Connectivity 向 Data Center Infrastructure Connectivity 的一次延伸；但目前最明确的应用仍是 OOBM 和 Console，向 PDU、Facility 等更广泛基础设施网络扩展仍属于潜在方向。

而一个更值得继续研究的问题是：究竟从多大规模开始，AIDC 的 Infrastructure Connectivity 会出现采用 DC-POL 的经济临界点？这可能决定 PON 究竟只是数据中心 OOBM 领域的一项优化技术，还是会进一步成为 AIDC 基础设施网络的一种新型基础架构。

参考资料

Dell’Oro Group. (2026, August). Data Center and Enterprise PON Equipment 5-Year Forecast Report.

Dell’Oro Group Official Market Research
- 引用说明：提供 2026 年 Data Center PON 设备收入同比增长 844%、2026—2030 年累计支出 30 亿美元及 52% CAGR 的市场预测数据与 DCIM/OOBM 场景定义。

Meta Infrastructure Networking Team / Bhatia, Anurag. (2025). PON-based Data Center Management & Console Architecture in Hyperscale Environments. Presented at NANOG 94 (North American Network Operators’ Group).

[NANOG 94 Presentation Archives]
- 引用说明：提供 Meta 在数据中心引入 PON 替换 Row 级交换机/铜缆的工程实践，包括 Canopy 机柜顶端封装、无状态 ONU 以及每个 Row/Rack 的连接密度数据。

Ciena Corporation. (2025/2026). Data Center Out-of-Band Management (DCOM) Solution Brief.

引用说明：出处文中“Ciena 实践”，提供基于 XGS-PON 的数据中心带外管理与路由平台整合商业解决方案。

Nokia Solutions and Networks. (2026, March). Nokia Aurelis for Data Centers: Reimagining Infrastructure Out-of-Band Management with Passive Optical Networks.

引用说明：出处文中“Nokia 2026 年 3 月发布”，提供 Aurelis 方案在有源设备减少率（最多 90%）、功耗降低（50% 以上）及运维优化（最多 80%）的特定对比指标。

光电共封装（CPO）：数据中心的下一场“能效革命

Fri, 10 Oct 2025 00:00:00 +0800

为何CPO（光电共封装）成为焦点？

近年来，AI大模型、云计算、自动驾驶和高性能计算（HPC）对数据中心带宽和算力需求激增。芯片算力不断强化，传输速率从100G、400G提升至800G乃至1.6T，但随之而来的是能耗和带宽瓶颈的新挑战。

传统架构中，交换芯片（ASIC）与光模块分离，光模块通过电连接器插在设备前面板上。这种“可插拔光模块”虽然灵活，速率提升后因电连接距离长，导致功耗高、信号衰减严重，且占用宝贵的前面板空间。

CPO的创新在于把光引擎与交换芯片直接封装，将电信号在极短距离内转换为光信号，极大减少能耗与信号损失，实现了光通信不再是外围，而是芯片核心部分。这一设计被视为突破数据中心能效和带宽瓶颈的关键。

CPO技术演进：从插拔到共生

CPO的发展是光通信追求更高速率与能效的必然趋势：

• 第一阶段：可插拔光模块。优点是灵活易维护，但速率超400G后，长距离电连接导致功耗激增和信号损耗。
• 第二阶段：近封装光学(Near-Packaged Optics)。光模块移近ASIC，采用短电缆连接，功耗有所下降，但光电器件依旧分离，能效提升有限。
• 第三阶段：光电共封装（CPO）。光芯片与ASIC共封装，电路径极短，数据即刻转为光信号，显著降低功耗并释放更多端口空间，完成了“电主光辅”向“电光共生”的结构转变。

CPO核心价值：更高带宽、更低功耗、更绿数据中心

CPO解决了数据中心的三大痛点：

优势	解决的问题	实际意义
更低功耗	电路径缩短，减少损耗	降低系统整体能耗，减轻散热负担
更高带宽	解放前面板空间	支撑51.2T、102.4T级大容量交换机
更小延迟	消除长距离电信号传输	适应AI、HPC等计算密集型应用对时延的严苛需求

面对AI集群中CPU、GPU与交换机间频繁高速数据传输需求，CPO不仅保障高速通信，还显著节省能耗，是算力中心实现“每瓦算力”跃升的底层革命。

2025年CPO产业现状：迈向实用化

• 芯片巨头布局积极：Broadcom、Marvell、Intel、NVIDIA均展示CPO样机，Broadcom Tomahawk 5验证了51.2Tbps级CPO系统。国内华为、中科院光电所等在硅光封装领域取得重要进展。
• 标准化稳步推进：OIF发布《CPO Implementation Agreement 1.0》，IEEE 802.3df/802.3dj推动1.6TbE、3.2TbE相关标准制定，为生态建设奠定基础。
• 制造生态形成：台积电、日月光、Amkor等封装厂已具备量产CPO封装能力，主流采用硅光与高密度封装技术（InFO、CoWoS、EMIB）。
• 应用初现端倪：CPO主要面向AI算力互连和超大规模数据中心核心交换，契合高带宽、低能耗、低延迟需求的典型场景。

三大挑战：热管理、封装精度与维护

• 散热难题：高功耗ASIC和光芯片共封装导致热密度高，光器件对温漂敏感。主流方案包括液冷微通道、分区散热和异构封装设计。
• 封装精度：光芯片对准误差需控制在微米级，自动化主动对准和光学测试助力提升良率。
• 维护复杂：CPO结构非传统可插拔，维护难度大。采用外置激光器（ELS）方案，将激光源独立外置，仅保留调制器在封装内，提高维护便捷度。

全球生态与标准化：协同共建

CPO涉及光电芯片、材料、封装、散热及测试等多环节，需产业链高度协同：

• 国际标准组织：OIF、COBO、IEEE、OCP等共同推动接口与封装标准制定。
• 产业合作网络：涵盖芯片设计、封装制造、光器件及系统厂商。
• 中国力量崛起：国内厂商从追赶者转向积极参与，推动生态与标准发展，彰显行业话语权提升。

未来三步走

• 短期（2025-2027）：小规模试用聚焦AI/HPC互连，外置激光方案主导，模块化系统逐步完善。
• 中期（2027-2030）：随102.4Tbps交换芯片商用，CPO进入主流，与NPO并行发展以满足多样化需求，光电协同设计工具链成熟。
• 长期（2030以后）：实现“光原生”数据中心架构，光电封装成为芯片设计常态，计算与通信深度融合。

结语：算力时代的能效转折点

CPO不仅是光模块的迭代，更是芯片与通信关系的重新定义。它将光通信从外围配件转变为算力系统核心，回应了AI计算时代对能效的极致追求。随着从可插拔到共封装的转变，CPO正引领数据中心迈向以光为底层语言的未来。