企业官网建设流程全解析

上个月在实验室调一台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从光链路里拿掉，换一种更省的方式完成同样的事。目前主要有三条路线在并行：

• LPO（Linear-drive Pluggable Optics，线性驱动可插拔光模块）：可插拔模块里不装DSP，宿主SerDes直接通过线性Driver驱动光引擎，接收端只用TIA，不做重定时。
• NPO（Near-Package Optics，近封装光学）：光引擎不放进可插拔模块，而是摆到交换芯片或GPU的封装基板附近，电信号缩短到几厘米级别，链路简单到不需要DSP。
• CPO（Co-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之间通过基板上的高速走线相连，走线长度一般只有几厘米，损耗小到几乎可以忽略。光引擎的另一侧通过光纤阵列（FAU，Fiber Array Unit）把光信号引到前面板或连接器，再接到外部光纤跳线。为了便于散热和器件寿命，NPO方案里的激光光源一般放在光引擎外部甚至板卡外部，通过ELSFP（External Laser Source）或者独立光源模块供光。

这样布局最直接的好处是，电信号根本不用穿越整块PCB，也不用过各种背板连接器，信号完整性从源头就非常优秀。传统可插拔方案里，SerDes信号要跑20到40厘米的PCB走线，还要经过连接器、解锁机构，损耗很大；NPO方案里段电链路被压缩到几厘米，损耗可能只有前者的十分之一。没有了长铜线上的损耗、串扰和频率依赖衰减，也就不需要DSP做大幅度的均衡补偿。

2.2 NPO、LPO、CPO一张表看清差异

我在给团队做内部培训的时候，喜欢用一张表把这几种方案放在一起比较，重点关注几个维度：电信号链路长度、是否使用DSP、光引擎位置、可维护性、良率风险。

从这张表能看出来，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），接收灵敏度设为S（dBm），链路损耗包括光纤损耗（每公里约0.35dB）和连接器插损（一个MPO连接器约0.5dB）。如果光纤长度10米、有两对连接器，那么链路损耗大约是0.35×0.01+1，也就是1.1dB左右。这个损耗水平下，光功率预算余量做到5dB以上没问题。

再看电端：NPO方案里SerDes到光引擎的电走线只有几厘米，插损可能只有0.5dB到1dB，而传统可插拔模块那条几十厘米的线路插损可能到10dB以上。电信号预算非常充沛，SerDes不需要开太多的均衡抽头，CDR的锁定也更轻松。把光功率预算和电信号预算两边一拉，你会发现NPO完全能在没有DSP的情况下保证信号眼图张开。

反过来，如果把链路距离拉到2公里，中间又有多个扇出连接器，没有DSP的均衡能力就会很吃力。所以我的判断标准很简单：300米以内、连接器数量小于等于4个、链路总损耗小于3dB，NPO去掉DSP完全可行；超过这个范围，还是规规矩矩用DSP方案或者上更强FEC吧。

3.2 NPO端口选型：光引擎、光源和连接器都要单独定

评估NPO时容易忽略的一点是，NPO不是一个完整模块，而是一个由很多子部件拼起来的系统。我梳理之后发现，实际选型要定四样东西：光引擎本身、激光光源、光纤阵列FAU和外部连接器。

• 光引擎（Optical Engine）：核心指标是调制格式（PAM4）、通道数、功耗和灵敏度。目前主流是硅光方案，硅光的优势是可以用CMOS工艺做高密度集成，缺点是插损偏大；也有人用EML加TIA的方案，光性能好但功耗稍高。选型时还要关注光引擎的工作温度范围，是否能和ASIC封装的热设计匹配。
• 光源（Laser）：很多NPO光引擎里并不会直接放激光器，因为激光器的寿命和热敏感度会影响整个封装件的可靠性。一般使用外置CW光源，通过ELSFP或独立光源模块供光。选型要看光源的波长、线宽、功率稳定性，以及是否支持冗余（比如1+1保护）。
• FAU（Fiber 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光模块每个18W，64个是1152W；NPO的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系统常见问题速查表

把我在实际项目中遇到过的问题整理成一张速查表，供做运维和测试的朋友参考：

我在把NPO方案从实验室测试推向实际机房的过程中，最大感受是这项技术不是简单的“把DSP拿掉”，而是一次系统层面的重构。去掉DSP之后，链路功耗和时延确实下来了，但系统对光学器件质量、热管理、运维规范的要求变得更高，整个团队的技术栈也需要跟着调整。如果你正准备在AI服务器互连里评估或采用NPO，我给的建议很简单：先在实验室做链路预算测算，接着用温度循环和功率扫描把系统余量摸清楚，再谈量产。眼光放长远一点的话，NPO很可能只是从可插拔走向更深度光互连路上的一站，但它确实让DSP在AI互连里的角色开始退场了。