数据中心光互连：从铜缆瓶颈到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、分布式存储这些高层接口。对于做云基础架构和底层网络的人来说变化会更明显网络拓扑设计不再只考虑端口数量还要考虑光器件功耗和散热模组容量规划要区分“电链路优化”和“光链路优化”成本模型里也会多出光模块折旧、光纤维护和备件采购的权重。这类变化不会让日常开发语言发生剧变但会让基础设施团队在做预算、选型和扩容时有更多新变量。5.3 长期光互连不只是数据中心而是“系统级互连”如果往前看十年光互连的影响不会只停留在数据中心内部。芯片与芯片之间的光互连、光互连内存、传感器网络、车载计算、边缘设备都在尝试把“光”下沉到更接近计算核心的位置。数据中心只是最先被功耗和带宽瓶颈逼到门口的场景。回到 Lumilens 那轮融资我更愿意把它理解成一次关于底层基础设施的重注。它押的不是一根更好的线而是一个方向当电信号在更高频率、更短距离上越来越难走时计算系统必须想办法让光来承担更多传输任务。这个方向能不能按预期兑现还要看封装、良率、标准和维护成本等一堆实际问题。但有一件事已经很清楚数据中心里不会再有哪根线可以靠不变应万变。速率继续往上走新的传输方案就必须不断往下探从芯片间到系统间重新定义整个网络的物理层。对工程师来说与其等着革命发生不如先问自己一个问题你的链路里真正的瓶颈到底长在哪一层