MLOps 团队如何缩短训练与推理流水线周期

“模型都准备好了，GPU 还在排队”

一位 MLOps 负责人复盘季度发布时说过一句话，让我们印象很深：

他们的流水线并不差——训练、评估、上线、回滚都有规范；问题出在最朴素的地方：GPU 永远不够用，而且永远不知道什么时候够用。

重训一跑起来，线上推理就抖；线上流量一上来，实验就卡。团队不是缺流程，而是缺一套让算力“跟着流水线走”的方式。

事情为什么会变糟（而且非常常见）

在训练与推理共用一池 GPU 的系统里，经常会出现三种“慢性病”：

• 共享池变成了隐形优先级系统：谁先提交、谁占住卡，谁就赢。
• 训练和推理互相抢头寸：一个牺牲 SLO，一个牺牲迭代速度。
• 突发流量把稳定性撕开口子：平时看着还行，一到上线、A/B、活动就全线告急。

让流水线重新跑起来的关键改动

我们帮团队做的事情并不复杂：把 GPU 资源按“流水线阶段”重新组织，而不是按“团队”或“项目”堆在一起。

1) 把“常态”与“突发”拆开

• 推理池：小而稳，保持热态，目标是可预测。
• 训练池：弹性突发，集中在重训窗口拉起，用完就收。

只做这一步，最严重的资源互抢就会明显缓解。

2) 弹性要对着“队列”和“指标”生效

团队把扩缩容的触发条件换成了更“硬”的信号：

• 训练队列是否在排队
• 推理请求压力是否持续升高
• SLO 是否接近阈值（比如 p95 延迟、错误率）

相比“多留点备用”，这种方式更可控，也更容易被复盘。

3) 把优先级写成规则，而不是写在值班同学心里

他们定了一条很简单的底线：

线上推理永远有优先通道。

训练也照样跑得快——只是不会以线上事故为代价。

指标通常会怎么变化（典型区间）

在类似模式的团队里，常见改进大致是：

如果你也有同样的卡点，可以先照着做三件事

• 先把训练和推理拆开，别让它们在同一个池里“硬碰硬”。
• 让弹性跟着队列与 SLO 走，并设置明确的空闲缩容时间窗。
• 把优先级写进策略（而不是写进微信群）。

如果你愿意，我们可以一起把你的流水线按阶段梳一遍，找出“最贵的等待”发生在哪里，再用最小改动换来最大的提升。