2026/9/17 6:33:08
FEATURED · 精选文章 
GPU运维这个岗位这几年在招聘市场一直很热。不少做传统服务器运维的朋友跑来问我说简历上写了熟悉GPU服务器结果面试官一上来问CUDA context是什么NVLink拓扑怎么查直接懵了。这不能怪大家基础差而是GPU运维本身就是一个横跨硬件、驱动、虚拟化、调度、AI框架的交叉岗位面试题天然发散。你很难靠背一两个命令过关必须有体系地梳理一套自己的知识框架。这篇文章不罗列100道面试题而是按面试官真正想考察的几条主线来拆硬件底子、故障排查链路、多卡调度、性能分析、以及平台化思维。每一条我都结合实际遇到过的案例来讲包括那些我当年答得稀烂、事后才想明白的问题。准备面GPU运维岗的朋友或者已经在做GPU运维想系统补短板的朋友这篇文章应该能帮你省不少时间。1. 面试先考硬件底子从PCIe拓扑到显存带宽这些细节不能是死记硬背很多做运维的人有个误区觉得硬件是DELL、浪潮、超微这些厂商该管的事运维只需要会用命令。但GPU运维恰恰相反硬件架构理解得越深故障定位越快这是面试第一关就会考察的素质。1.1 一张GPU卡拆开来看你至少要说清这几层面试官让我介绍一张A100 GPU卡我当时的回答是显存80GB算力很强现在想想真想把当时的自己按在地上摩擦。正确的拆解维度至少要从封装、计算单元、存储层级、互联方式往外延伸核心逻辑层A100有108个SM流式多处理器每个SM里面有CUDA Core、Tensor Core以及共享内存、寄存器文件。SM和CUDA Core的关系就好比一个小型CPU里有多核而CUDA Core是真正执行指令的计算单元。训练模型时我们说GPU在算实际就是海量CUDA Core在并行做矩阵乘法、卷积这类的数学运算。显存层HBM2/HBM2e/HBM3位宽、频率共同决定显存带宽。A100 80GB的显存带宽大概是2TB/s左右H100能到3.35TB/s。很多面试题问为什么数据要尽量放显存里本质就是显存带宽和PCIe带宽差了一个数量级。主机互联层PCIe Gen4 x16的最大单向带宽约32GB/sNVLink则能到300GB/s以上NVSwitch则负责多卡全互联。这里的关键是理解GPU卡和CPU之间GPU卡和GPU卡之间这两条通道的带宽差异这会直接影响分布式训练的数据传输瓶颈定位。如果你能手画一张拓扑图标清楚CPU、PCIe Switch、GPU、NVLink、NVSwitch之间的连接关系这一关基本就过了。不会画的话服务器上跑一下nvidia-smi topo -m输出会直接给出GPU之间是NV#、PIX、PXB还是SYS连接面试时能讲明白这张表就是加分项。1.2 常见GPU型号的参数对照必背但更要理解演进逻辑市面上常见的有NVIDIA的V100、A100、H100、RTX 4090、L40S、A10等面试官不会要求你背全所有参数但至少主流型号要能脱口而出。我整理了一张表建议把它内化成自己心里的基准线型号显存容量显存带宽计算精度特性互联方式典型场景V10016GB/32GB900GB/sFP16 Tensor CorePCIe/NVLink早期深度学习训练A10040GB/80GB1.6-2TB/sTF32/BF16/FP16PCIe/NVLink/NVSwitch大规模AI训练、HPCH10080GB/94GB3.35TB/sFP8/BF16PCIe/NVLink/NVSwitch大模型训练推理A1024GB600GB/sFP32/FP16PCIe推理、图形L40S48GB864GB/sFP8/BF16/FP16PCIe推理、渲染、训练RTX 409024GB1.01TB/sFP16PCIe小规模训练、推理记这张表不是为了背数字而是理解NVIDIA的产品分层数据中心训练卡A100/H100、推理卡A10/L4/L40S、消费级卡RTX系列定位完全不同。面试里经常问为什么生产环境主推A100/H100而不是4090关键点不只是显存还有ECC显存纠错、NVLink互联、更低的故障率、vGPU/MIG支持、数据中心散热设计。消费级卡跑训练容易掉卡一个原因是散热结构和工作负载不匹配另一个是缺少ECC内存保护训练十几天后出现静默错误很难排查。1.3 nvidia-smi 的输出细节面试官爱问的都是你没注意过的nvidia-smi是GPU运维最基础的命令但正因为基础很多人反而没深究过每一行输出。比如我常被问到的几个点第一Volatile GPU-Util为什么叫Volatile它其实是一个采样值不是平均利用率。NVIDIA驱动每隔一段时间采样一次GPU上的计算单元忙碌情况这个值反映的是采样时刻附近的利用率不是精确的平均load。所以你会看到训练时利用率跳来跳去这不一定是出了问题可能只是采样点落在了kernel launch的间隙。第二显存Memory-Usage显示的数值是已分配显存不是实际写入数据量。CUDA 里cudaMalloc是一大块一大块分配的PyTorch 的 caching allocator 会缓存显存块所以你会看到任务结束后显存还占用着很多。面试题为什么程序退了显存还是满的答案之一就是这个——进程退了但显存没释放最常见的原因其实是还有僵尸进程或别的进程在占用其次才是caching allocator 的残留。第三nvidia-smi里的Ecc、Pwr、Temp这些字段代表什么能不能看懂这些状态来预判故障。Excessive temperature、Power limit throttling、Slowdown这类的状态标记往往比告警更早暴露问题。2. 高频故障题怎么答显存异常、掉卡、性能劣化的完整排查链路面试里最常出的场景题绝不是让你背命令而是给你一个现象让你讲讲排查思路。这一节我把GPU运维最高频的几类故障全部拆开按现象-根因-排查步骤-解决来梳理。2.1 显存占用异常排查先分清是进程占用还是驱动泄漏面试题原题通常是训练程序已经停了nvidia-smi显示显存还是占着几十GB怎么排查我见过太多候选人上来就答kill -9这是大忌。正确链路是这样的查进程占用nvidia-smi --query-compute-appspid,used_memory,process_name --formatcsv找出真正占显存的PID。如果发现PID是已经退出的程序残留那就是僵尸状态需要确认其父进程必要时kill父进程。查运行实例fuser -v /dev/nvidia*能看哪些进程打开了GPU设备文件。有些情况下程序fork出来的子进程未退出此命令能揪出来。驱动层面如果完全没有进程占用但显存占用不为0多半是驱动bug或者CUDA context未正常销毁。可以试试重启驱动nvidia-smi -r但生产环境慎用会打断所有GPU任务或是reboot节点。内存泄漏的隐藏点PyTorch/CUDA caching allocator会让显存看起来只增不减。回答时可以补充让小batch先跑一下观察显存基线再利用torch.cuda.empty_cache()不能彻底解决long-running任务应该从代码层面处理显存碎片。这类题面试官真正想考察的不是你会不会敲nvidia-smi而是你有没有系统排查意识按进程-设备文件-驱动-应用的顺序层层递进而不是一上来就快刀斩乱麻。2.2 GPU掉卡/卡不可用一个从dmesg开始的真实案例GPU掉卡在训练集群里太常见了尤其在多卡机器上。现象就是明明有8张卡nvidia-smi只看到6张或者进程直接报CUDA error: all CUDA-capable devices are busy or unavailable。完整排查链路应该是第一步dmesg -T | grep -i nvidia。看驱动log通常会有Xid错误码。Xid是NVIDIA驱动的错误事件码比如Xid 79是GPU fallen off the busXid 43是GPU stopped processing。这些码直接决定了后面往哪个方向排查。第二步lspci | grep -i nvidia。确认PCIe层面是否还能看到设备。如果lspci里都看不到了问题大概率在硬件层面——接触不良、供电异常、PCIe slot故障。第三步检查物理状态。电源线松动是GPU服务器最常见的问题之一。高功耗的GPU瞬时电流很大供电接口接触不良会导致电压跌落GPU直接掉线。第四步软件兜底。如果lspci能看到设备但驱动加载不了尝试重新加载驱动模块modprobe -r nvidia_drm nvidia_modeset nvidia_uvm nvidia modprobe nvidia。有些驱动版本和内核升级后不兼容会导致设备stuck在udelay或者timeout。说一个我实际处理过的案例。当时一台8卡A100机器跑大模型训练任务到第3天突然报NCCL failure一看nvidia-smi只剩7卡。dmesg里出现了 Xid 79lspci里那张卡还在但状态显示rev后将SERR等。我查了供电查了PCIe插槽最后发现是这张卡的散热风扇转速异常温度飙到95度触发了过热保护。清灰、重新涂硅脂后恢复了。这个案例我的体会是掉卡不一定是卡坏了散热引发的自我保护占了不少比例。2.3 GPU利用率忽高忽低别急着怪GPU——性能问题多半在CPU、存储和网络面试题经常是nvidia-smi看GPU Util只有30%训练速度上不去怎么排查最常见的错误回答是升级GPU驱动或者换更好的GPU。实际上GPU利用率低大概率瓶颈不在GPUCPU数据加载瓶颈数据预处理、DataLoader的num_workers不够CPU吃不满导致GPU一直在等数据。可以用top、pidstat看CPU状态通常会发现CPU的某个核心已经打满或者python进程在等I/O。存储瓶颈数据集在机械盘或网络盘上读速度跟不上训练速度。iostat -x 1看%util和await如果磁盘util一直很高说明存储是瓶颈。把数据放到本地NVMe盘能立竿见影。GPU通信瓶颈多卡训练时通信时间占比过高。A100用PCIe卡和NVLink卡训练同样的模型速度差距很大。这时候需要用nvidia-smi topo -m看卡间拓扑ps记录下来看通信是否跨了PCIe switch甚至跨socket。小kernel频繁启动模型里有很多小算子GPU一次计算量很小kernel launch开销占比高利用率自然低。这种用nsys profile或ncu才能看出来属于性能分析范畴。这类题最后一定要补充一句排查到瓶颈后我一般先用数据并行、batch size调大、减少CPU日志输出这几个手段来做快速验证。这样面试官会认为你不仅有排查框架还有落地手段。3. 多卡、分布式与资源调度的面试高频点NVLink、NCCL、MIG和容器化现在的GPU运维早就不限于单机单卡了。面试官问多卡、分布式相关的问题主要考察你是否理解GPU在现代AI基础设施里的协作方式。3.1 NVLink、NCCL和卡间通信性能分析先讲清楚一个底层事实GPU之间通信有两种路径一种是走PCIe另一种是走NVLink。PCIe是共享总线式架构实际是交换式但这里为了理解可以简单类比为共享通道NVLink是GPU之间直连的高速互联。多卡训练时用NCCL通信库它会在运行前检测GPU之间的拓扑自动选择最快的通信路径。面试中常问怎么确认NCCL用的什么拓扑、跑没跑在NVLink上可以这样答用nvidia-smi topo -m查看GPU间的连接带宽输出里的NV代表理论NVLink连接PIX代表同PCIe switchPXB代表跨PCIe bridgeSYS代表经过CPU socket。程序运行时设置环境变量NCCL_DEBUGINFOlog里会打出NCCL用了哪条路径P2P还是SHM还是NET。测实际带宽可以用all_reduce_perf或自己做一个小规模的bandwidth test。如果测出来多卡通信带宽只有理论值的几分之一说明拓扑或网络配置有问题。补充一个常见坑NCCL在网络通信时既可以用IBInfiniBand也可以用RoCE还可以走TCP。面试题问你多机多卡性能瓶颈在哪既要考虑GPU到GPU的通信又要考虑跨节点网络两者不是一个层面的瓶颈。我在实际运维中见过一个案例单机8卡训练正常但4机32卡训练时吞吐量上不去后来发现IB网络配置里把导流和乱序的GID配置搞错了数据包跨子网走了路由器延迟陡增。这类问题用ibstatus、ib_write_bw测试几分钟就能定位出来。3.2 虚拟化与资源隔离MIG、vGPU和容器化GPU怎么管理面试官如果确认你有一定基础会问资源隔离一台8卡GPU机器怎么分给多个小团队用这是一个看起来很开放、实际在考你虚拟化技术选型的问题。几个层面的方案要说清楚MIGMulti-Instance GPUA100/H100等卡支持。可以把一张物理GPU切成多个实例每个实例有独立的显存和计算单元硬件级隔离。比如A100 80GB可以切成2个40GB或者7个10GB实际配置取决于具体型号。优点是隔离性强、故障域小缺点是计算单元利用率可能下降灵活性不如软件方案。vGPU通过NVIDIA虚拟化软件把GPU共享给多台虚拟机。典型场景是VDI或者云平台。运维上要装vGPU License和管理组件复杂度比MIG高。容器化Device Plugin这是目前最主流的方案。Kubernetes NVIDIA Device PluginPod通过nvidia.com/gpu资源申请GPUDevice Plugin负责把宿主机GPU分配进容器。运维上要维护驱动、容器运行时如containerd、NVIDIA Container Toolkit。这里我强烈建议准备面试的人深入理解Device Plugin的工作原理它本质上是一个gRPC服务在kubelet分配设备时返回设备路径和挂载参数。面试时如果能说清GPU没有标准的cgroup资源隔离Device Plugin是依靠设备白名单显存限制来实现隔离的就已经比大部分候选人有深度了。3.3 多租户调度为什么GPU资源要看显存算力两个维度很多传统运维习惯CPU按核数、内存按GB来分配GPU资源分配却要同时考虑显存和算力SM利用率。面试题往往是一个训练任务申请了40GB显存但只用了10%的算力你怎么办这题考察的是对GPU利用率的运营意识。我的回答思路是算力利用率低的常见原因数据加载瓶颈、任务小、模型小、batch太小。优先优化任务本身而不是调整资源。如果业务上就是间歇性波动的服务考虑用MIG或者vGPU共享提高物理资源利用率。如果是长期低效任务在调度平台层面增加GPU利用率审计定期找资源Owner优化应用这是平台运维很重要的一个运营动作。如果想提升利用率还可以把推理服务和训练任务混部用K8s的优先级、抢占机制管理但要注意显存隔离和性能干扰。这种回答展示的是我能从上往下看整套系统而不仅是会装驱动。4. GPU性能分析与优化基础非性能工程师的运维也要懂的关键命令这一节容易被候选人忽视觉得性能优化是算法工程师的事。但面试官越来越爱问性能分析因为运维如果不懂性能数据的含义就没法区分设备故障和应用问题更没法在故障报告里给出有效数据支撑。4.1 从GPU Util到nvidia-smi dmon找到性能问题的第一现场很多人只知道nvidia-smi一个命令但面试里聊深了至少要知道这几层工具nvidia-smi静态概览适合快速看每张卡的利用率、显存、温度、功耗。nvidia-smi dmon动态监控适合持续观察GPU状态变化。每行显示时间戳能看到util、显存使用、温度、功耗、SM时钟的实时变化。nvtop类htop风格适合交互式排查能按进程排序看GPU使用情况。nvidia-smi pmon进程级监控能看到进程ID、SM利用率、显存占用适合定位到底是哪个进程在吃GPU。ncuNsight Computekernel级profiling能分析单算子、访存效率。普通运维不要求精通但至少要能听懂算法工程师在说什么。nsysNsight Systems系统级tracing能看到CPU和GPU的timeline判断数据加载、通信、kernel执行的时间重叠。面试官常以nvidia-smi dmon为例问输出怎么看重点集中在sm、mem、enc、dec这几列。SM列表示SM利用率跟同Volatile GPU-Util的区别在于更细粒度可以理解为设备内部的计算单元忙碌程度。知道这一点能加分。4.2 驱动版本与CUDA版本兼容矩阵一票否决题这一节我认为是一票否决题因为GPU运维如果在这块答不对后面讲再多高端内容都会被打折。NVIDIA驱动、CUDA Toolkit、PyTorch/CUDA runtime版本之间有兼容关系。驱动版本里的CUDA Version字段表示该驱动支持的最高CUDA版本所以驱动是不能随便升级的升完发现PyTorch编译用的旧CUDA跑不起来了这种事故我见过不止一次。通常运维要做三件事记录每台机器的驱动版本、CUDA版本、容器runtime版本并维护一张兼容矩阵表。驱动升级前先在测试机上验证所有上层任务是否兼容。重点验证torch.cuda.is_available()、NCCL多机通信、TensorFlow GPU测试。对于多容器环境推荐用宿主机只装驱动容器内带CUDA的模式因为CUDA Toolkit在容器里是自洽的只要宿主机驱动版本够新容器内带多个CUDA版本互不干扰。一个实际踩过的坑某次宿主机驱动从525升级到535本机上有一个老模型用torch 1.10 CUDA 11.3编译的时代启动直接报CUDA error: no kernel image is available for execution on the device。原因就是535驱动停掉了对旧SM架构比如sm_70的前向兼容。所以升级驱动的调研里一定要确认业务方有没有老kernel的代码。4.3 性能监控与告警体系的指标设计面试的开放题经常是让你设计一套GPU集群监控告警你会监控哪些指标阈值怎么定这题重在逻辑不一定要精确到某个数值。我会这样回答第一层主机层。CPU负载、内存、磁盘I/O、网络带宽。因为GPU任务强依赖这些资源任何一个瓶颈都会拖慢训练。第二层GPU设备层。温度、功耗、显存使用率、SM利用率、GPU卡状态UP/DOWN、PCIe链路速率、ECC错误计数、Xid错误计数、NVLink带宽。这些数据大多能从DCGMNVIDIA Data Center GPU Manager或nvml接口获取用Prometheusdcgm-exporter即可。第三层任务层。统一调度平台的任务状态Running/Failed/OOM、排队时长、单卡算力利用率、显存实际需求峰值。任务层数据能帮助做资源容量规划。关于阈值我一般建议梯度告警而不是一个固定值硬编码。比如温度优先关注接近降频阈值和接近过温阈值两个级别而不是等90度才告警显存利用率持续5分钟100%也不一定是故障要看任务预期。这个设计逻辑能体现运维对GPU特性的理解。5. 面试实战中的加分项把单点排查能力上升到平台化运维思维到了这一节面试官通常已经认可你的技术底子了接下来是判定你是初级运维还是高级平台运维的分水岭。常见的问题是你前面讲了很多故障排查那你们是怎么提前发现问题的怎么防止同类故障再次发生这题没有统一答案但可以围绕平台化、标准化、数据化三个关键词展开。5.1 从人肉巡检到自动化健康检查早期管GPU集群很多团队靠人工每天看几遍nvidia-smi这样不仅效率低而且很难发现间歇性问题。平台化运维的第一步是把人肉巡检变成自动化的健康检查脚本。我实践下来比较有价值的是三类检查定期探测DCGM采集每个GPU的temperature、power、utilization、memory、PCIe throughput、NVLink error counters。把GPU的ECC错误计数作为重要健康指标。单bit ECC可纠正暂不致命持续增长的uncorrectable ECC error就要尽早准备迁移任务和RMA。针对Xid错误事件做审计。Xid 43/45/79这类高发错误一旦出现就先检查散热和供电再检查驱动和PCIe链路。把这些检查结果汇总成GPU健康评分每次调度任务前自动检查节点健康度不健康的节点自动下线、踢出调度池。这个设计在面试里说出来基本就能让面试官眼神发光。5.2 故障复盘模板用故障影响-时间线-根因-预案代替我修好了面试官如果让你分享一次印象最深的故障处理经历一定要用结构化的复盘方式来答而不是流水账。我自己的回答框架是故障现象和影响范围哪个集群、多少卡、哪些业务受影响多久。时间线几点发现、几点定位、几点恢复、每个节点做了哪些操作。根因分析不要只说温度高了要深挖为什么温度高了是散热片老化、风扇策略失效还是机房空调故障。临时处置和长期预防临时重启恢复任务、长期加装温度巡检和自动关机预案。6. 面试官不会明说但心里一直会验证的坑心态与表达最后聊点软性的。很多人技术能力不差但面试表现不好往往是败在沟通方式上。GPU运维面试尤其如此因为面试官很难通过一道题判断你水平他更看重你遇到未知问题时的反应模式。几个我亲测有效的建议不要背答案要讲过程。被问到“GPU利用率低怎么排查”最好答我先看CPU还是GPU在等然后用top和nvidia-smi对照分析如果是多卡,再看NCCL通信时间。这比背一堆命令有价值得多。敢于说不知道。面试官问到具体参数或罕见错误码你说不确定很正常。接着说我会先去查dmesg和官方文档定位到具体原因后再处理这种态度更接近真实工作。多讲一个为什么。不只是说出操作还要解释为什么这么操作。比如 nvidia-smi显示显存占用我会再确认进程是否存在因为PyTorch的显存分配是缓存式的只看显存数值容易误判。 这一句话就能把会用命令和懂机理拉开差距。我当年第一次面GPU运维岗时被问到如何确认两张卡之间走的NVLink还是PCIe我当时愣了半天只憋出查资料。后来自己管理多卡集群才真正理解了拓扑信息在通信调优里的作用。这种靠踩坑攒来的认知才是面试里最打动人的部分。如果你正在准备面试建议无论如何都要找一台真的GPU服务器亲手敲几遍nvidia-smi、topo -m、dmon看一次Xid错误日志再装一次NVIDIA Container Toolkit。这些动作做一遍比背二十道面试题都管用。
GPU运维面试全攻略：从硬件底子到平台化思维的知识体系
GPU运维这个岗位这几年在招聘市场一直很热。不少做传统服务器运维的朋友跑来问我说简历上写了熟悉GPU服务器结果面试官一上来问CUDA context是什么NVLink拓扑怎么查直接懵了。这不能怪大家基础差而是GPU运维本身就是一个横跨硬件、驱动、虚拟化、调度、AI框架的交叉岗位面试题天然发散。你很难靠背一两个命令过关必须有体系地梳理一套自己的知识框架。这篇文章不罗列100道面试题而是按面试官真正想考察的几条主线来拆硬件底子、故障排查链路、多卡调度、性能分析、以及平台化思维。每一条我都结合实际遇到过的案例来讲包括那些我当年答得稀烂、事后才想明白的问题。准备面GPU运维岗的朋友或者已经在做GPU运维想系统补短板的朋友这篇文章应该能帮你省不少时间。1. 面试先考硬件底子从PCIe拓扑到显存带宽这些细节不能是死记硬背很多做运维的人有个误区觉得硬件是DELL、浪潮、超微这些厂商该管的事运维只需要会用命令。但GPU运维恰恰相反硬件架构理解得越深故障定位越快这是面试第一关就会考察的素质。1.1 一张GPU卡拆开来看你至少要说清这几层面试官让我介绍一张A100 GPU卡我当时的回答是显存80GB算力很强现在想想真想把当时的自己按在地上摩擦。正确的拆解维度至少要从封装、计算单元、存储层级、互联方式往外延伸核心逻辑层A100有108个SM流式多处理器每个SM里面有CUDA Core、Tensor Core以及共享内存、寄存器文件。SM和CUDA Core的关系就好比一个小型CPU里有多核而CUDA Core是真正执行指令的计算单元。训练模型时我们说GPU在算实际就是海量CUDA Core在并行做矩阵乘法、卷积这类的数学运算。显存层HBM2/HBM2e/HBM3位宽、频率共同决定显存带宽。A100 80GB的显存带宽大概是2TB/s左右H100能到3.35TB/s。很多面试题问为什么数据要尽量放显存里本质就是显存带宽和PCIe带宽差了一个数量级。主机互联层PCIe Gen4 x16的最大单向带宽约32GB/sNVLink则能到300GB/s以上NVSwitch则负责多卡全互联。这里的关键是理解GPU卡和CPU之间GPU卡和GPU卡之间这两条通道的带宽差异这会直接影响分布式训练的数据传输瓶颈定位。如果你能手画一张拓扑图标清楚CPU、PCIe Switch、GPU、NVLink、NVSwitch之间的连接关系这一关基本就过了。不会画的话服务器上跑一下nvidia-smi topo -m输出会直接给出GPU之间是NV#、PIX、PXB还是SYS连接面试时能讲明白这张表就是加分项。1.2 常见GPU型号的参数对照必背但更要理解演进逻辑市面上常见的有NVIDIA的V100、A100、H100、RTX 4090、L40S、A10等面试官不会要求你背全所有参数但至少主流型号要能脱口而出。我整理了一张表建议把它内化成自己心里的基准线型号显存容量显存带宽计算精度特性互联方式典型场景V10016GB/32GB900GB/sFP16 Tensor CorePCIe/NVLink早期深度学习训练A10040GB/80GB1.6-2TB/sTF32/BF16/FP16PCIe/NVLink/NVSwitch大规模AI训练、HPCH10080GB/94GB3.35TB/sFP8/BF16PCIe/NVLink/NVSwitch大模型训练推理A1024GB600GB/sFP32/FP16PCIe推理、图形L40S48GB864GB/sFP8/BF16/FP16PCIe推理、渲染、训练RTX 409024GB1.01TB/sFP16PCIe小规模训练、推理记这张表不是为了背数字而是理解NVIDIA的产品分层数据中心训练卡A100/H100、推理卡A10/L4/L40S、消费级卡RTX系列定位完全不同。面试里经常问为什么生产环境主推A100/H100而不是4090关键点不只是显存还有ECC显存纠错、NVLink互联、更低的故障率、vGPU/MIG支持、数据中心散热设计。消费级卡跑训练容易掉卡一个原因是散热结构和工作负载不匹配另一个是缺少ECC内存保护训练十几天后出现静默错误很难排查。1.3 nvidia-smi 的输出细节面试官爱问的都是你没注意过的nvidia-smi是GPU运维最基础的命令但正因为基础很多人反而没深究过每一行输出。比如我常被问到的几个点第一Volatile GPU-Util为什么叫Volatile它其实是一个采样值不是平均利用率。NVIDIA驱动每隔一段时间采样一次GPU上的计算单元忙碌情况这个值反映的是采样时刻附近的利用率不是精确的平均load。所以你会看到训练时利用率跳来跳去这不一定是出了问题可能只是采样点落在了kernel launch的间隙。第二显存Memory-Usage显示的数值是已分配显存不是实际写入数据量。CUDA 里cudaMalloc是一大块一大块分配的PyTorch 的 caching allocator 会缓存显存块所以你会看到任务结束后显存还占用着很多。面试题为什么程序退了显存还是满的答案之一就是这个——进程退了但显存没释放最常见的原因其实是还有僵尸进程或别的进程在占用其次才是caching allocator 的残留。第三nvidia-smi里的Ecc、Pwr、Temp这些字段代表什么能不能看懂这些状态来预判故障。Excessive temperature、Power limit throttling、Slowdown这类的状态标记往往比告警更早暴露问题。2. 高频故障题怎么答显存异常、掉卡、性能劣化的完整排查链路面试里最常出的场景题绝不是让你背命令而是给你一个现象让你讲讲排查思路。这一节我把GPU运维最高频的几类故障全部拆开按现象-根因-排查步骤-解决来梳理。2.1 显存占用异常排查先分清是进程占用还是驱动泄漏面试题原题通常是训练程序已经停了nvidia-smi显示显存还是占着几十GB怎么排查我见过太多候选人上来就答kill -9这是大忌。正确链路是这样的查进程占用nvidia-smi --query-compute-appspid,used_memory,process_name --formatcsv找出真正占显存的PID。如果发现PID是已经退出的程序残留那就是僵尸状态需要确认其父进程必要时kill父进程。查运行实例fuser -v /dev/nvidia*能看哪些进程打开了GPU设备文件。有些情况下程序fork出来的子进程未退出此命令能揪出来。驱动层面如果完全没有进程占用但显存占用不为0多半是驱动bug或者CUDA context未正常销毁。可以试试重启驱动nvidia-smi -r但生产环境慎用会打断所有GPU任务或是reboot节点。内存泄漏的隐藏点PyTorch/CUDA caching allocator会让显存看起来只增不减。回答时可以补充让小batch先跑一下观察显存基线再利用torch.cuda.empty_cache()不能彻底解决long-running任务应该从代码层面处理显存碎片。这类题面试官真正想考察的不是你会不会敲nvidia-smi而是你有没有系统排查意识按进程-设备文件-驱动-应用的顺序层层递进而不是一上来就快刀斩乱麻。2.2 GPU掉卡/卡不可用一个从dmesg开始的真实案例GPU掉卡在训练集群里太常见了尤其在多卡机器上。现象就是明明有8张卡nvidia-smi只看到6张或者进程直接报CUDA error: all CUDA-capable devices are busy or unavailable。完整排查链路应该是第一步dmesg -T | grep -i nvidia。看驱动log通常会有Xid错误码。Xid是NVIDIA驱动的错误事件码比如Xid 79是GPU fallen off the busXid 43是GPU stopped processing。这些码直接决定了后面往哪个方向排查。第二步lspci | grep -i nvidia。确认PCIe层面是否还能看到设备。如果lspci里都看不到了问题大概率在硬件层面——接触不良、供电异常、PCIe slot故障。第三步检查物理状态。电源线松动是GPU服务器最常见的问题之一。高功耗的GPU瞬时电流很大供电接口接触不良会导致电压跌落GPU直接掉线。第四步软件兜底。如果lspci能看到设备但驱动加载不了尝试重新加载驱动模块modprobe -r nvidia_drm nvidia_modeset nvidia_uvm nvidia modprobe nvidia。有些驱动版本和内核升级后不兼容会导致设备stuck在udelay或者timeout。说一个我实际处理过的案例。当时一台8卡A100机器跑大模型训练任务到第3天突然报NCCL failure一看nvidia-smi只剩7卡。dmesg里出现了 Xid 79lspci里那张卡还在但状态显示rev后将SERR等。我查了供电查了PCIe插槽最后发现是这张卡的散热风扇转速异常温度飙到95度触发了过热保护。清灰、重新涂硅脂后恢复了。这个案例我的体会是掉卡不一定是卡坏了散热引发的自我保护占了不少比例。2.3 GPU利用率忽高忽低别急着怪GPU——性能问题多半在CPU、存储和网络面试题经常是nvidia-smi看GPU Util只有30%训练速度上不去怎么排查最常见的错误回答是升级GPU驱动或者换更好的GPU。实际上GPU利用率低大概率瓶颈不在GPUCPU数据加载瓶颈数据预处理、DataLoader的num_workers不够CPU吃不满导致GPU一直在等数据。可以用top、pidstat看CPU状态通常会发现CPU的某个核心已经打满或者python进程在等I/O。存储瓶颈数据集在机械盘或网络盘上读速度跟不上训练速度。iostat -x 1看%util和await如果磁盘util一直很高说明存储是瓶颈。把数据放到本地NVMe盘能立竿见影。GPU通信瓶颈多卡训练时通信时间占比过高。A100用PCIe卡和NVLink卡训练同样的模型速度差距很大。这时候需要用nvidia-smi topo -m看卡间拓扑ps记录下来看通信是否跨了PCIe switch甚至跨socket。小kernel频繁启动模型里有很多小算子GPU一次计算量很小kernel launch开销占比高利用率自然低。这种用nsys profile或ncu才能看出来属于性能分析范畴。这类题最后一定要补充一句排查到瓶颈后我一般先用数据并行、batch size调大、减少CPU日志输出这几个手段来做快速验证。这样面试官会认为你不仅有排查框架还有落地手段。3. 多卡、分布式与资源调度的面试高频点NVLink、NCCL、MIG和容器化现在的GPU运维早就不限于单机单卡了。面试官问多卡、分布式相关的问题主要考察你是否理解GPU在现代AI基础设施里的协作方式。3.1 NVLink、NCCL和卡间通信性能分析先讲清楚一个底层事实GPU之间通信有两种路径一种是走PCIe另一种是走NVLink。PCIe是共享总线式架构实际是交换式但这里为了理解可以简单类比为共享通道NVLink是GPU之间直连的高速互联。多卡训练时用NCCL通信库它会在运行前检测GPU之间的拓扑自动选择最快的通信路径。面试中常问怎么确认NCCL用的什么拓扑、跑没跑在NVLink上可以这样答用nvidia-smi topo -m查看GPU间的连接带宽输出里的NV代表理论NVLink连接PIX代表同PCIe switchPXB代表跨PCIe bridgeSYS代表经过CPU socket。程序运行时设置环境变量NCCL_DEBUGINFOlog里会打出NCCL用了哪条路径P2P还是SHM还是NET。测实际带宽可以用all_reduce_perf或自己做一个小规模的bandwidth test。如果测出来多卡通信带宽只有理论值的几分之一说明拓扑或网络配置有问题。补充一个常见坑NCCL在网络通信时既可以用IBInfiniBand也可以用RoCE还可以走TCP。面试题问你多机多卡性能瓶颈在哪既要考虑GPU到GPU的通信又要考虑跨节点网络两者不是一个层面的瓶颈。我在实际运维中见过一个案例单机8卡训练正常但4机32卡训练时吞吐量上不去后来发现IB网络配置里把导流和乱序的GID配置搞错了数据包跨子网走了路由器延迟陡增。这类问题用ibstatus、ib_write_bw测试几分钟就能定位出来。3.2 虚拟化与资源隔离MIG、vGPU和容器化GPU怎么管理面试官如果确认你有一定基础会问资源隔离一台8卡GPU机器怎么分给多个小团队用这是一个看起来很开放、实际在考你虚拟化技术选型的问题。几个层面的方案要说清楚MIGMulti-Instance GPUA100/H100等卡支持。可以把一张物理GPU切成多个实例每个实例有独立的显存和计算单元硬件级隔离。比如A100 80GB可以切成2个40GB或者7个10GB实际配置取决于具体型号。优点是隔离性强、故障域小缺点是计算单元利用率可能下降灵活性不如软件方案。vGPU通过NVIDIA虚拟化软件把GPU共享给多台虚拟机。典型场景是VDI或者云平台。运维上要装vGPU License和管理组件复杂度比MIG高。容器化Device Plugin这是目前最主流的方案。Kubernetes NVIDIA Device PluginPod通过nvidia.com/gpu资源申请GPUDevice Plugin负责把宿主机GPU分配进容器。运维上要维护驱动、容器运行时如containerd、NVIDIA Container Toolkit。这里我强烈建议准备面试的人深入理解Device Plugin的工作原理它本质上是一个gRPC服务在kubelet分配设备时返回设备路径和挂载参数。面试时如果能说清GPU没有标准的cgroup资源隔离Device Plugin是依靠设备白名单显存限制来实现隔离的就已经比大部分候选人有深度了。3.3 多租户调度为什么GPU资源要看显存算力两个维度很多传统运维习惯CPU按核数、内存按GB来分配GPU资源分配却要同时考虑显存和算力SM利用率。面试题往往是一个训练任务申请了40GB显存但只用了10%的算力你怎么办这题考察的是对GPU利用率的运营意识。我的回答思路是算力利用率低的常见原因数据加载瓶颈、任务小、模型小、batch太小。优先优化任务本身而不是调整资源。如果业务上就是间歇性波动的服务考虑用MIG或者vGPU共享提高物理资源利用率。如果是长期低效任务在调度平台层面增加GPU利用率审计定期找资源Owner优化应用这是平台运维很重要的一个运营动作。如果想提升利用率还可以把推理服务和训练任务混部用K8s的优先级、抢占机制管理但要注意显存隔离和性能干扰。这种回答展示的是我能从上往下看整套系统而不仅是会装驱动。4. GPU性能分析与优化基础非性能工程师的运维也要懂的关键命令这一节容易被候选人忽视觉得性能优化是算法工程师的事。但面试官越来越爱问性能分析因为运维如果不懂性能数据的含义就没法区分设备故障和应用问题更没法在故障报告里给出有效数据支撑。4.1 从GPU Util到nvidia-smi dmon找到性能问题的第一现场很多人只知道nvidia-smi一个命令但面试里聊深了至少要知道这几层工具nvidia-smi静态概览适合快速看每张卡的利用率、显存、温度、功耗。nvidia-smi dmon动态监控适合持续观察GPU状态变化。每行显示时间戳能看到util、显存使用、温度、功耗、SM时钟的实时变化。nvtop类htop风格适合交互式排查能按进程排序看GPU使用情况。nvidia-smi pmon进程级监控能看到进程ID、SM利用率、显存占用适合定位到底是哪个进程在吃GPU。ncuNsight Computekernel级profiling能分析单算子、访存效率。普通运维不要求精通但至少要能听懂算法工程师在说什么。nsysNsight Systems系统级tracing能看到CPU和GPU的timeline判断数据加载、通信、kernel执行的时间重叠。面试官常以nvidia-smi dmon为例问输出怎么看重点集中在sm、mem、enc、dec这几列。SM列表示SM利用率跟同Volatile GPU-Util的区别在于更细粒度可以理解为设备内部的计算单元忙碌程度。知道这一点能加分。4.2 驱动版本与CUDA版本兼容矩阵一票否决题这一节我认为是一票否决题因为GPU运维如果在这块答不对后面讲再多高端内容都会被打折。NVIDIA驱动、CUDA Toolkit、PyTorch/CUDA runtime版本之间有兼容关系。驱动版本里的CUDA Version字段表示该驱动支持的最高CUDA版本所以驱动是不能随便升级的升完发现PyTorch编译用的旧CUDA跑不起来了这种事故我见过不止一次。通常运维要做三件事记录每台机器的驱动版本、CUDA版本、容器runtime版本并维护一张兼容矩阵表。驱动升级前先在测试机上验证所有上层任务是否兼容。重点验证torch.cuda.is_available()、NCCL多机通信、TensorFlow GPU测试。对于多容器环境推荐用宿主机只装驱动容器内带CUDA的模式因为CUDA Toolkit在容器里是自洽的只要宿主机驱动版本够新容器内带多个CUDA版本互不干扰。一个实际踩过的坑某次宿主机驱动从525升级到535本机上有一个老模型用torch 1.10 CUDA 11.3编译的时代启动直接报CUDA error: no kernel image is available for execution on the device。原因就是535驱动停掉了对旧SM架构比如sm_70的前向兼容。所以升级驱动的调研里一定要确认业务方有没有老kernel的代码。4.3 性能监控与告警体系的指标设计面试的开放题经常是让你设计一套GPU集群监控告警你会监控哪些指标阈值怎么定这题重在逻辑不一定要精确到某个数值。我会这样回答第一层主机层。CPU负载、内存、磁盘I/O、网络带宽。因为GPU任务强依赖这些资源任何一个瓶颈都会拖慢训练。第二层GPU设备层。温度、功耗、显存使用率、SM利用率、GPU卡状态UP/DOWN、PCIe链路速率、ECC错误计数、Xid错误计数、NVLink带宽。这些数据大多能从DCGMNVIDIA Data Center GPU Manager或nvml接口获取用Prometheusdcgm-exporter即可。第三层任务层。统一调度平台的任务状态Running/Failed/OOM、排队时长、单卡算力利用率、显存实际需求峰值。任务层数据能帮助做资源容量规划。关于阈值我一般建议梯度告警而不是一个固定值硬编码。比如温度优先关注接近降频阈值和接近过温阈值两个级别而不是等90度才告警显存利用率持续5分钟100%也不一定是故障要看任务预期。这个设计逻辑能体现运维对GPU特性的理解。5. 面试实战中的加分项把单点排查能力上升到平台化运维思维到了这一节面试官通常已经认可你的技术底子了接下来是判定你是初级运维还是高级平台运维的分水岭。常见的问题是你前面讲了很多故障排查那你们是怎么提前发现问题的怎么防止同类故障再次发生这题没有统一答案但可以围绕平台化、标准化、数据化三个关键词展开。5.1 从人肉巡检到自动化健康检查早期管GPU集群很多团队靠人工每天看几遍nvidia-smi这样不仅效率低而且很难发现间歇性问题。平台化运维的第一步是把人肉巡检变成自动化的健康检查脚本。我实践下来比较有价值的是三类检查定期探测DCGM采集每个GPU的temperature、power、utilization、memory、PCIe throughput、NVLink error counters。把GPU的ECC错误计数作为重要健康指标。单bit ECC可纠正暂不致命持续增长的uncorrectable ECC error就要尽早准备迁移任务和RMA。针对Xid错误事件做审计。Xid 43/45/79这类高发错误一旦出现就先检查散热和供电再检查驱动和PCIe链路。把这些检查结果汇总成GPU健康评分每次调度任务前自动检查节点健康度不健康的节点自动下线、踢出调度池。这个设计在面试里说出来基本就能让面试官眼神发光。5.2 故障复盘模板用故障影响-时间线-根因-预案代替我修好了面试官如果让你分享一次印象最深的故障处理经历一定要用结构化的复盘方式来答而不是流水账。我自己的回答框架是故障现象和影响范围哪个集群、多少卡、哪些业务受影响多久。时间线几点发现、几点定位、几点恢复、每个节点做了哪些操作。根因分析不要只说温度高了要深挖为什么温度高了是散热片老化、风扇策略失效还是机房空调故障。临时处置和长期预防临时重启恢复任务、长期加装温度巡检和自动关机预案。6. 面试官不会明说但心里一直会验证的坑心态与表达最后聊点软性的。很多人技术能力不差但面试表现不好往往是败在沟通方式上。GPU运维面试尤其如此因为面试官很难通过一道题判断你水平他更看重你遇到未知问题时的反应模式。几个我亲测有效的建议不要背答案要讲过程。被问到“GPU利用率低怎么排查”最好答我先看CPU还是GPU在等然后用top和nvidia-smi对照分析如果是多卡,再看NCCL通信时间。这比背一堆命令有价值得多。敢于说不知道。面试官问到具体参数或罕见错误码你说不确定很正常。接着说我会先去查dmesg和官方文档定位到具体原因后再处理这种态度更接近真实工作。多讲一个为什么。不只是说出操作还要解释为什么这么操作。比如 nvidia-smi显示显存占用我会再确认进程是否存在因为PyTorch的显存分配是缓存式的只看显存数值容易误判。 这一句话就能把会用命令和懂机理拉开差距。我当年第一次面GPU运维岗时被问到如何确认两张卡之间走的NVLink还是PCIe我当时愣了半天只憋出查资料。后来自己管理多卡集群才真正理解了拓扑信息在通信调优里的作用。这种靠踩坑攒来的认知才是面试里最打动人的部分。如果你正在准备面试建议无论如何都要找一台真的GPU服务器亲手敲几遍nvidia-smi、topo -m、dmon看一次Xid错误日志再装一次NVIDIA Container Toolkit。这些动作做一遍比背二十道面试题都管用。 
