AI平台运维工程师岗位说明书（含避坑说明）

AI平台运维工程师岗位说明书第1页共1页2026版AI平台运维工程师岗位说明书解决「AI平台运维工程师招不准、定级没依据、考核扯皮」：13张表讲透岗位职责·任职要求·考核指标·薪酬带宽·晋升路径，附JD模板与可打印面试评估表，HR与用人经理可直接套用一、岗位概述1.1岗位定位AI平台运维工程师属于AI原生技术岗，但技术重心不在模型本身，而在"承载模型的那套基础设施"。它维护的是一条完整链路：数据管道把样本送进存储，训练平台把GPU分给任务，任务产出权重，推理服务把权重变成有SLA的API。与传统运维相比，有三个绕不过去的硬差异：1.GPU是稀缺资源，必须"调度"而不是"分配"。一台8卡A800节点月租在数万元量级，闲置一天就是上千元。集群里"谁先用、用多久、能不能被抢"，直接决定哪个业务能按时上线。2.训练任务是长事务，不能滚动重启。一个大模型训练任务跑3天到3周是常态，中途重启等于把已消耗的卡时全部作废。运维动作必须考虑"这个操作会不会杀掉一个已经跑了6天的任务"。3.推理服务有SLA，且故障横跨五层。硬件（GPU掉卡、ECC错误）→驱动与CUDA→框架（PyTorch、NCCL、vLLM）→模型（权重、tokenizer、显存占用）→业务（超时、重试放大、限流）。任何一层出问题，表象都可能是"接口变慢"。一句话概括：把GPU变成可计量、可排队、可恢复、可追责的生产力。1.2岗位价值●算力的放大器：没有调度与配额，集群实际GPU利用率普遍停在25%～35%，卡被"占着不用"；建立队列、配额、回收机制后可稳定到65%以上，等于在预算不变的前提下多出一倍算力。●训练连续性的保险：没有断点续训与自动重试，一个已消耗上万卡时的任务在第6天因单卡故障中断就要从头再来，损失按GPU时直接折算成钱。●推理SLA的守门人：没有灰度与限流，一次模型上线就可能把P99从800ms推到4s，打穿业务侧超时阈值，引发上游重试风暴。●故障定位的加速器：五层链路没有分层排查手册，平均故障恢复时间会从30分钟拉长到4小时以上，且同类故障反复发生。●成本的可见化：没有按队列、按业务的成本分摊，账单只有一个总数，超支时找不到责任人，采购谈判也没有依据。●环境一致性的维护者：镜像不锁版本，同一个commit今天能训、明天报错，实验不可复现，算法团队的结论全部作废。1.3岗位边界（与相邻岗位的分工）岗位核心产出与本岗的分工边界推理优化工程师量化方案、算子优化、连续批处理、显存优化本岗保"不挂、不超时、容量够"，优化工程师提"更快、更省"。同一张卡，本岗对可用性负责，他对性能上限负责AI数据工程师数据内容、清洗规则、质量校验、向量库本岗管管道"跑得通、跑得完、跑得准时"，数据工程师管"数据对不对、好不好"大模型算法工程师模型权重、训练方案、效果指标本岗提供配额、镜像、队列、排障支持，不调超参、不改训练脚本逻辑应用开发工程师业务服务、编排逻辑、前端集成本岗管模型服务这一层，业务侧的超时与重试预算由应用方设定基础设施/IDC运维机房、供电、制冷、物理上架、硬件返修本岗管机房之上的GPU资源池与平台软件；硬件故障由本岗发现、摘除、报修、验收，返修执行归IDC或厂商SRE/应用运维通用中间件、业务服务稳定性本岗专管AI负载特性：GPU、RDMA、大显存、长任务、模型版本信息安全网络策略、权限模型、审计规则本岗执行策略并反馈可用性代价，不制定策略采购与财务预算审批、合同签订本岗提供用量数据、成本测算与卡型建议>中小企业最常见的混岗是"算法工程师兼平台运维"。后果是两边都做不深：模型效果上不去，集群也没人管。招聘时必须在JD里写明本岗是否包含硬件采购与机房对接。1.4岗位别名与招聘口径平台常见名称实际工作内容是否等同本岗AI平台运维工程师/机器学习平台运维资源池、训练任务、推理发布、监控是算力平台工程师/GPU集群运维偏底层：卡、驱动、调度器、网络是，需确认是否含推理侧MLOps工程师偏流水线、模型注册、CI/CD部分重合，可能完全不含硬件与GPUAI基础设施工程师含选型、架构、容量规划是，属更高阶HPC运维工程师Slurm、IB网络、并行文件系统相近，需验证K8s与推理服务经验云原生运维/K8s运维通用容器平台否，通常无GPU调度与训练框架经验模型部署工程师/推理服务运维只覆盖推理侧部分重合，不含训练任务保障算法工程师（兼运维）小团队混岗否，需单独确认运维投入占比二、汇报关系2.1标准汇报线●直接上级：AI平台负责人/基础设施负责人/AI研发总监/技术总监（CTO）●直接下级：无（L1～L2）；L3可带2～4人，L4可带5～10人并分管训练平台组与推理平台组●虚线汇报：向算法团队负责人虚线汇报"资源需求满足率"，向业务方汇报"推理服务SLA达成情况"2.2三种企业形态下的组织位置企业类型组织挂靠汇报对象工作特征大型互联网/云厂商基础架构部、算力平台部平台总监集群千卡级以上，分工极细，可能专职做调度器二次开发或专职做监控体系中大型行业企业（金融、制造、医疗）科技部/数字化部下设AI平台组科技部总经理几十到几百卡，一人多角色，需兼顾内网隔离、审计合规与业务排期中小型企业/创业公司技术部，与后端或SRE合并CTO或技术合伙人8～32卡，自建与租云混合，既要运维又要做选型、比价、甚至机房上架2.3横向协作接口协作方协作内容交付物常见摩擦点算法团队配额申请、任务排期、训练故障支持配额单、任务工单、排障记录"我这个任务很急"但给不出优先级依据，资源分配变成嗓门比拼推理优化团队压测环境、性能基线、版本发布压测报告、发布单、容量水位表优化方改完参数直接上线，未同步显存与并发变化，导致容量预估失效AI数据工程管道调度、存储配额、数据同步调度DAG、存储水位报表数据管道夜间跑满IO，把训练任务的读取带宽挤到1/3应用开发服务接入、超时重试、限流阈值接入文档、SLA协议应用侧无重试预算，故障时流量放大3倍，把局部故障变成全站故障采购与财务卡型选型、账单核对、预算编制成本月报、采购建议表业务方私自开按需实例，月底账单超预算才发现信息安全网络策略、账号权限、镜像扫描权限矩阵、镜像合规报告训练需要拉取公网依赖，策略不允许，只能手工开后门机房/硬件供应商上架、返修、固件升级报修工单、验收单返修周期2～4周，期间算力缺口无人补位三、核心工作职责以下按"资源调度—训练保障—推理运维—监控告警—故障处理—成本优化"六个模块展开。每条均含动作、产出物、验收标准，可直接转写为绩效目标。3.1算力调度与资源治理1.资源池划分与配额下发：按业务线把集群切成三类池——生产推理池（独占、禁止超卖）、训练池（可超卖、按配额）、探索池（低优先级、允许被抢占）。配额以"卡时/月"为单位下发到项目，超额需二级审批。产出：资源池拓扑图与配额台账。验收：任一项目单日占用不超过配额的110%，超额告警在5分钟内到达项目负责人。2.队列与优先级策略：设置P0（线上故障修复、合规整改）、P1（有对外上线日期的项目）、P2（探索性实验）三级队列，P0可抢占P2，抢占前必须落盘checkpoint。产出：队列配置与抢占规则文档。验收：P0任务排队时间≤30分钟，P2被抢占后可在原配额内24小时内重新排到。3.利用率度量与闲置回收：以周为单位统计"分配率"与"真实利用率"双指标（GPUSM占用率、显存占用率），识别连续2小时GPU利用率低于5%且无交互的任务，通知后回收。产出：利用率周报与回收清单。验收：集群月度GPU平均利用率≥65%，闲置卡从发现到回收平均≤2小时。4.多租户隔离：用namespace、ResourceQuota、NetworkPolicy做逻辑隔离，配合节点亲和与污点避免关键任务与实验任务同节点；单卡多任务场景用MIG或时间片切分。产出：隔离策略与隔离压测记录。验收：单租户压测打满时，同节点其他租户P99上浮不超过10%。3.2训练任务保障5.任务提交标准化：提供三类任务模板（单机8卡、多机多卡、参数化扫参），强制填写镜像tag、数据路径、预计时长、优先级、负责人、是否可抢占。产出：提交模板与字段校验脚本。验收：90%以上任务通过模板提交，字段缺失在提交阶段即被拒绝，不进入队列。6.镜像版本管理：基础镜像按"驱动+CUDA+框架"三维锁定（例如驱动535、CUDA12.1、PyTorch2.1.0），业务镜像必须从基础镜像派生，禁止使用latest标签，镜像变更需登记。产出：镜像仓库目录与版本兼容矩阵。验收：任一30天内的历史任务可用原镜像完整重建，环境漂移导致的失败为0。7.分布式训练网络配置：多机任务开通RDMA/IB，启用拓扑感知调度（同leaf交换机下的节点优先成组），上线前跑NCCL带宽基线。产出：网络配置模板与带宽基线表。验收：8机64卡all-reduce带宽达到同机型基线的90%以上，跨leaf调度比例低于20%。8.断点续训与失败重试：强制每N步（建议500～1000步）保存checkpoint到共享存储，配置自动重试并区分错误类型——节点故障、网络抖动可重试；数据格式错误、代码异常不可重试，直接失败并通知。产出：续训配置模板与错误分类表。验收：单节点故障导致的训练中断，恢复后从最近checkpoint继续，损失步数不超过N。9.日志与指标统一采集：采集任务stdout/stderr、GPU指标、NCCL日志、宿主机dmesg，按任务ID聚合检索，保留期不少于30天（故障复盘场景90天）。产出：日志检索入口与任务详情页。验收：任一失败任务可在10分钟内判定失败层级（硬件/驱动/框架/数据/代码）。3.3推理服务运维10.模型部署标准化：把"权重+tokenizer+推理引擎参数+资源规格"打成一个发布单元，用声明式配置描述副本数、GPU型号、显存上限、健康检查路径、环境变量。产出：部署模板与发布单。验收：新模型从提报到可被调用≤1个工作日，配置差异导致的部署失败为0。11.灰度发布与回滚：按流量比例分档灰度（5%→20%→50%→100%），每档观察不少于30分钟，对比P99延迟、错误率、输出一致性（同输入抽样比对）；保留上一版本镜像与权重，回滚操作≤10分钟。产出：灰度记录表与回滚演练报告。验收：灰度期间错误率上升超过0.5个百分点时自动熔断并回滚。12.弹性扩缩容：基于队列长度、GPU利用率、P99延迟三指标配置HPA，同时设置最小副本（保底容量）与最大副本（防雪崩），把模型冷启动时间（大模型加载常需2～8分钟）计入扩容决策。产出：扩缩容策略与容量水位表。验收：流量涨至日常2倍时P99不超过SLA的1.2倍，扩容在3分钟内完成。13.限流降级与多模型共卡：为每个服务设置QPS上限与排队上限，超限返回明确错误码而非无限挂起；小模型共卡部署时按显存配额硬隔离，为单模型设置显存上限，防止一个模型把整卡吃满。产出：限流配置与共卡部署清单。验收：过载时服务不雪崩，错误码可被上游识别并触发降级，共卡场景下单模型故障不影响同卡其他模型。14.健康检查设计：区分存活探针（进程是否在）与就绪探针（能否真正推理），就绪探针必须真实发起一次短推理请求，避免"进程活着但模型加载失败"仍接流量。产出：探针配置规范。验收：模型加载失败或显存不足的实例在1分钟内被摘除，不接收任何流量。3.4监控告警与可观测性15.GPU硬件指标监控：采集温度、功耗、显存占用、ECC可纠正/不可纠正错误、XID错误码、PCIe与NVLink降速、风扇转速。产出：GPU健康看板与单卡档案。验收：不可纠正ECC与严重XID错误100%触发告警，并自动将该卡从调度池摘除。16.训练任务卡死检测：以"GPU利用率+日志输出+loss变化"三条件联合判断卡死（例如30分钟内无日志输出且GPU利用率低于3%），命中后自动dump进程堆栈与GPU状态。产出：卡死检测规则与自动处置脚本。验收：卡死任务平均发现时间≤30分钟，自动恢复率≥70%。17.推理服务SLO监控：监控P50/P95/P99延迟、首token时间（TTFT）、每秒token数、错误率、超时率、排队深度、GPU显存水位。产出：SLO看板与错误预算消耗表。验收：P99越过阈值后5分钟内告警到值班人，月度SLO达成率可自动出报表。18.成本与容量监控：按namespace统计卡时消耗，按服务统计单千次调用成本，监控存储水位与网络出流量。产出：成本日报与容量水位预警。验收：单日成本波动超过15%时可在1小时内归因到具体队列或服务。3.5故障处理与应急19.五层分层排查手册：按硬件→驱动/CUDA→框架/NCCL→模型/权重→业务链路建立排查树，每层给出3～5条判定命令与典型现象，配套"看到什么现象走哪条分支"的决策图。产出：排障手册与决策树。验收：新人依手册可在1小时内定位80%的常见故障所属层级。20.GPU掉卡处置：检测到XID严重错误或设备不在位，自动cordon节点、驱逐可迁移任务、生成报修工单并记录卡序列号、故障码、发生时间。产出：掉卡工单与影响面清单。验收：从发现到节点隔离≤10分钟，单卡故障对同节点其他任务的影响不超过1次重试。21.显存泄漏与OOM处置：区分两类问题——请求级OOM（单条输入过长）通过限制输入长度与批大小解决；累积泄漏（长跑显存单调上升）通过定时滚动重启加现场保留解决。产出：OOM归因记录与处置方案。验收：同类OOM复发率下降≥50%。22.NCCL通信超时处置：按"网卡状态→IB链路→是否跨leaf→NCCL版本与算法→超时参数"顺序排查，严禁把调大超时参数当作解决方案。产出：通信故障排查记录。验收：通信类故障平均恢复时间≤2小时，且能给出根因结论而非"重启后恢复"。23.驱动与CUDA版本冲突处置：维护"驱动-CUDA-框架-国产卡固件"四维兼容矩阵，任何升级先在灰度节点验证24小时再全量。产出：兼容矩阵与升级SOP。验收：驱动升级引发的批量故障为0，升级回滚可在30分钟内完成。3.6成本优化24.闲时缩容与混部：依据历史流量曲线为推理服务设置定时缩容（例如夜间降至30%副本、周末降级非核心服务），训练与推理混部时用优先级与抢占保护在线业务。产出：缩容策略表与混部比例方案。验收：非高峰时段GPU闲置率下降≥20个百分点，且无SLA违约。25.竞价实例与包年权衡：无状态、可中断的训练任务优先用竞价实例，长周期稳定负载用包年包月；建立"中断概率×重跑成本vs折扣收益"的测算表，按任务时长分档选型。产出：采购建议表。验收：同等算力下月度成本下降≥15%，任务平均中断次数不超过每任务1次。26.成本归因与内部分摊：按项目出具账单，把卡时、存储、网络出流量折算成内部结算价，季度与业务方对账。产出：月度成本分摊表。验收：每个业务方能自助查到自己的用量与费用，超支项目有书面整改动作。四、任职要求4.1硬性要求（不满足则不进入技术面）维度具体要求说明学历大专及以上，本科优先运维岗以实操能力为主，学历门槛可适度放宽，但需用项目证明专业计算机、网络工程、电子信息、自动化非科班但有3年以上Linux运维经验且懂GPU者可放宽工作年限初级1～2年，中级3～5年，高级5年以上年限按"GPU集群或AI平台"计，通用运维年限需折算Linux功底熟练使用dmesg、journalctl、lsof、ss、perf、strace、tcpdump定位问题面试需现场给一段报错日志让其判断方向容器与编排熟练K8s：Deployment、StatefulSet、ResourceQuota、taint/toleration、亲和性、PVC、CRD能说清PodPending的完整排查顺序，不能只答"看describe"GPU知识懂GPU架构、显存管理、ECC、XID错误码、NVLink与PCIe拓扑、nvidia-smi与DCGM能解释"为什么8卡机跨NUMA会导致带宽下降"调度器至少精通一种：Volcano、Slurm、Kueue、YARN需说明队列、抢占、gangscheduling的实际配置经验网络懂RDMA/IB或RoCE配置与测试（ibstat、perftest），懂TCP参数调优有分布式训练网络排障经验者优先训练框架能读懂torchrun、DeepSpeed、Megatron的启动参数与并行策略不需要会改模型，但要能判断"是框架配置错还是代码错"推理引擎会部署vLLM、SGLang、TensorRT-LLM、Triton中的至少一种需说明显存占用估算方法与并发压测方法监控体系熟练Prometheus、Grafana、Alertmanager，能写PromQL要求能设计一套GPU告警规则，而非只会用现成面板脚本能力Python或Shell能写自动化脚本；会Go写Operator为加分面试需展示一个自己写的自动化工具4.2软性要求●变更纪律：任何改动先写变更单，含影响面、回滚步骤、观察窗口；不因"顺手改一下"而在业务高峰期动配置。●值班韧性：凌晨两点被叫起来，能打开手册按步骤执行，而不是凭记忆在生产环境试命令。●分层思维：遇到"训练很慢"，先问"是哪一层慢"，用数据排除，不直接重启任务。●成本敏感：能随口说出自己管的集群一天烧多少钱、哪个业务最贵。●沟通克制：向算法同学说"没卡"时，同时给出三个替代方案（降卡数、换时段、换卡型），不只传递坏消息。●复盘习惯：每次P1故障24小时内出复盘，写清时间线、根因、改进项与责任人，不写"加强监控"这类空话。●边界意识：明确"哪些操作必须双人确认"，例如删除PVC、批量重启节点、修改调度器配置。4.3分级能力要求层级经验能力特征典型产出参考薪酬带宽（一线城市，年包）L1初级0～2年能按手册执行部署、巡检、告警响应；能独立处理单机单卡故障日常巡检记录、单服务部署18～24万L2中级2～4年能独立管理百卡级资源池，设计配额与队列，处理NCCL与OOM类故障资源池方案、排障手册24～32万L3高级4～7年能设计千卡级集群架构，主导调度器选型与二次开发，建监控体系集群架构方案、成本优化成果32～40万L4专家/平台负责人7年以上能规划多集群多地域算力布局，决定自建与租云比例，带团队算力战略、平台产品化40～45万以上>薪酬区间为市场参考。懂K8s+GPU调度+国产卡适配三项叠加者，同层级普遍高出20%～40%，这是本岗最明显的溢价点。实际定薪需结合集群规模、是否含7×24值班、是否有股权。4.4加分项与伪加分项真实加分项：●有千卡级以上集群的运维经历，能说出具体的故障率、MTTR、利用率数字●有国产加速卡（昇腾、寒武纪、海光等）的实际适配经验，能说清驱动、算子库、框架版本的匹配过程●写过调度器插件、K8sOperator、GPU设备插件或自研监控exporter●有可量化的成本优化成果（如月度算力成本下降20%且SLA不降）●有从0到1搭建监控告警体系并显著降低误报率的经历●有开源项目贡献（Volcano、DCGMexporter、vLLM部署工具链等）伪加分项（不可作为主要录用依据）：●只考过K8s认证但没管过GPU节点，答不出显存碎片与设备插件的关系●简历写"熟悉分布式训练"，实际只跑过单机单卡demo●把"用过云厂商控制台开机器"当作集群运维经验●项目描述只有"负责XX平台运维"，无集群规模、无故障数据、无个人动作●只会用现成监控面板，让他从零设计一套GPU告警规则就卡住五、工作环境5.1物理与工具环境●办公形态：以办公室与终端为主，需定期进机房处理上架、换卡、连线；部分企业要求驻场数据中心。●硬件环境：GPU服务器（常见8卡机型）、IB/RoCE交换机、并行文件系统或高性能NAS、带外管理网（IPMI/BMC）。●软件工具链：Linux（Ubuntu/CentOS系）、K8s及调度器、容器镜像仓库、Prometheus/Grafana/Loki、DCGM、Ansible/Terraform、GitLabCI、工单系统。●值班设备：值班手机或告警机器人必须保持可达，告警需分级（P1电话、P2短信、P3群消息），避免所有告警都打电话导致疲劳。●权限：拥有生产集群的高权限账号，属于高风险岗位，需配套双人复核与操作审计。5.2协作与节奏●值班制度：普遍实行7×24轮班或on-call，一轮7天，夜间告警响应时限通常为15分钟（P1）。招聘时必须说明值班频率与调休规则，这是本岗候选人最关心的问题之一。●发布窗口：推理服务发布通常安排在业务低峰（夜间或凌晨），灰度观察期需要人盯着，实际是"夜间工作、白天补休"。●训练高峰：季度末、项目上线前是算力申请高峰，资源冲突集中爆发，需要有排队与谈判机制。●会议负荷：容量评审会、故障复盘会、发布评审会为主，中等。●出差：自建机房或多地集群场景下需出差，年均约5%～15%。5.3保密与合规环境●签署保密协议，集群拓扑、资源规模、模型清单、业务用量均属敏感信息，不得对外披露。●训练数据不得出域：平台侧需保证存储与网络策略不产生数据外流路径，跨域同步须走审批与加密通道。●操作审计：所有高权限操作（删除、扩缩容、改调度配置）需留痕，日志留存不少于6个月，满足内控与监管检查。●资源使用红线：严禁利用公司GPU进行挖矿、私自训练个人模型、对外提供算力，此类行为通常直接构成严重违纪。●涉及个人信息或重要数据的场景，需配合完成安全评估，平台侧提供资源隔离与访问控制的技术材料。六、考核指标6.1指标设计原则1.稳定性优先于一切：本岗的第一价值是"不出事"，任何效率指标都不能以牺牲可用性为代价。2.可用性与变更成功率成对考核：只考核可用性会导致"不敢发版"，只考核变更速度会导致事故频发。3.利用率必须与有效性挂钩：单纯考核GPU利用率会催生"跑无意义任务占卡"，必须同时看有效产出。4.指标数量控制在6～8项：超过8项必然失焦，且数据采集成本高于收益。5.口径提前约定：可用性按分钟还是按请求、故障按P1还是P1+P2，必须在季度初书面确认。6.2季度考核表（中级岗位示例）考核维度指标权重计算口径数据来源稳定性推理服务可用性25%1减去（不可用分钟数/统计总分钟数），按服务加权平均，月度汇总监控平台SLO报表稳定性P1/P2故障数与MTTR15%P1故障0起为满分，每起扣20%；MTTR取季度中位数，目标≤30分钟工单系统资源效率GPU平均利用率15%有效卡时/可用卡时，有效指有推理请求或有checkpoint产出DCGM与调度器数据交付资源需求满足率10%在承诺时限内按量满足的申请数/总申请数配额台账交付平台变更成功率10%未引发回滚或故障的变更数/总变更数，目标≥98%变更管理系统成本单位算力成本10%月度算力总支出/有效卡时，环比下降为达标账单与成本分摊表自动化自动化处置覆盖率5%自动扩缩、自动摘卡、自动重试覆盖的任务或服务占比平台配置统计协作与沉淀支持满意度与文档产出10%协作方评分（1～5分）占5%，复盘报告与手册更新占5%360评价、文档库6.3分级考核差异●L1：以任务完成度、响应及时性、操作规范性为主，可用性指标权重下调至15%，增加"独立处理工单比例"与"操作零违规"。●L2：按上表执行，强调独立负责一个资源池或一类服务。●L3：增加"架构改进项目"权重（如调度器升级、监控体系重构），个人日常工单权重下调，考核"是否让平台整体能力上台阶"。●L4：以算力战略达成、成本结构优化、团队梯队建设、跨部门协同为主，不考核具体工单量。6.4常见考核失真与纠正失真现象成因纠正办法可用性好看但用户仍抱怨只统计服务进程存活，不统计实际推理成功率可用性口径改为"成功返回且延迟达标的请求占比"利用率虚高为凑指标跑无意义任务占卡引入"有效卡时"定义，需有checkpoint产出或真实请求告警数量被当作勤奋指标导向错误，导致滥发告警改考核MTTD（平均发现时间）与漏报率，而非告警条数MTTR短期好看但故障复发只奖励"快"，不追究根因增加"同类故障90天内复发率"作为否决项成本下降但交付变慢采购低质低价算力，训练时长翻倍改考核"单位任务完成成本"而非"单位卡时价格"变更成功率靠少发版团队趋于保守，技术债累积设定季度最低变更次数，与成功率联合考核七、职业发展路径7.1纵向：专业序列●L1平台运维工程师：能按SOP完成部署、巡检、告警响应，独立处理单机故障。●L2高级平台运维工程师：独立管理百卡级资源池，设计配额与队列，主导故障复盘。●L3平台技术专家/AI基础设施工程师：设计千卡级集群架构，主导调度器选型与二次开发，建设监控与成本体系。●L4首席基础设施专家/平台架构师：规划多集群多地域算力布局，决策自建与租云比例，定义平台技术路线。晋升核心门槛：L1→L2看"能否独立负责一个资源池"；L2→L3看"能否设计出让别人少踩坑的机制"；L3→L4看"能否用算力策略影响公司成本结构与业务节奏"。7.2纵向：管理序列L3及以上可转M序列：平台组长（M1）→平台经理（M2）→基础设施总监（M3）。转管理需补三项能力：容量预算编制、跨部门资源谈判、值班团队排班与士气管理。不建议L2以下转管理，本岗的管理威信高度依赖技术判断力——值班同学不会服一个排不明白故障的人。7.3横向：转岗路径目标岗位迁移难度需补能力适配人群推理优化工程师中高CUDA编程、算子优化、量化原理、性能剖析对性能极限有执念、愿意啃底层者AI架构师中系统分层设计、多方案成本对比、技术选型方法有跨集群规划经验者AI数据工程师中数据管道编排、数据质量体系、向量库偏应用与数据侧兴趣者SRE/云原生工程师低通用中间件、服务治理、混沌工程想拓宽技术面者信息安全工程师中安全策略、等保要求、渗透基础对合规与攻防有兴趣者AI解决方案架构师中高客户沟通、方案包装、售前支持表达能力强、愿出差者技术管理中目标拆解、预算管理、人才梯队有带队意愿者7.4成长路线建议0～12个月（立足）：吃透现有集群的拓扑与配额规则；把排障手册从头到尾走一遍，独立处理20个以上真实工单；掌握一套监控查询语言；建立个人故障笔记，记录每次"现象—判断—验证—结论"。12～24个月（独立）：独立负责一个资源池或一条业务线的推理服务；主导一次调度策略调整并拿出利用率数据；完成一次成本优化项目并算清节省金额；开始带新人值班。24～36个月（影响）：主导一次集群架构升级（调度器替换、网络改造、国产卡引入）；建立团队级的监控与容量体系；在国产卡适配或成本优化上形成个人技术标签；对外输出（技术分享、开源贡献、行业会议）。八、招聘与用工落地要点8.1JD发布要点●写清集群规模与卡型：多少卡、什么型号、自建还是租云、是否含国产卡。这一项对候选人的吸引力常高于薪酬，也是判断其经验是否匹配的最快方式。●写清值班规则：几班倒、夜间响应时限、调休与补贴。含糊其辞的JD会在面试后期大量流失候选人。●写清主责边界：是否包含硬件采购、机房对接、推理性能调优。三者差别很大，不写清必然扯皮。●写清技术栈版本：K8s版本、调度器、推理引擎、监控体系。候选人能据此判断自己是否需要重新学习。●避免的表述："精通K8s与GPU"、"有很强的抗压能力"、"能接受弹性工作"。前两个无法验证，第三个常被理解为"随时加班"，会筛掉优质候选人。8.2面试流程设计（建议4轮）轮次时长考察重点面试官一面45分钟Li