2026/9/16 1:12:46
FEATURED · 精选文章 
1. 这不是“点点鼠标就能跑程序”的平台——先搞清它到底是什么南京工业大学高性能计算平台这个名字听起来很技术、很高端但很多刚接触它的同学第一反应是“这不就是个‘超级电脑’我写好代码上传点运行等结果出来不就完了”——这个想法非常普遍也非常危险。我带过三届研究生上机实操几乎每届都有人因为没搞懂平台本质在提交作业或跑实验时卡在第一步甚至误删关键系统文件最后不得不找管理员重置环境。这不是夸张而是真实发生的高频事故。它本质上是一套集中式资源调度系统核心不是“快”而是“公平”与“可控”。你看到的登录界面、作业提交窗口、文件管理器背后是 Slurm 调度器在实时分配 CPU 核心、GPU 显存、内存容量和 IO 带宽。你提交的每一个任务都会被编入一个动态队列和其他几十甚至上百个任务一起竞争资源。它不像你本地笔记本那样“我的程序独占所有资源”而是“我的程序只被允许使用我申请到的那一小块资源”。这个根本差异决定了所有后续操作逻辑为什么不能直接在登录节点编译大型项目为什么提交脚本里必须明确写#SBATCH --cpus-per-task4而不是默认用满为什么srun和sbatch的行为截然不同这些都不是平台“故意设门槛”而是资源隔离机制的必然要求。举个生活化类比它就像大学里的公共自习室管理系统。登录节点相当于“前台登记处”你只能在这里填表写脚本、查空位看队列状态、领号牌提交作业。真正的学习计算必须去指定的座位计算节点完成。如果你赖在登记处写一整天论文在登录节点跑耗时程序不仅自己卡顿还会让后面排队的同学无法登记影响他人登录响应。而“座位”是按需分配的——你申请4个座位4核CPU系统就给你腾出4个连座你申请一块带独立电源的VIP座位1块A100 GPU系统就为你锁定那台特定机器上的显卡资源绝不允许别人插手。这种“预约制物理隔离”的设计保证了全校师生能稳定、公平地使用有限的硬件资源。所以“基础使用指南”的第一课从来不是教你怎么敲命令而是帮你建立对平台底层逻辑的正确认知。跳过这一步后面所有操作都像在没学骑车规则的情况下直接上路——表面看能动但随时可能翻车。尤其对计算机科学与技术专业的同学来说理解这套调度机制本身就是对分布式系统、资源管理、并行编程等核心课程知识的一次实战印证。分数线再高如果不会用学校提供的这台“超级杠杆”你的科研效率可能反而不如隔壁学院熟练使用平台的本科生。提示平台首页通常会显示当前集群负载率如 CPU 使用率 62%、GPU 空闲数 3/8。这个数字不是“剩余算力百分比”而是过去5分钟内所有节点的平均占用统计。它不能预测你提交后多久能运行但能帮你判断是否该避开高峰时段如工作日9:00-11:00大量课程实验集中提交。2. 登录与环境准备——三个必须亲手验证的“安全检查点”很多人以为拿到账号密码ssh 连上服务器就万事大吉。实际上从成功登录到真正能提交第一个作业中间至少有三个关键检查点缺一不可。我见过太多人卡在第二步反复重装编译器却不知问题出在环境变量上。2.1 验证SSH连接与基础权限首先确保你使用的是学校统一认证的账号通常是学号或工号而非个人邮箱别名。连接命令为ssh -p 2222 usernamehpc.njtech.edu.cn注意端口号2222是平台专用端口不是默认的22。首次连接会提示确认服务器指纹输入yes即可。登录成功后第一时间执行whoami hostname pwd这三条命令分别验证whoami确认当前用户身份无误避免因多账号切换导致权限混乱hostname返回类似login01.hpc的主机名证明你确实在登录节点而非误连到其他测试机pwd显示当前路径应为/home/username这是你的个人主目录所有文件操作必须在此或其子目录下进行。绝对禁止在/tmp或/scratch等临时目录下长期存放代码或数据——这些目录会被定时清理且不备份。注意登录节点严禁运行任何计算密集型任务如python train.py、make -j8。平台监控脚本会自动检测CPU占用超5分钟且持续高于80%的进程并强制终止。这不是系统故障而是保护机制。2.2 检查模块化环境Modules是否生效南京工业大学HPC采用 Environment Modules 管理软件环境。这意味着 Python、GCC、CUDA 等工具不是全局安装的而是以“模块”形式按需加载。登录后执行module avail你会看到一长串列表如python/3.9.7,gcc/11.2.0,cuda/11.7。这说明模块系统正常。但此时你并没有任何环境——所有命令如python、gcc都不可用。必须手动加载module load python/3.9.7 gcc/11.2.0验证是否成功python --version # 应输出 Python 3.9.7 gcc --version # 应输出 GCC 11.2.0关键经验不要试图用sudo apt install或pip install --system安装软件。所有依赖必须通过module load加载官方预编译模块或在自己的$HOME目录下用pip install --user安装。后者安装的包会自动加入PYTHONPATH但仅对当前用户有效。2.3 验证存储空间与配额平台为每位用户分配三类存储空间Home 目录/home/username容量小通常50GB用于存放代码、配置文件、小数据集支持每日快照备份Work 目录/work/username容量大通常2TB用于存放训练模型、中间结果、大型数据集不备份但保留周期长90天Scratch 目录/scratch/username容量最大通常5TB用于临时计算缓存不备份且每周自动清理空闲超7天的文件。执行以下命令检查实际使用情况df -h /home /work /scratch quota -u usernamedf -h显示各挂载点总容量与已用空间quota则显示你在/work和/scratch的硬性配额限制如block quota: 2.0T/2.0T。一旦达到上限sbatch提交会直接失败报错No space left on device。此时必须手动清理旧文件不能依赖管理员扩容——配额是全校统一分配策略个人无法突破。3. 作业提交的核心逻辑——为什么你的脚本总在“Pending”状态Slurm 是南京工业大学HPC的调度引擎它把所有计算请求当作“作业”来管理。新手最常问的问题是“我提交了脚本为什么状态一直是PENDING是不是系统坏了” 其实90%的情况都是作业脚本本身未满足调度条件。下面拆解三个决定性因素。3.1 资源申请必须精确匹配硬件拓扑平台计算节点并非均质。目前主力节点分两类CPU 节点每台 64 核 CPU 256GB 内存适合 MPI 并行或高内存需求任务GPU 节点每台 2 块 NVIDIA A100 80GB GPU 48 核 CPU 512GB 内存适合深度学习训练。你的脚本中#SBATCH参数必须与目标节点硬件严格对应。例如申请2块GPU#!/bin/bash #SBATCH --job-namemy_train #SBATCH --partitiongpu # 必须指定gpu分区否则默认在cpu分区排队 #SBATCH --gresgpu:2 # 明确申请2块GPU #SBATCH --cpus-per-task24 # 每个GPU绑定12核CPU符合A100节点拓扑2×12核 #SBATCH --mem384G # 总内存申请不能超过节点总量512G但需预留系统开销 #SBATCH --time24:00:00 # 最大运行时间超时自动终止常见错误忘记--partitiongpu导致作业进入CPU队列永远等不到GPU资源--cpus-per-task48—— 虽然节点有48核但2块GPU共享48核若申请48核则无法分配需留出系统进程核--mem512G—— 实际可用内存约490G超限会导致调度拒绝。3.2 作业依赖与队列策略的真实含义平台设置了多个优先级队列short最长运行2小时用于调试、快速验证normal默认队列最长7天long最长30天需单独申请权限gpu专供GPU任务资源紧张时优先级略低于normal。PENDING状态的深层原因往往藏在squeue -u username的输出里。例如JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 12345 gpu my_train username PD 0:00 1 (Resources)(Resources)表示资源不足但具体缺什么执行scontrol show job 12345 | grep Req输出可能显示ReqNodeMatchList: gpu-a100-03 ReqMem: 384G这说明调度器已锁定目标节点gpu-a100-03但该节点当前内存不足384G可能被其他作业占用。此时你有两个选择降低--mem申请值如改为320G增加匹配成功率改用--nodelistgpu-a100-02指定另一台空闲GPU节点需先用sinfo -p gpu查看节点状态。3.3 交互式作业srun与批处理作业sbatch的本质区别很多同学用srun --pty bash开启交互式终端以为可以像本地一样自由操作。这是巨大误区。srun分配的是独占式资源一旦你启动了srun --gresgpu:1 --cpus-per-task8 bash这1块GPU和8个CPU核心就完全属于你直到你退出exit或超时。期间其他人的作业无法使用这些资源。而sbatch提交的是批处理作业由Slurm统一调度、排队、启动。它更高效也更符合平台设计初衷。正确的工作流应该是用srun快速测试单次命令如srun nvidia-smi查GPU状态用sbatch提交完整训练脚本含错误重试、日志记录、资源监控绝不在srun开启的终端里运行长时间任务如python train.py这会浪费资源且易中断。4. 文件IO与数据管理——那些让你训练速度慢10倍的隐藏瓶颈在HPC上数据读取速度往往比GPU计算速度更能决定整体效率。我帮一位做医学影像分割的同学优化时发现他的U-Net训练吞吐量只有理论值的35%。排查后发现问题不在模型而在数据加载方式——他把原始DICOM文件直接放在/home目录用PyTorchImageFolder逐帧读取导致I/O成为绝对瓶颈。4.1 存储类型与访问模式的匹配原则存储位置适用场景I/O 特性关键限制/home/username代码、配置、小数据集1GB高可靠性支持快照容量小I/O带宽低约50MB/s/work/username训练数据集、模型权重、中间结果高吞吐约1.2GB/s低延迟不备份需自行管理生命周期/scratch/username临时缓存、预处理中间文件极高吞吐约3GB/sSSD加速自动清理不保证持久性正确做法将原始数据集如ImageNet压缩包解压到/work训练时用torchvision.datasets.ImageFolder(root/work/imagenet)直接读取若需预处理如resize、normalize将处理后的TFRecord或LMDB格式数据存入/scratch训练时从这里读取绝对禁止在/home下读取大型数据集——这会触发NFS协议的多次网络往返严重拖慢速度。4.2 数据加载的实操优化技巧PyTorch 用户务必启用以下参数train_loader DataLoader( dataset, batch_size32, num_workers8, # 工作进程数建议申请的CPU核数/2 pin_memoryTrue, # 将数据预加载到GPU显存减少CPU-GPU传输延迟 prefetch_factor2, # 预取批次数量缓解I/O等待 persistent_workersTrue # 复用worker进程避免重复fork开销 )其中num_workers是关键。若你申请了--cpus-per-task24则num_workers设为12最佳。设为24会导致进程间竞争CPU反而降低效率设为4则I/O带宽未充分利用。4.3 跨节点数据同步的避坑指南当使用多GPU或多节点训练时如torch.distributed.launch数据必须位于所有节点均可访问的共享存储。平台/work和/scratch是GPFS并行文件系统天然支持跨节点并发读写。但切记所有节点的代码路径必须一致如都用/work/username/project/train.py不要将数据集复制到各节点本地/tmp——这会造成数据不一致且浪费空间使用torch.distributed.init_process_group(backendnccl)时NCCL会自动利用GPFS的RDMA网络加速无需额外配置。一次真实事故某课题组用rsync将数据同步到各节点/tmp结果因同步延迟不同GPU加载了不同版本的数据导致Loss曲线剧烈震荡调试两周才发现根源。后来改用统一/work路径问题瞬间解决。5. 故障排查实战链路——从“作业失败”到定位根因的完整过程作业失败是常态关键在于如何高效定位。我整理了一套标准化排查流程覆盖95%的常见问题。记住永远不要凭直觉修改代码先看日志再查资源最后动代码。5.1 第一步获取原始错误日志不是控制台回显scancel或作业超时后Slurm 会生成两个日志文件slurm-jobid.out标准输出stdoutslurm-jobid.err标准错误stderr。很多人只看.out却忽略.err。真正的错误信息如ImportError: No module named torch、CUDA out of memory几乎全在.err中。执行tail -n 50 slurm-12345.err若日志为空说明作业甚至没启动——问题出在调度阶段而非代码执行。5.2 第二步反向追溯调度日志若.err无内容执行scontrol show job 12345重点检查字段JobState若为FAILED查看Reason如NodeDown表示目标节点宕机StartTime若为Unknown说明从未启动Comment有时管理员会添加人工备注如User quota exceeded。进一步用sacct -j 12345 --formatJobID,JobName,Partition,AllocCPUS,State,ExitCode,MaxRSS查看历史状态。ExitCode是关键0:0表示成功1:0表示脚本执行出错如Python语法错误2:0表示内存溢出OOM Killer终止进程9:0表示被管理员手动取消。5.3 第三步复现与隔离测试假设日志显示CUDA out of memory不要立刻调小batch size。先做隔离测试提交一个最小化脚本只初始化GPU#!/bin/bash #SBATCH --job-nametest_gpu #SBATCH --partitiongpu #SBATCH --gresgpu:1 #SBATCH --cpus-per-task4 #SBATCH --mem32G nvidia-smi python -c import torch; print(torch.cuda.memory_summary())若此脚本能成功运行则问题在你的训练代码若失败则检查是否与其他作业冲突squeue -u username或GPU驱动异常联系管理员。5.4 第四步性能瓶颈的量化诊断当作业“能跑但很慢”用seff 12345获取详细性能报告JobID: 12345 Cluster: hpc User/Group: username/username State: COMPLETED Nodes: 1 Cores per node: 24 CPU Utilized: 12.3 CPU Hours CPU Efficiency: 85.2% of 14.4 CPU Hours Job Wall-clock time: 00:36:22 Memory Utilized: 12.4 GB (3.27 GB/node) Memory Efficiency: 32.6% of 38.0 GB (10.0 GB/node)关键指标解读CPU Efficiency 70%说明计算线程未饱和可能是I/O等待或单线程瓶颈Memory Efficiency 50%申请内存远超实际使用浪费资源可下调--memWall-clock time 远大于 CPU Utilized存在大量空闲等待需检查数据加载或同步逻辑。我曾用此方法帮一位做分子动力学模拟的同学将单次模拟从8小时缩短到3.2小时——根源是--mem128G申请过大导致调度器总分配到较老的、内存带宽更低的节点。下调至64G后自动匹配到新节点带宽提升2.3倍。6. 进阶实践如何让平台真正成为你的科研加速器掌握基础操作只是起点。真正发挥HPC价值在于将其融入科研工作流。分享三个经过验证的进阶策略。6.1 自动化作业模板库手动写#SBATCH参数极易出错。我在/home/username/templates/下建立了标准化模板gpu_train.sh预设A100训练参数2GPU、24CPU、384G内存cpu_mpi.sh预设MPI并行参数64核、256G内存、mpirun -np 64debug_short.sh预设短时调试参数1GPU、4CPU、2G内存、2小时时限。每次新建任务只需cp templates/gpu_train.sh train_001.sh然后修改--job-name和脚本路径。这避免了90%的参数错误也方便团队协作——所有人用同一套基准配置。6.2 日志与结果的结构化管理在作业脚本末尾添加# 记录本次运行的关键参数 echo RUN SUMMARY ${LOGFILE} echo Time: $(date) ${LOGFILE} echo Job ID: $SLURM_JOB_ID ${LOGFILE} echo Node: $(hostname) ${LOGFILE} echo GPU: $(nvidia-smi --query-gpuname --formatcsv,noheader) ${LOGFILE} echo CUDA Version: $(nvcc --version | head -1) ${LOGFILE} echo PyTorch Version: $(python -c import torch; print(torch.__version__)) ${LOGFILE}所有日志统一存入/work/username/logs/按日期和项目分类。这样当你需要对比不同超参的效果时不用翻几十个文件只需grep val_acc /work/username/logs/2024-*/project_x/*.log一键提取。6.3 与本地开发环境的无缝协同HPC不是孤岛。我推荐“本地编辑远程提交”工作流VS Code 安装 Remote-SSH 插件直接连接usernamehpc.njtech.edu.cn在VS Code中打开/work/username/project目录编辑、调试、Git提交全部在本地IDE完成右键点击脚本选择 “Run on Remote” 即可提交作业日志文件自动同步到本地双击即可跳转到报错行。这套方案消除了“写完代码→scp上传→ssh登录→chmod→sbatch”的繁琐步骤将HPC真正变成你本地开发环境的延伸。一位做自然语言处理的博士生采用此法后实验迭代周期从平均1.5天缩短到4小时。最后分享一个真实体会南京工业大学高性能计算平台的价值不在于它有多“快”而在于它提供了可复现、可追溯、可协作的科研基础设施。当你第一次用seff精准定位到内存泄漏当你用模块化环境确保师弟师妹复现你的结果当你用结构化日志在结题报告中清晰展示所有实验参数——那一刻你才真正拥有了平台。它不是一台电脑而是你科研能力的放大器。
南京工业大学HPC平台使用指南：从资源调度原理到作业实战
1. 这不是“点点鼠标就能跑程序”的平台——先搞清它到底是什么南京工业大学高性能计算平台这个名字听起来很技术、很高端但很多刚接触它的同学第一反应是“这不就是个‘超级电脑’我写好代码上传点运行等结果出来不就完了”——这个想法非常普遍也非常危险。我带过三届研究生上机实操几乎每届都有人因为没搞懂平台本质在提交作业或跑实验时卡在第一步甚至误删关键系统文件最后不得不找管理员重置环境。这不是夸张而是真实发生的高频事故。它本质上是一套集中式资源调度系统核心不是“快”而是“公平”与“可控”。你看到的登录界面、作业提交窗口、文件管理器背后是 Slurm 调度器在实时分配 CPU 核心、GPU 显存、内存容量和 IO 带宽。你提交的每一个任务都会被编入一个动态队列和其他几十甚至上百个任务一起竞争资源。它不像你本地笔记本那样“我的程序独占所有资源”而是“我的程序只被允许使用我申请到的那一小块资源”。这个根本差异决定了所有后续操作逻辑为什么不能直接在登录节点编译大型项目为什么提交脚本里必须明确写#SBATCH --cpus-per-task4而不是默认用满为什么srun和sbatch的行为截然不同这些都不是平台“故意设门槛”而是资源隔离机制的必然要求。举个生活化类比它就像大学里的公共自习室管理系统。登录节点相当于“前台登记处”你只能在这里填表写脚本、查空位看队列状态、领号牌提交作业。真正的学习计算必须去指定的座位计算节点完成。如果你赖在登记处写一整天论文在登录节点跑耗时程序不仅自己卡顿还会让后面排队的同学无法登记影响他人登录响应。而“座位”是按需分配的——你申请4个座位4核CPU系统就给你腾出4个连座你申请一块带独立电源的VIP座位1块A100 GPU系统就为你锁定那台特定机器上的显卡资源绝不允许别人插手。这种“预约制物理隔离”的设计保证了全校师生能稳定、公平地使用有限的硬件资源。所以“基础使用指南”的第一课从来不是教你怎么敲命令而是帮你建立对平台底层逻辑的正确认知。跳过这一步后面所有操作都像在没学骑车规则的情况下直接上路——表面看能动但随时可能翻车。尤其对计算机科学与技术专业的同学来说理解这套调度机制本身就是对分布式系统、资源管理、并行编程等核心课程知识的一次实战印证。分数线再高如果不会用学校提供的这台“超级杠杆”你的科研效率可能反而不如隔壁学院熟练使用平台的本科生。提示平台首页通常会显示当前集群负载率如 CPU 使用率 62%、GPU 空闲数 3/8。这个数字不是“剩余算力百分比”而是过去5分钟内所有节点的平均占用统计。它不能预测你提交后多久能运行但能帮你判断是否该避开高峰时段如工作日9:00-11:00大量课程实验集中提交。2. 登录与环境准备——三个必须亲手验证的“安全检查点”很多人以为拿到账号密码ssh 连上服务器就万事大吉。实际上从成功登录到真正能提交第一个作业中间至少有三个关键检查点缺一不可。我见过太多人卡在第二步反复重装编译器却不知问题出在环境变量上。2.1 验证SSH连接与基础权限首先确保你使用的是学校统一认证的账号通常是学号或工号而非个人邮箱别名。连接命令为ssh -p 2222 usernamehpc.njtech.edu.cn注意端口号2222是平台专用端口不是默认的22。首次连接会提示确认服务器指纹输入yes即可。登录成功后第一时间执行whoami hostname pwd这三条命令分别验证whoami确认当前用户身份无误避免因多账号切换导致权限混乱hostname返回类似login01.hpc的主机名证明你确实在登录节点而非误连到其他测试机pwd显示当前路径应为/home/username这是你的个人主目录所有文件操作必须在此或其子目录下进行。绝对禁止在/tmp或/scratch等临时目录下长期存放代码或数据——这些目录会被定时清理且不备份。注意登录节点严禁运行任何计算密集型任务如python train.py、make -j8。平台监控脚本会自动检测CPU占用超5分钟且持续高于80%的进程并强制终止。这不是系统故障而是保护机制。2.2 检查模块化环境Modules是否生效南京工业大学HPC采用 Environment Modules 管理软件环境。这意味着 Python、GCC、CUDA 等工具不是全局安装的而是以“模块”形式按需加载。登录后执行module avail你会看到一长串列表如python/3.9.7,gcc/11.2.0,cuda/11.7。这说明模块系统正常。但此时你并没有任何环境——所有命令如python、gcc都不可用。必须手动加载module load python/3.9.7 gcc/11.2.0验证是否成功python --version # 应输出 Python 3.9.7 gcc --version # 应输出 GCC 11.2.0关键经验不要试图用sudo apt install或pip install --system安装软件。所有依赖必须通过module load加载官方预编译模块或在自己的$HOME目录下用pip install --user安装。后者安装的包会自动加入PYTHONPATH但仅对当前用户有效。2.3 验证存储空间与配额平台为每位用户分配三类存储空间Home 目录/home/username容量小通常50GB用于存放代码、配置文件、小数据集支持每日快照备份Work 目录/work/username容量大通常2TB用于存放训练模型、中间结果、大型数据集不备份但保留周期长90天Scratch 目录/scratch/username容量最大通常5TB用于临时计算缓存不备份且每周自动清理空闲超7天的文件。执行以下命令检查实际使用情况df -h /home /work /scratch quota -u usernamedf -h显示各挂载点总容量与已用空间quota则显示你在/work和/scratch的硬性配额限制如block quota: 2.0T/2.0T。一旦达到上限sbatch提交会直接失败报错No space left on device。此时必须手动清理旧文件不能依赖管理员扩容——配额是全校统一分配策略个人无法突破。3. 作业提交的核心逻辑——为什么你的脚本总在“Pending”状态Slurm 是南京工业大学HPC的调度引擎它把所有计算请求当作“作业”来管理。新手最常问的问题是“我提交了脚本为什么状态一直是PENDING是不是系统坏了” 其实90%的情况都是作业脚本本身未满足调度条件。下面拆解三个决定性因素。3.1 资源申请必须精确匹配硬件拓扑平台计算节点并非均质。目前主力节点分两类CPU 节点每台 64 核 CPU 256GB 内存适合 MPI 并行或高内存需求任务GPU 节点每台 2 块 NVIDIA A100 80GB GPU 48 核 CPU 512GB 内存适合深度学习训练。你的脚本中#SBATCH参数必须与目标节点硬件严格对应。例如申请2块GPU#!/bin/bash #SBATCH --job-namemy_train #SBATCH --partitiongpu # 必须指定gpu分区否则默认在cpu分区排队 #SBATCH --gresgpu:2 # 明确申请2块GPU #SBATCH --cpus-per-task24 # 每个GPU绑定12核CPU符合A100节点拓扑2×12核 #SBATCH --mem384G # 总内存申请不能超过节点总量512G但需预留系统开销 #SBATCH --time24:00:00 # 最大运行时间超时自动终止常见错误忘记--partitiongpu导致作业进入CPU队列永远等不到GPU资源--cpus-per-task48—— 虽然节点有48核但2块GPU共享48核若申请48核则无法分配需留出系统进程核--mem512G—— 实际可用内存约490G超限会导致调度拒绝。3.2 作业依赖与队列策略的真实含义平台设置了多个优先级队列short最长运行2小时用于调试、快速验证normal默认队列最长7天long最长30天需单独申请权限gpu专供GPU任务资源紧张时优先级略低于normal。PENDING状态的深层原因往往藏在squeue -u username的输出里。例如JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 12345 gpu my_train username PD 0:00 1 (Resources)(Resources)表示资源不足但具体缺什么执行scontrol show job 12345 | grep Req输出可能显示ReqNodeMatchList: gpu-a100-03 ReqMem: 384G这说明调度器已锁定目标节点gpu-a100-03但该节点当前内存不足384G可能被其他作业占用。此时你有两个选择降低--mem申请值如改为320G增加匹配成功率改用--nodelistgpu-a100-02指定另一台空闲GPU节点需先用sinfo -p gpu查看节点状态。3.3 交互式作业srun与批处理作业sbatch的本质区别很多同学用srun --pty bash开启交互式终端以为可以像本地一样自由操作。这是巨大误区。srun分配的是独占式资源一旦你启动了srun --gresgpu:1 --cpus-per-task8 bash这1块GPU和8个CPU核心就完全属于你直到你退出exit或超时。期间其他人的作业无法使用这些资源。而sbatch提交的是批处理作业由Slurm统一调度、排队、启动。它更高效也更符合平台设计初衷。正确的工作流应该是用srun快速测试单次命令如srun nvidia-smi查GPU状态用sbatch提交完整训练脚本含错误重试、日志记录、资源监控绝不在srun开启的终端里运行长时间任务如python train.py这会浪费资源且易中断。4. 文件IO与数据管理——那些让你训练速度慢10倍的隐藏瓶颈在HPC上数据读取速度往往比GPU计算速度更能决定整体效率。我帮一位做医学影像分割的同学优化时发现他的U-Net训练吞吐量只有理论值的35%。排查后发现问题不在模型而在数据加载方式——他把原始DICOM文件直接放在/home目录用PyTorchImageFolder逐帧读取导致I/O成为绝对瓶颈。4.1 存储类型与访问模式的匹配原则存储位置适用场景I/O 特性关键限制/home/username代码、配置、小数据集1GB高可靠性支持快照容量小I/O带宽低约50MB/s/work/username训练数据集、模型权重、中间结果高吞吐约1.2GB/s低延迟不备份需自行管理生命周期/scratch/username临时缓存、预处理中间文件极高吞吐约3GB/sSSD加速自动清理不保证持久性正确做法将原始数据集如ImageNet压缩包解压到/work训练时用torchvision.datasets.ImageFolder(root/work/imagenet)直接读取若需预处理如resize、normalize将处理后的TFRecord或LMDB格式数据存入/scratch训练时从这里读取绝对禁止在/home下读取大型数据集——这会触发NFS协议的多次网络往返严重拖慢速度。4.2 数据加载的实操优化技巧PyTorch 用户务必启用以下参数train_loader DataLoader( dataset, batch_size32, num_workers8, # 工作进程数建议申请的CPU核数/2 pin_memoryTrue, # 将数据预加载到GPU显存减少CPU-GPU传输延迟 prefetch_factor2, # 预取批次数量缓解I/O等待 persistent_workersTrue # 复用worker进程避免重复fork开销 )其中num_workers是关键。若你申请了--cpus-per-task24则num_workers设为12最佳。设为24会导致进程间竞争CPU反而降低效率设为4则I/O带宽未充分利用。4.3 跨节点数据同步的避坑指南当使用多GPU或多节点训练时如torch.distributed.launch数据必须位于所有节点均可访问的共享存储。平台/work和/scratch是GPFS并行文件系统天然支持跨节点并发读写。但切记所有节点的代码路径必须一致如都用/work/username/project/train.py不要将数据集复制到各节点本地/tmp——这会造成数据不一致且浪费空间使用torch.distributed.init_process_group(backendnccl)时NCCL会自动利用GPFS的RDMA网络加速无需额外配置。一次真实事故某课题组用rsync将数据同步到各节点/tmp结果因同步延迟不同GPU加载了不同版本的数据导致Loss曲线剧烈震荡调试两周才发现根源。后来改用统一/work路径问题瞬间解决。5. 故障排查实战链路——从“作业失败”到定位根因的完整过程作业失败是常态关键在于如何高效定位。我整理了一套标准化排查流程覆盖95%的常见问题。记住永远不要凭直觉修改代码先看日志再查资源最后动代码。5.1 第一步获取原始错误日志不是控制台回显scancel或作业超时后Slurm 会生成两个日志文件slurm-jobid.out标准输出stdoutslurm-jobid.err标准错误stderr。很多人只看.out却忽略.err。真正的错误信息如ImportError: No module named torch、CUDA out of memory几乎全在.err中。执行tail -n 50 slurm-12345.err若日志为空说明作业甚至没启动——问题出在调度阶段而非代码执行。5.2 第二步反向追溯调度日志若.err无内容执行scontrol show job 12345重点检查字段JobState若为FAILED查看Reason如NodeDown表示目标节点宕机StartTime若为Unknown说明从未启动Comment有时管理员会添加人工备注如User quota exceeded。进一步用sacct -j 12345 --formatJobID,JobName,Partition,AllocCPUS,State,ExitCode,MaxRSS查看历史状态。ExitCode是关键0:0表示成功1:0表示脚本执行出错如Python语法错误2:0表示内存溢出OOM Killer终止进程9:0表示被管理员手动取消。5.3 第三步复现与隔离测试假设日志显示CUDA out of memory不要立刻调小batch size。先做隔离测试提交一个最小化脚本只初始化GPU#!/bin/bash #SBATCH --job-nametest_gpu #SBATCH --partitiongpu #SBATCH --gresgpu:1 #SBATCH --cpus-per-task4 #SBATCH --mem32G nvidia-smi python -c import torch; print(torch.cuda.memory_summary())若此脚本能成功运行则问题在你的训练代码若失败则检查是否与其他作业冲突squeue -u username或GPU驱动异常联系管理员。5.4 第四步性能瓶颈的量化诊断当作业“能跑但很慢”用seff 12345获取详细性能报告JobID: 12345 Cluster: hpc User/Group: username/username State: COMPLETED Nodes: 1 Cores per node: 24 CPU Utilized: 12.3 CPU Hours CPU Efficiency: 85.2% of 14.4 CPU Hours Job Wall-clock time: 00:36:22 Memory Utilized: 12.4 GB (3.27 GB/node) Memory Efficiency: 32.6% of 38.0 GB (10.0 GB/node)关键指标解读CPU Efficiency 70%说明计算线程未饱和可能是I/O等待或单线程瓶颈Memory Efficiency 50%申请内存远超实际使用浪费资源可下调--memWall-clock time 远大于 CPU Utilized存在大量空闲等待需检查数据加载或同步逻辑。我曾用此方法帮一位做分子动力学模拟的同学将单次模拟从8小时缩短到3.2小时——根源是--mem128G申请过大导致调度器总分配到较老的、内存带宽更低的节点。下调至64G后自动匹配到新节点带宽提升2.3倍。6. 进阶实践如何让平台真正成为你的科研加速器掌握基础操作只是起点。真正发挥HPC价值在于将其融入科研工作流。分享三个经过验证的进阶策略。6.1 自动化作业模板库手动写#SBATCH参数极易出错。我在/home/username/templates/下建立了标准化模板gpu_train.sh预设A100训练参数2GPU、24CPU、384G内存cpu_mpi.sh预设MPI并行参数64核、256G内存、mpirun -np 64debug_short.sh预设短时调试参数1GPU、4CPU、2G内存、2小时时限。每次新建任务只需cp templates/gpu_train.sh train_001.sh然后修改--job-name和脚本路径。这避免了90%的参数错误也方便团队协作——所有人用同一套基准配置。6.2 日志与结果的结构化管理在作业脚本末尾添加# 记录本次运行的关键参数 echo RUN SUMMARY ${LOGFILE} echo Time: $(date) ${LOGFILE} echo Job ID: $SLURM_JOB_ID ${LOGFILE} echo Node: $(hostname) ${LOGFILE} echo GPU: $(nvidia-smi --query-gpuname --formatcsv,noheader) ${LOGFILE} echo CUDA Version: $(nvcc --version | head -1) ${LOGFILE} echo PyTorch Version: $(python -c import torch; print(torch.__version__)) ${LOGFILE}所有日志统一存入/work/username/logs/按日期和项目分类。这样当你需要对比不同超参的效果时不用翻几十个文件只需grep val_acc /work/username/logs/2024-*/project_x/*.log一键提取。6.3 与本地开发环境的无缝协同HPC不是孤岛。我推荐“本地编辑远程提交”工作流VS Code 安装 Remote-SSH 插件直接连接usernamehpc.njtech.edu.cn在VS Code中打开/work/username/project目录编辑、调试、Git提交全部在本地IDE完成右键点击脚本选择 “Run on Remote” 即可提交作业日志文件自动同步到本地双击即可跳转到报错行。这套方案消除了“写完代码→scp上传→ssh登录→chmod→sbatch”的繁琐步骤将HPC真正变成你本地开发环境的延伸。一位做自然语言处理的博士生采用此法后实验迭代周期从平均1.5天缩短到4小时。最后分享一个真实体会南京工业大学高性能计算平台的价值不在于它有多“快”而在于它提供了可复现、可追溯、可协作的科研基础设施。当你第一次用seff精准定位到内存泄漏当你用模块化环境确保师弟师妹复现你的结果当你用结构化日志在结题报告中清晰展示所有实验参数——那一刻你才真正拥有了平台。它不是一台电脑而是你科研能力的放大器。 
