另外開一篇
在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利用