UPN512 技术架构白皮书
目录
1.术语 3
2. AI基础设施网络的发展趋势 3
3. xPUScaleup 网络的演进和挑战
4. 阿里云 UPN512架构概览
4
6
5. UPN512系统设计和关键组件 8
系统架构 8
AI Rack-铜互连紧耦合系统 8
UPN512-单层光互连解耦系统 8
全光互连 9
单层千卡域 12
解耦设计 12
光互连概览 14
可插拔光互连∗案 14
∗密带宽光互连∗案 15
LPO/NPO 场景和∗案的选择 17
LPO/NPO 成本 18
互连稳定性 19
传输语义 19
在∗计算 22
1. 术语
术语 解释
UPN Ultra Performance Network
HPN High Performance Network
MoE Mixture of Experts
EP Expert Parallelism
FRO Fully Retimed Optics
LPO Linear-drive Pluggable Optics
NPO Near-packaged Optics
CPO Co-packaged Optics
OE Optical Engine
VCSEL Vertical-Cavity Surface-Emitting Laser
EML Electro-Absorption Modulated Laser
ELSFP External Laser Small Form-Factor Pluggable
MTBF Mean Time Between Failures
MTTR Mean Time To Repair
2. AI基础设施网络的发展趋势
近年来，随着人工智能（AI）技术蓬勃发展，大模型训练、推理任务对算力、内存的需求呈现
指数级增长。为了提升算力，获取更短的训练时间和更高的推理效率，智算集群通过高性能网
络进行集群算力的扩展，目前已经从万卡向十万卡、数十万卡级别迈进。为了实现高效的训练
推理，业界通常会采用多种并行策略驱动数千甚至数万张xPU进行交换数据，协作完成作业，
这依赖于高性能的网络转发能力。纵观AI基础设施的技术发展，如下几个方面对网络提出新的
要求。
模型结构从Dense演进到MoE。大模型经过其初期发展后，在提升模型容量效率和降低计算成
本的驱动下，基于MoE（Mixture of Experts）的模型结构逐渐代替Dense模型结构，成为一种
趋势。MoE将模型划分为多个独立专家网络，并利用门控机制动态分配输入数据给特定专家 进
行处理。MOE 通过多个专家并行处理不同的数据子集，然后根据输入数据的特征动态选择最
合适的专家输出，在提高模型性能的同时有效地控制了算力成本。从网络视角，MoE模型结 构通
常采用EP并行（Expert Parallelism），EP并行要求网络超大带宽和超低时延，同时由于更多EP
并行域（大EP）会带来计算效率的提升，更大的EP网络通信域成为网络演进的趋势。
从预训练到训推一体。智算集群的算力负载，已经从预训练逐步向训推一体演进，即在同一个
网络集群内有离线的模型训练、RL，也会有在线的推理服务，推理场景中也演化出分布式效率
优化技术包括PD分离、AF分离、大EP推理等。从网络视角，在线和离线流量共存，不同并行
模式，以及不同计算密度负载的分离，都使得网络通信模型更加复杂，对训推一体的网络架构
设计提出更高的要求。
通过 xPU Scale up 扩展提升集群化算力。为了应对模型对算力增长的诉求，算力互联技术同样
发展迅速，通过大带宽低时延的网络互联实现集群化的超节点算力提升成为主要趋势，比如
NVIDIA GPU Scale up 域已经由原来的8卡风冷系统演进到72卡液冷系统，华为也已经发布了
通过UB网络组成的384张NPU超节点。
通过超大带宽超低时延的 Scale up 网络扩展xPU的集群超节点算力是AI底层算力基础设施发
展的一个重要方向。本文探讨 xPU Scale up 系统的演进和遇到的挑战，并提出阿里云UPN
（Ultra Performance Network）架构设计，面向未来构建“大规模、高性能、高可靠、低成本、
可扩展” 的 xPU Scale up 系统。
3. xPU Scale up 网络的演进和挑战
如上文所述，一方面超大带宽超低时延的 Scale up 网络互联可以有效提升xPU超节点的集群
化算力，另一方面MoE模型的发展趋势也对于 Scale up 互连域的扩展提出要求。基于MoE的
稀疏模型结构逐渐代替稠密型（Dense）模型结构成为主流的同时，MoE模型的专家
（Expert）数量也越来越大。最早的开源MoE模型Mixtral 8x7B有8个Expert，今年的主流开源
模型Qwen3有128个Expert，DeepSeek-v3有256个Expert，Kimi K2 有384个Expert。在MoE模
型中，通过大EP方式（即通过更多xPU实现专家并行）来优化模型的训练和推理效率是 一个主
要的算力效率优化方向，这使得主流算力系统的演进方向都在考虑做更大的 Scale up 网络互
联域来满足EP的大带宽大规模互通需求。NV已经发布了NVL72，并规划了未来的NVL144和
NVL576，华为发布了384颗NPU组成的 Scale up 系统CM384超节点，AMD宣称其下一代芯片
的 Scale up 网络互联域将达到256。展望未来，而如何扩展设计构建更大的 xPU Scale up 系统
，则是xPU算力超节点技术的主要挑战。
目前 Scale up 系统大多采用铜缆互连的方案。基于技术发展的现状，铜缆互连是一种成本相对
低，稳定性相对好的互连技术，缺点在于互连距离受限，所以当前业界主要聚焦于利用铜缆 在
Rack空间内采用高密设计来实现算力的最大化。然而，高密Rack设计使得系统复杂性急剧 增
加，可靠性受到挑战，系统扩展性有限。面向未来，光互连是更大范围的 Scale up 网络互联
的必然选择，然而相比铜缆互连，业界关注的光互连主要有两个挑战，成本和可靠性。
关于光互连的成本挑战。影响 Scale up 系统网络成本的因素有多个，光与铜的互连成本差异是
其中之一。首先，架构选择对于系统的网络互联成本有较大的影响，比如基于Switch的交换 架构
有比较好的通信pattern适配性，从而可以获得更好的性能，缺点是成本相对高， NVIDIA、
AMD、华为CM384均采用此路线，无Switch架构的Torus互连可以降低成本，但在 性能上有
一些妥协，Google TPU采用此路线。其次，未来Scale up和Scale out的继续分离， 还是走向融
合，对网络成本的影响也不容小觑。最后，我们再来看选择不同互连方案的成本分 析，这里建
立了一个成本估算的模型，利用业界公开的数据进行分析，比较基于Switch交换架 构的几种方
案的成本（无Switch架构的“Torus互连+OCS”或者“nD mesh”具有更低的成
本，但是部分通信pattern性能不能对齐Switch架构，所以不列入比较）。从成本分析来看： 1）
铜缆覆盖范围内（64或128 xPU），铜缆方案的整体成本大约是光互连方案整体成本的
1/2（按照互连成本+Switch成本的综合），铜缆占优；2）超过铜缆覆盖范围的场景（>128
xPU），采用传统单层光互连方案要比2层（铜+光）方案的成本更低。由此可见，为了扩展
Scale up 的规模，采用单层光互连是比较好的选择，但是光互连方案的成本仍然相对高，在此
基础上如何进一步降低光互连的成本是一个关键挑战。
图1. Switch交换架构下不同规模采用不同互连方案的成本对比（相对值对比）
关于光互连的可靠性挑战。网络系统的可靠性本质上是对网络传输错误的容忍和恢复处理能
力，主要分为两大类问题。第一类是对链路信号质量问题产生的错包进行纠错和恢复，这类问
题的处理业界有比较成熟的解决方案，比如FEC、LLR进行链路级报文错误的恢复和重传；第
二类是对链路故障和交换节点故障造成的inflight丢包进行响应和恢复，这类丢包无法通过FEC
或LLR进行恢复，需要端到端的重传机制来恢复。端到端重传与具体GPU架构及其协议实现强
相关，所以不在本文中讨论。更核心的问题，当我们在考虑更大规模的 Scale up 系统时，规模
变大天然使得这两类错误的发生概率增加，系统的MTBF会显著减小（规模扩大10，MTBF缩 小
10倍），所以针对大规模 Scale up 架构可靠性设计的重心应该转移到面向更好容错的系统 架构
上，并在此基础上兼顾互连本身的可靠性。此外，互连系统的可靠性还需要考虑生产良率和运
维代价，实际落地过程中我们看到高密度铜互连的cable tray和连接器在这方面有不小的挑战
。基于线上运行大数据统计，铜缆互连的链路故障概率是基于FRO（带DSP）光互连概率的1/6
（见下文表6），如何提升光互连链路的可靠性是 Scale up 系统扩展的另外一个关键挑战。
此外，随着xPU算力和显存HBM的不断扩展，每GPU的 Scale up 带宽也在逐步扩大，比如
NIVIDA GPU 的NVLink带宽跟随GPU架构逐代增长，从A系列到最新的B系列，NVLink带宽
增长3倍，最新Blackwell系列GPU已经做到
需要消耗更多的计算资源，比如DeepEP实现中，网络传输需要占据15%的GPU计算资源。所
以，如何设计更好的网络传输语义和在网计算能力，减少网络通信过程中的算力消耗是另外一 个
xPU Scale up 系统设计需要面对的挑战。
4. 阿里云 UPN512 架构概览
如上文所述，随着算力超节点的演进，xPU Scale up 域不断扩展，需要有新系统架构设计来
解决上述可能遇到的问题和挑战，包括光互连的成本、可靠性，以及大带宽通信过程中的算力 消
耗。为此，阿里云提出UPN（Ultra Performance Network）Scale up 网络系统，继承HPN（
High Performance Network）Scale out 网络的设计理念，将“大规模、高性能、高可靠、低成
本、可扩展” 的设计思路应用到 Scale up 网络域，解耦当前 Scale up 设计对于高密系统（类“
小型机”）的依赖。
图 2. HPN 与 UPN
图3. HPN 和 UPN 组成的高性能系统
UPN架构的主要设计基于如下三点：
1、基于 High Radix 以太网。以太网生态成熟强大，单层设计可以做到最大512 xPU系统
（未来支持到1K及以上），规模大、可扩展。
2、采用LPO/NPO光互连。通过光互连实现规模扩展，同时解耦高密机柜依赖（“小型机”-
>“X86”），降低高密系统高复杂度带来的稳定性和运维挑战。阿里云在光互连方面的技 术
积累和方案选择，预计实现光互连成本30%以上降低，可靠性提升约3倍以上，使得低 成
本、高可靠的光互连方案成为可能。
3、基于单层交换的协议设计。单层交换设计可以使网络协议设计尽量简化，在此基础上扩展
定义网络通信语义和在网计算，聚焦高性能的网络通信并降低计算资源的消耗。
本文阐述UPN512系统的关键架构设计。
5. UPN512 系统设计和关键组件
系统架构
AI Rack-铜互连紧耦合系统
以NVL72为代表的AI Rack架构充分利用了铜互连高可靠、低成本、低时延的优势，将xPU通
过高密线缆组件和交换芯片在机柜内进行互连组网，同时针对这样的高功耗系统配套了高能效
的集中供电系统和液冷方案，以机柜为单位可整体交付和部署，是当今主流的超节点系统方
案。
AI Rack架构是构建百卡规模超节点的业界常规方案，但是也存在一些问题和局限性：
1、 AI Rack 架构基于铜缆互连，由于铜互连需要在一定距离内才能保证性能，因此AI Rack架
构需要将算力资源做到极致的紧凑，这样对系统的设计带来了非常大的挑战，比如高密铜
互连方案带来的可制造性上的困难，高功率密度带来的供电和制冷方案的挑战，高度物理
耦合的系统对于故障率和运维带来的挑战。
2、百卡以上至千卡的scale up域，由于距离限制，铜互连已经无法覆盖，需要考虑光互连的方
案。
UPN512-单层光互连解耦系统
图4. 单层光互连系统
UNP512利用光互连连接XPU和交换机，通过单层CLOS网络实现512个xPU的全互连（见图4
）。xPU芯片和Switch芯片通过光电引擎(OE)实现光电转化，从而利用光纤互连。理论上， 光
电引擎的具体形态可以是可插拔光模块如FRO(Fully Retimed Optics)、LPO（Linear-
drive Pluggable Optics），也可以是近封装光模块NPO（Near-packaged Optics）或是共封装光
引擎CPO（Co-packaged Optics），考虑到互连密度、成本、稳定性等因素，LPO和NPO是
UPN512系统的优选方案，下文详述。
图5. UPN系统布局
设备物理形态上，由于光互连打破了距离限制，UPN512可以最大化地解耦设备和机柜，xPU
和交换机都能够回归盒式的设备，同时机柜也没有了限制，常规标准机柜即可支持部署。
全光互连
区别于AI Rack方案，UPN512采用全光互连代替铜互连。铜互连受限于连接的距离，通常限
制在一个机柜内，而光互连可以轻松覆盖几十米、几百米甚至更远，不同互连介质可以覆盖的
距离如下表1。
介质/形态 100G/lane 典
型覆盖距离
200G/lane 典
型覆盖距离
适用
无源铜缆 DAC 2 m 1m 单柜-AI Rack
有源铜缆ACC(均衡/放大，无重定时) 5 m 3m
有源AEC(带重定时的主动电缆) 7 m 5m
2～4柜-AI
Rack
光模块–MMF（VR多模） 50m 50m
光模块–MMF（SR多模） 100m 100m
光模块–SMF（DR单模） 500m 500m
多柜-UPN512
光模块–SMF（FR） 2km 2km /
表1. 不同类型的互连方案
在通用计算和xPU scale-out网络上，FRO（带DSP的可插拔光模块）是光互连的主流方案。
Scale up 网络由于新的特点和要求，对于光互连方案的选择需要重新考量。
（1） 带宽密度
xPU的scale-up网络带宽远大于scale-out网络带宽，以英伟达的xPU为例，scale-up的带宽 是
scale-out的9倍，几乎是一个数量级的差别。更大的互连带宽意味着更多的光纤通道和更大 的光
电引擎的带宽。当xPU带宽增大时，可插拔模块在带宽密度上会有受限。以典型的
scale-up xPU为例，带宽需要8个OSFP形态的800G可插拔模块，4个xPU 仅考虑 Scale
up 光接口就需要消耗掉至少1U的面板空间。如果是 Scale up XPU，则需要16个
OSFP可插拔模块，4个xPU的scale-up光接口需要消耗掉2U的面板空间。 在一定的 Scale up
互连带宽要求下，相比可插拔模块，NPO/CPO由于本体不占用设备面板空间，且带宽密度更高，
能够为系统设计提供更大的灵活性。
（2） 时延、可靠性、成本、功耗
Scale up 网络对于时延、可靠性、成本、功耗更为敏感，对于几种光互连方案
● FRO光模块在光电引擎外增加了DSP来支持更加恶劣的电通道和光通道，但DSP也导致了时
延、功耗、成本的增加，同时降低了光模块的整体可靠性，不适合 Scale up 场景。对于
Scale up 场景的光互连方案来说去掉DSP采用线性直驱是强诉求。
● LPO是可插拔模块形态的线性直驱模块，去除DSP，成本降低约30%，但非常依赖模块和
主芯片之间电通道性能以及主芯片的SerDes能力，系统设计上通常需要针对LPO做较大适
配和妥协以保证通道性能，适用于主芯片SerDes能力较强，芯片带宽适中的应用。LPO具 备
可插拔、低成本、标准化、多源性等优点，在系统和主芯片能够满足LPO性能的情况下 是
UPN512光互连的可行方案。
● NPO能够靠近主芯片，能够降低对于主芯片SerDes的驱动/均衡能力的要求，对系统和主 芯
片的依赖性较小，更容易支持线性直驱。带宽密度上相比LPO更高，成本更优，并且天然
和主芯片解耦，容易标准化，是比较适合UPN512的光互连方案。
● CPO相比NPO更加靠近主芯片，但是由于和主芯片合封，标准化和多源性差，是UNP512 需
要追求极致性能时的一种可选方案。
对比维度 FRO LPO NPO(Linear) CPO(Linear)
线性直驱 否 是 是 是
可插拔 是 是 否 否
单体可靠性 低 中 高 高
带宽密度 低 低 高 高
时延 高 低 低 低
功耗 高 低 低 低
成本 高 低 低 低
标准化程度 高 高 高 低
主芯片耦合 无 无 无 是
对设备方案
及主芯片性
能依赖性
一般 强 弱 弱
表2. 几种光互连技术的优缺点
（3） 系统可靠性和可用性
大多数 Scale up 网络采用内存语义，其对通信通道的闪断或者中断较为敏感，我们将其称为对
系统可靠性的要求。硬件故障不可避免，当故障发生时需要快速更换和恢复，尽量减少故障 组件
离线的影响面也很重要，我们将这部分能力称为可用性。下面比较 LPO/NPO/CPO 技术选择
对可靠性和可用性方面的考虑。
● 从可靠性角度，NPO/CPO方案的电通道极短，连接界面少，信号完整性显著改善，并且将
故障率高的光源和光电引擎解耦，单体和单链路的可靠性更高。而可插拔模块连接界面多
（主板连接器、笼子、模块、外部跳线），潜在接触不良、污染、插拔磨损、ESD等失效
模式，并且电通道走线更长，信号完整性相比NPO/CPO要差，单体和单链路的可靠性不如
NPO/CPO。
● 从可用性角度，UPN512架构本身的解耦设计是高可用设计的一部分，这使得故障单体的
影响面更小，更换效率更高。此外，从光互连的技术选型上，可用性受单体的故障率和单
链路的更换速度影响。
● 可插拔模块LPO
● 特点：支持端口级热插拔，单端口/单模块故障可快速独立更换，MTTR（Mean
Time To Repair）分钟级，影响域小。
● 结论：即便 MTBF（Mean Time Between Failures） 略低，因 MTTR 很短、故
障域小，单端口/单链路可用性通常更高。
● CPO/NPO
● 特点：单体 MTBF 往往更高，但一旦故障，常需更换设备（影响其他链路），
MTTR 小时级，影响域大。
● 结论：需要强健的端到端系统容错能力，比如网络单体不存储系统的状态信息，
同时冗余设计可以保证部分网络节点在损失的状态下仍然可以正常运行等，通过
这些高可靠高可用架构设计弥补较长 MTTR 和较大故障域对上层业务的影响。
单层千卡域
单层网络相比多层网络能够做到最简拓扑和最短时延。实现单层千卡需要突破两大物理限制：
（一）距离限制。采用光互连突破了距离的限制，使得scale up域不再局限到一个机柜内，百卡
、千卡xPU可以分布到多个机柜内。
（二）芯片限制。交换芯片的Radix决定了网络规模的上限，单层CLOS架构所能接入的xPU数
量等于交换芯片的Radix。当前业内以太网交换芯片最大的Radix是512，而下一代会达到1024
甚至更高。这就意味着用以太网交换芯片单层组网可以轻松构建512及以上的 xPU Scale up
规模。
表3. 基于Ethernet单层互连的 Scale up 规模
解耦设计
当前AI Rack设计为了利用铜互连，整个硬件系统做到了极致紧凑和耦合，具体体现为：
● 采用cable tray高密线缆背板来连接xPU和Switch，线缆背板本身的生产良率提升困难，一
个链路损坏后就需要更换整个cable tray，上线后的故障影响面大，问题分析和部件更换时间
长。
● 为了压缩互连距离，xPU节点和Switch节点的尺寸也被极致压缩，比如NVL72的4个xPU
就被限制到了1RU高的tray内，节点内器件的布局、散热、供电难度提升。
● 节点和机柜紧耦合，数据中心和机房建设的时候就需要考虑特定的机柜方案的适配。
UPN512通过光互连实现了设备盒式化并且与机柜解耦，具体对比如下。
对比维度 AI Rack(紧耦合机柜系统） UPN512(盒式化，完全解耦)
设计和制造复杂度 ● 基于高密线缆和高速背板/中
板/正交连接的系统，托盘(节
点)、背板等各个组件之间高
度耦合，装配公差与一致性的
要求很高，系统设计复杂。
● 高密铜缆连接组件的生产良率
提升困难，NPI/量产周期长、
工艺门槛高。
● 盒式设备，设计难度小。
● 盒式设备，生产良率提升快，NPI
周期短。
部件供应 ● 高密线缆和高速背板/中板/
正交组件通常各供应商设计
无法兼容，供应、产能容易
受限。
● 光互连组件标准化程度高，多源供
应链成熟。
故障域、运维 ● 高密线缆和高速连接组件为一
体件，单链路故障常需更换整
件，影响面大。
● 更换组件需整体停机，多人工
配合，MTTR高
● 故障可按设备/模块/端口/光纤细粒
度隔离、更换，并且易于做N+1备
份与旁路，降低故障影响。
● 细粒度组件更换时间短，MTTR低
。
供电与散热挑战 ● 设备空间受限导致极致功率密
度与受限风道（如 NVL72 将
4 xPU压至1RU托盘），高密
铜缆遮挡气流，需液冷/高转
速风扇。
● 大电流母排带来供配电可靠性
挑战。
● 热负载分散至多个盒式设备，盒式
设备空间和风道设计自由度高，可
按设备职能和部署条件分别采用风
冷、液冷。
● 可支持传统分布式供电，单点电气
风险低。
机房与部署条件 ● 与机柜/供冷/供电强绑定，需
专用机柜与设施；上线需一次
性整体规划，后期改造空间
小。
● 单柜功率高，对机房能力要求
高。
● 与机柜解耦，可用标准19英寸机
柜；设备位置灵活。
● 光互连距离充裕，便于空间规划和
灵活调整。便于分期建设与滚动升
级，降低土建/配电/冷却一次性门
槛。
表4. UPN512设计解耦对“高密”的依赖，“小型机 -> X86”
光互连概览
本章对UPN架构所使用光互连技术进行概览介绍。如上文所述，综合考虑几种光互连技术的成
本、时延、功耗、可靠性、带宽密度等因素，LPO/NPO是当前最适合用于 Scale up 光互连的
技术，适用于不同的场景选择。
可插拔光互连方案
传统的光互连技术方案以可插拔光模块为主，有传统带重定时的可插拔光模块（FRO，Fully
Retimed Optics）以及新型的线性可插拔光模块(LPO，Linear Pluggable Optics)，可插拔光模
块是完全开放解耦的技术路线，即插即用，有着非常繁荣的生态，能够满足多样化的应用 需求。
图6. 可插拔模块FRO和LPO
传统可插拔模块中由于FRO模块中有DSP，可以恢复衰减的电信号，但DSP模块功耗大、时延
大、成本高，并不适合 Scale up 场景。相比而言，LPO（Linear Pluggable Optics）光模块去
除了DSP（数字信号处理器）芯片，在功耗、时延、成本方面有显著的收益。同时受益于新 一
代强大的Digital Serdes能力，LPO在性能方面显示出和传统带重定时DSP的光模块处于同等
水平。阿里云已经在 Scale out 网络中实现了400G DR4 LPO光模块的规模部署，显示出优异的
性能和稳定性。
图7. 800G OSFP LPO光模块结构示意图
高密带宽光互连方案
近年来，光互连速率越来越高，高速信号完整性问题和功耗问题催生了新的光互连概念，包括
共 封 装 光 互 连 CPO（Co-packaged Optics） 和 近 封 装 光 互 连 NPO（Near-packaged
Optics），它们的技术形态分别如下图8所示。
图8. NPO和CPO
NPO和CPO的区别在于是否把光引擎OE（Optical Engine）和交换芯片封装在一起，封装在一
起的是CPO，没有封装在一起而只是把OE靠近交换芯片放置并焊接在PCB板，通过PCB板进 行
高速信号连接的是NPO。CPO和NPO的都是通过把光引擎OE尽量靠近交换芯片，从而减少信
号衰减，同时实现更高带宽密度的作用。CPO由于共封可使得高速信号损耗更低，是极致形 态
，但是需要依赖芯片厂商实现，会造成产业生态封闭，不适合系统解耦，而NPO则可以把光 引擎
OE和交换芯片解耦，同时能够很好地利用现有的光模块产业，在实现难度和供应生态上 来说更
具备可行性。
NPO光模块采用OIF标准封装，通过LGA连接器实现可拆卸，可替换。当前的NPO光模块速率
是（ PAM4）收发一体，未来可升级至()。
图9. OIF NPO模块示意图
NPO模块架构和LPO类似，采用线性直驱的技术方案，模块内部没有使用DSP（数字信号处理
器）或CDR（时钟重定时）Retimer 芯片，相比FRO模块，LPO/NPO可以减少50%功耗，同时
降低降低 110ns 时延。模块的光芯片可以采用VCSEL、硅光、甚至EML技术，从底层芯片供应
上形成一定的技术竞争和供应链互补。
LPO/NPO 场景和方案的选择
LPO是可插拔光模块形态，尺寸较大，在硬件设备里占据较大的空间（包括前面板空间和设备
内部空间）。前面板接入带宽密度：以400G QSFP112 LPO光模块为例，1U前面板空间最多
只能放40个，实现16T的带宽接入；以800G OSFP800 LPO光模块为例，1U前面板空间最多放
32个，实现的带宽接入。NPO模块只有外部光源模块ELSFP（ External Light Source
Form Factor）需要占用一些前面板空间，但是光口可以采用高密光接口，最高可做到1U前面板
容纳2K～3K纤芯，按照112G per lane计算，1U理论接入带宽可达200T～300T，远超可插拔光模
块，面板空间不会成为带宽密度的瓶颈。
设备内部空间带宽密度：如下表所示，QSFP112占用系统内部空间体积大约是OIF NPO的
倍， NPO的带宽是400G QSFP112 LPO的8倍，NPO带宽密度是400G QSFP112 LPO的
12倍；OSFP800占用系统内部空间体积大约是OIF NPO的2倍， NPO是800G OSFP800
LPO模块带宽的4倍，NPO带宽密度是800G OSFP800 LPO的8倍。
长（mm） 宽（mm） 高（mm）
体积
（mm3）
综合体积
QSFP112 61 19 10 11590 11590
OSFP800 91 24 15 32760 32760
OIF NPO 35 24 6 5040
ELSFP 100 22 10 22000
5040+2200
0/2=15020
（*）
*按照1个ELSFP驱动2个NPO来计
算表5. 不同光模块的体积对比
LPO只能放在设备的前面板，靠两边的端口和系统内部芯片（如xPU、Switch芯片）的距离较
大而导致高速PCB走线偏长，高速电信号的损耗较大，这对于芯片的serdes能力要求就极高； 但
NPO是在系统内部，可以布放到芯片的周围，这样高速PCB走线可以控制的很短，高速信号 的
损耗小且较一致，这对芯片的serdes能力要求相对要低很多。NPO模块在设备内部可以根据 网络
架构的需要灵活组合光纤通道来实现不同网络连接拓扑，设备外部不需要shu∗e box， 从而可
以简化设备外部布线，提高光链路的链路布线稳定性。
所以LPO和NPO作为UPN网络的两个选项，可以应用在不同的场景。当 Scale up 带宽需求不高
且芯片serdes能力较强的时候，可以选择LPO方案。未来带宽密度高或者芯片Serdes能力不 足时
可以选择NPO方案。
LPO/NPO 成本
LPO和NPO部署规模尚未到达FRO的量级，可以根据成本结构大致推断其成本区间。LPO相比
于目前已知成本的传统带重定时的可插拔光模块FRO，去除了DSP芯片，成本降低幅度约
30%。NPO比LPO紧凑和小型化，单位带宽的硅光芯片面积更小，所以按硅光芯片的面积和其
他关键物料的成本对比，NPO光模块的成本预计比LPO光模块再低约10%。总体上，相比传统
FRO模块，LPO/NPO技术在光成本上降低30%~40%的成本使得整体解决方案的网络成本（光
互连+Switch）降低（如下图10），并且将来随着产业生态的进一步成熟丰富，网络成本将进
一步降低。
图10. UPN架构通过LPO/NPO实现光互联成本的降低
互连稳定性
LPO和NPO技术所使用的关键器件和传统的FRO可插拔光模块相似，去除了DSP芯片，在物料
清单上更简洁，失效点少。与传统FRO模块相比，不存在异厂商DSP之间的互通问题，理论上
LPO/NPO的互连互通兼容性问题会得到改善。阿里云规模部署LPO模块已经超过一年时间，
通过分析LPO模块与传统FRO模块的稳定性数据，我们发现LPO的链路稳定性有较大提升，并
接近铜缆。
FRO LPO 铜缆
月化抖动链路比例 ~6x ~2x 1x
表6. 光互连和铜互连的稳定性对比
UPN512架构采用的低时延传输方案基于ETH+协议，详细协议设计见《高通量以太网协议标准
（）》。根据xPU自身特性，UPN512提出三种不同的低时延语义：面向内存的
传输语义
Load/Store语义，面向消息的Send/Recv，以及针对大模型场景网络通信优化的张量
（Tensor）Push/Pull语义（可选增强）。
操作方式 介绍
LOAD 内存语义发送，从本地或远端内存中向寄存器加载数据
STORE 内存语义接收，从寄存器向本地或远端内存中存储数据
SEND 消息语义发送，从本地内存向远端内存搬移数据
RECV 消息语义接收，从远端内存向本地内存搬移数据
PUSH 张量语义发送，从本地内存和寄存器向远端内存寄存器搬移张量
PULL 张量语义接收，从远端内存和寄存器向本地内存和寄存器搬移张量
表7. Scale up 网络通信语义
内存语义是一种由处理器直接驱动的同步内存访问机制。在典型的 xPU 或 CPU 架构中，
Load 和 Store 指令由执行单元主动发起，用于访问本地或远端地址空间中的数据。每条指令通
常传输 32~256 字节的数据，具备访问粒度小、控制精度高的特点。该语义由计算核心内部如
LSU（Load/Store Unit）模块直接生成，并通过协议的语义适配层转换为内存操作请求， 最
终通过网络完成目标数据的获取或写入。这类语义广泛应用于状态同步、控制变量读写、分 布
式信号处理、以及小块数据的搬运等场景，对通信时延和顺序一致性具有较高要求。由于每 次
访问所需数据量有限，Load/Store 操作在并发大量请求时会消耗一定的核心算力，但其实现路
径简洁，响应延迟极低，适合用于控制通路、轻量同步或实时决策路径。
消息语义是一种异步、不受计算模块硬性控制的数据搬运机制，通常由专用的数据传输引擎
（如 DMA Engine、TMA、RDMA Core）在后台执行。 DMA 语义用 SEND 和 RECV 两种
操作表示，分别表示将本地数据块异步写入远端设备，或从远端地址读取数据至本地。在实际系
统 中，这类操作适合传输数 MB 到 GB 级别的大块张量或模型权重，通常用于 AI 训练过程
中的前向传播结果同步、梯度合并或参数写回等场景。DMA 操作由软件或调度器生成描述符
，通过门铃（Doorbell）机制启动，协议栈接收描述符后完成数据的拆分、调度与可靠传输。由
于 DMA 操作不依赖于计算核心直接参与执行，能够显著减轻核心负担，提高并行计算与通信
的重叠效率，是高吞吐系统架构中不可或缺的基础能力。
张量语义是一种 UPN512 首先提出的，面向大模型应用针对性优化的传输机制。张量定义
为，最小的可以参与模型计算的连续的数据。大模型应用在xPU间传递消息的绝大部分是以张
量为基本单元的数据块。如在混合专家模型训练任务中，使用专家并行训练方式引入的
Dispatch和Combine集合通信的基本传输单位就是模型隐藏层大小（hidden size）张量。主
流大模型通信时，张量大小在几到几十KB之间。使用内存语义通信会带来显著的xPU算力开
销，而使用消息语义会引入较高的启动开销，需要应用进行针对性的优化（如数据重排）。因
此，UPN512 提出对1-100KB的数据块的传输，即张量语义，进行针对性的优化。
大模型应用对张量的传输存在如下的特点：
1. 确定性。张量的大小，在模型，及应用的并行设置确定后，即确定下来。如专家并行引入
的Dispatch集合通信会收发整数个隐藏层大小的张量，张量并行引入的AllReduce集合通
信会收发整数个（隐藏层大小/张量并行大小）的张量。
2. 整体性。应用要求一个张量的全部数据完整到达，才能进行后续的矩阵运算。
3. 灵活性。一个张量内，不同字节的到达顺序，不影响应用的正确性。
4. 独立性。通常来说，在一次集合通信中，不同张量的到达顺序不会影响后续操作的正确
性。
针对上述特点，UPN 架构提出的张量语义提供如下能力：
1. 异步IO：对应用的发起方，张量语义提供异步IO能力。即IO模块会立即确认PUSH/PULL指
令的成功失败，无需等待操作的完成。操作的正确性由IO模块和网络的可靠性机制保证。
异步IO可以显著降低核心算力的开销，提升算力的利用率。
2. 批量/流式传输：对应用的发送侧，张量语义提供批量和流式，两种消息传输方式。
a. 批量传递将多个张量汇总，统一提交，当所有的数据到达接收侧后，通知接收侧，同
时向发送侧确认操作完成。用于计算通信顺序依赖的应用场景。
b. 流式传输会独立追踪每一个张量的传输情况，在每一个张量的数据全部到达后，立即
向接收侧发送通知，同时向发送侧确认（可累积）。接收侧在收到一整个张量之后，
可以决定是否立即发起后续计算，用于计算通信细粒度交叠应用场景。
3. 显式/隐式消息确认：对应用的接收侧，张量语义提供显式和隐式两种消息确认方式。
a. 显式消息确认方式下，需要收侧主动调用张量接收API，当API返回时，代表部分/全部
张量到达。
b. 隐式消息确认方式下，需要收侧指定显存地址，当收侧IO模块收到部分/全部张量时，
修改该显存地址确认到达。收侧需读写取该显存地址，确认张量的接收情况
4. 最小化张量传输延迟：网络侧提供最小化每个张量传输延迟的优化，包括但不限于：
a. 在流式传输方式下，网络侧会将每个张量的数据均匀的按照多路径分散，在每个路径
中按照相同张量顺序发送，以最小化每一个张量的传输延迟。每一个张量在每一条路
径上会最小化对应的网络数据包数量（如1个），以最小化消息重传的代价。
b. 收侧IO模块会独立记录每一个张量对应的数据包的到达及内存写入状态，当每一个张
量对应的数据完整写入接收侧显存后，会立即显示/隐式通知收侧，无需发侧再次进行
确认。
5. 动态压缩：根据用户需求，硬件可以利用LogFMT等格式进行张量的压缩/解压缩，降低传
输时间的同时减少计算开销。
6. 在网计算：网络提供张量感知的原生在网计算能力。端侧IO模块和网内交换机配合，对应
用层提供常见集合通信（包括但不限于AllReduce，AllGather，AllToAll，Dispatch，
Combine）的在网计算加速能力，降低网络IO次数，降低网络传输数据量，降低集合通信
完成时间。
在网计算
随着 Scale up 网络域越来越大，单 xPU 的 Scale up 带宽、显存也在扩大，数据传输所消耗的
计算资源也会越来越多，通过通信语义优化和在网计算，可以有效提升数据传输效率并降低 计
算资源消耗。
在网计算是一种利用网络设备对集合通信进行加速的技术，比如在交换机上做数据的计算聚
合。在网计算可以显著加速AllReduce类集合通信的完成时间，也可以显著降低
ReduceScatter、AllGather、Dispatch、Combine等集合通信的显存带宽/计算资源开销。 同时
，也可以加速Broadcast和Reduce，提供对称内存等能力。
目 前 ， 业 界 成 熟 的 在 网 计 算 方 案 主 要 以 Nvidia 的 SHARP (Scalable Hierarchical
Aggregation And Reduction Protocol)为主，但SHARP需要IB网卡与IB交换机的支持。UPN 架
构基于以太网，对下一代在网计算进行如下定义：
在交换芯片方面，下一代以太网交换芯片需要满足“可计算”的能力。交换芯片可以通过计算 引
擎提供在网计算能力，支持以 INT32/Float8/Float16/Float32/BFloat16为主的数据类
型，支持以Min/Sum/Max为主的计算类型，支持MMU（Memory Management Unit）到计算
引擎的精细流控。
图11. 交换机在网计算引擎
在协议方面，目前Scale-up协议呈现百花齐放的状态，我们提出与协议解耦且通用的在网计
算标准，任何基于以太网的Scale-up协议均可以通过支持“扩展计算头”，搭配可计算ASIC， 实
现内存语义级别的在网计算能力。
图12. 协议解耦的在网计算（标准制定中）
在通信标准方面，按照集合通信收发侧数据量的规律，分为对称集合通信和非对称集合通信。
对称集合通信（如AllReduce，AllGather）中，发端可以通过收端显存起始地址和发端当前张
量偏移量，独立确认每一个张量在收端显存的地址。如在AllGather中，假设每个xPU发送
m 个，大小为 x 的张量，xPU i 的收侧显存起始地址为 Ai ，那么当xPU j 向
xPU
i 发送的
第 k 个张量时，发端可以独立确认其收端显存地址为 Ai + m ∗ x ∗ j + k ∗ x 。
非对称集合通信（如Dispatch/Combine）有如下的特点：
● 发端和部分收端通信，每一次通信的收端xPU集合有可能不同；
● 发端发送至每一个收端的通信量不均等，每个发端无法独自确认每一个张量的显存地址；
● 当一个张量被复制到多个xPU时（如Dispatch集合通信），因为不同收侧xPU接收的数据
量也不同，该张量在不同xPU上的多个拷贝的偏移量也会不同。
集合通信的对称性会影响在网计算的方案。
对称集合通信的在网计算流程如下
1. 在集合通信建立阶段，参与集合通信的xPU共同协商一个虚拟显存地址 VG ，在交换机中
注册集合通信组ID，配置组播组成员；
2. 在每一次集合通信开始前，每一个收侧xPU各自建立虚拟地址和集合通信结果输出地址之
间的映射关系；
3. 根据集合通信类型的不同，发侧使用PUSH和PULL两种不同语义，交换机相应的提供不同
的在网计算加速能力：
a. 对于Broadcast类集合通信（如Broadcast，AllGather）：发侧使用PUSH操作，将张
量发送至交换机，交换机将报文广播至所有其他xPU；
b. 对于Reduce类集合通信（如Reduce、AllReduce、ReduceScatter）：收侧使用 PULL操
作，从其他xPU中获取张量。交换机将PULL请求广播至所有xPU，发侧交换机 将张量
发送至交换机，交换机将返回值暂存，当交换机获取全部张量后，进行Reduce
操作，再将汇总结果发送至收侧xPU。特殊的，AllReduce可以转化为
ReduceScatter+AllGather，一次PULL，一次PUSH操作的耦合；
4. PULL/PUSH操作中，目的地址基于虚拟地址的张量偏移量生成，由于对称集合通信的特
性，每个发侧可以独立计算目的地址；
5. 收侧xPU将报文指向的虚拟地址翻译成真实显存地址，存入显存中。
XPU
Broadcast
Switch
发侧发送写请求
解析GPU编码，
∗播到∗的GPU
写∗显存地址 V_G + k*x
XPU
Reduce
收侧发送读请求
解析GPU编码，
∗播到数据源
GPU
读取显存地址V_G + k*x
存储数据，执∗聚
合
收侧接收结果
图13. 对称通信在网计算通信过程 (以Broadcast和Reduce为例)
在非对称集合通信中，因为同一张量在不同收侧xPU上的偏移量不同，不能继续沿用上述流
程。采用如下流程实现非对称集合通信的在网计算
1. 在集合通信建立阶段，参与集合通信的xPU共同协商一个虚拟显存地址 VG ，每个成员维
护一个计数器 T ，在交换机中注册集合通信组ID，配置组播组成员；
2. 每一次集合通信开始前，每一个xPU清除计数器 T
果输出地址之间的映射关系；
，并且各自建立虚拟地址和集合通信结
3. 对于Dispatch集合通信，发侧xPU i 使用PUSH语义，将每一个张量，以及目的xPU的编
码，一起发送到在网计算交换机上，第 k 个张量传递的目的显存地址，指向 VG + k ∗ x
。交换机依照报文中目的xPU编码，组播到相应的目的xPU上。收侧xPU j 将张量写入地
址 VG + T ∗ x ，记录 i ， k ∗ x 和 T 的映射关系，将计数器 T 做原子单增操作；
4. 对于Combine集合通信，收侧xPU i 使用PULL语义，将想要接收的张量信息，以及目的
xPU的编码，一起发送到在网计算交换机上，第 k 个张量传递的目的显存地址，指向
VG + k ∗ x 。交换机依照报文中目的xPU编码，组播到相应的目的xPU上。发侧xPU j 查
询上一次Dispatch集合通信记录的映射关系，获取发侧真实显存地址，将对应张量发送至 交
换机。待交换机收到全部张量后，进行汇聚操作，再将汇总结果发至收侧xPU。
图14. 非对称通信在网计算通信过程 (以Dispatch和Combine为例)
