登录/计算节点资源申请与国产海光 DCU 环境初始化

在 上一篇 中，我们通过免 Root 部署的单文件网盘 Filebrowser，在超算的用户目录下搭建好了舒适的网页端开发环境。接下来，我们将正式进入算力调度核心，聊聊**“如何合理申请超算显卡，并初始化国产海光 DCU 计算环境”**。

这看似简单，但如果不注意资源分配的“潜规则”，代码在加载阶段就会被系统无情强杀。

1. 物理界碑：登录节点 vs 计算节点 ​

很多刚接触超算的朋友会犯一个直观错误：登录上服务器后，看到终端就直接运行 Python 推理/训练脚本，或者敲击显卡管理命令。这种“直觉式”的操作在超算的硬件限制和守护策略下，不仅无法正常运行，甚至会导致进程被系统直接强杀。

1.1 节点分工 ​

超算由大量的服务器节点通过高速网络互联组成，它们被划分为不同的角色：

• 登录节点（Login Node）：如你在终端中看到的 your_username@login04。登录节点只配备了基础的 CPU 和少量的内存，仅供用户用于代码编写、小文件编译、文件传输和作业提交。登录节点上没有计算显卡，且严禁直接跑任何高负载或后台计算程序。一旦 CPU、内存占用过高或运行时间超标，会被系统守护进程直接强杀进程。情节严重或屡教不改者，超算中心会自动锁定/封禁账号。

• 计算节点（Compute Node）：真正插满显卡、提供澎湃算力的节点。用户必须通过作业调度系统发出申请，排队获取计算节点的临时使用权。不同的超算平台会配置不同的作业调度系统（如 Slurm、LSF 等）。

  NOTE

  重要说明：由于使用的这台超算仅配置并支持 Slurm 作业调度系统，因此本系列后续所有资源申请与作业投递操作均只针对 Slurm 展开。

  下表列出了 Slurm 的常用指令，同时附带 LSF 系统的命令对比，以便有其他超算背景的用户对照查阅：

  常用操作	Slurm 调度系统 (当前超算使用)	LSF 调度系统
  交互式资源申请	srun --pty bash (或 salloc)	bsub -Is bash
  批处理作业投递	sbatch <脚本>	bsub < <脚本>
  查看作业与排队	squeue	bjobs
  终止/撤销作业	scancel <作业ID>	bkill <作业ID>

1.2 登录节点的运行行为与潜在风险 ​

在没有显卡资源的登录节点上运行命令或代码，不同的操作会有不同的表现，但铁律是：绝对不要尝试在登录节点跑计算任务。

• 运行深度学习代码（Python）：
  • 若代码没有 CPU 回退机制（如硬编码了 .to("cuda")）：由于登录节点缺乏 /dev/kfd 等硬件设备节点，PyTorch 无法检测到可用 GPU，torch.cuda.is_available() 会直接返回 False，随后在试图调用 GPU 时抛出 RuntimeError: No CUDA GPUs are available 崩溃退出（注：海光官方编译的 PyTorch 已在底层将 DCU 映射为 cuda 接口，硬编码 cuda 的脚本在有卡的计算节点上能无缝运行，但在无卡的登录节点上必然会报错崩溃）。
  • 若代码配置了 CPU 回退保护（如包含 else "cpu"）：程序检测不到 GPU 后，确实会降级到 CPU 模式继续执行。然而，登录节点是全体用户共享的，一旦你跑起高负载的训练/推理，会瞬间占满 CPU。超算系统的守护进程会立刻强杀（SIGKILL）该进程，终端只会留下 Killed。
• 超算账号封禁风险：多次在登录节点上跑高负载 CPU 计算导致公共资源瘫痪，会触发系统自动监控警报，你的超算账号极易被管理员临时锁定或永久封禁。

2. 作业调度与交互式 DCU 资源申请 ​

在调试代码阶段，最方便的方法是申请一个交互式的计算节点，让我们能像在普通 Linux 终端里一样在线调测代码。

2.1 避坑绝杀：千万别漏了 -c（CPU核心数） ​

这台超算采用 Slurm 调度系统。我们使用以下命令交互式地申请一张海光 DCU 显卡：

srun --partition=kshdtest --gres=gres:dcu:1 -c 6 --pty bash

申请成功后，你会发现终端的提示符由 your_username@login03 变成了类似 your_username@e10r3n03，这说明你已成功跃迁到了计算节点！

3. 国产海光 DCU 显卡状态监测 ​

海光 DCU 是国产 GPU 生态的杰出代表，主要基于 AMD ROCm 架构进行底层深度改造，并配有专门的 DTK (Deep learning Toolkit) 开发包^[1]。

进入计算节点后，我们可以敲击国产 GPU 的管理指令 hy-smi（功能和 NVIDIA 的 nvidia-smi 几乎完全一致）：

hy-smi

如果成功输出显卡的温度、显存占用、功耗和 DCU 占用率（GPU 核心型号通常显示为 66a1 等），则说明显卡已经成功“咬住”了。

4. 初始化 PyTorch 运行环境底座与虚拟环境（venv） ​

超算平台通常通过 module 管理器统一提供经过官方调优的底层编译器和计算依赖库。虽然我们可以直接使用系统 Python，但在权限与网络受限的超算环境里，我们强烈建议为项目创建专属的虚拟环境（venv），以隔离不同项目的第三方库，并避免版本冲突。

4.1 前置知识：为什么超算部署第一步是建立虚拟环境 (venv)？ ​

在超算平台上跑 Stable Diffusion 这样庞大的深度学习应用，第一步必须是创建 Python 虚拟环境（venv）。这不仅仅是为了包的隔离，在权限与网络都极度受限的超算环境里，它是解决三大硬伤的物理钥匙：

1. 解决“无 Root 权限”的硬伤：超算上的系统全局 Python 是公共且只读的，普通用户无法安装全局包。在个人目录下初始化 venv，我们能拥有一个完全自主控制的独立沙盒，自由安装所需的第三方包。

2. 规避远古系统环境与包的冲突：超算集群的操作系统底座通常较为老旧（例如 CentOS 7），默认配套的 Python 版本非常低（如 Python 3.7.13）。如果不使用 venv 隔离，直接把最新版依赖堆在一起，很多最新版的依赖库（例如新版 modelscope）会因为引入了 Python 3.8+ 独有的海象运算符（:=）而直接报 SyntaxError 崩溃。venv 能帮我们把特定兼容的包版本（如 modelscope==1.9.5）物理隔离并锁死。

3. “穿透虚拟环境”借调给主环境运行（PYTHONPATH 终极黑魔法）： 这是我们在超算上能够成功生图的最关键一步。在计算节点上正式运行推理时，我们其实并没有激活虚拟环境（甚至会在脚本里显式执行 deactivate 退掉虚拟环境状态），而是使用系统官方的 Python 主环境。

   • 为什么不能直接在 venv 下跑？：因为我们本地 venv 自带的虚拟 Python 找不到超算官方通过 module load 加载的、具有海光加速卡（DCU）物理驱动的满血 PyTorch 环境。
   • 为什么不能直接用系统主环境跑？：因为系统主环境又找不到我们刚才在本地 venv 里为了兼容而降级安装的 diffusers、safetensors 等第三方包。

   为了打破这个“两头不讨好”的死局，我们的终极解法是：在系统主环境下用官方 Python 运行代码，但通过全局环境变量 PYTHONPATH 强行把我们 venv 的包路径“穿透”借调过去：

   bash

   export PYTHONPATH="/public/home/$(whoami)/sd_automation/venv/lib/python3.7/site-packages:$PYTHONPATH"

   1
   

   官方只读的 Python 在启动瞬间，就会在万分之一秒内跨界首选去我们本地的 venv 下找包。这就完美实现了“系统级显卡加速底座”与“个人虚拟环境隔离包”的无缝合体！

4.2 搭建 venv 虚拟环境与配置镜像源 ​

首先，我们在有网的登录节点（Login Node）上，加载超算官方的 PyTorch 运行底座（借用其配套的 Python 3.7.13 运行环境），并在专属的工作目录 ~/sd_automation 下初始化虚拟环境并配置清华源镜像加速：

# 1. 确保在你的工作目录下
mkdir -p ~/sd_automation && cd ~/sd_automation

# 2. 加载官方 PyTorch 运行底座 (借用其 Python 3.7)
module load apps/PyTorch/1.10/dtk-22.04-py37

# 3. 创建并激活你的专属虚拟环境
python -m venv venv
source venv/bin/activate

# 4. 配置虚拟环境内 pip 的清华源镜像全局加速
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

4.3 Python 3.7 专属黄金依赖版本（避坑 puccinialin 编译死锁） ​

由于超算官方 PyTorch 镜像底座配套使用的是较老旧的 Python 3.7 环境。如果在激活虚拟环境后直接运行普通的 pip install，pip 会尝试拉取最新版的第三方组件，这在老旧 Python 3.7 环境下会引发严重编译或兼容故障：

1. safetensors 的 puccinialin 编译死锁：新版 safetensors（如 0.5.3）没有针对 Python 3.7 的预编译 Wheel 包，pip 会自动下载源码并尝试在本地编译。然而，新版源码的构建后端依赖一个在 PyPI 和镜像站中根本不存在的库 puccinialin，导致编译时直接报错死锁：

   ERROR

   ERROR: Could not find a version that satisfies the requirement puccinialin (from versions: none) ERROR: No matching distribution found for puccinialin

2. 新版组件的兼容冲突：最新版 diffusers、accelerate 等包对 Python 3.8+ 及新版 transformers 有硬性依赖，与超算自带的环境冲突。

终极解法：在激活的 venv 环境中，手动指定安装经实测最兼容、最稳定的“黄金版本全家桶”：

# 精准锁定兼容 Python 3.7 且免编译的 Wheel 稳定版
pip install \
    "diffusers==0.21.4" \
    "accelerate==0.20.3" \
    "safetensors==0.4.5" \
    "transformers==4.30.2" \
    "sentencepiece==0.2.0" \
    "requests==2.31.0"

• safetensors==0.4.5：完美避开 puccinialin 编译陷阱，免去本地 Rust/C++ 现场编译，直接以预编译 Wheel 形式秒速完成安装（只要不安装到触发编译的 0.5.3 及以上版本即可）。
• diffusers==0.21.4、accelerate==0.20.3 与 transformers==4.30.2：这一套组合是 Stable Diffusion 在 Python 3.7 时代兼容性非常好的黄金搭配。
• 其他库：sentencepiece==0.2.0（分词器加速依赖，指定版本以防新版编译冲突）与 requests==2.31.0（网络请求支持）。

4.3 终端 Python 联调验证 ​

虚拟环境与依赖包安装完成后，在有卡的计算节点上加载驱动与我们刚装好的虚拟环境，并进入 Python 交互界面进行验证：

# 1. 物理清空 Module 并重新加载官方 PyTorch 底座驱动
module purge
module load apps/PyTorch/1.10/dtk-22.04-py37

# 2. 启动 Python 终端
python

进入 Python 交互界面后，依次输入以下代码：

>>> import torch

# 1. 验证 PyTorch 是否能通过 ROCm/DTK 识别到显卡
>>> print(torch.cuda.is_available())
True

# 2. 获取设备名称
>>> print(torch.cuda.get_device_name(0))
Device 66a1

只要这两个测试顺利通过，就说明我们的国产 DCU 显卡环境已经彻底热身完毕，具备了运行深度学习模型的一切前提！

下一篇，我们将进入终极挑战：“在超算离线网络环境下，如何成功全速下载 Stable Diffusion 大模型，修复 Anything-V5 的离线加载 Bug，并用 Slurm 点火器自动化生图”。