1. 从DSP到NPOAI集群互连正在经历一场“去掉重包袱”的变革先说说背景。这几年做AI集群网络的朋友应该都有同感GPU/TPU算力翻倍速度已经远超光模块的演进节奏而卡间互联、集群scale-out的带宽密度需求逼得服务器和交换机厂商喘不过气。过去十年光纤互连的主流方案一直是可插拔光模块DSP这几乎成了光通信领域“理所当然”的路径。就在2024年之后风向变了越来越多头部云厂商和AI算力玩家开始认真评估甚至部署NPONear-Package Optics近封装光学而讨论最多的一个话题就是“DSP是不是要被干掉了”这篇博文想聊的就是这件事。它不是某个产品发布会上的PPT概念而是真实影响AI服务器内部互连架构、光引擎设计、交换芯片封装、散热方案和运维模型的一次技术重构。我打算从自己实际接触过的互连仿真、光模块测试和AIDCAI数据中心组网经验出发把“DSP为什么被压垮”“NPO到底怎么重构互连”“落地要注意哪些坑”这几个问题拆开讲清楚。适合谁看做AI基础设施的架构师、光模块/光引擎公司的人、云计算网络规划的同学以及想搞明白下一代AI服务器互连为什么“不插光模块了”的硬件工程师。这篇文章尽量做到不看原厂白皮书也能把链路逻辑捋顺。理解这个转变首先要放下一个执念光模块不是越能插拔越好DSP也不是永远必要的。当互连距离足够短、通道足够多时让光器件靠到交换芯片旁边去掉一颗颗高功耗DSP反而更划算。NPO干的就是这一件事。下面我把这件事的前因后果、技术细节和实操要点一层层拆开。2. AI服务器互连的容量焦虑DSP为什么成了“过街老鼠”2.1 传统可插拔光模块方案不再够用先回顾一下经典方案。过去八年从100G到400G再到800G数据中心机架顶TOR交换机和GPU服务器之间的链路都是前面板插光模块QSFP-DD、OSFP这类可插拔封装模块里集成一颗PAM4 DSP负责把主机侧NRZ信号转成PAM4并对光纤色散、链路损耗做补偿。这个方案有几个深层次代价在AI时代被放大了。第一是功率密度爆炸。一颗800G OSFP模块的典型功耗在14到18瓦其中DSP功耗占了大约40%到50%也就是6到9瓦。一个支持32个800G端口的交换机光模块DSP本身的功耗就在200瓦以上快赶上一颗TOPS级的交换芯片了。如果我们考虑一个包含2万张GPU的集群按每个GPU配2个800G端口计算光是连接AlltoAll网络的端口光模块DSP功耗就可能接近100千瓦这还没算模块整体的其它功耗。第二是前面板空间和信号完整性无法兼顾。800G端口需要8个100G或4个200G的电气通道而这些信号要从交换芯片封装引脚跑到PCB前面板连接器再穿过模块金手指进入DSP。这段PCB走线长度通常在10到20厘米而112G/laneGbps每通道甚至224G/lane的串行速率下PCB过孔、连接器、焊盘都会让信号严重劣化必须有重定时器做均衡。第三是散热和后向维护的复杂度。可插拔笼子前面板的风流设计往往要阻挡或者绕过光模块模块散热只靠小面积散热器和系统风压导致热仿真做起来极其痛苦稍有功率变化模块就容易顶到85度上限。在AI集群里端口数量、单端口速率、链路总带宽这三件事同时增长老方案就撑不住了。2022年前后做800G集群还会纠结“前置光模块会不会被PIC光子集成电路替代”实际上到了2024到2025年走向已经非常明确把光学引擎挪到交换芯片封装基板附近这就是NPO的中文直译——近封装光学。2.2 DSP“去留之争”的真实原因到底是功能过剩还是功耗过剩很多人一听到NPO“干掉DSP”第一反应是没有DSP怎么做信号均衡其实问题在于PAM4 DSP在短距AI机架拓扑里属于高射炮打蚊子。在同一个机柜或相邻机柜之间光纤长度通常不超过1到3米甚至很多是铜缆都能覆盖的尺度。这种距离下光纤色散和功率预算的挑战很低真正的短板变成了PCB上的电信号完整性。可插拔模块之所以塞DSP一部分原因是它需要补偿主机侧那段十几厘米PCB带来的损耗。讽刺的是这段PCB损耗恰恰是“可插拔封装”自身制造的麻烦——如果直接把光引擎装在靠近交换芯片有机基板或substrate边缘这段寄生的PCB损耗根本不存在。NPO的思路就是在物理距离上“去马赛克”光引擎做的足够薄直接贴在有机基板外围从交换芯片fan-out出来的高速信号走不超过几毫米的封装走线就进入光芯片调制器。此时系统里不再需要DSP做重定时补偿因为损耗和反射被压到了最低水平。对应到离散数学概念里就是减少了不必要的均衡环节。所以与其说是“DSP功能被干掉了”不如说是“导致DSP成为必需品的链路模型被改掉了”。这个区别很重要——NPO不是不做信号处理而是把信号处理简化为低功耗线性驱动LPOLinear-drive Pluggable Optics或完全线性的方式。一旦没有重定时器功耗降低、时延降低、成本降低但代价是必须保证整个shipping链路从serdes到TIA到激光器直到对端serdes的损伤足够小。2.3 直驱架构在AI服务器中的实际定位在NPO语境下“linear drive”已经不是一个新鲜词。过去两年讨论的LPO线性直驱可插拔光模块就是把DSP拿掉用交换芯片的SerDes直接驱动光模块内的驱动器。而NPO在物理形态上更彻底光引擎直接进封装距离从十几厘米缩小到几毫米。AI服务器内部互连最常见的是Star拓扑一个交换芯片外接多个GPU/加速卡或者GPU-NPU通过PCIe/CXL/私有协议连到TOR。距离短、端口多、链路数量大——这是NPO最匹配的场景。它的优势有三个功耗单光引擎整体功耗比同带宽可插拔模块低40%至60%没有DSP就没有它的6到9瓦。时延去掉DSP的编解码和均衡延迟光链路端到端时延可以降低几十纳秒到百纳秒。当然这个量级和大帧传输时延比不突出但在NCCLNVIDIA Collective Communications Library这类集合通信里几百纳秒对allreduce的尾部延迟依然有意义。密度NPO没有笼子和连接器机箱前面板不再被网口挤满光缆可以走机箱内部或背板端口密度提升30%以上。NPO并非“未来概念”但确实也不是一个能直接套用的免费午餐。它对交换芯片封装、光源管理、现场可维护性提出了完全不同的要求下面一节重点展开这部分。3. NPO近封装光学的技术拆解链路怎么建、芯片怎么摆、信号怎么保3.1 从交换芯片到光引擎的物理结构先做个NPO系统的分层解构避免后面越聊越抽象。一个NPO交换系统从上到下包括交换芯片ASIC做以太网或者InfiniBand报文转发内部集成几百个SerDes通道。早期SerDes是25.6Tbps芯片配单体现在的51.2T/102.4T芯片SerDes通道上限已经到112G甚至224G。有机基板Organic Substrate芯片下方那块大面积基板用来把ASIC的引脚fan-out到BGA封装边缘。光引擎Optical Engine一种小的光电混合封装单元内部有微激光器、硅光调制器、光电探测器PD、TIA等。NPO就是把多个这种小光引擎沿基板边缘摆放两者之间走线距离极短。外部激光器/光源硅光调制器往往不集成激光器用一个外置光源组件External Laser Source, ELS通过光纤把连续光注入硅光芯片。光纤连接管理光引擎出来的光纤通过一个集成线缆连接器跳到外部MPO/MDC接头或直接布到背板。NPO的关键结构指标就是“从ASIC die边缘到光引擎driver之间的电信号距离”。理想情况下这段长度小于5毫米总插入损耗压低到几个dB以内。为什么要这么短看一组数字当SerDes速率是112G/lane时PCB上普通走线的损耗大约在0.5~1dB/inch而到了224G/lane损耗几乎翻倍。如果这一段芯片外走线超过2.5厘米那么抖动预算会被吃掉一大半——这就是可插拔模块里DSP存在的最根本理由。NPO把走线缩短到毫米级之后不需要重定时均衡链路也能在一个合理的BER误码率比如1e-6量级上工作剩下来的修正由交换芯片的SerDes内部的CTLE/DFE完成。3.2 激光器外置NPO不可回避的“第二根光纤”之前我在做一个PIC设计选型的时候反复纠结到底用CW激光器集成还是外置光源NPO在中长距离和AI集群高密度场景几乎都选择外置激光器ELS原因很现实硅光调制器本身是损耗器件需要在片外提供连续光源。激光器寿命和温度稳定性差对热敏感而交换芯片顶部和基板边缘恰恰是散热死角。故障隔离外置光源坏了可以直接拔掉换一个不需要动整个交换单元。这就引入了NPO系统的特殊点每个光引擎不仅需要信号光纤把调制后的光送出去还要一根“泵浦光纤”把外部激光器的连续光引入。所以NPO整机部署时光缆管理复杂度反而比可插拔模块高出一个量级。你想象一下一台标准机箱正面密密麻麻的方向上同时出现了信号光纤和LPO模式的激光供给光纤这对跳线、光纤弯曲半径、极性管理都提出了新要求。我第一次进NPO实验室时光看光纤走线图就觉得头大——所有的系统设计必须在一开始就把这部分plan进去否则后期测试时根本分不清哪根是信号光纤哪根是光源光纤。3.3 通道速率演进112G/lane到224G/lane是否影响NPO判断现在业界正处于从112G/lane SerDes向224G/lane SerDes切换的窗口期。112G/lane时代800G光模块通常直接使用8x100G到224G/lane1.6T光模块用8x200G信号电接口速率为每通道224G。这里有一个很关键的技术背景电信号速率越高可插拔DSP方案的补偿压力越大。DSP本身有功耗墙壁它的复杂度随波特率非线性上升而PAM4信号波特率越高对ADC采样率和DSP均衡器的抽头数要求也越高这使得DSP功耗从早期100G模块的约2到3瓦一路飙升到800G的7瓦以上。如果1.6T模块继续沿用DSP方案单模块的DSP功耗会逼近12到15瓦——这几乎无法在普通风冷前端口实现散热。反过来NPO在没有DSP的纯线性链路上只要光引擎的调制带宽能跟上224G功耗增长相对温和。这就是为什么“NPO干掉DSP”在224G时代成了不可逆趋势。谁先落地224G/lane的NPO引擎谁就能拿到下一代超大规模AI集群里更大的话语权。3.4 与CPO共封装光学的路线之争讲到NPO就绕不开CPO。很多科普把两者混为一谈但搞硬件的一定要分清。CPO把光引擎直接利用2.5D封装放到和交换芯片同一个中介层interposer或重布线层上光引擎到ASIC之间通过硅中介层的微凸点连接。这是最彻底的“zero-distance”光子集成信号损耗最小但挑战也巨大良率牵制、测试难题、维护黑洞——光引擎任何一个点失效都要rework整个芯片封装这在量产服务器里是一场灾难。NPO是一种折中不用高成本的中介层共封装而是光引擎放在基板边缘距离虽然比CPO长一点但仍在近封装范围内典型几毫米封装工艺成熟度接近传统2D基板光引擎可替换性远好于CPO。用一个不太严谨但好理解的比喻CPO像是把发动机焊死在车架上理论效率最大化但维修换整车NPO像是把发动机做成快拆模块装在车身最贴心的发动机舱位置改造量小、拆装相对容易、收益覆盖90%的CPO红利。从目前主流云厂商和交换芯片公司放出的产品看NPO是比CPO更快“上车”的现实路线。CPO更多被用在“延迟极度敏感端口密度极高”的超高端场景。AI服务器互连这类高容错、高维护率、循环迭代快的场景NPO反而是最理性选择。4. 落地NPO互连的实操要点从交换板到系统联调的完整路径4.1 交换芯片封装设计角度看NPO如何落地如果你在芯片封装团队想让NPO落地最早的一步往往不是“选光引擎”而是先定义SerDes通道的边界条件。你需要和光引擎厂商明确以下参数SerDes发射端幅度范围和均衡能力比如是否支持2.5pF的封装负载、是否能在TX侧做基于DFE的3抽头驱动。封装走线模型从ASIC bump到基板边缘光引擎driver的走线长度、参考层、过孔数目。目标通道损耗预算例如不超过3dB28GHz56Gbaud下Nyquist频率。光引擎的驱动带宽和输入灵敏度能否在无DSP情况下保证1e-6以下BER。这些参数相互耦合必须用联合仿真验证。做基板layout时一个常见错误是把交换芯片放在基板正中心四周放满了退耦电容和供电网络导致边缘几乎没有位置容纳光引擎的足迹。我在项目里见过的一个可行做法是基板设计时提前预留“光学环”——沿着基板四周留一圈无源区和连接焊盘把信号从ASIC边缘用微带或带状线引过来。这种设计牺牲一部分基板布线面积但能极大降低后续光引擎与DSP间信号干扰。4.2 光引擎选型三种主流方案的取舍做系统级集成光引擎选型真的能决定项目生死。当前主流技术路径大致分三类硅光方案Silicon Photonics调制器和探测器都做在硅片上能沿用CMOS工艺大规模集成度高。缺点是激光器要做成外置ELS耦合工艺复杂。薄膜铌酸锂方案TFLN带宽极高线性度好适合224G甚至更高速率的调制但产业链成熟度低成本和产能都是问题。InP磷化铟方案调制器、激光器、探测器都可以集成在一颗芯片上但大规模工艺成本高良率挑战大。在AI服务器NPO场景中硅光外置激光器方案当前综合性价比最高也最成熟。实际选择时除了看光眼图和误码率曲线还建议重点比较“耦合容差”。同一款光引擎设计时把光纤耦合容差从±1.5um放宽到±2.5um耦合良率可能提升好几倍。良率提升对整机BOM成本的影响比你想象更大。4.3 链路设计中最容易被忽略的“TIA到SerDes”匹配把DSP拿掉之后光接收侧那一路TIA和SerDes之间的界面会成为新的性能瓶颈。过去DSP内部自带的AGC自动增益控制和均衡技术可以在很大范围内弥补前端线性度不足去掉它之后TIA输出摆幅、共模电压、单端/差分阻抗、AC耦合电容取值都必须做得非常干净。这里有个实操经验如果你使用线性直驱方案接收侧的AC耦合电容建议取值不要太小。过小的耦合电容会在低频处引入额外的高通极点导致PAM4长串0/1时出现基线漂移。实际调试中用0.1uF的0402电容往往不够至少需要用0.47uF或1uF才能保证在KP4-FEC的突发错误场景下依然稳定。还有一个容易被忽视的是TIA和SerDes之间的“过驱保护”。没有DSP削波之后如果前端光纤链路瞬态功率过大TIA输出会饱和导致SerDes输入损坏。一般需要在TIA输出级和SerDes间加一个简单的限幅网络不能只靠SerDes内部的钳位二极管。4.4 调试与测试从电磁仿真到链路误码率验证实操阶段联调流程通常分为四个步骤单板电链路验证先用误码仪或交换芯片自带的PRBS伪随机码流测试口直接分析SerDes到光引擎driver这一段电信号眼图。光引擎单独环回把发射端和接收端用一根短光纤或者衰减片连接起来测TIA输出端信号质量并统计BER。整条NPO光链路测试两端都切到实际交换芯片SerDes跑以太网或者InfiniBand流量对比开启FEC和不开启FEC的两种模式。压力与温度测试把光引擎温度从25度升到70度持续跑mixed traffic观察BER随时间漂移。在第3步尤其注意一个细节——NPO链路没有了DSP的时钟恢复发端和收端完全依赖交换芯片内的同一个时钟源或者两个独立时钟源。如果两个节点不是同步时钟那需要处理频偏问题。AI服务器内部短距互连一般可以选择同步模式但如果是跨机柜的NPO到NPO互连两组交换芯片可能锁定不同参考时钟这时系统设计必须在协议层或者物理层留好异步容差方案。我们实测下来如果频率偏移超过±200ppm而不做补偿KP4-FEC会频繁触发纠错业务层面表现成偶发的链路降速。4.5 光源冗余与可靠性设计NPO系统里一旦某个ELS失效覆盖的多个光引擎会同时失去光源导致系统出现“一个点坏全盘崩”的故障模式。因此实际部署时必须考虑光源冗余策略。推荐做法是“11备份”每组光引擎预留一个冗余光源输入端口主用ELS通过1x2光开关或50∶50分光器连接两个ELS。平时两个都亮故障时靠自动光功率检测切换。光开关插损和分光损耗是可以接受的代价换来的是一台NPO设备可靠性的大幅提升。4.6 散热设计与现场运维差异NPO设备与可插拔光模块的散热差异巨大却极少被讲透可插拔模块的散热是由前面板进风直接吹过笼子模组本身自带散热鳍片实现的而NPO光引擎紧贴基板边缘它几乎只能依赖热传导把热量传给系统散热器。因此板级设计必须要在光引擎背面留好导热垫的接触位置。NPO光引擎贴近Switch ASIC两个热源叠加需要一种更加精细化的冷却方案比如冷板式液冷至少也要优化导热气流路径。凡是想靠着传统风冷混过NPO项目的人大概率会遇到高温下误码率飙升或者光功率输出衰减的问题。行业实践里AI服务器互连的NPO方案大多数都直接搭配液冷——这也和AI服务器的整体趋势一致。运维侧NPO的精髓是光引擎可现场更换。设计时尽量采用板载连接器和标准光纤接头避免光引擎直接焊死在基板上。从我们的实际测试来看设计成“可插拔光引擎NPO中板”的结构维护MTTR能从小时级别压缩到分钟级别。5. 常见性能瓶颈、故障排查与工程避坑指南5.1 眼图明明很好为什么FEC纠错飙高这是我在好几个项目往复踩过的坑。眼图好、BER测试也正常但因为很多工程师只测“短时PRBS”没有考虑PAM4信号的“低频特性”在NPO线性链路中TIA的低频截止频率如果太高长串数据会因为基线漂移产生突发的猝发错误。KP4-FEC每秒纠错数量看起来不高一旦发生超限的连续错误帧业务就会降级。排查思路先把误码仪切成长PRBS比如PRBS31Q跑至少10分钟。再用示波器抓取下TIA输出端的低频包络看看有没有明显的基线漂移。最后检查AC耦合电容如果太小按照之前讲的加大至少一个数量级再对比。5.2 高温下面功耗没变但光功率下降激光器驱动电流和温度呈强相关。NPO如果用外置ELS一般ELS会内置TEC半导体制冷器控温。但如果TEC控温点设置过高往往你会发现TCASE机箱内部温度在75度时光功率下降超过2dB导致链路预算不足。遇到这类问题不要只加大激光器驱动电流——那会让失效率升高。应该去检查ELS的TEC温度设定看是否跟随系统环境温度合理漂移。很多ELS默认控温25度而NPO机箱边缘温度可能已经到45度甚至55度这时候TEC的制冷功耗会剧烈上升甚至来不及把激光器温度拉住。解决方案有两个方向选用支持高温控温点的激光器比如70度或者设计时抬高控制目标温度让TEC不用克服太高的环境温差减小制冷负担。5.3 链路插损没问题可就是时不时“误报LOS”NPO的光引擎靠近交换芯片会受到明显的电磁干扰EMI。这个问题在可插拔模块时代几乎不存在——模块在面板位置远离ASIC。光引擎内部的LOS检测电路对电压阈值非常敏感ASIC的高频开关噪声一旦耦合到光引擎的模拟供电就可能触发错误的信号丢失标志。解决方式在光引擎电源引脚加足够的去耦电容组合形成LC滤波。检查PCB参考层完整性——保证光引擎下方不能有孤岛铜所有信号走线必须有完整回流路径。软件上把LOS的判定阈值调高一些或增加debounce时间避免瞬时毛刺导致误报告警。5.4 表格式速查遇到问题先对号入座现象可能根因首选动作高温误码率飙升ELS控温点不合理/散热设计差抬高控温点、加大导热垫覆盖长时间满负载测试偶尔闪断低频基线漂移增大AC耦合电容光功率正常但BER偏高TIA/SerDes阻抗匹配异常实测S参数对比仿真模型模块无光输出ELS失效或光纤奇偶接反检查ELS状态并核对光纤极性特定lane持续高FECSerDes TX预设不合适尝试关闭/调整发送端预加重单光引擎损坏导致多个端口掉线光源共享设计缺陷实施11冗余供光方案5.5 关于供应链与标准化的提醒NPO近两年还在标准化的快速演进期。可以关注COBOConsortium for On-Board Optics在NPO模块外形上提出的规范以及OIF在外部激光源、光引擎电接口层面制定的实现协议。做整机的时候建议优先选择符合COBO写的早期定义或主流厂家主导的“去差异化方案”避免被锁死在专用接口/专用光纤管理器里。采购光引擎时最好同时锁定两到三个供应商并对不同方案光引擎的耦合光纤类型做一版通用设计——因为NPO的光引擎和交换基板绑定紧密后期换供应商的成本远比可插拔模块时代换模块高。6. 结语与个人体会分享一点实际做AI集群基建的体会。我们在评估NPO方案时一开始最担心的不是技术上做不做得成而是整条产业链的成熟度——尤其是光引擎良率、ELS可靠性和兼容性标准化。但经过几个月的POC概念验证实测最终结论是在800G向1.6T迭代的窗口期NPO在功耗、时延和系统集成密度上的优势已经把可插拔DSP方案甩开了一个身位。更准确地说DSP并没有被粗暴地“干掉”只是它在短距、高密度的AI服务器互连场景中让出了主角位置。DSP仍然大量存在于长距离传输模块、传统数据中心和电信设备中只要链路还有几十公里的距离要跑DSP就是不可替代的。NPO最打动我的还不是单一数字的功耗降低而是整机系统设计的思维反转以前我想方设法让光模块去适配交换芯片的电接口今天NPO让交换芯片的封装去适配光子学的物理规律。把光靠近电不给信号处理留那么多“中间商赚差价”这才是它真正的意义。未来如果技术进一步成熟光引擎会不会最终变成交换芯片封装的一部分就是另一个更大的话题了。最后分享一个压箱底的小技巧在整个系统方案定稿前哪怕你对光引擎所有参数都满意也强烈建议做一版“低温长时间老化”验证把样机在40度环境温度下连续跑72小时。NPO链路里很多接触性连接器和耦合点的问题都是在热胀冷缩最显著的阶段才暴露的。这时候发现隐患的成本远比量产晚期的故障召回低得多。