AI平台运维工程师培训课件照着流程就能开课

AI平台运维工程师培训课件第1页共1页2026版AI平台运维工程师培训课件解决「GPU抢不到、训练任务一挂全部重跑」：6个模块拆解真实工作流，含课时分配表·课堂练习·结业考核·讲师手册，企业内训与转岗自学都能直接开课课程总说明一、课程基本信息项目内容课程名称AI平台运维实战：从GPU资源池到推理SLA课程定位面向已具备Linux与容器基础的运维人员，用4天把"管服务器"的能力升级为"管AI算力平台"的能力总课时32课时（4天，每天8课时，每课时45分钟）授课形式讲授40%+实验40%+案例研讨20%，全程在实验集群上操作班型20～30人，分5～6组，每组共用一套实验环境前置要求能熟练使用Linux命令行；了解K8s基本对象（Pod、Deployment、Service）；知道GPU是什么但不需要会写CUDA实验环境2台8卡GPU服务器（或云上按小时租用8卡实例），1套K8s集群，1套Prometheus+Grafana，1个对象存储桶，1台IB或RoCE交换机（无硬件时用模拟网络指标代替）考核方式实验操作60%+结业笔试25%+故障演练15%结业标准总分≥70分，且"五层故障定位"实验必须独立完成；未通过者补考一次二、课程目标学完本课程，学员能做到：1.能画出企业AI平台的完整链路图（数据管道→训练平台→模型仓库→推理服务），并指出每一层的故障表征。2.能在K8s集群上划分生产推理池、训练池、探索池三类资源池，配置配额与优先级队列，并解释超卖与抢占的代价。3.能独立提交一个多机多卡训练任务，配置拓扑感知、断点续训与自动重试，并说明每项配置解决什么问题。4.能部署一个推理服务并完成5%→100%的分档灰度，配置弹性扩缩容、限流与就绪探针，说出每档的观察指标与熔断条件。5.能针对"GPU掉卡、显存泄漏、NCCL超时、OOM、驱动冲突、存储IO瓶颈"六类故障，在30分钟内判定所属层级并给出处置动作。6.能用一套指标口径算出集群GPU利用率与单千次调用成本，并给出至少三条可执行的降本措施。7.能针对国产加速卡完成一次最小可用适配（驱动→算子库→框架→模型），并把踩坑记录写成可复用的知识条目。三、课时分配表模块主题课时形式模块一平台全景与岗位认知3讲授+研讨模块二GPU资源池与调度6讲授+实验模块三训练任务全生命周期保障7讲授+实验模块四推理服务发布与SLA6讲授+实验模块五监控告警与五层故障排查6讲授+演练模块六成本优化与国产卡适配4讲授+案例结业考核笔试+实验+故障演练4考核合计—36含2课时机动，可按班型压缩模块一模块一平台全景与岗位认知1.1学习目标●能按"数据—训练—推理"三段说出平台各组件的作用与依赖关系。●能对比传统运维与AI平台运维在资源属性、任务时长、故障层级上的三点差异。●能说出本岗与算法、推理优化、数据工程三个岗位的边界。1.2核心内容1.2.1一条链路上的六个组件AI平台的链路可以拆成六段，每段都有独立的故障模式，运维必须知道"这一段挂了，表象是什么"。组件作用典型技术选型挂了之后的表象数据管道把样本从业务系统搬到训练存储调度器+对象存储+ETL任务训练任务启动即报"文件不存在"，或读到半天前的旧数据训练平台接收任务、分配GPU、管理生命周期K8s+Volcano/Slurm任务长期Pending，或反复重启镜像仓库提供可复现的运行环境Harbor/云镜像服务拉镜像超时，或拉到错误版本导致环境漂移共享存储存放数据集、checkpoint、模型权重并行文件系统/高性能NAS训练卡在数据加载，GPU利用率长期低于30%模型仓库管理权重版本与元信息MLflow/自建元数据服务上线用错版本，回滚找不到上一版权重推理服务把权重变成有SLA的APIvLLM/SGLang/Triton+网关接口变慢、超时、5xx上升1.2.2与传统运维的三个硬差异差异维度传统Web运维AI平台运维直接后果资源属性CPU可超卖，成本低GPU单价高、不可超卖（显存独占）必须做配额与排队，不能"先到先得"任务时长请求级，秒级训练任务3天到3周不能随意重启，必须断点续训故障层级应用—中间件—系统—网络硬件—驱动—框架—模型—业务五层排障必须分层，不能直接怀疑应用容量弹性扩容分钟级大模型冷启动2～8分钟，卡源采购周级容量必须提前规划，不能临时抱佛脚成本结构按CPU核时按GPU卡时，且存在大量闲置浪费必须做利用率治理1.2.3岗位边界：三句话讲清●与算法工程师：本岗给"资源与环境"，算法用"资源与环境"。算法说"训练慢"，本岗要能回答"慢在数据读取、通信还是算力"，而不是回一句"卡就这水平"。●与推理优化工程师：本岗保"稳"，他保"快"。同一张卡，本岗负责它不挂、不超时、容量够；他负责同样的卡跑出更高吞吐。●与AI数据工程师：本岗管管道"跑得通、跑得完、跑得准时"，他管"数据对不对、全不全、质量达不达标"。1.3案例或演示讲师现场打开一套真实（或脱敏）的平台拓扑图，用一次真实故障串起全链路：某天上午推理接口P99从900ms涨到3.2s。逐层排除——业务侧流量翻倍（不是本岗）→推理服务副本数未扩容（容量问题）→扩容后发现新Pod一直Pending（GPU配额不足）→配额被一个跑了11天的训练任务占满（调度问题）→该任务GPU利用率仅8%（占卡不用）。最终结论：一个"接口慢"的表象，根因在调度与配额。这个案例的教学价值：让学员第一次直观感受到"五层链路"不是概念，而是排查顺序。1.4课堂练习每组15分钟，画出本公司（或假设公司）的AI平台链路图，标注：每段用什么技术、谁负责、最可能出什么故障。完成后每组讲3分钟，讲师点评"哪些环节其实没人负责"。1.5讲师提示●学员最容易把"模型效果差"也算进运维问题，要在一开始就划清：效果归算法，可用性归平台。●不要花时间讲GPU微架构，学员当前需要的是"哪些指标能反映硬件异常"。●若学员多来自传统IDC运维，重点强调"任务不能重启"这一点，他们的肌肉记忆是"不行就重启"。模块二GPU资源池与调度2.1学习目标●能按业务属性划分三类资源池，并说明各自的超卖与抢占策略。●能在K8s上配置ResourceQuota、优先级队列与gangscheduling。●能用双指标（分配率、真实利用率）算清集群利用率，并给出回收动作。2.2核心内容2.2.1三类资源池的划分逻辑划分依据不是"部门"，而是"能不能被中断"。池类型承载业务是否超卖是否可被抢占配额单位典型占比生产推理池对外API、在线业务禁止超卖不可抢占卡数（独占）40%～50%训练池有上线日期的训练任务可轻度超卖（1.2倍）仅被P0抢占卡时/月35%～45%探索池实验、调参、验证可超卖（2倍）随时可被抢占卡时/周10%～20%>三类池的物理边界建议用节点标签+污点实现，而不是只靠逻辑配额。逻辑配额挡不住"一个Pod申请整节点"的调度行为。2.2.2调度器选型与关键能力调度器适用场景关键能力主要短板默认调度器+设备插件小规模、单机任务为主部署简单，生态成熟无队列、无gangscheduling，多机任务易死锁VolcanoK8s上的批处理与AI训练队列、优先级、gangscheduling、公平共享配置复杂，需理解PodGroup概念Slurm传统HPC、超算成熟的作业队列与计费与K8s生态割裂，推理服务支持弱Kueue云原生批处理与K8s原生集成好，配额借用清晰生态较新，高级抢占能力弱于VolcanoYARN大数据与AI混部与Hadoop生态一体容器化支持弱，GPU调度粒度粗gangscheduling为什么必须配：一个8机64卡的任务，如果调度器把其中60张卡先分配出去、剩4张卡排队，已分配的60张卡会一直空转等待，集群有效利用率瞬间掉一半，且可能死锁。gangscheduling保证"要么全给，要么一个不给"。2.2.3利用率的正确算法很多团队报的"利用率90%"是假的，因为他们算的是"已分配卡数/总卡数"。真实利用率必须双指标：指标计算方式健康区间异常含义分配率已分配给Pod的卡数/总卡数75%～90%过高说明无空闲应对突发，过低说明调度或配额有问题真实利用率GPUSM占用率>10%的时间/总时间≥65%分配率高但真实利用率低，说明大量"占卡不用"显存利用率已用显存/总显存60%～85%长期低于30%说明可以合卡或换小卡有效卡时占比有checkpoint产出或真实请求的卡时/总卡时≥80%低于此值说明存在无效任务2.3案例或演示讲师现场演示一次"占卡不用"的回收：在实验集群上提交一个申请8卡但只做sleep的任务，观察面板上分配率100%、真实利用率3%；然后执行"连续2小时利用率<5%触发通知→4小时未响应则驱逐"的策略，展示驱逐前后的指标变化与任务方的沟通话术。2.4课堂练习1.给定一个32卡集群和三个业务方的需求（推理24卡常驻、训练每周约200卡时、探索不定），划分资源池并写出配额表。2.在实验集群创建一个Volcano队列，提交一个2机16卡任务，观察不配gangscheduling时的Pending现象，再配置后对比。3.用DCGM数据算出过去1小时的分配率与真实利用率，判断是否存在占卡不用。2.5讲师提示●学员常问"配额定多少合适"。答案是"按历史P90用量上浮20%"，不是拍脑袋平均分。●一定要讲清"超卖的代价"：训练池超卖1.2倍意味着有20%概率任务启动时排队，必须让业务方知情并签字。●抢占策略必须配"抢占前落盘checkpoint"，否则抢一次等于毁掉几天训练，业务方会强烈抵触。模块三训练任务全生命周期保障3.1学习目标●能设计一套强制字段的任务提交模板，把90%的低级错误挡在提交阶段。●能锁定镜像版本矩阵，说明环境漂移的三种成因。●能配置分布式训练网络、断点续训与错误分类重试，并算出"重跑一次损失多少卡时"。3.2核心内容3.2.1任务提交：把错误挡在入口必填字段校验规则不填的后果镜像tag必须精确到版本号，禁止latest环境漂移，实验不可复现数据路径必须为已挂载的共享存储路径任务启动即失败，浪费排队时间预计时长必须填写，超过24小时需说明无法做队列规划与抢占决策优先级P0/P1/P2三选一资源冲突时按提交时间排队，重要任务被堵是否可抢占是/否不可抢占任务被误抢，损失数天训练checkpoint间隔建议500～1000步故障后重跑，损失不可控负责人与联系方式必填卡死任务无人认领，只能占卡3.2.2镜像版本矩阵与环境漂移环境漂移有三种成因，对应三种防法：成因现象防法基础镜像被覆盖同一tag内容变了，昨天能跑今天报错基础镜像只增不改，版本号进tag，禁用latest依赖在线安装pipinstall未锁版本，拉到新版本后API变了依赖全部预装进镜像，禁止运行时联网安装驱动与CUDA不匹配宿主机驱动升级后旧镜像全部失效维护驱动-CUDA-框架三维矩阵，升级前灰度验证版本矩阵示例（讲师按企业实际情况替换）：矩阵行驱动版本CUDA版本框架版本适用任务状态稳定线53512.1PyTorch2.1.0生产训练与推理主力，禁止随意变更新特性线55012.4PyTorch2.4.0新模型验证灰度，仅限探索池兼容线47011.4PyTorch1.13历史任务复现冻结，不再新增3.2.3断点续训与错误分类重试错误类型典型报错是否重试处置动作节点故障节点NotReady、XID错误是换节点重调度，从最近checkpoint恢复网络抖动NCCLtimeout、IBlinkdown是（限3次）重调度到同leaf节点，连续3次失败升级人工显存不足CUDAoutofmemory否通知任务方调整batch或并行策略数据错误文件不存在、格式解析失败否通知任务方修数据，避免无效重试占用卡代码异常Pythontraceback、断言失败否直接失败，附完整堆栈存储超时IOerror、readtimeout是（限2次）检查存储水位与带宽，排除后重试算一笔账：一个64卡任务跑5天，若第4天因单卡故障中断且无checkpoint，损失=64卡×96小时≈6100卡时。按每卡时20元计，一次中断约12万元。而配checkpoint的成本是每1000步多写一次存储，几乎可以忽略。3.2.4分布式训练网络●拓扑感知：同一leaf交换机下的节点优先成组调度，跨leaf通信带宽通常只有同leaf的1/2到1/4。●带宽基线：上线前必须跑一次all-reduce基准，记录不同卡数下的带宽，作为后续"变慢"的判断依据。●常见配置错误：网卡未绑NUMA、IB网卡未启用RDMA、MTU不一致、NCCL未指定网卡列表。四类错误占通信故障的多数。3.3案例或演示演示一个8机64卡任务的完整生命周期：提交→排队→调度→启动→NCCL带宽校验→训练中单节点故障→自动重试→从checkpoint恢复→完成。全程在面板上展示GPU利用率曲线、通信带宽曲线与日志，让学员看到"一次故障恢复"在数据上长什么样。3.4课堂练习1.为一个假设任务（8机64卡、预计72小时、可抢占）填写完整提交模板，并计算"checkpoint间隔设为1000步时的最坏损失"。2.在实验环境人为kill一个worker进程，观察自动重试是否触发，检查恢复后起始step是否正确。3.给定一段NCCLtimeout日志，判断是网络问题、拓扑问题还是配置问题。3.5讲师提示●"重试"不是万能药。必须让学员理解：不可重试的错误重试100次也只是浪费100次卡时。●讲checkpoint时一定要算钱，学员对"损失12万"的记忆远深于"要配checkpoint"。●拓扑感知在小集群（单机8卡）上体现不出来，若实验环境只有单机，用拓扑图讲解代替实操。模块四推理服务发布与SLA4.1学习目标●能写出一份包含副本数、资源规格、探针、限流的部署配置。●能设计分档灰度方案，说出每档的观察指标、观察时长与熔断条件。●能根据流量曲线与冷启动时间设计扩缩容策略，避免"扩了但来不及"。4.2核心内容4.2.1发布单元与部署配置一个可发布的推理服务，配置里必须包含六类信息，缺一类就会在上线后暴露问题：配置类别必填项缺失后果模型权重路径、版本号、tokenizer路径加载到旧版本，输出与测试不一致引擎推理引擎及版本、最大并发、最大模型长度并发超限时OOM或排队雪崩资源GPU型号、卡数、显存上限、CPU与内存调度到错误机型，或与共卡模型互相挤占探针存活探针、就绪探针（须真实推理）模型加载失败仍接流量扩缩容最小/最大副本、扩缩容指标与阈值流量峰值扛不住，或缩到0导致冷启动超时限流QPS上限、排队上限、超限错误码过载时请求无限挂起，连接池耗尽4.2.2灰度发布的四档节奏档位流量比例最短观察时长重点观察指标熔断条件第一档5%30分钟错误率、P99、输出抽样一致性错误率上升>0.5个百分点第二档20%60分钟P99、TTFT、GPU显存水位P99超过SLA的1.2倍第三档50%120分钟上述全部+上游超时率上游超时率翻倍第四档100%24小时全量SLO、成本、负反馈任一SLO跌破错误预算>灰度不只是"切流量"，还必须做输出一致性比对：同一批固定输入在新旧两版上各跑一次，比较输出差异率。差异率超过预期（例如换了量化版本，差异率15%）要提前与业务方确认可接受。4.2.3扩缩容：冷启动是最大的坑指标触发阈值示例优点缺点GPU利用率持续5分钟>70%扩容直接反映算力压力大模型加载慢，扩出来时已经晚了排队深度队列>10扩容提前于延迟恶化需引擎支持队列指标P99延迟超过SLA的0.8倍扩容最贴近用户体验滞后，容易过冲定时策略按历史曲线预设应对可预测高峰最有效无法应对突发组合策略：定时策略打底（覆盖已知高峰）+P99与队列深度做实时补充+最小副本保底（不允许缩到0）。冷启动时间必须实测并写入容量文档：7B模型冷启动约1～2分钟，70B级模型可能5～8分钟。4.2.4多模型共卡与限流●共卡前提：小模型（显存占用<10GB）可共卡，但必须为每个模型设显存硬上限，防止一个模型的长请求把整卡吃满。●共卡风险：一个模型故障（如死循环）会拖垮同卡其他模型，因此共卡只用于低优先级或可容忍抖动的服务。●限流三层：网关层（全局QPS）、服务层（单副本并发）、模型层（最大batch与队列）。三层缺一层，过载就会穿透。4.3案例或演示演示一次"上线把P99打穿"的完整过程：新版本模型未做量化、显存占用翻倍、单卡并发从8降到4、副本数未调整，灰度到20%时P99从800ms涨到2.6s，触发熔断自动回滚。回滚后讲师带学员逐项复盘：如果当时先做压测、先算显存、先调副本，哪一步能拦住。4.4课堂练习1.为一个7B模型服务写部署配置，包含探针、资源、扩缩容、限流四部分，并说明每个数值的依据。2.设计一个灰度方案：从5%到100%，写出每档的观察指标与熔断阈值。3.给定一条流量曲线（早9点与晚8点双高峰），设计定时扩缩容策略并计算所需最小副本数。4.5讲师提示●学员最容易忽略"就绪探针要真实推理"。必须强调：只检查端口通不通，等于没检查。●讲灰度时用"错误预算"概念比讲"错误率阈值"更有说服力：一季节省下来的预算可以换一次大胆发布。●共卡部分不要讲太深，除非学员企业确实有大量小模型。模块五监控告警与五层故障排查5.1学习目标●能设计一套GPU硬件、训练任务、推理服务三层的监控指标与告警规则。●能按五层排查树，在30分钟内判定故障所属层级。●能识别"告警疲劳"的成因并给出收敛方案。5.2核心内容5.2.1三层监控指标清单层级必采指标采样频率典型阈值GPU硬件温度、功耗、显存、ECC可纠正/不可纠正、XID、PCIe与NVLink降速15秒温度>85℃告警，不可纠正ECC立即告警并摘卡训练任务任务状态、GPU利用率、日志输出间隔、loss、checkpoint时间30秒30分钟无日志且利用率<3%判卡死推理服务P50/P95/P99、TTFT、tokens/s、错误率、队列深度、显存水位10秒P99>阈值持续5分钟告警平台资源节点状态、卡分配率、存储水位、网络带宽30秒存储水位>80%预警，>90%告警成本卡时消耗、单千次调用成本、按namespace用量1小时日环比波动>15%告警5.2.2五层排查树（本课程的核心工具）层级判定问题典型现象首查命令或动作第一层硬件卡还在不在、有没有硬件错误训练突然中断、卡数变少nvidia-smi、dmesg查XID、DCGM查ECC第二层驱动与CUDA驱动版本、CUDA运行时是否匹配报"driverversioninsufficient"、CUDAerror查驱动版本、容器内CUDA版本、兼容矩阵第三层框架与通信NCCL、分布式初始化、并行策略NCCLtimeout、all-reduce卡住、rank不齐查NCCL日志、ibstat、带宽基线对比第四层模型与权重权重完整性、tokenizer、显存占用加载失败、输出乱码、OOM校验文件哈希、比对显存估算第五层业务链路超时、重试放大、限流、上游依赖接口慢但GPU指标正常查网关指标、上游QPS、重试次数排查纪律：必须自下而上或自上而下单向推进，不允许跳层。跳层的典型错误是"接口慢就重启服务"，而根因是第一层的一张卡降速。5.2.3告警分级与疲劳治理级别定义通知方式响应时限P1线上服务不可用或大面积降级电话+短信15分钟P2部分用户受影响或SLA即将耗尽短信+群消息30分钟P3潜在风险，暂不影响业务群消息当班处理P4记录类，仅看板展示无通知周会回顾告警疲劳的三个成因：阈值拍脑袋（例如GPU温度告警设60℃，正常负载就到70℃）；同一根因重复告警（一个节点掉卡触发20条规则）；没有责任人（发到群里没人认领）。对应三招：用历史P95数据定阈值、做告警聚合与抑制、每条告警绑定owner。5.3案例或演示讲师给出四段真实日志片段（XID79、NCCLtimeout、CUDAOOM、驱动版本不匹配），学员分组判断属于第几层、下一步动作是什么。讲师现场演示一次完整的XID排查：nvidia-smi看到卡消失→dmesg看到XID79→判定为GPU掉卡→cordon节点→驱逐任务→报修。5.4课堂练习1.为实验集群写5条PromQL告警规则，覆盖GPU温度、显存、任务卡死、P99、存储水位。2.给定一个"训练突然变慢3倍"的场景，按五层顺序写出排查步骤与每步的判定依据。3.对现有告警列表做一次收敛：找出重复告警、无主告警、阈值不合理的告警各一条。5.5讲师提示●五层排查树要打印成A4卡片发给学员，让他们带走。●学员容易在第二层和第三层之间混淆（CUDA错误vsNCCL错误），用"报错里出现nccl字样先归第三层"这类简单规则帮助记忆。●强调"重启不是排查"，重启只是把现场销毁了。模块六成本优化与国产卡适配6.1学习目标●能算出集群的卡时成本、单千次调用成本，并定位最贵的业务。●能列出至少五种降本手段并说明各自的前提条件与风险。●能描述国产卡适配的四步流程与三类典型卡点。6.2核心内容6.2.1成本结构与五种降本手段手段适用前提预期降幅主要风险闲时缩容流量有明显昼夜差异10%～20%缩得太狠导致早高峰冷启动超时训练推理混部训练任务可被抢占15%～25%混部不当导致推理P99抖动竞价实例任务可中断、有checkpoint30%～60%中断频繁，重跑成本抵消折扣卡型匹配小模型用大卡、或反之20%～40%换卡需重新压测与调参利用率治理存在占卡不用视情况，可达30%需业务方配合，沟通成本高测算方法：单千次调用成本=（月度GPU费用+存储费用+网络费用）/月度有效调用次数（千次）。按服务分别计算，才能发现"哪个服务在烧钱"。常见结论是：20%的服务消耗了60%的算力。6.2.2国产卡适配的四步流程步骤动作完成标志典型耗时一、环境打通装驱动、固件、CANN或对应算子库，跑通健康检查设备可见、算力跑分达标1～3天二、框架适配安装对应框架版本，跑通单卡推理单卡输出与GPU版一致2～5天三、多卡与算子跑通多卡通信，替换不支持的算子多卡线性度达标，无算子回退1～3周四、模型验证全量模型跑通，比对精度与性能精度差异在容忍范围，性能达基线比例1～2周三类典型卡点：驱动与固件版本必须严格配对，错一个版本就报设备初始化失败；算子库对某些算子不支持，会静默回退到CPU导致性能骤降（表现为"能跑但慢10倍"）；框架版本与算子库版本强绑定，升级框架必须同步升级算子库。>国产卡适配的最大成本不是技术，而是资料少、社区弱。必须自建知识库：每条踩坑记录包含现象、报错原文、根因、解法、验证方式，否则同一个坑会在半年后由另一个人再踩一遍。6.3案例或演示讲师展示一份脱敏的成本月报：三个业务线共用一个64卡集群，A业务占卡40%但只产生15%的调用量。逐项分析后发现A业务的模型可以用更小的卡型，迁移后月度成本下降22%，P99无变化。学员讨论：如果你是运维，怎么说服A业务迁移？6.4课堂练习1.用给定的用量数据算出三个业务的单千次调用成本，排出优先级。2.为一个可中断的训练任务设计竞价实例方案，估算中断率与重跑成本，判断是否划算。3.列出国产卡适配中你会写进知识库的五个字段。6.5讲师提示●成本话题容易变成"运维背锅"，要强调：成本是业务、算法、平台三方共担，运维提供数据与手段。●国产卡部分不要评价厂商优劣，只讲适配方法论与共性卡点，避免争议。●竞价实例的账一定要算给学员看，"折扣60%但重跑两次"是亏的。结业考核一、考核构成考核项形式时长分值合格线笔试闭卷，30题（选择+简答）60分钟25分15分实验一资源池划分与配额配置60分钟20分12分实验二多机任务提交与故障恢复90分钟20分12分实验三推理服务部署与灰度90分钟20分12分故障演练随机抽取一类故障现场处置30分钟15分9分合计——100分70分二、评分维度表维度观察点分值占比操作正确性命令与配置无误，未造成环境破坏40%排查逻辑按层推进，有判定依据，不跳层不瞎试30%文档与记录操作有记录，结论有证据，能复现15%时间控制在规定时间内完成，超时按比例扣分10%沟通表达能向"业务方"解释故障与影响面5%三、合格标准●总分≥70分，且实验二、实验三均≥12分，故障演练≥9分。●故障演练中出现"未判断层级直接重启生产服务"的行为，该项直接判0分并需重考。●笔试简答题出现"加强监控""提高意识"类无动作答案，该题不计分。附录讲师手册常见学员问题与标准回答序号学员问题标准回答1我们没有K8s，只有Slurm，课上的调度内容还用得上吗队列、优先级、抢占、gangscheduling的概念完全通用，只是配置语法不同。实验可改用Slurm的squeue与sbatch演示2GPU利用率65%是不是太低了，CPU都能到90%GPU的算力单元与显存是两套资源，数据加载与通信阶段利用率天然下降。65%是含等待