训练和推理混跑GPU资源分配，正确做法是让推理任务持有最高优先级和独占显存，训练任务在推理空闲时插空运行，靠动态配额和物理隔离实现二者共存。
训练和推理混跑GPU资源分配，先看清两者分歧在哪
训练和推理混跑之所以让GPU资源分配变得棘手,是因为这两个任务的目标函数完全相反，训练是个大胃王，恨不得把GPU的算力和显存一次性吃干榨净；推理是个急性子，每个请求都有严格的延迟红线，资源稍有争抢，P99延迟立刻飙升，两者挤在同一张卡上，矛盾不可避免。
显存争夺：训练要连续大块，推理要碎片灵活
训练任务做大batch时,需要连续的显存块来装载激活值和梯度，推理任务则不同，尤其是大模型推理，KV cache会随着并发请求数动态伸缩，在显存里留下大量碎片，这种碎片化会直接导致训练任务分配不到足够大的连续显存，batch size被迫缩小，训练吞吐掉得厉害。
大模型混跑显存不够怎么办？最简单的答案是：别让它们在显存层面硬挤，先确认模型尺寸和显存容量，推理模型常驻显存的部分建议单独隔离，训练任务只使用剩余显存区间。推理模型占用的显存建议预留为峰值的1.2倍，剩余空间再交给训练任务动态伸缩。
算力峰谷错配：训练峰值和请求洪峰撞车
训练的算力需求长期处于高位,推理的算力需求则跟着用户请求波动，二者混跑时，一旦请求洪峰到来，训练正在跑的大矩阵乘法会占据大量SM，推理请求只能在后排队，反过来，推理空闲时，GPU算力大量闲置，训练任务却因为显存不连续而无法利用这些空闲算力。
行业共识认为,混跑的前提是先把任务错峰，训练任务优先吃推理任务的空闲期，如果推理请求平缓且预测性强，训练任务可以压低batch size，把GPU占用量控制在一个安全水位。
稳定性目标不一致
训练任务中断大不了重新拉起,顶多损失一点训练进度；推理任务中断就是线上事故，用户直接感知，混跑时必须接受一个事实：训练任务必须能被随时暂停、缩容、甚至驱逐，做不到这一点的训练框架，不建议放进混跑集群。
训练推理混跑GPU资源分配，核心是优先级和隔离
混跑方案的架构设计,业内专家指出，最重要的是把“优先级”和“隔离”拆开处理，优先级解决的是谁先谁后，隔离解决的是谁都不能碰谁的资源，两者缺一不可：没有优先级，训练和推理互相抢占；没有隔离，高优先级任务也会被低优先级任务的显存碎片影响。
优先级怎么设：推理延迟敏感，训练弹性容忍
任务队列要分等级,推理Pod应该进入无法被抢占的高优队列，训练任务标记为可抢占（preemptible），Kubernetes里可以通过设置priorityClass，让推理任务的调度权重远高于训练任务。
- 推理请求队列：最高优先级，延迟敏感，资源预留
- 训练任务队列：中低优先级，弹性调度，随时可让出资源
- 数据预处理任务：最低优先级，只在GPU完全空闲时运行
当推理负载上升时,调度器先驱逐数据预处理任务，再压缩训练任务batch，最后如果还不够，挂起训练任务，这个顺序需要提前写进调度策略，不能等到冲突发生时再手动干预。
显存级别怎么隔离
隔离方案取决于GPU型号。
- A100/A800支持MIG（多实例GPU），可以切出多个实例，每个实例独享显存和计算单元，推理实例和训练实例完全物理隔离，MIG切分后，实例间无性能干扰，是最可靠的隔离手段。
- 4090没有MIG能力，只能用CUDA_VISIBLE_DEVICES做整卡隔离，或者用容器运行时限制显存，但这只是软件层隔离，显存带宽和L2缓存仍然共享，极端负载下仍有性能波动。
- H800/H20同样支持MIG，但具体切分配比要参考NVIDIA官方文档中的实例规格表。
容器层面,可以通过NVIDIA device plugin为每个容器设置显存上限，给训练容器限定一个显存天花板，防止它把所有剩余显存一次性占满。
算力时间片怎么分
显存隔离解决的是空间问题,算力分配解决的是时间问题。
推理请求低峰期（比如凌晨），训练任务从checkpoint恢复训练，逐步扩大batch size，把GPU算力吃满，推理请求高峰期（比如白天业务时段），训练任务缩小batch size，降低SM占用率，如果一个训练步长内连续多次观测到推理延迟超标，训练任务应当主动挂起，释放全部算力。
可落地的混跑流程参考：
- 监控推理负载,统计最近三分钟的平均请求间隔
- 推理空闲度超过阈值（比如请求间隔大于3秒），拉起训练任务
- 训练任务每30秒检查一次推理P99延迟,超过设定红线就缩batch
- 缩batch两次后P99仍超标,保存临时checkpoint，挂起训练任务
- 训练任务恢复时,从临时checkpoint重启，不能从零开始
这套流程的关键在于阶段三的检查频率,检查太频繁会消耗算力，检查太稀疏又保护不了推理。
30秒一轮是比较稳妥的折中值。
单卡混跑和多卡混跑，哪个更适合你的场景
场景不同,混跑方案的选择直接分化。
单卡混跑：4090做推理卡，活动空间有限
单卡混跑适合模型参数量小于13B、请求量平缓的私有化部署场景，4090的24GB显存是硬约束，推理模型常驻显存后，剩余空间通常只够训练任务跑很小的batch，这种情况下，训练任务只能作为“余量利用者”存在，别指望它达到理想训练吞吐。
多卡混跑：A100和4090分工，各干各的
多卡混跑在实践中更常见,A100（80GB）用作训练池，4090用作推理池，二者通过网络层打通，4090推理池承接高频推理请求，A100训练池专门跑训练任务，两个池子之间通过资源调度框架动态调整比例：推理负载高了，把部分A100从训练池借调过来跑推理实例；推理空闲了，A100全部回归训练池。
4090和A100混跑对比：
| 维度 | 单卡混跑（4090） | 多卡混跑（A100+4090） |
|---|---|---|
| 显存 | 24GB，模型受限 | 80GB，大模型训练友好 |
| 隔离能力 | 无MIG，软件层隔离 | A100支持MIG，物理隔离 |
| 适合场景 | 中小模型、请求平稳 | 大模型、高并发弹性场景 |
| 故障影响 | 单卡故障，混合任务全挂 | 单卡故障，只影响对应池 |
| 运维复杂度 | 低 | 中高 |
如果训练和推理都是常态化高负载业务,多卡混跑几乎是必然选择，单卡混跑只能在资源实在受限的过渡期使用。
GPU混跑成本怎么算，空闲算力定价才是关键
混跑的收益来自GPU利用率的提升,但成本核算如果算不清楚，省下来的资源反而会变成糊涂账。
每张GPU的固定成本包括采购折旧、机房机架费用和电费，推理服务有一套SLA，它必须预留足够的冗余算力应对洪峰，这些冗余算力在大部分时间是闲置的，混跑的核心收益，就是把这些闲置时间卖给训练任务。
定价逻辑参考：
- 推理服务固定预留30%算力兜底，这部分成本由推理业务承担
- 剩余70%算力按实际运行时长计价，谁用谁付
- 训练任务使用暗时间（推理空闲时段），单位价格按推理业务电价和折旧成本折算，通常比独占整机更便宜
- 如果训练任务在高峰期抢占推理资源导致SLA违约,需要设置惩罚价格
近年来,越来越多的中小团队开始接受这种成本分摊模型，GPU混跑方案在AI Infra团队中的采用比例明显上升。
北京和上海智算中心的混跑调度，有哪些可借鉴的做法
国内智算中心在混跑调度上已经有一套成熟的工程实践,北京和上海的超大规模GPU集群，普遍采用“分区错峰+动态调度”的组合策略。
- 北京某智算中心的做法：把集群按业务类型分区，白天高峰时段运行推理和在线服务，凌晨低峰时段统一调度训练任务，调度器基于Slurm队列，训练任务以backfill模式填充空闲节点。
- 上海智算中心的思路：在物理分区基础上引入DPU网络隔离，混跑时训练任务的高速通信流量不会影响推理请求的网络延迟，据工信部算力基础设施相关规划中提及的信息，这种网络级隔离已经被纳入智算中心建设参考指标。
对中小团队而言,不必照搬超大规模的调度系统，但“分区错峰”的思想可以直接落地：物理上隔离训练和推理分区，逻辑上通过时间维度错峰切分。
训练推理混跑GPU资源分配的常见疑问
大模型混跑显存不够怎么办
优先压缩推理侧的KV cache显存占用，使用PagedAttention或量化KV cache（如INT8），把推理驻留显存压到原始方案的70%左右，同时限制推理最大并发数，给训练任务留一条底线性显存空间，这两步做完仍然不够的情况下，只能走多卡混跑，把训练任务迁移到另一张卡上，不要在单卡上强行塞两个大模型。
单卡混跑时训练把推理拖垮了，怎么办
确认隔离策略是否真正生效,没有MIG的显卡上，训练任务的CUDA kernel会和推理kernel争抢SM，解决办法：用任务绑核（如CUDA_LAUNCH_BLOCKING）给推理关键路径提权，或者直接禁止训练任务在推理高峰期运行，如果业务有规律性洪峰，建议采用时间窗口切分：高峰前15分钟挂起训练，洪峰过后再恢复。
混跑时训练任务总被抢占，会不会一直完不成
训练任务被抢占的前提是它没跑完,要保证训练有进展，给训练任务设置一个最低连续运行时间，比如强制保证“当前checkpoint步骤完成后再处理抢占请求”，通过优雅退出机制实现，调度器需要记录训练任务实际获得的GPU时长，当累计被抢占次数超过阈值时，把训练任务升级为不可抢占的高优队列，直到它完成一个完整的checkpoint周期。