一卡多用，资源更高效：华为云 CCE FlexNPU 算力共享实践

导读：将一张昇腾 NPU 按算力和显存进行细粒度切分，让空闲算力在多个模型之间弹性共享，空闲时充分利用，竞争时各得其所。本文介绍华为云云容器引擎 CCE 如何通过 FlexNPU 实现 NPU 算力共享，覆盖核心架构、调度策略、隔离机制、共享效果验证及高校教学落地实践。

▍一、为什么需要 NPU 算力共享

整卡分配与模型真实需求不匹配

Kubernetes 中传统 NPU 资源通常按整卡申请。一个模型即使仅需整卡 20%～30% 的算力，也必须独占一张物理卡。

两张卡均未跑满，但剩余算力难以分配给其他 Pod。对于小参数模型、开发调试、低并发在线服务及教学实验，这种资源浪费尤为突出。

简单共享难以避免相互干扰

若直接让多个进程共享同一张 NPU 而缺乏资源控制，当某一模型请求突增时，将占用更多执行资源，导致同卡其他模型受到干扰。此类"邻居干扰"使无约束共享方案难以满足多业务共存的诉求。

Kubernetes 需要理解算力与显存

传统 Device Plugin 仅告知调度器"该节点有 8 张 NPU"。在算力共享场景中，调度器还需掌握：

• 每张卡剩余多少可保障算力
• 每张卡还有多少可用显存
• 当前已创建多少共享实例
• 新实例应放置于哪张物理卡
• 应优先集中放置还是分散放置

因此，FlexNPU 不仅是节点侧的设备代理，更需要与 Kubernetes 及 Volcano 调度体系深度协同。

▍二、CCE FlexNPU 核心方案

FlexNPU 面向昇腾硬件生态设计，采用 Client-Server 架构将应用发起的 NPU API 调用与物理设备执行解耦。业务容器不再直接持有 /dev/davinciX 等物理设备，而是通过容器内的 FlexNPU Client 发起调用，由宿主机侧的 aclserver 访问真实 NPU。

核心组件包括 flexnpu-device-plugin、flexnpu-runtime、flexnpu-daemon 和容器侧 flexnpu-client，各组件通过共享内存或轻量网络链路完成请求转发。

▲ CCE FlexNPU 整体架构

整体调用流程如下：

当前，FlexNPU 支持将一张昇腾 910B 细粒度切分为多个 NPU 共享实例，关键规格如下：

FlexNPU 对算力并非简单的静态硬切分，而是保障下限、弹性共享——设备存在空闲算力时，业务可使用超过申请值的算力；多个业务同时繁忙时，保障每个实例获得约定的算力份额，避免过载业务影响同卡其他模型。

1. Device Plugin：将 NPU 变为可声明资源

flexnpu-device-plugin 负责将算力与显存抽象为两种 Kubernetes 扩展资源：

资源申请示例：

resources:
   requests:
     volcano.sh/flexnpu-core.percentage: "50"
     volcano.sh/flexnpu-memory.128mi: "300"
   limits:
     volcano.sh/flexnpu-core.percentage: "50"
     volcano.sh/flexnpu-memory.128mi: "300"

其中 flexnpu-core.percentage: "50" 表示申请 50% 的算力保障；flexnpu-memory.128mi: "300" 表示申请 300 × 128 MiB = 37.5 GiB 显存。用户由此可根据模型真实需求精确申请资源，而非只能声明"一张 NPU"。

2. Volcano 调度：算力、显存与实例数的多维约束

CCE Volcano 调度器通过 flexnpuaffinity 插件参与 FlexNPU 资源放置，配置示例如下：

 - name: flexnpuaffinity
   arguments:
     scheduleMode: binpack

CCE Volcano 插件提供 binpack 和 spread 两种调度方式：

以 binpack 为例，调度逻辑为：

调度过程中，插件需同时校验以下约束：

这是一种算力、显存与实例槽位共同参与的多维资源调度，而非简单统计物理卡数量。

3. Runtime：容器启动阶段透明注入

flexnpu-runtime 工作于 OCI 容器创建链路中。Pod 启动时，它将共享实例所需的运行环境注入业务容器：

• FlexNPU Client 动态库
• client.conf 等通信配置
• 共享内存目录
• 共享设备相关配置

业务容器不直接挂载真实物理 NPU，真正持有并访问物理设备的是宿主机侧的 aclserver。

此举将物理设备控制权保留在宿主机侧，降低业务容器直接操作设备、影响同卡其他实例的风险。

4. Client 与 aclserver：API 调用与物理执行解耦

FlexNPU Client 以动态链接库形式存在于业务容器内部。当 PyTorch、vLLM 等上层框架调用 aclInit、aclrtMalloc、aclrtMemcpy、aclrtCreateStream 等接口时，请求首先由 FlexNPU Client 接管，Client 将调用类型、参数、虚拟句柄及数据描述传递给宿主机侧的 aclserver，由后者调用真实 Ascend Runtime 完成执行。

AI 框架和模型代码无需针对算力共享场景重新开发，通过动态库透明接管底层硬件 API，实现上层应用零侵入。

5. 双链路通信降低代理开销

FlexNPU 支持两类通信路径：

相比让大块数据反复经过 Socket 缓冲区，共享内存能够减少内核协议栈处理和进程间数据复制，显著降低代理开销。

▍三、算力共享的关键：空闲可借，竞争有保

FlexNPU 的资源策略并非将一张卡静态切分为若干互不流动的小块。

假设同一张 NPU 上部署两个模型：模型 A 申请 25% 算力，模型 B 申请 75% 算力。此处的比例表达的是竞争状态下的算力保障。

场景一：仅模型 A 有负载

模型 B 当前无任务，卡上存在大量空闲算力。FlexNPU 不会将模型 A 限制在 25%，模型 A 可使用设备上的空闲计算能力，实际使用量最高可达当前可用的整卡算力。

因此，较小的资源声明不会令单独运行的模型被限制在少量资源内。

场景二：模型 A、B 同时繁忙

两个模型均产生大量计算任务时，系统进入资源竞争状态：

• 模型 A：至少获得约定的 25%
• 模型 B：至少获得约定的 75%

模型 A 即使持续过载，也无法明显侵占模型 B 的保障份额。

这套策略可概括为：空闲可借、竞争归还、保障下限。与固定硬切分相比，避免了实例空闲时资源无法利用的问题；与无约束共享相比，又能在竞争时保护不同业务的算力份额。

▍四、显存隔离与算力共享的语义差异

显存和算力是两种性质不同的资源，需区别对待。

显存是容量型资源。 当一个实例申请 32768 MiB 显存时：

32768 MiB ÷ 128 MiB = 256

Pod 中配置为：

volcano.sh/flexnpu-memory.128mi:"256"

该额度约束实例可使用的显存容量上限，一个实例的异常显存申请不会侵占其他实例已分配的显存空间。

算力是可共享的执行资源。 算力随负载动态流动：

因此，FlexNPU 同时实现了：显存容量隔离、算力下限保障、空闲算力弹性复用、同卡业务间算力隔离。

▍五、效果验证：同卡双模型共享推理实测

为验证 FlexNPU 的算力共享与隔离效果，在同一张昇腾 910B 上部署两个模型：

操作演示：基于华为云CCE进行同卡双模型推理延迟实测

测试方法：

1. 持续向 Qwen2-VL-2B-Instruct 发送稳定请求
2. 对 DeepSeek-R1-Distill-Llama-8B 逐步增加请求压力
3. 同时观察两个模型的端到端推理延迟

测试结论：

• 随着 DeepSeek-R1-Distill-Llama-8B 请求压力增加，其自身请求开始排队，推理延迟逐渐上升
• Qwen2-VL-2B-Instruct 的延迟曲线保持平稳，未随 DeepSeek 的过载同步抬升
• DeepSeek 的过载未明显侵占 Qwen 已获得的算力保障

这表明 FlexNPU 在共享物理资源的同时维持了实例间的保障边界。当 Qwen 当前无负载时，DeepSeek 可使用卡上的空闲算力；当 Qwen 恢复请求后，系统重新保障其 75% 的约定份额。

FlexNPU 由此同时实现了：低负载时空闲算力充分流动，高负载时各业务各得其所。

▍六、高校人工智能教学落地：一台服务器支撑 128 名学生同时在线

FlexNPU 已在某高校人工智能教学场景成功落地。

在传统整卡模式下，每名学生的实验环境需独占一张 NPU。同时支撑 128 名学生在线开展模型推理、AI 框架实践和课程实验，所需资源为：

128 名学生 ÷ 每台 8 张 910B = 16 台 8 卡服务器

此方案存在明显问题：

• 单个学生实验通常无法持续跑满整张 910B
• 大量 NPU 在课程等待、代码编辑和低负载推理阶段处于空闲状态
• 实验资源成本高，扩容周期长
• 学生环境之间仍需独立管理和隔离

引入 FlexNPU 后，一台配备 8 张 910B 的服务器可切分出最多 128 个 FlexNPU 实例：

一名学生 → 一个独立 Pod → 一个 FlexNPU 实例 → 独立算力保障 + 独立显存额度

资源规模对比：

服务器数量降至传统方案的 1/16。

教学任务具有典型的间歇性特征：编辑代码 → 等待 → 启动模型 → 短时推理 → 查看结果。并非所有学生都会在同一时刻持续占用设备。FlexNPU 在保障各学生基本算力的同时，将暂时空闲的 NPU 能力提供给正在执行实验的实例，契合教学负载的真实使用规律。

同时，每个学生的实验运行于独立 Pod 和共享实例中：

• 显存额度相互隔离
• 算力竞争时有最低保障
• 单个学生任务异常或过载不会无限挤占其他学生的算力
• 教师可通过 Kubernetes 统一创建、回收和管理实验环境

对于高校而言，此模式不仅降低了硬件投入，也使课程资源能够按班级规模快速交付，提升实验环境的可管理性和并发能力。

▍七、典型适用场景

▍八、总结

传统整卡分配模式难以适应小模型推理、开发测试、人工智能教学等细粒度资源需求；无约束共享虽可提高利用率，却易产生相互干扰。

华为云 CCE FlexNPU 将算力共享、显存隔离与云原生调度统一于同一套体系，其核心价值在于：

• 细粒度切分：算力最小支持 1%，显存以 128 MiB 为单位
• 弹性共享：无竞争时，实例可使用更多空闲算力
• 算力保障：资源竞争时，保障各实例的算力份额
• 显存隔离：防止实例越界占用其他业务的显存
• 云原生调度：通过 Device Plugin 与 Volcano 实现声明式申请与自动放置
• 透明接入：Client-Server 架构，上层模型代码无需修改
• 规模化交付：单卡最多 32 个实例，单机最多 128 个实例

在某高校人工智能教学项目中，一台 8 卡 910B 服务器通过 FlexNPU 支撑了 128 名学生同时在线，而传统整卡方案实现相同规模需 16 台 8 卡服务器。

FlexNPU 的价值不仅在于将一张物理卡切分为更多实例，更在于：让多个业务共享同一张 NPU 时，空闲算力能够充分流动，资源竞争时又能守住各自的算力份额。

参考资料

[1] 华为云 CCE 官方文档: https://support.huaweicloud.com/cce/

[2] Volcano 调度器项目主页: https://volcano.sh/

关注魔方公众号，获取更多前沿资讯