超算中心GPU使用指南：从零掌握算力卡调度与优化

1. 国家超算中心GPU使用指南：从零开始掌握算力卡调度

在国家超算中心使用GPU资源时，很多新手用户都会遇到一个共同困惑：为什么在登录节点执行nvidia-smi命令看不到显卡？命令行操作会不会意外消耗我的GPU算力卡时长？其实这涉及到HPC（高性能计算）环境的基本设计理念。与个人工作站不同，超算中心的计算资源需要通过作业调度系统统一分配，这是保证资源公平使用和高效调度的关键机制。

我刚接触超算时也犯过同样的错误——在登录节点反复尝试运行CUDA程序，结果不仅无法执行，还担心会不会因此被计费。后来才明白，超算环境的设计遵循着严格的资源隔离原则。登录节点（通常以login或admin命名）仅用于文件管理、作业提交等轻量级操作，真正的计算资源（包括GPU）都部署在专门的计算节点上，必须通过Slurm等作业调度系统申请才能使用。

2. 超算中心架构解析：为什么登录节点看不到GPU？

2.1 登录节点 vs 计算节点

所有正规的超算中心都会将节点划分为两种角色：

• 登录节点（Login Node）：提供SSH接入、文件编辑、作业提交等基础功能
• 计算节点（Compute Node）：实际运行计算任务，配备GPU、大内存等硬件资源

这种隔离设计主要基于三个考虑：

1. 资源公平性：防止单个用户独占共享资源
2. 系统稳定性：避免计算任务影响关键服务
3. 计费准确性：确保资源使用可精确计量

2.2 GPU资源申请机制

超算中心的GPU资源就像酒店房间——不能随意进出，必须通过前台（调度系统）登记使用。以Slurm为例，关键参数包括：

bash复制--gres=gpu:1       # 申请1块GPU
--cpus-per-task=4   # 每个任务配4个CPU核
--mem=16G          # 申请16GB内存

这些参数不仅决定资源分配，也是计费依据。我曾见过用户因为漏写--gres参数，导致作业虽然运行但无法调用GPU，白白浪费计算时间。正确的做法是提交作业前用scontrol show partition查看分区配置，或直接咨询管理员获取推荐参数。

3. GPU使用全流程实操指南

3.1 交互式调试模式

当需要测试环境或调试代码时，交互式作业是最佳选择。以下命令申请1块GPU并进入bash shell：

bash复制srun -p hx2hdtest -N 1 --gres=gpu:1 --ntasks-per-node=1 \
     --cpus-per-task=4 --time=01:00:00 --pty /bin/bash

进入交互环境后，建议立即执行以下检查：

1. nvidia-smi 确认GPU可见性
2. nvcc --version 检查CUDA版本
3. python -c "import torch; print(torch.cuda.is_available())" 测试PyTorch环境

特别注意：交互式会话会持续占用资源直到超时或手动退出。我曾因为忘记退出导致GPU卡被占用8小时，不仅影响他人使用，还消耗了大量算力卡时。建议设置合理的--time参数，并在调试完成后及时输入exit退出。

3.2 批处理作业模式

正式计算任务应该使用批处理作业。下面是一个完整的Slurm脚本示例（保存为gpu_job.slurm）：

bash复制#!/bin/bash
#SBATCH -p hx2hdtest          # 指定分区
#SBATCH -N 1                  # 1个计算节点
#SBATCH --gres=gpu:2          # 申请2块GPU
#SBATCH --ntasks-per-node=1   # 每个节点1个任务
#SBATCH --cpus-per-task=8     # 每个任务8个CPU核
#SBATCH -t 24:00:00           # 最大运行时间
#SBATCH -o %j.out             # 输出日志
#SBATCH -e %j.err             # 错误日志

# 加载软件环境
module load cuda/11.7
source activate py38

# 运行Python脚本
python train.py --batch-size 256 --epochs 100

提交作业后，可以通过以下命令监控状态：

bash复制squeue -u $USER           # 查看自己的作业
sacct -j <JobID>          # 查看作业详情
scancel <JobID>           # 取消作业

4. 常见问题排查与优化技巧

4.1 GPU无法识别问题处理

当作业已经运行但GPU不可用时，按以下步骤排查：

1. 确认Slurm脚本包含--gres=gpu:N参数
2. 检查计算节点是否实际配备GPU（部分集群有混合节点）
3. 验证驱动兼容性：计算节点的NVIDIA驱动版本应≥本地CUDA Toolkit要求

我曾遇到过一个典型案例：用户本地开发环境使用CUDA 11.7，但计算节点仅支持CUDA 11.4。解决方案是在Slurm脚本中添加：

bash复制module load cuda/11.4

4.2 资源使用优化建议

根据不同类型的计算任务，推荐以下配置策略：

对于数据密集型任务，还可以通过以下方式提升效率：

• 使用/tmp作为临时文件存储（计算节点本地SSD通常更快）
• 采用并行数据加载（特别是PyTorch的num_workers参数）
• 启用CUDA Graph减少内核启动开销

5. 算力卡计费机制详解

5.1 计费规则解析

国家超算中心通常采用"卡时"（GPU×小时）作为计费单位，其计算方式为：

code复制总卡时 = GPU数量 × 实际使用小时数

例如使用2块GPU运行3.5小时，则消耗7卡时。

关键注意事项：

1. 登录节点操作不计费：文件编辑、作业提交等操作不会消耗算力卡时
2. 精确到秒计费：大多数集群按秒计费，短时测试成本极低
3. 队列优先级影响：部分中心会对高优先级队列收取额外系数

5.2 资源监控与成本控制

建议定期检查资源使用情况：

bash复制# 查看账户余额（不同集群命令可能不同）
balance_check
# 查询近期作业资源消耗
job_stat -u $USER -d 30

控制成本的实用技巧：

• 使用--time设置合理的时间上限
• 调试阶段可以先申请短时作业（如10分钟）
• 完成计算后及时关闭交互式会话
• 大型作业提交前先用小规模测试验证参数

6. 高级技巧与最佳实践

6.1 环境配置标准化

为避免每次重新配置环境，推荐以下做法：

1. 创建个人conda环境并导出：

bash复制conda env export > environment.yml

2. 使用Singularity容器封装复杂依赖
3. 将常用module load命令写入~/.bashrc

6.2 国产GPU适配方案

对于使用国产GPU（如海光DCU）的超算中心，需要注意：

1. 使用专用PyTorch版本（如DAS1.6优化版）
2. 检查算子的硬件兼容性
3. 可能需要调整内存访问模式

安装国产优化版PyTorch的示例：

bash复制pip install torch==2.5.1+das.opt1.dtk25041 \
  --index-url https://cancon.hpccube.com:65024/4/main/pytorch/DAS1.6

6.3 性能调优实战

通过以下方法可以显著提升GPU利用率：

1. 使用nsys进行性能分析：

bash复制nsys profile -t cuda,nvtx python train.py

2. 启用混合精度训练：

python复制torch.cuda.amp.autocast(enabled=True)

3. 优化数据流水线：

python复制DataLoader(..., num_workers=4, pin_memory=True)

经过这些优化，我曾将一个NLP模型的训练速度提升了3倍，相当于节省了2/3的计算成本。这充分证明了"磨刀不误砍柴工"的道理——在正式运行前花些时间优化配置，往往能获得超乎想象的回报。