Docker 中 privileged: true 的作用与昇腾 NPU 单卡隔离实践

在基于昇腾（Ascend）NPU 的 AI 推理服务部署中，开发者常面临两个关键问题：

1. 为什么容器需要 privileged: true 才能启动昇腾驱动？
2. 如何确保服务只使用指定的 NPU 卡（如第8张卡），避免资源冲突？

本文将深入解析 privileged: true 的本质作用，并介绍如何通过环境变量 ASCEND_RT_VISIBLE_DEVICES 实现精准的 NPU 设备隔离。

---

一、privileged: true 是什么？它做了什么？

在 Docker 或 Docker Compose 中，privileged: true 是一个高权限运行模式。它的核心作用是：授予容器几乎等同于宿主机 root 用户的全部能力。

1.1 默认容器的权限限制

普通 Docker 容器运行在 Linux 内核的多个安全隔离机制之下：

• Capabilities（能力集）：仅保留有限的内核操作权限（如不能挂载文件系统、不能修改网络配置）
• Device Cgroup：默认无法访问 /dev/ 下的设备（如 GPU、NPU、USB）
• Namespaces：隔离进程、网络、用户等视图
• SELinux/AppArmor：强制访问控制策略

这些限制保障了安全性，但也阻碍了需要深度硬件交互的应用（如 AI 加速器驱动）。

1.2 privileged: true 解除了哪些限制？

启用 privileged: true 后，容器获得以下能力：

• ✅ 访问所有主机设备（包括未显式挂载的 /dev/davinci*、/dev/nvidia* 等）
• ✅ 拥有全部 Linux Capabilities（如 CAP_SYS_ADMIN, CAP_DAC_OVERRIDE）
• ✅ 可以挂载文件系统、修改内核参数、访问 debugfs/sysfs
• ✅ 绕过大部分 cgroup 和 SELinux 限制

📌 对昇腾 NPU 而言：CANN 驱动在初始化时需要执行底层 ioctl 调用、访问 /dev/drv_debug、读取 sysfs 信息等操作，这些在非特权容器中常因权限不足而失败（表现为 drvErr=87 或 rtGetDeviceCount failed）。

1.3 使用 privileged: true 的代价

• 安全风险：容器可完全控制系统，一旦被攻破，宿主机暴露
• 资源可见性污染：容器内能看到所有 NPU 卡（davinci0 到 davinci7），即使你只想用一张

因此，不能仅靠 privileged: true 实现设备隔离——它解决了“能不能用”的问题，但没解决“用哪张”的问题。

---

二、如何只使用第8张 NPU 卡？ASCEND_RT_VISIBLE_DEVICES 的作用

昇腾 CANN 提供了一个标准环境变量，用于逻辑上限制进程可见的 NPU 设备：

ASCEND_RT_VISIBLE_DEVICES="7"

2.1 它的工作原理

• 类似于 CUDA 的 CUDA_VISIBLE_DEVICES
• 在驱动层（Runtime）生效，早于任何框架（如 MindSpore、vLLM）初始化
• 设置后，程序调用 rtGetDeviceCount() 将返回 1（而非物理卡总数）
• 唯一可见的设备 ID 被映射为 0，但实际对应物理卡 7

例如：

# 在 ASCEND_RT_VISIBLE_DEVICES="7" 环境下
import torch_npu
print(torch.npu.device_count())        # 输出: 1
torch.npu.set_device(0)                # 实际使用的是物理卡7

2.2 为什么它比设备挂载更可靠？

• 设备挂载（devices）：控制“能否看到设备文件”，但不阻止程序访问其他卡（如果驱动允许）
• ASCEND_RT_VISIBLE_DEVICES：在驱动 API 层直接屏蔽其他设备，即使容器有权限，也无法使用

✅ 这是运行时逻辑隔离，而非文件系统隔离，更符合 AI 框架的使用习惯。

---

三、最佳实践：privileged: true + ASCEND_RT_VISIBLE_DEVICES

结合两者优势，实现 “能跑 + 只用指定卡”：

# docker-compose.yml
services:
  pdf-server-vllm:
    image: your-ascend-image
    privileged: true                      # 确保驱动能初始化
    environment:
      ASCEND_RT_VISIBLE_DEVICES: "7"      # 强制只用第8张卡（ID=7）
    # devices 字段可省略（因 privileged 已暴露全部）
    # 但建议保留关键设备以提高可读性
    devices:
      - /dev/davinci7:/dev/davinci7
      - /dev/davinci_manager:/dev/davinci_manager
      - /dev/devmm_svm:/dev/devmm_svm
      - /dev/hisi_hdc:/dev/hisi_hdc

验证是否生效

1. 容器内检查：

   echo $ASCEND_RT_VISIBLE_DEVICES  # 应输出 7
   ls /dev/davinci*                 # 可能看到所有卡（因 privileged）
   

2. 宿主机监控：

   npu-smi info -t usage -i 7   # 有负载
   npu-smi info -t usage -i 0   # 无负载
   

3. 程序日志：

   • 不再出现 drvErr=87
   • 模型成功加载并推理

---

四、为什么不推荐完全去掉 privileged: true？

尽管从安全角度希望避免 privileged，但在当前昇腾生态中：

• 多数 CANN 版本（尤其 6.x~7.x）依赖特权操作初始化驱动
• 非特权模式需精确挂载数十个设备 + 配置 udev + 关闭 SELinux + 匹配 GID，维护成本高且易出错
• 华为官方示例和 ModelZoo 多数使用 privileged: true

💡 现实建议：在可信内网环境中，privileged: true + ASCEND_RT_VISIBLE_DEVICES 是最稳定、兼容性最好的方案。

---

五、总结

问题	解决方案	原理
昇腾驱动初始化失败	启用 privileged: true	提供完整内核访问权限
容器使用了错误的 NPU 卡	设置 ASCEND_RT_VISIBLE_DEVICES="7"	在驱动层逻辑隔离设备
多服务共享 NPU 集群	每个服务指定不同 VISIBLE_DEVICES	实现资源隔离，避免冲突

通过合理组合这两个机制，你可以在保证服务稳定运行的同时，精确控制 NPU 资源分配，为生产环境提供可靠支持。

记住：

• privileged: true → 解决 “能不能用”
• ASCEND_RT_VISIBLE_DEVICES → 解决 “用哪张”
  二者缺一不可，共同构成昇腾容器化部署的基石。