GPU虚拟化是什么？为什么企业部署AI会用到它
一家公司买回第一台GPU服务器时，分配方式简单得很：哪个团队要训练模型，就把一张卡整个交给它。可几个月过去，申请开始扎堆撞车——算法团队想连着训两天，开发同学只要调试半小时就够，在线服务希望每天稳稳占住一部分显存，连虚拟机里的业务也来提GPU需求。
接下来很可能就会冒出这样一幕：
想用的人都在排队，可已经分出去的那些GPU，却经常并没有跑满；
把整张卡包给一个任务，边界是清楚了，颗粒却又太粗；
干脆让好几个任务同时上，利用率是提上来了，它们却可能互相抢显存、争计算时间，甚至被同一个故障一起拖下水。
GPU虚拟化和共享技术，在AI平台里要做的正是这件事：把一块物理GPU，变成可以分配、可以隔离、也可以管理的资源。 不过要提醒一句，"虚拟化"并不是某一种固定的切法。整卡直通、时间切片、MIG、vGPU、MPS，各自解决的是不同的问题——想真正理清它们，得从"资源边界"入手，而不是先去背一串技术名词。
同一间会议室，其实有三种分配思路
把一张GPU想成公司里最抢手的那间大会议室。最省事的安排，是整天包给一个团队，空间和设备全归它——这就接近整卡独占或者设备直通：性能和故障的边界都好说清楚，但这个团队中途不用的时候，别人也进不去。
申请一多，就可以改成按时间预约。A团队先用一会儿，然后换B团队，大家轮流使用整间屋子。这对应的是时间共享的直觉：分出去的是使用时间，并没有真把那间屋子砌墙隔成几间小房。
第三种办法，是拿实体墙隔出几个小房间。每间的面积和设备都固定，几个团队可以同时开工，彼此干扰更小——这就更像MIG这类硬件分区了。边界是稳了，可房型只能按预先定好的规格来划，临时想借用隔壁的空位，也没那么灵活。
企业部署AI时，很多GPU方案都可以先塞进这三种思路里看一看：整卡使用、按时间共享、按空间分区。心里先有了这三格，再去看具体的运行环境和隔离要求，那些技术名称就不会糊成一团了。
整卡独占并不落后，它给出的是最清楚的起点
公司的大模型训练几乎把一张GPU的显存占得满满当当，而且会长时间高负载地跑下去。对这种任务来说，整卡独占根本谈不上浪费：它能用满完整的计算和显存，不必提防邻居突然来抢，跑性能测试、定位问题也都更直接。
要是任务跑在虚拟机里，平台还能靠PCIe设备直通，把整张GPU交给某一台虚拟机。设备边界一清二楚，代价则是其余虚拟机再也碰不到这张卡。
学GPU资源管理，最好先把整卡分配弄明白，因为后面所有的共享方式，其实都在回答同一个问题：整卡用不满时剩下的那点空闲，能不能被利用起来，同时又不丢掉足够的性能、显存和故障边界？也正因如此，大型训练、把显存吃满的任务、要求严格的基准测试，最后往往还是会回到整卡这个起点。
时间切片能提利用率，却没把一张卡变成几张小卡
平台团队先把开发和测试这类任务，塞进一个时间共享池。在Kubernetes环境里，NVIDIA的设备插件可以把一张物理GPU对外"公布"成好几个可调度的副本，让不同的Pod轮流拿到GPU的执行时间。于是原本得排队的Notebook，现在能共用同一块设备了。
这里最容易踩坑。控制台上显示"8份GPU"，并不意味着底层真冒出了八张小卡，也不保证每一份都有固定的显存和八分之一的性能。NVIDIA GPU Operator的文档说得很直白：这种时间切片的副本之间，既没有显存隔离，也没有故障隔离。只要一个任务占了大量显存，或者出了严重异常，就可能连累其他共享者。
所以时间切片的价值，是把那些轻量任务的使用密度提上去，适合性能偶有波动也能接受、而且共享者彼此都在同一个信任范围里的开发测试场景。而它的边界正好提醒我们：学GPU共享，不能只盯着"能分成几份"，还得接着问下去——显存到底怎么分、性能可不可预期、真出了故障会波及谁。
MIG、vGPU和MPS，各自补上不同层面的能力
在线推理服务想要一块稳定的资源，不愿意跟开发任务去抢显存。于是平台会开始评估MIG。受支持的NVIDIA GPU，可以被切成若干个MIG实例，每个实例都握着专用的计算和显存资源，还在硬件层面提供了内存与故障隔离——比起普通的时间切片，它更容易给出一份明确的规格。
当然，这份确定性也要付代价。MIG只支持特定的GPU和预先定义好的分区组合，实例大小不能随手乱切，重新配置时还可能影响正在跑的任务。入门阶段，你需要抓住的是"硬件空间分区"这条思路就好；至于支持哪些型号、分区怎么配、又该如何调度，留到MIG专题里再慢慢学。
公司还有另一类应用是跑在虚拟机里的，需要让好几台虚拟机共用同一张物理GPU。vGPU工作在虚拟化管理程序这一层，给客户机递上一块虚拟的GPU设备，再由相应平台去管显存配额、地址空间和调度。有些兼容的组合，甚至能把vGPU建在MIG实例之上。不过它的具体能力，高度取决于GPU、虚拟化平台、驱动版本和许可证——所以那张支持矩阵，属于部署前必须单独核对的东西。
同一个团队手里可能还有几个CUDA进程，单独跑谁都喂不饱一张GPU，可它们又用不着虚拟机那种级别的隔离。这时候MPS能派上用场：它让这些进程更高效地共用同一块GPU，把内核执行和内存复制这些动作更好地重叠起来。要注意，MPS强调的是协作和利用率，不该被当成面向"互不信任的租户"的那种完整安全边界。
把这三样放回公司的场景，界限就清楚了：MIG关心的是硬件怎么分区，vGPU关心的是虚拟机怎么拿到GPU，MPS关心的是协作的进程怎么更有效地共用设备。它们有时能搭配着用，但根本就不在同一个层面上回答问题。
容器和虚拟机，并不会自动替你把GPU切开
有一个很常见的误会：应用都跑在不同的容器里了，那GPU是不是也就自然隔离开了？其实不然。容器能隔离进程、文件系统和一部分系统资源，可GPU到底怎么暴露、要不要共享、显存和故障的边界划在哪儿，仍然是由设备插件、驱动和具体的共享技术说了算。
虚拟机提供了更完整的操作系统边界，但同样不会自动把一张GPU拆成好几份。用整卡直通时，这张物理GPU仍旧只属于其中一台虚拟机；只有部署了兼容的vGPU或者MIG-backed vGPU之后，平台才谈得上按相应的边界去服务多台虚拟机。
所以往后学习，最好把两个问题分开来看：容器和虚拟机回答的是"应用在什么环境里运行"，而整卡、时间切片、MIG、vGPU、MPS回答的是"GPU以什么方式被看见、被共享、被隔离"。
企业真正要管的是边界，不是份数
公司把这几种方案摆到一起之后，关注点就不再是"谁能切出最多份"了，而是顺着一个个真实任务往下追问：它到底要多少显存，偶尔慢一点能不能忍，共享它的人彼此信不信得过，任务是跑在容器里还是虚拟机里，一旦出故障又允许波及多大范围。
正是这几个问题，把资源池慢慢分了开来：开发实验进那个允许波动的时间共享池，需要稳定资源的推理服务去评估MIG，虚拟机业务照着支持矩阵采用vGPU，大型训练则继续整卡独占。与此同时，平台还得盯着显存、利用率、排队时间、性能抖动和失败情况，才能真正判断：这样共享，到底有没有换来更多有效产出。
这就是GPU虚拟化在AI里的核心作用：它并不能凭空造出算力，而是帮平台在利用率、性能确定性和隔离之间，做出一个能管得住的取舍。
这条GPU虚拟化学习路线，可以怎么走
后续学习，不妨沿着"资源边界"一层层往里走：
从整卡和设备直通开始：先把最清楚的那套设备、显存和故障边界摸透。
再学时间共享：弄清"调度时间"和"物理资源分区"的区别，想明白为什么共享副本并不等于固定性能。
然后学MIG硬件分区：重点看实例规格、显存隔离、故障边界，以及重新配置的种种限制。
接着学vGPU与虚拟化平台：理解虚拟机、客户机驱动、支持矩阵和许可证，是怎样共同决定最终能力的。
再学MPS与协作进程：分清"提高并发效率"和"提供多租户隔离"是两个不同的目标。
最后进入平台治理：继续研究Kubernetes GPU调度、监控、计量、配额、拓扑，以及资源池该怎么设计。
走完这条线，等你再面对一个具体方案时，第一反应就会变成先问它提供了怎样的资源边界，而不再只是问"一张卡能显示成几份"。
接下来可以读什么
想从全局把资源关系理顺，可以先读算力资源总览；负责容器平台，就接着学Kubernetes GPU调度和时间切片；负责虚拟化环境，则该进入vGPU与支持矩阵的专题；要是更关心多任务的效率，那就继续研究MIG、MPS和拓扑感知调度。
站内关联阅读
参考资料
NVIDIA Multi-Instance GPU User Guide：https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/
NVIDIA GPU Operator, Time-Slicing GPUs in Kubernetes：https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html
NVIDIA Virtual GPU Documentation：https://docs.nvidia.com/vgpu/latest/
NVIDIA vGPU for Compute Overview：https://docs.nvidia.com/ai-enterprise/release-8/latest/infra-software/vgpu/overview.html
NVIDIA Multi-Process Service：https://docs.nvidia.com/deploy/mps/latest/index.html
Kubernetes, Schedule GPUs：https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/