光互联这个词这几年在数据中心和AI集群的圈子里被提得越来越频繁。早些年大家聊交换机关注点基本都在交换芯片的容量、缓存大小、端口密度这些电层面的指标上光模块不过是插在面板上的一个可插拔配件选型时看看速率、传输距离、功耗就差不多了。但现在情况变了800G还没完全铺开1.6T的讨论已经热火朝天交换芯片的带宽每两年翻一倍可面板上的可插拔光模块却越来越跟不上节奏——功耗压不住、密度上不去、信号完整性也越来越难做。于是业界开始把目光从面板上的光模块转向封装内的光引擎OIO、OBO、NPO、CPO这四个词就是这么冒出来的。它们代表了四种不同的光互联架构思路核心区别在于光引擎离交换芯片到底有多近。这篇文章我会把这四种技术掰开揉碎讲清楚包括它们各自解决什么问题、代价是什么、什么场景下该选哪种以及我在实际项目和测试中踩过的那些坑。1. 从可插拔光模块到封装内光互联的演进逻辑1.1 可插拔光模块的天花板到底在哪里要理解OIO、OBO、NPO、CPO为什么会出现得先搞清楚传统可插拔光模块遇到了什么麻烦。过去十几年交换机前面板插光模块、光模块通过PCB走线连接到交换芯片这套架构简单、灵活、可维护性好坏了换一个模块就行。但到了800G时代这套玩法的物理极限开始显现。最直接的问题是功耗。一个800G可插拔光模块的功耗大约在15到18瓦一个32端口的800G交换机光模块的总功耗就超过500瓦这还没算交换芯片本身的功耗。对于AI训练集群这种动辄需要上万张GPU互联的场景光互联的功耗占比越来越高散热和供电都成了大问题。其次是面板密度前面板的空间是有限的当单端口速率提升到1.6T甚至更高时可插拔模块的尺寸和散热要求会让面板根本放不下那么多端口。第三个问题是信号完整性从交换芯片到前面板光模块之间的电信号走线长度通常在十几到几十厘米在112Gbps甚至224Gbps的SerDes速率下这段走线的损耗和串扰变得非常棘手需要昂贵的PCB材料和复杂的均衡技术来补偿。这里有个容易被忽略的点很多人以为光互联的瓶颈在光本身其实在可插拔架构下瓶颈往往在电这一段——芯片到面板之间的电通道。光模块内部的光电转换反而相对成熟。1.2 四种技术路线的核心分野光引擎离芯片有多近OIO、OBO、NPO、CPO这四种方案本质上是在回答同一个问题光引擎应该放在哪里把它们按照光引擎到交换芯片的距离从远到近排列大致是这样的技术路线光引擎位置与芯片的距离电通道形式可插拔传统前面板十几到几十厘米PCB走线OIO封装外但靠近芯片几厘米短PCB走线OBO封装基板上毫米到厘米级基板走线NPO封装基板近芯片处几毫米基板短线CPO与芯片同封装内极短基板/中介层OIO全称是Optical Input/Output有时候也被叫做板上光或近封装光它的思路是把光引擎从前面板挪到PCB上靠近交换芯片的位置缩短电通道长度。OBO是Optical Board-level Optics或者On-Board Optics光引擎直接集成在封装基板或板级载板上。NPO是Near Package Optics光引擎放在封装基板附近但不在同一个封装体内。CPO是Co-Packaged Optics光引擎和交换芯片封装在一起共享同一个基板甚至中介层。这四种方案不是简单的替代关系而是在不同阶段、不同场景下的渐进式选择。理解它们的关键是理解距离缩短带来的收益和代价分别是什么。1.3 为什么不是一步到位直接上CPO既然CPO把光引擎拉到最近理论上收益最大为什么不直接跳过OIO、OBO、NPO上CPO这个问题我在和不少同行交流时都被问到过。答案其实很现实CPO的工程难度和生态成熟度还不足以支撑大规模部署。CPO面临的核心挑战包括光引擎和交换芯片封装在一起后任何一个环节出问题都可能导致整个封装报废良率和可维护性是大问题激光器的高温可靠性交换芯片附近温度很高传统激光器在高温下寿命会急剧下降需要外置激光源方案封装内的光纤耦合和对准精度要求极高标准化还在推进中不同厂商的CPO方案互不兼容。相比之下OIO和OBO的改动更小、风险更低、生态更成熟可以作为过渡方案先落地。NPO则介于两者之间是一个折中的选择。所以这四种技术更像是渐进路线图上的不同站点而不是非此即彼的竞争关系。2. OIO与OBO把光引擎从面板挪到板上的第一步2.1 OIO的核心思路与适用场景OIO的核心思路说起来很简单既然前面板到芯片的电走线太长那就把光引擎挪到芯片附近让电信号只走很短的一段距离剩下的长距离传输交给光纤。这个改动看似不大但带来的收益是实实在在的。从电通道角度看OIO把芯片到光引擎的电走线从几十厘米缩短到几厘米信号损耗大幅降低对SerDes均衡能力的要求也随之下降。这意味着可以用更便宜的PCB材料或者在不换材料的情况下支持更高的速率。从功耗角度看电通道缩短后驱动电信号所需的功耗也会降低虽然光引擎本身的功耗没有减少但整体链路的功耗会有改善。从面板密度看光引擎不再占用前面板空间前面板可以留给其他接口或者干脆做成全光互联的形态。OIO比较适合那些对可维护性要求高、但已经感受到可插拔模块功耗和密度压力的场景。比如一些大型数据中心的核心交换层端口速率在800G到1.6T之间希望在不改变现有运维体系的前提下降低功耗、提升密度。OIO的光引擎通常还是可维护的坏了可以单独更换这一点比CPO友好很多。2.2 OBO的工程实现与关键细节OBO把光引擎进一步集成到封装基板或板级载板上距离芯片更近一步。它的典型实现方式是交换芯片和光引擎都安装在同一个封装基板上光引擎通过基板上的短走线连接到芯片光纤从封装侧面引出。OBO的工程实现有几个关键细节值得展开说。第一是基板走线的设计虽然距离缩短了但基板走线的损耗特性跟PCB不一样需要重新做信号完整性仿真和优化。第二是散热光引擎和芯片在同一个基板上热耦合更紧密需要统筹考虑散热方案不能让光引擎被芯片的热量烤坏。第三是光纤引出和布线从封装侧面引出的光纤需要精心规划走线路径避免过度弯折导致光损耗同时要考虑光纤的固定和保护。我在一个OBO相关的测试项目里遇到过一个典型问题光引擎和芯片之间的基板走线在高温下损耗特性发生了变化导致误码率在温度升高后明显恶化。后来通过调整走线阻抗和增加温度补偿才解决。这个坑说明OBO虽然距离短但热-电-光耦合的复杂度反而更高了不能简单套用可插拔时代的经验。2.3 OIO和OBO在实际部署中的取舍OIO和OBO经常被放在一起讨论因为它们都属于把光引擎挪到板上这个大方向但实际部署时的取舍点不太一样。OIO的改动相对温和光引擎还是独立的模块形态运维体系基本不用大改适合作为从可插拔到更深度集成的过渡。它的主要收益是缩短电通道、降低功耗、释放面板空间但光引擎本身的功耗和散热问题没有根本解决。OBO的集成度更高收益更大但工程复杂度和风险也更高尤其是散热和信号完整性的协同设计。从成本角度看OIO的初期投入相对低因为光引擎还是标准化的模块供应链成熟。OBO往往需要定制化的基板设计和封装方案初期投入高但规模化后单端口成本可能更低。所以选择哪种取决于你的部署规模、运维能力、以及对风险的容忍度。小规模试点可以先上OIO大规模部署且有能力做深度定制的可以考虑OBO。3. NPO与CPO逼近封装内的终极形态3.1 NPO的定位CPO的预备役NPONear Package Optics这个名字本身就说明了它的定位——光引擎在封装附近但不在封装内。它通常被看作是CPO的预备役或者轻量版在工程难度和收益之间取一个折中。NPO的典型形态是光引擎安装在封装基板旁边的载板上通过很短的基板走线或柔性连接与交换芯片通信。它比OBO更近但还没有到CPO那种同封装的程度。这个定位带来的好处是光引擎可以独立于交换芯片封装进行测试和更换良率和可维护性比CPO好同时电通道已经足够短功耗和信号完整性的收益接近CPO。NPO适合那些想尝鲜封装内光互联、但又不想承担CPO全部风险的场景。比如一些前沿的数据中心试点项目或者对功耗极度敏感但运维能力有限的AI集群。NPO的光引擎通常还是可以单独维护的这一点在早期部署阶段非常重要因为新技术总会有各种意想不到的问题可维护性就是生命线。3.2 CPO的技术内核为什么它被认为是终极方案CPOCo-Packaged Optics把光引擎和交换芯片封装在同一个封装体内共享基板甚至中介层。这是光互联距离芯片最近的一种形态也是理论上收益最大的方案。CPO的核心收益体现在三个层面。功耗层面电通道缩短到极致后SerDes的功耗可以大幅降低整体链路的能效比显著提升。业界普遍认为CPO可以把光互联的功耗降低30%到50%这在AI集群这种功耗敏感的场景下是巨大的诱惑。密度层面光引擎不再占用面板空间单机架的互联密度可以大幅提升这对于需要海量互联的AI训练集群至关重要。信号完整性层面极短的电通道意味着信号损耗和串扰都大幅降低可以用更简单的均衡方案支持更高的速率。但CPO的技术内核也决定了它的难点。光引擎和芯片同封装后激光器的热可靠性是头号难题。交换芯片工作时温度很高传统激光器在高温下寿命会急剧下降所以CPO通常采用外置激光源External Laser Source方案把激光器放在封装外通过光纤把光引入封装内的光引擎。这样就规避了激光器的高温问题但增加了光纤耦合的复杂度。封装内的光纤耦合和对准是另一个难点需要亚微米级的对准精度对封装工艺要求极高。良率和可维护性也是大问题封装内任何一个光引擎出问题整个封装可能都要报废或返修成本很高。3.3 NPO和CPO的边界与选择依据NPO和CPO的边界其实比较模糊不同厂商的定义可能略有差异。一般来说NPO的光引擎在封装外但紧邻封装CPO的光引擎在封装内。但从实际效果看两者的电通道长度可能只差几毫米收益差距没有想象中那么大。选择NPO还是CPO主要看几个因素。一是运维能力如果你的团队有能力处理封装级的返修和更换CPO可以考虑如果希望光引擎还能单独维护NPO更稳妥。二是部署规模大规模部署时CPO的成本优势更明显小规模试点NPO更灵活。三是生态成熟度CPO的标准化还在推进中不同厂商方案差异大NPO相对更接近现有生态。四是时间窗口如果你的部署时间紧NPO可能更快落地如果着眼长远且愿意承担早期风险CPO是方向。我在和几个做数据中心架构的朋友聊的时候大家有个共识CPO是方向但不是现在。未来两三年NPO和OBO会是更现实的选择CPO会在特定场景先落地然后逐步铺开。4. 四种技术的实测对比与选型决策框架4.1 关键指标的横向对比把OIO、OBO、NPO、CPO放在一起做横向对比能更清楚地看出各自的定位。下面这张表是我根据公开资料和实际测试经验整理的数值是典型范围具体会因厂商和实现方式不同而有差异。指标OIOOBONPOCPO电通道长度几厘米毫米到厘米几毫米极短功耗改善10%-20%20%-30%30%-40%30%-50%面板密度提升中等较高高最高可维护性好较好中等较差工程难度低中中高高生态成熟度高中高中低到中初期成本低中中高高适用阶段过渡过渡到进阶进阶终极从这张表能看出一个清晰的梯度从左到右收益递增但工程难度、成本和风险也递增。没有哪个方案是全面最优的关键看你的具体约束条件。4.2 选型时最容易踩的三个坑在实际选型过程中我见过也踩过一些坑这里挑三个最有代表性的说说。第一个坑是只看功耗数字忽略散热协同。很多人选型时盯着功耗改善的百分比觉得CPO功耗最低就选CPO。但实际上CPO把光引擎和芯片封装在一起后散热设计变得极其复杂如果散热方案跟不上光引擎的实际工作温度可能比可插拔方案还高可靠性反而下降。选型时必须把散热方案一起考虑不能只看功耗数字。第二个坑是低估可维护性的长期成本。CPO的可维护性差这在试点阶段可能不是问题但大规模部署后任何一个光引擎故障都可能导致整封装返修运维成本和时间成本会急剧上升。我见过一个项目初期为了追求功耗指标选了CPO结果后期运维团队苦不堪言最后不得不回退到NPO方案。选型时要算总账不能只看初期指标。第三个坑是忽视生态和标准化。CPO目前标准化还在推进中不同厂商的方案互不兼容一旦选了某家的方案后续升级和替换都会被绑定。OIO和OBO的生态相对成熟兼容性更好。如果你的部署周期长、希望保留灵活性生态成熟度是一个必须考虑的因素。4.3 一个可落地的选型决策流程基于上面的分析我整理了一个简单的选型决策流程供参考。第一步明确你的核心约束。是功耗优先、密度优先、还是可维护性优先不同优先级会导向不同的选择。功耗和密度优先往CPO方向走可维护性和生态优先往OIO方向走。第二步评估你的运维能力。团队有没有封装级返修的能力有没有处理光纤耦合问题的经验如果没有NPO和CPO的风险会很高。第三步看部署规模和周期。小规模试点可以选NPO或OBO灵活且风险可控大规模长期部署如果生态成熟度允许CPO的长期成本优势更明显。第四步做小规模验证。不管选哪种都建议先做小规模试点实测功耗、散热、误码率、可维护性等关键指标再决定是否大规模铺开。我在项目里始终坚持先试点、再推广的原则能避免很多后期返工。第五步保留回退路径。新技术总有不确定性选型时要考虑如果方案不达预期能不能回退到上一代方案。OIO和OBO的回退路径相对清晰CPO的回退成本较高这一点要提前想清楚。5. 光互联技术演进中的测试挑战与实操经验5.1 封装内光互联给测试带来的新问题光互联从可插拔走向封装内测试的难度是成倍增加的。可插拔时代光模块是独立的测试可以在模块级别完成插到交换机上再做系统级验证。但到了NPO和CPO光引擎和芯片封装在一起测试的介入点变得非常有限。最直接的问题是测试点难以触及。封装内的光引擎电信号测试点很难引出光信号的测试也需要特殊的光纤耦合方案。这就导致很多测试只能在系统级别做出了问题很难定位是芯片、光引擎还是耦合环节的问题。我在一个CPO相关的测试项目里遇到过一个误码率间歇性恶化的问题排查了很久才发现是封装内某一路光纤耦合的应力在温度循环下发生了变化这种问题在可插拔时代几乎不会遇到。另一个问题是测试的标准化。可插拔光模块有成熟的MSA标准测试方法和指标都有明确规范。但NPO和CPO的测试标准还在制定中不同厂商的测试方法和指标定义可能不一样给横向对比和验收带来困难。这也是为什么我一直建议在标准成熟之前选型时要特别关注厂商的测试能力和测试方案是否透明。5.2 实际测试中值得关注的几个指标在封装内光互联的测试中有几个指标特别值得关注我结合实际经验说说。误码率BER的温度稳定性。封装内光互联的温度环境比可插拔复杂得多光引擎可能同时受到芯片热量和自身热量的影响。测试时不能只看常温下的误码率要做温度循环测试看误码率在温度变化下的稳定性。我见过常温下误码率很好的方案在高温下就崩了。光功率和耦合效率的一致性。封装内的光纤耦合每一路的耦合效率可能都有差异测试时要关注多路之间的一致性不能只看平均值。一致性差的方案系统余量会很小长期可靠性堪忧。功耗的实际值 vs 标称值。封装内光互联的功耗标称值往往是在理想条件下测的实际部署时由于散热条件不同功耗可能会有差异。测试时要在实际散热条件下测功耗不能只看数据手册。可维护性相关的指标。比如光引擎故障后的更换时间、返修成本、是否需要整封装更换等。这些指标在选型时容易被忽略但在长期运维中影响巨大。5.3 从测试角度给选型提几条实操建议基于这些测试经验我给正在做光互联选型的朋友几条实操建议。第一测试方案要提前介入。不要等选型定了再想怎么测选型阶段就要评估厂商的测试能力和测试方案测试能力弱的厂商后期出问题很难定位和解决。第二坚持做温度循环和长期可靠性测试。封装内光互联的可靠性问题往往在温度变化和长期运行后才暴露短期测试很难发现。建议至少做1000小时的高温老化测试和完整的温度循环测试。第三关注多路一致性不只看平均值。封装内多路光引擎的一致性直接影响系统余量测试时要看最差的那一路而不是平均值。第四把可维护性纳入测试范围。模拟光引擎故障测试更换和返修的实际时间和成本这些数据对选型决策很重要。第五保留测试数据和测试方法。封装内光互联的测试数据是后续运维和升级的重要参考测试方法和条件要详细记录方便后续对比和复现。光互联这四种技术说到底是在性能、成本、风险这个三角里找平衡点。OIO和OBO是当下更现实的选择NPO是进阶的折中CPO是方向但还需要时间。我在实际项目里的体会是不要盲目追新也不要固守旧方案关键是把你的核心约束想清楚然后选一个风险可控、能落地、留有余地的方案。技术演进很快今天的选择可能两三年后就要调整所以保留灵活性和回退路径比追求单点最优更重要。
