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

Những 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 là vấn đề 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 phải có khả năng tự build lại.

Hầu hết stack hiện đại đều đáp ứng yêu cầu này mà không cần chỉnh sửa. Lỗi thường tập trung ở 2 nơi: các container image trước đây chỉ được build cho một kiến trúc, 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 bạn kiểm tra cả hai vấn đề trên stack của mình trước khi trả phí cho một instance. Nếu bạn vẫn đang xác định loại máy chủ 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: các tên này có nghĩa gì

Chạy các lệnh sau trên mọi instance 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 dùng các tên khác nhau cho cùng một tập lệnh, vì vậy aarch64 và arm64 chỉ một loại, còn x86_64 và amd64 chỉ loại kia. Docker dùng cách đặt tên của Debian, nên platform của image có dạng linux/arm64.

Trên arm64 không có dòng model name trong /proc/cpuinfo. Thay vào đó, bạn sẽ thấy trường Features, trong đó 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 có tác dụng tương tự AES-NI trên CPU Intel và AMD: tăng tốc TLS (transport layer security) và mã hóa đĩa 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 kiến trúc.

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

Mỗi Docker image manifest đều ghi lại kiến trúc 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 xuất hiện 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à việc kernel từ chối chạy file vì header ELF (định dạng thực thi và liên kết) chỉ ra một loại máy mà CPU này không hỗ trợ. Không có thiết lập nào sửa được lỗi này. Tập lệnh đó không tồn tại trong phần cứng.

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 linux/amd64 và linux/arm64. Nếu thiếu 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à hành vi có thể thay đổi giữa các bản release, nên ưu tiên imagetools.

Với các image tự build, hãy build cả hai kiến trúc trong một command rồi push một manifest list:

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

Build cho kiến trúc khác trên một host duy nhất cần QEMU user mode emulation được đăng ký với kernel thông qua handler binfmt_misc:

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

Dùng emulation để build và test. Không dùng emulation để phục vụ traffic. Tài liệu của Docker nêu rằng emulation với QEMU “có thể chậm hơn nhiều so với build native, đặc biệt với các tác vụ nặng về tính toán như biên dịch và nén hoặc giải nén”, vì vậy một service x86 chạy emulation trên instance ARM sẽ làm mất khoản tiết kiệm 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 kiến trúc: chạy Docker trên một VPS trình bày phần này, và một file Compose 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ó tồn tại 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 có thiếu package.

Truy vấn trực tiếp bằng apt 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 bật cung cấp bản build của package đó cho kiến trúc này. apt-get install -s mô phỏng việc cài đặt nhưng không ghi thay đổi nào; trong cùng trường hợp, lệnh kết thúc với E: Unable to locate package.

Sau đó đọc output của apt update thay vì cuộn qua. Repository của vendor chỉ hỗ trợ amd64 sẽ ghi 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ả source entry. Một dòng được pin bằng [arch=amd64] sẽ bị bỏ qua trên host arm64, nên package có vẻ bị thiếu trong khi nguyên nhân thật sự là pin.

Những workload nào an toàn và 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, API Node, binary Go chạy phía sau Nginx hoặc database Postgres đều là những workload thông thường trên arm64.

Compiler just in time (JIT) tạo machine code trong lúc chương trình chạy, nên cần 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. 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ừ nhiều năm trước, hãy kiểm tra release notes của bản đó để 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 x86 assembly 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 cũng có nhánh NEON (NEON là tập lệnh vector của ARM) hoặc fallback bằng C thuần, 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 dựa trên một bài viết.

Phần mềm 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 cho arm64 thì bạn không thể xử lý bằng cách khác. cPanel và WHM là ví dụ 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 vẫn phải 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 khiến bạn chưa chuyển đổi, 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: ARM instance vẫn khác nhau ở đâu

Server x86-64 gần như có thể thay thế cho nhau. Server ARM ít đồng nhất hơn, và những khác biệt này 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 môi trường production. Phần lớn kernel arm64 dùng page 4 KiB, giống x86-64. Một số kernel dùng 64 KiB. Red Hat Enterprise Linux 8 cho aarch64 mặc định dùng kernel với page 64 KiB, còn RHEL 9 chuyển mặc định về 4 KiB và vẫn cung cấp package kernel-64k riêng cho workload cần kích thước lớn hơn. Page 64 KiB làm tăng mức memory tối thiểu của process có nhiều mapping nhỏ, vì chunk nhỏ nhất kernel có thể cấp phát lớn hơn 16 lần. Chạy getconf PAGESIZE trên instance và đọc giá trị, thay vì tự giả định.

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

Nền tảng máy chủ 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 dựng arm64 được hỗ trợ đầy đủ, còn các image chính thức trên Docker Hub mặc nhiên hỗ trợ nhiều kiến trúc.

Bằng chứng rõ nhất gần đây là Proxmox. Ngày 5 August 2026, Proxmox công bố bản arm64 đầu tiên của Proxmox Virtual Environment được hỗ trợ chính thức, phiên bản 9.2. 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ông cụ tương đồng với x86-64, ngoại trừ một số ít mục riêng cho từng kiến trúc.

Hãy đọc các điểm hạn chế trong chính thông báo đó. Chúng cho thấy phần cứng máy chủ ARM được hỗ trợ chính thức hiện vẫn rất hạn chế. Proxmox đã xác thực các hệ thống NVIDIA Grace và NVIDIA Vera ngay từ ngày đầu, sau khi thử nghiệm chung 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ựa trên UEFI chỉ được hỗ trợ theo nguyên tắc best effort. Các máy tính single-board chỉ dùng device tree như Raspberry Pi không được hỗ trợ. Guest chỉ chạy được trên node có cùng kiến trúc với nó. Live migration chỉ hoạt động giữa các node cùng kiến trúc. Cluster có kiến trúc hỗn hợp 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 với cùng vòng đời như x86-64 là bước tiến thực sự của nền tảng này. Nhưng danh sách phần cứng được hỗ trợ ngay từ ngày đầu chỉ gồm hai họ CPU.

Checklist cần thực hiện trước khi quyết định

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 đều có 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 sử dụng 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 sẽ không đưa ra cho bạn tỷ lệ hiệu năng trên giá giữa ARM và x86. Giá mỗi core khác nhau 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 thể dự đoán kết quả trên hệ thống của bạn. Hãy tự đ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 một phương pháp có thể lặp lại, còn chi phí thực tế của một VPS trình bày khía cạnh giá của phép so sánh. Storage là một quyết định riêng 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ó entry 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. Các image chính thức trên Docker Hub thường hỗ trợ nhiều kiến trúc. Image từ các vendor nhỏ hơn và 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 dùng được cho 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 khai báo loại máy khác và từ chối thực thi. Trên host arm64, điều này gần như luôn có nghĩa là binary hoặc container image x86-64. Docker sẽ in cảnh báo trước, cho biết platform của image được yêu cầu là linux/amd64 nhưng không khớp với platform của host được phát hiện là linux/arm64/v8. Cách khắc phục là build cho đúng kiến trúc. Không có thay đổi cấu hình nào giúp 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 instruction set 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 platform string của Docker, dùng arm64. Phía còn lại cũng có cách phân biệt tương tự: uname -m có nghĩa là 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?

Không có câu trả lời chung cho câu hỏi này. Mọi tỷ lệ đơn lẻ bạn đọc được đều được đo trên phần cứng không phải máy của bạn. Tốc độ phụ thuộc vào model CPU cụ thể, số core được cấp, cách provider xử lý tranh chấp tài nguyên giữa các tenant và mức độ workload của bạn tận dụng được vector instruction. Hãy benchmark hai plan 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 số liệu đó.

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

Có 4 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 vượt qua một trong 4 kiểm tra này đều là lý do để giữ server đó trên x86.