上个月在实验室调一台800G的AI训练交换机厂商FAE过来递了一块新背板说“这代我们不用DSP光模块了NPO光引擎直驱”。我第一反应是不信800G链路没有DSP做均衡和时钟恢复误码率能压得住结果他现场跑了一遍压测FEC前误码率稳在1e-5以内比旁边那套DSP可插拔方案还干净。从那天起我开始认真研究这项技术越看越觉得NPO近封装光学对AI服务器互连的冲击比很多人想象的更大。这篇文章不聊PPT上的概念就说说DSP到底在互连里干什么、NPO怎么把它“干掉的”以及我在方案选型、部署测试中实际遇到的经验和坑。1. DSP在AI服务器互连里到底在干嘛先弄清楚要被干掉的东西是什么1.1 一个800G端口里DSP的工作量要理解NPO为什么能取代DSP得先搞清楚DSP在光互连链路里的职责。一个传统可插拔光模块比如QSFP-DD或OSFP里面除了激光器、调制器、TIA和Driver之外一定会有一颗DSP芯片。这颗DSP做的事情可以拆成四件PAM4信号编译码400G/800G光模块用的不是普通NRZ而是PAM4电信号和光信号之间需要做编码转换。自适应均衡高速信号经过PCB走线、连接器、光器件之后波形会严重畸变DSP通过CTLE和DFE等算法把波形修回来。时钟数据恢复CDR把接收信号中的时钟重新提取出来让输出数据和系统SerDes的时钟保持同频同相。FEC编码DSP内部带了一套FEC通常是RS(544,514)负责把模块内部链路的误码率从10^-5量级压到10^-8以下。这几件事听起来都不难但放在112Gbps甚至224Gbps的SerDes速率下DSP的算力开销非常可观。以一颗800G OSFP模块为例DSP要并行处理多个通道的高速PAM4信号内部还要跑均衡抽头和FEC解码芯片面积和功耗都不可能小。实际上一颗7nm工艺的DSP功耗就在10W到15W之间几乎占了整个光模块功耗的一半还要多。真正让DSP显得“不可替代”的是它的健壮性。无论光路损耗多大、端面脏不脏、链路老化多少DSP都能通过自适应算法把误码率拉回来所以用DSP的方案链路预算非常好算工程上很难出问题。做互连设计的人都知道DSP就是一种“用功耗换省心”的方案。但AI服务器互连对功耗和时延极度敏感这种“省心”的代价现在越来越付不起了。1.2 DSP的三个硬伤功耗、时延和成本DSP带来最直观的问题是功耗。我们算一笔账假设一台AI训练服务器需要8个800G端口如果都用带DSP的可插拔光模块光模块功耗按18W估光模块部分就吃掉144W。如果这个规模放大到64个800G端口的接入交换机光模块总功耗接近1200W几乎是一台小型空调的功耗。这些功耗最终全变成机房的制冷压力AI集群的PUE数字就会被拖下去。第二个问题是时延。AI训练里的集合通信比如All-Reduce是逐跳累积的数据交互光模块DSP的收发时延虽然只有几纳秒到十几纳秒不同厂商5ns到20ns不等但在万卡集群的Scale-up域里跳数多、链路长纳秒级时延的差距会被放大成训练效率的差距。训练大模型时跑一轮迭代慢多少毫秒很多人不在意但千卡以上规模累计起来就很可观了。第三个问题是成本也是云厂商和运营商最敏感的。DSP芯片一颗成本几十美元一颗800G光模块里面有DSP、DSP供电电路、高精度时钟这些都要算进BOM里。AI集群的端口数量是百万级起的端口一多DSP带来的成本就是亿级美元。做硬件的人都明白一个方案只要能去掉一块几十美元的关键芯片整个供应链成本都会松一口气。1.3 “干掉DSP”不是黑科技是三条路线在同步推进说出“DSP被干掉”的时候先澄清一点行业里说的不是光模块这个形态消失而是把DSP从光链路里拿掉换一种更省的方式完成同样的事。目前主要有三条路线在并行LPOLinear-drive Pluggable Optics线性驱动可插拔光模块可插拔模块里不装DSP宿主SerDes直接通过线性Driver驱动光引擎接收端只用TIA不做重定时。NPONear-Package Optics近封装光学光引擎不放进可插拔模块而是摆到交换芯片或GPU的封装基板附近电信号缩短到几厘米级别链路简单到不需要DSP。CPOCo-Packaged Optics共封装光学更激进直接把光引擎和ASIC die放到同一个封装里用2.5D/3D互连短到几乎没有寄生效应。这三条路线里LPO最保守适合现有框式设备改一下电路板就能支持CPO最彻底但良率、可维修性、光源方案都还有一堆坑NPO则恰好卡在中间——它既有CPO那种低功耗低延迟的优势又不像CPO那样把光引擎和ASIC死死绑在一起是目前AI服务器互连里最容易落地、也最值得关注的方案。2. NPO近封装光学是什么把光引擎搬到ASIC门口2.1 NPO的结构和物理布局NPO的全称是Near-Package Optics翻译过来就是近封装光学。核心思想其实很简单让光引擎Optical Engine包含电光调制器、光电探测器、Driver、TIA以及必要的无源光波导尽量靠近主芯片缩短电信号在铜线上的传输距离。我评估的那套NPO背板结构可以这样理解一颗交换ASIC或者GPU它的封装基板比普通芯片大一圈基板旁边并排放着两个或多个光引擎每个光引擎负责一个或两个光通道对。光引擎和ASIC die之间通过基板上的高速走线相连走线长度一般只有几厘米损耗小到几乎可以忽略。光引擎的另一侧通过光纤阵列FAUFiber Array Unit把光信号引到前面板或连接器再接到外部光纤跳线。为了便于散热和器件寿命NPO方案里的激光光源一般放在光引擎外部甚至板卡外部通过ELSFPExternal Laser Source或者独立光源模块供光。这样布局最直接的好处是电信号根本不用穿越整块PCB也不用过各种背板连接器信号完整性从源头就非常优秀。传统可插拔方案里SerDes信号要跑20到40厘米的PCB走线还要经过连接器、解锁机构损耗很大NPO方案里段电链路被压缩到几厘米损耗可能只有前者的十分之一。没有了长铜线上的损耗、串扰和频率依赖衰减也就不需要DSP做大幅度的均衡补偿。2.2 NPO、LPO、CPO一张表看清差异我在给团队做内部培训的时候喜欢用一张表把这几种方案放在一起比较重点关注几个维度电信号链路长度、是否使用DSP、光引擎位置、可维护性、良率风险。维度可插拔DSPLPO可插拔NPOCPO电链路长度20-40cm20-40cm2-10cm2cmDSP有10-15W无无无光引擎位置模块内部模块内部封装基板上ASIC同封装可插拔更换支持支持可局部返修整机返修光引擎良率影响只影响模块只影响模块影响封装单颗影响整颗ASIC当前成熟度高中中低从这张表能看出来NPO最大的优势是“折中”。它占了CPO在功耗和信号完整性上的收益但没有CPO那种“光引擎坏了ASIC也报废”的风险。它比LPO多一个优势光引擎到ASIC的距离短到可以放松对SerDes驱动能力的要求。LPO虽然也去掉了DSP但模块里的光引擎离交换芯片还是有几十厘米对SerDes的driver摆幅、接收灵敏度和FEC编排都有更高要求工程实现并不比DSP方案简单。2.3 为什么AI服务器互连会先吃NPO红利NPO这个概念其实在电信和数通领域提了好几年真正大规模落地靠的却是AI服务器互连这个场景。原因是AI集群对带宽密度的需求太猛了单GPU卡已经开始遇到端口瓶颈。传统可插拔光模块占用了面板空间一个1U设备前面板能放的OSFP数量非常有限想给单卡跑800G甚至1.6T面板空间和散热空间都不够。AI服务器走的是Scale-up和Scale-out混合网络GPU与GPU之间需要比传统以太网更高密度、更低延迟的互连可插拔模块的物理形态慢慢成了限制因素。NPO把光引擎从面板挪到芯片旁边前面板只用接光纤跳线端口密度立刻就上去了。交换芯片或GPU封装上能放多少光引擎由基板面积决定不再依赖面板尺寸这是一个架构级的改变。另一个现实原因是AI网络的链路相对短。大部分AI集群内部的光纤长度在100米以内甚至很多就是机柜内跳线光链路总损耗很小。NPO去掉DSP之后靠着激光器功率和接收灵敏度的余量完全可以在短距离场景下达到规定的误码率。既然短距不需要DSP的大功率补偿能力DSP自然就可以提前“退休”。3. 从DSP可插拔迁移到NPO我实测的评估和选型路线3.1 链路预算审计算一笔账就知道能不能去掉DSP我接到NPO方案评估任务后第一件事不是跑demo而是老老实实把链路预算摊开算了一笔账。这是决定方案能不能去DSP的核心逻辑。以一条800G单模光纤链路为例链路预算可以这么估光引擎输出光功率设为P_out单位dBm接收灵敏度设为SdBm链路损耗包括光纤损耗每公里约0.35dB和连接器插损一个MPO连接器约0.5dB。如果光纤长度10米、有两对连接器那么链路损耗大约是0.35×0.011也就是1.1dB左右。这个损耗水平下光功率预算余量做到5dB以上没问题。再看电端NPO方案里SerDes到光引擎的电走线只有几厘米插损可能只有0.5dB到1dB而传统可插拔模块那条几十厘米的线路插损可能到10dB以上。电信号预算非常充沛SerDes不需要开太多的均衡抽头CDR的锁定也更轻松。把光功率预算和电信号预算两边一拉你会发现NPO完全能在没有DSP的情况下保证信号眼图张开。反过来如果把链路距离拉到2公里中间又有多个扇出连接器没有DSP的均衡能力就会很吃力。所以我的判断标准很简单300米以内、连接器数量小于等于4个、链路总损耗小于3dBNPO去掉DSP完全可行超过这个范围还是规规矩矩用DSP方案或者上更强FEC吧。3.2 NPO端口选型光引擎、光源和连接器都要单独定评估NPO时容易忽略的一点是NPO不是一个完整模块而是一个由很多子部件拼起来的系统。我梳理之后发现实际选型要定四样东西光引擎本身、激光光源、光纤阵列FAU和外部连接器。光引擎Optical Engine核心指标是调制格式PAM4、通道数、功耗和灵敏度。目前主流是硅光方案硅光的优势是可以用CMOS工艺做高密度集成缺点是插损偏大也有人用EML加TIA的方案光性能好但功耗稍高。选型时还要关注光引擎的工作温度范围是否能和ASIC封装的热设计匹配。光源Laser很多NPO光引擎里并不会直接放激光器因为激光器的寿命和热敏感度会影响整个封装件的可靠性。一般使用外置CW光源通过ELSFP或独立光源模块供光。选型要看光源的波长、线宽、功率稳定性以及是否支持冗余比如11保护。FAUFiber Array Unit这是NPO封装里最容易被忽视也最容易出问题的部件。光纤阵列需要把几十根单模光纤精确对准光引擎上的波导光口对准偏差一两个微米就可能带来0.5dB的损耗差异。选FAU时一定要看端面研磨质量和通道间一致性。外部连接器NPO光引擎出来一般走到前面板的SN-MT或MPO-16连接器。这个连接器需要支持现场插拔同时又不能给内部光纤路径引入太大的弯曲应力机械设计上要特别注意。此外还要和ASIC封装的散热设计配套。光引擎是发热体它贴在ASIC封装周围和ASIC天然抢散热资源。选型时最好让光引擎厂商提供结温-寿命曲线不能只看标称功耗就下单。3.3 落地测试别被demo骗了要测FEC余量和误码率分布NPO方案的demo通常都很漂亮眼图明显张开误码率低得惊人。但我自己的经验是如果不做压力测试和功率扫描很容易被demo骗过去。我当时的测试流程分四步。第一步测静态误码率用BERT接到交换芯片SerDes上跑24小时统计FEC前误码率和FEC后无误码率。第二步做功率扫描用可调光衰减器VOA在光路上人为加损耗逐步加大衰减观察误码率什么时候开始劣化。第三步做温度循环把整块板卡放到温箱里从25度升到70度再降回来看误码率是否漂移。第四步做抖动注入在SerDes参考时钟上额外注入抖动验证系统的容差。实际测试里我发现NPO方案最需要注意的一个指标是误码率分布的“长尾”。DSP方案由于有均衡和重定时误码率事件往往比较均匀NPO方案去掉DSP之后偶尔会有突发性误码如果突发长度超过FEC纠错能力就会造成丢包。所以不能只看平均误码率一定要统计误码的突发性比如记录超过一定bit长度的连续误码事件用来评估FEC余量是否充足。测试还有一个容易踩的坑NPO光引擎的光纤阵列和外部光纤之间的连接器在测试时会受到弯曲半径的影响。光纤一旦被弯到半径小于10毫米插损就会突变很容易被误判为方案本身的问题。所以我测链路预算之前会先做一次插损确认确保外部光纤的布线半径合规。3.4 成本和功耗测算NPO到底省了什么最后帮读者算一笔经济账。以64个800G端口的接入交换机为例传统DSP可插拔方案里64个光模块按280美元一个估算模块成本就是1.7万美元以上而且每模块里边的DSP占了成本的30%到40%。NPO方案的光引擎数量与端口数等价但光引擎因为集成度和工艺成熟度还没到量产峰值单颗成本目前并不会低太多。真正省钱的地方是省掉了模块外壳、连接器、DSP、外部时钟等外围物料长期看量起来以后单端口成本有机会降20%到30%。功耗方面会更明显。DSP光模块每个18W64个是1152WNPO的64个端口只算光引擎和光源大概能做到6到8W一个端口总功耗降到450W左右。64端口算下来每年省下的电费非常可观在大型数据中心里这是几百万美元的运营成本差距。所以NPO的“性价比”不能只看采购单要从TCO总拥有成本整体角度去算。4. 部署NPO方案时踩过的坑和排查技巧4.1 光纤阵列对准问题误码率高往往是“微米级”的锅NPO部署第一个容易翻车的是光纤阵列FAU与光引擎的耦合。FAU通常是用UV胶和机械定位固定到光引擎的耦合区如果胶水量控制不好或者固化时出现微小位移耦合效率就会下降。耦合损耗增加0.5dB对DSP方案可能无所谓但对没有DSP的NPO链路可能就是“能收敛”和“不能收敛”的区别。排查时不要只换光引擎先把FAU和光引擎端面的插损测出来用光功率计分别测每个通道的光功率差距大于0.7dB就要检查耦合。另外一个常见的坑是FAU端面脏污。NPO虽然在封装内部但FAU与外部连接器相接的位置是暴露的。每次拔插外部跳线如果端面没有清洁干净灰尘就会被推进FAU的端面。去掉DSP之后模块没有内置的重定时器去“兜底”光纤端面脏一点直接反映到误码率上。所以NPO设备的维护规范里一定要加入“插拔前必清端面”的硬性要求。4.2 NPO封装内部的热点问题芯片不热光引擎热NPO把光引擎贴到基板上之后整个热设计会发生很大的变化。ASIC本身功耗很高有风冷或液冷先把核心热量带走但光引擎的位置往往在芯片边缘是一个容易被热设计忽略的死角。很多光引擎的最大结温是85度或90度一旦超过激光器波长漂移、探测器灵敏度下降光链路的误码率就会明显恶化。我在温箱测试中发现如果把散热器只压在ASIC表面NPO光引擎区域温度能比ASIC核心温度高上10度以上。后来通过有限元热仿真定位到问题光引擎和基板之间的导热垫厚度不均热阻偏大。解决办法是在光引擎顶部加一块均热板通过热管引到主散热器同时调整导热垫的压缩量。AI芯片设计人员在做NPO版本时一定要给光引擎区域预留热管或均热板的位置这属于必要设计不是可选优化。4.3 运维模式变了从“拔模块”到“动手术”传统可插拔光模块坏了一个运维直接把模块拔下来换新的全程不超过两分钟。NPO光引擎焊在基板上坏了就需要把整块板卡下线、回到维修车间用热风枪或者回流焊把光引擎拆下来重装。这种运维模式的变化需要提前规划备件策略和服务渠道。另一个运维层面的变化是光源与光引擎分离。外置光源ELSFP是可插拔的但光引擎不是。如果链路光功率偏低首先要判断是光源的问题还是光引擎的问题。最简单的办法是看所有端口是否同时衰减所有端口同时衰减大概率指向光源只有单个端口衰减大概率指向FAU耦合或者光引擎通道故障。我建议在NPO系统的监控界面里把光源功率和每个通道的接收光功率都做成可读参数否则出故障时连定位都费劲。4.4 NPO系统常见问题速查表把我在实际项目中遇到过的问题整理成一张速查表供做运维和测试的朋友参考现象可能原因排查手段应对建议单通道误码率高FAU耦合偏移、通道光功率低用光功率计测各通道光功率分布返修FAU重新耦合全端口误码率上升外置光源老化、功率抖动查ELSFP状态和输出光功率更换光源模块温度升高后误码率劣化光引擎结温超限查看NTC温度传感器跑温箱循环增加均热板、优化风道突发误码导致丢包FEC余量不足、抖动过大统计长突发误码事件调SerDes均衡参数、增强系统FEC外部跳线弯折后误码光纤弯曲半径过小检查布线路径使用理线架限制弯曲半径拔插连接器后误码FAU端面污染用端面检查仪观察用专用清洁笔清洁端面我在把NPO方案从实验室测试推向实际机房的过程中最大感受是这项技术不是简单的“把DSP拿掉”而是一次系统层面的重构。去掉DSP之后链路功耗和时延确实下来了但系统对光学器件质量、热管理、运维规范的要求变得更高整个团队的技术栈也需要跟着调整。如果你正准备在AI服务器互连里评估或采用NPO我给的建议很简单先在实验室做链路预算测算接着用温度循环和功率扫描把系统余量摸清楚再谈量产。眼光放长远一点的话NPO很可能只是从可插拔走向更深度光互连路上的一站但它确实让DSP在AI互连里的角色开始退场了。