R9700 Proxmox VE 懶人部署兩週運行心得

CS6

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 相容性紀錄。

抡锤者

R9700 Proxmox VE 懶人部署兩週運行心得

R9700 Proxmox VE 懶人部署兩週運行心得

硬體規格

軟體規格

整體架構

GPU passthrough 設定教學：以 R9700 為例

1. BIOS 先打開虛擬化和 IOMMU

2. PVE host 啟用 IOMMU

3. 找出 GPU 的 PCI 裝置和 IOMMU group

4. 讓 host 不要拿這張卡當一般顯卡用

5. 用 Proxmox Resource Mapping 管理 GPU

6. VM 設定：OVMF + q35 + host CPU + PCIe passthrough

7. Guest 裡再裝 GPU stack

8. 單張卡的使用規則

儲存配置

網路配置

VM 與服務狀態

VM 100：主要 AI Lab 機器

VM 100 裡的容器與 AI 工具鏈

目前測過的模型與結果

對外服務與 Gateway

兩週運行心得

1. CPU 很夠，RAM 比較快緊

2. R9700 可以玩，但不要把 host 當實驗場

3. GPU passthrough 要接受它是「一張實體卡」

4. Cloudflare Tunnel 很省事

之後的規劃

相關連結

R9700 Proxmox VE 懶人部署兩週運行心得

硬體規格

軟體規格

整體架構

GPU passthrough 設定教學：以 R9700 為例

1. BIOS 先打開虛擬化和 IOMMU

2. PVE host 啟用 IOMMU

3. 找出 GPU 的 PCI 裝置和 IOMMU group

4. 讓 host 不要拿這張卡當一般顯卡用

5. 用 Proxmox Resource Mapping 管理 GPU

6. VM 設定：OVMF + q35 + host CPU + PCIe passthrough

7. Guest 裡再裝 GPU stack

8. 單張卡的使用規則

儲存配置

網路配置

VM 與服務狀態

VM 100：主要 AI Lab 機器

VM 100 裡的容器與 AI 工具鏈

目前測過的模型與結果

對外服務與 Gateway

兩週運行心得

1. CPU 很夠，RAM 比較快緊

2. R9700 可以玩，但不要把 host 當實驗場

3. GPU passthrough 要接受它是「一張實體卡」

4. Cloudflare Tunnel 很省事

之後的規劃

相關連結