GPU虚拟化原理要同时理解显存、计算单元、驱动、隔离和调度。能不能切分，不只取决于软件，还取决于硬件能力和业务负载。
机制边界：显存可切分不代表性能可预测，虚拟化方案必须同时验证邻居任务影响。
GPU虚拟化要先问“切的是什么”
GPU虚拟化原理不能只用“把一张卡切成多张卡”解释。不同方案切分的对象不同：可能是显存容量、计算时间片、硬件实例、驱动上下文，也可能只是调度层的使用时间。
切分对象不同，隔离强度、性能稳定性和适用负载就不同。训练、推理、开发调试和图形桌面不能用同一套判断。
显存切分相对直观，但性能不一定等比例
显存上限可以通过MIG、vGPU配置或软件策略限制，让任务看到固定容量。这样能减少单个任务占满整卡的风险。
但计算单元、缓存、带宽和驱动队列并不总能按同样比例切开。某些方案能限制显存，却不能保证延迟和吞吐稳定；某些方案隔离更强，但要求特定硬件型号和驱动支持。
分时共享适合轻量负载，MIG更强调硬件隔离
分时共享通过时间片让多个任务轮流使用GPU，适合开发、测试、小模型推理或不敏感任务。它部署灵活，但性能可预测性相对弱。
MIG把支持的GPU切成多个硬件实例，显存和计算资源隔离更清晰，适合多租户推理和资源碎片利用。它的限制是依赖特定NVIDIA GPU型号，并且实例规格不是任意切分。
调度层负责分配，不能替代底层隔离
调度系统可以决定任务去哪张卡、何时运行、是否排队和是否抢占，但它不能凭空提供硬件隔离。隔离能力来自驱动、硬件、运行时和虚拟化层。
| 问题 | 需要看的层级 | 验收方式 |
| 显存是否超用 | 虚拟化/运行时 | 显存上限和失败行为 |
| 性能是否抖动 | 硬件/驱动/邻居任务 | 并发压测和延迟曲线 |
| 租户是否隔离 | 权限/设备/命名空间 | 访问控制和日志审计 |
| 调度是否公平 | 调度层 | 队列、配额和抢占记录 |
不同切分方式对应不同失败模式
分时共享失败时，常见表现是延迟抖动、吞吐下降或邻居任务影响；显存限制失败时，常见表现是任务启动失败、OOM或模型加载不完整；MIG配置失败时，常见表现是实例规格不匹配、设备不可见或调度资源名错误。
理解这些失败模式，有助于排查时少走弯路。看到任务慢，不一定是调度器问题；看到设备不可见，也不一定是Kubernetes问题，可能发生在驱动或硬件实例层。
显存切分要结合模型和批量大小评估
推理任务的显存需求受模型大小、batch size、并发和上下文长度影响。训练任务还要考虑优化器状态、梯度、激活值和检查点。只按模型参数估算显存，容易低估真实需求。
因此，GPU虚拟化方案验收时应使用真实模型和真实输入，而不是只运行简单样例。样例能验证设备可用，不能验证生产容量。
算力切分还要看邻居任务影响
当多个任务共享同一张GPU时，一个任务的显存访问、计算负载或IO行为可能影响另一个任务。对于在线推理，这种影响会表现为尾延迟升高；对于训练任务，则可能表现为吞吐下降和训练时间不可预测。
如果业务需要稳定SLA，应优先采用隔离更强的方案，或为关键任务保留整卡。共享适合提升利用率，但不应牺牲关键业务的稳定性。
验收时要把隔离证据写成可复查记录
GPU虚拟化方案上线前，应把隔离证据写成记录，而不是只凭经验判断。显存上限是否生效，任务能否越界访问设备，邻居任务是否影响延迟，驱动异常是否会扩大影响面，日志是否能追踪到租户和任务，这些都应有测试结果。
对于AI平台团队来说，这些证据比架构描述更重要。出现故障时，可以根据证据判断问题发生在硬件实例、驱动、容器运行时、调度层还是应用框架。
不同业务负载要建立不同虚拟化策略
开发调试更看重资源可得性，允许一定性能波动；在线推理更看重稳定延迟和隔离；训练任务更看重长时间吞吐和跨卡通信。三类负载如果都使用同一种GPU虚拟化策略，必然会在某些场景下失衡。
建议平台把负载类型写进资源申请流程。申请人选择训练、推理或调试，平台再匹配整卡、MIG、分时或队列策略，而不是让用户自己猜应该申请哪种资源。
监控指标要能解释“为什么慢”
GPU虚拟化上线后，用户最常反馈的问题不是“能不能运行”，而是“为什么变慢”。平台需要把显存、GPU利用率、SM占用、任务排队、邻居任务、容器重启、驱动错误和业务延迟关联起来。
如果监控只能看到GPU平均利用率，就很难解释性能抖动。建议在试点阶段就建立任务级指标和租户级指标，让后续排查能从业务任务追到虚拟化资源。
可以继续阅读 AI基础设施分类 ，把本文主题放回企业云原生平台、AI算力调度和基础设施演进路径中继续评估。
SAQ：GPU虚拟化原理常见问题
GPU虚拟化能把一张卡任意切成多份吗？
不能。切分方式受硬件、驱动和方案限制。尤其是MIG类硬件切分有固定规格，软件分时共享也不能保证所有负载都稳定。
落到团队评审时，建议用一个真实AI工作负载验证资源申请、调度、数据访问、监控、故障恢复和成本归集。这样能判断方案是只在实验环境可用，还是具备进入多团队共享和生产运行的基础。对于关键训练或推理任务，还要额外验证性能波动和隔离边界。
如果进入正式POC，还应把GPU型号、驱动版本、任务样本、监控指标和失败处理写进验收记录，避免只凭一次演示判断生产可用性。
显存隔离是否等于性能隔离？
不等于。显存可控只能说明容量边界清楚，计算、带宽、缓存和IO仍可能竞争。生产验收应同时看性能和错误日志。
落到团队评审时，建议用一个真实AI工作负载验证资源申请、调度、数据访问、监控、故障恢复和成本归集。这样能判断方案是只在实验环境可用，还是具备进入多团队共享和生产运行的基础。对于关键训练或推理任务，还要额外验证性能波动和隔离边界。
如果进入正式POC，还应把GPU型号、驱动版本、任务样本、监控指标和失败处理写进验收记录，避免只凭一次演示判断生产可用性。
GPU虚拟化适合大模型训练吗？
大模型训练通常更依赖整卡、跨卡通信和稳定性能。虚拟化更常用于开发调试、小模型推理和多租户共享，关键训练任务要谨慎评估。
落到团队评审时，建议用一个真实AI工作负载验证资源申请、调度、数据访问、监控、故障恢复和成本归集。这样能判断方案是只在实验环境可用，还是具备进入多团队共享和生产运行的基础。对于关键训练或推理任务，还要额外验证性能波动和隔离边界。
如果进入正式POC，还应把GPU型号、驱动版本、任务样本、监控指标和失败处理写进验收记录，避免只凭一次演示判断生产可用性。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/717/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
