多租户推理不能只按模型大小分配显卡：权重之外，激活值、KV 缓存、批处理和运行时工作区都会占用显存。GPU虚拟化切分技术与显存隔离配置，应先看任务的峰值显存和并发方式，再决定是硬件分区还是共享调度。切得过细可能导致显存不够，切得过粗则浪费资源。
先辨明三种共享方式的差别
MIG：硬件分区，适合需要强隔离的任务
在支持 MIG（Multi-Instance GPU）的 NVIDIA 加速卡上，可将一张卡划分为相互隔离的实例，各实例拥有指定的计算与显存资源。具体可选配置取决于显卡型号，A100、H100 等产品的支持情况和可用分区组合应以对应硬件文档为准。它适合多个租户需要相对稳定资源边界、且单个任务能装入某个分区的场景；代价是分区规格固定，零散余量不一定能被其他实例灵活利用。
时间片共享：提高利用率，但不是显存硬隔离
时间片共享让多个任务轮流使用计算资源，适合负载较轻、峰值错开的任务。它通常比固定分区灵活，但请求高峰时会互相争用计算时间。时间片本身不能等同于显存配额：一个进程申请过多显存，仍可能影响同卡任务或触发显存不足，因此不能把它当作强安全边界。
vGPU：按产品和软件栈核对支持条件
vGPU 可用于将加速器资源提供给虚拟机等环境，但具体能力与硬件、驱动、虚拟化平台及授权条件相关。若租户以虚拟机为隔离单位，需逐项核实兼容性和配置要求；若只是容器内多任务共享，不能仅因名称相似就认为容器获得了同等的显存硬隔离。
按负载确定分区，而不是按模型参数量估算
推理显存可粗分为模型权重、运行时开销、激活值和 KV 缓存。相同模型在不同输入长度、批大小和并发请求下，峰值可能差异明显。图像生成、长上下文问答和短文本分类也不应直接套用同一份切分表。
- 测峰值。在目标软件版本下，以预期最大输入长度、批大小和并发运行代表性请求；记录显存占用、延迟及显存溢出情况。只测空闲状态或单条短请求不足以定容量。
- 留余量。以实测峰值为基础选择分区。可先将约 10%–20% 的容量作为试运行余量，再通过压力测试调整；这只是起始参考，框架开销、缓存策略和并发波动都可能要求更多空间。
- 匹配隔离方式。硬隔离优先考虑支持的 MIG 配置；任务小且可接受性能波动时，可评估时间片共享；虚拟机租户则核对 vGPU 的平台条件。若任务峰值超过可用分区，不要靠降低监控阈值掩盖问题，应改用更大分区、减少并发或拆分任务。
- 落实调度约束。在 Kubernetes 等编排环境中，按实际启用的设备插件和分区方式暴露资源，并给租户设置明确的可见设备范围。容器的主机内存限制并不自动成为显存上限；还要确认不同租户不会被调度到本应独占的实例。
- 验收并观察。用接近峰值的请求做并发测试，检查显存占用、利用率、延迟和 OOM（显存不足）日志。上线后持续按租户或实例观察趋势，负载变化时重新评估分区，而非只在部署时测一次。
常见配置误区
把框架的显存预留或缓存设置当成硬配额，是常见误区：它们可影响单个进程的分配行为，却未必能阻止进程继续争用设备资源。另一个误区是只看平均占用。多租户服务需要关注峰值和并发叠加，特别是长输入带来的 KV 缓存增长。
因此，GPU虚拟化切分技术与显存隔离配置应形成“测峰值、选隔离、设余量、压测、持续观察”的闭环。若业务需要明确的显存边界，优先采用硬件支持的分区并验证租户间隔离；若目标是提高轻负载利用率，则可接受共享波动，但必须配套并发限制和监控。
常见问题
显存切分越小，资源利用率一定越高吗？
不一定。小分区可能放不下模型运行时开销或缓存，导致任务失败；应以峰值测量和请求特征判断。
时间片共享能限制每个容器的显存吗？
不能仅凭时间片实现显存硬隔离。需结合设备分区能力、软件栈及调度策略确认边界。
什么时候需要重新配置分区？
模型、输入长度、批大小、并发或运行环境发生变化，或监控显示峰值持续接近容量时，应重新压测并评估配置。
