GPU运维面试到底考什么？硬件、监控、调度与AI场景全解析

GPU运维面试，到底在考什么？

最近“GPU运维面试题”这个词的热度一路飙升，我一点也不意外。大模型把GPU从“图形加速卡”变成了“算力基础设施”，训练脚本跑不起来、显存爆了、多卡利用率上不去、推理延迟飙高，这些问题已经不归算法同学管了，全部落到运维头上。

我这两年面试GPU运维岗位的候选人，最大的感受是：很多人还在用传统服务器运维的思维答GPU的问题，一说调度就答K8s、一说监控就答Prometheus，但问到GPU驱动和CUDA版本怎么匹配、NVLink拓扑怎么影响通信、显存占用不高但算力上不去怎么排查，就答不上来了。

这篇文章我梳理了一套完整的GPU运维面试准备体系，覆盖硬件架构、驱动栈、监控排查、集群调度、AI场景这几个核心板块。每条内容都是从真实工作场景里反推出来的考点，不是网上那种“面试题大全”能比的。不管你是准备跳槽的运维工程师，还是刚接手GPU集群的SRE，都可以拿这套框架自查一遍。

1. 拆解考点：面试官从哪些维度考察GPU运维

1.1 GPU运维和传统运维的边界在哪里

先说一个最常见的误区：很多人觉得GPU运维就是把服务器的CPU换成GPU，其他思路照搬。这是完全错误的。

传统服务器运维关心的是CPU、内存、磁盘、网络这四大件，问题模型相对线性：资源不够就扩容，进程挂了就重启，性能瓶颈看负载均衡。GPU运维多了一个完全不同的维度——并行计算资源。

GPU和CPU在架构上就有本质区别。CPU核心少但单核能力强，适合处理复杂逻辑；GPU核心多但单核能力弱，适合做大规模并行计算。这就导致GPU运维的思维方式和传统运维完全不同：不能只看“卡没卡死”，还要看“算力利用率”和“访存带宽”这些并行计算特有的指标。

面试官考察的第一层能力，就是你有没有建立这种“GPU算力思维”。比如问你“GPU利用率100%是不是就是好事”，你要能回答出来：很多场景下利用率100%但性能仍然上不去，可能是因为内存带宽不够，可能是因为kernel launch太频繁，也可能是因为数据在CPU和GPU之间来回拷贝。

1.2 从真实工作流反推面试考察点

我带团队这几年，把GPU运维的实际工作拆成了五条线，面试题基本都从这里面出：

第一条线是“装”：驱动安装、CUDA工具链配置、容器运行时接入。考察的是对GPU软件栈有没有系统认识，遇到驱动和CUDA版本不匹配时能不能快速定位。

第二条线是“看”：监控指标体系搭建、性能数据采集、告警规则设计。考察的是知道该看哪些指标，以及指标异常代表什么问题。

第三条线是“查”：训练变慢、显存泄漏、进程卡死等问题的排查能力。这是最难考察的，通常用场景题来面，给你一个现象，让你分析可能的原因。

第四条线是“调”：多卡训练、分布式通信、任务调度。考察对GPU集群的整体把控能力，包括通信拓扑、共享调度、隔离方案。

第五条线是“省”：GPU资源成本控制、配额管理、碎片整理。大模型时代GPU是公司最贵的单类资源，能不能省钱是面试官很看重的加分项。

这五条线我下面会逐条展开，每一条都配上面试中最可能遇到的具体问题和答题思路。

2. 硬件与架构基础：GPU并不是一张“大号显卡”

2.1 从计算单元到显存层次的核心术语

GPU面试题里70%的基础概念题，翻来覆去就是那几类：SM、CUDA Core、显存带宽、NVLink、拓扑结构。有些候选人能背出参数，但追问“这对运维调优意味着什么”就卡住了。

先说计算单元。以NVIDIA的架构为例，GPU内部由多个流式多处理器（SM）组成，每个SM里面有若干CUDA Core。CUDA Core是执行并行计算的最小单元，但真正决定计算性能的是SM的调度机制——线程束（warp）是GPU调度的基本单位，通常32个线程组成一个warp，以SIMT模式执行。

从运维视角看，这些架构细节解释了为什么GPU适合做矩阵运算和神经网络计算：矩阵乘法本质是大规模浮点运算，正好可以切成无数个warp扔到SM上并行执行。这也是为什么大模型训练几乎离不开GPU，而不是靠堆CPU服务器就能解决。

“gpu的cta是什么”这个热词也出现在热搜里，说明很多人在搜面试相关的概念。CTA（Cooperative Thread Arrays，协作线程数组）是CUDA编程模型中的一个概念，比warp高一级，一个CTA包含多个warp，共享一块共享内存。面试如果问到CUDA编程模型，能说清楚线程、warp、CTA、block、grid这几个层次的关系，基本就能过关。

再说显存层次。GPU有寄存器、共享内存、L2缓存、显存（VRAM）这几级存储。运维最常打交道的显存，带宽远高于CPU内存，但容量有限，一张A100也只有40GB（A100 40G）或80GB（A100 80G）显存。大模型训练时的显存分配主要包括模型参数、梯度、优化器状态、激活值这几块，超出显存容量就会报OOM。

2.2 NVLink、PCIe和GPU拓扑对性能的影响

单机多卡和跨机训练时，GPU之间的通信方式决定了扩展效率。这个知识点面试命中率极高。

常见的GPU互联方式有PCIe和NVLink。PCIe是通用总线，带宽有限，一张卡的PCIe 4.0 x16单向带宽大约16GB/s；NVLink是NVIDIA专有的GPU间高速互联，A100的NVLink单向带宽能到300GB/s（第三代NVLink），H100的第四代NVLink是900GB/s。在不同拓扑下，多卡通信走NVLink和走PCIe，性能差距可能是10倍以上。

运维需要掌握的拓扑概念包括：NVLink全互联（每张卡都和其他卡直连）、NVSwitch（通过交换机芯片互联，H100/A100的8卡机型常见）、PCIe交换机、NUMA亲和性。

面试典型题目：“8卡机器上，为什么有时候4卡训练比8卡还快？”这个问题背后就是通信瓶颈：8卡并行需要更多的AllReduce通信，如果节点间网络带宽不够，通信时间会吃掉计算加速的红利。这种问题考察的是对Amdahl定律的直觉理解——并行计算加速比受串行部分和通信开销限制。

实操建议：拿到一台新的GPU服务器，先用nvidia-smi topo -m查看卡间拓扑，再用nvidia-smi topo -mp查看NVLink连接情况。这两条命令输出的拓扑矩阵，决定了多卡任务应该怎么绑核、怎么设环境变量，是GPU运维的基本功。

3. 驱动与软件栈：一切崩溃的根源

3.1 驱动、CUDA、cuDNN的版本匹配关系

GPU运维里故障率最高的方向，就是驱动和CUDA版本不匹配。我甚至可以说，生产环境里80%的GPU初始化失败，都是版本问题。

先理清几个概念：GPU驱动（如525.147.05）是操作系统和GPU硬件之间的桥梁；CUDA Toolkit是开发/运行环境，包含编译器nvcc和运行时库；cuDNN是深度神经网络加速库，底层依赖CUDA。

驱动版本决定支持的最高CUDA版本，但CUDA Toolkit本身可以安装多个版本。实际部署时的规则是：驱动版本必须高于程序使用的CUDA版本要求的最低驱动版本。比如CUDA 12.2要求Linux驱动版本>=525.60.13，你装的是520版本的驱动，就会报“CUDA driver version is insufficient”。

面试官常追问：“容器里能装CUDA吗？”答案是：容器镜像里可以装CUDA Toolkit和cuDNN，但容器里的CUDA版本必须小于等于宿主机驱动支持的CUDA版本。因为GPU驱动是宿主机内核层面的，容器无法也无需自行加载驱动，容器的CUDA运行时通过宿主机的驱动和硬件通信。

这里给一个我踩过的坑。有次线上训练任务报错“CUDA error: no kernel image is available for execution on the device”，排查了很久，最后发现是容器里CUDA版本太高，而宿主机驱动太老，导致驱动不知道如何把kernel加载到GPU上。处理办法是降容器内CUDA版本或升级宿主机驱动，两个方向都行，但要评估影响面。

3.2 PyTorch GPU版跨系统安装的关键点

热搜里“pytorch安装教程gpu”和“安装paddleocr gpu版本”都被搜得很频繁，说明很多人的GPU上手是从AI框架开始的。面试不会让你现场装PyTorch，但会从安装细节里抽问底层原理。

比如问：PyTorch安装时选CUDA 11.8还是CUDA 12.1有什么差别？这取决于你用的GPU的算力。老一点的GPU（如V100算力7.0、T4算力7.5）在新版本CUDA可能遇到算力兼容问题；新卡如A100算力8.0、H100算力9.0，用太老的CUDA则根本跑不起来。安装命令里pip install torch默认安装的是CPU版，必须指定--index-url https://download.pytorch.org/whl/cu118之类的CUDA版本源才能装到GPU版——这是入门者最常卡住的地方。

前面面试题里还有一条“gpu cpu 内存占用都不高但卡”，这是另一类高频场景。先在下面放答案，后面第5节再展开排查思路。

从运维角度看，这类AI框架安装问题还涉及依赖管理和环境隔离。推荐用虚拟环境或容器来装，避免全局环境的依赖冲突。线上GPU服务器的规范做法是：宿主机只装驱动和nvidia-container-toolkit，AI环境全部用容器隔离，避免算法同学互相踩依赖。

3.3 国产GPU生态（昇腾等）的基本认知

“昇腾系列有哪些gpu”也在热搜里，说明国产算力已经是面试必问项。昇腾（Ascend）是华为推出的AI处理器系列，包括昇腾310（推理）和昇腾910系列（训练），软件开发栈是CANN（Compute Architecture for Neural Networks），类似NVIDIA的CUDA。

做GPU运维的人对国产卡要有一个心态上的准备：不能拿NVIDIA的标准去要求国产卡，现在的生态成熟度确实有差距。实际部署中常见的问题包括：框架适配不完善（很多开源项目只适配了CUDA，昇腾需要额外的适配层）、容器镜像不成熟、监控指标不完全兼容Prometheus体系。

昇腾环境里NVIDIA的nvidia-smi命令不适用，替代命令是npu-smi，也是npu-smi info查看基本信息。如果面试岗位涉及国产化替代，建议提前查一下CANN的OP融合算子、Ascend Docker Runtime，以及MindSpore/昇腾版PyTorch的安装方式。答出“CANN为昇腾硬件提供类似CUDA的编程接口和运行时环境”这句话，就能证明你不是完全没接触过国产AI生态。

4. 监控体系与指标解读

4.1 从nvidia-smi到dcgmi的监控工具链

面试必考的一道实操题：“怎么确认当前用的是哪块GPU？”这个问题的答案是nvidia-smi，同时nvidia-smi -L列出所有GPU，CUDA_VISIBLE_DEVICES环境变量控制哪些GPU对程序可见。

nvidia-smi是最基础的GPU监控工具，但很多人只会看GPU-Util那一列，这是远远不够的。nvidia-smi输出字段里有几个面试官爱深挖的点：

• Memory-Usage：显存使用量/总量，不代表算力使用率。显存占用100%而利用率0%，说明程序申请了显存但没在计算。
• GPU-Util：GPU计算单元利用率。注意这个指标是采样周期内的平均利用率，瞬时波动大，不能只靠它判断瓶颈。
• Volatile GPU-Util和GPU-Memory后的ECC、Persistence-M、Compute Mode这些字段，分别表示纠错状态、持久模式、计算模式。

比nvidia-smi更专业的工具是NVIDIA DCGM（Data Center GPU Manager），配合dcgm-exporter可以把GPU指标接入Prometheus。DCGM能采集的指标非常丰富，包括温度、功耗、SM利用率、显存带宽利用率、NVLink通信速率、PCIe吞吐、ECC错误计数等，是生产环境GPU监控的事实标准。

Grafana社区有很多现成的DCGM Dashboard模板，部署后就可以看到GPU核心的完整画像。面试能答出“生产监控用dcgm-exporter+Prometheus+Grafana，而不是用nvidia-smi轮询”，说明你有生产环境经验。

4.2 算力利用率、显存带宽、功耗等核心指标的业务含义

GPU监控指标这么多，面试官真正想听的是你对指标业务含义的理解。我整理了一张高频指标对照表：

这里最容易踩的坑是把GPU-Util当成唯一指标考核。实践里我遇到过GPU-Util只有30%但任务跑得比GPU-Util 80%还快的情况——因为每步迭代里有大量时间花在CPU做数据预处理、数据加载（DataLoader）和GPU同步上，GPU-Util低不代表算力不够，可能是CPU喂数据的速度跟不上。

面试问到监控告警，建议答三层：基础设施层（宿主机CPU/内存/磁盘/网络，用node-exporter）；GPU设备层（DCGM采集的GPU指标）；应用层（训练进度、loss曲线、吞吐）。三层指标打通，才能从“GPU卡没卡”上升到“训练效率高不高”。

4.3 监控告警阈值如何设置才不误报

告警阈值是实操里最考验经验的环节。设置太高，故障没人发现；设置太低，半夜被告警轰炸。

GPU常用的告警项和推荐阈值：

• GPU利用率低于10%且持续15分钟以上，同时任务状态是运行中——大概率是任务卡死或等待死锁，值得告警。但要排除任务本身处于验证/推理阶段的低利用率区间。
• 显存剩余不足5%——即将OOM的前兆，需要留出缓冲时间处理。
• GPU温度高于85摄氏度且持续10分钟——散热异常，再热可能触发降频保护。
• ECC错误次数大于0且持续累加——显存有硬件问题，需要评估是否换卡。
• 功耗长期接近TDP上限且伴随温度告警——散热跟不上，机房空调吃紧。

阈值不是一个固定值，和具体业务强相关。训练任务GPU-Util天然会周期性抖动，推理服务则要求稳定高利用。面试中能把这一点讲清楚，比背一堆阈值数字更有说服力。

5. 高频问题排查：从现象到根因的思维链

5.1 场景题1：GPU占用不高但就是卡

这个场景搜的人最多，说明生产环境里太常见了。现象通常是：GPU-Util不高、显存占用不高、CPU和内存也不高，但训练或推理就是明显卡顿。

遇到这种问题，我会按以下顺序排查：

第一，排除“假卡”。先看是不是NVLink或PCIe链路降速了。用nvidia-smi -q -d PCIE查看PCIe当前速率和链路宽度，如果显示“8.0 GT/s x16”降到了“x8”甚至“x4”，通信带宽腰斩，训练速度自然上不去，但GPU-Util未必能反映出来。

第二，查CPU侧瓶颈。训练pipeline里GPU要等CPU完成数据预处理和拷贝，如果CPU瓶颈，GPU只能空转等待。看top和perf确认是否有进程占满CPU，同时看GPU的GR Engine利用率和Inference、Compute等引擎状态，判断是计算忙还是通信忙。

第三，查存储瓶颈。数据从磁盘读不出来，DataLoader卡在IO上，GPU同样会“没事干”。看iostat的await和util，如果util持续接近100%但r/s很低，可能是磁盘随机读性能差或单文件读太慢。解决思路是换SSD、加大预读取批量、调优DataLoader的num_workers和prefetch_factor。

第四，查锁等待和内核态卡顿。nvidia-smi里进程状态显示D（不可中断睡眠）说明进程在等待IO；大量R状态进程抢CPU，说明调度在抖动。用cat /proc/<pid>/stack可以看内核栈，很多GPU驱动问题会在栈里暴露出来。

第五，查GPU掉卡或Xid错误。执行dmesg -T | grep -i xid，如果看到Xid 79、Xid 63等错误码，说明GPU硬件或驱动有问题，已经发生或即将发生GPU掉卡。这种问题不解决，就算卡也要掉，比性能问题严重得多。

回答这类场景题，面试官看重的不只是排查步骤，更是你如何收敛问题范围。我的习惯是：先看硬件层是否正常，再看操作系统层是否有异动，最后看应用层有没有死锁或等待。从下往上，逐层排查，定位准确。

5.2 场景题2：想用GPU加速软件结果没有生效

“gazebo使用gpu加速”、“abaqus使用gpu加速”、“keyshot2025.3版本不能使用gpu渲染”这些热搜词的共同点是：软件有GPU加速功能，但用户开启后发现没效果或者直接报错。

这类问题的排查思路是通用的：

第一步，确认GPU驱动能正常加载。nvidia-smi能输出信息不代表驱动完全没问题，还要确认/dev/nvidia*设备节点正常、内核模块（nvidia、nvidia_uvm、nvidia_drm）已加载。

第二步，确认软件真的调用到了GPU。很多软件在设置页开了GPU加速，但因为环境变量、版本兼容性问题，实际还是走CPU计算。可以在软件运行时用nvidia-smi观察，如果GPU-Util一直为0%且没有进程在GPU上，说明软件没有真正调用GPU。

第三步，检查软件对GPU架构的要求。数据科学软件如abaqus对GPU的CUDA算力有最低要求，太老的卡可能不满足要求，软件会静默回退到CPU。Keyshot这类渲染软件对驱动版本敏感，新版驱动有时反而和旧版本软件不兼容。

5.3 场景题3：显存泄漏和OOM

大模型训练场景最经典的故障就是“显存泄漏”——随着训练步数增加，显存占用越来越高，最终OOM进程被杀。

显存泄漏的原因通常有三个：模型定义里重复创建了张量没释放，PyTorch的DataLoader的num_workers泄漏了CUDA context，或者是第三方库内部缓存没清理。

快速定位方法是观察显存增长曲线：跑固定步数后看显存是否持续无上限上涨。如果呈现阶梯式上涨，配合代码review，大概率能锁定是某个操作没有释放显存。排查时可以用nvidia-smi --query-compute-apps=pid,used_memory --format=csv关联进程和显存，再配合PyTorch的torch.cuda.memory_summary()获取分配详情。

生产环境更常见的OOM不是泄漏，而是模型太大或batch_size设太大导致单次训练峰值显存超了。这种情况调小batch_size或开启gradient checkpointing就能解决。但要注意调小batch_size会影响收敛效果，一般配合梯度累积（gradient accumulation）一起调，保持等效batch大小不变。

6. GPU集群的调度与共享

6.1 K8s下GPU调度的两种主流方案

GPU上云和集群化之后，调度就成了核心问题。Kubernetes下有两种主流调度方式：设备插件（Device Plugin）和节点池绑定。

NVIDIA官方方案是nvidia-device-plugin。它把GPU作为可调度资源暴露给K8s，应用通过resources: nvidia.com/gpu: 1来申请。Devices Plugin方案的好处是和标准K8s流程无缝集成，调度、配额都走原生机制。

另一种常见方案是做节点池隔离：把不同规格的GPU机器划分成多个节点池，比如A100池、T4池，任务通过nodeSelector或toleration指定跑到哪类GPU上。这种方式胜在简单可控，GPU类型和拓扑都由节点池固定，避免调度器把任务排到不合适的卡上。

多租户场景还有MIG（Multi-Instance GPU）和vGPU方案。A100/H100支持MIG，可以把一张物理GPU切分成最多7个实例，每个实例有独立的显存和算力隔离。这在成本控制上很关键，因为很多推理服务的算力需求远不满一张卡，MIG可以提高单卡利用率，代价是实例间不能直接通信，没法做多卡并行训练。

6.2 多卡训练的通信瓶颈与拓扑感知调度

前面提到8卡训练可能比4卡慢，展开聊聊多卡训练的拓扑问题。8卡A100机器在NVSwitch拓扑下通信是全互联的，通信效率很高；但如果是两机各4卡，跨机通信走IB或RoCE网络，延迟和带宽都会受限。

面试里追问到分布式训练，关键是能说出来：数据并行、模型并行、流水线并行、张量并行这几种范式，对通信的需求完全不同。数据并行每个step都要AllReduce同步梯度，对通信带宽极其敏感；模型并行和张量并行需要在每层的前向/反向都交换数据，对延迟更敏感。

运维侧的对应动作是“拓扑感知调度”：调度器尽量把单机多卡任务排在同一个NVLink域内，跨机任务优先选择同一网络交换域内的机器。K8s上可以通过TopologyManager配合NVIDIA Topology Aware Scheduling实现。能讲出这层，说明你不只是会装驱动，而是真正理解GPU集群的性能模型。

6.3 GPU资源池化与空闲回收策略

算力闲置是GPU集群成本的大头浪费点。面试题常问：“你怎么提升GPU利用率？”这个问题的标准回答方向是：

第一，池化，不固定绑卡。把GPU放进共享资源池，任务动态申请、用完释放。第二，优先级抢占。离线任务使用空闲GPU，遇到高优任务立刻释放，这在K8s里可以用PriorityClass和抢占策略实现。第三，超卖。在稳定性和利用率之间取平衡，允许推理任务和空闲训练任务共卡。第四，时间片共享。AI工作负载没跑满时，用k8s-device-plugin带time-slicing功能把一张卡分成多个时间片，供多个低负载任务使用。

要注意超卖和时间片不是没有代价的。多个进程同时抢GPU会带来算力干扰和显存竞争，轻则性能下降，重则OOM。生产环境必须配套完善的QoS监控和驱逐机制，否则“省成本”会变成“制造故障”。

7. 大模型场景下的GPU运维专项

7.1 大模型微调对资源的影响：从显存估算到调度

“gpu微调大模型”是当前运维面试最前沿的考点，而且几乎必然是加分项。面试里会往深了问：一个7B模型做LoRA微调，需要多大显存？

这种问题考察的是你对模型显存占用模型的理解。推理显存主要由模型参数决定，一个7B模型以FP16存储约14GB，所以7B推理通常需要至少16GB显存。训练就复杂多了，除了参数还要存梯度和优化器状态。以Adam优化器为例，每个参数要额外存一阶动量、二阶动量和参数副本，FP16训练时显存需求约为模型参数的16~20倍。

所以7B模型全参训练可能需要140GB以上显存，一张A100 80G根本不可能。LoRA等参数高效微调方法只训练少量新增参数，冻结原参数，显存需求大幅下降，8GB~16GB就能跑起来。这也是小团队和个人微调大模型的现实路径。

运维实际要做的是：根据模型参数量、精度、训练方式估算显存需求和卡数，配合调度策略分配资源。这个估算能力在面试里非常吃香，因为它同时考察了你对模型、硬件和调度的理解深度。

7.2 DataLoader、上下文长度和推理吞吐对GPU负载的影响

大模型场景里GPU负载的特性和传统CV任务完全不同。训练侧，DataLoader瓶颈比以往更严重——tokenize（文本转ID）是CPU密集操作，上下文越长、并发越高，CPU越容易成为瓶颈。GPU-Util上不去，首先怀疑CPU喂不动。

推理侧，面试高频问题“怎么计算一个推理服务的吞吐上限？”关键指标是TTFT（首token延迟）和ITL（token间延迟）。并发吞吐的上限受到KV Cache显存占用的约束——上下文越长，KV Cache占的显存越大，能同时服务的并发数就越少。大模型推理的显存计算除了模型参数之外，还要把KV Cache的空间留出来。

这些内容面试官问出来，想听的不只是名词解释，而是你有没有亲手调过：是不是要加max_seq_len限制，是不是要用continuous batching（连续批处理），是不是要用vLLM这类推理加速框架。这三个词说出口，面试就很难把你当成传统运维看待了。

7.3 AI框架版本与驱动升级的变更管理

最后聊一个日常运维里最容易被忽视的点：变更管理。GPU环境最怕AI框架、CUDA、驱动、容器运行时任意一层升级后出现兼容性问题。生产环境我踩过最痛的一次：有人升级了nvidia-container-toolkit，结果所有推理容器的GPU都访问不了，因为新版toolkit默认对所有算子做校验，旧镜像没加对应注解直接失联。

所以遇到驱动或CUDA升级，我的固定流程是：先在测试环境把AI镜像全量回归一遍，重点检查算子结果是否一致；再验证nvidia-smi、dcgm-exporter、nvidia-container-toolkit是否协同正常；最后小流量灰度，确认无误再全量滚动。

面试里问到变更流程，最能体现经验的回答方式是：强调“镜像锁版本”——推理和训练镜像里固定CUDA版本、cuDNN版本、AI框架版本，宿主机只升级驱动层，把变更影响隔离在镜像之外。这条思路，是我希望每个GPU运维候选人都能说出来的。

8. 面试实战中的答题话术与常见雷区

8.1 答题框架：先说现象，再说原因，再说处理

面试答题和写排查报告不一样，候选人常见的失误是一上来就背命令，或者一上来就下结论。好的答题结构是“现象→原因→处理”三层：

比如问“GPU利用率高但训练速度慢”，标准答法应该是：先说训练速度慢的现象里包含GPU高利用的情况，再说可能的原因（kernel launch过密导致GPU空转、L2缓存命中率低导致频繁访问显存、数据精度和计算模式不匹配），最后给出排查命令和优化动作。这样答，面试官才能看出你的思维链，而不是把面试变成知识背诵考核。

一个特别容易被忽略的加分点是主动说“风险”。比如你推荐超卖方案，主动补一句“但超卖会带来算力争抢风险，需要配套监控和驱逐”，表态就比只说方案完整得多。面试官要招的是能把生产环境扛起来的人，不是只会打开放大镜找问题的人。

8.2 高频失分点：比简历更早暴露工作年限的细节

有几个细节特别容易暴露经验深浅，我一条条列出来，能避则避。

第一，只知道nvidia-smi，不知道nvidia-smi dmon、nvidia-smi pmon、nvtop、dcgmi。面试官问“生产环境怎么监控GPU”，只答得出“定时跑nvidia-smi存日志”，基本就凉了。

第二，把GPU-Util当成性能指标天花板。真正专业的回答会拆开说：SM利用率、显存带宽利用率、内存拷贝引擎利用率、NVLink吞吐，这些才组成完整的性能画像。

第三，驱动和CUDA分不清。驱动是内核模块，CUDA Toolkit是用户态工具包，两者分层不同。面试时如果能主动把驱动版本判断规则（驱动最低版本对应表，如CUDA 12.x需要525.x以上）讲清楚，充电量极强。

第四，GPU OOM只会说“加显存”或“换卡”。高级一点的回答会提：先检查有没有显存泄漏，再看batch_size和序列长度，再看是否可以用梯度累积、混合精度、模型并行来降低单卡压力。

第五，完全没接触过国产AI加速卡。在国产化趋势下，即使公司现在没用，面试官也很看重你至少知道昇腾的CANN和NPU监控方式。

8.3 面试准备清单：按优先级排序的20个自测问题

最后给一份实用清单，按优先级从高到低排列。这些题如果都能从容答出来，GPU运维面试基本不会卡壳：

1. 简述GPU和CPU在架构和适用场景上的区别。
2. GPU驱动、CUDA、cuDNN在软件栈中的位置和职责是什么？
3. 宿主机驱动版本和容器内CUDA版本不匹配，会出现什么现象，怎么处理？
4. nvidia-smi输出里哪些字段对运维最有价值，为什么？
5. 怎么查看一台机器上多张GPU的通信拓扑？为什么关注这个？
6. 什么是Xid错误？常见Xid错误码有哪些，分别代表什么？
7. 训练任务变慢，你会从哪些维度排查？
8. 显存占用很高但GPU利用率很低，可能是什么原因？
9. GPU利用率很高但训练速度不快，可能是什么原因？
10. 怎么判断一个推理任务是否被CPU数据准备拖累了？
11. K8s下GPU调度的主流方案有哪些？各有什么优劣？
12. MIG是什么，适用什么场景，限制是什么？
13. 大模型训练中，一张A100 80G能跑多大参数量模型的全参训练？估算依据是什么？
14. LoRA微调相比全参训练，显存需求差别多大？
15. 大模型推理怎么估算并发上限？KV Cache是什么？
16. 为什么说DataLoader在LLM训练中很容易成为瓶颈？
17. 驱动程序升级的变更流程是什么？最需要注意什么？
18. 怎么设计GPU监控告警体系？告警阈值怎么定才科学？
19. GPU服务器常见的硬件故障有哪些？怎么提前发现？
20. 如果公司要建设GPU算力平台，你会怎么规划？

在做面试培训的时候我常说：这些问题看着碎，但背后就一条主线——你能不能把一个GPU任务，从设备分配到运行、监控、调优、故障恢复的全链路管理起来。面试官要的不是你背了多少命令，而是你有没有这套完整闭环的思维。

我自己带人也是这个标准。框架有了，知识往里填就行。希望这套体系能帮你省下几个月的摸索时间。