ARM VPS 與 x86 VPS 差在哪裡？

移轉至 ARM VPS 後的變化

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

大多數現代堆疊無須額外處理即可通過相容性檢查。問題主要集中在兩個地方：只曾針對單一架構建置的容器映像檔，以及沒有 arm64 下載版本的閉源軟體。以下指令可在您租用執行個體前，針對自己的堆疊確認這兩點。如果您仍在確認需要哪一類伺服器，請先閱讀 VPS 是什麼，以及它與共用主機的差異。

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

先在任何 instance 上執行以下命令。

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

在 ARM 機器上，uname -m 會輸出 aarch64；在 Intel 或 AMD 機器上，則會輸出 x86_64。對同樣的兩台機器，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 硬體加速涵蓋兩種架構的測試方法。

容器為何會先失效，以及錯誤訊息的樣子

每個 Docker image manifest 都會記錄其建置目標架構。將只有 amd64 manifest 的 image pull 到 arm64 host 時，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（可執行與可連結格式）標頭指定的 machine type 並未由此 CPU 實作。沒有任何設定可以修正這個問題。這些指令不存在於該硬體中。

部署前先檢查 manifest：

docker buildx imagetools inspect nginx:1.27

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

對於自行建置的 image，請在單一命令中建置兩種架構，並 push manifest list：

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

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

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

請使用 emulation 進行建置與測試。不要用它來提供 network traffic。Docker 的官方文件指出，使用 QEMU 進行 emulation「可能比原生建置慢很多，尤其是編譯及壓縮或解壓縮等需要大量運算的工作」，因此在 ARM instance 上執行 emulated x86 服務，會抵銷促使你遷移的成本節省。在原生架構情境下，host 設定在兩種架構上完全相同：在 VPS 上執行 Docker 涵蓋相關內容；只要其中每個 image 都有 arm64 manifest，現有的 Compose file 即可直接使用。

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] 鎖定的項目會被略過，因此套件看似不存在，實際原因是 pin 設定。

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

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

即時編譯器（JIT）會在程式執行期間產生 machine code，因此需要支援目標架構的 code generator。目前的版本通常都已具備此能力：OpenJDK、.NET、Node.js 內的 V8 engine，以及 PyPy 都在 Linux 上支援 arm64。真正的風險是固定使用的舊版本。若 deploy script 會安裝數年前的 runtime release，應查閱該版本的 release notes，確認是否支援 aarch64，不要直接假設可以運作。

包含手寫 x86 assembly，或使用 SSE 與 AVX intrinsics 的 library，通常較不容易察覺問題。大多數 library 也具備 NEON 路徑（NEON 是 ARM 的向量指令集），或提供純 C fallback，因此仍可編譯與執行。效能可能比 x86 build 好，也可能較差。請在自己的 instance 上進行測量，不要根據文章內容預測結果。

閉源軟體才是實際的阻礙。廠商提供的 monitoring agent、licensed database driver、commercial control panel 或 anti-virus daemon 都是編譯後的 binary；如果廠商沒有發布 arm64 build，就無法自行解決。cPanel 和 WHM 是 hosting 領域最明顯的案例：其 system requirements 指定 x86_64，未列出 ARM，因此 control panel server 應維持使用 x86（已於 August 2026 查閱，但仍應重新確認廠商自己的 requirements page）。如果唯一阻礙就是這項軟體，值得在 VPS 上執行的 cPanel 替代方案是開始查找的地方，並以相同方式確認每個方案的 architecture support。

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

x86-64 伺服器幾乎可以互換使用。ARM 伺服器較不一致，差異存在於應用程式之下的系統層。

頁面大小是最可能影響正式環境的差異。大多數 arm64 核心使用 4 KiB 頁面，與 x86-64 相同。有些核心使用 64 KiB。Red Hat Enterprise Linux 8 for aarch64 預設採用 64 KiB 頁面的核心，而 RHEL 9 將預設值改回 4 KiB，同時保留個別的 kernel-64k 套件，供需要較大頁面大小的工作負載使用。對於具有大量小型記憶體映射的程序，64 KiB 頁面大小會提高記憶體下限，因為核心能配置的最小區塊大 16 倍。在執行個體上執行 getconf PAGESIZE 並讀取數值，不要自行假設。頁面大小不是唯一會影響你的核心決策，因為供應商提供的核心版本也會決定工作如何排程至核心，而 Linux 7.2 加入的快取感知排程 同樣會套用至 arm64 與 x86-64。

還有幾項較小的差異值得了解。arm64 沒有作業系統提供的 CPU 微碼套件，因此韌體更新由供應商提供，而不是透過 apt 取得。ARM 伺服器透過 UEFI（統一可延伸韌體介面）開機，並透過 ACPI（進階組態與電源介面）描述硬體。部分 x86 功能完全沒有 ARM 對應項目，包括 AMD SEV 記憶體加密和 Intel GVT-g mediated GPU。

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

就軟體而言，是的。Debian、Ubuntu、Fedora 和 RHEL 都提供完整支援的 arm64 組建，Docker Hub 上的官方映像檔也通常都是 multi-arch。

最近最明確的證據是 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 硬體則僅提供 best effort 支援。僅支援 device tree 的單板電腦，例如 Raspberry Pi，不在支援範圍內。Guest 只能在相同架構的 node 上執行，live migration 也只能在相同架構的 node 之間運作，混合架構叢集則不受正式支援。

截至 2026 年 8 月，實際情況就是如此。Hypervisor 廠商以與 x86-64 相同的生命週期發布 arm64 版本，確實代表平台有所進展。但首日支援的硬體清單只有兩個 CPU 家族。

提交前的檢查清單

1. 在測試執行個體上執行 uname -m，確認輸出 aarch64。
2. 對 Compose 檔案中的每個映像執行 docker buildx imagetools inspect，確認每個映像都輸出一行 linux/arm64 平台資訊。
3. 在 ARM 執行個體上執行 apt update，逐一閱讀輸出的 Skipping acquire 警告。
4. 開啟所依賴之每個封閉原始碼代理程式的下載頁面，依名稱尋找 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 重新建置，讓同一個標籤同時支援兩種架構。

ARM 伺服器上的 exec format error 是什麼意思？

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

arm64 和 aarch64 是同一回事嗎？

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

ARM VPS 比 x86 VPS 快嗎？

這個問題沒有通用答案。您看到的任何單一比例，都是在與您的硬體不同的環境中測得。速度取決於具體的 CPU 型號、您獲配的核心數量、供應商如何處理租戶之間的資源競用，以及工作負載對向量指令的使用程度。如果可以，請使用自己的工作負載，對實際考慮中的兩個方案進行基準測試，再比較測試結果。

將正式環境伺服器移轉至 arm64 前，應檢查哪些事項？

依序進行以下 4 項檢查。確認每個容器映像檔都有 arm64 manifest。確認每個第三方 apt 套件庫都發布 binary-arm64。確認每個閉源代理程式都有 aarch64 下載版本。接著在目標執行個體上執行 getconf PAGESIZE，因為 64 KiB 頁面大小的核心會改變具有大量小型映射之程序的記憶體使用量。任何一項檢查失敗，都是讓該伺服器繼續使用 x86 的理由。