多模型共享 GPU 时如何管理加载、驻留与淘汰？

面试时怎么答

多模型驻留是带显存预算和加载成本的缓存调度，不是简单 LRU。先拆权重、KV、工作区与安全余量，再说明热点常驻、冷模型放 Host/对象存储、共享基座的 Adapter 单独管理。常驻过多挤压并发，淘汰过快造成反复加载，因此需要水位和最小驻留时间。

可以这样答：

多模型共享 GPU 本质上是一个带显存预算和加载成本的缓存调度问题，不能只按 LRU 淘汰。把显存拆成权重、KV、工作区和安全余量；热点模型常驻，低频模型放 Host 或对象存储，可共享基座的 Adapter 单独管理。但常驻越多冷启动越少，却会压缩并发 KV；淘汰太积极又会反复加载。服务侧设置高低水位、最小驻留时间和请求合并，监控驻留命中率、加载 P95、每小时淘汰次数、Goodput 与 OOM。

核心回答

多模型服务要把模型仓库状态、主机缓存、GPU 驻留和流量就绪分开管理。热门且加载慢的模型常驻 GPU，温模型留在 CPU/本地盘，冷模型从远端仓库按需拉取；只有权重加载、内存分配、Warmup 和健康检查全部成功后，控制面才把新流量导向该实例。

显存不足时，淘汰决策不能只看 LRU，还要考虑模型大小、重载时间、请求热度、当前引用、SLO 和替代副本。正在处理请求的版本用引用计数保护；卸载和新加载需要预留峰值空间，避免先加载后切流时 OOM。

展开说明

状态机：Unavailable、Loading、Warming、Ready、Draining、Unloading、Failed，操作要幂等。
并发控制：同一模型的并发加载使用单航班/租约，避免多个副本同时下载造成 Thundering Herd。
版本切换：新旧版本短暂共存，先 Warmup 再原子切流；回滚版本在观察期内保留。
淘汰：优先无引用且重载成本低的冷模型，同时为紧急回退和 Workspace 留安全余量。
故障：仓库不可用时继续服务已驻留版本，并阻止“控制面错误”误卸载最后可用副本。

版本边界：Triton 的 NONE、EXPLICIT、POLL 等模型控制模式及限制以具体版本为准；通用 LLM 引擎可能不支持运行时完整模型卸载，或要求进程级重启释放内存。

工程实践

记录模型加载各阶段耗时、仓库与本地缓存命中、常驻显存、淘汰/抖动次数、冷请求 TTFT 和失败回退。用热点迁移、仓库断网、损坏权重、加载期间流量突增和连续版本发布做演练，确认不会出现反复装卸或零副本窗口。

常见追问

为什么简单 LRU 容易失效？ 一个近期未访问但加载需十分钟的大模型，可能比一个可秒级重载的小模型更值得保留；应把大小、加载成本和预测热度纳入评分。
模型 Ready 前为什么需要 Warmup？ 首次执行可能触发权重搬运、Kernel 选择、编译或 CUDA Graph Capture；不预热会把这些成本暴露给首批用户。
如何避免加载新模型时把旧模型挤掉后又失败？ 先做容量预留与完整性校验，在独立槽位加载并验证；只有新版本 Ready 后才 Drain 旧版本，否则保持旧服务。

一句话复习

多模型驻留是带版本的加载状态机和容量调度问题，淘汰要同时考虑热度、大小、重载成本、引用与回滚余量。

参考资料

官方文档：NVIDIA Triton Model Management