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是什么”这个热词也出现在热搜里说明很多人在搜面试相关的概念。CTACooperative Thread Arrays协作线程数组是CUDA编程模型中的一个概念比warp高一级一个CTA包含多个warp共享一块共享内存。面试如果问到CUDA编程模型能说清楚线程、warp、CTA、block、grid这几个层次的关系基本就能过关。再说显存层次。GPU有寄存器、共享内存、L2缓存、显存VRAM这几级存储。运维最常打交道的显存带宽远高于CPU内存但容量有限一张A100也只有40GBA100 40G或80GBA100 80G显存。大模型训练时的显存分配主要包括模型参数、梯度、优化器状态、激活值这几块超出显存容量就会报OOM。2.2 NVLink、PCIe和GPU拓扑对性能的影响单机多卡和跨机训练时GPU之间的通信方式决定了扩展效率。这个知识点面试命中率极高。常见的GPU互联方式有PCIe和NVLink。PCIe是通用总线带宽有限一张卡的PCIe 4.0 x16单向带宽大约16GB/sNVLink是NVIDIA专有的GPU间高速互联A100的NVLink单向带宽能到300GB/s第三代NVLinkH100的第四代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-toolkitAI环境全部用容器隔离避免算法同学互相踩依赖。3.3 国产GPU生态昇腾等的基本认知“昇腾系列有哪些gpu”也在热搜里说明国产算力已经是面试必问项。昇腾Ascend是华为推出的AI处理器系列包括昇腾310推理和昇腾910系列训练软件开发栈是CANNCompute 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列出所有GPUCUDA_VISIBLE_DEVICES环境变量控制哪些GPU对程序可见。nvidia-smi是最基础的GPU监控工具但很多人只会看GPU-Util那一列这是远远不够的。nvidia-smi输出字段里有几个面试官爱深挖的点Memory-Usage显存使用量/总量不代表算力使用率。显存占用100%而利用率0%说明程序申请了显存但没在计算。GPU-UtilGPU计算单元利用率。注意这个指标是采样周期内的平均利用率瞬时波动大不能只靠它判断瓶颈。Volatile GPU-Util和GPU-Memory后的ECC、Persistence-M、Compute Mode这些字段分别表示纠错状态、持久模式、计算模式。比nvidia-smi更专业的工具是NVIDIA DCGMData Center GPU Manager配合dcgm-exporter可以把GPU指标接入Prometheus。DCGM能采集的指标非常丰富包括温度、功耗、SM利用率、显存带宽利用率、NVLink通信速率、PCIe吞吐、ECC错误计数等是生产环境GPU监控的事实标准。Grafana社区有很多现成的DCGM Dashboard模板部署后就可以看到GPU核心的完整画像。面试能答出“生产监控用dcgm-exporterPrometheusGrafana而不是用nvidia-smi轮询”说明你有生产环境经验。4.2 算力利用率、显存带宽、功耗等核心指标的业务含义GPU监控指标这么多面试官真正想听的是你对指标业务含义的理解。我整理了一张高频指标对照表指标命令/来源高时表示低时表示GPU-Utilnvidia-smi / DCGMSM执行单元忙空闲或等待同步/数据显存占用Memorynvidia-smi模型和中间件占了显存显存未被利用显存带宽利用率DCGMdram_throughput访存密集计算密集温度nvidia-smi散热瓶颈正常功耗nvidia-smi高负载低负载NVLink吞吐DCGM多卡通信繁忙通信不饱和ECC错误nvidia-smi显存有硬件问题正常这里最容易踩的坑是把GPU-Util当成唯一指标考核。实践里我遇到过GPU-Util只有30%但任务跑得比GPU-Util 80%还快的情况——因为每步迭代里有大量时间花在CPU做数据预处理、数据加载DataLoader和GPU同步上GPU-Util低不代表算力不够可能是CPU喂数据的速度跟不上。面试问到监控告警建议答三层基础设施层宿主机CPU/内存/磁盘/网络用node-exporterGPU设备层DCGM采集的GPU指标应用层训练进度、loss曲线、吞吐。三层指标打通才能从“GPU卡没卡”上升到“训练效率高不高”。4.3 监控告警阈值如何设置才不误报告警阈值是实操里最考验经验的环节。设置太高故障没人发现设置太低半夜被告警轰炸。GPU常用的告警项和推荐阈值GPU利用率低于10%且持续15分钟以上同时任务状态是运行中——大概率是任务卡死或等待死锁值得告警。但要排除任务本身处于验证/推理阶段的低利用率区间。显存剩余不足5%——即将OOM的前兆需要留出缓冲时间处理。GPU温度高于85摄氏度且持续10分钟——散热异常再热可能触发降频保护。ECC错误次数大于0且持续累加——显存有硬件问题需要评估是否换卡。功耗长期接近TDP上限且伴随温度告警——散热跟不上机房空调吃紧。阈值不是一个固定值和具体业务强相关。训练任务GPU-Util天然会周期性抖动推理服务则要求稳定高利用。面试中能把这一点讲清楚比背一堆阈值数字更有说服力。5. 高频问题排查从现象到根因的思维链5.1 场景题1GPU占用不高但就是卡这个场景搜的人最多说明生产环境里太常见了。现象通常是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-appspid,used_memory --formatcsv关联进程和显存再配合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类型和拓扑都由节点池固定避免调度器把任务排到不合适的卡上。多租户场景还有MIGMulti-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延迟和ITLtoken间延迟。并发吞吐的上限受到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运维面试基本不会卡壳简述GPU和CPU在架构和适用场景上的区别。GPU驱动、CUDA、cuDNN在软件栈中的位置和职责是什么宿主机驱动版本和容器内CUDA版本不匹配会出现什么现象怎么处理nvidia-smi输出里哪些字段对运维最有价值为什么怎么查看一台机器上多张GPU的通信拓扑为什么关注这个什么是Xid错误常见Xid错误码有哪些分别代表什么训练任务变慢你会从哪些维度排查显存占用很高但GPU利用率很低可能是什么原因GPU利用率很高但训练速度不快可能是什么原因怎么判断一个推理任务是否被CPU数据准备拖累了K8s下GPU调度的主流方案有哪些各有什么优劣MIG是什么适用什么场景限制是什么大模型训练中一张A100 80G能跑多大参数量模型的全参训练估算依据是什么LoRA微调相比全参训练显存需求差别多大大模型推理怎么估算并发上限KV Cache是什么为什么说DataLoader在LLM训练中很容易成为瓶颈驱动程序升级的变更流程是什么最需要注意什么怎么设计GPU监控告警体系告警阈值怎么定才科学GPU服务器常见的硬件故障有哪些怎么提前发现如果公司要建设GPU算力平台你会怎么规划在做面试培训的时候我常说这些问题看着碎但背后就一条主线——你能不能把一个GPU任务从设备分配到运行、监控、调优、故障恢复的全链路管理起来。面试官要的不是你背了多少命令而是你有没有这套完整闭环的思维。我自己带人也是这个标准。框架有了知识往里填就行。希望这套体系能帮你省下几个月的摸索时间。