會開始組這台機器，其實是因為 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萬上下....

9950X3D 對 Proxmox 很舒服，16C / 32T 可以切給幾台 VM，還不會一下就見底。
R9700 是這台的重點，32GB VRAM 剛好能跑 26B/27B 量化模型，也能測 MoE、小模型、GGUF，還可以跑星際公民。

64GB RAM 是目前比較明顯的瓶頸(但真的太貴了）。不是不能用，是你會需要小心分配：VM 100 給 36GB，VM
103 給 36GB，gateway 再拿一些，host 自己也要留。下一個升級我大概會先補記憶體...如果有降價

軟體規格

PVE host 我盡量保持乾淨。這裡的「乾淨」不是什麼都不裝，而是不把 AI/GPU 推理 stack 裝在 host 上。GPU driver、ROCm、vLLM、llama.cpp、ComfyUI 這些容易互相影響的東西都放 VM 裡；host 只保留跟硬體、網路、儲存和維運直接相關的工具。

目前 host 上額外安裝或啟用的東西大概是這些：

風扇控制是 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 這邊的設定大概是這樣：

我沒有直接在 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 裡先確認這幾個功能有打開：

我的 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，比較不容易抓錯。

這台的概念設定如下：

在 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 設定裡不是寫：

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，所以規則很簡單：

這是 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 會顯示容量被占用，但不代表裡面的檔案系統真的寫滿。

網路配置

/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 與服務狀態

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。

VM 100 的關鍵路徑：

我習慣做法：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 會讓事情變得很煩。

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 或小模型取得更高速度。但它不是多卡機器，不適合幻想同時塞多個大模型。

最讓我印象深的是 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。

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 上會特別明顯。

ComfyUI 這邊我想另外整理一份比較表。重點不是只看「能不能跑」，而是要列出常用 node 在不同平台上的實際情況：

短期先做幾件事：

• 重新整理 samsung-lvm 的 LV 配置。
• 把 VM 100 / VM 103 的 GPU 切換流程寫成 runbook。
• 繼續補 R9700 / ROCm / vLLM / llama.cpp 實測紀錄。
• 補 ComfyUI 在 VM 103 的部署、常用 workflow、node 相容性紀錄。

相關連結

• Proxmox VE
• Proxmox VE Documentation
• Cloudflare Tunnel
• ROCm Documentation
• kyuz0/amd-r9700-vllm-toolboxes
• vLLM
• llama.cpp
• ComfyUI
• DeepCool Digital Linux