第一次用超算中心的人十个里有八个会在命令行里犯嘀咕我在这敲敲打打算力卡是不是已经在偷偷烧我的配额了为什么敲个nvidia-smi还提示找不到显卡是不是我压根就不该进来得赶紧退出这问题听着基础但确实卡住了不少人——尤其是从本地实验室搬过来的同学习惯了在自己机器上随便跑一到国家超算中心这种共享环境连呼吸都怕扣费。先说结论在登录节点和计算节点上敲命令行几乎不会消耗算力卡资源而“找不到显卡”多半也不是你的问题是你站错了地方、或者看错了时机。但“要不要退出”这件事确实分情况不能一概而论。这篇文章我把超算中心里命令行、算力卡和“找显卡”这件事从头到尾捋一遍读完你就知道什么时候该慌什么时候该安心干活。1. 先分清你站在哪台机器上登录节点不等于计算节点1.1 登录节点和计算节点到底有什么区别国家超算中心的集群物理上是一大片机器堆在一起但逻辑上严格分成两类角色登录节点和计算节点。这两者的分工完全不一样。登录节点有的地方叫前端机、提交机是你通过 SSH 连上去的第一台机器。它的主要职责是让你做几件事编辑代码、编译程序、管理文件、提交作业、查看作业状态。说白了它是一个“前台”给你一个相对稳定的环境做准备工作。绝大多数超算中心的登录节点都不挂 GPU/加速卡或者只挂极少量的调试卡。因为登录节点是大家共享的如果每个人都上去跑 GPU 计算那调度系统就形同虚设了整个集群都会卡死。计算节点是真正跑活儿的地方。你通过作业调度系统提交任务之后调度器会从资源池里挑一台符合你申请条件的计算节点把 CPU、内存、GPU 这些资源划给你然后你的任务就在那台机器上跑。这个过程通常是隔离的——你自己的作业不会跑到别人的计算节点上别人也占用不了你申请到的资源。所以当你在登录节点上敲nvidia-smi发现“No devices were found”或者“Command not found”这太正常了不是你的账号出问题了而是这台机器本来就没有给你分配显卡。你站在前台当然看不到后厨的灶台。1.2 算力卡从来不是“常驻”在命令行里的很多第一次用超算的人默认了一个模型登录到集群之后整个集群的资源都是透明的我能看到所有显卡所有内存所有核数。实际上完全不是这样。超算中心为了保证公平调度会把资源“藏起来”。你在登录节点上执行nvidia-smi看到的只是登录节点这一台机器的情况。哪怕这个集群里有几百张 A100只要这些卡没有通过作业调度系统分配给你的某个作业你在登录节点上就看不到它们。这就像你去酒店开房前台能看到整个酒店的房态其实你也看不到但你没有拿到房卡之前是进不了任何一间房间的。就算你走到某一间房门口门锁也是开的你也用不了里面的设施。命令行里的“能找到资源”和“能用资源”是两码事。超算环境里只有当你提交了作业、作业开始运行你才“拿到房卡”。这时候你进入计算节点才能看到真实的 GPU 状态。2. 命令行敲命令到底会不会消耗算力卡2.1 算力卡只有在操作系统分配给你之后才存在关于“命令行会不会消耗算力卡”先要理解算力卡在超算中心是如何被使用的。算力卡也就是 GPU/加速卡NVIDIA A100、H800、华为昇腾、寒武纪等在超算中心里不是像 CPU 那样时时刻刻都在被调度的。GPU 是稀缺资源通常按“张”来申请。你通过 Slurm或 PBS 等调度系统提交一个作业在脚本里写--gresgpu:1意思是“请给我分配 1 张 GPU 卡”。调度器会找到一台有空闲 GPU 的计算节点把这张卡绑定到你的作业上。从这一刻起这张卡在这个作业的运行期间内基本是“你的”。那么你在命令行里敲ls、cd、vim、grep这些操作消耗的是什么是 CPU、内存和一点点硬盘 I/O。这些操作发生在你的登录会话或者作业的控制进程里根本不会去碰 GPU 的计算单元。GPU 需要被“用”起来通常是通过 CUDA 之类的运行时库由你的程序代码在计算时去调用。换句话说敲命令这个行为本身几乎不会消耗算力卡。真正消耗算力卡的是你的程序里跑起来的张量运算、模型推理、训练循环。命令行只是一个“遥控器”它不占灶台只有你真正开火做饭才烧燃气。2.2 真正“扣钱”的指标是什么卡时、核时和排队时间超算中心的计费方式通常有两种核时CPU 核数 × 运行小时数和卡时GPU 卡数 × 运行小时数。不同的中心计费粒度不一样但共同点是计费按你申请的作业资源算而不是按你“敲了多少命令”算。举个例子你写了一个脚本申请了 1 张 A100、8 个 CPU 核计划跑 10 个小时。调度器把资源分配给你之后不管你这 10 个小时里是在真正跑训练还是在命令行里发呆调 bug这 1 张卡 × 10 小时的“卡时”都会从你的账户里扣除。有些超算中心还允许你在作业排队期间占用资源但不计算比如运行前检查阶段不计费但绝大多数情况下作业一启动计时就开始了。所以在命令行里敲敲nvidia-smi、看看日志、改改参数这些操作本身不额外计算卡时。但如果你的作业申请了 GPU你却让它空转——比如把训练脚本写成无限循环等待或者挂起了一个交互式 session 却一直不干活——那这些时间照样计费。这才是你最需要心疼的地方。提示很多超算中心提供“调试队列”或者“短作业队列”资源申请时间短比如 1 小时计费单价也更便宜。专门用来做命令行调试、查 GPU 状态、跑小规模测试非常划算。正式跑大任务之前先在调试队列把环境跑通能省下不少正式队列的卡时。2.3 哪些命令会碰 GPU哪些绝对不会为了彻底打消你“敲命令会不会烧卡”的焦虑我列一个实际经验中的分类清单绝对不碰 GPU 的命令ls、cd、cat、grep、find这类文件操作vim、emacs、less这类文本编辑查看git版本管理操作python启动一个什么都没干的解释器只要不 import 深度学习库并执行张量运算squeue、sinfo、scontrol这类调度系统查询命令会碰 GPU 的命令 / 场景在 Python 里执行torch.cuda.is_available()并运行tensor.cuda()或模型.fit()之类的操作直接调用nvidia-smi本身——但要注意nvidia-smi只是读取 GPU 状态它不会让你产生真正的“算力消耗”只是让驱动汇报一下温度、显存占用、利用率。偶尔敲几下完全没问题不用因此退出运行任何基于 CUDA/OpenCL 的推理或训练程序所以你在命令行里正常地「查看显卡状态」这个动作无论是nvidia-smi还是rocm-smi都只是在“看仪表盘”没有烧油。3. “找不到显卡”的三种典型情况你可能只是虚惊一场接下来重点聊聊最让人焦虑的场景明明觉得自己申请了 GPU却在命令行里死活看不到显卡。以我的经验90% 的情况是下面这三种之一。3.1 情况一你在登录节点上直接敲了nvidia-smi前面说过登录节点大概率不带显卡。你 SSH 登录后的默认位置就是登录节点。在这个节点上nvidia-smi的输出要么是特别简短的“No devices were found”要么直接报错Command not found因为登录节点上可能根本没装 NVIDIA 驱动或者驱动只装了核心部分。判断方法敲hostname看看返回的主机名是不是带有login、front字样。如果是基本可以确定你在登录节点上。此时找不到显卡不是你的问题是常规状态。正确处理不用退出也不用慌。你需要通过调度系统申请一个带 GPU 的计算节点然后进入那个节点才能看到显卡。后面的第 4 节会给你具体的命令。3.2 情况二你申请了 GPU但交互式任务没有正确加载很多超算中心支持交互式作业你敲一条srun或salloc命令调度系统直接给你开一个登录到计算节点的 shell。很多同学在这里踩坑——他们确实申请了 GPU但参数写错了或者漏了导致实际分配的计算节点根本没有挂 GPU。举例有的集群默认分区叫gpu有的叫gpu2有的集群--gres的值不是gpu:1而是按型号写A100:1或者a800:1。如果你把分区名写错调度器可能在你不注意的时候给你分配了一个 CPU 节点如果你把--gres写错调度器可能会直接报错拒绝你的任务。更隐蔽的情况是调度器分配的计算节点上有多张 GPU但你的交互式任务进入节点时没有自动设置CUDA_VISIBLE_DEVICES环境变量导致你看到的 GPU 列表为空或者只看到一部分。Slurm 在部分配置下会帮你设置这个变量但不同数据中心环境差异很大。判断方法进入计算节点后先执行echo $CUDA_VISIBLE_DEVICES。如果输出为空再执行nvidia-smi -L列出所有 GPU对比。如果nvidia-smi -L能看到 GPU 但 CUDA 程序说找不到设备多半是环境变量的问题。3.3 情况三你的计算节点是异构节点但任务被分配到无 GPU 的机器超算中心为了提升资源利用率计算节点往往不是清一色的。有的节点有 GPU有的没有还有的节点上有多种型号的 GPU。你申请了 GPU 资源但调度器可能把任务分到了一个没有 GPU 的节点——这通常发生在你的申请参数不够严格、调度器做了“变通”的情况下。这种状态特别气人squeue里明明显示你的作业在运行状态 R你进入计算节点却发现nvidia-smi什么都看不到。这时候不要急着退出先用scontrol show job 作业ID查看你的作业实际占用了哪几个节点、申请了哪些资源。如果确认作业没有绑定到带 GPU 的节点正确做法是取消作业重新提交而不是在节点上继续耗时间。重新提交时把分区名、--gres参数写清楚最好再加一个--constraint参数例如--constraintA100来强制指定 GPU 型号调度器就不会乱分配了。4. 要不要退出先把这几条命令跑一遍再决定“是否退出”是很多用户最纠结的地方。退出怕浪费排到的资源不退出又担心白白烧卡时。实际上你可以用几条命令快速搞清楚自己现在的状态然后做出正确决策。4.1 先看自己在哪台机器上进入命令行后第一件事永远是hostname。如果返回的名称包含login、front之类的字样说明你在登录节点此时没有任何算力卡资源挂在你的会话上你也没有占用任何计算资源谈不上“需不需要退出”——你可以继续在登录节点上编辑代码、提交作业这都是安全的。如果返回的名称是node、cn、gpu之类的字样说明你已经在计算节点上了。那么继续看下一步。4.2 查看你的作业被分配了什么资源使用squeue -u $USER可以列出你当前所有的作业记下你关心的那个作业 ID然后执行scontrol show job 作业ID输出里重点看这几行JobState是RUNNING还是PENDINGNodeList你实际跑在哪个节点Gres这一行列出了作业申请的 GPU 类型和数量例如Gresgpu:A100:1意思是申请了一张 A100NumCPUs/MinMemoryNodeCPU 和内存的分配情况如果JobState是PENDING排队中那你的资源还没有分配此时你敲任何命令都不会消耗卡时等到排到之后会开始计费。如果JobState是RUNNING但Gres显示的申请数量是 0 或者没有 GPU 相关字段说明这次提交的作业本来就没申请 GPU。你可以考虑是否是提交脚本写错了。4.3 交互式 GPU 任务的正确打开方式如果你想要的是“一个能敲命令、能看到显卡、能在里面跑模型的交互式环境”正确姿势是srun --partitiongpu --gresgpu:1 --ntasks1 --cpus-per-task4 --pty bash各参数含义--partitiongpu指定 GPU 分区具体的分区名以超算中心的使用手册为准有的是gpu有的是gpu2、gpu_a100不要照抄--gresgpu:1申请一张 GPU 卡--ntasks1只启动一个任务--cpus-per-task4额外申请 4 个 CPU 核避免模型预处理时 CPU 资源不够--pty bash分配一个交互式终端执行成功后你会“挪”到计算节点上此时再敲nvidia-smi就能看到你申请的卡了。用完之后直接exit退出这个交互式 session资源会立即释放计费也会停止。这种交互式 session 用完一定要退出不然它会一直挂着把你排队排来的卡时白白烧掉。4.4 什么时候“退出”才是正确的操作整理一下遇到以下情况退出是正确的你的交互式作业已经调完 bug不再需要继续占着 GPU你发现提交的作业参数写错了GPU 没有申请到正在空跑一个不完整的任务你在计算节点上发现环境完全不对需要回到登录节点重新配置遇到以下情况不必退出你在登录节点上它本身不消耗算力卡你的批处理作业已经在正常运行你退出 SSH 也不会影响它后台作业由调度系统托管这里要特别提一点批处理作业不会因为你退出 SSH 就停止。你提交的脚本通过 Slurm 在计算节点上运行跟你的登录会话完全解耦。很多人担心“我关了电脑、断了 SSH作业会不会中断”——不会超算中心的设计就是为了让你可以提交完任务就安心睡觉。但交互式 srun 不一样你的终端退出了进程也就断了。5. 超算中心 GPU 使用的常见误区与实战经验最后这部分聊几个我这些年见过的用户共性问题也算给大家提个醒。5.1 误区一申请了 GPU 就必须“立刻看到”显卡超算环境里有排队这一说。你提交了作业不代表立刻就有资源给你。尤其到了晚上或月末GPU 队列经常要排几个小时甚至一两天。在PENDING状态下你即使在命令行里敲一万遍nvidia-smi也看不到任何卡——因为资源还没分配给你呢。正确做法是提交作业后用squeue -u $USER看状态如果长时间PENDING且REASON列显示Resources或Priority说明在等资源。这时候你不需要“退出”任何东西该干嘛干嘛等作业跑起来之后去计算节点查看即可。5.2 误区二以为 GPU 越贵越好拼命申请大卡国家超算中心的算力卡按型号分价格不同A100/H800 这类顶级卡通常更贵配额消耗也更快。很多新手一上来就申请 A100 跑一个小到用 CPU 都能秒完的任务结果白白烧掉大量配额还让后面排队的人等更久。我的建议是先在小卡上把代码跑通再提交到大卡上跑完整训练。超算中心一般都有多种 GPU 分区先用那种配额便宜、排队短的卡做测试再转换到正式卡上。跑模型之前先用一行命令python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))确认 CUDA 环境和显卡能对上再启动正式训练脚本。这一步 5 秒钟能省下你数小时的踩坑时间。5.3 经验命令行里查看 GPU 状态别只知道nvidia-sminvidia-smi是 NVIDIA GPU 最基本的查看命令但超算中心不一定全是 NVIDIA 的卡。比如有的中心部署了 AMD 的 Instinct 系列用rocm-smi查看或者国产昇腾、寒武纪、海光 DCU各自有专门的工具如npu-smi、dcu-smi等。到了一个新环境不确定用什么命令时可以先看看有没有对应的工具rocm-smiAMD 卡npu-smi info昇腾卡dcu-smi海光 DCUixsmi燧原等国产卡另外还有一些交互式监控工具比如nvtop它像 Linux 的top一样实时刷新 GPU 利用率和显存占用调试模型时非常好用。如果你的超算环境里没有预装可以让管理员帮忙装一下或者用pip install nvitop装一个轻量级的。5.4 “找不到显卡”时最后的大招找管理员上面说的排查方法都试过之后还是找不到显卡最不丢人的做法是直接问管理员。超算中心的支撑团队一般都很快响应。你只要把squeue -u $USER和scontrol show job 作业ID的输出贴给他们他们一眼就能看出问题出在参数还是节点配置。比你自己在命令行里反复试更强。我见过最离谱的一次是一个用户申请 GPU 的时候把--gres拼成了--gpu调度器默默接受了这个错误参数有些旧版 Slurm 不校验给他分配了一个纯 CPU 节点结果他在上面干瞪眼半小时。后来支撑团队看了一眼作业配置三秒钟就指出了问题。所以遇到“找不到显卡”又不确定原因时请务必留下作业 ID这是你排查所有问题的基础。5.5 命令行本身不“烧卡”但别让调试占用你的卡时最后成体系地强调一下核心观点命令行操作本身几乎不消耗算力卡资源但“卡时”的消耗与你的作业是否运行、是否占用了资源有关。你真正该关心的不是“敲命令会不会扣配额”而是“我的作业有没有在正确高效地跑”。如果你用交互式 srun 申请了 GPU 用来调试调试完之后记得立刻exit释放资源。出一个有意思的细节很多超算中心的调度策略是“先进先出 优先级抢占”你长时间占着一个交互式 session 不退出不仅烧自己的配额还可能把后面焦急等着跑实验的同学急到跺脚。用超算的基本素养就是「资源用完就还」。我个人现在的习惯是这样写代码、改脚本、看文档全在登录节点做每做一步只跑最小验证真正需要 GPU 的时候用srun开一个交互式任务验证完马上退出确认没问题再写正式批处理脚本提交到队列。全程下来命令行几乎没有额外消耗过卡时排队时间也省了不少。