ARM VPS 與 x86 VPS 有何不同？相容性與成本

切換至 ARM VPS 後有哪些變化

ARM VPS 執行與 x86 VPS 相同的 Linux 和 Nginx，通常每個核心的成本也較低。切換時的風險在於相容性。針對 x86-64 編譯的程式完全無法在 arm64 上執行，因此堆疊中的每個軟體都必須提供 arm64 組建，或能夠由您自行重新編譯。

大多數現代堆疊無須修改即可通過這項檢查。問題主要集中在兩個地方：只為單一架構建立的容器映像，以及沒有提供 arm64 下載版本的封閉原始碼軟體。以下指令可在您租用 instance 前，針對自己的堆疊回答這兩個問題。如果您仍在確認需要哪一類伺服器，請先閱讀 VPS 是什麼，以及它與 shared hosting 有何不同。

arm64、aarch64、amd64：各名稱代表什麼

在執行其他操作前，先於任何 instance 上執行以下命令。

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

在 ARM machine 上，uname -m 會輸出 aarch64；在 Intel 或 AMD machine 上，則會輸出 x86_64。對相同的兩台 machine 而言，dpkg --print-architecture 會輸出 arm64 和 amd64。兩種結果都正確。Linux kernel 與 Debian packaging system 為相同的 instruction set 採用了不同名稱，因此 aarch64 與 arm64 代表其中一種，x86_64 與 amd64 則代表另一種。Docker 使用 Debian 風格的名稱，因此 image platform 會顯示為 linux/arm64。

在 arm64 上，/proc/cpuinfo 中沒有 model name 行。取而代之的是 Features 欄位，硬體加密功能會以 aes pmull sha1 sha2 等 flags 顯示。這些是 ARMv8 Cryptographic Extensions，功能相當於 Intel 和 AMD 處理器上的 AES-NI：讓 TLS（transport layer security）與磁碟加密在硬體中高速執行。檢查 VPS 是否支援 AES 硬體加速 說明了如何在兩種 architecture 上進行測試。

容器為何會最先發生問題，以及錯誤訊息的樣子

每個 Docker 映像檔 manifest 都會記錄其建置目標架構。將只有 amd64 manifest 的映像檔 pull 到 arm64 主機時，pull 會成功。直到第一個程序啟動時才會發生錯誤：

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error

exec format error是 kernel 拒絕執行該檔案，因為其 ELF（可執行與可連結格式）標頭指定的機器類型並未由此 CPU 實作。沒有任何設定可以修正這個問題。因為該指令集並不存在於硬體中。

部署前先檢查 manifest：

docker buildx imagetools inspect nginx:1.27

輸出會針對 manifest list 中的每個映像檔，各列出一行 Platform:，例如 linux/amd64 和 linux/arm64。如果缺少 linux/arm64，該 tag 就無法在 ARM VPS 上啟動。docker manifest inspect --verbose nginx:1.27 會顯示相同資訊，但 Docker 將 docker manifest 記載為實驗性命令，其行為可能在不同版本間變更，因此優先使用 imagetools。

如果自行建置映像檔，請在單一命令中建置兩種架構，並推送 manifest list：

docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4 --push .

在單一主機上為其他架構建置時，需要使用已向 kernel 的 binfmt_misc handler 註冊的 QEMU user mode emulation：

docker run --privileged --rm tonistiigi/binfmt --install all

使用 emulation 進行建置與測試。不要使用它來提供網路流量服務。Docker 官方文件指出，使用 QEMU 進行 emulation「可能比原生建置慢很多，尤其是編譯、壓縮或解壓縮等計算密集工作」，因此在 ARM 執行個體上執行 emulated x86 服務，會抵銷促使你遷移的效能與成本效益。在原生架構情境下，兩種架構的主機設定完全相同：在 VPS 上執行 Docker 涵蓋相關設定；只要其中每個映像檔都有 arm64 manifest，現有的 Compose 檔案即可直接使用。

arm64 上會有我需要的套件嗎？

Ubuntu 和 Debian 幾乎會為 arm64 建置整個套件庫，因此 apt install nginx postgresql redis-server 在這兩種架構上的行為相同。差異通常出現在第三方套件庫。

請直接在 ARM 執行個體上查詢 apt：

apt-cache policy some-vendor-agent
apt-get install -s some-vendor-agent

apt-cache policy 回報 Candidate: (none)，表示目前啟用的套件庫沒有為此架構發布該套件的建置版本。apt-get install -s 會模擬安裝而不寫入任何內容；在相同情況下，最後會顯示 E: Unable to locate package。

接著查看 apt update 的輸出，不要直接略過。供應商套件庫若僅支援 amd64，會明確顯示：

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

套件庫已完成設定且可連線，但其中沒有這台機器可以安裝的套件。同時也請檢查來源項目本身。在 arm64 主機上，以 [arch=amd64] 設定固定的行會被略過，因此套件看似不存在，實際原因是該固定設定。

哪些工作負載可以直接使用，哪些需要先確認

直譯式與位元組碼執行環境原本就具備可攜性。PHP、Python、Ruby 與 Node.js 在主要發行版中都有 arm64 套件。Go 與 Rust 只要設定一個目標平台，就能交叉編譯為 arm64。LEMP stack、Node API、置於 Nginx 後方的 Go 二進位檔，或 Postgres 資料庫，都是 arm64 上的常見工作負載。

即時編譯器（JIT）會在程式執行期間產生機器碼，因此需要支援目標架構的程式碼產生器。目前的版本都有此支援：Linux 上的 OpenJDK、.NET、Node.js 內的 V8 engine，以及 PyPy 都支援 arm64。真正的風險是被固定使用的舊版本。若部署指令碼會安裝數年前的 runtime release，應根據該版本的說明確認是否支援 aarch64，不要直接假設可以運作。

包含手寫 x86 assembly，或 SSE 與 AVX intrinsic 的函式庫，通常較不容易立即發現問題。多數函式庫也有 NEON 路徑（NEON 是 ARM 的向量指令集）或純 C fallback，因此仍可編譯與執行。效能可能比 x86 build 好，也可能較差。請直接在你的 instance 上測量，不要根據文章預測結果。

閉源軟體才是真正的阻礙。廠商提供的監控 agent、授權資料庫 driver、商用 control panel 或防毒 daemon 都是編譯後的二進位檔；如果廠商沒有發布 arm64 build，就沒有可行的處理方式。在 hosting 領域，cPanel 和 WHM 是最明顯的案例：其系統需求列出 x86_64，但未列出 ARM，因此 control panel server 應繼續使用 x86（截至 August 2026 已確認，仍建議重新閱讀廠商自己的需求頁面）。如果唯一阻礙就是這項限制，請從 值得在 VPS 上執行的 cPanel 替代方案 開始，並以相同方式確認每個方案的架構支援情況。

Kernel 與頁面大小：ARM 執行個體仍有哪些差異

x86-64 伺服器幾乎可以互換使用。ARM 伺服器的規格較不一致，而且差異位於應用程式之下的層級。

頁面大小是最可能影響正式環境的差異。大多數 arm64 Kernel 使用 4 KiB 頁面，與 x86-64 相同。有些 Kernel 使用 64 KiB。Red Hat Enterprise Linux 8 for aarch64 預設提供 64 KiB 頁面的 Kernel；RHEL 9 則將預設值改回 4 KiB，同時保留獨立的 kernel-64k 套件，供需要較大頁面的工作負載使用。對於具有許多小型映射的程序，64 KiB 頁面大小會提高記憶體下限，因為 Kernel 能配置的最小區塊大了 16 倍。請在該執行個體上執行 getconf PAGESIZE 並讀取數值，不要自行假設。

還有幾項較小的差異值得了解。arm64 沒有作業系統 CPU microcode 套件，因此 firmware 更新由 provider 提供，不是由 apt 提供。ARM 伺服器透過 UEFI（unified extensible firmware interface）開機，並透過 ACPI（advanced configuration and power interface）描述硬體。部分 x86 功能完全沒有對應的 ARM 功能，包括 AMD SEV 記憶體加密與 Intel GVT-g mediated GPU。

ARM 伺服器平台是否已經成熟？

在軟體方面，答案是肯定的。Debian、Ubuntu、Fedora 和 RHEL 都提供一級支援的 arm64 組建，而 Docker Hub 上的官方映像通常也都支援多架構。

近期最明確的證據是 Proxmox。2026 年 8 月 5 日，Proxmox 宣布推出首個正式支援 arm64 的 Proxmox Virtual Environment 版本 9.2。此版本與 x86-64 版本共用套件儲存庫及發布週期。它以 Debian 13.5 為基礎，搭載 Linux 7.0、QEMU 11.0、LXC 7.0 和 ZFS 2.4。除了少數架構特定項目外，其設定方式與工具都與 x86-64 相同。

請閱讀同一份公告中的限制，因為這些內容顯示目前正式支援的 ARM 伺服器硬體範圍仍然非常有限。Proxmox 在首日驗證了 NVIDIA Grace 和 NVIDIA Vera 系統，並已與 NVIDIA 和 Supermicro 共同測試 Grace Hopper 硬體。其他採用 UEFI 的 ARMv8-A 和 ARMv9-A 硬體則僅提供盡力支援。僅支援 device tree 的單板電腦，例如 Raspberry Pi，不在支援範圍內。客體只能在相同架構的節點上執行，live migration 也只能在相同架構的節點之間進行，混合架構叢集則不受正式支援。

這就是截至 2026 年 8 月的實際情況。虛擬機器管理程式供應商以與 x86-64 相同的生命週期發布 arm64 版本，確實代表平台已有進展。但首日獲支援的硬體清單仍只有兩個 CPU 家族。

提交前的檢查清單

1. 在測試實例上執行 uname -m，確認輸出 aarch64。
2. 對 Compose 檔案中的每個映像檔執行 docker buildx imagetools inspect，確認每個映像檔都有一行 linux/arm64 平台資訊。
3. 在 ARM 實例上執行 apt update，並閱讀其輸出的每一則 Skipping acquire 警告。
4. 開啟所依賴之每個閉源 agent 的下載頁面，依名稱尋找 arm64 或 aarch64 版本。
5. 執行 getconf PAGESIZE，在決定記憶體配置前記下輸出結果。
6. 分別在 ARM 方案與正在比較的 x86 方案上執行自有基準測試。

這篇文章不主張的內容

我們不會直接提供 ARM 與 x86 的性價比。每個核心的價格會因供應商和方案而異，而且在他人硬體上測得的數據，無法預測你的結果。請自行測量。我們的 VPS 效能測試指南涵蓋 sysbench 和 fio，並提供可重複執行的方法；VPS 的實際成本則說明比較中的價格因素。儲存是不同於 CPU 架構的獨立決策，VPS 上 NVMe 與 SATA SSD 的比較會處理這部分。請在兩個方案上執行相同測試；可行時使用你自己的工作負載，並讓測試數據決定結果。

FAQ

我的 Docker 容器可以在 ARM VPS 上執行嗎？

只要堆疊中的每個映像檔，其 manifest 都包含 linux/arm64 項目，就可以執行。使用 docker buildx imagetools inspect <image> 檢查每個映像檔，並尋找 Platform: linux/arm64 行。Docker Hub 上的官方映像檔通常支援多種架構。較小型供應商提供的映像檔，以及您在 x86 機器上自行建置的映像檔，通常不支援多種架構。對於自行建置的映像檔，請使用 docker buildx build --platform linux/amd64,linux/arm64 ... --push 重新建置，讓同一個標籤同時支援兩種架構。

exec format error 在 ARM 伺服器上代表什麼？

核心嘗試執行 ELF 標頭所指定機器類型不同的二進位檔，因此拒絕執行。在 arm64 主機上，這幾乎總是表示該檔案是 x86-64 二進位檔或容器映像檔。Docker 會先顯示警告，指出要求的映像檔平台 linux/amd64 與偵測到的主機平台 linux/arm64/v8 不相符。解決方式是建置適用於正確架構的版本。變更設定無法讓 x86-64 二進位檔在 ARM 上原生執行。

arm64 和 aarch64 是同一回事嗎？

是。這是 64-bit ARM 指令集的兩種名稱。核心會透過 uname -m 回報 aarch64，而 Debian 和 Ubuntu 的套件，以及 Docker 平台字串，會使用 arm64。另一側也有相同的名稱差異：uname -m 代表 x86_64，套件則使用 amd64。如果下載頁面只提供 aarch64 檔案，這些就是適用於 dpkg --print-architecture 稱為 arm64 的機器的正確檔案。

ARM VPS 比 x86 VPS 快嗎？

這個問題沒有普遍適用的答案。您讀到的任何單一比例，都是在與您不同的硬體上測得的。速度取決於特定 CPU 型號、分配給您的核心數量、供應商如何處理租戶之間的資源競爭，以及工作負載對向量指令的利用程度。請針對實際要選擇的兩個方案進行基準測試；如果可以，請使用自己的工作負載，然後比較測試數據。

將 production 伺服器移轉至 arm64 前，應檢查哪些項目？

請依以下順序進行 4 項檢查。確認每個容器映像檔都有 arm64 manifest。確認每個第三方 apt repository 都發布 binary-arm64。確認每個 closed-source agent 都提供 aarch64 下載檔。接著在目標 instance 上執行 getconf PAGESIZE，因為 64 KiB page kernel 會改變具有大量小型 mapping 的程序記憶體占用量。任何一項檢查失敗，都是讓該伺服器繼續使用 x86 的理由。