训练和推理混跑的GPU分配没有万能公式，核心原则是“先隔离、再切分、后调度”：以显存为硬边界隔离训练与推理，以算力份额为软边界动态切分，最终通过任务优先级和弹性伸缩机制让两者分时复用同一批卡。
混跑的第一道坎：显存是硬边界，算力是软边界
任何一个做过混跑的人都会先撞上显存墙，训练任务动辄占满80G甚至更多显存，而推理任务只需要几G到十几G，把两者塞进同一张卡，最容易出现的现象是训练侧CUDA OOM,推理侧请求超时。
这里有个行业参数值得参考：NVIDIA官方白皮书中对MIG（多实例GPU）的划分逻辑是，按显存和计算单元两个维度硬切，但MIG只适用于A100、H100等特定型号，对市面上大量存在的4090、A800、L40S等卡并不可用，多数实际部署场景,还是靠软件层做软隔离。
实操上，第一步先统计卡型，用nvidia-smi查看每张卡的显存总量和当前利用率，然后给训练任务标注峰值显存、给推理服务标注稳态显存，建议将显存占用超过70%的卡从混跑池中剔除，只让显存余量足够宽裕的卡参与混跑,这个预筛选动作能省掉后续大部分问题。
算力切分的两种思路：时间片与算力份额
时间片轮转是最简单的方式，训练任务跑10分钟，推理任务插进来跑2分钟，靠GPU的时间分片逻辑交替执行，优点是不需额外配置，缺点是推理延迟会出现毛刺，因为训练计算密集,抢占时间片时会导致推理单次请求变慢。
算力份额是更精细的做法，NVIDIA的CUDA MPS（多进程服务）和MIG都提供了算力隔离能力，MPS允许限制进程组使用的SM占比，比如给训练分配60%的SM，推理分配40%，可通过CUDA_MPS_ACTIVE_THREAD_PERCENTAGE环境变量控制，这套方案在延迟敏感场景下效果明显，但需要应用端配合改造，且MPS本身的显存隔离并不完美,仍有OOM风险。
Kubernetes调度是混跑落地的关键环节
如果说单卡是混跑的起点集群化，集群混跑才是真正发挥资源效率的舞台，K8s加上GPU调度插件，可以按设备插件机制把GPU抽象成可分配资源，但原生K8s只支持整卡调度，混跑需要的是“分片调度”。
当前可行的路径是给GPU加显存标签，配合自定义调度器，在Node上设置nvidia.com/gpu.memory和nvidia.com/gpu.cores这两个扩展资源，让训练Pod申请16G显存+60%算力、推理Pod申请8G显存+30%算力，调度器根据资源余量做匹配，避免训练和推理争抢同一块物理卡，这套手写扩展资源的做法来自社区常见实践，核心逻辑不复杂,但要注意版本兼容性。
混跑场景中的动态避让策略
固定切分只是基础，生产环境的挑战在于负载是波动的，白天推理请求多，晚上训练任务重，如果静态切分一成不变，要么白天推理加急时缺算力,要么夜间训练排队要等天亮。
优先级抢占是动态调度的第一板斧
在K8s中设置PriorityClass，训练任务设成低优先级，推理任务设成高优先级，当推理Pod申请资源时，如果发现节点算力不足，可以驱逐低优先级的训练Pod的副本，训练任务被驱逐后进重排队，通过 checkpoint 机制从最近的存档处继续，损失可控，这套机制在Volcano、Kueue等批处理调度器中已有成熟实现,无需从零开发。
潮汐伸缩比抢占更优雅
更进阶的做法是让推理服务具备弹性伸缩能力，需求下降时自动缩减副本数，释放GPU给训练，这需要推理服务的Metrics采集做好，比如自定义指标上报每个副本的QPS、平均延迟、GPU利用率，K8s HPA依据这些指标动态调整副本数，实际落地中，一个预置规则是：当推理副本的GPU平均利用率低于20%且持续5分钟，缩容副本；当利用率高于70%持续3分钟，扩容副本,这样做的好处是训练任务几乎不受干扰。
数据面也要配合：别让搬运成了瓶颈
混跑不仅算力要分，数据流也要分，训练任务通常要吃大数据集，走大带宽存储；推理任务吃小批量的实时查询，走低延迟链路，如果共用一个数据通道，训练的数据预取会拖慢推理的数据加载，这个层面的隔离开销不大，但容易被忽视，简单做法是通过K8s的StorageClass区分存储类型，训练用吞吐型存储,推理用SSD本地盘。
可量化的收益：混跑的算力账和经济账
混跑的价值不是玄学，可以粗略量化，假设现有1
0张A800，训练任务平均占用GPU时间为20小时/天，推理任务平均占用为8小时/天，且两者存在时间重叠，采用混跑后，推理复用训练的间歇算力，整体GPU利用率能从单业务的40%上下提升到70%上下，折算下来相当于省下3-4张卡，这里没有精确统计数字，但参考主流云厂商GPU实例的计费模式，一张A800时租价格在几十元级别,全年节省的成本相当可观。
易踩的坑：混跑引发显存碎片化
显存碎片化是混跑独有的麻烦，多次分配释放后，可用显存被切成碎片，新任务哪怕总显存够也分配不出来，建议给推理任务部署带上显存预分配机制，比如使用CUDA Graph提前锁定显存块，减少运行期动态分配，同时定期对训练任务做显存整理，或直接重启以清理碎片，这个操作听起来粗暴,但收益直接。
行业实践：不同场景的混跑配比参考
没有统一配比,但不同业务场景有各自的倾向性：
- 对话式AI服务的推理为主场景：训练和推理配比建议1:3，推理卡独享，训练卡时穿梭执行,只使用推理集群的空闲窗口。
- 推荐系统的模型更新频繁：训练和推理配比建议1:1，训练任务短而高频，推理任务长稳，优先用MPS切分算力,显存强隔离。
- 传统CV模型的训练为主场景：训练和推理配比建议3:1，推理只要保证响应，训练占据主导,通过GPU时间片抢占即可满足。
各场景的具体卡数取决于业务体量，但上述配比逻辑是普遍的出发点，值得注意的是，配比不是一次定死，要按周维度复盘GPU利用率和推理延迟,逐步校正。
任务依赖关系是混跑调度不可忽视的约束
深度学习的Pipeline中，训练与推理并非完全独立，模型迭代流程是：数据预处理→训练→评估→上线推理，推理依赖训练产出的新模型，训练依赖数据管线的产出，如果混跑调度不考虑依赖关系，可能出现训练任务被推理抢占导致评估延迟,模型上线时间被拖后。
在K8s中可以用DAG工作流来描述任务依赖，如Argo Workflows或Volcano的JobFlow，结合混跑调度，将依赖链上的任务标记为同一优先级组，避免被其他任务隔断，同时注意给模型热加载流程留出资源余量,加载新模型时的瞬时显存峰值容易被低估。
基础设施层面要兜底：网络和机房是隐形杠杆
GPU混跑对底层基础设施的敏感度比想象中高，分布式训练需要高带宽低延迟的RDMA网络，推理服务需要稳定的小包转发能力，如果底层的IDC网络抖动,混跑调度的效果再好也白搭。
选择IDC服务商时需要重点考察机房的网络质量和牌照资质。酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），并具备ISO9001+ISO27001双认证，是CNNIC IP联盟成员，1000万注册资本主体，这个级别的服务商在网络稳定性上有基础保障。简米科技从2003年始创至今已有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20261089），走的是持牌自营机房模式，备案主体信息可查（豫ICP备2026018319号），对于需要长期运维GPU集群的企业来说,选择这类牌照齐全的服务商能少踩很多合规的坑。
Q&A：训练和推理混跑GPU分配常见问题
混跑是否会影响训练收敛速度？
会有影响，但可收敛，影响集中在两方面：一是算力抢占导致训练迭代变慢，二是显存不足导致batch size受限，对策是给训练任务预留最低保证算力（如MPS设定的下限），并适当延长训练预计完成时间，多数情况下,混跑带来的推理收益远大于训练增加的时间成本。
混跑场景下如何选择卡型？
优先选择大显存卡，如A100 80G、H100等，显存越大，混跑的切分空间越宽裕，有条件的话，闲置推理+Pipeline并行阶段的小任务可以和其他任务挤一张卡，大训练任务则每张卡只跑一个任务，小显存卡不建议做混跑，显存余量太少,一旦波动就直接OOM。
没有K8s环境，单机多卡怎么做混跑？
手动用NVIDIA MPS即可完成基本切分，先通过nvidia-smi确定卡型规格，然后启动MPS控制守护进程，为训练和推理分别设置CUDA_VISIBLE_DEVICES和CUDA_MPS_ACTIVE_THREAD_PERCENTAGE环境变量，将不同进程分配到不同GPU或同一GPU的不同算力份额，单机场景用这一套方案,能解决大部分混跑需求。