同一台服务器既跑模型训练，又接收在线推理请求，问题往往不是“资源够不够”，而是高负载训练会不会挤占推理所需的计算、显存和数据通道。设计训练与推理混合负载的计算资源隔离策略，建议先画出边界，再决定是否共享设备；不要一开始只靠调低训练优先级。
先区分两种负载的风险
训练通常以较长时间的连续计算和较高吞吐为目标，批量大小、数据读取速度都会影响资源占用。在线推理则更在意单个请求的响应时间，尤其是高分位延迟；即使平均延迟尚可，突发请求与训练争用也可能导致尾部请求变慢。批处理推理介于两者之间，通常能容忍更长的等待，但仍要设定任务完成时间。
因此，隔离目标要写成可检查的约束：推理服务的延迟目标和错误率、训练任务可用的设备范围、单个任务的显存上限，以及共享存储和网络的带宽边界。训练与推理混合负载的计算资源隔离策略不是单一开关，而是一组能互相补足的限制。
四层边界，按风险逐步选择
物理设备：边界清晰，成本也最高
将在线推理固定到一组 GPU，将训练放到另一组设备，是最容易理解的隔离方式。两类任务不会直接争用同一张卡，适合延迟目标严格、训练持续时间长，或共享时难以稳定复现性能的场景。缺点是空闲资源不容易互借，设备利用率可能下降。可以先按服务重要性划分设备池，再通过调度规则禁止训练作业进入推理池。
GPU 分区：适合受支持的设备与工作负载
NVIDIA MIG 可在支持该功能的部分 GPU 上把设备划分为多个实例，隔开一定范围的计算与显存资源；具体可用配置取决于 GPU 型号和设备配置，不能假设所有卡都支持相同分区。它比单纯共享一张卡更容易控制资源边界，但分区后可分配的组合会受限，训练任务也未必适合较小实例。上线前应分别验证推理模型能否装入分配的显存，以及训练吞吐是否仍满足需求。
软件共享：灵活，但不能当作硬隔离
CUDA MPS 可让多个进程共享 GPU 执行资源，适合需要提升并发利用率的场景；它不等同于物理隔离，也不能单独保证推理延迟。容器编排平台 Kubernetes 的命名空间和资源配额有助于管理作业，但仅设置配额并不自动隔离 GPU 性能。使用 Triton Inference Server 部署模型时，也应结合设备分配、实例并发和请求队列设置，而不是只看服务进程是否分开。
从空闲环境开始的落地步骤
- 记录基线。先单独运行推理服务，记录代表性请求下的吞吐、错误率及高分位延迟；再单独运行训练，观察设备显存和计算占用。测试输入、模型版本和并发条件要固定，便于比较。
- 选定隔离层级。延迟目标严格时优先物理分卡；设备支持且分区规格合适时评估 MIG；只有在能接受性能波动并具备监控时，再尝试共享调度。不要把进程优先级当成资源边界。
- 补齐主机与数据通道限制。为容器设定主机内存、处理器核数和进程数上限，并限制训练的数据加载并发。检查共享存储读写与网络传输是否会造成拥塞；GPU 分开了，数据通道仍可能互相影响。
- 混合压测并设回退条件。同时运行训练与推理，逐步增加训练负载，比较推理延迟和错误率是否越过预设目标。若超标，先减少训练并发或迁移训练任务；无法恢复稳定时，退回物理设备隔离。记录每次配置，避免只凭一次短测决定上线。
常见问题
训练任务设置低优先级就够了吗？
不够。优先级影响调度顺序，却未必能及时中断正在执行的计算，也不保证显存和数据通道有保留量。
MIG 和 CUDA MPS 应该怎么选？
MIG 偏向有明确设备分区边界的共享，前提是硬件支持且分区规格适合；MPS 更灵活，但性能隔离较弱。应按延迟风险和设备条件选择。
什么情况下必须分开 GPU？
当混合压测反复导致推理目标无法满足、资源峰值难以预测，或业务不能接受训练引起的延迟波动时，优先采用物理设备隔离。
上线后主要看哪些指标？
持续观察推理吞吐、错误率和高分位延迟，同时监控显存、设备利用率、主机内存及数据读写。训练与推理混合负载的计算资源隔离策略应随这些指标复核，而不是配置一次后长期不变。
