数据中心正在迎来一个容易被忽视、但影响深远的转折互联介质正在从铜线切换到光。过去十年交换机端口的速率从 40G 走到 800G但线缆的物理极限却越来越明显——距离一长、速率一高铜缆的功耗和成本会指数上升。就在这个窗口期Lumilens 以 700M 美元的融资规模进入大众视野主打的正是“用光替代数据中心内部的线缆”。这件事不只是融资新闻它背后是整个 AI 算力集群对互联带宽的极端需求以及硅光技术从实验室走向大规模量产的开端。这篇文章从技术角度拆解三件事第一数据中心内部互联为什么会从铜转向光第二Lumilens 这类公司做的光互连到底改变了什么第三作为开发者、算法工程师或运维人员你要关注哪些技术变量。1. 为什么数据中心互联会成为千亿美元赛道先说结论GPU 集群的扩展速度已经超过了传统铜缆互联能承载的物理极限。大模型训练本质上是一个大规模并行计算问题。以万卡集群为例数千张 GPU 在训练同一个模型时需要频繁同步梯度。每一次梯度同步都意味着节点之间要传输大量数据。GPU 算力提升可以靠芯片设计、先进工艺但卡与卡之间的数据搬运必须靠网络和线缆完成。传统数据中心内部大量使用 DACDirect Attach Cable铜缆也就是我们常说的无源高速铜缆。它的优势很明显成本低、功耗低、即插即用。但它有一个硬伤随着速率提升铜缆的有效传输距离急剧缩短。400G 时代DAC 的有效传输距离通常只有 2 到 3 米。800G 时代这个距离还会继续收缩。一旦超过有效距离信号完整性会严重劣化误码率上升只能改用 AEC有源电缆或光模块。大模型集群的物理规模决定了GPU 和 GPU 之间、GPU 和交换机之间的距离不可能都很短。一个标准的智算中心机房机柜到 Leaf 交换机的距离往往超过 5 米跨机柜和跨列的距离可能是几十米到上百米。在这个尺度下铜缆已经无能为力。更关键的是功耗。速率越高铜缆上的信号损耗越大。为了维持信号质量就需要更强的驱动电路和均衡算法。这会导致 SerDes 功耗、线缆自身发热都快速上升。800G 铜缆链路的功耗预算非常紧张光模块虽然也有功耗但在长距离和高速率场景下单位比特传输功耗反而优于铜缆。所以 Lumilens 拿到的这 700M 美元本质上不是给一家初创公司的“估值奖励”而是资本市场对“数据中心互联介质换代”这个确定性趋势的押注。2. 从“铜线”到“光线”变化发生在哪一层要理解光互连替代铜缆先要分清数据中心里有哪几种互联需求。按照通信距离和层次可以简单分成四类互联层级典型距离传统方案光互连方案芯片内部 / 封装级毫米级金属走线共封装光学CPO光 I/O 到封装边缘机柜内 / GPU 到交换机2-10 米DAC 铜缆、AEC近封装光学NPO、可插拔光模块列间 / 交换机之间10-100 米AOC 有源光缆可插拔光模块QSFP-DD、OSFP楼宇间 / 数据中心互联 DCI数百米到数十公里长距离光模块相干光模块、硅光集成Lumilens 这种公司的核心产品方向主要集中在数据中心内部的中短距离光互连也就是机柜内、机柜到交换机、交换机到交换机这一段。这段距离过去大量使用 DAC 和 AOC现在正在被更高速率、更低功耗的光模块替代。很多人会误以为“光进铜退”只是把线换一下。实际上这个替换发生在三个层面第一层是物理介质。这条线从铜缆换成光纤信号载体从电脉冲变成光脉冲。这是最直观的变化。第二层是信号调制与编码。电信号需要经过 DSP数字信号处理器调制到光载波上到达另一端后再解调回电信号。DSP 的算法直接决定误码率、功耗和成本。第三层是系统架构。当光模块足够小、功耗足够低交换机厂商、GPU 厂商就会考虑要不要把光引擎做到交换芯片旁边甚至做到 GPU 封装旁边。这就是 CPOCo-Packaged Optics路线架构一旦变化整个散热、维护、故障隔离方式都要跟着改。所以光互连替代铜缆不只是组件替换而是从传输介质到系统架构的整体迁移。这也是为什么头部云厂商会深度参与这类创业公司的融资——它关系到未来十万卡集群的物理可行性。3. Lumilens 到底是什么类型的公司由于公开信息有限我们可以先看标题里的几个关键词Startup、Raise、$700M、Replace Data-Center Wires with Light。这是一个典型的硅光互联创业公司画像。从行业逻辑推断它大概率做的事情是把传统的光模块和光引擎通过硅光工艺和先进封装集成在一起做成更高密度、更低功耗、更低成本的光互连产品。这里需要理解硅光Silicon Photonics到底是什么。传统的分立光模块是用几颗独立的芯片实现的激光器芯片负责发光调制器芯片负责把电信号加载到光上探测器芯片负责接收。每一颗芯片用不同的材料体系比如磷化铟InP、砷化镓GaAs封装时要把它们精密对准、耦合、打线工艺复杂、成本高。硅光则是用 CMOS 工艺来做光学器件。把波导、调制器、探测器、耦合器全部集成到硅片上再用半导体工艺批量制造。好处是成本可以摊薄、集成度可以提升、功耗可以降低。Lumilens 要做的事情从技术方向看大概率属于这个范畴用硅光把数据中心内部的光互连做得更便宜、更可靠、更容易大规模部署。但这不意味着它可以绕开光模块行业积累的工程难题。硅光虽然集成度高但激光器仍然需要外部光源或混合集成光纤到芯片的耦合效率仍然是个老大难大功率下的热管理也远比电芯片复杂。这也是为什么 Lumilens 拿到的钱不是几千万而是 700M 美元——因为硅光的研发和量产需要同时攻克芯片设计、封装工艺、可靠性验证和客户导入四个环节任何一个环节掉链子产品都上不了量。4. 光互连技术栈的核心组件拆解为了给后面实践部分做铺垫这里先梳理光互连中最常接触的六个技术概念。做网络、系统或算法优化的工程师理解这些词以后才能看懂设备厂商的产品参数。光模块Optical Transceiver把电信号转成光信号、再把光信号转回电信号的器件。常见封装有 QSFP-DD、OSFP。数据中心内部主流是 400G、800G 这类可插拔模块。DSPDigital Signal Processor光模块内部负责信号修复、均衡和编码的芯片。它决定一个 800G 模块要用多高功耗的电芯片去补偿信号损伤也直接影响模块价格。DSP 是光模块功耗的主要来源之一。硅光芯片Silicon Photonics用 CMOS 工艺制造的光学集成电路包含调制器、探测器、波导等结构。CPOCo-Packaged Optics把光引擎和交换芯片封装在同一个基板上缩短电信号走线距离降低功耗提高整机端口密度。CPO 是比可插拔光模块更激进的架构。LPOLinear-drive Pluggable Optics去掉模块内部的 DSP 重定时功能让交换芯片的 SerDes 直接驱动光引擎。功耗更低但牺牲了信号恢复能力对链路质量要求更高。AOC / DAC / AEC分别是有源光缆、无源铜缆、有源电缆。AOC 适合中短距离DAC 适合短距离AEC 在铜缆基础上加入信号放大延长铜缆可用距离。这些概念之间不是互斥的而是针对“密度、功耗、成本、距离”四个维度的不同取舍。理解取舍关系比记住概念本身更重要。5. 为什么 AI 大模型集群最需要光互连前面讲的是传输介质和产品形态这一节聚焦一个实际问题大模型训练集群为什么是最先被光互连改变的场景。大模型训练的通信模式大体可以分为三类。第一类是集合通信Collective Communication。AllReduce、AllGather 这类操作要求在短时间内完成跨节点数据聚合。万卡训练时每完成一个迭代都要做一次全集群的梯度同步。通信时间直接变成训练等待时间通信效率就是训练效率。第二类是流水线并行通信。在流水线并行中不同层的计算分布在不同 GPU 上前向和反向传播需要在层与层之间传输激活值和梯度。这种通信对延迟敏感距离越短越好。第三类是专家并行和 MoE 通信。混合专家模型会把不同专家放在不同节点Token 需要路由到对应专家所在的 GPU 上通信模式更碎片化、更动态对网络带宽和网络拓扑的适应能力要求更高。这三种模式都指向同一个结论集群规模越大通信质量和网络带宽就越成为训练吞吐量的瓶颈。英伟达在系统设计里提出过“等效带宽”的概念。简单理解GPU 计算数据的速度和网络搬运数据的速度必须匹配。如果计算速度是每秒 1000 个 Token但网络搬运只能支撑每秒 500 个 Token那 GPU 有一半时间在空转。光互连接入后对集群的直接改变有三个单链路带宽更高。单根光纤可以承载 800G、1.6T而铜缆做到 800G 已经非常吃力。传输距离更长。光信噪比在几十米到几百米内几乎不衰减不限制机柜和机柜之间的距离。功耗更低。单位比特传输功耗更低对大规模集群的供电和散热压力是重大缓解。所以 Lumilens 拿到 700M 美元的核心逻辑不是“搞一个新产业链”而是“AI 算力集群的扩展速度和规模已经超出了传统铜缆互联的支撑上限”。6. 从成本模型看铜缆和光缆的真实差距这一节聊一个更实际的问题光互连这么强为什么没有在五年前彻底替代铜缆答案很简单成本。铜缆的物料成本远低于光模块这是它至今仍大量存在的原因。一个 400G DAC 可能只要几百到一千元人民币而一个 400G 光模块可能要到两三千元甚至更高。带宽需求没有达到某个临界点时算总账铜缆更划算。但是当集群规模变大总成本的计算方式会改变。第一功耗成本。假设一个 10 万卡集群每张卡对应的网络端口功耗相差 5 瓦10 万卡就是 500 千瓦的差距。这还没算制冷。按电费折算一年的差额就在千万元级别。第二故障和维护成本。铜缆在长距离高速率下更容易出现误码和链路不稳定排障时间、链路重新训练时间都会拉高集群的无效工作时间。光链路虽然也会故障但可监控性更强光纤链路诊断也更成熟。第三布线空间和端口密度。同样一个交换机面板光模块能做到 QSFP-DD、OSFP 这样的高密度封装端口数量更多布线更灵活。铜缆直径大、重量大机柜内走线空间很容易被占满。所以这不是“光一定优于铜”的绝对判断而是“在高速率、大规模、长距离场景下光的整体拥有成本TCO更低”。这正是 700M 美元融资背后的成本计算模型。7. 开发者如何评估光互连带来的集群变化前面讲了产业逻辑和技术概念这一节落到实操分三个角色来聊。如果你是算法工程师或大模型训练工程师最直接的感受是训练稳定性和吞吐量变化。光互连带宽更高、误码率更低AllReduce 时间会更短训练迭代时间会更稳定。你应该关注的是监控指标里是否出现网络等待、链路重传、AllReduce 耗时波动。如果你是网络或系统运维工程师你需要关注的是光模块的数字化诊断监控DDM信息包括光功率、温度、电压、偏置电流。光链路比铜缆多出光功率这个核心监控维度。链路劣化通常先表现为光功率下降而不是突然中断。提前预警比事后排查更能保证集群稳定。如果你是平台研发工程师你可能要关注调度器是否感知网络拓扑。大模型训练的最佳实践是把频繁通信的 Worker 调度到同一个 ToR 交换机下减少跨交换机流量。光互连虽然提高了带宽但跨交换机通信的延迟仍然高于同交换机内通信。拓扑感知调度依然重要。8. 光互连集群的带宽需求估算示例为了更直观地理解光互连的驱动力这里用一个最小估算脚本演示一个训练集群到底需要多大的网络带宽。假设使用 1000 张 H 系列 GPU 训练一个大模型每张卡的模型并行度、每轮需要传输的梯度数据量设为变量。这里不执着于具体数值重点展示估算思路。# 文件路径estimate_bandwidth.py # 功能粗略估算大模型训练集群的总线带宽需求 def estimate_training_bandwidth( gpu_count: int, bytes_per_gpu_per_step: float, sync_seconds: float, utilization: float 0.8, ) - float: 估算给定 GPU 数量和同步时间内所需的总互联带宽。 参数说明 - gpu_count: GPU 卡数 - bytes_per_gpu_per_step: 每张卡每个训练步骤平均需要发送的字节数单位 Byte - sync_seconds: 期望的梯度同步耗时上限单位 秒 - utilization: 网络可用利用率一般取 0.7-0.9 total_bytes gpu_count * bytes_per_gpu_per_step bandwidth_bps total_bytes / sync_seconds / utilization bandwidth_gbps bandwidth_bps / 1e9 return bandwidth_gbps if __name__ __main__: # 示例1000 卡每卡每步同步 1GB 梯度希望 5 秒内完成同步 gbps estimate_training_bandwidth( gpu_count1000, bytes_per_gpu_per_step1 * 1024 * 1024 * 1024, sync_seconds5.0, utilization0.8, ) print(f估算所需总互联带宽: {gbps:.0f} Gbps) print(f折合 800G 光模块链路数: {gbps / 800:.1f} 条)运行方式python estimate_bandwidth.py这个模型的结论是千卡集群已经需要数百 Gbps 到 Tbps 级别的互连带宽这远超传统铜缆在几米以上的承载能力。所以光互连不是“锦上添花”而是规模扩展的必选项。9. 光链路健康检查的常用命令与监控思路光模块的运维和铜缆有一个明显差异你可以直接读到模块内部的光功率数值判断链路质量是否在安全范围内。这里给出一个通用的健康检查思路不绑定具体厂商。以 Linux 环境下使用 ethtool 查询光模块 DDM 信息为例# 查看所有网络接口 ip link show # 查看指定接口的链路状态 ethtool eth0 # 查询光模块 DDM 信息光功率、温度、电压、偏置电流 ethtool -m eth0ethtool -m输出中需要重点关注几个字段Laser output power发送光功率。如果低于阈值下限可能是模块发射端老化。Receiver signal average optical power接收光功率。如果过低可能是光纤衰减过大、连接器污染或链路距离超标。Module temperature模块温度。光模块对高温敏感超过工作温度范围会导致误码率上升。光功率不是“越低越省电”而是必须落在厂商规定的范围内。过高会导致光接收器饱和过低会导致信号无法正确恢复。日常运维中如果发现误码率上升第一步不是换模块而是先用仪器检测光纤端面是否被污染、光功率是否漂移。下面是采集多个端口光功率并报警的示例脚本这里使用ethtool作为演示工具#!/bin/bash # 文件路径check_optics.sh # 功能检查多个网口的光模块接收功率输出低于阈值的端口 THRESHOLD_DBM-12 for intf in eth0 eth1 eth2 eth3; do rx_power$(ethtool -m $intf 2/dev/null | grep Receiver signal average optical power | awk -F : {print $2} | awk {print $1}) if [ -z $rx_power ]; then echo $intf: 无法获取光功率信息 continue fi echo $intf: RX power ${rx_power} dBm # 使用 awk 做浮点数比较 awk -v intf$intf -v p$rx_power -v t$THRESHOLD_DBM \ BEGIN { if (p t) print intf : 接收光功率低于阈值请检查光纤链路 } done运行方式chmod x check_optics.sh ./check_optics.sh这里的-12 dBm只是一个示例阈值真实环境中必须参考你的光模块规格书。不同速率、不同距离的光模块接收灵敏度和告警阈值差别很大。10. 生产环境接入光互连时的调度配置示例光互连改造完成后集群软件层也需要做配合。一个典型工作是让调度器感知网络拓扑尽量把通信量大的任务放到同一个交换域内。这里以一个简化的调度策略配置文件为例展示拓扑感知调度的配置思路。实际场景中具体字段和参数以你的调度系统为准。# 文件路径topology-aware-scheduling.yaml # 功能示意一个感知网络拓扑的任务调度配置 apiVersion: scheduling.example.io/v1 kind: TopologyAwarePolicy metadata: name: gpu-training-policy spec: # 允许的跨交换机通信比例。比例越低调度器越倾向于把任务放到同一交换域内。 maxCrossSwitchTrafficRatio: 0.15 # 训练任务关键通信模式 preferredCommunicationPattern: allreduce # 链路质量筛选调度 Worker 时排除光功率接近告警阈值的节点 linkHealthFilter: enabled: true metric: rx_power_dbm minThreshold: -12 # 亲和规则优先将同一任务的 Worker 调度到同一机柜 affinity: sameRackPreferred: true sameTorSwitchPreferred: true # 拓扑感知缩减光互连故障时优先缩减跨交换机副本 failureHandling: shrinkCrossSwitchReplicasFirst: true这个文件的关键在于三点限制跨交换机流量比例避免光链路成为热点。过滤健康状态差的节点减少训练中途的链路故障。故障时优先缩减跨交换机副本保留机柜内的高带宽低延迟链路。在实际生产环境这类配置通常要和集群管理平台、任务编排系统联动。光互连只是提供了更宽的管道真正让管道高效运转的仍然是软件层的调度、监控和容错。11. 常见误区与问题排查误区一光互连就等于“距离无限远”光模块按传输距离分成 SR短距、DR/FR/LR中长距等不同规格。数据中心内部用的 SR 和 DR 模块传输距离通常只有 100 米到 500 米超过距离同样会出现信号衰减。不要因为看到“光”字就以为可以跨城传输。误区二光模块耗电一定比铜缆低在短距离3 米以内、低速率的场景下铜缆仍然更省电。光模块的功耗优势主要体现在 800G 及以上速率、几十米距离的场景。光互连是“在特定范围内更优”不是“全场景更优”。误区三光模块故障就是模块本身坏了实际运维中光功率异常往往不是模块损坏而是光纤端面污染、连接器松动、弯曲半径过小、跳线衰减过大。排查链路故障时先用光功率计测试再检查光纤最后才考虑更换模块。常见问题排查表问题现象可能原因排查方式解决方案链路频繁 down光功率低于接收灵敏度查看 DDM 接收光功率阈值清洁光纤端面或更换跳线误码率上升激光器偏置电流异常检查模块温度与偏置电流历史改善散热或更换模块光模块温度过高机柜风道设计不合理检查气流方向和相邻模块温度调整风扇策略或增加散热训练 AllReduce 时间波动大跨交换机链路拥塞查看网络吞吐和光端口丢包统计调整拓扑感知调度降低跨交换机流量12. 对开发者的实际建议光互连的趋势很明确但这篇文章最后想说的是不必急着追新硬件先把你知道的链路评估方法用起来。第一步看你的训练脚本里是否有网络等待。用nvidia-smi查看 GPU 利用率如果利用率持续低于 90%并且多个进程的通信阶段占比很高网络就是瓶颈。# 每隔 1 秒刷新一次 GPU 利用率和显存使用 watch -n 1 nvidia-smi第二步看网络是否存在重传和丢包。光模块和交换机端口都会上报 CRC 错误、丢包计数。如果发现端口错误在持续增长链路健康状态已经亮红灯。第三步评估集群规模到底在什么速率下需要换光。用前面给的带宽估算脚本带入自己集群的 GPU 数量、模型大小、同步时间目标算完之后再决定是继续优化拓扑还是升级光互连设备。13. 这轮融资真正值得关注的技术信号最后做一个技术信号层面的总结。Lumilens 拿到 700M 美元对这个行业的真正影响有两个。第一资本开始认可硅光互连作为 AI 基础设施的关键组件。过去硅光更多被当作“未来技术”在讨论现在它已经进入“必须重资产投入、必须规模化量产”的阶段。数据中心光互连不再是一个配套产业而是决定集群规模上限的核心产业。第二光互连的竞争从“光模块厂商之间的竞争”扩展到“光模块厂商、交换芯片厂商、GPU 厂商、云厂商共同参与的生态竞争”。不同公司从不同角度切入同一个问题如何在十万卡甚至百万卡集群里实现极低功耗、极高密度、极高可靠性的数据互联。对于普通开发者这轮融资的启示是未来的大模型训练、推理集群网络会越来越像“光网络”而不是“电网络”。这会导致岗位技能随之变化——懂光模块运维、懂网络拓扑、懂带宽成本模型的人会比只懂单一环节的人更有竞争优势。这就是接下来值得投入的方向。