大模型推理的显存账算完之后，更难的问题来了：十个模型抢一张卡，怎么分？ GPU 共享调度是多模型团队的日常战场，把常见的四种策略和各自的坑摊开讲。
策略一：时分复用（最简单，最粗暴）
模型 A 用 5 分钟、模型 B 用 5 分钟——加载/卸载交替。坑在加载延迟：大模型冷启动要几十秒到几分钟，频繁切换的切换成本吞掉收益。适合场景：低频任务+大模型（每天跑几次的批处理），高频服务别用。
策略二：显存分区（静态配额）
把显存切成 N 块，每个模型驻留一块。稳定但浪费：配额按峰值定，低谷期大量显存闲置。适合场景：延迟敏感的常驻服务（在线 API），用空闲率换稳定性。优化方向：配额别拍脑袋，按一周的 P99 用量定。
策略三：统一池化（MPS/MIG 级共享）
用厂商的 GPU 分区能力（硬件级隔离）或 MPS（进程级共享）让多模型真正同时跑在一块卡上。隔离性和安全性的取舍：MPS 性能好但一个进程崩可能连累邻居；MIG 硬件隔离稳但分区粒度固定。适合场景：模型数量固定、信任度一致的企业内部。
策略四：抢占式调度（弹性优先）
高优任务可以抢占低优任务的显存，被抢的模型自动卸载、请求排队。吞吐最高，体验最不可控。适合场景：离线批处理集群（夜间跑评测/ embeddings），在线服务慎用。
混合是常态
生产环境很少用单一策略。我们见过的合理组合：常驻 API 用静态分区、批处理用时分复用、突发流量用池化兜底。调度器按「服务等级目标」路由——SLO 越高的模型分到越稳的策略。
三个共同的坑
- 碎片化：反复加载卸载后显存碎片化，总容量够但连续块不够——定期整卡重启排进维护窗口
- forget KV Cache：共享场景的 KV Cache 预算最容易被漏算，多模型叠加时爆显存的第一元凶
- 没有全局视图：每套模型自己管自己的监控，谁在吃卡查不清——先建统一 GPU 监控再谈调度
结语
GPU 共享调度的本质是延迟、吞吐、成本的三方博弈。没有最优解，只有「按 SLO 分层」的工程解。先建监控全局视图，再选策略组合——顺序反了，调了个寂寞。
