多模型并发部署如何做GPU资源隔离

先给结论：先选隔离等级，再选调度方式

多模型并发部署时，只用 CUDA_VISIBLE_DEVICES 分配GPU编号，只能限制进程看到哪些卡，不能在同一物理GPU内形成强计算和显存隔离。企业应根据租户边界、延迟稳定性、模型显存和故障影响，在整卡独占、MIG硬件分区、容器绑卡和时间共享之间选择。

GPU隔离要同时看六个维度

• 可见性：容器或进程能看到哪些GPU或GPU实例。
• 显存：一个服务的权重、KV Cache和工作区是否会挤占另一个服务。
• 计算：长上下文或大批处理请求是否会导致其他模型延迟抖动。
• 带宽：显存带宽、PCIe、NVLink或NIC是否被多个实例共享。
• 故障域：单个进程OOM、驱动异常或GPU复位会影响多大范围。
• 服务等级：是否能分别保护在线低延迟、批处理和开发测试队列。

四种常见隔离路径怎么选

六步完成多模型资源规划

1. 建立模型清单：记录权重版本、精度、最大上下文、并发和峰值显存。
2. 分类服务等级：将在线、离线、开发和应急服务放入不同队列。
3. 选隔离单元：优先用整卡或MIG实例形成边界，再考虑同卡共享。
4. 设置准入与预留：为权重、KV Cache、图捕获和运行时工作区保留空间。
5. 实施路由和限流：按模型、租户和优先级分配请求，对队列长度和最大并发设置边界。
6. 做干扰测试：同时施加长上下文、大批处理和异常退出，检查其他服务的延迟与可用性。

PoC必须验收哪些项

把模型资源需求写成准入台账

隔离方案不能只记录“占几张卡”。每个模型至少要登记权重版本、加载精度、最大上下文、目标并发、KV Cache上限、峰值工作区、冷启动时长和可接受的重启范围。台账应区分常驻显存与随请求变化的显存，并为运行时预留余量；余量不是固定百分比，应通过目标框架和真实请求分布测得。

MIG在受支持的GPU上把计算和显存资源划分为GPU实例，适合需要更清晰资源与故障边界的场景；是否可用取决于GPU型号、驱动与实例配置，不能把“MIG”写成适用于所有GPU的通用开关。

Kubernetes通过设备插件把GPU等扩展资源交给调度器，资源请求通常必须写在limits中。它解决的是设备分配入口，不自动解决同一设备内的显存配额、请求优先级和业务SLA。

用干扰包络线决定能不能共享

先分别测每个模型的单独基线，再让背景模型制造三类压力：持续解码、长提示词预填充和模型加载。比较前台服务的TTFT、TPOT、失败率和队列等待时间。如果尾延迟越过业务阈值，应降低共享密度、拆分队列或改用更强隔离；不能只看平均GPU利用率。

框架的数据并行可以复制模型并把请求路由到多个实例，但数据并行规模、节点布局和外部负载均衡仍需单独设计。它是扩展服务能力的方法，不等同于同一GPU内的硬隔离。

隔离配置也要纳入变更控制

GPU实例配置、驱动、容器镜像、框架参数或模型上下文上限变化后，应重跑显存上限与互扰测试。生产配置应保存设备映射、实例标识、路由规则和回退版本，避免故障后以不同切分方式恢复。

赋创可以提供哪些支持

赋创可从AI算力基础设施和系统工程角度，协助完成GPU服务器选型、MIG或整卡资源规划、容器环境部署、推理框架安装、监控接入和同条件干扰测试。

赋创可协助搭建测试环境、执行测试并记录结果，具体模型质量指标、业务回归数据集和上线标准由客户算法或业务团队确认。

常见问题

CUDA_VISIBLE_DEVICES能否限制单个服务的显存用量？

不能把它当成硬显存配额。它主要控制进程的GPU可见性。同一物理GPU上的多个进程仍可能竞争显存和计算资源。

MIG是否适合所有NVIDIA GPU？

不是。MIG只适用于官方支持的GPU、驱动和配置组合。截至2026-07-17，部署前仍应查看NVIDIA MIG支持表和目标平台文档。

GPU时间共享能否用于严格低延迟服务？

可以进行PoC，但不应在没有干扰测试的情况下直接用于严格SLA。时间共享不等于独立显存、带宽和故障域。

资源隔离台账的交付边界

最终交付物应能回答三个问题：每个模型拿到什么资源、超出额度时系统怎样处理、单个实例故障会影响谁。模型效果和业务SLA由客户确认；赋创可协助服务器、资源切分、编排、监控和干扰测试环境的配置与记录。