CPO/NPO 光互联革命：AI 算力基础设施的「最后一公里」博弈

前言：当光速遇上算力瓶颈

2026年的全球AI军备竞赛，正在从芯片性能的比拼悄然转向另一个战场——服务器内部以及服务器之间的高速互联。

GPT-5集群训练需要数万亿参数在数万个GPU之间同步；Claude 3.7 Sonnet的百万Token上下文需要海量的KV Cache在计算节点间流动；国产DeepSeek-V3要追赶国际顶级模型，同样面临TB级的梯度同步开销。这些场景背后，有一个被忽视却致命的瓶颈：电气互连的物理极限。

当SerDes速率从56G向112G、224G演进时，传统的PCB铜线传输面临功耗急剧上升、信号完整性恶化、电磁干扰加剧等一系列工程挑战。光互联（Optical Interconnect）被业界视为破局之路，而其中最具争议、最受关注的两条技术路线——CPO（Co-Packaged Optics，共封装光学）和NPO（Near-Packaged Optics，近封装光学）——正在成为2026年AI基础设施领域最激烈的技术博弈。

本文将深入剖析这场光互联革命的底层原理、架构取舍、产业现状和程序员视角下的影响。

一、背景：为什么 AI 算力被「连接」卡住了脖子

1.1 从芯片到集群：被忽视的互联墙

过去几年，AI算力的讨论焦点几乎全部集中在芯片本身：H100的Tensor Core数量、B200的晶体管密度、GB200的制程节点。然而，当我们将视角从单芯片切换到整个训练集群时，会发现一个令人不安的事实：GPU之间的互联带宽，正在成为比GPU算力更稀缺的资源。

一个典型的LLM训练集群包含数千到数万个GPU。以GPT-4的训练为例，据估算需要约25,000张A100 GPU运行约100天。期间，模型参数梯度需要定期在所有GPU之间同步——这不是简单的数据传送，而是对带宽、延迟和同步精度的三重严苛要求。

典型集群互联带宽需求估算：

模型参数量：175B（GPT-3级别）
GPU数量：1,024张 A100（80GB显存）
梯度同步频率：每几步同步一次（ microbatch 级别）
单次梯度通信量 ≈ 参数总量 / 数据并行度
                 = 175GB × 8bytes / 1024
                 ≈ 1.37GB/同步周期

在1000次同步/轮次的高频场景下：
总带宽需求 = 1.37GB × 1000 × 训练轮数

当模型规模达到万亿级别，互联带宽不足会导致AllReduce操作成为系统瓶颈，GPU算力利用率（GPU Utilization）可能低至30%-40%，相当于数百万美元的硬件投资大量闲置。

1.2 传统可插拔光模块的天花板

当前数据中心主流的可插拔光模块（Pluggable Optics），如QSFP-DD、OSFP规格的400G/800G光模块，采用的是分离式架构：

• 光引擎（光模块）独立于交换芯片，插入面板前端
• 芯片到模块之间通过PCB走线和连接器电气传输
• 典型距离：数厘米到数十厘米

这一架构在400G时代运行良好，但在向800G、1.6T乃至3.2T速率演进时，面临系统性的工程困境：

功耗问题：可插拔光模块的典型功耗为每100G约7-8W。800G模块功耗约25-30W，而1.6T模块可能超过50W。在一个配备数百个光模块的64端口交换机上，仅光模块的功耗就可能超过3kW——这已经超过了许多单台服务器的电源预算。

信号完整性：224G PAM4信号的PCB传输损耗在高频下急剧恶化。以10英寸PCB走线为例，56G PAM4的插入损耗约5dB，而112G PAM4可能超过15dB，需要昂贵的重计时器（Retimer）来补偿，进一步推高功耗和成本。

密度瓶颈：前面板空间有限。64端口×800G的配置需要大量前面板面积，与散热 airflow 设计冲突。

延迟开销：芯片→PCB→连接器→光纤的路径，每个环节都引入额外的信号延迟。对于AI训练中需要高频同步的AllReduce操作，这种延迟会直接叠加到关键路径上。

1.3 AI 集群的两种互联拓扑：Scale-Up vs Scale-Out

在讨论光互联技术路线之前，需要理解AI集群的两种互联拓扑：

Scale-Up（纵向扩展）：单个计算节点内部的GPU/NPU互联。典型如NVIDIA DGX GB200 NVL72系统，72个GPU通过NVLink 5.0全互连，单节点内部带宽达到每秒1.8TB。这是英伟达的「超级计算机」路线——把整个集群压缩进一个机柜。

Scale-Out（横向扩展）：数千数万GPU之间的集群网络。依赖InfiniBand或以太网交换机进行节点间通信。这是互联网大厂训练大模型的「大规模并行」路线——用商品化的网络设备将数十万张卡连成一张巨型计算网。

两条路线对光互联的需求不同：

• Scale-Up：极致带宽密度、超低延迟，但节点数量少，主要用铜缆（NVLink Copper）和少量光缆
• Scale-Out：超大规模端口数、高可靠性、可维护性是刚性需求，光互联是必然选择

CPO和NPO的博弈，核心就在Scale-Out场景。

二、CPO：共封装光学的「终极野心」

2.1 架构原理：将光引擎推向前沿

CPO（Co-Packaged Optics，共封装光学）的核心理念，用一句话概括：把光引擎和交换芯片封装在同一块基板上，消灭它们之间的电气连接。

传统可插拔架构：

[交换芯片] ---(PCB走线, 10-30cm)---> [前面板连接器] ---(光纤)---> [可插拔光模块]

CPO架构：

[交换芯片 + 光引擎] ---(基板内互连, <5cm)---> [光纤接口（前面板）]

在CPO方案中，光引擎（如硅光调制器、III-V激光器阵列）不再是一个独立可插拔的模块，而是与ASIC交换芯片共同焊接在同一块高密度基板（Substrate）上，甚至可能采用2.5D/3D封装将两者堆叠。

典型CPO模块的结构：

┌──────────────────────────────────────────┐
│          CPO 光引擎模组（与芯片共基板）     │
│  ┌─────────┐    ┌─────────┐               │
│  │ 交换芯片 │────│ 硅光引擎 │              │
│  │ (ASIC)  │铜互连│(Silicon │              │
│  │         │<5cm │ Photonic)│             │
│  └─────────┘    └────┬────┘               │
│                      │光纤（LC/MPO接口）   │
│                      ↓                   │
│              前面板光纤连接器               │
└──────────────────────────────────────────┘

2.2 技术优势：为什么业界对 CPO 寄予厚望

功耗降低：这是CPO最核心的价值主张。业界普遍预期CPO可将光互联功耗降低30%-50%。原因有三：

1. 电气距离缩短：从芯片到光引擎的铜互连从30cm缩短至2-5cm，驱动器和重计时器的功耗大幅降低
2. SerDes复杂度降低：长距离电气信号的均衡需求减弱，可使用更低功耗的SerDes方案
3. 光引擎集成度提升：硅光技术允许在单个芯片上集成数十甚至上百个波导通道

带宽密度提升：CPO可在相同的面板空间内容纳更多端口。由于光引擎被「推到」芯片旁边，前面板的面积可以专门用于光纤连接，而不是被光模块外壳占用。

信号完整性改善：极短的电气互连大幅降低了高频信号的反射、串扰和ISI（符号间干扰），无需重计时器即可实现可靠传输。

2.3 技术挑战：理想与现实的鸿沟

然而，CPO的工程化道路远比技术原理复杂：

维护性灾难：这是CPO被批评最多的痛点。当一个CPO光引擎出现故障时，需要更换整个CPO模组——包括与之共封装的交换芯片。这意味着：

• 维护窗口不再是「拔出一个模块，插入一个新模块」的5分钟操作
• 而是需要整个系统下电、拆焊、重新焊接、测试的数小时工程
• 在一个拥有数万台交换机的超大规模数据中心，这可能是运维的噩梦

升级锁定：可插拔光模块的灵魂在于灵活性。当光模块技术升级（如从CWD4升级到CWD8）、或需要更换波长时，只需拔出旧模块插入新模块。在CPO架构下，这意味着整个CPO模组需要重新设计。

散热设计复杂：交换芯片和光引擎都是发热大户。在可插拔架构中，光模块可以通过独立散热片、甚至主动散热来管理。而在CPO架构中，光引擎和芯片共享散热系统，热设计需要整体考虑。

供应链锁定：CPO需要光引擎厂商和交换芯片厂商的深度合作。博通、Marvell等交换芯片厂商与Celestial AI、Intel Foundry等光引擎厂商需要联合开发、联合优化。这种强耦合的合作模式在技术上有优势，但在商业上是巨大的风险。

2.4 产业现状：2026——CPO 量产的元年还是幻灭的开始？

2026年，CPO正站在从「概念验证」到「小批量量产」的关键节点上。

英伟达的Rubin架构已经明确采用CPO技术路径。据公开信息披露，Rubin计划在2026年率先在Scale-Out网络场景实现CPO量产。这对于整个行业是一个重大信号——当全球最大的AI算力采购方选择了CPO，上游供应链将被迫跟进。

然而，博通（Broadcom）却公开唱反调。2026年初，博通在其投资者日活动中表示：「CPO技术尚未成熟，今明两年难以实现有意义的量产部署」。博通的顾虑集中在三点：

1. 维护成本远高于预期
2. 光学器件的良率问题尚未解决
3. 客户对供应链锁定风险的担忧

这一分歧揭示了CPO当前的核心矛盾：最激进的推动者（英伟达）和最重要的供应商（博通）之间，对成熟度的判断存在根本分歧。

三、NPO：务实的「过渡方案」

3.1 架构原理：站在巨人和可插拔之间的中间路线

NPO（Near-Packaged Optics，近封装光学）的定位，是比可插拔更近、但比CPO更远的一种折中方案。

传统可插拔：芯片 <---30cm PCB---> 连接器 <---光纤---> 光模块
NPO：        芯片 <---5-10cm PCB---> NPO光引擎（近芯片）<---光纤---> 外部接口
CPO：        芯片 ===<5cm 基板互连>=== 光引擎（与芯片同基板）

NPO的核心特征：

• 光引擎仍然是独立封装，可以单独维护和更换（这是与CPO的根本区别）
• 光引擎非常靠近交换芯片（通过高密度连接器和短PCB）
• 光引擎到外部光纤接口的距离大大缩短（省去了前面板连接器的环节）

3.2 中际旭创的 NPO 实践

在NPO路线上，中国光模块厂商中际旭创（InnoLight）是走得最快的企业之一。

2025-2026年，中际旭创已经实现NPO 1.6T光引擎的量产，并明确表示该产品适配英伟达GB200集群。其技术路线图显示：

NPO产品路线（中际旭创）：
- 2025 Q4：NPO 800G 量产交付
- 2026 Q1：NPO 1.6T 量产交付（适配英伟达 Rubin 前瞻需求）
- 2026 Q3：NPO 1.6T 增强版（功耗进一步降低20%）
- 2027+：NPO/CPO 混合架构探索

NPO之所以在量产上领先CPO，核心原因在于它保留了可插拔模块的可维护性优势。当NPO光引擎出现故障时，可以单独拆换，而不需要连同交换芯片一起处理。这对于大规模数据中心的运维团队来说，是一条不可忽视的「保命」设计。

3.3 NPO 的功耗与性能数据

根据公开资料和行业测算，NPO在功耗和性能上的典型数据：

从这个对比表中可以看出，NPO本质上是「用适度的功耗节省换取可维护性和可升级性」。这是一种务实主义的工程哲学：在技术还不完全成熟时，不追求极致，而是在多个维度找到平衡点。

四、CPO vs NPO：架构取舍背后的工程哲学

4.1 两种路线的核心分歧

CPO和NPO的争论，本质上是**「追求极致性能」与「保持系统灵活性」**之间的权衡。这一分歧贯穿了整个数据中心网络技术的演进历史：

2010年代：光模块从CFP→CFP2→CFP4小型化
          → 行业选择了持续小型化而非共封装
          → 因为可维护性是刚需

2020年代：112G/224G SerDes时代的功耗墙
          → CPO倡导者认为功耗问题无法靠小型化解决
          → NPO支持者认为CPO的可维护性代价太大

2026年： 英伟达 VS 博通的分歧
         → 前者选择激进推进CPO量产
         → 后者认为技术成熟度不够
         → 市场将用订单投票

4.2 微软的「反潮流」选择

有趣的是，全球第二大AI算力采购方微软在光互联路线上表现得极为保守。微软Azure的官方技术博客多次表示：

「在CPO技术证明其可维护性和供应链成熟度之前，我们将继续投资于可插拔光模块的高密度集成和LPO线性直驱技术。」

微软的态度代表了一批「务实派」的观点：与其冒着运维风险押注一个未成熟的技术，不如先把钱花在刀刃上。

4.3 LPO：被忽视的第三条路线

在CPO和NPO的聚光灯之外，**LPO（Linear Pluggable Optics，线性直驱光模块）**是一条经常被忽视但正在快速成熟的第三条路线。

LPO的核心思路是去掉光模块中的DSP（数字信号处理器），直接用线性模拟前端驱动光收发器。DSP是光模块中功耗最高的组件之一（可达5-10W），去掉DSP后功耗可降低40%以上，但代价是对信号质量的控制要求大幅提高。

功耗对比（800G DR8光模块）：

含DSP可插拔：  ~25W
LPO（无DSP）： ~12-15W  （节省约40%）
NPO：           ~15-18W
CPO：           ~10-14W

LPO的功耗优势接近CPO，但保留了可插拔的可维护性。

LPO的问题在于对SerDes和光纤链路质量的依赖。在没有DSP进行信号重定时的情况下，224G PAM4信号在光纤中的传输质量必须足够好，否则误码率会飙升。目前，LPO主要在数据中心内部短距离场景（如服务器到叶交换机的连接）中部署。

五、产业格局：谁在押注，谁在观望

5.1 玩家矩阵

交换芯片厂商：
  - Broadcom（Tomahawk 5 / Baudrate 3）
  - Marvell（Prestera 9500）
  - Cisco（Silicon One G系列）
  - 盛科通信（中国） / 华为CloudEngine（中国）

光模块/光引擎厂商：
  - 中际旭创（InnoLight）—— NPO领先
  - 华工科技 —— NPO跟进
  - 剑桥科技 —— 传统可插拔+NPO
  - Intel Foundry Services —— 硅光CPO
  - Lumentum —— 3D VCSEL/外调制器
  - 华为光产品线 —— 全系列自研

超大规模云厂商（需求侧）：
  - 英伟达（DGX Rubin）—— CPO激进派
  - 谷歌（Gemini集群）—— 可插拔为主
  - Meta（Llama训练集群）—— NPO为主
  - 微软Azure —— 保守观望
  - 亚马逊AWS —— 自研Silicon Photonics

5.2 集邦咨询的 CPO 渗透率预测

根据集邦咨询（TrendForce） 2026年4月发布的最新报告：

从0.05%到35.74%，意味着65倍的增长空间。但这些数字背后需要注意：

• 2026年的0.55%意味着CPO仍处于「Pilot部署」阶段
• 真正起量要到2027-2028年
• 届时NPO+LPO+CPO将形成共存格局，而非单一技术替代

5.3 中国产业链的机遇与挑战

对于中国AI基础设施产业来说，CPO/NPO光互联既是机遇也是挑战：

机遇：

• 中国光模块厂商（中际旭创、华工科技、剑桥科技）在光模块制造工艺上已全球领先
• 国产交换芯片（盛科通信、华为CloudEngine）正在快速追赶
• 庞大的国内AI算力投资提供了市场规模保障

挑战：

• 硅光核心芯片（硅光调制器、SOI晶圆）仍依赖境外供应链
• CPO共封装工艺需要芯片和光引擎的深度协同，中国生态还不够成熟
• 224G以上速率的TIA/Driver芯片与博通、Macom等仍有差距

六、程序员视角：光互联革命对我们的影响

6.1 AI 框架层的间接影响

对于大多数应用层程序员来说，CPO/NPO是「看不见」的基础设施，但它会通过以下路径影响我们的工作：

训练时间：更高速的Scale-Out网络 → AllReduce更快完成 → 训练周期缩短 → 模型迭代加速

想象一个具体的场景：

传统架构：1000 GPU集群，互联带宽800G
         梯度同步耗时占每步总耗时的40%
         
NPO升级后：1000 GPU集群，NPO 1.6T互联
          梯度同步耗时降低60%
          每步耗时从200ms降至80ms
          
对训练的影响：
- 原来100天的训练 → 约80天
- 原来需要1600卡时的场景 → 1280卡时
- 节省约20%的算力账单

推理吞吐量：对于需要大量分布式推理的服务（如ChatGPT、Claude API），更高的网络带宽意味着更大的Batch Size和更低的Token间延迟。

成本结构：AI推理的算力成本中，互联成本约占10%-15%。CPO/NPO降低的功耗最终会传导到API定价上，让终端用户受益。

6.2 调度层的直接挑战

对于从事AI基础设施（训练框架、推理引擎、集群调度）的工程师来说，CPO/NPO带来了新的架构约束：

网络拓扑变化：CPO通常采用16或32端口的高密度交换机（而非传统的64端口），这意味着网络拓扑从Fat-Tree向更深的3层甚至4层结构演进，对集合通信（ NCCL/CCL）的拓扑感知调度提出新要求。

亲和性调度：在CPO架构中，光引擎与特定交换芯片绑定，光纤布线的变更成本极高。这意味着集群调度系统需要更强的网络拓扑亲和性感知，确保通信密集的任务被分配到网络拓扑上更近的节点组。

监控与诊断：传统可插拔光模块支持热插拔和实时数字诊断（DOM），故障定位相对简单。CPO模组的故障诊断需要新的工具链——这对SRE团队是全新的挑战。

6.3 代码示例：基于拓扑感知的 NCCL 通信优化

以下是使用NCCL的拓扑感知特性来优化分布式训练通信的示例代码（Python + PyTorch）：

import torch
import torch.distributed as dist
import os
import subprocess

def get_nccl_topology_info():
    """
    获取当前系统的NCCL拓扑信息
    NCCL会自动探测硬件拓扑并生成最优通信策略
    """
    # 设置环境变量让NCCL打印拓扑信息
    os.environ["NCCL_DEBUG"] = "INFO"
    os.environ["NCCL_DEBUG_SUBSYS"] = "ALL"
    
    # 初始化分布式环境
    dist.init_process_group(backend="nccl")
    
    rank = dist.get_rank()
    world_size = dist.get_world_size()
    
    # NCCL会自动在初始化时探测网络拓扑
    # 我们可以通过环境变量获取关键信息
    local_rank = int(os.environ.get("LOCAL_RANK", 0))
    nnodes = int(os.environ.get("NNODES", 1))
    nproc_per_node = int(os.environ.get("NPROC_PER_NODE", 1))
    
    return {
        "rank": rank,
        "world_size": world_size,
        "local_rank": local_rank,
        "nnodes": nnodes,
        "nproc_per_node": nproc_per_node,
        "node_rank": rank // nproc_per_node
    }

def build_topology_aware_process_group(topology_info):
    """
    在CPO/NPO环境中，基于节点拓扑构建优化的进程组
    
    策略：
    1. 优先在同节点内（NVLink域）完成小规模AllReduce
    2. 跨节点通信使用优化的网络路径
    3. 对于CPO交换机端口规划，避免同端口过载
    """
    rank = topology_info["rank"]
    world_size = topology_info["world_size"]
    local_rank = topology_info["local_rank"]
    nproc_per_node = topology_info["nproc_per_node"]
    node_rank = topology_info["node_rank"]
    
    # NCCL 2.x+ 会自动处理同节点和跨节点的通信分层
    # 但我们可以通过自定义 process group 进一步优化
    from torch.distributed.distributed_c10d import _get_default_store
    
    # 节点内通信组（同GPU服务器内，NVLink或CPO交换机内部）
    local_ranks = list(range(node_rank * nproc_per_node, 
                             (node_rank + 1) * nproc_per_node))
    
    # 为每个节点创建本地进程组
    local_pg = dist.new_group(ranks=local_ranks)
    
    # 全局通信组（跨节点，通过Scale-Out网络）
    all_pg = dist.group.WORLD
    
    # 在CPO环境中，节点内通信的带宽远高于跨节点
    # NCCL会根据拓扑自动选择 Ring 或 Tree 算法
    # 但我们可以给出提示：
    
    os.environ["NCCL_ALGO"] = "Ring"  # Ring在CPO高带宽下性能更稳定
    os.environ["NCCL_MAX_NCHANNELS"] = "8"  # CPO环境下可开更多通道
    
    return local_pg, all_pg

def benchmark_inter_node_bandwidth():
    """
    基准测试：验证NPO/CPO升级后的跨节点带宽提升
    
    在传统架构下，跨节点带宽通常只有节点内NVLink的1/5~1/10
    CPO升级后，这个比例有望提升到1/3~1/2
    """
    dist.init_process_group(backend="nccl")
    
    rank = dist.get_rank()
    world_size = dist.get_world_size()
    
    # 创建大尺寸tensor来测试实际带宽
    # 1GB tensor
    size_mb = 1024
    tensor_size = size_mb * 1024 * 1024 // 4  # float32
    
    tensor = torch.randn(tensor_size, device=torch.cuda.current_device())
    
    if world_size > 1:
        # 所有进程同步计时
        torch.cuda.synchronize()
        start = torch.cuda.Event(enable_timing=True)
        end = torch.cuda.Event(enable_timing=True)
        
        start.record()
        
        # AllReduce 1GB 数据
        dist.all_reduce(tensor, op=dist.ReduceOp.SUM)
        
        end.record()
        torch.cuda.synchronize()
        
        elapsed_ms = start.elapsed_time(end)
        
        if rank == 0:
            bandwidth_gbps = (size_mb * 8) / (elapsed_ms / 1000)
            print(f"AllReduce带宽测试:")
            print(f"  数据量: {size_mb} MB")
            print(f"  耗时: {elapsed_ms:.2f} ms")
            print(f"  等效带宽: {bandwidth_gbps:.2f} Gbps")
            print(f"  (传统架构参考: ~800 Gbps)")
            print(f"  (NPO升级后预期: ~1200-1400 Gbps)")

6.4 存储层的拓扑优化

在CPO环境中，GPU与存储服务器的通信模式也会发生变化。传统架构下，存储流量通常走Ethernet数据网络，与GPU集合通信共享交换机端口。在CPO部署后：

传统存储路径：
[GPU] ---(NVLink)---> [HBM/NVMe]          # 本地存储
[GPU] ---(PCIe)---> [NIC] ---(Ethernet)---> [分布式存储]
                          ↑
                    共享25%带宽

CPO环境优化路径：
[GPU] ---(NVLink)---> [HBM/NVMe]           # 本地存储
[GPU] ---(PCIe)---> [NIC] ---(CPO光互联)---> [分布式存储]
                          ↑
              CPO提供专用高带宽通道，不与集合通信争抢

这意味着分布式训练的数据加载管道可以更高效，DataLoader的Prefetch策略可以更激进：

import torch
from torch.utils.data import DataLoader
from torch.distributed.elastic.multiprocessing import get_context
import threading

class TopoAwareDataLoader:
    """
    拓扑感知的数据加载器
    
    在CPO环境中，存储网络带宽大幅提升，
    我们可以增加 prefetch_factor 来隐藏数据加载延迟
    """
    
    def __init__(self, dataset, batch_size, num_workers=8, 
                 storage_bandwidth_gbps=1600):
        """
        Args:
            storage_bandwidth_gbps: NPO/CPO升级后的预估带宽
                                    传统Ethernet: ~400Gbps
                                    CPO 1.6T互联: ~1600Gbps
        """
        self.dataset = dataset
        self.batch_size = batch_size
        
        # 根据存储带宽动态调整 prefetch
        # CPO环境：可以4倍 prefetch，因为带宽充足
        if storage_bandwidth_gbps >= 1000:
            self.prefetch_factor = 8  # CPO环境下的激进预取
        else:
            self.prefetch_factor = 4  # 传统环境
        
        self.loader = DataLoader(
            dataset,
            batch_size=batch_size,
            num_workers=num_workers,
            pin_memory=True,
            prefetch_factor=self.prefetch_factor,
            persistent_workers=True  # 保持worker进程常驻
        )
        
        # CPO环境下，可以同时预加载下一个epoch的数据
        self._prefetch_next_epoch()
    
    def _prefetch_next_epoch(self):
        """在CPO高带宽下，提前预加载下一个epoch的数据"""
        self._next_epoch_data = None
        
        def _background_load():
            if self.storage_bandwidth_gbps >= 1000:
                # CPO环境：异步预加载
                self._next_epoch_data = list(self.loader)
        
        self._prefetch_thread = threading.Thread(target=_background_load)
        self._prefetch_thread.daemon = True
        self._prefetch_thread.start()

七、技术演进路线图：2026-2030

基于当前产业信息，以下是光互联技术的演进路线图：

2026年：量产的起点
├── Scale-Out: NPO 1.6T 开始批量出货
├── Scale-Out: CPO 1.6T Rubin Pilot部署（数百至数千端口）
├── LPO 800G 在短距离场景规模应用
├── 传统可插拔 800G/1.6T 仍是主流（>95%份额）
└── 行业焦点：NPO量产交付能力、CPO良率

2027年：技术路线的分化期
├── NPO 1.6T 成为主流选择（成本与性能的平衡点）
├── CPO 3.2T 进入早期部署（2027年末）
├── Scale-Up互联：全光NVLink探索
├── LPO向224G演进
└── 行业焦点：CPO与NPO的份额之争

2028年：CPO规模化的关键年
├── CPO在AI数据中心占比达到2-7%
├── 3.2T CPO进入量产
├── 硅光子与III-V混合集成技术成熟
├── OCS（Optical Circuit Switch）开始渗透
└── 行业焦点：CPO的运维生态是否建立

2029-2030年：新格局形成
├── CPO 6.4T+ 技术成熟
├── 35%+ AI数据中心采用CPO
├── NPO成为过渡技术，份额开始下滑
├── 全光互联（Optical I/O）进入研发阶段
└── 硅光子代工生态形成独立产业

八、给不同角色的建议

8.1 应用层程序员

如果你主要使用云厂商的API（OpenAI、Claude、DeepSeek等）：

• 好消息：CPO/NPO升级带来的算力成本下降，最终会传导到API定价上。2027-2028年，AI API的$/token预计将进一步降低30%-50%。
• 影响：推理延迟可能会降低，特别是长上下文场景（100K+ Token）。

8.2 AI 框架和基础设施工程师

如果你在自建AI训练集群或开发推理引擎：

• 关注CPO对网络拓扑的影响：特别是NCCL通信库对CPO交换机的支持情况
• 评估存储网络分离：CPO升级后，存储流量与计算流量的分离策略值得重新审视
• 监控工具升级：提前规划CPO模组的监控和故障诊断能力

8.3 云厂商基础设施团队

• NPO先行，CPO跟进：2026年的实际部署策略应该是NPO为主，CPO为辅
• 运维工具链投资：CPO的可维护性是最大风险，需要提前布局自动化运维能力
• 关注国产替代：中际旭创、华工的NPO产品已经具备量产能力，可以考虑纳入供应链

8.4 芯片和光模块从业者

• 硅光技术是CPO的核心：需要加大对硅光芯片、SOI晶圆工艺的投入
• 封装技术是瓶颈：2.5D/3D封装的良率和成本，是决定CPO能否量产的关键
• 测试和可靠性：CPO模组的寿命测试和现场可靠性数据，是说服客户的关键

结语：光速革命的「最后一公里」

2026年的AI光互联之争，表面上是CPO与NPO两种技术路线的商业博弈，深层是**「极致性能」与「系统工程可靠性」**之间永恒的张力。

CPO代表了一种技术理想主义：追求最高的带宽密度、最低的功耗，把光引擎和芯片融合成一个不可分割的整体。这条路线的拥趸相信，当功耗墙和带宽墙同时逼近物理极限时，融合是唯一的出路。

NPO代表了一种工程现实主义：在追求性能提升的同时，保留系统最基本的可维护性和可升级性。这条路线的支持者明白，一个不能被运维的「完美」系统，在工业界是没有生命力的。

两种路线的最终胜负，不取决于实验室里的性能数据，而取决于哪一种方案能在真实的数据中心环境中，以合理的成本和可接受的运维风险，完成规模化部署。

对于我们程序员来说，这场革命虽然发生在「看不见」的物理层，但它正在通过算力成本、模型迭代速度和API定价，悄无声息地塑造着我们的工作和生活。无论你是写PyTorch模型的算法工程师，还是在裸金属服务器上调试NCCL的infra工程师，这场光速革命，都与你息息相关。

在AI算力的「最后一公里」，光，正在取代铜。

参考资料（数据来源）：集邦咨询 2026年4月报告、国金证券光通信深度报告、界面新闻、腾讯新闻、新浪财经、中际旭创公开技术文档、英伟达GTC 2026技术披露、博通2026年投资者日材料。