ARM VPS và x86 VPS khác nhau ở điểm nào?

Điều gì thay đổi khi chuyển sang ARM VPS

ARM VPS chạy cùng Linux và cùng Nginx như VPS x86, đồng thời thường có chi phí trên mỗi core thấp hơn. Rủi ro khi chuyển đổi nằm ở khả năng tương thích. Một chương trình được biên dịch cho x86-64 hoàn toàn không thể chạy trên arm64, vì vậy mọi phần mềm trong stack của bạn phải có bản build arm64 hoặc có thể tự build lại.

Hầu hết stack hiện đại đều vượt qua yêu cầu này mà không cần xử lý thêm. Lỗi thường tập trung ở 2 nơi: các container image trước đây chỉ được build cho một architecture, và phần mềm mã nguồn đóng không có bản tải xuống cho arm64. Các lệnh dưới đây giúp kiểm tra cả 2 vấn đề trên với stack của bạn trước khi thuê một instance. Nếu bạn vẫn đang xác định loại server cần dùng, hãy bắt đầu với VPS là gì và khác shared hosting như thế nào.

arm64, aarch64, amd64: tên nào có nghĩa gì

Chạy các lệnh này trên bất kỳ instance nào trước khi làm việc khác.

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

uname -m in aarch64 trên máy ARM và x86_64 trên máy Intel hoặc AMD. dpkg --print-architecture in arm64 và amd64 trên hai loại máy tương ứng. Cả hai kết quả đều đúng. Linux kernel và hệ thống đóng gói Debian chọn các tên khác nhau cho cùng một instruction set, nên aarch64 và arm64 chỉ cùng một thứ, còn x86_64 và amd64 chỉ thứ còn lại. Docker dùng tên theo kiểu Debian, nên platform của image hiển thị là linux/arm64.

Trên arm64 không có dòng model name trong /proc/cpuinfo. Thay vào đó, bạn nhận được một field Features, và hardware crypto xuất hiện ở đó dưới dạng các flag như aes pmull sha1 sha2. Đây là ARMv8 Cryptographic Extensions. Chúng thực hiện cùng vai trò với AES-NI trên các CPU Intel và AMD: tăng tốc TLS (transport layer security) và mã hóa disk bằng phần cứng. Kiểm tra hardware acceleration cho AES trên VPS trình bày cách kiểm tra trên cả hai architecture.

Vì sao container lỗi trước tiên và lỗi hiển thị như thế nào

Mỗi Docker image manifest đều ghi lại architecture mà image được build cho. Nếu pull một image chỉ có manifest amd64 trên host arm64, thao tác pull vẫn thành công. Lỗi xảy ra khi process đầu tiên khởi động:

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 là kernel từ chối chạy file vì header ELF (executable and linkable format) khai báo một machine type mà CPU này không hỗ trợ. Không có setting nào sửa được lỗi này. Các instruction đó không tồn tại trong silicon.

Kiểm tra manifest trước khi deploy:

docker buildx imagetools inspect nginx:1.27

Output liệt kê một dòng Platform: cho mỗi image trong manifest list, chẳng hạn như linux/amd64 và linux/arm64. Nếu không có linux/arm64, tag đó sẽ không khởi động trên ARM VPS. docker manifest inspect --verbose nginx:1.27 hiển thị cùng thông tin, nhưng Docker ghi rõ docker manifest là command thử nghiệm và behaviour có thể thay đổi giữa các release, vì vậy nên dùng imagetools.

Với image tự build, hãy build cả hai architecture trong một command rồi push manifest list:

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

Build cho architecture khác trên một host duy nhất cần QEMU user mode emulation được đăng ký với binfmt_misc handler của kernel:

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

Dùng emulation để build và test. Không dùng emulation để phục vụ network traffic. Tài liệu chính thức của Docker nêu rằng emulation bằng QEMU “có thể chậm hơn nhiều so với native build, đặc biệt với các tác vụ nặng về tính toán như compile và nén hoặc giải nén”, vì vậy một service x86 chạy bằng emulation trên instance ARM sẽ làm mất phần lợi ích khiến bạn chuyển sang ARM. Thiết lập host cho trường hợp native giống nhau trên cả hai architecture: chạy Docker trên VPS đã trình bày phần này, và Compose file hiện có sẽ hoạt động không cần thay đổi khi mọi image trong đó đều có manifest arm64.

Các package tôi cần có trên arm64 không?

Ubuntu và Debian build gần như toàn bộ archive cho arm64, nên apt install nginx postgresql redis-server hoạt động giống nhau trên cả hai kiến trúc. Các repository bên thứ ba mới là nơi thường thiếu package.

Chạy apt trực tiếp trên instance ARM:

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

apt-cache policy báo Candidate: (none) nghĩa là không có repository nào đang được enable phát hành bản build của package đó cho kiến trúc này. apt-get install -s mô phỏng quá trình cài đặt và không ghi thay đổi nào; trong cùng trường hợp, lệnh kết thúc bằng E: Unable to locate package.

Sau đó đọc output của apt update thay vì bỏ qua nó. Repository của vendor chỉ hỗ trợ amd64 sẽ báo rõ điều đó:

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

Repository đã được cấu hình và có thể truy cập, nhưng không chứa package nào mà máy này có thể cài đặt. Hãy kiểm tra cả chính source entry. Một dòng được ghim bằng [arch=amd64] sẽ bị bỏ qua trên host arm64, nên package trông như bị thiếu trong khi nguyên nhân thực sự là pin.

Những workload nào an toàn và những workload nào cần kiểm tra trước

Các runtime thông dịch và bytecode vốn được thiết kế để có tính portable. PHP, Python, Ruby và Node.js đều có package arm64 trong các bản phân phối chính. Go và Rust có thể cross-compile sang arm64 bằng cách đặt một target. LEMP stack, Node API, binary Go chạy phía sau Nginx hoặc database Postgres đều là các workload thông thường trên arm64.

Trình biên dịch just-in-time (JIT) tạo machine code trong khi chương trình chạy, nên cần có code generator cho architecture đích. Các phiên bản hiện tại đều có code generator này: OpenJDK, .NET, engine V8 bên trong Node.js và PyPy đều hỗ trợ arm64 trên Linux. Các phiên bản cũ bị pin mới là rủi ro thực sự. Nếu deploy script cài một bản runtime đã phát hành từ vài năm trước, hãy kiểm tra ghi chú của chính bản release đó để xác nhận hỗ trợ aarch64, thay vì mặc định cho rằng nó sẽ hoạt động.

Các library chứa assembly x86 viết thủ công hoặc intrinsic SSE và AVX là trường hợp khó nhận biết hơn. Phần lớn vẫn có nhánh NEON (NEON là tập lệnh vector của ARM) hoặc fallback C thông thường, nên vẫn compile và chạy được. Hiệu năng có thể cao hơn hoặc thấp hơn bản build x86. Hãy đo trực tiếp trên instance của bạn thay vì dự đoán từ một bài viết.

Software mã nguồn đóng mới là blocker thực sự. Monitoring agent của vendor, licensed database driver, commercial control panel hoặc anti-virus daemon được cung cấp dưới dạng compiled binary. Nếu vendor không phát hành bản build arm64 thì bạn không thể tự xử lý vấn đề này. cPanel và WHM là trường hợp rõ nhất trong lĩnh vực hosting: system requirements của sản phẩm chỉ nêu x86_64 và không liệt kê ARM, nên server chạy control panel phải tiếp tục dùng x86 (đã kiểm tra vào August 2026 và vẫn nên đọc lại trên trang requirements chính thức của vendor). Nếu đây là yếu tố duy nhất đang cản bạn, các lựa chọn thay thế cPanel đáng chạy trên VPS là nơi nên bắt đầu; hãy kiểm tra architecture support của từng lựa chọn theo cùng cách đó.

Kernel và kích thước page: các instance ARM vẫn khác nhau ở đâu

Server x86-64 gần như có thể thay thế cho nhau. Server ARM kém đồng nhất hơn, và khác biệt nằm bên dưới ứng dụng của bạn.

Kích thước page là khác biệt ảnh hưởng trực tiếp đến production. Phần lớn kernel arm64 dùng page 4 KiB, giống x86-64. Một số kernel dùng page 64 KiB. Red Hat Enterprise Linux 8 cho aarch64 phát hành kernel dùng page 64 KiB theo mặc định, còn RHEL 9 đưa mặc định trở lại 4 KiB và vẫn giữ một package kernel-64k riêng cho workload cần kích thước lớn hơn. Kích thước page 64 KiB làm tăng mức memory tối thiểu của tiến trình có nhiều mapping nhỏ, vì chunk nhỏ nhất kernel có thể cấp phát lớn hơn mười sáu lần. Chạy getconf PAGESIZE trên instance và đọc giá trị, thay vì tự giả định. Kích thước page không phải quyết định duy nhất của kernel ảnh hưởng đến bạn, vì version do provider phát hành cũng quyết định cách công việc được lập lịch trên các core, và cơ chế lập lịch nhận biết cache được thêm vào Linux 7.2 có trên cả arm64 và x86-64.

Có một số khác biệt nhỏ hơn cũng đáng biết. arm64 không có package microcode CPU ở cấp hệ điều hành, nên firmware update đến từ provider chứ không phải từ apt. Server ARM boot qua UEFI (unified extensible firmware interface) và mô tả phần cứng bằng ACPI (advanced configuration and power interface). Một số tính năng của x86 hoàn toàn không có counterpart trên ARM, trong đó có mã hóa memory AMD SEV và GPU mediated Intel GVT-g.

Nền tảng server ARM đã trưởng thành chưa?

Về phần mềm thì có. Debian, Ubuntu, Fedora và RHEL đều phát hành bản build arm64 chính thức, còn các image chính thức trên Docker Hub đương nhiên hỗ trợ multi-arch.

Bằng chứng rõ nhất gần đây là Proxmox. Ngày 5 August 2026, Proxmox công bố phiên bản arm64 được hỗ trợ chính thức đầu tiên của Proxmox Virtual Environment, phiên bản 9.2. Phiên bản này dùng chung package repository và vòng đời phát hành với bản x86-64. Nó được xây dựng trên Debian 13.5, với Linux 7.0, QEMU 11.0, LXC 7.0 và ZFS 2.4. Cấu hình và các công cụ tương đồng với x86-64, ngoại trừ một số ít mục dành riêng cho kiến trúc.

Hãy đọc các giới hạn trong chính thông báo đó. Chúng cho thấy phần cứng server ARM được hỗ trợ chính thức vẫn còn rất hạn chế. Proxmox đã kiểm thử và hỗ trợ NVIDIA Grace và NVIDIA Vera ngay từ ngày đầu, sau quá trình phối hợp kiểm thử với NVIDIA và Supermicro trên phần cứng Grace Hopper. Các phần cứng ARMv8-A và ARMv9-A khác dùng UEFI chỉ được hỗ trợ best effort. Các single-board computer chỉ dùng device tree như Raspberry Pi không được hỗ trợ. Guest chỉ chạy trên node có cùng kiến trúc với guest. Live migration chỉ hoạt động giữa các node cùng kiến trúc. Cluster hỗn hợp nhiều kiến trúc không được hỗ trợ chính thức.

Đó là tình hình thực tế tính đến August 2026. Việc một nhà cung cấp hypervisor phát hành arm64 theo cùng vòng đời với x86-64 là bước tiến thực sự của nền tảng này. Danh sách phần cứng được hỗ trợ ngay từ ngày đầu chỉ gồm 2 họ CPU.

Checklist cần thực hiện trước khi commit

1. Chạy uname -m trên một instance thử nghiệm và xác nhận lệnh in ra aarch64.
2. Chạy docker buildx imagetools inspect trên mọi image trong file Compose và xác nhận mỗi image có một dòng platform linux/arm64.
3. Chạy apt update trên instance ARM và đọc mọi cảnh báo Skipping acquire mà lệnh in ra.
4. Mở trang download của từng agent mã nguồn đóng mà bạn phụ thuộc vào và tìm bản build arm64 hoặc aarch64 theo tên.
5. Chạy getconf PAGESIZE và ghi lại kết quả trước khi tính dung lượng memory.
6. Tự chạy benchmark trên cả plan ARM và plan x86 mà bạn đang cân nhắc.

Những điều bài viết này không khẳng định

Chúng tôi không đưa ra tỷ lệ hiệu năng trên giá giữa ARM và x86. Giá mỗi core thay đổi tùy provider và plan, còn một con số đo trên phần cứng của người khác không dự đoán được kết quả trên hệ thống của bạn. Hãy tự đo thay vì dựa vào đó. Hướng dẫn benchmark VPS của chúng tôi trình bày cách dùng sysbench và fio với phương pháp có thể lặp lại, còn chi phí thực tế của một VPS đề cập đến khía cạnh giá trong phép so sánh. Storage là quyết định độc lập với kiến trúc CPU, và NVMe so với SATA SSD trên VPS như thế nào xử lý phần đó. Hãy chạy cùng một bài test trên cả hai plan, dùng workload của chính bạn nếu có thể, rồi để các số liệu của bạn quyết định.

FAQ

Container Docker của tôi có chạy trên ARM VPS không?

Container sẽ chạy nếu mọi image trong stack đều có mục nhập linux/arm64 trong manifest. Kiểm tra từng image bằng docker buildx imagetools inspect <image> và tìm dòng Platform: linux/arm64. Image chính thức trên Docker Hub thường hỗ trợ nhiều kiến trúc. Image từ các nhà cung cấp nhỏ hơn, cũng như image bạn tự build trên máy x86, thường không hỗ trợ. Với image của riêng bạn, hãy build lại bằng docker buildx build --platform linux/amd64,linux/arm64 ... --push để một tag phục vụ cả hai kiến trúc.

exec format error có nghĩa là gì trên máy chủ ARM?

Kernel đã cố thực thi một binary có ELF header chỉ định loại máy khác và từ chối thực thi. Trên host arm64, điều này hầu như luôn có nghĩa là binary hoặc container image x86-64. Docker trước tiên sẽ in cảnh báo rằng platform của image được yêu cầu là linux/amd64, không khớp với platform của host được phát hiện là linux/arm64/v8. Cách xử lý là build cho đúng kiến trúc. Không có thay đổi cấu hình nào khiến binary x86-64 chạy native trên ARM.

arm64 có giống aarch64 không?

Có. Đây là hai tên gọi của tập lệnh ARM 64-bit. Kernel báo cáo aarch64 thông qua uname -m, còn hệ thống package của Debian và Ubuntu, cùng các chuỗi platform của Docker, dùng arm64. Sự khác biệt tương tự cũng tồn tại ở phía còn lại, trong đó uname -m cho biết x86_64 còn hệ thống package dùng amd64. Nếu trang download chỉ cung cấp file aarch64, đó là các file phù hợp với máy mà dpkg --print-architecture gọi là arm64.

ARM VPS có nhanh hơn x86 VPS không?

Câu hỏi này không có câu trả lời chung, và mọi tỷ lệ đơn lẻ bạn đọc được đều được đo trên phần cứng không phải của bạn. Tốc độ phụ thuộc vào model CPU cụ thể, số core bạn được cấp, cách nhà cung cấp xử lý tranh chấp tài nguyên giữa các tenant và mức độ workload của bạn sử dụng vector instruction. Hãy benchmark hai plan mà bạn thực sự đang cân nhắc, dùng workload của chính bạn nếu có thể, rồi so sánh các con số đó.

Tôi nên kiểm tra gì trước khi chuyển server production sang arm64?

Hãy thực hiện 4 bước kiểm tra theo thứ tự này. Xác nhận mọi container image đều có manifest arm64. Xác nhận mọi apt repository của bên thứ ba đều phát hành binary-arm64. Xác nhận mọi agent closed source đều có bản download aarch64. Sau đó chạy getconf PAGESIZE trên instance đích, vì kernel dùng page 64 KiB làm thay đổi memory footprint của các process có nhiều mapping nhỏ. Bất kỳ thành phần nào không đạt một trong 4 bước kiểm tra này đều là lý do để giữ server đó trên x86.