海光DCU部署全攻略：开箱、配置到AI训练的最佳实践｜2026工程化版本

海光DCU部署全攻略：开箱、配置到AI训练的最佳实践｜2026工程化版本

- [0. 先选路线：你部署的不是一台机器，而是一种"运行形态"](#0. 先选路线：你部署的不是一台机器，而是一种“运行形态”)
- - [路线 A（更偏生产）：OpenCloudOS 9 / TencentOS 体系（推荐）](#路线 A（更偏生产）：OpenCloudOS 9 / TencentOS 体系（推荐）)
  - [路线 B（兼容存量）：Ubuntu 20.04（你现网若已定型）](#路线 B（兼容存量）：Ubuntu 20.04（你现网若已定型）)
- [1. 开箱验收清单：先把"硬件不确定性"消掉](#1. 开箱验收清单：先把“硬件不确定性”消掉)
- [2. 从"能跑"到"可管"：我建议你按这个流程工程化](#2. 从“能跑”到“可管”：我建议你按这个流程工程化)
- [3. 路线 A：OpenCloudOS 9（更偏生产的"少折腾"路线）](#3. 路线 A：OpenCloudOS 9（更偏生产的“少折腾”路线）)
- - [3.1 安装要点（按文档思路整理成"可交付步骤"）](#3.1 安装要点（按文档思路整理成“可交付步骤”）)
- [4. 路线 B：Ubuntu 20.04（兼容存量，但要补齐"工程护栏"）](#4. 路线 B：Ubuntu 20.04（兼容存量，但要补齐“工程护栏”）)
- [5. AI 框架与生态：别只盯 PyTorch，国产栈往往更"开箱即用"](#5. AI 框架与生态：别只盯 PyTorch，国产栈往往更“开箱即用”)
- - [5.1 Paddle（飞桨）在 DCU 上的资料更系统](#5.1 Paddle（飞桨）在 DCU 上的资料更系统)
  - [5.2 推理侧：把 vLLM 当成"吞吐放大器"](#5.2 推理侧：把 vLLM 当成“吞吐放大器”)
- [6. 性能优化（不玄学）：你只盯三类瓶颈就够了](#6. 性能优化（不玄学）：你只盯三类瓶颈就够了)
- - [6.1 显存/内存与上下文（训练与推理都逃不开）](#6.1 显存/内存与上下文（训练与推理都逃不开）)
  - [6.2 数据管道（别让 CPU 把 DCU 饿死）](#6.2 数据管道（别让 CPU 把 DCU 饿死）)
  - [6.3 多卡扩展（先稳定，再扩展）](#6.3 多卡扩展（先稳定，再扩展）)
- [7. 故障排除：按"定位链路"处理，不要靠猜](#7. 故障排除：按“定位链路”处理，不要靠猜)
- [8. 交付级资产：把 DCU 环境做成"可搬家"的项目](#8. 交付级资产：把 DCU 环境做成“可搬家”的项目)
- [结语：DCU 部署的终点不是"装完"，而是"长期可维护"](#结语：DCU 部署的终点不是“装完”，而是“长期可维护”)

你是否正在为部署海光 DCU 加速卡而烦恼？或者刚拿到 DCU，不知道从何下手？

我想先把一句"反直觉"的结论放在开头：DCU 部署真正的门槛，不是"装不装得上"，而是"能不能长期稳定复现 + 能不能被团队接手维护"。

所以这篇我按"工程交付"的方式重写：不追求花哨工具链，而是给你一套可复用、可回滚、可扩展 的部署路线，并补齐近期更偏"生产可用"的新变化（例如 OpenCloudOS 9 + 6.6 内核 + DTK 25.04.2 的原生适配路线）。 (docs.opencloudos.org)

0. 先选路线：你部署的不是一台机器，而是一种"运行形态"

我把海光 DCU 的落地分成两条主路线（你可以把它理解为"稳定生产"和"兼容存量"）：

路线 A（更偏生产）：OpenCloudOS 9 / TencentOS 体系（推荐）

OpenCloudOS 文档给出了一条更"发行版原生"的路径：6.6 内核 + DCU 驱动 6.3.16 + DTK 25.04.2 ，并通过 RPM 形态提供驱动、管理工具与上层 AI 组件，目标就是降低兼容性摩擦。 (docs.opencloudos.org)

路线 B（兼容存量）：Ubuntu 20.04（你现网若已定型）

很多单位环境仍在 Ubuntu 20.04 上跑（含"锁内核"的传统做法）。这条路线可以做，但我建议你从第一天就补齐：版本锁定、可复现脚本、容器化封装，否则后续升级/迁移成本会非常高。

一句话：路线 A 追求"原生适配 + 省心运维"，路线 B 追求"兼容历史 + 可控变更"。

1. 开箱验收清单：先把"硬件不确定性"消掉

你拿到卡后的前 30 分钟，别急着装框架，先做三件事：

确认设备识别 ：lspci | grep -i hygon（或按 PCIe 设备信息确认 DCU 被系统识别）
确认管理工具链 ：后续你会用到 hy-smi / rocm-smi 这类工具来做健康检查（温度、功耗、显存、频率）。OpenCloudOS 路线明确用 hy-smi 进行驱动验证，并用 rocm-smi 做 DTK/设备状态确认。 (docs.opencloudos.org)
确认运行形态 ：裸机直装还是容器优先？如果你后面要上 vLLM / PyTorch 多进程并行，容器通常需要配置共享内存（--ipc=host 或 --shm-size），否则会遇到"能跑但随机卡死/吞吐异常"的经典坑。 (GPU Stack)

2. 从"能跑"到"可管"：我建议你按这个流程工程化

用一张 Mermaid 把链路讲清楚------你后面排障也按这条链路逐级定位：
硬件识别 / BIOS / PCIe
驱动安装与验证 hy-smi
DTK安装与验证 rocm-smi/rocminfo
运行形态: 裸机 or 容器
AI框架: PyTorch/TensorFlow/Paddle
训练/推理: 单卡 -> 多卡 -> 集群
工程资产: 镜像/脚本/版本锁定/监控/基准测试

3. 路线 A：OpenCloudOS 9（更偏生产的"少折腾"路线）

如果你有选型权、或新集群从零开始，我更倾向你走这条路线。OpenCloudOS 文档把关键版本写得很明确：

内核：6.6
驱动：hygon-driver-6.3.16（安装后需重启）
DTK：dtk-25.04.2
并给出 hy-smi、rocm-smi 的验证方式。 (docs.opencloudos.org)

3.1 安装要点（按文档思路整理成"可交付步骤"）

安装软件源（EPOL extras）
安装驱动包并重启
重启后用 hy-smi 验证驱动
安装 DTK 包
用 rocm-smi 验证 DTK/设备状态 (docs.opencloudos.org)

你会发现：这条路线的价值不在"命令多简单"，而在于它把驱动/工具链以发行版方式交付，后续打补丁、做运维都更像"标准化IT"。

4. 路线 B：Ubuntu 20.04（兼容存量，但要补齐"工程护栏"）

你原文里强调"断网安装 + 锁内核"是典型的存量环境经验，我认可它在某些场景下能显著降低驱动安装失败概率。

但我建议你把它升级成"工程护栏三件套"：

版本基线文件 ：把 OS / 内核 / 驱动 / DTK / 框架版本写成一份 BASELINE.md
一键自检脚本：开机跑一遍，输出"是否可用"的结论
容器封装：把训练/推理环境固化在镜像里，避免 Python 依赖漂移

为什么我这么强调容器？因为它直接把"复现成本"从"人肉记忆"变成"可执行资产"。而且不少 DCU 相关的实践文档/生态项目也在推动 Docker 优先（尤其在需要 vLLM / PyTorch 并行时对共享内存有明确要求）。 (GPU Stack)

5. AI 框架与生态：别只盯 PyTorch，国产栈往往更"开箱即用"

很多人部署 DCU 的第一反应是"装 PyTorch"。我的建议是：先把你要跑的业务框架定下来，再反推工具链。

5.1 Paddle（飞桨）在 DCU 上的资料更系统

飞桨提供了 DCU 支持说明，明确支持海光 Z100 系列，并给出安装/部署相关指引（包括建议使用官方镜像/安装方式等）。如果你是"训练+推理一体"的项目，Paddle 的这条线往往更省心。 (paddlepaddle.org.cn)

5.2 推理侧：把 vLLM 当成"吞吐放大器"

即使你主要做训练，也建议你提前把推理链路想清楚：

vLLM 在 ROCm 路线里已经把 FP8/FP4、KV cache 量化、连续批处理等优化讲得很清楚（这类优化的核心价值是：更长上下文、更高并发、更少显存压力 ）。 (ROCm Documentation)
容器部署时要特别注意共享内存与进程间通信配置（--ipc=host / --shm-size），否则并行推理会"暗损耗"。 (GPU Stack)

现实经验：训练能跑只是第一步；当你开始做服务化、做并发、做长上下文，推理栈的工程细节会反过来决定你的交付质量。

6. 性能优化（不玄学）：你只盯三类瓶颈就够了

6.1 显存/内存与上下文（训练与推理都逃不开）

训练：gradient checkpointing、混合精度、合理 batch / seq_len
推理：KV cache、上下文长度、并发批处理策略（vLLM 在 ROCm 的 KV cache/量化支持就是为这件事服务）。 (ROCm Documentation)

6.2 数据管道（别让 CPU 把 DCU 饿死）

DataLoader 并行、pin memory、数据预取
尽量避免训练时做重 CPU 预处理（把代价前移到离线）

6.3 多卡扩展（先稳定，再扩展）

单卡稳定：基准测试 + 温度/功耗监控 + OOM 边界确认
再上多卡：DDP/分布式策略 + 网络与共享内存配置（容器尤其要注意） (GPU Stack)

7. 故障排除：按"定位链路"处理，不要靠猜

你可以直接照这套"定位顺序"排：

驱动层 ：hy-smi 能否看到设备、状态是否正常（OpenCloudOS 文档用它做驱动验证） (docs.opencloudos.org)
工具链层 ：rocm-smi / rocminfo 是否正常（文档同样给出验证思路） (docs.opencloudos.org)
框架层：最小 demo 是否能跑通（不要一上来就跑大模型）
并行层：容器 shm / ipc、并发、NUMA、网络
工作负载层：batch、seq_len、混合精度、梯度累计策略

8. 交付级资产：把 DCU 环境做成"可搬家"的项目

我建议你直接用下面这套工程目录，把"环境"当成项目交付物：

text 复制代码

Hygon_DCU_Deploy/
  00_Baseline/
    BASELINE.md                # OS/Kernel/Driver/DTK/Framework 固化
    COMPAT_MATRIX.xlsx         # 兼容矩阵（你自己维护）
  01_Install/
    install_driver.sh
    install_dtk.sh
    post_check.sh              # 一键自检：设备/驱动/DTK/框架
  02_Containers/
    Dockerfile.train
    Dockerfile.infer
    docker-compose.yml
  03_Benchmarks/
    torch_smoke_test.py
    nccl_like_bandwidth_test.md
    logs/
  04_Operations/
    backup_restore.md
    upgrade_strategy.md        # 升级策略：先灰度再全量
    monitoring.md              # 温度/功耗/显存/日志
  05_KnowledgeBase/
    FAQ.md
    Troubleshooting_Playbook.md

这套结构的意义在于：你下一次换服务器/换机房/换系统，不需要"重新踩坑"，而是"复制项目"。

结语：DCU 部署的终点不是"装完"，而是"长期可维护"

如果你只把 DCU 当成"插上就用的显卡"，你会在第一个版本升级、第一次团队交接、第一次业务并发上来时吃大亏。

把它当成一个工程系统交付，你会越来越省心。