数据中心光互连：从铜缆瓶颈到CPO封装重构-编程实验室

机房里的线缆，正在成为整个数据中心最让人头疼的部分。速率越高，铜缆越粗，越难折，越难散热；信号衰减、串扰、误码全都在高速率下集中爆发。即便只是两米机柜内的互联，都越来越接近物理极限。

在这种背景下，一家名为 Lumilens 的初创公司对外宣布完成新一轮融资，规模达到 7 亿美元，用来推进“用光替代数据中心线缆”这件事，就不难理解了。标题里的金额不管最终结构如何，至少说明资本愿意为一个长期被认为“还很遥远”的方向砸下重注。

这篇文章不炒概念，只建立一个基本判断：数据中心内部的光互连，并不是把铜线换成光纤那么简单，而是一次从网络架构到运维体系、从供应链到芯片封装方式的整体重构。真正驱动它的，不是“光比电快”这种直觉，而是功耗、距离和密度三重瓶颈。

1. 为什么数据中心的“最后一寸铜线”会成为瓶颈

1.1 铜线的物理极限：速率越高，问题越尖锐

过去几代数据中心网络升级，一直都绕不开一件事：如何在更高速率下保持信号稳定。10G 时代，铜缆还算从容；到了 100G、400G，问题开始浮现；再往上走，同样长度的铜缆在单位时间里要承载的数据量越来越大，信号衰减、电磁串扰、误码率都会快速恶化。

这不是线材厂商不努力，而是物理规律在起作用。高频信号在铜介质里传输，会受到集肤效应、介质损耗和阻抗不连续的影响。速率越高，信号衰减越明显，能跑通的距离就越短。所以你会看到高速率下的无源铜缆（DAC）越来越多地限制在几米以内，一旦距离变长，就要换用有源电缆（AEC）或者光模块。

如果把视角放到整个数据中心，这里就会出现一个很尴尬的局面：网络端口速度持续往上走，但机房内部的空间、散热、布线通道并不会同步变大。铜缆为了应对高速率，需要加粗、加屏蔽、加连接器补偿电路，最终变成一根又粗又硬、弯曲半径很大、施工时很难伺候的线缆。很多做基础设施的工程师都有体会：400G 之后，光是在机柜里理线就够让人崩溃的。

1.2 “功耗墙”才是真正的危机

很多讨论把高速铜缆的问题归结为“跑不远”，但真正让超大规模数据中心焦虑的，是功耗。

铜缆传输数据，本质上是在铜线里推动电流变化。速率越高，驱动电路和信号均衡电路要做的补偿越多，消耗的功率就越大。速率翻倍时，链路功耗不会是简单的翻倍，而是会处在一条往上走得更陡的曲线上。当一条链路只是几瓦，机房里有上万条链路时，这个数字会变得非常惊人。

另一个问题是散热。高速铜缆的功耗最终都会变成热量，热量又会对周边设备产生影响。数据中心为了应对额外热量，需要更强的制冷，这又会进一步拉高运行成本。前段时间很多讨论都在讲 GPU 显卡功耗高，其实网络端的功耗同样在快速膨胀。只不过它分散在很多条链路里，不容易被单独注意到。

相比之下，光通信在长距离传输上的单位比特能耗明显更低。光纤本身的损耗很小，信号传输质量也更稳定。当然，光互连并不是零功耗，激光器、调制器、光电转换、接收放大都会耗电，但它提供了一个更关键的选项：把链路从功耗增长曲线的悬崖边拉回来。

1.3 为什么只看“速度提升”会误判这个方案

很多人一听到“用光代替铜线”，第一反应是“光更快”。但电信号在铜线里的传播速度大概是光速的 60% 到 70%，而光在光纤里的速度也并不是真空光速，而是视不同折射率，通常在光速的 65% 左右。两者在这个维度上并没有本质差距。

所以“光互连更厉害”这个说法不能只用单端口速率来证明。同样宣称 800G 速率，铜缆和光缆都能做到，真正拉开差距的是：在保持高速率的前提下，功耗差多少，距离能拉多远，布线密度能提高多少，系统能否长期稳定运行。

这也是判断 Lumilens 这类公司或任何光互连方案时最该注意的一点：不要只看“能不能更快”，而要算“单位比特传输成本”。把光用于数据中心内部互联，本质上是用相对成熟的光学技术，去替代一段正在逼近天花板的电互联链路。

2. 光互连不是“把线换成光”，而是把光下沉到离芯片更近的地方

2.1 三种“光互连”形态，不能混为一谈

光通信早就是数据中心的常客了。机房里的长距离链路，通常都使用可插拔光模块：交换机的面板端口上插一个光模块，外面接上光纤。这种形态非常成熟，模块坏了直接拔下来换新的，运维团队也很熟悉。

但端口速率继续提升时，可插拔光模块开始暴露问题。光模块放在面板端口上，与交换芯片之间有很长一段 PCB 走线。速率越高，这段电信号路径的信号完整性和功耗问题就越突出。为了解决这个问题，业界陆续出现了 LPO（线性驱动可插拔光模块）等新形态，核心思路是简化模块里的 DSP 芯片，让光模块更接近一个透明器件，从而降低功耗和时延。

再往前走一步，就是 CPO（共封装光学）。它不再是把光模块插在面板上，而是把光引擎和交换芯片封装在同一个基板上，让光电转换尽量靠近计算核心。这样电信号只需要走很短的距离，大量链路变成光信号传输。

这三种形态虽然都叫“光互连”，但技术难度、产业链和运维模式完全不同。讨论这个话题时，如果只笼统地说“光会取代铜”，很容易造成误判。

2.2 从“机架间”到“芯片间”：光在一步步靠近计算单元

回顾光通信进入数据中心的历史，会看到一个清晰的趋势：光一直在沿着网络链路往前走，从长途骨干网，到城域网，到数据中心机架间，再到机柜内，现在正在往板级和芯片封装级下沉。

为什么会有这个趋势？核心逻辑是：链路越短，电信号越有优势；但当速率和功耗压力大到一定程度后，即使是很短一段电通路，也会成为瓶颈。比如大规模 AI 训练集群里的 GPU 与 GPU 之间，通信量非常大，GPU 芯片之间如果全部依赖 PCB 走线，会因为布线空间、信号质量和功耗而受限。于是业界开始考虑把光引擎直接封装到 GPU 或交换芯片附近，让芯片之间的互联直接走光。

这里值得强调一点：光并不会在所有距离上取代电。1 米以内的极短链路，铜仍然有成本和功耗优势。光的真正价值在于，当距离超过某个阈值、速率压得很高时，它能让链路功耗不随着速率一起失控。

2.3 融资规模背后：市场先把“确定性”买下来了

回到最开头的问题：为什么一个做“光互连”的初创公司，能拿到这么多钱？

我的判断是：这轮融资本质上买的是“确定性”，而不是某个阶段的成熟产品。数据中心的功耗问题已经足够明确，AI 集群对带宽和低时延的需求足够明确，光互连在更高速率下替换部分电链路的方向足够明确。当这些条件同时满足时，资本愿意提前押注。

但融资成功不等于量产成功，更不等于技术路线已经跑通。决定光互连最终能走多远的，不是发布会和融资新闻，而是芯片良率、封装工艺、客户认证、长期可靠性这些看起来不那么性感的指标。

3. 从“换线”到“换架构”，真正难解决的问题是什么

3.1 封装、热和良率：CPO 这类新形态为什么难量产

先说一个常见的直觉：把光模块从面板上移除，集成到封装里，不是更省空间吗？理论上确实省了，但工程上代价非常大。

光引擎里有很多激光器，激光器对温度极其敏感。温度变化会导致激光波长漂移、输出功率波动，进而影响整条链路的稳定性。如果光引擎只是插在面板上，它自己有一个相对独立的壳体，散热设计比较好做。一旦把光引擎封装进交换芯片的基板里，它就要和交换芯片挤在同一个散热空间里，发热源更多、布局更复杂，热管理的难度直接上升。

封装精度也是一个问题。光引擎需要在基板上和其他芯片做高精度对准，激光器、探测器、光纤阵列的耦合误差必须控制在很小范围内。这直接影响良率，良率一低，成本就压不下来。这也是为什么很多光互连新方案在实验室里表现很好，真正进入量产时却会一再延期。

3.2 标准、供应链和可维护性：产业链要重新分工

传统可插拔光模块有一个成熟的多源协议生态，不同厂商的模块可以互相兼容，采购方不会被单一家供应商绑定。但 CPO 或者其他新形态会打破这种模式。光引擎一旦和交换芯片封装在一起，就不能再像更换模块那样单独更换光器件。如果某一路光引擎故障，可能整个交换机模块，甚至整颗芯片都要一起更换。这会让设备厂商、云厂商和运维团队面临一个很现实的问题：可维护性比以前差。

供应链也在发生变化。原来光模块厂商负责激光器封装、测试和模块组装，芯片厂商负责交换芯片设计，两者边界清晰。CPO 方案里，双方的工作被揉在一起，责任边界变得模糊。厂商之间谁主导、谁代工、谁验收，都需要重新磨合。

这些问题不是光互连本身解决不了的，但需要时间。技术成熟不只看某一家公司的能力，更看整个产业生态能不能围绕新形态建立稳定的分工与标准。

3.3 存量数据中心要面对的“混合时代”

大型云计算厂商的数据中心有几十万甚至上百万台服务器，不可能因为新趋势出现就一夜之间整体替换。现实的演进路径一定是：新建的超大规模数据中心、AI 训练集群优先采用光互连；传统机架继续沿用现有的铜缆和可插拔光模块；机柜内短距离链路继续保留铜缆；跨机柜、跨列的长距离链路则加速转向光方案。

所以接下来的很长一段时间里，一个数据中心内部会是“铜缆 + 可插拔光模块 + 新光互连形态”并存的混合架构。运维团队要同时熟悉两种完全不同的排障思路，采购团队要在新旧技术路线之间做平衡，芯片厂商也要同时维护多条产品线。

这是工程实践中很容易被忽略的一点：新技术从来不是在真空中推广的，它必须背负一大笔历史兼容成本。

3.4 大额融资真正想解决的问题

一家初创公司拿到巨额融资后，要面对的事情并不会变少：建研发团队、完善测试验证、和下游客户一起做小规模试点、建立供应链、支撑前期几年无法盈利的研发周期。7 亿美元放在制造业面前，也并不是一个可以高枕无忧的数字。

它真正输送给市场的是一个信号：数据中心内部的光互连已经从“要不要做”变成了“怎么做、何时做”。后续的竞争，会从讲故事转向比拼产品良率和客户验证速度。谁能在功耗、成本、可维护性上拿出可复制的方案，谁才有机会真正走进机房。

4. 工程落地前的判断框架：需求、验证与排查链路

4.1 先判断你的场景是否真的需要光互连

光互连是趋势，但不等于现在每一个数据中心都应该全面拥抱它。判断自己是否需要引入新方案，可以从链路距离、速率、功耗预算和运维能力四个维度去评估：

场景	链路特征	更合适的选择
机柜内同一交换机到服务器	短距离、中等速率	铜缆或有源电缆
跨机柜、跨列	几十米到几百米、高速率	可插拔光模块
大规模 AI 训练集群	高带宽、高密度、功耗压力极大	关注 LPO、CPO 等新形态
存量机房升级	设备年代不同、兼容性复杂	先做局部试点，不宜整体切换

这里要说明：上面只是通用判断，不是绝对结论。最终还是要结合自己的设备型号、机房条件、采购周期和团队能力来定。

4.2 引入光方案前的验证清单

如果你的场景确实需要往光互连方向走，不要一上来就批量采购。先按下面这个顺序做验证：

先用小批量样机在同一批设备中验证，观察误码率、温度和功耗是否与标签一致。
确认供应商责任边界，明确“链路故障时，是模块问题、线缆问题还是设备问题”。
确认备件策略。光引擎或封装式器件损坏后，维修路径是什么，更换成本是多少。
统计实际功耗和散热变化，不要只信实验室数据，要以实际机柜温度为依据。
让运维团队提前参与，确认团队是否具备光域检测工具和排障经验。

不要因为“光互连是趋势”，就把机房里所有铜缆都换掉。趋势是长期判断，落地是约束选择。

4.3 已经使用光链路时，故障排查链路

光链路故障和铜缆故障的排查思路并不一样。铜缆很多时候用测线仪就能判断通断，光链路则要借助光功率计、光源、光衰耗计等工具。如果已经在用光模块或光引擎，可以按下面的链路排查：

先看现象：是速率掉速、误码、丢包，还是完全无光。
清洁光纤端面。光纤链路遇到的大部分误码和断链，都可以追溯到脏污端面。
检查光功率。查看收端功率是否在模块规格书要求的范围内。
检查链路损耗。逐段检查熔接点、跳线、配线架的损耗值。
检查模块本身。查看模块温度告警、固件版本、兼容性参数。
最后再检查设备侧。比如端口协商、FEC 配置、芯片侧统计。

在 Linux 系统上，可以通过常见命令获取部分链路信息，不同版本和厂商实现会略有差异：

ethtool -m eth0 # 查看光模块诊断信息 ethtool -S eth0 # 查看网卡统计，重点关注误码和 FEC 相关计数

排查光纤链路时的第一原则：先清洁端面，再怀疑设备。光纤断链和误码里，有一大半是脏端面造成的。

5. 那么大规模的“光进铜退”会带来什么长期变化

5.1 运维方式：从“拉线”到“管光路”

光互连普及之后，数据中心运维团队的知识结构会发生改变。过去铜缆时代，测线仪、打水晶头、网线测试几乎是基本功；光链路时代，运维人员需要掌握光功率计、OTDR、端面检测仪等工具，还要理解光模块告警参数、激光器工作温度、光纤弯曲半径这类概念。

这并不需要团队人人都成为光学专家，但确实需要至少几位核心成员具备光域排障能力。日常运维中还要增加对光纤端面的定期检查，对跳线、配线架连接器进行规范管理。一个常见的坑是：机房施工时没有使用防尘帽，或者清洁方式不规范，导致光纤端面被污染，最终表现为应用层偶发丢包。

5.2 对普通开发者和云基础架构团队意味着什么

大部分应用开发者并不会直接接触光模块或光引擎。上层网络协议、云平台 API 会把物理层细节抽象掉，开发者编写的代码仍然是基于 HTTP、RPC、分布式存储这些高层接口。

对于做云基础架构和底层网络的人来说，变化会更明显：网络拓扑设计不再只考虑端口数量，还要考虑光器件功耗和散热模组；容量规划要区分“电链路优化”和“光链路优化”；成本模型里也会多出光模块折旧、光纤维护和备件采购的权重。这类变化不会让日常开发语言发生剧变，但会让基础设施团队在做预算、选型和扩容时有更多新变量。