另外开一篇
在Docker/Container概念开始流行之前，多重环境同时执行的概念
从"模拟"，也就是用软件进行binary translation，这种只靠CPU进行软件运算的
环境
到"虚拟"，在原生硬件上建立多个"楚门的世界"，并且都享有原生硬件效能
到"函式库共用"，同指令集架构的软件，如果函式库相同，则直接引用
不须要再建立那么多楚门的世界
2013年开始的GPU虚拟化只是当时要兴起的硬件虚拟化浪潮其中一环
而且还吃力不讨好，因为要牵动从硬件层，韧体层到软件层全部的设计
2020年的安培架构资料中心产品A100，多重执行实体Multiple Instance GPU
某种程度上解决了对于硬件依赖性的虚拟化方案
试想一下，如果今天GPU装在一个还没支援PCI IOMMU的平台上
那GPU硬件虚拟化便无用武之地，例如ARM
而MIG的作法提供了简单的驱动程式层隔离，脱离对硬件虚拟化平台的依赖
MIG方案其实设计得很细，在不依赖硬件虚拟化的前提下，instance profile
把CUDA core数量，VRAM，硬件编解码单元的划分方式都考虑进去了
除了等分切割，还支援混和规模切割(例如切一个大一点的VRAM instance
然后把剩下的VRAM都用最小单位切割)
而且文中提到，这些instance可以各自执行不同变量类型的workload
FP32，BF16，FP64，TF32...
那vGPU呢?
这其实不太能跟MIG拿来比较，因为vGPU其实是作为虚拟桌面解决方案
的，他的设计是从远端桌面环境体验去设计的，而MIG仅能执行"运算"
更新说明虚拟化等级:
Host OS->最常见的使用情境，就是安装一个例如Windows 10/11，RHEL，SLES
Guest OS->虚拟机当中运行的OS
Hypervisor->虚拟机管理软件，用来沟通其下层的资源提供来源与虚拟机群
不论资源来源提供是原生硬件还是CPU进行软件模拟
Level 0虚拟化 -> 虚拟机管理员hypervisor直接控制硬件，没有预先安装
Host OS，hypervisor自己就是host OS，例如VMware ESXi，Citrix XenServer
Level 1虚拟化 -> 一开始的Host OS还在，但退化成虚拟机的角色作为
管理接口，改由hypervisor核心来控制硬件，开机一样会进原本的OS GUI
例如Hyper-V，SuSE Xen kernel，此时该虚拟机被定义为Parent
Level 2虚拟化 -> Host OS当中安装hypervisor，对硬件没有控制权，仅作为
一个应用程式来执行，例如VMware Workstation，Oracle Virtual Box
Parallels Desktop
原po的方案我想应该是level 0，虽然proxmox我没有接触过
vGPU的方案是在这环境下，hypervisor(此处为proxmox)透过驱动程式
控制GPU，并且利用驱动程式提供的功能建立vGPU
这个vGPU是一种"子项目"，"子分支"，大概是这样的概念
vGPU可以提供1/1到1/n(n视该卡型号提供的分割而定)GPU硬件的效能
并且占用PCI bus形成硬件通道，让guest OS可以使用
上面提到的控制权是一个很重要的点
Host OS上了驱动程式，则Host OS核心可以透过驱动程控该硬件
其他OS核心无法控制，在虚拟化环境中则是
Hypervisor控制了GPU，因此guest OS无法直接控制GPU，顶多只能透过
软件来"分"一些GPU效能
如果希望要guest OS群都能享受原生硬件存取，免去软件转译的效能耗损
1. Passthrough
叫hypervisor不要用，不上驱动程式，并且设定为passthrough
成为等待指派的资源，接着guest OS来占用，带着这张硬件开机
然后guest OS得到这张硬件，比照host OS方式安装驱动，享受该卡全部
硬件效能，但也因此当要调度硬件时，必须要先关虚拟机，造成downtime
2. SR-IOV
GPU卡建立一些硬件通道，让这些硬件通道分布在PCI bus上
guest OS可以占用这些硬件通道，虽然只能得到1/n的GPU效能
但在需要调度效能的时候，因为hypervisor控制硬件，所以不会受限
于任何guest OS独占，只要GPU还有剩余可调度效能，随时可以变换规划
由于proxmox不是NVIDIA支援项目，所以我猜proxmox是设计成直接读取
给其他hypervisor用的驱动程式，例如VMware ESXi
但因为可能有license锁，所以可能要花时间去改动一些细节才能
让proxmox利用