训练和推理共用一座集群时，怎样不互相伤害

1. 目标函数：不是 GPU 利用率最大，而是业务价值最大

训练希望尽快完成 step/epoch，离线 batch 可容忍秒级抖动；在线推理要求毫秒级 TTFT/TBT 和高可用。集群调度要在推理 SLO、训练完成时间、成本、能耗和故障风险之间权衡。把 GPU utilization 推到 100% 可能正是尾延迟失控的原因。

2. 四类工作负载的资源画像

3. 推理与训练的内存构成完全不同

推理副本的动态大头是 KV；训练的动态大头是保存激活、梯度与优化器。Adam 类训练在不做 ZeRO/FSDP 时，参数、梯度、主权重和两个 moment 会使每参数状态远大于仅权重推理。量化 rollout 也不等于可以用同精度训练。

共卡时还会产生 allocator 碎片和 CUDA Graph 固定地址冲突。除非 runtime 明确支持弹性 HBM/时间切片，在线推理与训练放在同一进程/同一 GPU 通常风险高于收益。

4. 五种干扰路径

1. HBM：训练激活或 optimizer state 挤压推理 KV，触发抢占/OOM。
2. SM：大训练 GEMM 占满 SM，decode token iteration 延后。
3. 链路：梯度 all-reduce、EP all-to-all、PD KV 同时 burst。
4. 存储：checkpoint、dataset scan 与 KV SSD load 争 NVMe/网络存储。
5. 控制面：训练作业扩缩容导致 communicator/模型加载，冲击在线 worker。

平均利用率看不见这些毫秒级同步冲突。必须把推理 TBT spike 与训练 step/collective/checkpoint timeline 对齐。

5. 推荐的三层资源边界

Tier 表示资源策略，不一定对应某种物理机型。Tier A 不能依赖随时可能被训练占满的资源；Tier C 可以使用空闲容量，但要在承诺时间内归还。

6. 控制循环：预测、保留、借出、回收

1. 按模型和 SLO 预测未来窗口的 inference demand，加入误差与故障余量。
2. 为 hot replicas、KV 和链路预留 Tier A 容量。
3. 把剩余 GPU 以 lease 借给训练，lease 标明最晚归还、checkpoint 成本和可迁移 mesh。
4. 负载上升前发出 reclaim；训练在安全边界 checkpoint、缩 DP 或结束低价值 trial。
5. 在线扩容先加载权重/communicator、warm graph/cache，再把流量切入。
6. 比较预测与实际，更新安全余量和回收提前量。

7. 优先级与抢占：粒度必须匹配状态成本

在线 decode 不应被训练 kernel 长时间阻塞；训练也不应在任意指令中断后丢失数小时工作。合理抢占点是 decode token/chunk、训练 step/optimizer update、RL trajectory batch。每类作业声明 checkpoint bytes、预估时间和最小 gang size。

GPU gang scheduling 还要避免部分资源占用：一个 TP8 作业只拿到 7 卡不能运行，却可能阻塞队列。调度器应原子分配完整 topology-compatible group，或使用支持动态 TP/PP 的 runtime 在明确边界变形。

8. Checkpoint：从“定时保存”变成弹性协议

完整 checkpoint 包含模型、optimizer、scheduler、RNG、dataloader position、并行 shard metadata；RL 还要保存 policy/reference/reward 版本与 trajectory cursor。只保存权重可能无法无偏恢复训练。

回收训练资源前，应先确认 checkpoint manifest committed，再释放 gang。写到一半的 shard 不能被恢复器视为完整版本。

9. 弹性并行：改变 DP 最容易，改变 TP/PP 更昂贵

训练增加/减少 DP replica 主要改变数据划分与梯度 group；改变 TP/PP 会重分权重、optimizer 和 activation schedule，成本更高。推理中增加 DP replica 需加载整份权重；动态 TP 则需重排 KV 和 communicator。

弹性控制通常优先调整 DP/P worker 数，TP/PP 的变化成本更高。Nitsum 与 Flying Serving 的 2026 工作表明在线动态 TP 可行，但需要 weight shard view、KV adaptor、communicator pool 和切换 hysteresis；Kubernetes pod 数量变化本身并不等同于模型并行的安全切换。

10. Agentic RL 为什么把训练和推理真正揉在一起

RLHF/RLAIF/Agentic RL 的 rollout 用当前 policy 生成轨迹，环境/tool 执行在 CPU 或外部系统，reward/verifier 打分，trainer 更新权重，再把新版本发给 rollout。各组件资源特性不同，若严格同步，最慢组件让全 pipeline 空等。

系统必须记录每条 trajectory 使用的 policy version，控制允许的 staleness；否则高吞吐异步会改变训练算法语义。

11. RollArt（OSDI 2026）：按硬件特性拆 Agentic RL pipeline

RollArt 把 prefill 放到 compute-oriented GPU、decode 放到 bandwidth-oriented GPU、环境放 CPU，并做 trajectory-level asynchronous execution。OSDI 官方页报告训练加速 1.31–2.05×，并在阿里 3,000+ GPU 集群上运行数千亿参数 MoE。

不同阶段可以使用不同资源池，从而减少全局 barrier。代价包括异步 trajectory 的 policy staleness、跨池 KV/trajectory 传输和更复杂的故障恢复。部署前需要与算法团队共同定义允许的 policy version 差值。

12. DynaRL（OSDI 2026）：用动态超图迁移 RL 组件资源

DynaRL 把 RL pipeline 表示成 dynamic hypergraph，根据 agentic/multi-turn 动态性在组件间迁移资源。OSDI 官方页报告吞吐最高 1.98×。

相对静态“rollout X 卡、train Y 卡”，动态超图能随输出长度、工具等待和训练阶段变化调整。实现难点是迁移成本估计和最小稳定窗口；若每个负载尖峰都重配置，权重/communicator 搬迁会吞掉收益。

13. 异构推理池：旧卡不是只能做离线任务

EcoServe（OSDI 2026）在 commodity Ethernet cluster 上做 partially disaggregated serving；32×L20、30B/70B 实验中，相对 vLLM、Sarathi、DistServe、Mooncake 的 goodput 分别最高 1.96×、1.99×、2.51×、2.40×。它说明并非所有 PD 都要求顶级 fabric，但工作负载和传输设计要适配以太网。

ShuntServe（2026 预印本）面向异构 spot GPU，用 roofline estimator 和 DP placement，支持输出保持的迁移、并发初始化与共享 tensor store；在 AWS L4/A10G/L40S、Llama‑3.1‑70B/Qwen3‑32B 上报告吞吐/成本效率改善。spot interruption 模型和云价格会变化，必须重算而非固化论文结论。

14. CPU/GPU 混合 MoE：容量池可以承担特定阶段

OSDI 2026 的 Local MoE CPU/GPU system使用 stream-loading prefill、zero-copy PD 等机制；官方摘要报告单机 prefill 1200 token/s、32K 在 30 秒内，两张 RTX5090 达 1800 token/s/45K，zero-copy PD 在低于 15% latency 代价下吞吐提高 50%；INT4 DeepSeek‑V3 达 28 token/s，FP8 21.5 token/s。

它适合容量受限、交互 SLO 较宽或边缘场景，不应与 rack-scale H200/B300 服务直接横比。训练/推理共用集群可把低优先级长 prefill 或冷模型送到这类容量池，但 router 必须知道更高的 TTFT。

15. 模型冷启动与权重分发

在线突发前把训练 GPU 改成推理 GPU，需要下载权重、初始化并行 group、分配 workspace、capture graph、warm kernel 和注册 router。只计算权重大小/存储带宽会低估启动时间。

HydraServe（NSDI 2026）针对 serverless cold start，使用主动模型分发、阶段重叠、topology-aware worker placement 和 pipeline consolidation；论文报告冷启动降低 1.7–4.7×、SLO attainment 提高 1.43–1.74×。训练容量回收要把这些启动阶段纳入 lead time。

16. 网络与存储必须做全局 QoS

训练 gradient、checkpoint、dataset，推理 TP/EP、PD KV、权重冷启动共用 fabric。建议至少划分 latency-critical collective/KV、model/weight distribution、checkpoint/bulk data 三类 traffic，并给 bulk 流量速率上限。

存储同样要把 SSD KV 与 checkpoint IOPS 分开预算。checkpoint 可以延迟几十秒，首 token KV load 不行；优先级需要从应用队列延伸到 storage/NIC。

17. 功率、散热与可用容量

机架功率是硬约束。训练持续高功率，推理更突发；二者共处可能让瞬时功率/散热超过设施预算，即使 GPU 数量还有空位。调度器应使用实测功率曲线和设施 cap，必要时给低优先级训练做 power cap，而不是在在线负载到来后紧急杀作业。

能耗指标应按成功请求或有效训练 token 归一化。降低单卡功率若使 job 延长并占用更多固定设施能耗，未必降低总能耗。

18. 故障域与恢复

在线 replica 应跨机架/电源/交换故障域；大型训练 gang 可接受单点导致 step retry，但 checkpoint 必须在独立持久层。Agentic RL 还需恢复 rollout queue、trajectory version 与 trainer step，避免同一轨迹重复计入。

• worker loss：router 停止新流量，KV directory 失效 owner epoch。
• training rank loss：gang abort 或 elastic shrink，恢复到 committed checkpoint。
• network partition：在线优先降级到本地 replica；训练暂停跨域 collective。
• control-plane loss：租约保守到期，禁止继续侵占 Tier A 保留容量。

19. 具体例子：32 张 GPU 如何在白天和夜间重分配

假设 8 卡为一个高速域。白天保留 2 个 TP8 decode replica（16 卡），1 个 TP4 prefill pool 加 4 卡弹性（8 卡），剩余 8 卡做可抢占 fine-tune。夜间需求下降，只保留一个 TP8 热副本，另外 24 卡组成 3×DP 的 TP8 训练/rollout mesh。

1. 预测高峰前 20 分钟发 reclaim；训练完成 step 并异步 checkpoint。
2. 8 卡加载 prefill/第二 decode 权重，预建 communicator、capture graph、执行健康请求。
3. router 只在 warmup 达标后逐步切流；保留旧容量直到 P99 稳定。
4. 高峰结束后先 drain 新副本，保留有价值 KV 到远端 tier，再把整 gang 租回训练。

实际提前量要由 checkpoint、权重加载和 warmup 的 P99 决定；这里的卡数只是说明控制流程。

20. 统一指标：一张表看训练、推理和共用损失

21. 运行手册

• 先用 2–4 周 trace 建需求/回收模型，再开放训练借用在线容量。
• Tier A 保留池设置不可被普通 batch scheduler 覆盖的硬 quota。
• 所有训练 job 声明 checkpoint P99、最小 gang、可缩 DP 和最大归还时间。
• 模型镜像、权重与 communicator warmup 定期演练，不在首次高峰时验证。
• 做网络/SSD fault injection，确认训练 bulk traffic 限速真的保护 TBT。
• 每次调度策略变更同时回放推理和训练 trace，观察两侧 Pareto front。
• RL pipeline 明确 policy staleness 与 trajectory exactly-once/at-least-once 语义。

22. 局限与何时不该共用

若在线 SLO 极严、需求不可预测、模型加载数十分钟、训练不可 checkpoint，物理隔离通常更便宜。若网络已经被训练 collective 饱和，把 PD/EP 推理放进同一 fabric 会制造难以控制的尾延迟。合规数据域不同，也可能禁止共享存储或 worker。

23. 最小复现实验

选一个固定推理 trace 与一个可 checkpoint 训练作业。依次测试物理隔离、静态共分、弹性租约、弹性+网络 QoS。对推理负载注入 2× 突发，对训练注入 checkpoint 和 rank failure。

验证问题：
1. 推理 P99 TTFT/TBT 相对隔离基线恶化多少？
2. 训练 time-to-train 改善/恶化多少？丢失多少 step？
3. reclaim request → warm replica 可接流量的 P99 多久？
4. checkpoint/weight load 是否造成 NIC/SSD tail spike？
5. 预测错误 2× 时 Tier A 是否仍满足 SLO？

24. 2026 一手来源