1. 曙光超算平台初体验从登录到资源抢占第一次接触曙光超算平台时我完全被它强大的计算能力震撼到了。但随之而来的是一连串的困惑怎么登录如何抢占资源为什么我的作业总是莫名其妙中断这些问题困扰了我整整两周直到摸清了平台的使用门道。登录超算平台通常有两种方式网页端和命令行。我强烈建议新手从网页端开始因为图形界面更友好。在浏览器输入官方网址后你会看到一个简洁的登录页面。这里有个小技巧如果你的账号同时关联了多个项目记得在登录时选择正确的项目ID否则后续的资源申请可能会失败。资源抢占是使用超算的第一步也是最容易踩坑的环节。平台提供了两种主要方式salloc和sbatch。salloc适合交互式任务比如调试代码或短时间运算。我常用的命令格式是salloc -p wzhdtest -N 1 -n 8 --gresdcu:1这个命令的意思是在wzhdtest分区申请1个节点、8个CPU核心和1块DCU加速卡。注意不同分区的资源配比可能不同比如有些分区要求核卡比为8:1这点一定要提前确认。使用salloc时有个重要细节命令执行后会分配计算节点但需要手动ssh连接到该节点才能使用DCU。比如分配到的节点是b03r4n14就需要执行ssh b03r4n14这里有个大坑保持E-Shell页面常开如果意外关闭终端对应的作业会被系统自动终止。我有次跑了3小时的任务就因为网络波动导致终端断开所有进度都丢失了。对于长时间任务强烈建议使用sbatch提交这个我们后面会详细讲。2. 环境配置的三大雷区与解决方案配置Python环境可能是最让人头疼的环节。我遇到过无数次pip install失败的情况总结下来主要有三类问题环境错配、版本冲突和权限问题。首先是环境错配。超算平台通常预装了多个Python环境比如基础环境(base)和各种框架专用环境(pytorch、tensorflow等)。新手最容易犯的错误是在错误的环境中安装包。正确的做法是先激活目标环境。以PyTorch为例source pytorch_env.sh这个脚本通常包含如下内容source ~/.bashrc conda activate pytorch_1.10 module switch compiler/dtk/22.04.2 LD_LIBRARY_PATH/public/software/apps/DeepLearning/PyTorch_Lib/lib:$LD_LIBRARY_PATH注意module switch命令用于加载特定版本的DTK(DeepToolKit)这是曙光平台的深度学习工具包。如果版本不匹配可能会导致奇怪的运行时错误。版本冲突是另一个常见问题。我有次安装tensorboard时总是失败最后发现是setuptools版本过高(60)。解决方法很简单pip uninstall setuptools pip install setuptools56.1.0建议在安装新包前先用pip list查看已安装包的版本必要时创建新的虚拟环境隔离不同项目。最隐蔽的问题是权限问题。当通过salloc抢占资源后如果在计算节点直接pip install可能会失败。这是因为计算节点的环境权限受限。解决方法很巧妙先logout退出计算节点在登录节点安装好所需包再重新连接计算节点。这个小技巧帮我节省了大量调试时间。3. 作业提交的艺术从手动到自动化经历了多次训练意外中断的痛苦后我彻底放弃了手动运行的方式转向脚本提交。sbatch命令配合SLURM脚本可以完美解决这个问题还能实现作业排队、自动重试等高级功能。一个典型的SLURM脚本(test.slurm)长这样#!/bin/bash #SBATCH -p wzhdtest #SBATCH -N 1 #SBATCH --ntasks-per-node8 #SBATCH --gresdcu:1 #SBATCH -J my_job #SBATCH -o %x.o%j #SBATCH -e %x.e%j # 环境配置 source ~/.bashrc conda activate pytorch_1.10 module switch compiler/dtk/22.04.2 LD_LIBRARY_PATH/public/software/apps/DeepLearning/PyTorch_Lib/lib:$LD_LIBRARY_PATH # 运行命令 python -u train.py --batch_size 32 --epochs 100这个脚本有几个关键点-p指定分区不同分区的资源配额和优先级不同-o和-e分别指定标准输出和错误输出的日志文件-u参数强制Python立即刷新输出缓冲区否则日志文件可能长时间空白提交作业只需一行命令sbatch test.slurm之后可以用squeue查看作业状态squeue -u $USER输出中的R表示正在运行PD表示排队中。如果作业卡在PD状态超过预期可能是分区资源紧张可以尝试换到其他分区。对于需要频繁修改参数的实验我开发了一个小技巧使用环境变量传递参数。修改SLURM脚本的最后一行python train.py --lr $LR --batch_size $BATCH_SIZE然后这样提交作业LR0.001 BATCH_SIZE32 sbatch test.slurm这样就能轻松实现参数化实验而不用每次都修改脚本。4. 异常处理与性能调优即使准备得再充分作业运行中还是会出现各种意外。掌握快速诊断和修复的技巧能大幅提高工作效率。第一个救命命令是hy-smi相当于NVIDIA的nvidia-smi用于查看DCU使用情况。但要注意必须在计算节点上执行常见输出如下------------------------------------------------------- | DCU Utilization Memory Usage | || | 利用率% | 温度 | 功耗 | 显存总量 | 已用显存 | 空闲显存 | | 75% | 65℃ | 150W | 32GB | 24GB | 8GB | -------------------------------------------------------如果发现利用率长期低于30%可能是代码存在性能瓶颈。常见原因包括数据加载速度慢、CPU-GPU通信频繁、batch size太小等。我的优化经验是使用DataLoader的num_workers参数增加数据加载并行度用pin_memoryTrue加速CPU到DCU的数据传输适当增大batch size但要注意不超过显存容量当作业出现异常需要强制终止时千万别直接关闭终端正确的做法是先找到作业IDsqueue -u $USER然后用scancel终止作业scancel JOBID如果作业已经失控可以登录计算节点用ps配合kill终止进程ps -ef | grep 用户名 | awk {print $2} | xargs kill -9但这种方法比较暴力可能导致资源释放不完全建议作为最后手段。日志分析是另一个重要技能。SLURM默认会在脚本所在目录生成两个日志文件.o后缀记录标准输出.e后缀记录错误信息。有个常见问题是日志文件不更新这时可以检查Python命令是否加了-u参数在代码中手动调用sys.stdout.flush()使用tail -f实时查看日志tail -f my_job.o12345最后分享一个监控资源使用的小工具——sacct。它可以显示作业的历史资源消耗sacct -j JOBID --formatJobID,Elapsed,MaxRSS,CPUTime这对优化代码和合理申请资源非常有帮助。比如发现MaxRSS远低于申请的内存下次就可以减少内存请求提高资源利用率。