04 智算平台运维与资源治理

学习目标：能从运维视角把 K8s GPU 集群管起来（device plugin / GPU Operator / NFD / Volcano/Kueue 的运维面）；能设计和运维配额、抢占、优先级、多租户隔离，会治理 GPU 碎片；能让万卡集群"状态看得见"、变更可灰度；能诊断 GPU 利用率为什么低并系统性提升，会按团队做成本归因；懂训练/推理混部的潮汐调度。 重点度：需要精通（智算平台 SRE 的核心战场，直接决定集群 ROI）

概述#

智算平台运维和普通 K8s 运维的差别，可以用一句话概括：普通集群运维在保"服务不挂"，智算平台运维在保"几千万的 GPU 别被浪费"。

text
一个万卡 H100 集群，卡的采购+电费+机房一年成本以亿计。
利用率从 40% 提到 70%，等于凭空多出小半个集群——
这就是智算平台 SRE 的核心 KPI，比"可用性"更被老板盯。

所以本章不讲怎么写调度器（那是研发的事），只讲运维要干的四件事：

把 GPU 集群装起来、管起来（device plugin / Operator / NFD / 调度器运维面）
把资源治理住（配额、抢占、优先级、碎片、多租户隔离）
让万卡集群看得见、变更可控（可见性 + 变更管理）
把利用率和成本治理好（KPI、成本归因、混部潮汐）

调度器的原理和 CRD 细节（Volcano PodGroup、Kueue 四层对象、Gang Scheduling、GPU 共享方案 MIG/HAMi）见 主线 Ch4「算力资源调度」。本章只讲这些东西"上线后怎么运维"。

一、K8s GPU 调度运维#

组件栈：一台 GPU 节点是怎么"能被调度"的#

运维视角，一台裸 GPU 服务器要能被 K8s 正常分配 GPU，靠这一串组件（推荐直接用 NVIDIA GPU Operator 统一管理，避免手工装驱动踩坑）：

组件	干什么	运维关注点
GPU 驱动 + container-toolkit	让容器能访问 GPU	版本要和 CUDA/固件匹配；驱动升级要滚动、要 drain
NFD（Node Feature Discovery）	给节点打硬件标签（`nvidia.com/gpu.product`、显存、MIG 能力）	标签是调度选卡型的依据，标签缺失/错误→调度错卡
NVIDIA device plugin	向 kubelet 上报 `nvidia.com/gpu` 资源	DaemonSet，挂了该节点 GPU 就"消失"不可调度
DCGM-exporter	导出 GPU 监控指标到 Prometheus	利用率/温度/XID 故障的数据源，本章后面重度依赖
MIG Manager	管理 MIG 切分	改 MIG 规格要重置 GPU，需 drain 节点

运维高频故障：device plugin Pod 挂了 → 该节点 GPU 全部从可调度资源里消失，作业莫名 pending；驱动/toolkit 版本漂移 → 容器里 nvidia-smi 报错、CUDA 初始化失败。

调度器的运维面（Volcano / Kueue）#

原理不复述，运维只盯这几点：

队列/配额是否跟组织对齐：一个团队一个 Queue（Volcano）或 ClusterQueue+LocalQueue（Kueue），配额别按模型拆。
Gang Scheduling 必须开：否则高负载下分布式训练会互相占坑死锁（4 个 Worker 上去 3 个等第 4 个，谁也起不来）。
调度器可观测：pending_jobs、queue_usage、调度延迟进 Grafana。大量作业 pending 但集群有空卡 → 多半是碎片或配额卡住，要能一眼看出来。
借用要设上限：Kueue 的 borrowingLimit 不设，一个队列能借光全集群，其他队列饿死。

二、资源治理#

配额 / 优先级 / 抢占#

分层资源池是治理的骨架：

text
生产推理  → 高优先级、不可被抢占（QoS 保命）
训练      → 中优先级、可被抢占（但必须有 checkpoint）
实验/开发 → 低优先级、随时可被抢占

配额（Quota）：每个租户/团队一个上限，防止一家把集群吃光。
优先级（PriorityClass）：决定谁先调度、谁能抢谁。
抢占（Preemption）铁律：抢占是"杀 Pod"不是"暂停"，被杀的进度全丢。所以能被抢占的训练必须有周期 checkpoint + preStop hook 抢救，否则抢一次损失几小时。

GPU 碎片治理（利用率杀手）#

碎片是智算平台利用率低最隐蔽的原因：小任务（Notebook、CI、小推理）零散占卡，剩下的 GPU 凑不成整机，大训练作业申请 8 卡整机时到处放不下。

text
节点 A（8卡）：Notebook 占 1、CI 占 1 → 剩 6 卡，8卡作业放不下
节点 B（8卡）：Notebook 占 1        → 剩 7 卡，还是放不下
节点 C（8卡）：全空                 → 只有这里能放
→ 集群明明有 21 张空卡，8卡作业却几乎无处可去

治理手段（运维配置层面）：

手段	思路
分离调度	小任务走独立队列/独立节点池，别污染大任务的整机池
Binpack	优先把小任务塞满已占用节点，保留完整空节点给大作业
整机预留	划一批节点只给整机训练，禁止小 Pod 落入
抢占碎片	大作业可抢占低优先级碎片任务腾整机
拓扑感知	8 卡 TP 尽量落同一 NVSwitch 域，避免跨域降速

多租户隔离#

资源隔离：ResourceQuota（配额）+ MIG（需要强隔离时的物理切分）。
命名空间/权限隔离：namespace + RBAC，团队只能看/管自己的资源。
网络隔离：NetworkPolicy 限制租户间互访。
节点池隔离：敏感/合规租户用独立 node pool + 污点（taint）+ 亲和。

三、万卡集群可见性与变更管理#

万卡规模下，"人肉登机器看"彻底失效，一切靠可见性 + 自动化变更。

集群状态怎么"看得见"#

必须有一块"集群健康总览"大盘，运维一眼能答出：现在多少卡在用、多少空闲、多少故障、多少 pending 作业在排队。核心数据源是 DCGM-exporter → Prometheus → Grafana：

关键 GPU 指标（DCGM）：

text
DCGM_FI_DEV_GPU_UTIL          # GPU 利用率（粗，见下节陷阱）
DCGM_FI_PROF_SM_ACTIVE        # SM 活跃度（比 GPU_UTIL 真实）
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE  # Tensor Core 活跃度（算力真用了吗）
DCGM_FI_DEV_FB_USED           # 显存占用
DCGM_FI_DEV_POWER_USAGE       # 功耗（能侧面判断是否真在算）
DCGM_FI_DEV_GPU_TEMP          # 温度（过热会掉频→straggler）
DCGM_FI_DEV_XID_ERRORS        # ⭐ GPU 硬件故障码，运维保命指标
DCGM_FI_DEV_ECC_*             # ECC 错误
DCGM_FI_DEV_NVLINK_*          # NVLink 链路状态

GPU 硬件健康与自动摘除#

万卡集群每天都有卡出问题。XID 错误是 NVIDIA GPU 的故障码，运维要认识几个高危的：

text
Xid 79   GPU fell off the bus（GPU 掉线，通常要重启/换卡）
Xid 48   Double Bit ECC（不可纠正 ECC 错误）
Xid 63/64 Row remapping（显存行重映射，卡在退化）
Xid 74   NVLink error
Xid 94/95 Contained/Uncontained ECC error

自动化闭环（成熟平台标配）：

text
DCGM 检测到严重 XID / dcgmi diag 不通过
   → Node Problem Detector 上报节点状况
   → 自动 cordon（禁止新作业调度）+ drain（驱逐现有作业）
   → 告警给运维 + 触发工单换卡
   → 修复后自动 uncordon 回收

批量配置变更、灰度、异常快速识别#

变更走 GitOps（ArgoCD / Flux）：集群配置声明化、可审计、可回滚。禁止手工登机器改。
灰度/分批：驱动、固件、device plugin、调度器升级要按节点池分批滚动，先小批验证再全量，绝不一次性推全集群。
变更即观测：每次批量变更后盯 GPU 可调度数、作业成功率、XID 增量。变更后指标恶化立即回滚。
异常快速识别：大盘要有"异常聚合"视角——例如"某机架 12 台同时 NVLink 报错"往往指向机架级问题（供电/交换机），而不是 12 个独立故障。

四、GPU 利用率与成本治理（运维 KPI）#

先分清两个"利用率"#

运维最容易被坑的地方：

text
分配率（allocation）：多少卡被作业"占用"了       ← 看起来很高（90%）
真实利用率（utilization）：占用的卡里 SM/Tensor 真在算  ← 往往很低（30%）
   两者之差 = 被占着但没干活的卡 = 纯浪费

只看"卡分配出去了"会自我感觉良好。要盯 DCGM_FI_PROF_SM_ACTIVE / PIPE_TENSOR_ACTIVE，甚至算 MFU（Model FLOPs Utilization），才知道算力真的用了多少。

利用率为什么低#

原因	表现
碎片	有空卡但凑不成整机，大作业 pending（见第二节）
僵尸/空占	Notebook 占着卡不跑、跑完不释放、开发者忘关
申请多用少	作业申请 8 卡实际只用 2 卡（over-request）
数据加载瓶颈	dataloader / 存储 IO 跟不上，GPU 等数据（GPU_UTIL 周期掉 0）
通信瓶颈	网络慢/无损没配好，GPU 等 all-reduce（见 Ch3）
batch 太小 / 模型太小	单卡吃不满，算力空转
排队	配额/队列设计不合理，作业在排队而卡在闲置

怎么系统性提升（运维打法）#

text
1. 先量化，别拍脑袋
   拉 SM_ACTIVE / TENSOR_ACTIVE / FB_USED 的分布，找出"占着不算"的卡

2. 清僵尸
   自动回收：GPU 利用率 <X% 持续 N 小时的 Notebook/Pod 自动告警或回收
   （尤其开发环境，僵尸 Notebook 是头号浪费）

3. 治碎片
   binpack + 分离调度 + 整机预留（第二节）

4. 拧 over-request
   看历史实际用量，推动业务把申请量调到接近实际；用 GPU 共享（MIG/HAMi）
   让小任务别独占整卡

5. 混部填谷
   训练填推理的低谷（第五节潮汐）

6. 定期复盘 Top 浪费方
   按团队/作业排"分配了多少卡 vs 实际算力"，点名低效大户

成本归因（showback / chargeback）#

老板要的是"每个团队花了多少 GPU 钱、值不值"：

打标签：所有作业带 team/project label，namespace 分租户。
GPU-hour 核算：占用卡数 × 时长，再乘单卡成本（采购摊销+电费+机房）。
工具：OpenCost / Kubecost + DCGM 指标，能出"按团队的 GPU 成本 + 实际利用率"报表。
showback（展示）→ chargeback（真扣钱）：先让团队看到自己的浪费（showback），成熟后按用量真实分摊成本（chargeback），倒逼团队自己提效。

五、训练 / 推理混部（潮汐调度）#

推理有明显的日夜波峰波谷（白天用户多、夜里少），训练则是"有卡就想跑、可中断"。把两者混部能极大提升整体利用率：

text
白天：推理高峰占大部分 GPU，训练收缩到少量卡
夜间：推理回落，空出的卡让训练扩上去把集群填满
      → 同一批卡白天服务用户、夜里训模型，利用率拉满

运维实现要点：

优先级 + 抢占：推理高优先级不可抢占；训练低优先级可被抢占。推理波峰来了自动抢回训练的卡。
弹性伸缩联动：推理侧 HPA/KEDA 按 QPS 缩容，释放的卡 Kueue/Volcano 自动给训练。
训练必须能被中断：混部的训练一定要有 checkpoint，抢占时保存进度、恢复时续跑。
隔离防打扰：混在同机时用 MIG/MPS/HAMi 做算力显存隔离，别让训练把推理的延迟拖崩（noisy neighbor）。
护栏：给推理留安全水位（reserved 卡），别为了填谷把推理 SLO 搞挂。

实战#

实战一：GPU 集群利用率低，怎么系统性提升#

现象：财务盯着说卡买了这么多，利用率报表只有 35%。

text
1. 分配率 vs 真实利用率对齐
   大盘拉：卡分配了多少（quota/占用）？ SM_ACTIVE 中位数多少？
   → 若"分配 90% 但 SM_ACTIVE 30%" → 占着不算，是浪费不是缺卡

2. 定位浪费构成（按数据分类）
   - FB_USED 高但 SM_ACTIVE≈0 且持续数小时 → 僵尸/空占（多为 Notebook）
   - GPU_UTIL 周期性掉 0 → 数据加载或通信瓶颈
   - pending 作业多但有空卡 → 碎片 / 配额卡住

3. 分头治理
   僵尸 → 自动回收策略；碎片 → binpack+整机预留；
   over-request → 推业务改申请量 + 上 GPU 共享；
   数据瓶颈 → 优化存储/dataloader；排队 → 重配队列配额

4. 上混部
   训练填推理低谷，把夜间空卡吃掉

5. 建长效机制
   showback 报表按团队公示浪费，月度复盘 Top 低效方

实战二：某租户把卡占满了，别的团队起不来#

现象：team-A 一夜之间把集群大半 GPU 吃光，team-B 作业全 pending。

text
1. 快速定位是谁、占了多少
   按 namespace/label 聚合 GPU 占用 → 锁定 team-A 及其作业列表

2. 判断"合法占用"还是"越界"
   - team-A 是否超了自己的 quota / 借用是否超了 borrowingLimit？
     → 若配额没设或 borrowingLimit 没设，这是治理漏洞，先补上
   - 是不是僵尸作业占着不算？→ SM_ACTIVE 若≈0，是空占，可回收

3. 应急处置（按红线：写操作/驱逐先确认影响面）
   - 有合理配额体系：靠抢占自然平衡——team-B 高优先级作业抢回借出的卡
   - 无配额体系（裸奔）：先和 team-A 沟通，再手工按优先级驱逐其可中断作业
     （确认这些作业有 checkpoint，否则会丢进度）
   - 紧急给 team-B 保命：临时提优先级 / 划预留节点

4. 根因整改
   - 给每个租户配 quota 上限 + 合理 borrowingLimit
   - 分层 PriorityClass（生产不可抢、训练可抢）
   - 加"单租户占用超阈值"告警，下次自动预警而不是等人投诉

小结#

智算平台运维的本质是"用治理手段把昂贵的 GPU 榨出价值"，四条主线：

text
管得住   → GPU Operator/NFD/device plugin/调度器运维面，节点能调度、故障能摘除
治得了   → 配额+优先级+抢占+碎片治理+多租户隔离，资源不被吃光不被浪费
看得见   → DCGM→Prometheus→Grafana 大盘 + XID 自动摘卡 + GitOps 灰度变更
省得下   → 分清分配率与真实利用率，清僵尸/治碎片/拧 over-request/混部填谷 + 成本归因

运维要刻进肌肉的几点：

利用率的真相在 SM_ACTIVE，不在分配率——分配 90% 也可能真用 30%。
碎片和僵尸是利用率的头号杀手，靠 binpack+整机预留+自动回收治。
抢占必配 checkpoint，否则每次抢占都是几小时进度打水漂。
万卡靠可见性和自动化活着：XID 自动摘卡、GitOps 灰度变更、异常聚合识别。
成本归因倒逼提效：showback→chargeback，让浪费的团队自己心疼。

下一章是 AI Infra 全景与岗位地图——把前面所有专题串成一张图，讲清运维 vs 研发的分野、分层全景、模型全生命周期的运维触点、岗位地图，以及国产化（昇腾）运维差异。