重读BlueField-2 DPU方案：数据面卸载与裸金属弹性存储

简介：《BlueField DPU Solutions 202104.pdf》围绕 NVIDIA BlueField-2 DPU 的产品方案展开，面向数据中心架构师、云计算与网络虚拟化从业者，以及关注裸金属云和基础设施卸载的技术人员。正文从 DPU 的基本概念入手，依次覆盖安全加速、存储加速、网络加速、裸金属云与 BlueField 生态，并配合硬件框图、能力对比和方案页，帮助读者理解以 DPU 承载软件定义基础设施的思路。压缩包包含 1 个 PDF 文件，大小约 4.7MB，适合集中阅读和离线查阅。已有 807 人学习，反映出该主题在虚拟化与裸金属场景中具有一定关注度。读者可从中梳理 BlueField-2 的 ARM 核、PCIe 交换结构、安全与存储卸载能力及典型应用边界，其中关于安全卸载、正则匹配与存储 I/O 加速等内容，可帮助判断 DPU 与 CPU 的分工边界；对裸金属云和混合云场景的讨论，也能为云平台选型、网络与存储方案设计提供参考，适合作为入门概览和方案汇报的辅助材料。

1. 一份 2021 年的 DPU 方案文档，为什么现在翻出来还值得读

「一颗芯片抵 125 个 x86 核」在变成宣传语之前，其实是一份方案文档里的对照系数。这份 2021 年 4 月版的 BlueField-2 DPU 解决方案文档，把网络、存储、安全三块数据面从主机 CPU 上整块切下来，放进一颗 6.9B 晶体管、8 个 64 位 Arm A72 核的片上系统，并在上面跑一套叫 DOCA 的 SDK。它今天还值得重读，原因很现实：裸金属与虚拟化之间那条保持了十几年的边界，正在被重新划线，而这份文档是那条线最早的施工图之一。主机让出数据面之后，「物理机的隔离」和「云盘的弹性」第一次不再互相排斥。对做基础设施的人来说，读懂这份材料，相当于提前看懂后来一大批「基础设施卸载」产品的设计套路。

2. 从网卡到基础设施芯片：BlueField-2 的硬件账本

把 DPU 理解成「一张更快的网卡」，是那两年最普遍的误读。文档第 6 页的块图给出了另一种读法：网络接口、Arm 核簇、PCIe 交换单元被放在同一块 die 上，主机侧看到的不再是一个单纯的端点设备，而是一个可以自己挂载设备、自己跑协议栈、自己管理自己的小系统。这个变化带来的连锁反应，比任何单点加速倍数都重要。

2.1 6.9B 晶体管与 8 个 A72 核：把「卸载」写进硅片

文档给出的核心规格是 6.9B 晶体管、8 个 64 位 Arm A72 核、最高 2.5GHz、8MB L2 加 6MB L3 缓存。这组数字放在 2020 年的时间点上，和一颗主流服务器 CPU 的晶体管规模处在同一量级，说明设计者从一开始就没把它当网络芯片做。

缓存的组织方式值得多看一眼：8 个核并不是平铺在一个共享缓存池上，而是按 4 个 Tile 切分，每个 Tile 里两个核共享本地缓存，再通过片上互连访问其他 Tile 的 L3 分区。这种布局的好处是面积和功耗可控，代价是跨 Tile 的内存访问延迟明显高于核内访问。后来在卡上跑数据面程序的人，血泪经验基本都集中在这里：一个处理流水线如果被调度器在四个 Tile 之间来回搬，缓存命中率会掉得很难看，吞吐抖动比预期大得多。常见的做法是把一个方向的流量处理绑在固定的几个核上，让它们尽量待在同一个 Tile 里。

除了通用核，芯片里还有双 16-way VLIW 引擎。这类固定功能加速器的特征是把指令级并行写死在编译器里，跑正则匹配、压缩、加解密这类模式固定的活极快，文档标称的 50 Gbps RegEx 和 100 Gbps 视频流处理就来自这里。反过来，任何带分支预测、状态机复杂、规则频繁变动的逻辑，扔进 VLIW 引擎都是自找麻烦。通用核与固定功能引擎的分工边界，基本决定了一颗 DPU 的适用场景。

这张表里最容易被忽略的是最后一行。PCIe 接口支持 Root Complex 模式，意味着这块卡可以反过来当主机用，直接挂载 NVMe 盘。后面要讲的存储模拟能力，物理前提就在这里。

2.2 200G 端口与 PCIe Gen4 分叉：块图里最容易被跳过的三行

块图上有三行信息，读方案的人经常一扫而过，但它们对部署方案的影响极大。

第一行是调制方式：200Gbps 速率同时支持 NRZ 和 PAM4。PAM4 用四个电平承载两个比特，在同样的符号率下把速率翻倍，代价是眼图张开度变小，对链路损耗、连接器质量、走线长度的容忍度都更低。这意味着同样标称 200G 的交换机和光模块，在实际机房里能不能跑满，取决于布线质量。早期部署里因为一根劣质跳线导致端口降速、再被上层误判成网卡故障的情况并不少见。

第二行是 PCIe 的分叉与模式。16 lane Gen4 可以拆成 x8+x8 或者更细的粒度，同时支持 Root Complex 与 End Point 两种角色。End Point 模式下它就是一张插在服务器里的加速卡；Root Complex 模式下它自己就是主机，能直接枚举下游设备。存储节点不需要再配一颗 x86 处理器来带盘，一块卡加几个 NVMe 盘就是一个能对外提供块存储的单元。这个形态上的自由度，是后来「存储解耦」类方案能成立的基础。

第三行是那颗 1GbE 带外管理口。它独立于业务端口，也独立于主机的 BMC，用于固件升级、远程调试和带外纳管。看起来是个小细节，但在规模化运维里意义不小：当主机操作系统起不来、或者主机本身已经被租户占用时，仍然有一条通道能碰到这块卡。反过来说，这条通道的访问控制、密码轮换、日志留存，也顺理成章地进入了安全审计范围——很多团队在第一批机器上线时忘了这一点。

还有一个隐性约束：接口标称 Gen3/Gen4 兼容。插在 Gen3 插槽上，x16 的理论带宽只有 Gen4 的一半，此时 200G 网络端口和 5M IOPS 的存储能力都会被主机侧总线卡住。加速卡买回来发现跑不出标称值，一半以上的原因在这个地方，跟卡的固件没关系。

2.3 125 个 x86 核这个数字，到底在跟谁比

文档里那句「替代 125 个 x86 CPU 核」，配的是一组不同负载的对照倍数。把这些倍数拆开看，会发现它们横跨两个数量级：

口径是「要达到单颗 DPU 的处理能力，需要额外增加多少 x86 核」。所以 125 这个总数不是任何单一负载的成绩，而是若干负载混合后的加权结果。一台机器上如果只跑 overlay 网络，加速收益只有个位数倍；如果叠加了有状态防火墙和块存储网关，数字才会被拉上去。

这个区别对容量规划很关键。可以写几行代码把自家流量结构代进去估一遍：

# 按流量结构折算等效 CPU 核数，倍数取自文档口径 workloads = { "overlay": {"share": 0.35, "gain": 2.5}, "firewall": {"share": 0.25, "gain": 150}, "ipsec": {"share": 0.20, "gain": 30}, "block_io": {"share": 0.20, "gain": 50}, } dpu_equiv = 0.0 for name, w in workloads.items(): # share 是该负载在单机数据面开销中的占比，gain 是该负载的等效倍数 dpu_equiv += w["share"] * w["gain"] print(round(dpu_equiv, 1)) # 输出的是加权后的等效核数量级

这段代码没有任何预测能力，它只是把「加权」这件事显式化。改动share的分布，结果会从个位数跳到几十，说明这个指标对业务形态极度敏感。真正做决策时，瓶颈往往不在 CPU 核数，而在内存带宽、PCIe 通道和主机侧中断处理。把加速倍数直接换算成「机器可以少买一半」，是那两年最常见的一笔糊涂账。

从行业角度看，125 这个数字的价值不在于精确，而在于量级提示：安全与存储的数据面开销，已经和业务负载本身处在同一个量级。既然它们占了这么多算力，把它们整体切走、放进一颗独立的芯片里，在经济上就成立了。这是 DPU 这个品类能被市场接受的根本理由，跟单个倍数是 30 还是 50 关系不大。

3. 安全与存储两条加速主线：信任锚点为什么搬到了卡上

硬件账本讲完，接下来是这份文档花了最多篇幅的两块内容：安全加速与存储加速。它们看起来是两个独立方向，实际上共享同一套逻辑——把「执行点」从主机操作系统里挪出来，放进一个主机看不见、也改不了的地方。

3.1 边界消失之后：有状态防火墙与 Root-of-Trust 的下沉

文档里有一张对比图，讲的是安全能力的位置迁移：过去防火墙、微隔离、入侵检测跑在数据中心边界，后来因为一台物理机上要承载几十个租户的工作负载，边界被打散，这些能力被塞进主机里，以软件形式跟业务争抢同一批 CPU 核。到了 DPU 这一代，执行点被挪到卡上。

这个迁移的实质收益不是「更快」，而是「隔离」。文档反复强调 fully isolated from host——主机上跑的代码看不到卡上的安全控制面，即便主机被攻破，防火墙规则、密钥、策略依然在另一个域里。这一点比任何加速倍数都更接近安全团队的真实诉求，因为它改变的是攻击面结构，不是处理速度。

文档列出的安全能力可以分三层看。硬件信任层包括安全固件升级、Root-of-Trust 和 Arm TrustZone，解决的是「这台机器启动的到底是什么」；L4-L7 层包括有状态防火墙、深度包检测和主机内省，解决的是「跑起来之后流量里有什么」；加密层包括传输加密、静态数据加密和公钥运算加速，解决的是「数据在链路上和盘上以什么形态存在」。三层里最容易被低估的是第一层：信任锚点从主板 BIOS 挪到卡上之后，度量链的起点变了，合规审计的取证对象也跟着变。很多团队在第一批机器上线时只盯着吞吐，把固件签名和度量日志留成了空白。

也要说清楚边界。规则集仍然是人维护的，策略仍然要有人写，证书生命周期仍然要有人管。卡只是把执行搬走了，它不会替你决定哪些流量该拦。把 DPU 当成「安全问题的解法」，和把它当成「安全执行点的高效载体」，是两种完全不同的预期，后者才站得住。

3.2 NVMe SNAP：把远端盘伪装成本地盘的那层「翻译层」

存储这块，文档给了一个叫 SNAP 的机制。原理不复杂：DPU 在 PCIe 上向主机模拟出一个本地 NVMe 设备或者 virtio-blk 设备，主机用操作系统自带的 inbox 驱动就能认出来，IO 请求发出去之后被 DPU 截获，转成 NVMe-oF 或者 RDMA 请求打到远端存储集群。

这个设计的巧妙之处在于「主机无感」。文档特意强调了 inbox 标准驱动、操作系统无关、支持遗留系统——翻译过来就是：云厂商不需要让客户换镜像、装客户端、改内核模块。一台十年前的旧系统，插上带这块卡的机器，看到的仍然是一块本地盘。

远端协议的支持面在文档里列得比较全：NVMe-oF、iSCSI、iSER、NFS、CEPH，本地侧分直接和间接两种路径。性能指标是双 100Gbps 或单 200Gbps 端口、4K 随机读最高 5.4M IOPS、最低时延，同时在卡上做 AES-XTS 静态加密、认证、压缩和去重。

主机侧发起连接的动作，和普通 NVMe-oF 主机没有区别：

# 主机侧通过标准 nvme-cli 连接远端子系统 # 载入 fabrics 与 rdma 传输模块 modprobe nvme-fabrics modprobe nvme-rdma # 发现目标：-t 指定传输层，-a 为目标地址，-s 为端口 nvme discover -t rdma -a 192.0.2.10 -s 4420 # 连接子系统：-n 为 NQN 名称，-Q 为队列深度，-l 为 keep-alive 超时（秒） nvme connect -t rdma -a 192.0.2.10 -s 4420 \ -n nqn.2021-04.example:nvme:storage-01 \ -Q 128 -l 30 # 查看本机识别到的命名空间 nvme list

参数里有几个值得单独拿出来说。-Q队列深度直接决定单连接能压出多少 IOPS，队列太浅，再快的后端也喂不饱；-l是 keep-alive 超时，它决定了链路抖动时主机多久判定目标失联。用 SNAP 场景时，这两个值要和卡上的模拟设备配置对齐，否则会出现主机侧已经重连、卡上会话还挂着的情况。-n的命名空间名称必须与后端配置完全一致，多一个字符都会连不上，这类错误在日志里只表现为一句 timeout，排查成本不低。

用 SNAP 之后，主机侧的排障思路要整体换一遍。iostat看到的延迟是模拟设备报出来的，真实的后端排队、网络重传、远端扩容事件，主机侧一概不知。这就是把后端封装起来之后必然要付的代价——它对上层是黑匣子，对运维也就变成了黑匣子。监控必须下沉到卡和后端两个层面，只盯主机指标会在故障时完全没有方向。

3.3 DOCA 的分层：开源 API、参考应用与那块不肯开放的固件

文档后半段介绍了 DOCA，一套面向这块卡的 SDK。组成上分三块：开源 API 层，包括 DPDK、SPDK、P4；经过认证的参考应用与第三方方案；以及对多种操作系统的支持。往下还有一组功能组件——加速交换与包处理、加密、信任根、DMA、SNAP、管理与遥测。

这个分层透露的信息量比它的功能列表更大。DPDK 和 SPDK 是数据面的事实标准，把这两个搬上来，等于告诉现有的网络与存储软件厂商：你们已有的代码有地方跑。P4 的加入说明转发面是可编程的，规则可以下发。而加密、模式匹配这些走的是固定流水线，写死在硅片里，不接受用户编程。

这条「可编程」与「写死」的分界线，恰好也是选型的判断依据。规则稳定、吞吐要求极高的部分交给固定引擎；规则天天变、需要快速迭代的部分放到 Arm 核上用 DPDK/SPDK 写。一个方案如果宣称所有功能都能在卡上编程实现，通常意味着它放弃了硬件加速的收益；反过来，全部写死、只给几个开关的方案，在业务变化时几乎没有腾挪空间。

管理和遥测组件经常被放到最后才看，实际在规模化部署里它是决定能不能运维的关键。卡上跑的是独立的操作系统，有自己的固件版本、自己的日志、自己的时间同步需求。它一旦进入生产环境，就必须被纳入现有的配置管理、监控告警和补丁流程，否则第一批机器上线三个月之后，会出现一批没人说得清版本状态的设备。这不是技术问题，是流程问题，但出问题的代价一点不小。

4. 裸金属与虚拟化不再二选一：DPU 改变的交付方式

前面讲的是能力，这一章讲的是这些能力组合起来之后，改变了什么交付方式。文档里给出的两个场景——弹性块存储与虚拟化平台联合方案——表面上是两个产品方向，实际上回答的是同一个问题：一台机器能不能既像物理机一样独占，又像虚拟机一样灵活。

4.1 一台裸金属服务器如何拥有云盘的弹性

传统裸金属云的尴尬之处在于，用户拿到了整台机器的隔离性，同时也拿到了它的全部刚性：本地盘绑死在这台机器上，容量不能超分，机器坏了盘也跟着走，扩容要停机加盘。

SNAP 机制把这一层解开了。主机看到的是模拟出来的本地 NVMe 或 virtio-blk 设备，实际数据在后端的分布式存储池里。于是几件事同时成立：容量可以超分，因为后端是池化的；盘可以在机器之间重新挂载，因为主机侧的「本地盘」只是一层映射；后端可以在机架甚至集群层面横向扩展，不需要动主机配置。文档里把这套组合称为弹性块存储，关键词是动态分配、不受物理容量约束、按机架或集群扩容。

这套东西对云厂商的吸引力在于交付形态。客户拿到的还是一台裸金属服务器，用lsblk看到的是标准块设备，装系统不需要任何特殊驱动，遗留的老操作系统也能跑。也就是说，云厂商可以在不改变客户使用习惯的前提下，把本地盘换成一个可编排的远端资源。这是一个典型的「改动全在后台」的产品设计。

对使用方来说，需要重新理解的是故障语义。远端存储不可达时，主机侧看到的是 IO 超时甚至设备挂起，而不是一块坏盘。重试策略、超时阈值、多路径配置都要跟着调整。把远端盘当成本地盘用，最容易翻车的地方就在这里——平时看不出区别，出问题时行为完全不同。

4.2 主机管理下沉：hypervisor 让出 CPU 之后

文档里提到的另一个方向，是与虚拟化平台厂商的联合项目：把网络与安全服务、存储数据面、主机管理组件从主机侧搬到卡上，主机上只留计算和控制面。裸金属与虚拟化由此不再是对立的两条产品线，而是同一套基础设施上的两种租用方式。

这个变化对资源账的影响很直接。一台服务器上跑虚拟化，管理组件和数据面转发本身要吃掉一部分核，比例随网络与存储负载上升。搬走之后，这部分核全部还给业务负载。文档给出的应用效率对照，本质上就是这个账的另一种写法。

影响更大的是攻击面和维保模型。管理面不在主机操作系统里，租户即使拿到了主机的 root 权限，也碰不到网络策略和存储路径的配置。维保也分开了：卡上的固件可以单独升级、单独重启，不需要把整台机器下架。对于提供托管服务的一方，这意味着可以在客户不知情的情况下修一个底层组件——听上去是好事，但前提是变更流程足够细，否则一次固件升级可能让整批机器的存储路径短暂中断。

代价也很清楚：多了一层要管的东西。原来一台机器一个管理入口，现在变成主机加卡两个；原来一套监控，现在要加卡的遥测和固件版本；原来排障看一个日志，现在要判断问题在哪一层。团队如果没有相应的流程配套，省下来的 CPU 核会被运维成本吃掉。

4.3 运维账本：省下的核、多出来的复杂度

把收益和成本摆在一张表上，比任何单方面宣传都清楚：

这张表最后一行是关键。单看卡的价格，任何团队都会犹豫；按整机 TCO 算——省下的核、省下的存储网关节点、省下的安全虚拟机、延长的旧机器使用寿命——账才可能算得平。而且这个平衡点随业务形态移动：数据面开销占比高的业务回本快，纯计算的业务几乎没有收益。

5. 五个容易踩的误判：落地现实与文档口径之间的距离

文档给的是架构和上限，落地遇到的是兼容性和下限。这两者之间的距离，构成了那两年大部分 DPU 项目的实际工期。

5.1 误判一：以为插上就有收益

误判点：把卡当成「更快的网卡」，认为装机之后现有业务自动加速。

为什么：加速的前提是数据面程序跑在卡上的 Arm 核里，走 DPDK/SPDK/P4 那套用户态路径。主机内核里的原有协议栈不参与这个过程，原来的 netfilter 规则、内核态的存储客户端、已有的监控探针，统统不会自动搬到卡上。不改造，卡就只是一张贵的网卡。

怎么看：先挑边界清晰、规则相对固定的负载做第一个试点，比如 IPsec 网关、overlay 隧道封装、NVMe-oF 接入层。这三类负载的共同点是输入输出明确、状态机简单、性能收益容易度量。等第一个场景跑顺了，再考虑把更复杂的策略搬过去。

5.2 误判二：把等效核数直接换算成采购量

误判点：看到 125 这个数字，按「一台顶几台」做预算。

为什么：这个数字是加权结果，权重来自流量结构。更要紧的是，即使 CPU 核省下来了，内存带宽、PCIe 通道带宽、主机中断处理仍然会形成新的天花板。很多场景里，加速卡装上去之后 CPU 利用率降了，但整机吞吐没有同比上升，因为瓶颈换位置了。

怎么看：用自己的流量结构做折算，同时把 PCIe 代际、插槽分叉方式、内存通道数一起纳入模型。判断标准不是「省了几个核」，而是「单位功耗下的有效吞吐提升了多少」。

5.3 误判三：把模拟出来的块设备当成真本地盘

误判点：主机侧看到一块 NVMe 盘，就按本地盘的思路做容量规划和故障预案。

为什么：这层设备是模拟出来的，背后是网络加远端存储。延迟分布、超时行为、错误码含义都和本地盘不同。本地盘坏了是硬件事件，远端不可达是网络事件，两者的处理路径完全不一样。

怎么看：把故障域画出来，明确写出「后端不可达时主机侧应该看到什么、上层应用应该怎么退避」。多路径、超时阈值、队列深度这几个参数要在压测里逐个改一遍，看系统行为如何变化，而不是照抄默认值。

5.4 误判四：认为安全卸载等于安全问题解决了

误判点：把防火墙、微隔离、加密都搬到卡上，就认为隔离做完了、合规过关了。

为什么：卡只是执行点。规则谁写、策略谁审、证书谁轮换、固件谁打补丁，这些流程一个都不会因为换了硬件而消失。而且卡本身跑着独立的操作系统，有自己的固件和带外管理口，它变成了一个新的资产，也变成了一个新的攻击面。安全固件升级和信任根这两个能力，正是为这件事准备的。

怎么看：把卡纳入资产清单、补丁流程和日志采集范围，和服务器同等对待。带外管理口的访问控制单独审一遍，别让它成为整个机房里唯一没有纳管入口的设备。

5.5 误判五：按文档时间线推进项目

误判点：把文档里的架构图当成「现在就能用」的功能清单。

为什么：架构文档描述的是方向和上限，具体到某个操作系统版本的驱动支持、某家云厂商的产品化进度、某个虚拟化平台把管理面迁走的时间点，都会晚于架构发布。方案里写的「支持多种操作系统」，落到实际项目里往往意味着「支持其中两个，其余在排队」。

怎么看：以自己目标环境的驱动支持情况为准绳，做一张兼容性矩阵，把内核版本、发行版、虚拟化平台版本逐项打勾。凡是打不了勾的，就当它不存在，别写进项目计划。

6. 从卸载卡到基础设施控制面：接下来该盯什么

把这份文档和后面几年的产品演进放在一起看，会发现一个清晰的位置变化：DPU 最早被当作卸载卡卖，卖的是省下来的 CPU 核；后来被当作隔离边界卖，卖的是主机碰不到的控制面；再往后，它的角色更像是基础设施的控制面本身——网络策略、存储路径、安全规则、租户隔离，这些决定「这台机器是什么」的东西，执行点都在卡上。谁掌握了这个执行点，谁就掌握了基础设施的定义权。

6.1 三个值得持续观察的窗口

第一个窗口是主机侧驱动的覆盖度。SNAP 这类机制能不能普及，取决于主流发行版是否把模拟设备当成标准设备对待，而不是要求用户装额外组件。驱动进主线的时间点，往往比产品发布的时间点更能说明落地进度。

第二个窗口是裸金属产品形态的变化。当云厂商开始默认把存储路径和网络策略放到卡上，而不是作为可选加购项时，说明这套架构的成本账已经算得过来。这个信号比任何一份技术白皮书都硬。

第三个窗口是 SDK 的收敛程度。一套 API 如果三年里还在频繁改名、频繁重构，说明抽象层没定型，上层应用不敢深度绑定；反过来，API 一旦收敛，生态应用会快速堆积。判断标准很简单：看第三方方案的数量，而不是看官方参考应用的数量。

6.2 给不同角色的判断建议

如果你在做基础设施架构，重点看故障域怎么变。多了一层独立的操作系统和独立的固件，就多了一套变更窗口和回滚方案，这部分工作量经常被低估。我的建议是在试点阶段就把监控和固件管理一起做进去，不要等功能验证完了再补。

如果你在做安全，重点看信任链的起点迁移到哪里。启动度量、固件签名、带外管理口的访问控制，这三件事一旦脱离原有流程，合规审计就会出问题。这部分不是技术选型，是流程设计。

如果你在做采购或技术决策，重点看 TCO 而不是卡价。省下来的核、省下来的网关节点、延长的旧机器寿命要一起算，同时把新增的运维复杂度折成人力成本扣掉。算完之后如果还是正的，再谈规模。

我自己在第一轮评估这类方案时，只盯着加速倍数和端口速率，把固件升级流程和带外管理口的权限设计全部略过了。结果试点机器上线两个月，一批卡的固件版本各不相同，谁在什么时候升的、升的哪个版本，没人说得清，最后只能整批停机对齐版本。从那以后我每次评估带独立管理面的硬件，都强制走一遍「它怎么升级、升级失败怎么回滚、谁有权操作」这三问，问不出答案就不进生产。希望帮到你。

本文还有配套的精品资源，点击获取