VPS ARM czy x86: różnice i kompatybilność oprogramowania

Co zmienia się po przejściu na VPS z architekturą ARM

VPS z architekturą ARM uruchamia ten sam system Linux i ten sam serwer Nginx co VPS x86, a zazwyczaj kosztuje mniej w przeliczeniu na rdzeń. Ryzyko przy zmianie wiąże się z kompatybilnością. Program skompilowany dla x86-64 nie uruchomi się na arm64, dlatego każdy element stosu oprogramowania musi posiadać wersję dla arm64 lub umożliwiać samodzielną kompilację.

Większość nowoczesnych stosów przechodzi ten test bez dodatkowej pracy. Problemy pojawiają się głównie w dwóch przypadkach: obrazy kontenerów zbudowane wyłącznie dla jednej architektury oraz oprogramowanie o zamkniętym kodzie źródłowym bez wersji dla arm64. Poniższe polecenia pozwalają sprawdzić oba te aspekty dla własnego stosu przed opłaceniem instancji. Jeśli nadal ustalasz, jakiego rodzaju serwera potrzebujesz, zacznij od czym jest VPS i czym różni się od hostingu współdzielonego.

arm64, aarch64, amd64: co oznacza każda z nazw

Uruchom poniższe polecenia na każdej instancji przed wykonaniem jakichkolwiek innych czynności.

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

uname -m wyświetla aarch64 na maszynie ARM oraz x86_64 na maszynie z procesorem Intel lub AMD. dpkg --print-architecture wyświetla arm64 oraz amd64 dla tych samych dwóch typów maszyn. Obie odpowiedzi są poprawne. Jądro Linux oraz system pakietów Debian przyjęły różne nazewnictwo dla tego samego zestawu instrukcji, dlatego aarch64 i arm64 oznaczają to samo, podobnie jak x86_64 i amd64. Docker stosuje nazewnictwo w stylu Debiana, dlatego platforma obrazu jest odczytywana jako linux/arm64.

W architekturze arm64 w pliku /proc/cpuinfo nie występuje linia model name. Zamiast niej dostępny jest wiersz Features, w którym sprzętowe wsparcie kryptograficzne widoczne jest jako flagi, takie jak aes pmull sha1 sha2. Są to rozszerzenia kryptograficzne ARMv8 (ARMv8 Cryptographic Extensions), które pełnią tę samą funkcję co AES-NI w jednostkach Intel i AMD: zapewniają sprzętowe przyspieszenie dla TLS (transport layer security) oraz szyfrowania dysków. Artykuł Sprawdzanie sprzętowej akceleracji AES na VPS zawiera opis testu dla obu architektur.

Dlaczego kontenery ulegają awarii jako pierwsze i jak wygląda ten błąd

Każdy manifest obrazu Docker rejestruje architekturę, dla której został zbudowany. Pobranie obrazu posiadającego tylko manifest amd64 na hosta arm64 kończy się sukcesem. Awaria następuje przy próbie uruchomienia pierwszego procesu:

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 oznacza, że jądro odmawia wykonania pliku, ponieważ jego nagłówek ELF (executable and linkable format) wskazuje typ maszyny, którego ten procesor nie obsługuje. Żadne ustawienie tego nie naprawi. Instrukcje nie znajdują się w krzemie.

Sprawdź manifest przed wdrożeniem:

docker buildx imagetools inspect nginx:1.27

Dane wyjściowe wyświetlają jedną linię Platform: dla każdego obrazu na liście manifestów, na przykład linux/amd64 oraz linux/arm64. Jeśli linux/arm64 jest nieobecne, dany tag nie uruchomi się na VPS z architekturą ARM. docker manifest inspect --verbose nginx:1.27 pokazuje te same informacje, jednak Docker dokumentuje docker manifest jako polecenie eksperymentalne, którego zachowanie może ulec zmianie pomiędzy wydaniami, dlatego należy preferować imagetools.

W przypadku obrazów budowanych samodzielnie, zbuduj obie architektury za pomocą jednego polecenia i wypchnij listę manifestów:

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

Budowanie dla obcej architektury na pojedynczym hoście wymaga emulacji trybu użytkownika QEMU zarejestrowanej w obsłudze binfmt_misc jądra systemu:

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

Używaj emulacji do budowania i testowania. Nie używaj jej do obsługi ruchu sieciowego. Dokumentacja Docker stwierdza, że emulacja za pomocą QEMU "może być znacznie wolniejsza niż natywne kompilacje, szczególnie w przypadku zadań wymagających dużej mocy obliczeniowej, takich jak kompilacja oraz kompresja lub dekompresja", więc emulowana usługa x86 na instancji ARM niweluje oszczędności, które skłoniły do migracji. Konfiguracja hosta dla przypadku natywnego jest identyczna na obu architekturach: uruchamianie Docker na VPS omawia ten proces, a istniejący plik Compose działa bez zmian, gdy każdy zawarty w nim obraz posiada manifest arm64.

Czy wymagane pakiety istnieją dla architektury arm64?

Ubuntu oraz Debian kompilują niemal całe archiwum dla architektury arm64, dlatego apt install nginx postgresql redis-server zachowuje się identycznie na obu architekturach. Braki występują głównie w repozytoriach zewnętrznych.

Należy zapytać bezpośrednio narzędzie apt na instancji ARM:

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

apt-cache policy zgłaszające Candidate: (none) oznacza, że żadne aktywne repozytorium nie udostępnia kompilacji danego pakietu dla tej architektury. apt-get install -s symuluje instalację bez wprowadzania zmian, a w takim przypadku kończy się komunikatem E: Unable to locate package.

Następnie należy przeanalizować wynik polecenia apt update zamiast go przewijać. Repozytorium dostawcy ograniczone do architektury amd64 informuje o tym wprost:

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

Repozytorium jest skonfigurowane i dostępne, jednak nie zawiera niczego, co można zainstalować na tej maszynie. Należy również sprawdzić sam wpis źródłowy. Linia z przypięciem [arch=amd64] jest pomijana na hoście arm64, przez co pakiet wydaje się niedostępny, podczas gdy rzeczywistą przyczyną jest właśnie to przypięcie.

Które obciążenia są bezpieczne, a które wymagają wcześniejszej weryfikacji

Środowiska uruchomieniowe oparte na interpretacji kodu oraz bajtkodzie są z założenia przenośne. PHP, Python, Ruby oraz Node.js posiadają pakiety arm64 w głównych dystrybucjach. Go oraz Rust umożliwiają kompilację skrośną dla arm64 poprzez ustawienie jednego celu. Stos LEMP, API w Node, binaria Go za Nginx czy baza danych Postgres to standardowe obciążenia na architekturze arm64.

Kompilator JIT (Just-In-Time) generuje kod maszynowy w trakcie działania programu, dlatego wymaga generatora kodu dla docelowej architektury. Bieżące wersje posiadają takie wsparcie: OpenJDK, .NET, silnik V8 wewnątrz Node.js oraz PyPy obsługują arm64 w systemie Linux. Prawdziwym zagrożeniem są przypięte stare wersje oprogramowania. Skrypt wdrożeniowy instalujący wydanie środowiska sprzed kilku lat powinien zostać zweryfikowany pod kątem informacji o wsparciu aarch64, zamiast zakładać, że zadziała poprawnie.

Biblioteki zawierające ręcznie pisany kod asemblera x86 lub instrukcje SSE i AVX stanowią mniej oczywisty przypadek. Większość z nich posiada ścieżkę NEON (NEON to zestaw instrukcji wektorowych ARM) lub alternatywną implementację w języku C, dzięki czemu kompilują się i działają. Wydajność może różnić się od wersji x86 w obie strony. Należy zmierzyć ją na własnej instancji, zamiast przewidywać wyniki na podstawie artykułów.

Oprogramowanie o zamkniętym kodzie źródłowym stanowi rzeczywistą przeszkodę. Agent monitorujący dostawcy, licencjonowany sterownik bazy danych, komercyjny panel sterowania czy demon antywirusowy są dostarczane jako skompilowane binaria. Jeśli dostawca nie opublikował wersji arm64, nie ma możliwości obejścia tego ograniczenia. cPanel oraz WHM to najbardziej wyrazisty przykład w hostingu: wymagania systemowe wskazują na x86_64 i nie wymieniają ARM, dlatego serwer z panelem sterowania musi pozostać na x86 (stan na sierpień 2026, warto ponownie sprawdzić stronę wymagań dostawcy). Jeśli jest to jedyny czynnik powstrzymujący przed migracją, alternatywy dla cPanel, które warto uruchomić na VPS to punkt wyjścia, przy czym dla każdej z nich należy w ten sam sposób zweryfikować wsparcie architektury.

Jądra systemu i rozmiar strony: gdzie instancje ARM nadal się różnią

Serwery x86-64 są niemal wymienne. Serwery ARM wykazują mniejszą jednolitość, a różnice znajdują się poniżej poziomu aplikacji.

Rozmiar strony pamięci jest parametrem, który wpływa na środowisko produkcyjne. Większość jąder arm64 używa stron 4 KiB, podobnie jak x86-64. Niektóre korzystają z 64 KiB. System Red Hat Enterprise Linux 8 dla aarch64 domyślnie dostarczał jądro ze stronami 64 KiB, natomiast RHEL 9 przywrócił domyślną wartość 4 KiB, zachowując osobny pakiet kernel-64k dla obciążeń wymagających większego rozmiaru. Rozmiar strony 64 KiB podnosi minimalne zużycie pamięci przez proces z wieloma małymi mapowaniami, ponieważ najmniejszy blok przydzielany przez jądro jest szesnastokrotnie większy. Należy uruchomić getconf PAGESIZE na instancji i odczytać wartość, zamiast zakładać ją z góry.

Warto znać kilka mniejszych różnic. W architekturze arm64 nie istnieje pakiet mikrokodu procesora dla systemu operacyjnego, dlatego aktualizacje oprogramowania układowego pochodzą od dostawcy, a nie z apt. Serwery ARM uruchamiają się poprzez UEFI (unified extensible firmware interface) i opisują sprzęt za pomocą ACPI (advanced configuration and power interface). Niektóre funkcje x86 nie mają odpowiedników w ARM, w tym szyfrowanie pamięci AMD SEV oraz wirtualizacja GPU Intel GVT-g.

Czy platforma serwerowa ARM osiągnęła dojrzałość?

Pod względem oprogramowania, tak. Debian, Ubuntu, Fedora oraz RHEL dostarczają pełnowartościowe kompilacje arm64, a oficjalne obrazy w Docker Hub są standardowo wieloarchitektoniczne.

Najwyraźniejszym dowodem z ostatniego okresu jest Proxmox. W dniu 5 sierpnia 2026 Proxmox ogłosił pierwszą oficjalnie wspieraną edycję arm64 dla Proxmox Virtual Environment, wersję 9.2, współdzielącą repozytoria pakietów oraz cykl wydawniczy z edycją x86-64. Została ona zbudowana na bazie Debian 13.5 z jądrem Linux 7.0, QEMU 11.0, LXC 7.0 oraz ZFS 2.4, a konfiguracja i narzędzia są identyczne jak w wersji x86-64, poza niewielkim zestawem elementów specyficznych dla architektury.

Należy zapoznać się z zastrzeżeniami zawartymi w tym samym ogłoszeniu, ponieważ pokazują one, jak wąski jest nadal zakres oficjalnie wspieranego sprzętu serwerowego ARM. Proxmox zweryfikował systemy NVIDIA Grace oraz NVIDIA Vera w dniu premiery, po wspólnych testach z NVIDIA i Supermicro na sprzęcie Grace Hopper. Pozostały sprzęt ARMv8-A oraz ARMv9-A oparty na UEFI otrzymuje wsparcie w ramach najlepszych starań (best effort). Komputery jednopłytkowe oparte wyłącznie na Device Tree, takie jak Raspberry Pi, nie są wspierane. Maszyna wirtualna (guest) działa wyłącznie na węźle o tej samej architekturze, migracja na żywo działa tylko między węzłami o tej samej architekturze, a klastry o mieszanej architekturze nie są oficjalnie wspierane.

Jest to rzetelne stanowisko na sierpień 2026. Dostawca hypervisora wydający wersję arm64 w tym samym cyklu życia co x86-64 stanowi realny postęp dla tej platformy. Lista sprzętu wspieranego w dniu premiery obejmuje dwie rodziny procesorów.

Lista kontrolna przed zatwierdzeniem zmian

1. Uruchom uname -m na instancji testowej i potwierdź, że wyświetla aarch64.
2. Uruchom docker buildx imagetools inspect dla każdego obrazu w pliku Compose i potwierdź obecność linii linux/arm64 platform dla każdego z nich.
3. Uruchom apt update na instancji ARM i przeczytaj każde ostrzeżenie Skipping acquire, które zostanie wyświetlone.
4. Otwórz stronę pobierania dla każdego agenta o zamkniętym kodzie źródłowym, od którego zależy system, i wyszukaj kompilację arm64 lub aarch64 po nazwie.
5. Uruchom getconf PAGESIZE i zanotuj wynik przed określeniem zapotrzebowania na pamięć.
6. Przeprowadź własny benchmark zarówno na planie ARM, jak i na planie x86, pomiędzy którymi dokonujesz wyboru.

Czego ten wpis nie zakłada

Nie przedstawiamy stosunku ceny do wydajności dla architektury ARM w porównaniu z x86. Ceny za rdzeń różnią się w zależności od dostawcy i planu, a wyniki pomiarów na cudzym sprzęcie nie są miarodajne dla Twojej infrastruktury. Należy wykonać własne pomiary. Nasz przewodnik po benchmarkach VPS opisuje narzędzia sysbench oraz fio wraz z metodologią, którą można powtórzyć, a rzeczywiste koszty VPS omawiają kwestie cenowe w tym porównaniu. Wybór pamięci masowej jest niezależny od architektury procesora, a porównanie NVMe z SATA SSD na VPS wyjaśnia tę kwestię. Uruchom te same testy na obu planach, najlepiej z własnym obciążeniem, i podejmij decyzję w oparciu o uzyskane wyniki.

FAQ

Czy moje kontenery Docker będą działać na VPS z architekturą ARM?

Będą działać, jeśli każdy obraz w stosie posiada wpis linux/arm64 w swoim manifeście. Sprawdź każdy z nich za pomocą docker buildx imagetools inspect <image> i poszukaj linii Platform: linux/arm64. Oficjalne obrazy w Docker Hub zazwyczaj obsługują wiele architektur. Obrazy od mniejszych dostawców oraz obrazy zbudowane samodzielnie na maszynie x86 często tego nie robią. W przypadku własnych obrazów należy przeprowadzić ponowną budowę za pomocą docker buildx build --platform linux/amd64,linux/arm64 ... --push, aby jeden tag obsługiwał obie architektury.

Co oznacza exec format error na serwerze ARM?

Jądro systemu próbowało wykonać plik binarny, którego nagłówek ELF wskazuje na inny typ architektury, i odmówiło wykonania. Na hoście arm64 prawie zawsze oznacza to plik binarny lub obraz kontenera w architekturze x86-64. Docker najpierw wyświetla ostrzeżenie, informując, że żądana platforma obrazu linux/amd64 nie pasuje do wykrytej platformy hosta linux/arm64/v8. Rozwiązaniem jest budowa obrazu dla właściwej architektury. Żadna zmiana konfiguracji nie sprawi, że plik binarny x86-64 zadziała natywnie na ARM.

Czy arm64 to to samo co aarch64?

Tak. Są to dwie nazwy dla 64-bitowego zestawu instrukcji ARM. Jądro systemu zgłasza aarch64 poprzez uname -m, podczas gdy pakiety w systemach Debian i Ubuntu oraz ciągi platform w Docker używają arm64. Ten sam podział występuje po drugiej stronie, gdzie uname -m podaje x86_64, a nazewnictwo pakietów amd64. Jeśli strona pobierania oferuje tylko pliki aarch64, są to właściwe pliki dla maszyny, którą dpkg --print-architecture nazywa arm64.

Czy VPS z ARM jest szybszy niż VPS z x86?

To pytanie nie ma ogólnej odpowiedzi, a każda pojedyncza wartość, którą można przeczytać, została zmierzona na sprzęcie innym niż Twój. Szybkość zależy od konkretnego modelu procesora, liczby przydzielonych rdzeni, sposobu zarządzania współdzieleniem zasobów przez dostawcę oraz tego, jak dobrze obciążenie wykorzystuje instrukcje wektorowe. Przeprowadź testy porównawcze dla dwóch planów, między którymi wybierasz, najlepiej przy użyciu własnego obciążenia, i porównaj uzyskane wyniki.

Co należy sprawdzić przed przeniesieniem serwera produkcyjnego na arm64?

Cztery kroki weryfikacji w podanej kolejności. Potwierdź, że każdy obraz kontenera posiada manifest arm64. Potwierdź, że każde zewnętrzne repozytorium apt publikuje pakiety binary-arm64. Potwierdź, że każdy agent o zamkniętym kodzie źródłowym posiada wersję dla aarch64. Następnie uruchom getconf PAGESIZE na docelowej instancji, ponieważ jądro z rozmiarem strony 64 KiB zmienia zapotrzebowanie na pamięć w procesach z wieloma małymi mapowaniami. Każdy element, który nie przejdzie pomyślnie jednej z tych czterech kontroli, jest powodem, aby utrzymać dany serwer na architekturze x86.