这次我们来看一个新融资事件Lumilens 完成了 7 亿美元融资目标很直接就是“用光替换数据中心里的线缆”。这个方向听起来没有大模型那么热闹但影响面一点都不小。AI 集群规模越来越大传统铜缆在距离、功耗、重量、散热和布线复杂度上的问题正在被放大光互连从可选项变成了必须认真评估的选项。围绕这个项目我准备重点回答三类问题第一Lumilens 这条技术路线到底要解决什么第二数据中心从铜缆切换到光互连实际落地要验证哪些指标第三如果你负责一个智算中心或高性能机房该怎么评估“以光代铜”方案能否在自己机房里跑通。这篇文章不会堆概念也不会给出 Lumenils 还没发布的假参数所有行业背景数据都按通用框架处理真正的产品规格要等官方白皮书出来再核对。先说结论Lumilens 的融资规模大、方向明确但光互连从来不是“把线换掉”那么简单它牵涉到光模块形态、交换芯片封装、布线规范、功耗预算、运维监控和批量割接。下面按评估框架逐层展开。1. Lumilens 核心能力速览先看这张速览表后面所有分析都围绕这几个维度展开。能力项说明公司定位面向数据中心的“以光代铜”互连方案提供商本轮融资约 7 亿美元基于公开标题信息技术方向用光链路替换传统数据中心线缆重点覆盖高速信号连接核心价值点更远传输距离、更低链路维护成本、提高端口密度、减轻机柜布线重量典型落地场景智算集群、超大规模数据中心、机柜内和跨机柜高速互联硬件形态公开信息尚未给出具体模块型号预计涉及光引擎、可插拔光模块或封装级光学部署方式数据中心硬件设施不是软件一键启动模式API / 软件接口当前公开信息未提及预计以硬件交付为主批量任务以链路批量部署、批量测试和设备验收为主适合读者数据中心网络架构师、智算平台运维、硬件选型工程师、光互连研究人员需要注意表格里的“预计”部分是基于行业通用判断不代表 Lumilens 官方已经公布。真正需要等的是光模块或光引擎的物理形态、支持的速率和传输距离、单端口功耗、兼容哪些交换芯片平台、能否在现有交换机上直接替换铜缆。2. 为什么数据中心线缆会成为瓶颈先说一个背景AI 训练集群和传统云计算集群的网络流量模型不一样。大模型训练通常依赖张量并行、流水线并行和专家并行这意味着 GPU 服务器之间、GPU 服务器与交换机之间需要有极高带宽和低延迟的互联。为了支持这种通信集群会使用大量高速线缆把节点连接起来。问题出在铜缆身上。传统数据中心常用的 DAC 铜缆和 AEC 有源电缆在短距离场景下确实稳定又便宜但速率往上走之后铜缆的有效传输距离会明显缩短。高速信号在铜介质里损耗大还容易受串扰影响当单端口速率从 400G 走向 800G 甚至 1.6T 时铜缆能覆盖的距离越来越短对线缆加工的精度要求也越来越高。另外一个很现实的问题是重量、弯曲半径和散热。大规模集群里几百根甚至上千根线缆捆在一起铜缆比光纤粗、重、硬布线和维护的难度随端口数量增加而快速上升。再加上交换机本身已经有不小的发热量再叠加铜缆信号驱动的功耗机柜的供电和散热预算很快就变得紧张。光互连解决的是这几个问题光缆传输距离更远同等速率下可以覆盖机柜内、跨机柜甚至跨楼层的场景光纤细、轻、柔走线方便采用合适的光模块或光引擎之后单端口功耗可以低于带 DSP 的铜缆或光模块方案。这是 Lumilens 这条路线的基本逻辑不是某一家公司的独占优势而是整个行业继续扩容时必然会面对的取舍。3. 光互连的三种落地形态机柜间、机柜内、封装内“用光替换线缆”这句话听起来简单实际落地时有几种差别很大的物理形态。理解这些形态才能判断 Lumilens 这类公司到底会在哪一层切入。3.1 可插拔光模块替换最容易成本也最直接最成熟的方式是保留现有交换机面板接口把原来的 DAC 铜缆换成 AOC 有源光缆或可插拔光模块加光纤。这种方式的好处是设备兼容性好只要交换机能插光模块基本不需要改硬件。但它的缺点也很明显可插拔模块需要额外的 DSP 或 CDR 芯片完成信号补偿和重新定时这些芯片会带来功耗和热量。高速率下可插拔光模块的散热压力很大面板前部空间也有限端口密度提升到一定水平后就很难继续往上堆。对于已经有大量现网设备的数据中心这是最现实的替换路径。3.2 LPO 线性驱动砍掉重定时芯片降低每端口功耗LPOLinear Pluggable Optics的思路是不在光模块内部做重新定时而是让交换芯片的 SerDes 直接驱动光引擎。这样一来光模块里省掉一部分 DSP/CDR 功能单端口功耗更低成本也更低。代价是系统设计难度提高。交换芯片和光模块之间的链路必须整体优化信号完整性要求更高误码率指标也需要重新衡量。LPO 通常更适合短距离、信号质量较好的场景比如机柜内或同一列交换机之间。如果 Lumilens 走这条线它的竞争力会体现在能不能做出“在几乎不增加功耗的同时支持足够高速率和可接受误码率”的光引擎。3.3 CPO 共封装光学把光引擎搬进芯片封装再进一步是 CPOCo-Packaged Optics把光引擎直接封装到交换芯片的基板上。这样信号不需要从交换芯片经过很长的 PCB 走线再进入面板光模块而是直接在封装内部完成光电转换功耗和信号损耗都能降下来端口密度也可以做得更高。CPO 的问题在于维护方式改变传统光模块坏了可以单独插拔更换CPO 的光引擎如果出问题可能需要更换整个交换板卡或处理组件维修成本更高对运维体系的要求也不一样。目前 CPO 尚处于标准化和规模化验证阶段真正大规模商用的案例还不多。Lumilens 如果面向“替换数据中心线缆”CPO 或硅光引擎是值得重点关注的方向因为它最直接解决线缆和连接器层面带来的复杂度和功耗问题。不过要强调一点现在没有 Lumilens 官方资料确认它最终采用哪一种形态。上面这部分是行业技术地图判读时作为参考即可。真实产品可能是其中一种也可能是几种形态的混合方案。4. 从“单条链路”到“集群网络”光互连选型观察点不管 Lumilens 最终采用哪种光引擎数据中心用户在实际选型时都会遇到这样一组观察点。4.1 传输距离先确定自己的场景是机柜内还是跨机柜。机柜内一般是几米到十几米铜缆短距离方案在成本上仍有竞争力跨机柜和跨列通常是几十米这是光互连优势明显的区间再往上到楼宇间基本只能靠单模光纤。Lumilens 如果主打“替换线缆”大概率瞄准的是传统上铜缆覆盖的中短距离区间而不是已经大量采用光模块的长距离链路。4.2 速率和端口密度单端口速率越高线缆对信号质量的要求越高。可以用各代际高速率技术做初步判断如果目标是未来单端口 1.6T可插拔光模块的体积和散热会成问题CPO 或高密度光引擎更有可能成为主流。端口密度直接关系到交换机面板能不能放下所有端口也关系到从交换芯片扇出到这个面板之间的 PCB 走线复杂度。4.3 功耗预算“以光代铜”并不自动等于功耗更低。如果光模块里带有完整 DSP功耗可能不低如果采用 LPO 或共封装光学功耗优势才更明显。所以选型时要重点问一个数字每端口功耗是多少换算成整台交换机、整个机柜的额外发热量再和现有供电制冷系统做匹配。4.4 可靠性与会维护性光链路比铜链路多出不少可维护节点包括光模块、光引擎、连接器端面、光纤跳线。任何一个点被污染或损坏就会丢包。因此要看 DDM 数字诊断监控是否完整、连接器端面能否现场清洁、光纤管理是否方便。这些细节决定了一条技术路线能不能在大规模机房长期稳定运行。4.5 总拥有成本不要只看线缆单价。总成本包括光模块采购、光纤布线施工、测试仪表、维护备件、培训以及因升级造成的停产时间。铜缆在短距离上仍然便宜光互连的优势主要体现在中长距离、高密度、低功耗和少布线这几个方面。每一家数据中心都要结合自己的拓扑结构做 TCO 计算。5. 数据中心部署环境与前置条件如果测试环境确定要引入光互连方案无论对象是 Lumilens 还是其他厂商下面这几个前置条件都应该提前准备。5.1 供电与散热规划光引擎和光模块同样是发热源新增链路后机柜热密度会变化。需要拿到设备的功耗规格模拟整柜供电余量和空调或液冷系统能否覆盖。比较理想的做法是在小范围机柜内先铺一个试点实测温度和功耗后再扩大部署。5.2 交换平台兼容性先确认现有交换机的端口是否支持光模块或光引擎。可插拔光模块相对简单只要面板端口支持 QSFP-DD、OSFP 等标准接口即可如果方案是 CPO 或板载光引擎那就不是“插一根线”能解决的需要更换交换机硬件。这一步必须在选型前确认否则会变成整机更换的大项目。5.3 布线与端面管理光纤布线有自己的规则注意极性、弯曲半径、跳线长度和标签管理。连接器端面如果有灰尘或脏污会导致光功率下降和误码率上升。建议准备光纤清洁工具和检测设备在部署前先完成端面检查。这也是很多光链路故障的根本原因。5.4 测试仪表与软件基础测试需要光功率计、误码仪、OTDR 光时域反射仪。运维侧需要能读取光模块 DDM 信息的网管或命令行工具便于定期查看收发光功率、温度、电压。软件层面建议先把链路台账建立好记录每个端口的链路 ID、机柜位置、光纤极性、预期光功率和实际测量值。6. 功能验证与批量部署流程下面这套流程是通用的光互连验收流程也适用于 Lumilens 这类“以光代铜”方案的初测。6.1 单链路验证先用一条链路跑通最基础的功能。# 查看网口链路状态和速率 ethtool eth0 # 查看光模块 DDM 信息包含温度、电压、收发光功率 ethtool -m eth0 # 查看端口统计关注丢包、CRC 错误、FCS 错误 ethtool -S eth0 | grep -E fcs|rx_error|tx_error|drop判断标准网口协商速率达到预期光功率在接收灵敏度范围内连续打流测试下没有丢包DDM 温度、电压正常。这条链路通过后再进入下一环节。6.2 光功率预算计算光链路能不能通第一步看光功率够不够。可以写一个简单的 Python 脚本做预算估算。# 光功率预算估算脚本参数需要按实际设备规格替换 def calc_margin(tx_power_dbm, rx_sensitivity_dbm, connector_loss_db, fiber_loss_db_per_km, distance_km): link_loss connector_loss_db fiber_loss_db_per_km * distance_km budget tx_power_dbm - rx_sensitivity_dbm margin budget - link_loss return budget, link_loss, margin if __name__ __main__: # 示例值发射功率 2dBm接收灵敏度 -10dBm2 对连接器共 0.8dB光纤每公里 0.35dB budget, link_loss, margin calc_margin( tx_power_dbm2.0, rx_sensitivity_dbm-10.0, connector_loss_db0.8, fiber_loss_db_per_km0.35, distance_km0.05, ) print(f链路预算: {budget:.2f} dB) print(f链路总损耗: {link_loss:.2f} dB) print(f余量: {margin:.2f} dB)注意这只是示例计算真实光模块和光引擎的预算值需要以厂商规格表为准。如果计算出来的余量很小说明链路设计很紧张不建议大批量部署。6.3 批量并发测试单条链路正常不代表批量部署正常。可以做一个简单循环遍历多个端口读取 DDM 并落盘。# 批量采集多个网口的光模块 DDM 信息 for port in 0 1 2 3 4 5; do ethtool -m eth${port} ddm_eth${port}.log 21 done # 查看所有日志里的接收光功率和温度 grep -H -E Laser output|Receiver signal|Temperature ddm_eth*.log更好的做法是使用自动化打流工具比如 iperf3 或更专业的数据包发生器在一个时间段内对多条链路同时发送压力流量观察是否有单条链路出现误码或丢包。6.4 长稳测试长稳测试一般建议跑 24 到 72 小时覆盖满带宽持续打流高温环境或模拟峰值负载频繁插拔或链路重训练电源波动场景。如果方案在长稳测试中出现偶发丢包要重点排查是不是光功率余量不足、连接器端面污染、温度过高或固件兼容性有问题。6.5 链路台账与批量部署批量部署前先建一个链路登记文件格式可以参考下面的 JSON。{ site: dc-east, test_date: 2025-03-01, links: [ { link_id: R01-C01-NIC01, location: rack-01-pos-01, type: optical, distance_m: 30, rate: 800G, expected_tx_dbm: 2.0, expected_rx_dbm: -5.0, actual_rx_dbm: -4.8, status: pass } ] }这种台账对后续排障很有用。哪个端口出问题可以直接对比“预期功率”和“实际功率”。7. 资源占用与性能观察对光互连方案来说最重要的资源指标和普通软件服务不太一样主要看功耗、温度、端口密度和链路稳定性。7.1 功耗与温度观察重点不是 GPU 显存而是光模块或光引擎的 DDM 温度。高温会导致光模块性能劣化、误码增加。可以在长时间运行中周期采集# 每 5 分钟采集一次该端口的光模块状态 for i in {1..288}; do date ddm_history.log ethtool -m eth0 | grep -E Temperature|Laser|Signal ddm_history.log sleep 300 done如果温度持续走高就要检查机柜风道、封堵漏风点或调整散热策略。7.2 功耗对比估算铜缆和光缆的功耗差异很难用一个固定数字概括因为模块类型和工作负载都不一样。但可以建立一套估算逻辑# 总信号链路功耗 交换芯片 SerDes 功耗 光模块/光引擎功耗 线缆驱动功耗一般思路是先计算现有 DAC 铜缆链路的总功耗再计算替换成光方案后的等效功耗两者相减就是节省值。这一步不要用厂商宣传值最好用实际计量插座或交换机功耗监测数据来验证。7.3 端口密度与布线空间光互连的核心收益之一是节省机柜空间和改善走线。一个简单的方法是统计同样数量的端口铜缆占用的理线架数量是多少光缆占用的数量是多少。算下来如果光方案能明显减少线缆空间机柜前后的理线时间和散热都会更可控。8. 常见问题与排查方法光互连部署中最常遇到的问题集中在光功率、温度、兼容性和污损这几个方向。问题现象可能原因排查方式解决方案链路无法协商光模块与交换平台不兼容查看设备日志和兼容列表刷新固件或更换兼容模块接收光功率过低连接器端面脏污或光纤损耗过大用光功率计测量收发光清洁端面重新插拔或更换跳线误码率逐步升高光模块温度过高检查 DDM 温度调整风道、降低机柜密度或增加散热偶发丢包但光功率正常链路余量不足信号质量差长时间打流观察误码情况缩短链路距离或增加补偿端口在批量测试中失败施工过程引入污染对比链路台账找差异针对失败链路单独复测更换后原有业务中断割接方案不完善检查切换时间点和路由准备回退方案保留原有链路标签无法读取 DDM 数据驱动或管理协议不支持检查系统日志和驱动版本升级驱动或换用支持 DDM 的模块整柜功耗超预算光引擎方案功耗高于原铜缆实测整柜功耗对比减少高功耗模块数量或升级制冷共封装光引擎故障单体损坏无法单独替换确认故障板卡范围按整板替换计划执行长稳测试偶尔闪断电源或 EMI 干扰查看电源日志和温度波动调整电源配置和机柜接地每一条故障处理完最好把原因写回链路台账这样后续批量部署可以提前规避。9. 使用边界与注意事项光互连并不是“全光必胜”。在几米到十几米的超高成本敏感场景里铜缆依然有优势数据中心也不会因为拿到 7 亿美元融资就立刻全面替换线缆。真正的边界要分三块看。第一场景边界。如果现有数据中心端口密度不高、速率还在 100G 或 400G 以内铜缆仍然是稳定省钱的选择。高速率、高密度、长距离才是光互连的主战场。第二运维边界。光链路多了之后端面清洁、纤芯极性、跳线管理都必须提上日程。如果没有熟练的光纤布线团队至少要提前准备工具和培训。第三合规边界。数据中心采用新硬件需要确认设备符合当地技术标准、采购渠道正规、固件来源可信。测试过程中如果用到了真实业务数据要遵守隐私保护和数据安全要求不能因为“只是换线缆”就忽略流程。任何涉及设备供应商的授权、兼容性声明和售后服务都应该在采购合同里落实。10. 总结与下一步Lumilens 拿到 7 亿美元融资说明资本市场对“用光替换数据中心线缆”这个方向有明确期待。但这个项目能不能真正落地决定因素不是融资额而是光引擎的物理形态、每端口功耗、传输距离和与主流交换平台的兼容性。对关注这条技术路线的人下一步建议做两件事。第一等官方发布技术白皮书后先核对光引擎形态属于可插拔、LPO 还是 CPO再对照自己的机房拓扑看距离和功耗是否匹配。第二拿到测试样品后先跑一轮本文第 6 节的单链路验证、批量并发测试和 72 小时长稳测试重点记录 DDM 温度、光功率余量和误码率。最容易踩的坑是只看单端口性能忽略整柜热密度和布线维护。光互连从一开始就要以“整机房可运维”为标准来评估而不是单独看某一根线缆能不能发光。第一次引入新方案时最好选一个独立机柜做试点跑完完整测试流程再谈大规模替换。