Lesson 03 · 训练 + 推理共集群不隔离 → 生产推理被训练挤停¶
Problem¶
AI 研究院 / 大集团 AI 中台常见: 12 团队共享 128 GPU. 上线后: - 训练任务一跑, 推理服务响应飙到 30s+ (SLA 3s 直接挂) - SRE 半夜被叫醒去 kill 训练任务 - 训练团队抱怨"跑一半被杀" - 推理团队抱怨"上线就挂" - 集群利用率反而只有 30%
Root Cause¶
训练 + 推理不能共 GPU 不隔离. 两个工作负载的时间尺度、抢占容忍度、VRAM 模式完全不同.
- 训练: 长任务 (几小时到几天) · 吃满 GPU · 不能被打断 (checkpoint 丢损失)
- 推理: 短任务 (毫秒到秒) · 突发峰值 · 必须 SLA 兜底
纯 K8s 或纯 Slurm 都不好: - 纯 K8s: 训练体验差 (无 gang scheduling · 无 batch queue · 长任务被 pod evict) - 纯 Slurm: 推理弹性差 (启动慢 · 无 auto-scale · 无 sidecar)
Fix¶
我们的 K8s + Slurm 混编方案:
- K8s (在线推理 / 短任务 / 弹性): NVIDIA GPU Operator + Kubeflow (可选)
- Slurm 22+ (离线训练 / 长任务 / 可抢占)
- 底层统一 GPU 资源池 — 通过 NVIDIA driver 层共享, 不分独立分区
- Priority Class 强制生产推理赢 — 训练可以被抢占, 推理不能
- Gang scheduling — 多 GPU 训练任务要么全部启动, 要么全部等待, 不占 GPU 空等
- DCGM + Prometheus 观测每 GPU 利用率, 空闲>24h 自动告警调优
How to Avoid¶
- 集群方案设计阶段就明确训练/推理比例 (通常 60/40 或 70/30)
- KPI 定义要有 SLA 兜底 (推理 p95 < 3s 不能违约)
- Priority Class 强制写死, 训练团队不能改
- 观测第一 — 观测就位后再上生产
- 压测 168h — 3× 峰值震荡, 训练+推理同时打满 (见 Lesson 11)
Related cases¶
- Case 13 · 128 GPU K8s+Slurm — 12 团队, 利用率 32% → 71%, 排队 -60%
Related how-tos¶
避坑成本估算: 集群不隔离 = 生产事故上升到 CTO + 团队互相不信任, 6 个月才能恢复.
下一步: 30 min 集群设计对齐