R9700 Proxmox VE 懶人部署兩週運行心得
-
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 pveOS Debian GNU/Linux 13 trixieProxmox 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-linuxDeepCool 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.serviceSSD / 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=1VM 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 | sort4. 讓 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-r9700Node pvePath <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 類型 容量 使用狀態 備註 localdir 約 94GB 實際用量約 13GB / 13.97% PVE local storage，ISO、備份或 snippets local-lvmLVM-thin 約 1.67TB thin pool 使用約 20.76% 主要 VM disk pool；VM disk 大小是上限，不等於實際寫滿 samsung-lvmLVM 約 477GB LVM 指派率約 98.55% 空間幾乎都已分配給 LV，但不等於檔案實際寫滿 /mnt/ai-sharedXFS 500GB 實際用量約 182GB / 37% AI 模型、資料集、文件共享 /mnt/media-sharedXFS 200GB 實際用量約 3.9GB / 2% 媒體共享，位於 Samsung LV /ext4 94GB 實際用量約 14GB / 15% PVE host root filesystem
網路配置
介面 狀態 說明 vmbr0UP Proxmox bridge，管理 IP <pve-ip>/24nic1UP vmbr0的 bridge portnic0DOWN 保留 wlp11s0DOWN Wi-Fi 7 無線網卡，未作為主要網路 tailscale0UP 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 05GbE 對這台很實用。模型、VM image、NFS 共享資料都很吃傳輸速度。Wi-Fi 7 我目前拿來當備用網路，這部分我寧願保守一點。
VM 與服務狀態
VMID 名稱 狀態 RAM Disk 100 ubuntu-26.04-labstopped 36GB 120GB 101 gatewayrunning 12GB 110GB 103 lab-colleaguerunning 36GB 120GB，ComfyUI 104 cachyos-gamingstopped 24GB 120GB 9000 debian-13-templatestopped 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-labIP <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-23RAM 36GB configured on PVE；文件規劃為 44GB，ballooning disabled Disk 120GB system disk on local-lvmGPU R9700 passthrough，gfx1201 / RDNA4 Network virtio on vmbr0NFS mount /mnt/data，來自 PVE/mnt/ai-sharedContainer runtime rootful podman 主要用途 AI inference、模型測試、ROCm/vLLM/llama.cpp 實驗 VM 100 的關鍵路徑：
路徑 用途 /mnt/dataNFS shared storage，模型與資料共用 ~/ai-models -> /mnt/data方便操作模型資料的 symlink /mnt/data/hf-cacheHugging Face / vLLM model cache /mnt/data/modelsGGUF 與其他模型檔 /dev/kfdROCm compute device /dev/dri/renderD128DRM 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 狀態 / 用途 vllmpodman docker.io/kyuz0/vllm-therock-gfx1201:latest8000 vLLM + ROCm / TheRock，OpenAI-compatible API llamapodman docker.io/kyuz0/amd-r9700-toolboxes:vulkan-radv8080 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-abliteratedAWQ vLLM 29.7 tok/s 穩定 gemma4-31b-abliteratedAWQ vLLM 10.6 tok/s context 較容易滿 qwen3.6-35b-uncensoredGGUF llama.cpp 76.5 tok/s MoE，速度最佳 qwen3.6-27b-abliteratedGGUF llama.cpp 30.5 tok/s 穩定 gemma4-31b-crackGGUF llama.cpp 25.3 tok/s 長輪次測試會 OOM/crash qwen2.5-7b-uncensoredGGUF 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.comHomepage gateway:3000 https://status.example.comUptime Kuma gateway:3001 https://api.example.comLiteLLM API gateway:4000 https://llm.example.comLiteLLM Web UI gateway:4000 https://chat.example.comOpen WebUI gateway:3003 https://gpu.example.comvLLM 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 相容性紀錄。
相關連結
-
系统 于 取消固定此主题
-
proxmox能用？我以为效果一般呢。我专门找出来个闲置的sata ssd，安装的Ubuntu，如果可用，我就用回我的proxmox了。
PVE对于Homelab来说基本是终极方案，尤其对于咱们这样的折腾人士来说有NAS的话给它挂个PBS自动备份太重要了，崩溃了随时会退，太强了。
我是一台Dell7820的服务器来跑的，现在一个VM装各种服务和docker等等，另一个VM直通了显卡作为算力中心，LLM/Comfyui都在一起，很好用只是5070Ti算力不错，但是卡显存很难受，所以入了R9700还没到，估计之后又是一顿折腾，哈哈。不过二手的服务器确实很香，稳的一批！
-
-
-
@fcme 我也是T7820 原来装了Quadro 5000 + 2张RTX2000 Ada；今天刚装了两张R9700。碰到的第一个难题是moddiy买的电源线太短，只能把卡放在第一和第三插槽。第三插槽速度很慢。
