DPU 与 CPO：AI 时代的网络基础设施革命

从数据中心网络卸载到光电共封装，全面解构 AI 算力集群背后的两大关键技术支柱。

引言：为什么 DPU 与 CPO 成为 AI 基础设施的必答题？

当我们谈论 AI 训练集群时，目光往往聚焦于 GPU、TPU 等计算巨头。然而，真正的瓶颈往往藏在看不见的地方：网络、存储、安全、虚拟化等基础设施开销正在吞噬宝贵的算力资源。据统计，在传统的虚拟化数据中心中，CPU 可能花费 30% 甚至更多 的周期处理网络 I/O、存储协议、安全加解密、虚拟交换等任务，这些任务并非业务逻辑，却不可或缺。

这就是 DPU（Data Processing Unit，数据处理单元） 登场的背景。它像一名专职的"基础设施管家"，将 CPU/GPU 从繁琐的 I/O 与通信任务中解放出来。而当 GPU 规模从几百块扩展到上万块时，单机内部、机架之间、乃至数据中心之间的数据搬运量呈指数级增长，传统可插拔光模块在功耗、带宽密度、延迟上的劣势愈发凸显，CPO（Co-Packaged Optics，共封装光学） 应运而生。

DPU 解决的是"谁来处理数据"的问题，CPO 解决的是"数据如何以更低功耗、更高密度传输"的问题。二者共同构成了下一代 AI 网络基础设施的硬件底座。

一、DPU 深度解析：从 SmartNIC 到片上系统的演进

1.1 什么是 DPU？

DPU 是一种专门用于卸载数据中心基础设施任务的系统级芯片（SoC）。它不是简单的网卡增强版，而是集成了通用 CPU 核心、网络加速引擎、安全加密引擎、存储加速器、内存控制器、PCIe 接口与高速网络端口的完整计算节点。

可以将 DPU 理解为数据中心基础设施的"CPU"：

• 网络卸载：包处理、L2-L4 协议解析、虚拟交换机（OVS）、RDMA、负载均衡。
• 存储卸载：NVMe-oF、压缩/解压、纠删码、加密存储。
• 安全卸载：TLS/IPSec 加解密、防火墙、微分段、入侵检测。
• 虚拟化卸载：SR-IOV、VirtIO、设备模拟、Hypervisor 辅助。
• 可编程数据面：支持 DPDK、SPDK、P4、DOCA Flow 等框架。

DPU 的核心价值可以用一句话概括：让 CPU 做它该做的事，让 GPU 只负责训练/推理，让 DPU 接管一切基础设施工作。

1.2 DPU、SmartNIC 与 IPU：别再混淆

面试中常见的误区："DPU 就是智能网卡。"这是不准确的。SmartNIC 是 DPU 的前身之一，但 DPU 是更完整的片上系统，具备独立运行操作系统、处理复杂控制面与数据面的能力。IPU 与 DPU 在概念上高度重叠，更多是厂商市场定位的差异。

1.3 DPU 的典型内部架构

一个现代 DPU 的内部结构可以抽象为以下几个层次：

+-----------------------------------------------------+
|  管理控制面：ARM/ARM Neoverse CPU 子系统             |
|  （运行 Linux/DOCA/OS，处理控制面、管理面任务）       |
+-----------------------------------------------------+
|  网络加速引擎：包解析/RDMA/连接跟踪/NAT/VLAN/VXLAN   |
+-----------------------------------------------------+
|  可编程数据面：P4/DOCA Flow/Verbs 流水线             |
+-----------------------------------------------------+
|  安全与存储引擎：TLS/IPSec/AES/SHA、压缩、纠删码     |
+-----------------------------------------------------+
|  内存子系统：DDR/HBM 控制器、缓存一致性接口          |
+-----------------------------------------------------+
|  I/O 接口：PCIe Gen5/Gen6 x16、网络 PHY 25G/100G/   |
|            200G/400G/800G                           |
+-----------------------------------------------------+

DPU 与主机的连接通常通过 PCIe 实现。在 NVIDIA BlueField 等设计中，DPU 既可作为主机的 PCIe 端点（Endpoint）运行，也可以被配置为 Root Complex，实现对主机的带外管理、安全监控，甚至在主机 OS 崩溃时仍然保持网络可达。

二、DPU 数据流全景：数据包从网口到 GPU 的完整旅程

理解 DPU 的关键在于理解它的数据流。下面以一个典型的 AI 训练场景为例：GPU 节点通过 RDMA 进行梯度同步，数据包从外部网络进入，最终到达 GPU 显存。

2.1 传统 CPU 处理路径

在传统服务器中，数据包的旅程如下：

flowchart LR
    A[外部网络] --> B[NIC 网卡]
    B --> C[DMA 到主机内存]
    C --> D[内核网络栈]
    D --> E[软中断 / ksoftirqd]
    E --> F[协议处理 TCP/IP]
    F --> G[拷贝到用户态应用]
    G --> H[应用层 RDMA Verbs]
    H --> I[写入 GPU 显存]

这条路径的痛点显而易见：

• 多次数据拷贝：网卡 DMA 到内核内存，再拷贝到用户态，最后到 GPU 显存。
• 上下文切换：数据包到达触发硬中断、软中断、进程调度。
• 协议栈开销：TCP/IP 协议解析、校验和计算、连接状态维护。
• CPU 占用高：每个数据包都消耗 CPU 周期。

2.2 DPU 卸载后的数据路径

当 DPU 接管网络与 RDMA 处理后，数据流发生了根本性变化：

flowchart LR
    A[外部网络] --> B[DPU 网络端口]
    B --> C[DPU RDMA 引擎]
    C --> D[DPU 内部 DMA]
    D --> E[直接写入 GPU 显存或主机内存]
    E --> F[GPU 直接消费数据]
    G[DPU ARM CPU<br/>处理控制面/异常] -.-> C

关键变化：

• 零拷贝（Zero Copy）：数据包通过 DPU 内部的 RDMA 引擎，直接 DMA 到 GPU 显存或应用缓冲区。
• 内核旁路（Kernel Bypass）：数据面完全绕过主机内核，由 DPU 硬件处理。
• CPU 释放：主机 CPU 不再处理每个数据包，仅需处理连接建立、异常等控制面事件。
• GPU Direct RDMA：配合 NVIDIA GPUDirect RDMA 技术，DPU 可直接将数据写入 GPU 显存，实现网卡到 GPU 的最短路径。

2.3 虚拟交换机卸载示例

在 Kubernetes 或 OpenStack 环境中，虚拟机/容器之间的通信通常经过 OVS（Open vSwitch）。传统 OVS 运行在主机内核中，每个数据包都需要 CPU 参与转发。

flowchart TB
    subgraph 主机侧
        VM1[容器/VM 1]
        VM2[容器/VM 2]
        OVS[内核 OVS<br/>消耗 CPU]
    end
    subgraph DPU侧
        HW[硬件加速 vSwitch]
        ACC[流表加速引擎]
    end
    VM1 --> OVS
    OVS --> VM2
    VM1 -.->|卸载后| HW
    HW --> ACC
    ACC -.-> VM2

通过 DPU 的 OVS 硬件卸载（OVS Offload），流表被下推到 DPU 硬件中。对于匹配的数据流，后续数据包完全由 DPU 在硬件层面转发，主机 CPU 几乎不参与。这在 AI 推理服务中尤为重要：大量小流量请求涌入时，DPU 可以保证网络转发不抢占 GPU 推理所需的 CPU 资源。

三、DPU 编程模型与代码实战

DPU 的强大不仅来自硬件，更来自其软件生态。下面介绍三种主流编程框架，并给出真实可运行的代码示例。

3.1 DPDK：用户态高性能包处理

DPDK（Data Plane Development Kit） 是一组用于快速包处理的用户态库和驱动。它的核心思想是绕过 Linux 内核网络栈，将网卡直接暴露给用户态应用，配合大页内存（Hugepage）和轮询模式（PMD，Poll Mode Driver），将包处理延迟从毫秒级降到微秒级。

DPDK 的核心组件

示例：DPDK 基础收包程序

#include <rte_eal.h>
#include <rte_ethdev.h>
#include <rte_mbuf.h>
#include <rte_lcore.h>

#define RX_RING_SIZE 1024
#define TX_RING_SIZE 1024
#define NUM_MBUFS 8191
#define MBUF_CACHE_SIZE 250
#define BURST_SIZE 32

static const struct rte_eth_conf port_conf_default = {
    .rxmode = {
        .max_rx_pkt_len = RTE_ETHER_MAX_LEN,
    },
};

static int lcore_main(void *arg)
{
    uint16_t port = *(uint16_t *)arg;
    uint16_t nb_rx;
    struct rte_mbuf *bufs[BURST_SIZE];

    printf("Core %u handling port %u\n", rte_lcore_id(), port);

    while (1) {
        nb_rx = rte_eth_rx_burst(port, 0, bufs, BURST_SIZE);
        if (unlikely(nb_rx == 0))
            continue;

        for (uint16_t i = 0; i < nb_rx; i++) {
            struct rte_ether_hdr *eth_hdr;
            eth_hdr = rte_pktmbuf_mtod(bufs[i], struct rte_ether_hdr *);

            // 简单统计以太网类型
            uint16_t eth_type = rte_be_to_cpu_16(eth_hdr->ether_type);
            if (eth_type == RTE_ETHER_TYPE_IPV4) {
                // 处理 IPv4 包
            }

            // 释放 mbuf
            rte_pktmbuf_free(bufs[i]);
        }
    }
    return 0;
}

int main(int argc, char *argv[])
{
    int ret = rte_eal_init(argc, argv);
    if (ret < 0)
        rte_exit(EXIT_FAILURE, "EAL init failed\n");

    uint16_t portid = 0;
    uint16_t nb_rxd = RX_RING_SIZE;
    uint16_t nb_txd = TX_RING_SIZE;

    // 配置网口
    struct rte_eth_conf port_conf = port_conf_default;
    ret = rte_eth_dev_configure(portid, 1, 1, &port_conf);
    if (ret != 0)
        rte_exit(EXIT_FAILURE, "Port configure failed\n");

    // 创建内存池
    struct rte_mempool *mbuf_pool = rte_pktmbuf_pool_create(
        "MBUF_POOL", NUM_MBUFS, MBUF_CACHE_SIZE, 0,
        RTE_MBUF_DEFAULT_BUF_SIZE, rte_socket_id());
    if (!mbuf_pool)
        rte_exit(EXIT_FAILURE, "Mempool create failed\n");

    // 设置接收/发送队列
    ret = rte_eth_rx_queue_setup(portid, 0, nb_rxd,
                                 rte_eth_dev_socket_id(portid),
                                 NULL, mbuf_pool);
    if (ret < 0)
        rte_exit(EXIT_FAILURE, "RX queue setup failed\n");

    ret = rte_eth_tx_queue_setup(portid, 0, nb_txd,
                                 rte_eth_dev_socket_id(portid), NULL);
    if (ret < 0)
        rte_exit(EXIT_FAILURE, "TX queue setup failed\n");

    ret = rte_eth_dev_start(portid);
    if (ret < 0)
        rte_exit(EXIT_FAILURE, "Device start failed\n");

    // 启动 worker 核心
    uint16_t port_arg = portid;
    rte_eal_remote_launch(lcore_main, &port_arg, rte_get_next_lcore(-1, 1, 0));

    lcore_main(&port_arg);
    return 0;
}

编译与运行

# 加载大页内存和 DPDK 驱动
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
modprobe uio
dpdk-devbind.py --bind=igb_uio 0000:03:00.0

# 编译运行
gcc -o dpdk_basic dpdk_basic.c $(pkg-config --cflags --libs libdpdk)
./dpdk_basic -l 0-1 -n 4 -- -p 0x1

DPDK 在 DPU 上的价值：DPU 通常内置对 DPDK 的优化，比如硬件流分类、RSS（Receive Side Scaling）、PMD 驱动等。开发者可以在 DPU 的 ARM CPU 上直接运行 DPDK 应用，也可以让主机通过 DPDK 访问 DPU 的虚拟网口。

3.2 NVIDIA DOCA Flow：面向 BlueField DPU 的高级抽象

DOCA（Data Center Infrastructure on a Chip Architecture） 是 NVIDIA 为 BlueField DPU 提供的软件框架，包含 DOCA Flow、DOCA RDMA、DOCA Security、DOCA Storage 等多个子模块。其中 DOCA Flow 用于在 DPU 硬件中创建和管理数据面流表。

与 DPDK 的"手动处理每个包"不同，DOCA Flow 的编程模型更接近于"定义匹配规则 + 定义执行动作"，由 DPU 硬件自动执行。

DOCA Flow 核心概念

示例：DOCA Flow 创建一条简单的五元组转发规则

#include <doca_flow.h>
#include <doca_log.h>

DOCA_LOG_REGISTER(DOCA_FLOW_BASIC);

#define NB_QUEUE 1
#define NB_ACTION 1
#define NB_FLOWS 1024

static struct doca_flow_port *init_doca_port(uint16_t port_id)
{
    struct doca_flow_port_cfg port_cfg;
    struct doca_flow_port *port;

    memset(&port_cfg, 0, sizeof(port_cfg));
    port_cfg.port_id = port_id;
    port_cfg.type = DOCA_FLOW_PORT_TYPE_PCI;
    port_cfg.queues = NB_QUEUE;

    if (doca_flow_port_start(&port_cfg, &port) != DOCA_SUCCESS) {
        DOCA_LOG_ERR("Failed to start DOCA Flow port %u", port_id);
        return NULL;
    }
    return port;
}

static int create_ipv4_forward_pipe(struct doca_flow_port *port)
{
    struct doca_flow_pipe_cfg pipe_cfg;
    struct doca_flow_pipe *pipe;
    struct doca_flow_match match;
    struct doca_flow_actions actions;
    struct doca_flow_fwd fwd;

    memset(&pipe_cfg, 0, sizeof(pipe_cfg));
    memset(&match, 0, sizeof(match));
    memset(&actions, 0, sizeof(actions));
    memset(&fwd, 0, sizeof(fwd));

    pipe_cfg.attr.name = "ipv4_forward";
    pipe_cfg.attr.is_root = true;
    pipe_cfg.attr.nb_flows = NB_FLOWS;
    pipe_cfg.port = port;
    pipe_cfg.match = &match;
    pipe_cfg.actions = &actions;
    pipe_cfg.attr.nb_actions = NB_ACTION;

    // 匹配 IPv4 包，基于目的 IP
    match.parser_meta.outer_l3_type = DOCA_FLOW_L3_META_IPV4;
    match.outer.l3_type = DOCA_FLOW_L3_TYPE_IP4;
    match.outer.ip4.dst_ip = 0xFFFFFFFF; // 掩码为全匹配占位

    // 动作：不修改，直接转发
    actions.action_idx = 0;

    // 转发到另一个端口
    fwd.type = DOCA_FLOW_FWD_PORT;
    fwd.port_id = 1; // 转发到 port 1

    if (doca_flow_pipe_create(&pipe_cfg, &fwd, NULL, &pipe) != DOCA_SUCCESS) {
        DOCA_LOG_ERR("Failed to create pipe");
        return -1;
    }

    // 添加具体流表项：将 10.0.0.1 的流量转发到 port 1
    struct doca_flow_match match_entry;
    memset(&match_entry, 0, sizeof(match_entry));
    match_entry.outer.ip4.dst_ip = RTE_BE32(0x0A000001); // 10.0.0.1

    struct doca_flow_pipe_entry *entry;
    if (doca_flow_pipe_add_entry(0, pipe, &match_entry,
                                 NULL, NULL, NULL, 0, &entry) != DOCA_SUCCESS) {
        DOCA_LOG_ERR("Failed to add flow entry");
        return -1;
    }

    DOCA_LOG_INFO("Flow entry added: dst 10.0.0.1 -> port 1");
    return 0;
}

int main(int argc, char **argv)
{
    struct doca_flow_cfg cfg;
    struct doca_flow_port *port0;

    memset(&cfg, 0, sizeof(cfg));
    cfg.queues = NB_QUEUE;
    cfg.mode_args = "vnf"; // 或 switch、nic 模式

    if (doca_flow_init(&cfg) != DOCA_SUCCESS) {
        DOCA_LOG_ERR("DOCA Flow init failed");
        return -1;
    }

    port0 = init_doca_port(0);
    if (!port0)
        return -1;

    if (create_ipv4_forward_pipe(port0) != 0)
        return -1;

    // 主循环：处理控制面事件
    while (1) {
        doca_flow_entries_process(0, 0, 0);
        sleep(1);
    }

    doca_flow_destroy();
    return 0;
}

DOCA 三种工作模式

DOCA Flow 的优势在于，它将复杂的硬件加速能力抽象为简单的 API，开发者无需关心底层寄存器细节，就可以获得接近硬件极限的转发性能。

3.3 P4：协议无关的可编程数据面

P4（Programming Protocol-independent Packet Processors） 是一种领域特定语言（DSL），用于定义数据包如何被解析、匹配和处理。P4 不绑定于任何特定硬件，可被编译到 Tofino ASIC、FPGA、SmartNIC、DPU 等多种目标平台。

为什么 P4 重要？

在传统网络设备中，协议解析逻辑固化在硬件中。如果你想支持一种新协议，可能需要等待下一代芯片。P4 让数据面变得可编程：你可以定义自己的包头格式、匹配字段、处理流水线。

示例：P4 程序实现 IPv4 基础转发

#include <core.p4>
#include <v1model.p4>

// 定义以太网头
header ethernet_t {
    bit<48> dstAddr;
    bit<48> srcAddr;
    bit<16> etherType;
}

// 定义 IPv4 头
header ipv4_t {
    bit<4>  version;
    bit<4>  ihl;
    bit<8>  diffserv;
    bit<16> totalLen;
    bit<16> identification;
    bit<3>  flags;
    bit<13> fragOffset;
    bit<8>  ttl;
    bit<8>  protocol;
    bit<16> hdrChecksum;
    bit<32> srcAddr;
    bit<32> dstAddr;
}

struct headers {
    ethernet_t ethernet;
    ipv4_t     ipv4;
}

struct metadata {
    bit<32> next_hop;
}

parser MyParser(packet_in packet,
                out headers hdr,
                inout metadata meta,
                inout standard_metadata_t standard_metadata) {
    state start {
        packet.extract(hdr.ethernet);
        transition select(hdr.ethernet.etherType) {
            0x0800: parse_ipv4;
            default: accept;
        }
    }

    state parse_ipv4 {
        packet.extract(hdr.ipv4);
        transition accept;
    }
}

control MyIngress(inout headers hdr,
                  inout metadata meta,
                  inout standard_metadata_t standard_metadata) {
    action drop() {
        mark_to_drop(standard_metadata);
    }

    action ipv4_forward(bit<48> dstMac, bit<9> port) {
        standard_metadata.egress_spec = port;
        hdr.ethernet.srcAddr = hdr.ethernet.dstAddr;
        hdr.ethernet.dstAddr = dstMac;
        hdr.ipv4.ttl = hdr.ipv4.ttl - 1;
    }

    table ipv4_lpm {
        key = {
            hdr.ipv4.dstAddr: lpm;
        }
        actions = {
            ipv4_forward;
            drop;
            NoAction;
        }
        size = 1024;
        default_action = drop();
    }

    apply {
        if (hdr.ipv4.isValid()) {
            ipv4_lpm.apply();
        }
    }
}

control MyEgress(inout headers hdr,
                 inout metadata meta,
                 inout standard_metadata_t standard_metadata) {
    apply 
}

control MyDeparser(packet_out packet, in headers hdr) {
    apply {
        packet.emit(hdr.ethernet);
        packet.emit(hdr.ipv4);
    }
}

V1Switch(
    MyParser(),
    MyVerifyChecksum(),
    MyIngress(),
    MyEgress(),
    MyComputeChecksum(),
    MyDeparser()
) main;

P4 在 DPU 中的位置

并非所有 DPU 都原生支持 P4。支持 P4 的 DPU 通常具备可编程数据面流水线，比如基于 FPGA 的 DPU 或部分 ASIC DPU。P4 编译器会将上述代码转换为目标硬件的配置。

flowchart LR
    A[P4 源代码] --> B[p4c 编译器]
    B --> C[目标配置]
    C --> D1[Tofino ASIC]
    C --> D2[FPGA DPU]
    C --> D3[SmartNIC]
    C --> D4[软件交换机 bmv2]

3.4 SPDK：存储卸载的加速器

SPDK（Storage Performance Development Kit） 与 DPDK 类似，但专注于存储 I/O。它提供用户态 NVMe 驱动、vhost-user 目标、NVMe-oF 发起端/目标端等组件。

在 DPU 上，SPDK 可以实现：

• NVMe-oF 卸载：DPU 作为 NVMe-oF 目标，将远程 NVMe 存储暴露给主机。
• 压缩/解压加速：利用 DPU 内置的压缩引擎减少存储占用和传输带宽。
• 加密存储：在 DPU 中完成数据加密，不影响主机 CPU。

// SPDK 初始化 NVMe 控制器示例（伪代码）
struct spdk_nvme_transport_id trid = {};
snprintf(trid.traddr, sizeof(trid.traddr), "%s", "192.168.1.10");
trid.adrfam = SPDK_NVMF_ADRFAM_IPV4;
trid.trtype = SPDK_NVME_TRANSPORT_TCP;
trid.subnqn[0] = '\0';

rc = spdk_nvme_probe(&trid, NULL, probe_cb, attach_cb, NULL);
if (rc != 0) {
    SPDK_ERRLOG("spdk_nvme_probe() failed\n");
    return rc;
}

四、DPU 技术路线：ASIC、FPGA、SoC 之争

4.1 ASIC 型 DPU

代表产品：NVIDIA BlueField-3/4、Marvell OCTEON 10/11、Broadcom Stingray。

优点：

• 性能最高：针对特定工作负载深度优化，转发性能可达 Tbps 级。
• 功耗最低：去除通用计算冗余，能效比远超 FPGA 和 x86。
• 成本最低（大规模量产）：一旦流片，单颗芯片成本随产量下降显著。

缺点：

• 灵活性差：新功能依赖芯片设计，无法像 FPGA 那样现场重编程。
• 开发周期长：从架构定义到流片通常需要 2-3 年。
• 生态依赖：通常绑定特定厂商的软件栈（如 DOCA、OCTEON SDK）。

4.2 FPGA 型 DPU

代表产品：基于 AMD Xilinx Alveo / Intel FPGA 的 SmartNIC/DPU。

优点：

• 灵活性极高：可重编程，适合快速迭代和定制化协议。
• 上市时间短：无需流片，直接基于 FPGA 开发。
• 适合前沿探索：新协议、新算法可以先用 FPGA 验证。

缺点：

• 成本高：高端 FPGA 价格远超 ASIC。
• 功耗大：FPGA 的可编程互连带来额外功耗。
• 性能瓶颈：同工艺下，FPGA 的时钟频率和并行效率通常不如 ASIC。
• 开发难度大：需要掌握 RTL 设计或 HLS 高级综合。

4.3 SoC 型 DPU

代表产品：部分国产 DPU、基于 ARM Neoverse SoC 的集成方案。

优点：

• 灵活性与性能平衡：既有通用 CPU 跑控制面，又有专用加速器跑数据面。
• 可运行完整操作系统：开发者可以在 DPU 上运行 Linux、Kubernetes。
• 生态友好：ARM 软件生态成熟，开发门槛低于 FPGA。

缺点：

• 功耗和面积较大：集成 CPU 子系统带来额外开销。
• 性能天花板取决于集成度：加速器数量和效率因厂商而异。

4.4 选型决策矩阵

五、CPO 与光互连技术：从可插拔到共封装

5.1 为什么需要 CPO？

AI 训练集群的扩展对网络提出了前所未有的要求：

• 带宽需求爆炸：单颗 GPU 可能需要 400G/800G 网络接口，一个机架交换机需要 51.2T 乃至 102.4T 交换容量。
• 功耗压力：传统可插拔光模块功耗占系统总功耗的 30%-50%，随着速率提升，光模块功耗增速超过交换芯片本身。
• 信号完整性：电信号在 PCB 上传输距离越长，损耗越大，需要更高功耗的 DSP 和 SerDes 进行补偿。

5.2 光互连技术的演进路线

flowchart LR
    A[传统可插拔光模块<br/>Pluggable Optics] --> B[LPO 线性直驱<br/>低功耗短距]
    B --> C[NPO 近封装光学<br/>性能与可维护性平衡]
    C --> D[CPO 共封装光学<br/>极致功耗与密度]

5.3 四种光互连方案深度对比

可插拔光模块的功耗构成

一个 400G QSFP-DD DR4 光模块的典型功耗构成：

pie title 400G 可插拔光模块功耗分布
    "激光器/TIA/Driver" : 35
    "DSP/CDR" : 40
    "SerDes 驱动" : 15
    "控制/电源/其他" : 10

CPO 的核心价值在于：

• 去掉 DSP：通过缩短电链路，降低对高功耗 DSP 的依赖。
• 缩短电互连：从芯片到光引擎的距离从厘米级缩短到毫米级。
• 提高集成度：单位面积可提供更多光口，提升交换机端口密度。

5.4 CPO 封装架构详解

flowchart TB
    subgraph 传统可插拔方案
        A1[Switch ASIC] --> |PCB 走线 ~10cm| B1[光模块插座]
        B1 --> C1[光模块]
        C1 --> D1[光纤]
    end

    subgraph CPO 共封装方案
        A2[Switch ASIC] --> |Interposer/基板 ~1-2mm| B2[光引擎]
        B2 --> C2[光纤]
        D2[外部激光源 ELS] -.->|光纤供电| B2
    end

在 CPO 架构中，关键组件包括：

• 交换芯片（Switch ASIC）：如 Broadcom Tomahawk 5、NVIDIA Spectrum-4。
• 光引擎（Optical Engine）：集成调制器、探测器、波分复用器等。
• 硅光芯片（Silicon Photonics）：基于硅基底的光波导和调制器。
• 封装基板/Interposer：连接交换芯片与光引擎，提供高密度电气互连。
• 外部激光源（ELS, External Laser Source）：由于激光器发热大，CPO 常将激光器外置，通过光纤为光引擎供光。

5.5 CPO 面临的技术挑战

1. 热管理

   • 交换芯片和光引擎集成后，热流密度急剧上升。
   • 光器件对温度敏感，温度波动会影响波长稳定性和信号质量。
   • 需要液冷、热电冷却（TEC）或先进散热方案。

2. 良率与可靠性

   • 光电混合封装工艺复杂，良率低于传统封装。
   • 一旦光引擎故障，可能需要更换整个交换机模块，维护成本高昂。

3. 可维护性

   • 可插拔模块坏了可以热插拔更换，CPO 则需要拆机甚至更换板卡。
   • 行业正在探索"可拆卸光引擎"等折中方案。

4. 标准化

   • CPO 涉及芯片、光引擎、封装、光学接口多个环节，不同厂商方案差异大。
   • OIF（Optical Internetworking Forum）等组织正在推动 CPO 标准化。

5. 供应链成熟度

   • 硅光芯片、先进封装产能仍集中在少数厂商手中。
   • 规模化量产需要产业链协同。

5.6 LPO 与 NPO：CPO 的过渡形态

LPO（Linear Pluggable Optics）

LPO 保留了可插拔形态，但去掉了光模块内部的 DSP/CDR。它依赖交换机 SerDes 提供足够的信号补偿能力。

flowchart LR
    A[交换机 SerDes] -->|直接驱动| B[LPO 模块]
    B --> C[光纤]
    B --> D[无 DSP 放大]

优点：

• 功耗比传统可插拔降低 30%-50%。
• 延迟降低（去掉 DSP 处理延迟）。
• 无需改变现有机架布线，兼容性强。

缺点：

• 传输距离短，通常限制在 2km 以内。
• 对交换机 SerDes 质量和互操作性要求高。
• 不同厂商 SerDes 与 LPO 模块的兼容性仍在完善。

NPO（Near Packaged Optics）

NPO 将光引擎放置在靠近交换芯片的基板上，但没有像 CPO 那样与芯片共封装。它在功耗和可维护性之间取得平衡。

flowchart LR
    A[Switch ASIC] -->|短距 PCB/Interposer| B[光引擎基板]
    B --> C[光纤]
    B --> D[可插拔/可更换结构]

NPO 可以看作是 CPO 的"可维护版"或"预演版"，许多厂商将 NPO 作为通往 CPO 的中间步骤。

5.7 硅光技术：CPO 的底层支撑

硅光（Silicon Photonics） 利用 CMOS 工艺在硅基上制造光波导、调制器、探测器等器件。它是 CPO 光引擎的主流技术路线之一。

硅光的优势：

• 与 CMOS 工艺兼容：可利用现有晶圆厂产能。
• 高集成度：可在单芯片上集成数十甚至数百个光通道。
• 低成本潜力：大规模生产后成本有望下降。

硅光的挑战：

• 激光器集成：硅本身不是高效发光材料，通常需要 III-V 族材料激光器。
• 耦合损耗：光从光纤耦合到硅光芯片存在损耗。
• 温度敏感性：硅光器件性能受温度影响较大。

六、DPU 与 CPO 在 AI 集群中的协同

6.1 AI 训练集群的网络痛点

在大规模分布式训练中，GPU 之间需要频繁交换梯度。以 GPT 类大模型训练为例：

• AllReduce 通信量巨大：每次迭代都可能产生数百 GB 的梯度同步。
• 延迟敏感：网络延迟直接影响 GPU 利用率。
• 长尾延迟：偶发的拥塞会导致整个训练任务等待。

6.2 DPU + RDMA + CPO 的协同架构

flowchart TB
    subgraph 单机节点
        GPU1[GPU 1]
        GPU2[GPU 2]
        GPU3[GPU N]
        DPU[DPU<br/>RDMA 引擎 / OVS 卸载 / 安全]
        GPU1 <-->|PCIe Switch / NVLink| GPU2
        GPU1 -->|GPUDirect RDMA| DPU
        GPU2 -->|GPUDirect RDMA| DPU
        GPU3 -->|GPUDirect RDMA| DPU
    end

    DPU -->|400G/800G| SW[CPO 交换机]
    SW -->|光互连| DPU2[远端 DPU]

    subgraph 外部
        ELS[外部激光源] -.->|供光| SW
    end

在这个架构中：

• DPU 负责端到端 RDMA：提供 RoCE v2 或 InfiniBand verbs 接口，实现 GPU 显存到 GPU 显存的直接数据传输。
• CPO 交换机负责高速光互连：以最低功耗、最高密度连接成千上万 GPU。
• GPUDirect RDMA：消除 CPU 和系统内存的中间拷贝。
• OVS 卸载：容器/虚拟机网络不占用主机 CPU。

6.3 DPU 在 AI 推理服务中的价值

训练场景关注高吞吐低延迟的 RDMA，而推理服务则关注：

• 高并发网络接入：成千上万的客户端请求同时到达。
• 负载均衡与 TLS 终结：DPU 可以卸载 SSL/TLS 加解密和四层负载均衡。
• 安全隔离：在多租户环境中提供微分段和防火墙。
• 存储加速：模型加载、日志写入通过 NVMe-oF 加速。

flowchart LR
    A[客户端请求] --> B[DPU TLS 卸载]
    B --> C[DPU L4 负载均衡]
    C --> D[容器 1]
    C --> E[容器 2]
    C --> F[容器 N]
    G[DPU 防火墙/微分段] -.-> D
    G -.-> E
    G -.-> F

七、产业格局与国产替代

7.1 全球主要玩家

7.2 国产替代机遇

• 政策驱动：美国出口管制倒逼自主可控，国产 DPU、交换芯片、光模块迎来窗口期。
• 市场驱动：东数西算、智算中心建设带来巨大需求。
• 成本与服务优势：国产方案在本地化支持、定制化响应、TCO 上具备竞争力。

7.3 技术差距与追赶方向

八、综合复习与面试准备

8.1 核心概念 checklist

• [ ] 能清晰区分 DPU、SmartNIC、IPU 的概念与能力边界。
• [ ] 能画出 DPU 在 AI 集群中的数据流路径。
• [ ] 能对比 ASIC、FPGA、SoC 三种 DPU 路线的优缺点与适用场景。
• [ ] 能解释 DPDK、SPDK、DOCA Flow、P4 在 DPU 编程中的作用。
• [ ] 能说明 CPO、NPO、LPO、可插拔光模块的区别、优缺点和发展阶段。
• [ ] 能分析 DPU 与 CPO 在 AI 训练/推理中的协同价值。

8.2 常见面试问题深度解析

Q1：DPU 和智能网卡（SmartNIC）有什么区别？

SmartNIC 主要做网络卸载，形态通常是增强型网卡。DPU 是完整的 SoC，除了网络，还集成存储、安全、虚拟化加速引擎，能独立运行操作系统，实现更完整的基础设施卸载。可以把 SmartNIC 看作 DPU 演进过程中的一个重要阶段。

Q2：为什么 AI 集群需要 DPU？

AI 集群中，CPU 被网络协议、虚拟交换、安全策略、存储 I/O 等任务严重消耗，无法充分发挥 GPU 的算力。DPU 将这些任务卸载到专用硬件，释放 CPU；同时通过 RDMA 和 GPUDirect 技术，为 GPU 提供低延迟、高吞吐的网络访问。

Q3：x86 + FPGA 的 DPU 方案有什么优缺点？

优点：灵活可编程，适合快速原型和自定义协议。缺点：成本高、功耗大、性能通常不如 ASIC，开发难度大。适合探索性场景，大规模部署通常选择 ASIC DPU。

Q4：CPO 相比可插拔光模块的优势和劣势是什么？

优势：功耗最低、带宽密度最高、电互连距离最短、信号完整性最好。劣势：可维护性差、良率低、热管理复杂、标准化程度不足。

Q5：你认为 CPO 什么时候会大规模商用？

CPO 正处于 2025-2027 年的量产爬坡期。大规模商用取决于硅光芯片良率提升、先进封装产能释放、可维护性方案成熟以及行业标准统一。短期内 LPO/NPO 会是过渡主力，CPO 将先在超大规模云厂商和 AI 训练集群中落地。

Q6：DPDK、DOCA Flow、P4 在 DPU 开发中如何选择？

• DPDK 适合需要精细控制每个数据包的应用，如自定义网关、防火墙。
• DOCA Flow 适合在 NVIDIA BlueField DPU 上做硬件加速的流表处理。
• P4 适合需要跨平台可编程数据面的场景，尤其是自定义协议和交换机流水线。

九、实操项目建议

项目一：DPU 技术路线深度对比报告

选择三款真实 DPU 产品（如 NVIDIA BlueField-3、Marvell OCTEON 10、国产 FPGA DPU），从以下维度对比：

1. 硬件架构：CPU 核心数量与架构、加速引擎类型、网络接口速率、内存配置。
2. 卸载能力：网络（OVS/RDMA）、存储（NVMe-oF/压缩）、安全（TLS/IPSec/防火墙）、虚拟化（SR-IOV/VirtIO）。
3. 编程框架：是否支持 DPDK、SPDK、DOCA Flow、P4、Verbs。
4. 软件生态与文档成熟度。
5. 适用场景与 TCO 估算。

项目二：CPO 产业链图谱绘制

绘制 CPO 产业链全景图，包括：

• 上游：交换芯片、光引擎、硅光芯片、激光器、封装基板/Interposer。
• 中游：CPO 交换机整机、光模块、NPO/LPO 模块。
• 下游：云厂商、AI 公司、电信运营商、超算中心。
• 标注：国内外主要玩家，以及各环节的技术成熟度。

项目三：DPDK/DOCA/P4 最小可运行 Demo

• 在支持 DPDK 的环境（物理机或虚拟机）中运行基础收发包程序。
• 如果有 NVIDIA BlueField DPU，尝试用 DOCA Flow 创建一条五元组转发规则。
• 使用 P4 编译器将基础 IPv4 转发程序编译到 bmv2 软件交换机运行。

十、推荐资料与学习路径

官方文档

• NVIDIA BlueField DPU 文档中心
• NVIDIA DOCA SDK 文档
• DPDK 官方文档
• P4 语言规范

技术博客与论文

• 芯片开发学习笔记·二十二——DPU 介绍
• DPU 加速网络数据面：基于 DOCA Flow 的硬件卸载实践
• 共封装光学(CPO) vs 可插拔光模块
• 超节点技术体系白皮书：光电互连封装
• CPO 交换机：AI 算力集群的"光速桥梁"与产业链全景

建议学习路径

flowchart LR
    A[网络基础：TCP/IP / 虚拟化 / RDMA] --> B[DPDK 用户态包处理]
    B --> C[DPU 架构与卸载原理]
    C --> D1[DOCA Flow 编程]
    C --> D2[P4 可编程数据面]
    D1 --> E[AI 集群网络优化实践]
    D2 --> E
    E --> F[CPO / LPO / NPO 光互连]
    F --> G[产业链分析与架构选型]

结语

DPU 与 CPO 分别代表了计算卸载与数据传输两个维度的硬件创新。DPU 让 CPU 和 GPU 从基础设施负担中解放出来，专注于它们最擅长的计算任务；CPO 则以光电融合的方式，为 AI 集群提供了面向未来的高带宽、低功耗、高密度互连方案。

对于希望深入 AI 基础设施领域的工程师而言，理解 DPU 的内部数据流、掌握 DPDK/DOCA/P4 等编程模型、把握 CPO 的技术演进与产业格局，已经成为必不可少的能力栈。随着 AI 算力需求持续增长，DPU 与 CPO 的重要性只会愈加凸显。