Proxmox VE 從 2008 年第一版釋出到 2026 年 8 月，整整 20 年只認 x86-64 這一種指令集。這段期間 Linux 核心早就把 arm64 打磨到伺服器級穩定、Kubernetes、KVM、Ceph 全都跑得動 ARM，Proxmox 卻沒動過官方支援的架構列表。這個假設在 2026 年 8 月 5 日被打破——Proxmox Server Solutions 釋出 VE 9.2 arm64 版本，跟 x86-64 走同一份 codebase、同一批套件倉庫、同一份釋出時程。這是 Proxmox 二十年來第一次把生產級 hypervisor 帶到第二個 CPU 架構上。
這件事之所以值得拆開來講，不是因為 arm64 本身有多新奇——AWS Graviton、Ampere Altra、Oracle Cloud OCI A1 早就把 ARM 伺服器變成常態選項——而是因為 Proxmox 的官方支援跟社群自己編譯的 unofficial port 有本質差異。企業訂閱、bug 修復時程、跨版本升級路徑，這些過去只有 x86-64 使用者能拿到的東西，現在 arm64 使用者也能拿到同一級的服務。
20 年才動的架構假設，觸發點是 NVIDIA Grace Hopper
Proxmox 這次的移植不是社群壓力推出來的——過去五年 GitHub 跟論壇上一直有人抱怨為什麼不支援 arm64，官方回應始終是「我們的目標客群還在 x86 上」。真正把這件事推過線的是 NVIDIA。Proxmox 官方明確說明整套 arm64 移植是跟 NVIDIA 與 Supermicro 合作完成，開發跟驗證環境用的就是 NVIDIA Grace Hopper Superchip 平臺。
這條線索指向的方向很清楚：AI 訓練與推論工作負載在 2025 到 2026 年被 CPU-GPU 統一記憶體架構重新洗牌，Grace Hopper 這種 CPU 側直接吃 480 GB LPDDR5X 加上高頻寬 NVLink 連 Hopper GPU 的機型，跑虛擬化叢集的需求真的浮出來。企業客戶要把這種節點納入既有的 Proxmox 管理平面，社群自編版本應付不了合約級的支援要求，官方 arm64 因此變成必要投資。
第一波官方支援硬體列表短得可以：NVIDIA Grace Hopper、NVIDIA Vera 兩個平臺是完整支援，其他 UEFI-based 的 ARMv8-A、ARMv9-A 伺服器是 best-effort，意思是可以裝、遇到問題官方會盡量處理但不保證。這個支援層級的區隔比 x86-64 時代更嚴格——過去 Proxmox 的 x86 支援基本上是 Intel/AMD 通吃，這次 arm64 則是先鎖定兩個特定平臺。
UEFI + ACPI 是硬門檻，Raspberry Pi 直接被擋在門外
想在自家 lab 拿 Raspberry Pi 5 或 Rockchip 板子跑 Proxmox 的人可以先放下這個念頭。官方文件寫得很直白：宿主機必須用 UEFI 啟動，並透過 ACPI 描述硬體。這個要求把幾乎所有依賴 device tree 的 SBC 排除在外——Raspberry Pi、Rock Pi、Orange Pi、NanoPi 這類板子雖然核心都跑得動 arm64 Linux，但它們的韌體不走 UEFI+ACPI 這條路，Proxmox 的安裝程式從第一步就過不去。
這不是短期會鬆綁的限制。Proxmox 選擇 UEFI+ACPI 是因為要複用 x86-64 時代累積的整套 boot 流程、韌體交握、硬體列舉邏輯，這樣才能維持同一份 codebase。要支援 device tree 意味著把 arm64 版本拆成第二條分支去維護，Proxmox 從 20 年的組織經驗來看很清楚不會走這條路。
要在 SBC 上跑虛擬化的人有其他選項可以看。Incus（2023 年 8 月由原 LXD 作者 Stéphane Graber 跟 maintainer 群從 Canonical 手中 fork 出來、回到 Linux Containers 專案維護的版本）從一開始就把 arm64 SBC 當一級公民支援，能同時管 LXC container 跟 KVM VM，Raspberry Pi 5 上跑起來的體驗跟在 x86 mini PC 上沒太大差別。要的是 Kubernetes 節點的話 K3s 在 arm64 SBC 上也已經是成熟方案。
少了 SEV、GVT-g、CPU microcode，這些差異不能忽略
ARM64 版本拿掉了幾樣 x86-64 時代大家可能習慣但架構本身沒有的東西。AMD SEV 記憶體加密不見了——這個功能本來就是 AMD 特有，ARM 對應的 CCA (Confidential Compute Architecture) 硬體支援還在早期，Proxmox 目前完全沒接。要跑 confidential VM 的工作負載這條路暫時走不通。
Intel GVT-g 這種 mediated GPU 虛擬化也不存在。ARM 平臺上 GPU 虛擬化的替代方案是 NVIDIA vGPU（要商業授權）或 SR-IOV，Proxmox arm64 對這兩者的支援目前沒有明確承諾。想在 ARM 節點上跑 GPU 密集 VM 的話，直接 passthrough 是目前最實際的路線。
比較底層的一個差異是沒有 OS 級別的 CPU microcode 套件。x86-64 時代 intel-microcode 和 amd64-microcode 這兩包幾乎每個安裝都會裝，硬體漏洞出來時 Proxmox 只要更新 microcode 就能緩解一大批 side channel 攻擊。ARM 伺服器的 CPU firmware 更新走完全不同的路徑——通常要靠 UEFI capsule update 或廠商特定的工具，責任落在硬體供應商而不是 OS。這在資安維運上是心智模型的轉換，運維團隊要調整反應流程。
VM 啟動這一層也少了 SeaBIOS。ARM 版本只用 AAVMF（Arm build of OVMF）走 UEFI 啟動一條路。從 x86 匯入的 legacy BIOS VM 過來的話得先在來源側改成 UEFI 才能上路，這個轉換不是純機械操作，Windows guest 尤其需要重灌 boot loader。
同一個 cluster 想混搭 x86 跟 ARM？技術上可以，實務上等於沒 HA
Proxmox arm64 版本可以加進既有的 x86-64 cluster——設定檔、SDN、Ceph pool 都認得對方——但這個混搭有一個致命限制：跨架構 live migration 完全做不到。要把 VM 從 x86 節點搬到 ARM 節點，只能走離線 migration（VM 關機、匯出、匯入、重開），而且 guest OS 得換成 arm64 版本，等於重裝。
這對 HA cluster 的意義是實質性的。Proxmox HA 的核心邏輯是節點掛掉時自動把 VM 搬到活的節點繼續跑，跨架構的話這個保證只在同架構的節點池內成立。要用混合 cluster 的人得手動設定 HA group，把 x86 VM 綁定到 x86 節點群、arm64 VM 綁定到 arm64 節點群，兩邊變成邏輯上獨立的可用性域。這個設計可以做得漂亮，但不能假裝跟純 x86 cluster 一樣操作。
實務上的建議是：需要 ARM 節點的話，開一個獨立的 arm64 cluster 比混合 cluster 好維護。管理平面的資料（使用者、權限、備份任務）可以透過 Proxmox Datacenter Manager 這個上層工具整合，把每個 cluster 當一個單位管理，避免混合 cluster 那些細節在故障排除時吃掉整個週末。
這條路線適合誰、不適合誰
想在 NVIDIA Grace Hopper 這類 AI 伺服器上做 VM 隔離的企業，這是目前最直接的官方路徑——省下自己維護 Cloud Hypervisor 或 Kata Containers 的成本。想在 Ampere Altra、Altra Max、AmpereOne 這類密集運算 CPU 上跑虛擬化叢集的服務商，best-effort 支援夠用；每核心功耗只有 x86 的 30-40%，同一個機櫃能塞的 VM 數量翻倍。
想在家跑 Raspberry Pi cluster、想拿舊 Chromebook 或 Android 平板改造成微型 hypervisor 的自架玩家，這個版本沒有幫助——換 Incus 或 K3s 是更務實的方向。想在中小型 VPS 上跑虛擬化的人，x86-64 版本目前依舊是首選，因為 ARM 伺服器在臺灣主機商的選項還不夠密集，維運工具鏈跟社群範例都還在 x86 那一側。
Proxmox 這次 arm64 移植的訊號意義比技術本身重要。過去二十年 x86-64 在 hypervisor 生態的獨佔已經被 AI 硬體的採購週期打破，ARM 進入資料中心的節奏這次是需求端拉動、不是供給端推廣。VE 9.2 arm64 不會取代 x86-64，兩者會長期並存，但企業選型的第一個問題從此多了一個：「這個工作負載該跑在哪個架構上？」
NCSE Network 在臺灣是方電訊機房提供採用 Intel Xeon Gold CPU 與 NVMe SSD 的 VPS 主機，適合跑 Proxmox VE 已經成熟的 x86-64 生態、Docker 容器編排、以及 Kubernetes 節點。若在評估自架 hypervisor 或多節點叢集部署，前往 ncse.tw 了解方案細節與臺灣本地低延遲線路的優勢。
