训练和推理混跑时，GPU资源分配的核心原则是：显存按需硬隔离，算力按优先级动态抢占，同时用MIG、时间片或进程级限额工具将两类负载关进不同“隔间”，避免互相干扰。混跑不是把任务塞进同一张卡就完事，而是要在显存、算力、调度三个维度同时做约束，否则轻则推理延迟飙升，重则训练OOM直接崩掉。
为什么训练和推理混跑会互相“打架”
训练和推理对GPU资源的需求完全是两种性格,训练任务像一头埋头苦干的牛，长时间霸占算力，显存占用波动剧烈，forward和backward阶段峰值差异很大，推理任务像一个需要随时响应的前台，延迟敏感，显存占用相对稳定但QPS波动明显。
把这两者放同一张卡上,如果没有约束机制，会出现三类典型问题。
显存封顶导致训练中断，训练任务在反向传播时会申请额外显存，如果推理任务已经把显存占了大半，训练轻则触发CUDA OOM，重则整个进程被杀，业内专家指出，训练任务的显存峰值通常比均值高出20%到30%，这点余量必须提前预留。
算力饥饿拖慢推理延迟，GPU的SM（流式多处理器）是共享资源，训练任务把SM占满后，推理请求的kernel只能排队等着，最直观的感受是，本来3毫秒能响应的接口，混跑后直接变成40毫秒甚至超时。
抖动引发连锁故障，推理服务为了追求吞吐，通常会设置动态batch，当训练任务周期性释放显存时，推理服务的内存池会重新分配，导致P99延迟忽高忽低，严重的直接触发健康检查失败，实例被K8s杀掉重启。
行业共识认为,混跑前不做好资源隔离，最终结果往往是训练和推理双输。
核心分配策略：从硬隔离到软抢占
训练和推理混跑GPU资源怎么分配才合理,本质上取决于你愿意为“隔离性”付出多少硬件利用率代价，按隔离强度从高到低，主流方案有四种。
设备直通（物理隔离）是最简单粗暴的方式，每张卡只跑一个任务，彻底物理隔绝，优点是零干扰，缺点是GPU利用率可能很低，尤其是推理负载波谷时段，卡基本在空转。
MIG（多实例GPU）是A100及H100等新一代卡上的硬隔离方案，一张卡可以切成最多7个实例，每个实例拥有独立的显存和计算单元，硬件层面真正隔离，但MIG的局限在于实例大小是离散档位，比如A100只能切成1g、2g、3g、7g这几种规格，显存浪费问题比较明显。
MPS（多进程服务）是软隔离方案，允许不同进程共享GPU，但可以限制每个进程使用的算力百分比，和MIG不同，MPS的显存仍然是共享的，只是通过算力上限来约束，适合显存占用不大、但算力需求明显的场景。
容器级时间片调度是K8s生态里最常见的方案,通过NVIDIA Device Plugin的time-slicing功能，一个GPU可以分配给多个Pod，按时间片轮转算力，配置成本最低，但隔离性最弱，高负载下性能衰减无法精确控制。
| 方案 | 隔离级别 | 显存隔离 | 算力隔离 | 适用场景 |
|---|---|---|---|---|
| 物理直通 | 硬件 | 完全隔离 | 完全隔离 | 关键生产、合规要求高 |
| MIG | 硬件 | 完全隔离 | 完全隔离 | 大卡拆分、稳定混部 |
| MPS | 软件 | 共享 | 比例限制 | 显存占用小、算力可压缩 |
| 时间片 | 软件 | 共享 | 轮转调度 | 开发测试、弹性混部 |
混合负载GPU显存分配方案怎么选更合理
选方案不能只看隔离强度,还要结合你的业务场景和显卡型号，下面按三种常见场景拆解。
开发测试环境的弹性混部
这种场景下,训练任务大多是单卡调试，推理任务可能是连着的测试服务，流量不大但要求响应快，此时选出错成本最低的时间片方案更合理，具体操作上，在K8s的ConfigMap里配置nvidia.com/time-slicing-gpu，把一张卡切成多个虚拟GPU，配合资源配额限制每个Pod的CPU和内存。
需要注意一点,时间片方案下，显存上限仍然是整张卡的显存总量，两个Pod同时向卡里塞数据，依然可能OOM，所以记得给每个Pod设置显存级别的硬限制，比如通过环境变量CUDA_VISIBLE_DEVICES配合NVIDIA容器运行时强行指定显存上限。
生产环境的稳定混跑
生产环境的核心诉求是推理延迟不能毛刺，训练不能无故中断，如果你手头是A100或H100，优先考虑MIG，比如一张A100显存80GB，用nvidia-smi命令创建两个实例，一个40GB专门给推理，一个40GB给训练，两边从硬件层面完全隔离，互不感知。
MIG的具体配置命令如下：
nvidia-smi mig -cgi 1g.40gb,3g.40gb -C其中1g.40gb和3g.40gb是MIG的不同实例档位，分别对应不同的SM数量和显存大小，创建好后，用nvidia-smi mig -gi查看实例ID，然后在容器启动时将实例ID透传给NVIDIA_VISIBLE_DEVICES环境变量即可。
单卡小模型的内网混跑
很多企业内部会拿一张RTX 4090同时跑微调和线上小模型推理，此时MIG用不了，MPS是个不错的选择，通过nvidia-cuda-mps-control -d启动MPS守护进程，再通过CUDA_MPS_PIPE_DIRECTORY设置进程专属管道，两个客户端就可以共享同一张卡，用CUDA_MPS_ACTIVE_THREAD_PERCENTAGE可以限制某个进程的算力上限。
这种方案能限制算力,但显存依旧是共享的，如果训练任务突然申请大显存，推理进程可能因无法分配显存而崩溃，此时可以考虑给推理服务加一层内存预热机制，让权重提前驻留显存，减少动态申请的概率。
混跑后的性能监测和动态调优
分配方案定下来不等于万事大吉,混跑是动态的，训练任务在epoch切换时算力需求会变，推理流量也有波峰波谷，需要一个反馈循环来持续调优。
第一步,采集基线数据，部署DCGM（Data Center GPU Manager）采集GPU利用率、显存占用、SM占用率和温度曲线，至少积累一周的样本，才能判断当前切分比例是否合理，如果发现训练任务长时间把算力打到90%以上而推理P99依然稳定，说明可以适当收紧训练配额，提高推理冗余。
第二步,设置告警阈值，不要等显存满了才收到告警，建议将显存占用率阈值设为75%，SM利用率设为85%，超过后自动触发资源调度脚本，比如通过K8s HPA（Horizontal Pod Autoscaler）根据自定义指标对推理Pod进行扩容，或者通过cronjob在预测流量高峰前手动减少训练任务的batch size。
第三步,定期复盘分配比例，可以用一句话检验分配是否健康：两个任务的疲劳度曲线是否都平缓，如果训练任务每天固定时间点显存飙高，推理延迟跟着同步抖动，说明隔离强度不够，需要升级到MIG或物理隔离。
训练推理混部时常见的几个认知误区
第一个误区,以为显存够用就不需要隔离，显存只计算了容量维度，没考虑带宽和L2缓存争抢，即使显存余量充足，训练和推理并发访问相同的内存bank时依然会产生冲突，导致实际带宽吞吐骤降。
第二个误区,算力限制设得太死，有些团队把训练任务的GPU利用率限制在30%，表面看是给推理留了空间，实际上训练任务因为算力不足，训练周期拉长了三倍，综合成本反而更高，更好的做法是按优先级抢占而非按比例硬切，用NVIDIA的优先级机制配合K8s QoS类，让紧急推理任务可以暂时抢走训练算力。
第三个误区,搞混部就是单纯省卡钱，混跑真正的价值在于提升GPU资源利用率，减少闲置浪费，而不是用一张卡干两倍的活，如果两个任务都存在明显尖峰，混跑后尖峰会互相叠加，反而比单独跑更慢。
训练和推理混跑GPU资源分配常见问题解答
混跑时如何快速判断当前资源分配是否合理？
观察两个核心指标：推理服务的P99延迟是否存在周期性毛刺，以及训练任务的有效吞吐是否明显低于单跑基线，前者用Prometheus配合Grafana做分钟级监控，后者在训练日志里对比step time的均值，如果两个指标都在可接受范围，说明分配基本合理；如果只有一方达标，就要调整配额比例。
两张同型号显卡混跑和一张大卡用MIG切分，哪种训练推理混跑更划算？
两张卡方案的优势在于训练和推理各自独占一张,彻底无干涉，但推理负载低时，另一张卡的算力就浪费了，单卡MIG方案的优势在于可以动态调整切分比例，比如业务闲时给训练分配60%算力，忙时切回40%，利用率更灵活，总体来看，如果推理负载波动明显且显卡支持MIG，单卡切分更划算；如果推理流量稳定且对延迟极度敏感，两张卡更省心。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/788210.html
