AI平台运维工程师面试题库（核心题库必背）

AI平台运维工程师面试题库第1页共1页AI平台运维工程师面试题库解决「面AI平台运维工程师问不出真本事、评分全靠感觉」：42题覆盖基础认知·实操应用·项目追问·风险避坑·开放思辨，每题附参考答案与追问链，含评分表与红旗信号使用说明一、题库定位本题库用于AI平台运维工程师（训练平台+推理服务+数据管道）的面试评估，覆盖L1～L3层级。题目围绕一条主线：候选人能否在"GPU稀缺、任务长跑、服务有SLA、故障跨五层"的约束下做出正确判断。题库不考察CUDA编程与模型算法细节——那是推理优化工程师与算法工程师的考察范围。本岗考察的是：资源怎么分、任务怎么保、服务怎么稳、故障怎么定层、钱怎么省。二、题目结构与建议用时部分题量建议用时考察目的适用层级一、基础认知题1220分钟概念是否清晰，是否存在"背术语"L1～L3二、实操应用题1030分钟有没有真干过，步骤是否可执行L1～L3三、项目经验题625分钟经历的深度与个人贡献的真实性L2～L3四、风险与避坑题815分钟判断力与边界意识L2～L3五、开放思辨题615分钟是否有体系化思考L3合计42约105分钟建议拆成两轮，单轮不超过60分钟—抽题建议：L1抽基础8题+实操5题；L2抽基础6题+实操6题+项目3题+风险4题；L3抽实操6题+项目4题+风险4题+思辨4题。三、评分锚点（1～5分）分值行为特征判定口径5给出完整步骤、量化依据、边界条件与失败预案可直接照着做，且能说出"什么情况下这招不管用"4步骤完整，有量化依据，缺少边界讨论能落地，但遇到异常可能卡住3方向正确，步骤不全或凭经验无数据需要有人带一次才能独立做2只答概念，说不出操作属于"看过书"层级1答错或答非所问概念性错误，存在操作风险四、面试官注意事项●必须追问"然后呢"：本岗的核心能力是排查链条，候选人答完第一步就停的，追问第二步、第三步，看是否真有经验。●用真实日志代替假设题：准备3～4段脱敏日志（XID报错、NCCLtimeout、CUDAOOM、PodPending事件），比纯口头提问的区分度高出一倍以上。●警惕"重启型"答案：任何以"重启一下就好了"作为主要处置手段的回答，都要追问"重启之前你判断是哪一层"，答不出则记录红旗。●不要用算法题筛人：本岗不需要手写Transformer，出算法题只会筛掉真正能干活的人。●记录原话：评估表里写候选人原话，不写"感觉不错"。事后复盘时只有原话能复现判断。一、基础认知题（12题）Q1.GPU利用率和分配率有什么区别？你们报的利用率是怎么算的？参考答案要点：1.分配率=已分配给Pod的卡数/总卡数，反映"占了多少"，不反映"用了多少"。2.真实利用率通常用GPUSM占用率大于某阈值（如10%）的时间占比，或用DCGM的GPU利用率指标。3.只报分配率会掩盖"占卡不用"，很多团队报90%实际有效算力不到40%。4.还应看显存利用率，长期低于30%说明可以合卡或换小卡。5.更严格的口径是"有效卡时占比"：有checkpoint产出或有真实请求的卡时/总卡时。追问：如果分配率85%、真实利用率35%，你会先查什么？Q2.K8s是怎么把一张GPU分配给Pod的？参考答案要点：1.节点安装GPU设备插件（deviceplugin），向kubelet注册扩展资源，如/gpu。2.Pod在resources.limits里声明GPU数量，调度器按扩展资源余量做过滤与打分。3.GPU是整数资源，不可压缩、不可超卖，一张卡在同一时刻只能给一个容器（MIG或时间片除外）。4.容器运行时负责把设备节点与驱动库挂进容器。5.常见坑：只写requests不写limits导致资源不生效；节点有卡但插件异常时资源显示为0，Pod一直Pending。追问：节点上nvidia-smi能看到8张卡，但kubectldescribenode显示GPU为0，你怎么查？Q3.什么是gangscheduling？不配会怎样？参考答案要点：1.gangscheduling要求一组Pod"要么全部调度成功，要么全部不调度"。2.不配的后果：8机64卡任务被分配了60卡，剩4卡排队，已分配的60卡空转等待，可能死锁。3.有效利用率会瞬间掉一半，且排队时间不可预测。4.实现方式：Volcano的PodGroup、Kueue的Workload、或调度器插件。5.配套需要设置组超时，避免组内一个Pod永远等不到而拖住整组。追问：配了gangscheduling后，发现大任务长期排不上，小任务也起不来，可能是什么原因？Q4.为什么训练任务不能像Web服务那样滚动重启？参考答案要点：1.训练是长事务，状态在GPU显存和进程内存里，重启即丢失。2.一个大任务跑3天到3周，重启意味着已消耗卡时全部作废，按卡时直接折算成钱。3.分布式训练还有rank概念，重启后需要重新初始化通信组，处理不当会死锁。4.正确做法是断点续训：定期存checkpoint，重启后从最近检查点恢复。5.运维动作必须先判断"这个操作会不会杀掉长任务"，例如节点排水要先看有无不可中断任务。追问：集群要升级驱动，必须重启所有节点，你会怎么安排？Q5.断点续训需要保存哪些内容？只存模型权重够不够？参考答案要点：1.模型参数、优化器状态（Adam的一阶二阶矩）、学习率调度器状态。2.当前step/epoch、数据加载器的位置与随机种子、各rank的RNG状态。3.混合精度训练的scaler状态。4.只存权重会导致恢复后优化器动量丢失，loss出现跳变，效果变差。5.还需记录保存时的代码commit与镜像digest，否则恢复后行为不一致。追问：恢复后loss比中断前高了一截，你怎么判断是正常波动还是续训没配对？Q6.GPU的XID错误是什么？哪些必须立即摘卡？参考答案要点：1.XID是NVIDIA驱动报告的错误码，出现在dmesg与系统日志中，用于标识GPU硬件或驱动级异常。2.与显存、总线、掉卡相关的严重错误码（如79掉卡、48双比特ECC、62页表错误）必须立即摘卡。3.处理动作：cordon节点、驱逐可迁移任务、记录卡序列号与错误码、报修。4.不能只重启了事——重启后卡可能短暂恢复，但在高负载下复发，且会污染同节点其他任务。5.必须建立单卡档案，记录同一张卡的历次错误，供厂商判断是否更换。追问：一张卡一个月内出现3次XID错误但每次重启都恢复，你怎么处理？Q7.ECC可纠正错误和不可纠正错误，处理上有何区别？参考答案要点：1.可纠正错误（单比特）由硬件自动修正，不直接影响结果，但计数上升说明显存老化。2.不可纠正错误（双比特）会导致数据错误，可能静默污染训练结果，必须立即停用该卡。3.可纠正错误的处置是监控趋势：单位时间内计数快速增长（如日增数百）则安排更换。4.需要区分"总量"与"增量"，只看总量会误判老卡的正常累积。5.训练场景对静默错误尤其敏感，宁可多换卡也不要带病运行。追问：训练loss出现不明原因的尖刺，你会不会怀疑是ECC问题？怎么验证？Q8.NCCL是做什么的？多机训练为什么需要它？参考答案要点：1.NCCL是集合通信库，实现all-reduce、all-gather、broadcast等操作，让多卡之间同步梯度。2.它负责选择通信拓扑（NVLink、PCIe、IB、RoCE）与算法（Ring、Tree）。3.多机训练必须依赖它，通信效率直接决定线性度：通信占比高时，加卡不加速。4.常见问题是网卡未绑NUMA、IB未启用RDMA、跨leaf通信、MTU不一致。5.排查工具：NCCL日志级别、ibstat、perftest带宽测试、与基线比对。追问：8机训练，从4机扩到8机后吞吐只涨了20%，你怎么定位？Q9.推理时显存都花在哪几部分？参考答案要点：1.模型权重（与参数量、精度相关）、KVCache（与并发数、序列长度、层数相关）。2.激活值与临时缓冲区、CUDA上下文与框架自身开销。3.显存碎片：反复分配释放导致无法利用的空洞。4.KVCache往往是并发上不去的主因，长上下文场景尤其明显。5.估算时必须按"权重+最大并发×单请求KV"算，不能只按权重算。追问：一个7B模型权重只占14GB，为什么在80GB卡上并发开到32就OOM？Q10.推理服务的P99和TTFT分别反映什么？参考答案要点：1.TTFT是首token时间，反映排队+预填充阶段，用户感知为"多久开始出字"。2.P99是尾部延迟，反映最慢的1%请求，通常由排队、长输入、GC或抢占引起。3.流式输出场景下，用户体感主要由TTFT与tokens/s决定，总时长反而次要。4.只看平均延迟会掩盖尾部问题，SLA必须用分位数。5.P99恶化但P50正常，通常是容量临界或个别实例异常，应查副本间差异。追问：P50是400ms、P99是5s，你会先怀疑容量还是怀疑个别坏实例？Q11.灰度发布为什么不能一次全量？灰度的关键动作是什么？参考答案要点：1.新版本的问题往往在真实流量分布下才暴露，测试环境覆盖不到长尾。2.分档（5%→20%→50%→100%），每档观察足够时长或足够请求量。3.关键动作不只是切流量，还要做输出一致性比对：固定样本新旧版各跑一次。4.必须有自动熔断条件与10分钟内可完成的回滚路径。5.灰度期间要盯的不止错误率，还有P99、显存水位、上游超时率。追问：灰度到20%时错误率没变但客诉上升，你怎么处理？Q12.国产加速卡适配的主要难点在哪？参考答案要点：1.驱动、固件、算子库、框架四者版本强绑定，错一个版本就初始化失败。2.算子覆盖不全，不支持的算子会回退到CPU，表现为"能跑但慢十倍"，且不报错。3.文档少、社区弱，遇到问题缺少可搜索的案例，需要自建知识库。4.多卡通信库的成熟度与调优空间与主流方案有差距，需要重新测带宽基线。5.迁移必须做精度与性能双比对，不能只看"能跑通"。追问：模型在国产卡上跑通了，但吞吐只有原卡的三分之一，你的排查顺序是什么？二、实操应用题（10题）Q13.一个Pod一直Pending，说说你的完整排查顺序。参考答案要点：1.看事件：describepod，读Events里的具体原因（Insufficient、Untainted、UnboundPVC等）。2.看资源：节点GPU余量、显存是否被占、CPU与内存是否够。3.看调度约束：nodeSelector、亲和性、污点容忍是否把自己限制死了。4.看配额：namespace的ResourceQuota是否已满，队列是否达上限。5.看设备插件：节点GPU资源是否注册成功，插件Pod是否正常。6.看存储：PVC是否Bound，存储类是否可用。7.结论要落到"哪一条约束不满足"，而不是"再等等"。追问：事件显示"0/20nodesareavailable:20Insufficient/gpu"，但看板显示集群还有16张卡空闲，怎么解释？Q14.一个训练任务突然变慢3倍，你怎么查？参考答案要点：1.先分层：是数据读取慢、通信慢、还是算力慢。2.看GPU利用率曲线：若周期性掉到0，多半是数据加载；若平稳但低，可能是通信或降频。3.查数据侧：存储带宽、IO等待、是否有其他任务抢占带宽。4.查通信侧：NCCL带宽与基线比对，是否被调度到跨leaf节点。5.查硬件侧：温度是否触发降频、是否有卡降速、PCIe是否降级。6.查任务侧：是否换了镜像、改了并行策略、数据量变大。7.每一步都要有数据支撑，不能靠猜。追问：如果各项指标都正常，但吞吐就是上不去，你还会看什么？Q15.监控告警某节点GPU掉卡，你的处置流程是什么？参考答案要点：1.确认：nvidia-smi对比卡数，dmesg查XID错误码，DCGM查ECC。2.隔离：立即cordon节点，防止新任务调度上去。3.止损：驱逐可迁移任务；不可中断的长任务先通知任务方并保存checkpoint。4.记录：卡序列号、槽位、错误码、发生时间、影响任务清单。5.报修：提交工单，注明已做的验证，避免厂商来回确认。6.复盘：判断是否与温度、供电、批次相关，若同批次多卡出现则升级为批量问题。7.验收：换卡后跑压力测试与带宽基线，确认恢复到正常水平再解除cordon。追问：这台机器上有一个跑了5天的任务，且没有checkpoint，你怎么办？Q16.怎么判断推理服务存在显存泄漏？发现后怎么处置？参考答案要点：1.判断：固定并发下长时间运行，显存占用单调上升且不回落，重启后恢复。2.区分：请求级OOM（单条输入过长）是尖峰，泄漏是趋势。3.定位：按输入长度分桶统计显存，看是否与某类请求强相关。4.止血：设置单副本最大请求数，达到阈值滚动重启，保留现场。5.根治：升级引擎版本、关闭可疑特性、限制最大序列长度。6.长期：把"显存随时间的斜率"做成监控指标，斜率异常即告警。追问：滚动重启会中断在途请求，你怎么做到用户无感？Q17.NCCLtimeout怎么排查？能不能直接调大超时时间？参考答案要点：1.不能。调大超时只是把故障延迟暴露，根因仍在。2.第一步看是哪个rank报错，是否固定在某台机器或某张卡。3.查网卡与链路：ibstat看端口状态，是否有linkdown、降速。4.查拓扑：是否跨leaf，跨leaf带宽通常只有同leaf的一半到四分之一。5.查配置：网卡是否绑NUMA、是否启用RDMA、MTU是否一致、NCCL是否指定网卡列表。6.查硬件：该节点是否有XID或ECC错误导致通信卡顿。7.查负载：是否有其他任务抢占了IB带宽。8.结论必须落到具体一层，不能写"重启后恢复"。追问：同一份代码在4机上正常、8机上必超时，你优先怀疑什么？Q18.一个推理服务P99从800ms涨到3s，GPU指标正常，你怎么查？参考答案要点：1.先看流量：QPS是否上涨、是否有重试放大（同一请求ID出现多次）。2.看副本：副本数是否变化、是否有实例不健康但仍在接流量。3.看输入分布：是否出现大量长输入，导致KVCache暴涨、批处理效率下降。4.看排队：队列深度是否上升，是否触发了限流。5.看上游：网关、鉴权、依赖服务的耗时是否变化。6.看变更：近期是否有发布、配置变更、模型切换。7.GPU正常只说明算力没瓶颈，不代表链路没问题。追问：查出是上游重试放大，你作为平台方能做什么？Q19.给你一个100卡的集群，三个业务方，你怎么设计资源池？参考答案要点：1.先问业务属性：是否有对外SLA、任务是否可中断、峰值形态。2.划分三类池：生产推理（40～50卡，独占不超卖）、训练（35～45卡，可轻度超卖）、探索（10～20卡，可抢占）。3.用节点标签+污点做物理隔离，不只靠逻辑配额。4.配额按"卡时/月"下发，同时设卡数上限，双约束。5.定义优先级：P0可抢占P2，抢占前强制checkpoint。6.留出10%缓冲应对突发与故障，不做满配。7.配套利用率度量与月度对账机制。追问：三个业务方都说自己需要60卡，你怎么谈？Q20.集群GPU利用率只有40%，你怎么把它提到65%？参考答案要点：1.先诊断结构：是分配率低（没任务）还是真实利用率低（占卡不用）。2.分配率低：查是否有卡不可调度（掉卡未摘、驱动异常、配额碎片）。3.真实利用率低：查占卡不用（连续2小时<5%）、数据加载瓶颈、通信瓶颈。4.措施一：闲置回收策略，通知+驱逐，配套沟通话术。5.措施二：小任务合卡（MIG或时间片），提高碎片利用率。6.措施三：训练与推理混部，填谷。7.措施四：调度优化，减少排队空转，启用gangscheduling。8.每个措施都要有前后对比数据，不能只说"做了优化"。追问：提到65%之后P99开始抖动，你怎么权衡？Q21.设计一个新模型上线的灰度方案。参考答案要点：1.前置：压测拿到基线（不同并发下的P99、TTFT、显存水位）。2.分档：5%→20%→50%→100%，每档至少30分钟或累计1万次请求。3.每档观察：错误率、P99、TTFT、显存水位、上游超时率。4.一致性：固定100条输入新旧版各跑一次，差异率在约定范围内。5.熔断：错误率上升>0.5个百分点或P99超SLA的1.2倍，自动回滚。6.回滚：镜像与权重保留，10分钟内完成，且演练过。7.放量后24小时继续观察，纳入周报。追问：这个服务日均只有200次调用，灰度分档还有意义吗？Q22.让你设计一套GPU相关的告警规则，你会怎么定阈值？参考答案要点：1.先分级：P1电话（不可纠正ECC、批量掉卡、服务不可用）、P2短信（单卡异常、P99超阈值）、P3群消息、P4仅看板。2.阈值来源：历史P95数据，不用默认值。3.温度：正常负载下的P95上浮10℃作为预警线，硬件上限前留10℃余量。4.ECC：不可纠正立即告警；可纠正按"日增量"而非总量告警。5.显存：按"无任务却高占用"和"斜率异常"两条规则，而非单纯百分比。6.必须做聚合与抑制：一个节点掉卡只产生1条主告警，其余关联告警抑制。7.每条告警绑owner与升级路径。追问：上线一周后发现日均300条告警，你怎么收敛到20条以内？三、项目经验题（6题）Q23.讲一个你处理过的最难的故障。参考答案要点：1.听结构：现象→影响面→排查路径→根因→处置→预防，六段是否齐全。2.听分层：是否明确说到"先排除了哪一层"，而不是一上来就重启。3.听数据：有没有具体的指标、日志、时间点。4.听个人贡献：是他判断的，还是别人告诉他答案的。5.听预防：事后做了什么机制性改进，有没有量化效果。追问链：●第一层：这个故障的表象是什么？影响多少用户或多少任务？●第二层：你最先怀疑哪一层？为什么不是别的层？●第三层：你用什么数据排除了其他可能？●第四层：如果当时没有那个工具或权限，你会怎么绕过去？●第五层：这件事之后，你推动了什么改动？现在同类故障还会发生吗？评分要点：5分=六段齐全且预防有量化；3分=能说清过程但无预防；1分=只说"重启后恢复"。红旗：全程只有"我协调了厂商""我上报了领导"，没有个人技术判断。Q24.讲一次你从0到1搭建或改造平台的经历。参考答案要点：1.起点：当时是什么状态（几张卡、什么调度方式、痛点在哪）。2.决策：为什么选这个调度器/这套监控，有没有比较过替代方案。3.落地：分几期、每期交付什么、遇到的最大阻力是什么。4.结果：利用率、故障率、交付时长的前后对比。5.反思：哪一步做错了，如果重来会怎么改。追问链：●当时为什么不用现成的云托管方案？●迁移期间老任务怎么办，有没有停机窗口？●用户（算法同学）最初的抵触点是什么，你怎么化解的？●这套东西现在谁在维护，你走了会不会瘫？评分要点：5分=有选型对比、有分期、有量化结果、有反思；3分=只讲结果不讲取舍。红旗：把"采购了一批服务器"说成"搭建平台"。Q25.讲一次你主导的成本优化，省了多少钱，怎么省的？参考答案要点：1.基线：优化前的月度支出与成本结构（卡时、存储、网络各占多少）。2.定位：哪个业务或队列最贵，为什么贵（卡型不匹配、利用率低、闲置）。3.手段：闲时缩容、混部、竞价实例、换卡型、利用率治理，用了哪几种。4.数字：省了多少百分比，绝对金额，SLA有没有变化。5.风险：降本带来的新问题（冷启动、中断、抖动）怎么兜住。追问链：●你怎么说服业务方接受缩容或换卡型？●降本之后P99有没有变化，你怎么证明没有牺牲稳定性？●竞价实例被回收过几次，重跑成本算进去了吗？●如果下季度还要再降15%，你还有什么牌？评分要点：5分=能算清账、有SLA对比、有下一步；3分=只说省了钱说不清口径。红旗：把"财务谈判砍价"说成"成本优化"，或省了钱但答不出SLA影响。Q26.讲一次国产卡适配的经历。参考答案要点：1.卡型与场景：什么卡、跑训练还是推理、什么模型。2.流程：环境打通→框架适配→多卡与算子→模型验证，每步耗时多久。3.卡点：遇到的具体问题（算子回退、版本不匹配、通信异常）。4.结果：性能达到原卡的百分之多少，精度差异多少。5.沉淀：有没有形成知识库或适配清单。追问链：●哪个算子不支持，你怎么发现的？静默回退还是报错？●性能只有原卡60%，你认为差距在算子、通信还是框架？●这套适配经验能复用到另一个模型吗？●如果让你给公司提建议，什么场景该用国产卡，什么场景不该？评分要点：5分=四步清晰、卡点具体、有性能数字、有复用结论；3分=只跑通过demo。红旗：说"装个驱动就能跑"，或答不出精度比对方法。Q27.讲一次你做的自动化，替代了多少人工。参考答案要点：1.场景：哪个高频人工动作（巡检、扩缩容、故障处置、报表）。2.方案：用什么实现（脚本、Operator、告警联动），触发条件是什么。3.边界：哪些情况自动处理，哪些必须人工确认。4.效果：节省多少工时/月，误判率多少。5.安全：有没有防止"自动化放大故障"的开关。追问链：●自动化误判过一次吗？后果是什么？●怎么防止它在异常情况下反复执行错误动作？●出了事谁负责，责任边界怎么划？●如果让你继续做，下一个自动化的点在哪？评分要点：5分=有边界设计、有熔断开关、有量化收益；3分=写了个脚本但没考虑误判。红旗：自动化没有人工兜底，或答不出"误杀"怎么办。Q28.讲一次你和算法团队（或业务方）的资源冲突，怎么解决的？参考答案要点：1.冲突本质：资源不够，还是优先级没定义。2.处理：用数据说话（历史用量、利用率、交付影响），而不是比谁嗓门大。3.机制：推动建立配额与优先级规则，把一次性冲突变成制度。4.妥协：给出了什么替代方案（换时段、降卡数、换卡型）。5.结果：冲突是否复发。追问链：●对方说"我的项目有上线日期，必须优先"，你怎么判断真假？●如果最终你让步了，你怎么保证别的项目不吃亏？●这套规则后来被挑战过吗？●你觉得平台团队应该服务业务还是约束业务？评分要点：5分=用数据+建机制+给替代方案；3分=靠上级协调解决。红旗：把冲突描述成"对方不讲理"，全程无自省。四、风险与避坑题（8题）Q29.业务方要求跳过灰度，直接全量上线，说"时间来不及"，你怎么办？参考答案要点：1.先量化风险：新版本未验证的部分是什么，最坏情况影响多少用户。2.给压缩方案：把四档压成两档（10%→100%），每档观察15分钟，总耗时约1小时。3.要前置条件：必须完成压测与一致性比对，必须有10分钟回滚能力。4.要书面确认：若对方坚持零灰度，需其负责人书面接受风险。5.底线：无回滚能力时坚决不同意，这不是流程问题而是能力问题。追问：对方是你上级的上级，你怎么办？Q30.领导说"监控告警太多，砍掉一半"，你怎么做？参考答案要点：1.不直接砍条数，先做分类：P1～P4各多少，哪些是重复、哪些无主。2.用数据说话：过去3个月每条告警的实际处置率，从没被处置过的是噪音。3.做聚合与抑制：同根因合并，一个故障只出一条主告警。4.调整阈值：用历史P95重设，而不是简单调高。5.保留兜底：砍掉的是通知，不是采集，数据仍留看板。追问：砍完之后漏报了一次P1，怎么复盘？Q31.你发现有人用公司GPU训练个人项目，怎么处理？参考答案要点：1.先确认事实：任务归属、资源占用、持续时间，避免误判（可能是未登记的内部项目）。2.按制度走：查员工手册与资源使用条款，确认是否明文禁止。3.处置：停任务、保留证据、上报直接上级与合规，不自行处理。4.机制：补技术手段（命名空间审计、镜像白名单、异常任务识别）。5.不扩散：不在群里公开讨论，避免人事风险。追问：这个人是你的同事兼朋友，你会不会先私下提醒？Q32.大促前夜，有人要求改调度器配置以腾出算力，你做不做？参考答案要点：1.默认不做。大促前是变更冻结期，任何配置变更都属高风险。2.先评估替代方案：能否从探索池回收、能否缩容非核心服务、能否临时租云。3.若必须改，走紧急变更流程：双人复核、灰度一台、可30分钟内回滚、全程有人盯。4.明确记录：谁提的、谁批的、风险谁承担。5.事后补：冻结期结束后重新评审该配置是否保留。追问：如果不改，业务方明确说会损失订单，你还坚持吗？Q33.供应商说他们的国产卡"完全兼容、零改动迁移"，你信吗？参考答案要点：1.不信。兼容性必须自己验证，不能采信宣传口径。2.验证清单：算子覆盖、框架版本、多卡通信、精度比对、性能基线。3.用真实业务模型跑，不用demo模型。4.要求提供已知问题清单与适配案例，且可联系到实际用户。5.小批量试点，达到约定性能比例再扩大采购。追问：试点跑出来性能只有原卡50%，但供应商说"调优后能到80%"，你怎么决策？Q34.算法团队说"训练慢是平台的问题"，你怎么回应？参考答案要点：1.不辩论，先取证：GPU利用率、数据读取耗时、通信耗时、单步耗时拆解。2.用数据分层：如果GPU利用率高但单步慢，是算力或模型问题；如果利用率低且IO等待高，是存储或数据管道问题。3.给对照：同机型、同规模的其他任务数据作为参照。4.明确边界：属于平台的（存储带宽、网络、调度）认领并给时间表；属于任务侧的（数据加载实现、并行策略）给出建议但不背锅。5.建机制：把"训练性能归因"做成标准流程，避免每次靠吵。追问：取证后发现确实是存储带宽不足，但存储不归你管，怎么办？Q35.值班同事误删了一个PVC，里面有正在训练的checkpoint，怎么处置？参考答案要点：1.立即止损：暂停相关任务，防止继续写入造成二次损坏。2.评估影响：删的是哪个PVC、有无快照或备份、影响哪些任务。3.恢复：优先从快照恢复；无快照则确认数据是否可从上游重建。4.上报：按事故等级上报，不隐瞒。5.机制：PVC删除加保护（回收策略、删除前二次确认、误删拦截），高危操作双人复核。6.复盘：写清时间线与根因，改进项落到权限与流程。追问：如果没有快照，任务要重跑两周，你怎么跟业务方沟通？Q36.扫描发现一个老镜像有高危漏洞，但还有5个任务依赖它，怎么办？参考答案要点：1.先评估可利用性：漏洞是否需要网络暴露、是否需要特定调用路径，不能只看评分。2.隔离：确认这些任务的网络策略，限制出网与横向访问。3.修复：基于新基础镜像重建，先在探索池验证，再逐步替换。4.过渡：无法立即替换的，登记豁免，写明理由、责任人、到期日。5.冻结：禁止新任务再使用该镜像，加准入校验。追问：重建后某个任务的依赖装不上，业务方要求延期，你批不批？五、开放思辨题（6题）Q37.公司要建AI平台，你建议自建还是租云？参考答案要点：1.判断依据不是"哪个便宜"，而是负载形态：稳定长跑vs波动短跑。2.自建适合：长期稳定负载、数据不能出域、有IDC与运维能力、规模足够摊薄成本。3.租云适合：负载波动大、需要快速验证、缺少硬件运维能力、有合规云可用。4.混合是常态：稳态自建+峰值租云，但要做好镜像与调度的统一，否则两边割裂。5.必须算总成本：不只是卡价，还有机房、电力、网络、人力、闲置率。6.高分答案会给出"什么条件下切换"的量化阈值。追问：如果自建利用率只有40%，租云按量付费，账怎么算？Q38.GPU利用率是不是越高越好？参考答案要点：1.不是。利用率是效率指标，不是目标本身。2.过高意味着没有缓冲，突发任务排不上，SLA风险上升。3.追求高利用率可能催生"跑无意义任务占卡"的造假行为。4.合理区间取决于业务结构：推理为主可高些，训练为主受排队与故障影响，通常65%～75%是较好水平。5.应同时看"有效卡时"与"SLA达成"，单看利用率会误导。6.高分答案能说出"为了稳定性主动放弃部分利用率"的取舍。追问：老板要求利用率做到90%，你怎么回应？Q39.平台要不要做自助化，让算法同学自己提交任务、自己发布服务？参考答案要点：1.方向要做，但要分级：低风险操作自助，高风险操作审批。2.自助范围：提交训练任务、查看日志、申请配额、部署到探索环境。3.审批范围：生产发布、跨池调度、大额配额、删除类操作。4.自助的前提是"护栏"：配额上限、镜像白名单、资源规格模板、自动回滚。5.收益：平台团队从工单中解放，业务迭代加快。6.风险：护栏不严会导致资源滥用与误操作，必须先建护栏再放权。追问：放权后第一个月资源用量涨了3倍，你怎么处理？Q40.平台团队的价值怎么衡量？没有直接业务收入，怎么证明自己有用？参考答案要点：1.三类指标：稳定性（可用性、故