DPU 加速弹性裸金属：让性能少走一层路
原文链接：https://mp.weixin.qq.com/s/bxXKkqlcETr375ktNhGqVQ
在 ZStack Cloud 5.5.16 版本发布里，我们提到过一个新能力：DPU 加速弹性裸金属。当时它只是版本特性清单里的一个小节，讲的是"硬件卸载、存储引擎、性能释放"。这篇文章，我们把它展开讲清楚：DPU 接进 ZStack 之后，弹性裸金属的网络、存储和设备管理路径发生了什么变化。
DPU 加速弹性裸金属，不只是版本清单里的一个新功能
在 ZStack Cloud 5.5.16 发布文章里，DPU 加速弹性裸金属被放在"弹性裸金属增强"下面：通过 DPU 设备直接管理裸金属节点，引入硬件卸载能力，结合高性能存储引擎，降低主机 CPU 负载，提升存储 IOPS 与网络吞吐能力。
这段话不长，但背后其实是一次弹性裸金属架构的调整。
ZStack Cloud 原本已经具备弹性裸金属的云化交付能力。DPU 接入之后，重点不是重新证明"裸金属能被云平台管理"，而是进一步把网络、存储和隔离这些数据面能力下沉到更靠近硬件的位置：少一层网关中转，减少主机侧协议栈消耗，也减少物理机硬件差异带来的适配成本。
为什么裸金属还需要 DPU
10G 网络时代，OVS 转发、存储协议栈、虚拟化中断处理这些开销还能接受。到了 25G，问题会被放大。
在 25G 网络和高性能云盘场景下，宿主机 CPU 往往不只承担业务计算，还要处理网络转发、I/O 请求和协议栈开销。流量和 I/O 压力越高，这部分数据面开销越容易被放大。它消耗的不是业务逻辑本身，而是数据包、I/O 请求和协议处理过程中的"搬运成本"。
在虚拟机里，这部分开销大家多少还能接受；但到了裸金属，就不一样了。客户买裸金属，买的就是尽可能接近物理机的性能。如果网络和存储开销还要继续占用主机 CPU，"裸金属"的价值就会被打折。
ZStack 和亚格之芯适配，目标很直接：把传统裸金属链路里那些"不该由物理机承担"的资源消耗都拿掉，让 DPU 去接网络、存储和设备侧的数据面工作。接下来，从三个典型客户场景看看我们具体解决了什么问题。
三个场景
下面三个场景，一个是当前已经落地的资源池化能力，一个是 ZStack 与亚格之芯正在共同推进的 AI 推理缓存方向，一个是高性能云盘承载方向。
场景一：GPU 物理机资源池流转
AI 智算客户要的是裸金属性能，但运营方真正头疼的，往往不是"这台机器能不能跑"，而是"这批机器能不能快速交付、快速回收、快速恢复"。
GPU 服务器贵，资源周转也快。传统物理机模式下，系统安装、镜像适配、故障替换、远程排障都会拉长交付周期。一台机器出问题，往往不是简单换一台就结束：系统盘、数据盘、业务环境、网络配置、故障现场都要跟着处理。
DPU 加速弹性裸金属想解决的，是让 GPU / 高性能物理机更像一个可流转的资源池，而不是一批需要逐台照看的服务器。
| 维度 | 网关代理模式 | DPU 加速模式 |
|---|---|---|
| 部署链路 | 需要网关节点参与 | 取消网关节点部署要求 |
| 系统盘交付 | 更依赖本地装机和镜像适配 | 系统盘拉远，通过云盘方式交付，减少部署时间 |
| 存储接入 | 依赖网关侧接入和转发 | DPU 承接存储数据面 |
| 网络路径 | 经过额外转发链路 | 网络能力向端侧卸载 |
| 镜像适配 | 更容易受物理机硬件差异影响 | 减少硬件差异带来的镜像封装负担 |
| 故障恢复 | 故障替换时更容易涉及系统、数据和业务环境迁移 | 系统盘、数据盘和生命周期统一管理，降低客户数据迁移成本，提升 SLA |
| 可视化排障 | 已支持弹性裸金属控制台能力，依赖镜像内 agent / VNC 组件等条件 | 后续在 DPU 场景补齐物理机显示透传后，可进一步提升 GPU 机器启动异常、系统卡死、黑屏 / 白屏等问题的可视化定位能力 |
| 高可用 | 依赖传统链路设计 | 支持存储、业务高可用能力演进 |
| 安全隔离 | 依赖网络侧配置 | 为端侧隔离和租户级网络能力打基础 |
这里的 AI 智算，不是说当前 25G DPU 已经承载训练网络或推理网络；更准确地说，是 GPU / 高性能物理机正在成为弹性裸金属资源池的典型使用对象。
这一步的价值很直接：不是让裸金属"第一次变成云资源"，而是让已经云化的弹性裸金属，更容易被交付、被回收、被恢复、被排障。对 AI 智算资源池来说，性能很重要，资源流转效率同样重要。
场景二：大模型推理缓存加速（KV Cache 的下一条高速路）
长文本、智能体、多轮对话正在把大模型推理从"算得快"推向"记得住、取得快"。
推理过程中产生的 KV Cache 会随着上下文长度和并发请求快速膨胀。一旦超出 GPU 显存，就需要在主机内存、SSD 或远端存储之间换入换出。传统路径要经过文件系统、主机内核、CPU 内存和多次数据拷贝，首字延迟（TTFT）和长上下文响应速度都会被拖慢。
这个方向需要双方一起推进：亚格之芯在 DPU 侧推进推理缓存加速能力，把 KV Cache 的文件访问、存储 Client 和数据搬运从主机侧下沉到 DPU；ZStack 侧则需要把这条数据路径纳入弹性裸金属 / 智算资源池的交付、调度和运维体系里。
推理框架看到的是标准文件或存储接口，复杂的协议解析、元数据交互和缓存块传输由 DPU 承担；进一步结合 RDMA / GPUDirect，KV Cache 可以以更短路径进入 GPU 显存，减少主机 CPU 和操作系统软件栈参与。
DPU 不替代 GPU 做推理计算。它更像 GPU 旁边的"缓存数据通道"，让上下文取回更快，让高并发推理少受数据搬运影响。
图中左侧是传统 KV Cache 换入换出路径，右侧是 DPU 侧承接存储 Client、协议解析和缓存块传输后的加速路径。核心变化不是让 DPU 替代 GPU 计算，而是让缓存数据搬运尽量少经过主机 CPU 和操作系统软件栈。
场景三：高性能云盘承载（数据库 / 实时分析）
数据库和实时分析系统对 IOPS、延迟和抖动都很敏感。
传统架构下，NVMe-oF、块存储协议栈和转发路径会消耗宿主机 CPU。业务越重，数据面开销越明显，CPU 越容易被"非业务计算"吃掉。
在 ZStack + 亚格 DPU 的路径里，DPU SoC 内置存储引擎承接协议解析，Guest 以 Virtio-blk 访问后端块存储。目标是让存储路径更短，让主机 CPU 尽量回到业务计算本身。
对比方向（ZStack 实验环境 / 数据库 OLTP 混合读写工况，完整数据随基准报告发布）：
| 指标 | 普通 Ceph gateway 路径 | DPU 加速路径 | 变化 |
|---|---|---|---|
| 4K 随机读 IOPS | 更容易受 gateway CPU、LIO、rbd-nbd、网络转发限制 | 路径更短、队列更直接，通常更高 | 提升更明显 |
| 4K 随机写 IOPS | 受 Ceph 副本 / 落盘和 gateway 中转双重影响 | 通常更高，但仍受 Ceph 副本 / 落盘链路影响 | 有提升 |
| 平均延迟 | BM → gateway → Ceph，多一跳数据面 | DPU / 主机侧更直接访问 Ceph | 延迟更低 |
| 主机 / gateway CPU | iSCSI initiator、TCP 栈、gateway 数据面开销更明显 | 主机侧 virtio-blk 开销更低，gateway 基本不在数据面 | CPU 占用下降 |
架构上，我们做了什么
前面三个场景看起来不太一样：一个讲 GPU 物理机流转，一个讲 KV Cache，一个讲高性能云盘。但落到底层，其实都指向同一件事：DPU 不能只是插在服务器里的一张卡，它必须被 ZStack Cloud 纳入管控面，同时接住网络和存储的数据面。
所以这次适配的重点，不是单独跑通某条链路，而是把 DPU 放进弹性裸金属的完整生命周期里：实例创建、启动、停止、删除时，DPU 侧资源要同步；取消网关节点之后，原来承担转发和存储接入的链路要重构；网络、存储和设备状态也要继续被云平台看见。
ZStack Cloud 与亚格之芯 DPU（YD-025G2-A-A）的适配，分成管控面和数据面两条线。
| 维度 | 做了什么 | 解决什么问题 |
|---|---|---|
| 管控面 | DPU 与物理机统一生命周期，DPU Agent 通过 Ansible 自动部署 | 云平台能看到、能纳管 |
| 存储数据面 | Guest 以 Virtio-blk 直连后端块存储，DPU SoC 承接协议解析 |
降低主机侧存储协议开销 |
| 网络数据面 | DPU 承接 OVS 卸载，业务网络逐步向端侧执行演进 | 减少主机 CPU 数据面负担 |
| 架构简化 | DPU 加速集群取消传统网关节点部署要求 | 减少中转链路和额外节点依赖 |
| 运维体验 | 集群、实例、云盘、网卡等操作继续进入统一控制面 | 保留云平台原有交付体验 |
【架构图建议位置】
插入「ZStack Cloud + 亚格 DPU 融合架构图」。重点标出：ZStack 管控面、DPU Agent、DPU SoC、Guest 实例，以及存储卸载路径和网络卸载路径。
这套设计的重点，不是让云平台少管一点，而是在原有弹性裸金属能力之上，把原来更容易消耗主机和依赖网关的部分，逐步放到 DPU 侧处理。
当前验证范围
以下能力来自 ZStack 实验环境（3 节点集群）的当前验证范围，更大规模验证正在进行中：
| 能力分类 | 具体项 | 状态 |
|---|---|---|
| 集群与节点 | DPU 裸金属集群创建（基于 ZStack 分布式存储） | 已验证 |
| 弹性裸金属节点添加 / 硬件信息同步 | 已验证 | |
| 实例管理 | 创建 / 停止 / 启动 / 重启 / 关闭电源 | 已验证 |
| 存储 | 数据盘热加载 / 卸载（在线，不停机） | 已验证 |
| 磁盘在线扩容（根盘 + 数据盘） | 已验证 | |
| 网络 | 业务网卡热插拔 | 已验证 |
测试环境：
text
CPU: Intel Xeon Gold 6430
DPU: 亚格之芯 YD-025G2-A-A（固件 v2.1.0，集成 25G 网络接口）
云平台: ZStack Cloud v5.5.16（DPU 支持起始版本）
集群规模: 3 节点（更大规模验证进行中）
存储: ZStack 分布式存储（ZStone）【视频建议位置】
插入「DPU 裸金属实际操作演示视频」，展示 4 个场景：
- 集群创建（向导式）
- 实例启停（控制台统一操作体验）
- 磁盘热加载（在线不重启）
- 业务网卡热插拔
视频不用追求复杂，重点是让读者看到：这些原本容易落到线下工单里的操作，已经进入了云平台控制台。
后面还要补什么
DPU 接进云平台之后，第一步是把原有弹性裸金属能力和 DPU 数据面打通。后面要补的是更完整的云平台能力：
| 方向 | 想做什么 | 状态 |
|---|---|---|
| 智算业务网络隔离 | 补齐 VPC、子网、安全组、QoS 等租户级业务网络能力，减少核心交换机人工配置依赖 | 规划中 |
| DPU 带外监控 | DPU 侧 CPU / 内存 / 网卡 / 磁盘指标采集，接入 ZStack 统一监控视图 | 进行中 |
| 网卡 / 磁盘 QoS | 管控下发网卡限速、磁盘 IOPS / 带宽限制 | 进行中 |
| 推理缓存加速 | 硬件 Virtio-FS 卸载、存储 Client 下沉、RDMA / GPUDirect 数据直达 | 进行中 |
| 存储路径故障切换验证 | 覆盖单存储节点宕机、客户端 IO 抖动、路径切换、恢复时间区间 | 进行中 |
| 更大规模集群验证 | 验证数十节点以上集群下的管控面性能和数据面稳定性 | 规划中 |
写在最后
DPU 的价值，不只是把某个 benchmark 数字跑高。
对 ZStack Cloud 来说，弹性裸金属的云化交付原本已经成立。DPU 要补上的，是性能路径、网关依赖、硬件兼容、安全隔离和高可用这些更底层的问题。
这也是 ZStack × 亚格之芯这次适配的方向：让 DPU 不只是服务器里的一张卡，而是弹性裸金属回归性能本身的一条数据面路径。云平台继续负责交付和运营，DPU 负责把网络、存储和隔离能力尽量放到更合适的位置。
欢迎关注 ZStack 技术爱好者，获取更多云平台 + 硬件加速的技术实践和前沿探索。
。*