DPU 与 Spectrum-X：把网络卸载到卡上

网卡开始跑自己的操作系统

一张普通网卡的职责是收发包。DPU（Data Processing Unit）在网卡上加了三样东西：

ARM CPU 核        ← 能跑一个完整的 Linux
网络处理引擎      ← 硬件加速的转发、封装、匹配
专用加速器        ← 加密、压缩、存储协议卸载

于是它不再是"设备"，而是一台独立的小服务器插在你的服务器里。 这个变化对运维的影响比对性能的影响更大。

能卸载什么

收益的本质是把"基础设施的开销"从业务 CPU 上挪走。 在虚拟化与多租户场景里，这部分开销可能占掉几个核——卸载掉就是净收益。

两种工作模式

这一点决定了它在架构里的位置：

第二种模式是零信任架构的关键：即使主机被完全攻破， 攻击者也改不了网络策略——策略在 DPU 上，主机没有权限。

传统：  [ 主机 root ] → 控制网卡、iptables、路由
DPU：   [ 主机 root ] → 只能用网络
        [ DPU 管理面 ] → 决定这台主机能通什么

Spectrum-X：端网协同拿确定性

DPU 之外，另一条相关的产品线是把网卡与交换机作为一套系统来设计。 IB vs RoCE 那节提过它的定位： 在以太网上拿到接近 IB 的确定性。

从实践中的 NCCL 配置能直接看出"配套"的含义：

NCCL_NET_PLUGIN=spcx                    # 专用网络插件
NCCL_IB_ADAPTIVE_ROUTING=1              # 自适应路由
NCCL_NCHANNELS_PER_NET_PEER=4
NCCL_P2P_NET_CHUNKSIZE=262144
NCCL_IB_PORT_SPEED=800000
NCCL_MIN_NCHANNELS=32
NCCL_IB_HCA=roce_vf_rail                # VF rail 模式

它解决的核心问题是以太网的静态哈希导致链路不均—— 多条大流哈希到同一条 spine 链路上，其它链路闲着， 表现为 AllReduce 的尾延迟很差（拓扑那节 讲过）。

什么规模值得引入

DPU 与 Spectrum-X 都属于"规模到了才划算"的技术：

判断标准很朴素：省下的 CPU 核数 × 机器数，能不能覆盖 DPU 的采购与运维成本。 小规模基本覆盖不了。

运维上的三个新增负担

引入 DPU 之后，多了三件以前不用做的事：

① 它也要打补丁

DPU 上跑着完整的操作系统，意味着：

# DPU 上的固件与 OS 版本
# （通过 BMC 或 DPU 自己的管理接口查询）
mlxfwmanager --query          # 固件版本
# DPU 内部：ssh 到 DPU 的管理地址后
uname -a; ofed_info -s

固件、DPU OS、主机驱动三者要版本匹配——升级时是一个矩阵，不是一条线。

② 它也会坏

DPU 故障的表现比普通网卡复杂：可能是网络不通， 也可能是网络通但策略失效、或者主机看不到存储设备。 排障时要多问一句"是主机侧的问题还是 DPU 侧的问题"。

③ 排障要跨两个系统

主机侧：ip link / ethtool → 可能只看到虚拟设备
DPU 侧：需要单独登录，用它自己的工具看真实的转发状态

这与 DPDK 那节 的教训类似： 能力增强的同时，可观测性的入口变了——原来的工具看不到全貌了。

检查点

这节课的落点

• DPU = ARM 核 + 网络引擎 + 加速器，本质是一台插在服务器里的小服务器
• 卸载对象：虚拟交换、加密、存储协议、网络策略、遥测；本质是把基础设施开销挪出业务 CPU
• 两种模式的区别在数据平面控制权；DPU 模式是零信任架构的关键
• 它带来的是信任边界迁移：多了一个要独立管理与审计的控制面
• Spectrum-X 是端网协同：解决以太网静态哈希导致的链路不均与尾延迟
• 配套方案的隐性成本是升级耦合与供应商锁定，选型时要显式算进去
• 引入门槛看规模：省下的核数 × 机器数能否覆盖成本；小规模基本不划算
• 三个新增运维负担：打补丁（版本矩阵）、会坏（故障形态更复杂）、跨系统排障