GPU 算力调度工程师
💵 2026 年薪资区间与平均薪资
下表口径：一线城市 · 社招 · 税前月薪（现金部分）。数字综合 2026 年公开招聘信息与薪酬报告整理，不是精确统计 —— 校招与社招、均值与中位、是否含股票期权的口径差异很大，实际请以招聘平台实时岗位为准。
| 层级 | 月薪区间 | 说明 |
|---|---|---|
| 🥉 初级（0–3 年 / 校招） | 20–32K | 看基础与动手能力，校招通常要求硕士起步 |
| 🥈 中级（3–5 年） | 32–58K | 能独立负责模块，市场上的主力区间 |
| 🥇 高级 / 专家（5 年以上） | 58–95K | 能定方案、带团队；含股票期权的总包常显著高于现金部分 |
平均月薪参考：约 40K（一线城市社招口径）。溢价在集群规模：管过百卡以上、处理过碎片与抢占导致的排队积压，是分水岭。
可以对照的公开锚点：2026 届校招里 AI 相关岗位月薪中位值约 2.53 万元；偏中高端的样本中 AI 岗位平均月薪约 6.07 万元；算法研究员 / 大模型算法岗位普遍在 7 万元 左右，AI 科学家 / 负责人可达 13 万元 以上。资深 AI 人才 2026 年的调薪幅度最高可达 20%–35%，高于市场平均。
地域差异明显：长三角与大湾区贡献了全国近七成的 AI 岗位需求，北京、上海、深圳、杭州、苏州的薪酬普遍高于其他城市。
🏦 岗位画像：这个岗位到底在招谁
GPU 算力调度工程师的工作，是在稀缺的卡和排队的任务之间做分配。目标不是「让任务跑起来」，而是在利用率、等待时间、公平性这三个互相拉扯的目标之间找到当下最合适的平衡点，并且让排队的人服气。
日常工作：维护调度系统（Kubernetes 加批量调度组件，或者 Slurm）、管理配额与优先级、设计抢占与断点续训、处理掉卡与节点故障、做监控与容量规划，以及花不少时间向业务方解释「为什么你的任务排在后面」。
三类用人单位侧重不同：
- 云厂商与大厂平台团队：多租户、大规模、强稳定性要求。面试重隔离、配额、故障自愈和线上事故处理经验。
- AI 公司自建集群：重利用率与训练效率。面试会追问你怎么把利用率提上去、怎么减少碎片、怎么让训练任务跑得更快。
- 智算中心与算力服务商：卡要卖出去，重计量、隔离与计费。面试关注多租户切分、SLA 与运营指标，而不只是技术方案。
一句话判断：如果你喜欢把资源用到极致，又愿意处理人和流程的问题（调度本质上是资源分配的政治），这个岗位合适。只想写代码、不想和业务方拉扯的人，要提前想清楚。
📅 岗位职责
- 调度系统维护与调优：调度器配置、批量调度组件、队列划分、优先级策略
- 配额与多租户：按团队或项目分配资源、超额策略、隔离方案（整卡 / 切分 / 共享）
- 拓扑感知：NVLink、NUMA、网卡亲和，保证通信密集的任务不被拆到不利位置
- 抢占与回收：低优先级任务可被抢占，配合断点续训把损失降到最低
- 故障自愈：掉卡检测、节点摘除、任务自动重调度、故障通知
- 监控与容量：利用率、排队时长、碎片率、故障率等指标与看板，并做容量规划
- 计量与计费：按 GPU 小时统计到团队与项目，支撑内部结算或对外售卖
- 与业务协作：帮训练任务选规格、判断「任务慢」是模型问题、数据问题还是集群问题
🗝️ 岗位技能：技术基础
必备
- Kubernetes 基础：Pod 生命周期、调度流程、device plugin、GPU Operator、亲和性与污点
- 调度器原理：过滤与打分机制、扩展点、批量调度组件（Volcano、Kueue 一类）与 gang scheduling
- Slurm：分区、QOS、抢占、作业数组，HPC 与训练集群里仍然很常见
- 拓扑知识：NVLink、PCIe、NUMA、RDMA 与 InfiniBand 的基本认识，以及它们对调度决策的含义
- 资源切分：MIG、时间片共享、MPS 的隔离强度与适用场景，知道哪种切法会互相干扰
- 监控指标：GPU 利用率、显存、SM 占用、通信耗时、节点健康（DCGM 一类采集）
- 运维能力：Linux、容器运行时、驱动与固件版本管理、YAML 与 Helm、日志与故障定位
- 脚本能力：Python 或 Go 写自动化工具，能通过 API 层操作调度系统做批量运维
加分
- 训练框架侧的调度接口：分布式启动、弹性训练、断点续训的工程实现
- 存储与数据本地性：并行文件系统、缓存层，理解数据读取对训练吞吐的影响
- 混部经验：训练与推理混跑、在线与离线混部，以及怎么控制互相干扰
- 成本模型：竞价实例加断点续训、资源超卖与风险控制
- 写过调度器插件或自定义调度逻辑
🛡️ 技术面重点：会被问什么
- 「GPU 利用率只有 40%，怎么查？」——最高频的一题。要分层回答：先看卡是真在算还是在等（等数据、等通信、等上一个步骤），再看单卡内部占用率与显存，最后才判断是任务本身低效还是调度造成的碎片。
- 「八卡任务排在队里，单卡任务却能插进去？」——考碎片与整机分配。整机预留会留下无法利用的零散资源；解决方向是拓扑感知、碎片整理与队列策略配合。
- 「为什么要 gang scheduling？」——分布式训练要么全起要么全不起，否则先起的任务占着资源等伙伴，造成死锁与大面积浪费。
- 「怎么防止一个团队占满集群？」——配额、优先级、抢占、单任务规模上限、排队时长上限；要主动说明这些策略的副作用（比如利用率下降）。
- 「MIG 切分值不值？」——小任务隔离好、计费细粒度；但大任务无法跨片使用，碎片化与运维复杂度上升。答案取决于集群里小任务占比。
- 「抢占怎么设计才不伤用户？」——只抢可恢复的任务、给足宽限时间、依赖断点续训、提前通知、事后补偿配额；否则用户会开始藏资源。
- 「训练任务无故变慢怎么排查？」——顺序是：数据读取、通信（NCCL 与网络）、同节点邻居干扰、降频、掉卡。要能说出每一步的观测手段。
- 「怎么衡量调度做得好不好？」——利用率、平均等待时长、长尾等待、抢占率、碎片率，单看利用率会掩盖公平性问题。
⚖️ 业务场景：选型与权衡
| 场景 | 方案 | 权衡 |
|---|---|---|
| 大规模训练为主、作业批处理 | Slurm | 作业模型简单直接、调度成熟；生态偏 HPC，云原生与多租户能力弱 |
| 训练加推理加 Notebook 混合 | Kubernetes 加批量调度组件 | 生态丰富、多租户好做；调度语义复杂，需要自己补批量与 gang 能力 |
| 大任务为主、追求通信效率 | 整机独占 | 通信最干净、性能最好；碎片多、小任务利用率低 |
| 大量小任务、多租户 | MIG 或时间片切分 | 利用率与隔离性提升；单任务性能下降，大任务无法使用 |
| 成本敏感、可容忍中断 | 竞价或抢占资源 | 显著便宜；必须配套断点续训与自动重调度 |
| 波动大、不想养硬件 | 公有云弹性资源 | 弹性好、免运维；单价高、库存受限、大规模训练有网络瓶颈 |
| 优先级差异大 | 优先级加抢占加配额 | 保障关键任务；设计不当会造成频繁抢占和资源藏匿 |
🚧 故障排查
- 掉卡：先看 Xid 报错与 ECC 计数，隔离节点再做判定；同时确认任务能自动重调度而不是一直挂在那里
- 任务一直处于等待状态：排查配额、亲和与拓扑约束、镜像拉取失败、污点未容忍；先看调度事件，再动手改配置
- 通信超时：查网卡与交换机、任务是否跨了较远的拓扑层级、MTU 配置、以及是否存在某张慢卡拉低整体
- 节点失联：kubelet 异常、device plugin 挂了、驱动版本不一致；要保证节点摘除后任务能被正确重调度
- 显存泄漏或僵尸任务：容器已退出但进程未回收，卡被人占着不能用；补上清理机制与超时回收
- 利用率看着高但产出低：任务占着卡在等数据或空转，需要看 SM 占用与真实吞吐，不能被汇总指标骗过去
💵 成本优化
- 把账算在 GPU 小时上：利用率从四成提到六成，等价于凭空多出一半算力，这是这个岗位最大的价值来源
- 回收闲置：Notebook 与调试任务长期空占是利用率最大的漏斗，加空闲超时回收，收益通常立竿见影
- 碎片整理：小任务填充零散资源、定期做合并窗口，减少「有卡但凑不出八卡」的浪费
- 抢占实例加断点续训：把可中断的任务放到便宜资源上，前提是把中断损失控制到可接受
- 混部：推理低峰把卡让给训练，前提是有明确的优先级与资源归还机制，不让在线服务受影响
- 计量到团队：让使用方看见自己花了多少卡时，才会主动优化任务写法——这比平台方单方面优化更有效
♾️ 项目经历怎么讲
调度类项目最容易被追问「你怎么证明是你的功劳」，因为利用率受任务结构影响很大。用三段式：
- 集群现状与问题：卡数、任务类型分布、当时的核心痛点（排队久、碎片多、利用率低、故障频繁）
- 你做的改动：调度策略、配额、隔离、抢占、自愈，每一项要讲清为什么这么设计，以及带来什么代价
- 指标变化：利用率、平均与长尾等待、故障恢复时间、单位算力成本，并说明怎么排除任务结构变化带来的干扰
正例：「集群里小任务多，整机分配导致碎片严重。我引入了碎片整理和队列分层，把大任务与小任务分开排，同时给调试任务加了空闲回收，整体利用率和等待时长都有改善，也说明了期间任务结构基本没变。」
反例：「我维护了公司的 GPU 集群，保证了训练任务稳定运行。」——没有指标、没有改动、没有取舍，等于没讲。
