光互联技术演进：OIO、OBO、NPO、CPO架构对比与选型指南

光互联这个词，这几年在数据中心和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的"预备役"

NPO（Near Package Optics）这个名字本身就说明了它的定位——光引擎在封装附近，但不在封装内。它通常被看作是CPO的"预备役"或者"轻量版"，在工程难度和收益之间取一个折中。

NPO的典型形态是：光引擎安装在封装基板旁边的载板上，通过很短的基板走线或柔性连接与交换芯片通信。它比OBO更近，但还没有到CPO那种"同封装"的程度。这个定位带来的好处是：光引擎可以独立于交换芯片封装进行测试和更换，良率和可维护性比CPO好；同时电通道已经足够短，功耗和信号完整性的收益接近CPO。

NPO适合那些想尝鲜封装内光互联、但又不想承担CPO全部风险的场景。比如一些前沿的数据中心试点项目，或者对功耗极度敏感但运维能力有限的AI集群。NPO的光引擎通常还是可以单独维护的，这一点在早期部署阶段非常重要，因为新技术总会有各种意想不到的问题，可维护性就是生命线。

3.2 CPO的技术内核：为什么它被认为是终极方案

CPO（Co-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放在一起做横向对比，能更清楚地看出各自的定位。下面这张表是我根据公开资料和实际测试经验整理的，数值是典型范围，具体会因厂商和实现方式不同而有差异。

指标	OIO	OBO	NPO	CPO
电通道长度	几厘米	毫米到厘米	几毫米	极短
功耗改善	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是方向但还需要时间。我在实际项目里的体会是，不要盲目追新，也不要固守旧方案，关键是把你的核心约束想清楚，然后选一个风险可控、能落地、留有余地的方案。技术演进很快，今天的选择可能两三年后就要调整，所以保留灵活性和回退路径，比追求单点最优更重要。