企业官网建设流程全解析

“我在超算上敲了几条命令，是不是就算力卡就不够了？” “ssh上去看半天没显卡，要不要赶紧退出？” 问这两个问题的人特别多，尤其是第一次接触国家级超算平台的用户。面对一个“命令行 + 算力卡 + 显卡”的环境，不熟悉调度系统的话，确实容易心里发毛。这篇文章就把这件事彻底说清楚：命令行到底消耗不消耗算力卡，找不到显卡到底怎么回事，以及什么时候该退出、什么时候根本不用退出。

1. 先确认你站在哪里：登录节点与计算节点的本质区别

1.1 超算上“命令行”的位置

大部分超算中心的使用方式是：你通过SSH登录到一台登录节点。登录节点是什么？说得直白点，它就是一个“门卫室”，给你敲命令、编辑代码、提交作业用的。门卫室里有电脑，有网线，但通常没有GPU显卡，更不承担大规模计算任务。

你在登录节点输入ls、cd、vim、python这些命令，走的全是CPU和内存，和算力卡（GPU）没有半毛钱关系。算力卡在这套体系里更像是“车间里的机床”，你在门卫室里写字、打电话、填单子，机床当然不会因为你填了一张单子就凭空消耗一个小时的电力。

真正要让机床转起来，你得通过作业调度系统（比如超算中心最常见的slurm）把任务提交到计算节点上去。只有计算节点上才挂着用户能使用的GPU。

1.2 为什么输入shell命令看不到显卡

很多人的第一反应是登录后执行nvidia-smi，结果屏幕提示command not found，或者看到“No devices were found”，心里就慌了：“是不是我的权限有问题？是不是显卡驱动没装？是不是算力卡被前人占光了？”

都不用慌。绝大多数超算登录节点压根没装GPU驱动工具，或者即使装了也不会向普通用户暴露任何GPU设备。看不到显卡，99%的情况不是因为你的问题，而是因为你根本还没“进入”有显卡的房间。

打个比方：你到了公司大楼的前台，问前台“怎么没有会议室投影仪”，那是因为会议室在楼上，你得先申请工牌、登记会议室，走进去才能看到投影仪。超算的命令行环境也一样，登录节点和计算节点是两个完全不同的“楼层”。

2. 命令行到底消耗不消耗算力卡

2.1 CPU、GPU、算力卡的关系

先把概念捋一下。CPU负责通用计算和系统调度，GPU（也就是俗称的显卡、算力卡）负责大规模并行浮点运算。云上也好、超算中心也好，说的“算力卡”通常就是GPU加速卡，比如NVIDIA的A100、V100、L20、H100这些。

命令行本身是交互式的，是一连串短小的操作，走的是CPU和内存。哪怕你在终端里疯狂按回车，消耗的也只是登录节点的极少CPU资源。算力卡的计费单位是“卡时”，算法是“GPU卡数量 × 使用时长”。你在终端里输入几个字符、执行一个python脚本打印hello world，这个过程中没有GPU参与计算，自然不产生卡时消耗。

那为什么有人会在账单里看到自己“消耗了算力卡”？最典型的原因有三种：

• 你提交了GPU计算任务，任务排队、加载模型、前向推理全程都在占用GPU。
• 你申请了一个交互式计算节点，然后开着这个会话摸鱼，节点一直在那等你，吊着GPU不放。
• 你在登录节点上跑了一个多进程并行程序，里面某些进程绑定了GPU探活逻辑（比如import了torch并调用了cuda()），虽然你没显式跑模型，但驱动已经初始化了显卡。

第三种情况是很多人忽略的。import torch本身不会占GPU，但如果你的代码里调用了torch.cuda.is_available()或者tensor.cuda()，程序会尝试访问设备，一旦初始化了CUDA上下文，那块卡就开始被“占用”着。你在超算上跑一个字符串处理脚本，里面不小心引用了深度学习库并执行了设备检查，再赶上脚本是多进程循环跑，算力卡就会被莫名挂住。

2.2 哪些“命令行行为”确实会占用算力

一张表看清楚：

这个表格你可以直接存下。以后在超算上干活，判断“我这条命令到底费不费卡”，先问自己一个问题：这个操作有没有真正让GPU驱动参与工作？

2.3 算力卡的调度方式（SLURM等）

超算中心的算力卡不是“谁看见谁用”，而是通过调度系统统一管理。国内超算用得最多的是slurm，少数用PBS或者自研调度系统。

• squeue：查看当前所有排队和运行中的作业。
• sinfo：查看所有分区（队列），比如GPU分区、CPU分区。
• srun：以交互方式申请计算节点。
• sbatch：提交批处理脚本。
• scancel：取消作业。

这种模式下，算力卡的“消耗”基本等于“你申请的作业占用了多少卡多久”。命令行本身不消耗算力卡，但命令行提交的那个作业消耗算力卡。搞清楚这一点，比纠结“命令会不会烧卡”重要得多。

3. 找不到显卡的真正原因与排查步骤

3.1 nvidia-smi命令的经典结果

你在终端输入nvidia-smi，可能遇到三种典型输出：

结果A：command not found说明登录节点压根没安装NVIDIA驱动。这不代表计算节点没有GPU，只是说你所在的“楼层”不提供显卡视野。

结果B：有输出但显示0张GPU说明节点安装了驱动，但当前登录节点没有任何GPU被分配给你。这是很正常的隔离策略——超算平台不会让用户在登录节点直接使用生产GPU。

结果C：能看到其他用户占用的GPU少部分超算登录节点会有调试卡或共享卡。这时候你要留意，nvidia-smi默认显示的是每个GPU的整体利用率，里面可能混了别人的任务。

无论哪种结果，都不能断定“这台超算没有算力卡”或者“我是不是把卡的额度用光了”。正确的做法是查调度系统。

3.2 交互式作业与批处理作业的区别

超算上使用GPU主要有两种姿势：

交互式作业：适合调试模型。命令一般长这样：

srun --partition=gpu --gres=gpu:1 --cpus-per-task=4 --time=02:00:00 --pty bash

这条命令的意思：向gpu分区申请1张GPU卡、4个CPU核、2小时时长，然后给我开一个交互式终端。进去之后再执行nvidia-smi，就能看到属于自己的那张卡了。

批处理作业：适合长时间训练。写一个脚本：

#!/bin/bash #SBATCH --partition=gpu #SBATCH --gres=gpu:2 #SBATCH --cpus-per-task=8 #SBATCH --time=12:00:00 source activate torch_env python train.py

然后用sbatch train.sh提交。这种方式不用挂终端，脚本丢给调度系统后，你可以直接退出SSH，任务照跑。

很多新手在登录节点直接执行python train.py，发现没有GPU，然后开始怀疑“显卡坏了”，这就是没弄明白：你要么通过srun进到计算节点，要么通过sbatch提交作业，而不是在登录节点裸跑。

3.3 如何拿到一个带GPU的计算节点

不同超算的命令细节略有差异，但基本思路一致：

1. 先看有哪些GPU分区：sinfo -p gpu，观察节点是否空闲。
2. 查自己正在排队的作业：squeue -u 你的用户名。
3. 申请交互式节点：srun --gres=gpu:1 --pty bash。
4. 进去后执行nvidia-smi，确认有卡。
5. 不干了记得exit，把节点释放。

这里有个常见误区：交互式会话里执行exit只是退出了终端，如果里面有正在运行的GPU进程，进程不会自动被杀。你需要先确认没有残留进程，然后再退出，否则算力卡会被后台任务一直占着。

4. 是否需要退出？退出前必须做的三件事

4.1 什么时候必须退出

分两种情况。

**情况一：你在登录节点上。**登录节点的环境通常是共享的，超算会限制CPU核数和内存上限。当一个用户占满登录节点CPU时，整个平台的交互体验都会卡。你如果只是敲了几条命令、挂着SSH没动，不构成问题，不用退出。但如果你在登录节点上跑了一个大循环或并发了成百上千个线程，那必须退出或终止进程，否则影响的不只是你一个人。

**情况二：你在交互式计算节点上。**这个节点是你申请来的，按小时计费（或者按配额扣减）。卡开了不用，费用照扣。如果你在这个节点上只是发呆，或者改了代码半天不跑，那就应该马上退出。退出之前，务必确认没有残留GPU进程。

所以，“是否需要退出”的真正答案不是“看命令行”，而是“看有没有占着算力卡不干活”。

4.2 退出和清理的完整操作流程

如果你已经在交互式节点上跑过GPU任务，正确释放流程是：

1. 查看残留进程：

nvidia-smi

看PID那一列，如果有自己的进程，记下来。

也可以用进程视角查：

ps aux | grep python

2. 按需终止：

kill -9 进程PID

如果分不清哪些是残留进程，用关键词精准关闭：

pkill -9 -f train.py

3. 退出交互会话：

exit

4. 确认作业已经从队列里消失：

squeue -u 你的用户名

如果列表为空，说明你已经把资源交还给了调度系统。

5. 如果之前提交的是批处理作业，但想中途取消：

scancel 作业ID

作业ID可以从squeue里看到。

4.3 防止退出后进程还在烧卡的技巧

踩过一次坑你就会长记性：训练进程明明在终端里被Ctrl+C了，结果显卡利用率还是100%。原因通常有两种：

• 程序有子进程，Ctrl+C只杀掉了父进程，子进程还活着。
• 程序用了nohup或写入了systemd服务，脱离了终端控制。

预防方案很朴实：退出前养成检查三连的习惯。

nvidia-smi # 看GPU占用 ps -ef | grep python # 看python进程 squeue -u 用户名 # 看作业状态

三样都没问题，再放心exit。这套动作我称之为“超算洗手”。虽然多花十秒钟，但能避免“卡被白白扣一小时”的惨剧。

5. 实战排查：一个完整的问题定位案例

5.1 典型场景复盘

假设你刚申请了交互式GPU节点，执行nvidia-smi发现：

+-----------------------------------------------------------------------------+ | NVIDIA-SMI 535.129.03 Driver Version: 535.129.03 CUDA Version: 12.2 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 NVIDIA A100-PCIE-40GB Off | 00000000:3B:00.0 Off | 0 | | N/A 45C P0 95W / 250W | 1024MiB / 40960MiB | 51% Default | +-------------------------------+----------------------+----------------------+

注意这行：1024MiB / 40960MiB，GPU总显存40GB，已经被用了10GB，利用率51%。但你明明什么任务都没跑，这是怎么回事？

排查步骤依次来：

1. 先看进程被谁占用：

nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

输出可能是：

PID, process_name, used_memory 12345, python3, 1024MiB

2. 查这个PID是谁的：

ps -p 12345 -o user,pid,cmd

发现一个train.py还在后台运行。这十有八九是上一次会话没有彻底退出，进程挂在后台继续占用显卡。

3. 终止它：

kill -9 12345

再次执行nvidia-smi，显存归零，利用率归零。这时候才算真正释放了算力卡。

5.2 每次登录必查的“资源三连”

见过太多用户在不知道状态下浪费机时，我把这套“资源三连”安利给每个找我问超算问题的朋友：

第一连：查自己的作业在不在跑

squeue -u 用户名

第二连：查当前节点的显卡占用

nvidia-smi

第三连：查自己的python/julia等计算进程

ps -ef | grep -E 'python|julia|train'

三连之后，你对自己“消耗了多少算力卡”这件事会心里有数。很多超算中心的后台日志里，你申请了多久的资源就记多久的账，哪怕你在显卡上睡着了，也算占用。所以“三连”不仅是排查技巧，也是省钱技巧。

5.3 超算用户常见的几个坑

结合这些年实际踩坑经验，顺手整理几个高频问题：

坑一：环境变量遮挡了显卡。

有些超算需要手动加载CUDA模块：

module load cuda/12.2

不加载模块的话，即使你人在计算节点上，nvidia-smi能看到卡，但python里的torch.cuda.is_available()也可能返回False。原因通常是LD_LIBRARY_PATH没指向正确的CUDA库。

坑二：CUDA_VISIBLE_DEVICES被设置成空。

检查一下：

echo $CUDA_VISIBLE_DEVICES

如果输出为空倒还好，如果输出是一个不存在的设备号，比如CUDA_VISIBLE_DEVICES=7，但节点只有4张卡，程序就会报CUDA error: no kernel image is available或者直接找不到设备。

坑三：多个用户共用一张卡。

部分超算为了提升利用率，允许GPU上跑多个小任务。你看到显存被人占了一半，以为“卡坏了”，其实只是“卡被人为切碎了”。遇到这种情况，要么排队申请独占卡，要么用--gres=gpu:1确保拿到一张完整卡。

坑四：登录节点上的进程忘了关。

在登录节点直接跑了python train.py --use_cuda，代码里执行了cuda()调用，虽然会报错，但某些框架在初始化设备时会短暂挂载显卡资源，如果超算登录节点恰好有少量调试卡，可能会造成微小的占用。规范做法是一切GPU任务都走调度系统，绝不在登录节点裸跑。

6. 实操心得：命令行环境下算力卡使用的三条准则

讲了这么多，落到个人体会，其实就三条准则。

**准则一：先定位，再操作。**判断要不要退出、要不要清理，第一步永远是“我当前在哪个节点”。登录节点是CPU环境，计算节点才是GPU环境。在登录节点看不到显卡完全正常，不用为此恐慌。

**准则二：任何GPU任务都要有“生命周期”意识。**从申请节点、激活环境、跑起任务，到终止进程、退出会话、确认释放，每一个环节都得闭环。只开不关，或者关了会话不关进程，就是给后面的人留坑，也是给自己的账号挖坑。

**准则三：评估“消耗”要看调度系统，不要看感觉。**你在终端敲再多的ls也不会让显卡风扇转起来。但如果你申请了卡、开着终端空转，那每一分钟都在消耗配额。真正决定是否退出的是“资源有没有被占用且没有被有效利用”，而不是“我是不是用了命令行”。

那次帮同事排查一个“幽灵占卡”问题，折腾了半小时，最后发现就是他在两小时前跑完推理后，终端直接关了，但python进程留在计算节点上继续占着显存。他后来跟我说：“我一直以为退出终端就等于程序结束了。”这个观念其实是很多超算新手的通病，也是我写这篇文章的最初动机。

最后再送你一个小习惯：每次退出交互节点之前，把你自己的用户名下的python进程全部列出来看一眼。如果有PID对应着一个你早该结束的任务，顺手kill掉，然后看一眼squeue，确认作业列表清爽了再关终端。这套动作落地之后，你在超算上的算力卡消耗会肉眼可见地变少。