R9700 Proxmox VE 懶人部署兩週運行心得
會開始組這台機器，其實是因為 Mac 不夠用了。
M4 Max 很強，跑 MLX 模型也不是不能用。但真的拿來當本地 LLM、ComfyUI 生圖、模型測試的主力，還是會覺得慢。尤其開始試不同模型、不同 runtime、不同 workflow 之後，就會發現筆電再強也還是筆電。它適合工作，不適合被我整天拿來折磨。
所以這台機器一開始的目標其實很雜：
- 本地 LLM
- ComfyUI
- 學 Proxmox
- 取代一部分雲端服務
- 給同事或朋友使用
- 測 AMD AI 生態
- 順便保留一顆獨立 Windows 11 碟玩星際公民
這聽起來很貪心，但 Home Lab 本來就是這樣長出來的。
一開始有考慮過 MINISFORUM MS-S1 Max AI Max+ 395，但現在價格已經到 HK$29,999.00，我覺得不太值得。最後還是回到自己組一台比較彈性。
會選 Proxmox VE，是因為我想把這些東西隔開。ROCm、vLLM、llama.cpp、ComfyUI 都不算穩定，R9700 / RDNA4 又還偏新。與其全部裝在同一個 Linux 裡，壞一次就整台重來，不如讓 PVE host 只負責虛擬化、網路、NFS 和 GPU passthrough。
真正會亂裝套件、會踩坑的東西，全部放進 VM。這樣壞了可以重建，設定檔也比較容易復用。
實際上的安裝大概只花了一個晚上就完成，config.yaml 靠 git sync ，後續的話就把常用的指令寫成 skill 讓 claude code 自己 ssh 進去玩 XD
跑了兩週後，我現在的感覺是：這個方向是對的，但很多地方還在調。
硬體規格
太細的 BIOS、PCI ID、實測頻率網路上已經很多資料，這裡只放跟這套 Lab 有關的零件。
成本大概台幣 13萬上下....
| 項目 | 品牌 | 規格 |
|---|---|---|
| 主機板 | ASUS | ProArt B850-CREATOR WIFI NEO |
| CPU | AMD | Ryzen 9 9950X3D，16C / 32T |
| CPU FAN | DeepCool Digital | ASSASSIN IV VC VISION |
| FAN | Noctua | 12" PWA、14" FN |
| 記憶體 | Kingston | DDR5 64GB，32GB x 2 |
| 顯示卡 | AMD | Radeon AI PRO R9700 |
| 有線網路 | Realtek | RTL8126 5GbE x 2 |
| 無線網路 | Realtek | RTL8922AE Wi-Fi 7 / 802.11be |
| 系統碟 | Crucial / Micron | T500 NVMe SSD，約 2TB |
| 資料碟 | Samsung | 980 / PM9A1 類 NVMe SSD，約 477GB |
| Windows 系統碟 | Predator / Biwin | NVMe SSD，約 1TB，獨立 Windows 11 系統，主要用途：星際公民 |
| 電源 | NZXT | 1500W |
| Case | Cooler Master | QUBE 540 |
9950X3D 對 Proxmox 很舒服，16C / 32T 可以切給幾台 VM，還不會一下就見底。
R9700 是這台的重點，32GB VRAM 剛好能跑 26B/27B 量化模型，也能測 MoE、小模型、GGUF，還可以跑星際公民。
64GB RAM 是目前比較明顯的瓶頸(但真的太貴了）。不是不能用，是你會需要小心分配：VM 100 給 36GB，VM
103 給 36GB，gateway 再拿一些，host 自己也要留。下一個升級我大概會先補記憶體...如果有降價
軟體規格
| 項目 | 版本 / 狀態 |
|---|---|
| Hostname | pve |
| OS | Debian GNU/Linux 13 trixie |
| Proxmox VE | 9.2.0 |
| PVE Manager | 9.2.2 |
| Kernel | Linux 7.0.2-6-pve |
| QEMU/KVM | pve-qemu-kvm 11.0.0-3 |
| QEMU Server | qemu-server 9.1.15 |
| LXC | lxc-pve 7.0.0-2 |
| ZFS utils | zfsutils-linux 2.4.2-pve1 |
| Backup Client | proxmox-backup-client 4.2.0-1 |
| Web UI | https://<pve-ip>:8006/ |
| SSH | 內網 SSH 管理 |
PVE host 我盡量保持乾淨。這裡的「乾淨」不是什麼都不裝，而是不把 AI/GPU 推理 stack 裝在 host 上。GPU driver、ROCm、vLLM、llama.cpp、ComfyUI 這些容易互相影響的東西都放 VM 裡；host 只保留跟硬體、網路、儲存和維運直接相關的工具。
目前 host 上額外安裝或啟用的東西大概是這些：
| 項目 | 內容 | 用途 |
|---|---|---|
| 主機板風扇控制 | fan-controller.service、/usr/local/bin/fan-controller.sh、nct6775 |
控制 ASUS ProArt B850 的機箱/CPU 風扇曲線 |
| DeepCool Digital | deepcool-digital.service、deepcool-digital-linux |
DeepCool ASSASSIN IV VC VISION 顯示/控制 |
| lm-sensors / fancontrol | lm-sensors、fancontrol、/etc/fancontrol、/etc/sensors3.conf |
感測器讀值與風扇控制基礎 |
| NFS Server | nfs-kernel-server、/etc/exports |
匯出 /mnt/ai-shared、/mnt/media-shared 給 VM 使用 |
| Tailscale | tailscaled.service |
遠端維運與 subnet route |
| iperf3 | iperf3.service |
測試區網吞吐量 |
| smartmontools | smartmontools.service |
SSD / NVMe 健康狀態監控 |
風扇控制是 host 上比較特別的一塊，因為它必須直接碰主機板 Super I/O 和實體風扇。現在的邏輯是：感測器讀取失敗就全速、CPU 高溫就全速、平常依照溫度線性調速。這部分放在 VM 裡反而不合理。
整體架構
PVE host (`<pve-ip>`)
├── NFS server → /mnt/ai-shared (500GB, models / data / docs)
├── ubuntu-lab VM 100 (`<lab-vm-ip>`)
│ ├── R9700 passthrough
│ ├── rootful podman
│ ├── vLLM toolbox / ROCm / TheRock
│ └── llama.cpp toolbox / GGUF models
├── gateway VM 101 (`<gateway-vm-ip>`)
│ ├── Cloudflare Tunnel
│ ├── Homepage / Uptime Kuma / LiteLLM / Open WebUI
│ └── docker compose stack
└── lab-colleague VM 103 (`<comfyui-vm-ip>`)
└── ComfyUI 工作機，與 VM 100 輪流使用同一張 R9700
我現在最喜歡這個架構的地方，是每個角色都很清楚。PVE 管底層，VM 100 跑 LLM，VM 103 跑 ComfyUI，VM 101 管對外入口。哪一塊壞了，就處理哪一塊。
目前比較大的限制是：這台主機只有一張 R9700，而且這張卡是用 PVE 的 GPU passthrough 直通給 VM。直通的意思是，這張實體顯卡在同一時間只能交給一台 VM 使用，不像 CPU/RAM 那樣可以同時切給多台 VM。也因為這樣，VM 100 和 VM 103 必須輪流開：要跑 LLM 就開 VM 100；要跑 ComfyUI 就開 VM 103。兩台都設定了同一張 gpu-r9700，不能同時啟動。
PVE 這邊的設定大概是這樣：
| 項目 | 設定 |
|---|---|
| PVE Resource Mapping | gpu-r9700 |
| 實體裝置 | <GPU PCI address> |
| Device ID | <R9700 device ID> |
| IOMMU group | <IOMMU group> |
| VM 設定 | hostpci0: mapping=gpu-r9700,pcie=1 |
| VM BIOS / Machine | OVMF + q35 |
| VM CPU | host |
我沒有直接在 VM 設定裡硬寫裸 PCI 位址，而是用 Proxmox 的 Resource Mapping。這樣做比較穩，因為 PCI 位址或裝置順序如果哪天變了，PVE 會用 mapping 去檢查裝置 ID，比較不容易誤抓到別的 PCIe 裝置。之前這種事情一旦出錯，debug 起來會很煩。
GPU passthrough 設定教學：以 R9700 為例
這段整理一下我這台的設定方式。不同主機板、BIOS、GPU 會有差異，但大方向差不多：先讓 PVE host 支援 IOMMU，再把 GPU 從 host 隔離出來，最後交給指定 VM。
1. BIOS 先打開虛擬化和 IOMMU
在 BIOS 裡先確認這幾個功能有打開：
| BIOS 項目 | 建議 |
|---|---|
| SVM / AMD-V | Enabled |
| IOMMU | Enabled |
| Above 4G Decoding | Enabled |
| Resizable BAR | 視情況，出問題可先關掉測試 |
| CSM | Disabled，使用 UEFI |
我的 VM 用 OVMF + q35，所以整體走 UEFI 路線會比較一致。
2. PVE host 啟用 IOMMU
AMD 平台通常會在 kernel cmdline 加上：
amd_iommu=on iommu=pt
如果是 Proxmox 預設 GRUB，可以檢查：
cat /etc/default/grub
update-grub
如果是 systemd-boot，則要看：
proxmox-boot-tool kernel list
cat /etc/kernel/cmdline
proxmox-boot-tool refresh
重開機後確認 IOMMU 有起來：
dmesg | grep -Ei 'iommu|amd-vi'
3. 找出 GPU 的 PCI 裝置和 IOMMU group
先用 lspci 找顯卡：
lspci -nn | grep -Ei 'vga|display|audio'
以我這台為例，R9700 會被辨識成 AMD Navi 48 類裝置。公開文章就不放實際 PCI 位址，概念上會得到類似：
<GPU PCI address> VGA compatible controller: AMD/ATI Navi 48 [Radeon AI PRO R9700] [<R9700 device ID>]
再確認 IOMMU group。重點是 GPU 和它的附屬裝置最好在可單獨直通的 group 裡，不要跟主機板關鍵裝置混在一起。
find /sys/kernel/iommu_groups/ -type l | sort
4. 讓 host 不要拿這張卡當一般顯卡用
GPU passthrough 的核心想法是：這張卡不要給 PVE host 使用，而是交給 VM。通常會透過 VFIO 綁定裝置。
概念上會有幾個設定：
# /etc/modules
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
以及把 GPU device ID 綁到 vfio-pci：
# /etc/modprobe.d/vfio.conf
options vfio-pci ids=<R9700 device ID>
實際 device ID 要用自己機器上的 lspci -nn 結果，不要照抄別人的。
設定後更新 initramfs 並重開：
update-initramfs -u -k all
reboot
重開後可以確認這張卡是不是由 vfio-pci 接手：
lspci -nnk -s <GPU PCI address>
如果看到 Kernel driver in use: vfio-pci，方向就對了。
5. 用 Proxmox Resource Mapping 管理 GPU
我這台沒有直接在 VM 設定裡寫死 PCI 位址，而是用 Proxmox 的 Resource Mapping。這樣之後如果 PCI 位址有變，PVE 會用 mapping 檢查裝置 ID，比較不容易抓錯。
這台的概念設定如下：
| 項目 | 設定 |
|---|---|
| Mapping name | gpu-r9700 |
| Node | pve |
| Path | <GPU PCI address> |
| Device ID | <R9700 device ID> |
| IOMMU group | <IOMMU group> |
在 Web UI 裡可以從：
Datacenter → Resource Mappings → PCI Devices
新增一個 mapping。名稱我用 gpu-r9700，之後 VM 只要引用這個 mapping。
6. VM 設定：OVMF + q35 + host CPU + PCIe passthrough
VM 100 和 VM 103 都是同一套概念：
| VM 設定 | 值 |
|---|---|
| BIOS | OVMF |
| Machine | q35 |
| CPU | host |
| GPU | hostpci0: mapping=gpu-r9700,pcie=1 |
也就是說，VM 設定裡不是寫：
hostpci0: <GPU PCI address>
而是寫：
hostpci0: mapping=gpu-r9700,pcie=1
這個差異對長期維護很重要。裸 PCI 位址比較容易因為硬體順序、BIOS、PCIe 插槽變動而出問題；Resource Mapping 比較像是幫這張卡取一個穩定名字。
7. Guest 裡再裝 GPU stack
PVE host 不裝 ROCm、不裝 vLLM、不裝 ComfyUI。這些都進 VM 裡處理。
VM 裡要確認的東西：
lspci -nn | grep -Ei 'vga|display'
ls -l /dev/kfd /dev/dri/
LLM VM 裡再跑 ROCm / vLLM / llama.cpp toolbox；ComfyUI VM 裡再處理 ComfyUI 和圖像工作流。這樣 host 壞掉機率低很多，VM 裡踩坑也比較好重來。
8. 單張卡的使用規則
目前只有一張 R9700，所以規則很簡單：
| 狀況 | 做法 |
|---|---|
| 要跑 LLM | 開 VM 100，VM 103 關機 |
| 要跑 ComfyUI | 開 VM 103，VM 100 關機 |
| 要切換 VM | 先停 vLLM / llama-server / ComfyUI，再 shutdown VM |
| VM 開不起來 | 先檢查另一台 GPU VM 是否還開著 |
這是 passthrough 最容易被忘記的地方。GPU 直通不是把 GPU 做成共享資源，而是把整張卡交給一台 VM。除非是 NVIDIA 特定高階卡搭配 vGPU / MIG 那類方案，否則一般家用或工作站卡大多都要當成「一次只能給一台 VM」來管理。
儲存配置
目前儲存分成三個主要方向：系統與 VM 放在 2TB Crucial/Micron T500，上面建立 Proxmox 的 local 與 local-lvm；AI 共享資料用獨立 thin volume 掛在 /mnt/ai-shared；媒體共享資料則放在 Samsung NVMe 的 /mnt/media-shared。
/mnt/ai-shared 和 /mnt/media-shared 我都用 XFS。原因不是它最潮，而是它很適合這種用途：模型檔、GGUF、cache、資料集、媒體檔通常都是大檔案，XFS 對大檔案和長時間寫入很穩；掛 NFS 給多台 VM 用也很直覺。這台是單節點 PVE，不是多節點 storage cluster，我不需要 Ceph 那種複雜度；磁碟大小也不對稱，ZFS 的優勢發揮有限，還會吃更多記憶體。XFS 對我來說是比較務實的選擇。
PVE 另一個我很喜歡的點，是 VM disk 可以很彈性地調整。像 VM 100、VM 103 都可以先給一個 120GB 的 disk 上限，但在 local-lvm 這種 LVM-thin pool 裡，不是建立時就真的吃掉 120GB，而是 VM 實際寫入多少才逐步配置多少。後面如果某台 VM 空間不夠，也可以在 PVE 裡把 disk 擴大，再進 VM 裡擴 filesystem。對 lab 來說這很好用，因為每個實驗一開始都很難準確估容量。
這裡要先講清楚，Proxmox 裡的容量數字不能只看一個百分比。
df -hT看到的是檔案系統實際寫入量，例如/mnt/ai-shared真的用了 182GB。local-lvm是 LVM-thin，使用率代表 thin pool 實際配置/寫入比例，不是 VM disk 標稱容量加總。- 一般 LVM volume 被指派出去後，Proxmox storage 會顯示容量被占用，但不代表裡面的檔案系統真的寫滿。
| Storage / Mount | 類型 | 容量 | 使用狀態 | 備註 |
|---|---|---|---|---|
local |
dir | 約 94GB | 實際用量約 13GB / 13.97% | PVE local storage，ISO、備份或 snippets |
local-lvm |
LVM-thin | 約 1.67TB | thin pool 使用約 20.76% | 主要 VM disk pool；VM disk 大小是上限，不等於實際寫滿 |
samsung-lvm |
LVM | 約 477GB | LVM 指派率約 98.55% | 空間幾乎都已分配給 LV，但不等於檔案實際寫滿 |
/mnt/ai-shared |
XFS | 500GB | 實際用量約 182GB / 37% | AI 模型、資料集、文件共享 |
/mnt/media-shared |
XFS | 200GB | 實際用量約 3.9GB / 2% | 媒體共享，位於 Samsung LV |
/ |
ext4 | 94GB | 實際用量約 14GB / 15% | PVE host root filesystem |
網路配置
| 介面 | 狀態 | 說明 |
|---|---|---|
vmbr0 |
UP | Proxmox bridge，管理 IP <pve-ip>/24 |
nic1 |
UP | vmbr0 的 bridge port |
nic0 |
DOWN | 保留 |
wlp11s0 |
DOWN | Wi-Fi 7 無線網卡，未作為主要網路 |
tailscale0 |
UP | Tailscale 遠端維運，IP <tailscale-ip> |
/etc/network/interfaces 的核心設定如下：
auto vmbr0
iface vmbr0 inet static
address <pve-ip>/24
gateway <gateway-ip>
bridge-ports nic1
bridge-stp off
bridge-fd 0
5GbE 對這台很實用。模型、VM image、NFS 共享資料都很吃傳輸速度。Wi-Fi 7 我目前拿來當備用網路，這部分我寧願保守一點。
VM 與服務狀態
| VMID | 名稱 | 狀態 | RAM | Disk |
|---|---|---|---|---|
| 100 | ubuntu-26.04-lab |
stopped | 36GB | 120GB |
| 101 | gateway |
running | 12GB | 110GB |
| 103 | lab-colleague |
running | 36GB | 120GB，ComfyUI |
| 104 | cachyos-gaming |
stopped | 24GB | 120GB |
| 9000 | debian-13-template |
stopped | 2GB | 3GB |
PVE host 本身目前沒有 LXC container。真正的容器是在 VM 裡跑：VM 100 用 rootful podman，gateway 用 docker compose。這樣比全部堆在 host 上乾淨很多。
VM 100：主要 AI Lab 機器
VM 100 ubuntu-lab 是我主要使用的VM 。它專門拿來跑 R9700 GPU workload 的 AI lab。
| 項目 | 規格 / 設定 |
|---|---|
| VMID | 100 |
| Hostname | ubuntu-lab |
| IP | <lab-vm-ip> |
| OS | Ubuntu 26.04 LTS |
| Kernel | 7.0.0-15-generic |
| CPU | 12 cores，pinned to CCD0 |
| CPU affinity | 0-7,16-23 |
| RAM | 36GB configured on PVE；文件規劃為 44GB，ballooning disabled |
| Disk | 120GB system disk on local-lvm |
| GPU | R9700 passthrough，gfx1201 / RDNA4 |
| Network | virtio on vmbr0 |
| NFS mount | /mnt/data，來自 PVE /mnt/ai-shared |
| Container runtime | rootful podman |
| 主要用途 | AI inference、模型測試、ROCm/vLLM/llama.cpp 實驗 |
VM 100 的關鍵路徑：
| 路徑 | 用途 |
|---|---|
/mnt/data |
NFS shared storage，模型與資料共用 |
~/ai-models -> /mnt/data |
方便操作模型資料的 symlink |
/mnt/data/hf-cache |
Hugging Face / vLLM model cache |
/mnt/data/models |
GGUF 與其他模型檔 |
/dev/kfd |
ROCm compute device |
/dev/dri/renderD128 |
DRM render device |
/var/lib/containers/storage/ |
podman image/container storage，本機磁碟 |
我習慣做法：VM 系統碟只放系統和容器，模型資料放 NFS。VM 壞了可以重裝，模型 cache 還在；容器壞了可以重建，資料也不跟著消失。
VM 100 目前因為 R9700 正由 VM 103 的 ComfyUI 使用而處於 stopped。R9700 只有一張，VM 100 與 VM 103 不能同時開。切換前要先停止 vLLM / llama-server 或 ComfyUI，關掉其中一台 VM，再啟動另一台。
VM 100 裡的容器與 AI 工具鏈
VM 100 裡主要不是跑 Docker Compose，而是跑 rootful podman。原因很務實：GPU device passthrough、/dev/kfd、/dev/dri/renderD128、render/video group 權限在 rootful podman 下比較好處理。rootless podman 我試過，但 GPU 權限和 user namespace mapping 會讓事情變得很煩。
| 容器 | Runtime | Image | Port | 狀態 / 用途 |
|---|---|---|---|---|
vllm |
podman | docker.io/kyuz0/vllm-therock-gfx1201:latest |
8000 | vLLM + ROCm / TheRock，OpenAI-compatible API |
llama |
podman | docker.io/kyuz0/amd-r9700-toolboxes:vulkan-radv |
8080 | llama.cpp toolbox，跑 GGUF 模型 |
vllm 和 llama 容器可以並存，但裡面的推理 server 不適合同時跑。原因很單純：兩者會搶同一張 R9700 的 32GB VRAM。
常用操作：
# vLLM
sudo podman ps | grep vllm
sudo podman exec -it vllm bash
start-vllm
# llama.cpp toolbox
sudo podman ps | grep llama
sudo podman exec -it llama bash
llama-server --host 0.0.0.0 --port 8080 ...
目前測過的模型與結果
R9700 的定位很清楚：單卡 32GB VRAM，可以舒服跑一個 26B/27B 級別的量化模型，也可以靠 MoE 或小模型取得更高速度。但它不是多卡機器，不適合幻想同時塞多個大模型。
| 模型 | 格式 | 後端 | 平均速度 | 結論 |
|---|---|---|---|---|
gemma4-26b-abliterated |
AWQ | vLLM | 29.7 tok/s | 穩定 |
gemma4-31b-abliterated |
AWQ | vLLM | 10.6 tok/s | context 較容易滿 |
qwen3.6-35b-uncensored |
GGUF | llama.cpp | 76.5 tok/s | MoE，速度最佳 |
qwen3.6-27b-abliterated |
GGUF | llama.cpp | 30.5 tok/s | 穩定 |
gemma4-31b-crack |
GGUF | llama.cpp | 25.3 tok/s | 長輪次測試會 OOM/crash |
qwen2.5-7b-uncensored |
GGUF | llama.cpp | 80.1 tok/s | 小模型速度非常快 |
最讓我印象深的是 qwen3.6-35b-uncensored。它是 35B MoE，但每 token 只啟動約 3.5B active params，所以速度比很多 dense 模型好看。這也提醒我，不能只看模型總參數。架構差異有時比「幾 B」更重要。
對外服務與 Gateway
VM 101 gateway 負責把內部服務透過 Cloudflare Tunnel 對外提供。我不想把 PVE Web UI 或 VM 服務直接暴露到公網，所以這台 VM 的角色很明確：它只做入口，不碰 GPU。
| URL | 服務 | Backend |
|---|---|---|
https://lab.example.com |
Homepage | gateway:3000 |
https://status.example.com |
Uptime Kuma | gateway:3001 |
https://api.example.com |
LiteLLM API | gateway:4000 |
https://llm.example.com |
LiteLLM Web UI | gateway:4000 |
https://chat.example.com |
Open WebUI | gateway:3003 |
https://gpu.example.com |
vLLM direct | ubuntu-lab:8000 |
gateway 這邊使用 docker compose，比較適合放 Homepage、Uptime Kuma、LiteLLM、Open WebUI、SillyTavern 這類輕量服務。VM 100 則專心跑 GPU 推理，不把入口服務混在一起。
兩週運行心得
1. CPU 很夠，RAM 比較快緊
16C / 32T 對 Proxmox 來說很好切。gateway、AI lab、ComfyUI 工作機都能各自拿到足夠核心。真正比較容易緊的是 RAM。現在 64GB 能跑，但不是很寬裕。下一步如果要讓 VM 100、VM 103、gateway 和其他測試 VM 更自在，記憶體升級會比 CPU 升級更有感。
9950X3D 這種 CPU 還有一個要注意的地方：它不是所有核心都一樣。X3D 版本有 CCD 分配問題，其中一組核心有 3D V-Cache，另一組核心通常頻率表現比較好。我的做法是用 PVE 的 CPU affinity 先把 GPU workload VM 固定在同一組核心上，避免 VM 在兩個 CCD 之間亂跳。像 VM 100 / VM 103 目前就是綁 0-7,16-23 這組核心；gateway 這種輕量服務則可以放到另一組核心。這不是什麼神奇最佳化，但可以讓 LLM / ComfyUI 這種比較吃互動延遲和資料 locality 的工作負載穩一點，也比較方便後面觀察效能。
2. R9700 可以玩，但不要把 host 當實驗場
R9700 / RDNA4 還是偏新的平台。自己從零兜 ROCm、TheRock、gfx1201 支援會花很多時間。現在比較穩的路線是用 kyuz0 的 toolbox image：kyuz0/vllm-therock-gfx1201 跑 vLLM，kyuz0/amd-r9700-toolboxes:vulkan-radv 跑 llama.cpp。
把這些都放在 VM 100 裡是對的。真的踩坑，也是在 VM 裡處理，不會污染 PVE host。
3. GPU passthrough 要接受它是「一張實體卡」
VM 100 跑 LLM，VM 103 跑 ComfyUI，兩台都想要 R9700。但 R9700 只有一張，所以它們必須輪流使用。這件事最好寫成固定流程，不要臨時憑感覺切。不然下一次你看到某台 VM 開不起來，八成又是在想「是不是 GPU 還被另一台占著」。
這點跟 CPU/RAM 很不一樣。一般 PCIe GPU passthrough 是把整張實體卡交給某一台 VM，host 和其他 VM 就不能同時用。NVIDIA 某些高階卡或資料中心卡可以透過 vGPU / MIG 這類方式把 GPU 資源切給多個 workload，但那是特定硬體、授權和驅動堆出來的能力，不是一般顯卡預設就有。R9700 這邊我就當成一張完整的實體卡來管理：一次只服務一台需要 GPU 的 VM。
4. Cloudflare Tunnel 很省事
它不是最自由的方案，但對這種個人 Lab 很好用。不用碰路由器，不用固定 IP，不用自己管憑證更新。對外入口集中在 gateway VM，也比直接暴露 PVE 或 VM 服務安心。
之後的規劃
R9700 現在可以跑，但它和 CUDA 生態還是有差距，這點在 ComfyUI 上會特別明顯。
| 方向 | 想解決的問題 | 優點 | 需要確認 |
|---|---|---|---|
| RAM 升級到 128GB 以上 | VM 100 / VM 103 / gateway 同時規劃時，64GB 太緊 | 最直接改善 VM 配置彈性 | 先確認 2 DIMM 還是 4 DIMM、頻率與穩定性 |
| 增加第二張 R9700 | LLM 和 ComfyUI 不用一直輪流搶同一張 GPU | AMD 生態一致，成本可能比較好控 | 主機板空間、供電、散熱、IOMMU group、ROCm 多卡支援 |
| 改看 B70 | 提高單卡 VRAM 或 AI workload 彈性 | 如果 VRAM/頻寬更好，可能比第二張 R9700 更適合 LLM | 價格、可買性、ROCm 支援程度、Proxmox passthrough 成熟度 |
| ComfyUI + 5090 | 補齊 CUDA 生態，降低 custom node 相容性問題 | ComfyUI / PyTorch / xFormers / Triton 生態通常更順 | 5090 供電散熱、Linux driver、PCIe 空間、是否獨立給 VM 103 |
| 無 CUDA 時的 ComfyUI node 對應方案 | R9700 上遇到 CUDA-only node 時，需要替代 workflow | 不必所有圖像流程都依賴 NVIDIA | 哪些 node 能用 ROCm/Vulkan/CPU 替代，哪些應該直接避開 |
ComfyUI 這邊我想另外整理一份比較表。重點不是只看「能不能跑」，而是要列出常用 node 在不同平台上的實際情況：
| ComfyUI 項目 | 5090 / CUDA | R9700 / 無 CUDA | 備註 |
|---|---|---|---|
| PyTorch GPU 加速 | CUDA 路線最成熟 | 依賴 ROCm 支援 | AMD 上要看 torch / ROCm 版本 |
| xFormers / attention 加速 | 通常比較好處理 | 常需要替代方案 | 有些 workflow 會卡在這裡 |
| CUDA-only custom node | 大多可直接用 | 需要找替代 node 或改 workflow | 之後要整理 node 對應清單 |
| 影像生成基礎流程 | 成熟 | 可行，但要看模型與套件 | SD / Flux / video workflow 要分開測 |
| Video / 3D / 特殊 node | CUDA 優勢明顯 | 不一定有等價方案 | 可能是 5090 最大價值 |
短期先做幾件事：
- 重新整理
samsung-lvm的 LV 配置。 - 把 VM 100 / VM 103 的 GPU 切換流程寫成 runbook。
- 繼續補 R9700 / ROCm / vLLM / llama.cpp 實測紀錄。
- 補 ComfyUI 在 VM 103 的部署、常用 workflow、node 相容性紀錄。
