個人結論：硬體等 Intel Panther Lake；軟體等 Ubuntu 25.10 用的 kernel（沒意外的話是 6.17 版）進 Proxmox VE，用支援 SR-IOV 的 Xe kernel driver。
需求#
用 VM 跑 HAOS，裝 Frigate Add-on 做 object detection，希望能夠硬體加速。
我知道用 container 就不用 passthrough，但 HA 用 container 不如 VM 好管，PVE container 也不是用 Docker 是用 LXC。
硬體#
其實原本也沒想說一定要跑 VM，但專機專用就要夠小，那就得是 SBC。
SBC 的話逼自己不帶偏見重新評估了 Jetson，可惜 NVIDIA 還是死性不改，沒在做 upstreaming，變相強迫大家用 JetPack，好好的硬體過幾年官方就放棄軟體支援（看看那可憐的 Jetson Nano），HAOS 又沒 image，出局。
給 Rockchip SoC 的 HAOS images 裡面似乎也沒有包 RKNPU driver，出局。
最後還是回到 x86 最安全。都用 x86 機器了，效能夠乾脆多跑一些服務，可以在 VM 裡面利用 GPU 的資源就變得重要。
把 GPU 資源 passthrough 進 VM 又有 full（passthrough 整個 iGPU）跟 SR-IOV（passthrough vGPU）兩條路線可選。後面研究了一下，感覺 SR-IOV 是比較優雅的解法。
AMD 的 iGPU 看起來目前都不支援 SR-IOV。lspci 就沒有看到 SR-IOV 的 Capability，所以應該是硬體就不帶這個 PCIe Extended Capability ID，就不用看 driver 支援了。
這裡順便抱怨一下 AMD。常常硬體開賣 driver 還沒 ready 就算了，好不容易等到 driver，下載還要登入是怎樣？如果連 NVIDIA 的東西都可以免帳號下載，你還有什麼理由要大家非得登入同意一堆條款？真有 bad actor 你這樣最好是擋得住！這門檻除了給法務虛幻的安全感之外，只會帶給用戶跟開發者麻煩。加油，好嗎？
Intel 的 iGPU 似乎從 Tiger Lake 開始硬體就有做 SR-IOV，不過 driver 部份要注意，下面再補細節。
Full Passthrough#
優點是 VM 會可以用實體輸出（通常是玩遊戲？純運算的話無接螢幕需求），缺點是麻煩，且只有一台 VM 能用。
麻煩的點在於需要有 OpROM 給 iGPU 重做 initialization，如果不想用難以驗證內容（網路上這類東西通常是第三方做的，怕有安全問題）的現成 binary blob，就得自己做，步驟如下：
- 從主機板的 UEFI firmware 抽 iGPU 的 DXE Driver
- 用 UEFITool 搜尋
Intel(R) GOP Driver可以找到
- 用 UEFITool 搜尋
- 用 EDK II 編譯其他搭配的 EFI 並組合
這裡還是列一下關鍵的參考資料：
- Intel Graphics Device (IGD) assignment with vfio-pci
- VfioIgdPkg - EFI drivers supporting IGD passthrough
SR-IOV (vGPU)#
用這個可以把 iGPU 切成多個 vGPU 給多台 VM 用。
但目前大部分的 Intel iGPU 在 mainline kernel 裡並沒有開啟 SR-IOV 的支援，必須用 DKMS 裝 out-of-tree driver。
Intel 自己有出，這裡有寫這個版本的 driver 才有 SR-IOV 支援。
美中不足的是支援的 distros 有限，實測過無法直接套用到 PVE。
所以最簡單的方法可能還是用 mainline。
Intel 現在在 mainline 裡有兩套 driver：舊的 i915 跟重新設計的 xe。兩者支援的硬體有重疊，目前多數硬體預設用 i915，只有少數較新的硬體才會預設用 xe。
在新的 mainline Xe driver 裡面有實作 SR-IOV 的支援，Panther Lake 有開。
因為 PVE 用的是 Ubuntu-based kernel，所以大概要等到 Ubuntu 25.10 出才會包到上面提的 commit。
期待 Intel 可以早日在 xe 啟用 Alder Lake 的 SR-IOV 支援，這樣那些用 N-series 的 mini PC 就有更多東西可以玩了。