ARM VPS чи x86 VPS: що реально змінюється

Що змінюється під час переходу на ARM VPS

ARM VPS працює на тій самій Linux і з тим самим Nginx, що й x86 VPS, і зазвичай коштує менше за ядро. Основний ризик переходу — сумісність. Програма, скомпільована для x86-64, взагалі не може працювати на arm64, тому кожен компонент вашого стека має мати збірку для arm64 або бути придатним для повторної компіляції.

Більшість сучасних стеків проходить цю перевірку без додаткових налаштувань. Проблеми зазвичай виникають у двох випадках: коли образи контейнерів створені лише для однієї архітектури та коли закрите програмне забезпечення не має версії для завантаження на arm64. Наведені нижче команди допоможуть перевірити обидва питання для вашого стека ще до оплати інстансу. Якщо ви ще визначаєтеся, який сервер вам потрібен, почніть із матеріалу що таке VPS і чим він відрізняється від shared hosting.

arm64, aarch64, amd64: яке позначення що означає

Виконайте ці команди на будь-якому інстансі перед усіма іншими діями.

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

uname -m виводить aarch64 на ARM-машині та x86_64 на машині з Intel або AMD. dpkg --print-architecture виводить arm64 і amd64 для цих самих двох машин. Обидві відповіді правильні. Ядро Linux і система пакування Debian використовують різні назви для того самого набору інструкцій, тому aarch64 і arm64 означають одне, а x86_64 і amd64 — інше. Docker використовує назви у стилі Debian, тому платформа образу має вигляд linux/arm64.

На arm64 у /proc/cpuinfo немає рядка model name. Замість нього є поле Features, де апаратне шифрування позначається прапорцями на кшталт aes pmull sha1 sha2. Це розширення криптографії ARMv8. Вони виконують ту саму функцію, що й AES-NI у процесорах Intel і AMD: прискорюють TLS (захист транспортного рівня) та шифрування диска апаратними засобами. У матеріалі Перевірка апаратного прискорення AES на VPS описано тестування для обох архітектур.

Чому контейнери виходять з ладу першими та який вигляд має помилка

У кожному маніфесті Docker image зазначено архітектуру, для якої його зібрано. Якщо завантажити image, який має лише маніфест amd64, на хост arm64, завантаження завершиться успішно. Помилка виникне під час першого запуску процесу:

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 — це відмова ядра запустити файл, оскільки його заголовок ELF (executable and linkable format) містить тип машини, який цей CPU не підтримує. Жодне налаштування не виправить проблему. У наборі інструкцій CPU немає потрібних інструкцій.

Перевірте маніфест перед розгортанням:

docker buildx imagetools inspect nginx:1.27

У виводі буде один рядок Platform: для кожного image у списку маніфестів, наприклад linux/amd64 і linux/arm64. Якщо linux/arm64 відсутній, цей tag не запуститься на ARM VPS. docker manifest inspect --verbose nginx:1.27 показує ту саму інформацію, але Docker позначає docker manifest як експериментальну команду, поведінка якої може змінюватися між випусками, тому надавайте перевагу imagetools.

Для image, які ви збираєте самостійно, зберіть обидві архітектури однією командою та передайте список маніфестів у registry:

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

Збирання для іншої архітектури на одному хості потребує емуляції QEMU у режимі user mode, зареєстрованої в ядрі через обробник binfmt_misc:

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

Використовуйте емуляцію для збирання та тестування. Не використовуйте її для обслуговування мережевого трафіку. У документації Docker зазначено, що емуляція з QEMU «може бути значно повільнішою за native builds, особливо для обчислювально інтенсивних завдань, як-от компіляція та стиснення або розпакування», тому емуляційний x86-сервіс на ARM-інстансі нівелює економію, заради якої ви виконали міграцію. Налаштування хоста для native case однакове в обох архітектурах: запуск Docker на VPS описує цей процес, а наявний Compose file працюватиме без змін, щойно кожен image у ньому матиме маніфест arm64.

Чи будуть потрібні мені пакети доступні для arm64?

Ubuntu і Debian збирають майже весь архів для arm64, тому apt install nginx postgresql redis-server працює однаково в обох архітектурах. Проблеми виникають переважно зі сторонніми репозиторіями.

Безпосередньо запитайте apt на ARM-інстансі:

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'

Репозиторій налаштований і доступний, але не містить нічого, що ця машина може встановити. Також перевірте сам запис джерела. Рядок із прив’язкою [arch=amd64] пропускається на хості arm64, тому пакет виглядає відсутнім, хоча справжня причина — ця прив’язка.

Які робочі навантаження безпечні, а які спочатку потрібно перевірити

Інтерпретовані середовища виконання та середовища виконання байткоду за задумом є переносними. PHP, Python, Ruby і Node.js мають пакети для arm64 в основних дистрибутивах. Go і Rust компілюють код для arm64 крос-компіляцією після вибору однієї цільової платформи. LEMP-стек, API на Node, бінарний файл Go за Nginx або база даних Postgres — це звичайні робочі навантаження на arm64.

JIT-компілятор створює машинний код під час виконання програми, тому йому потрібен генератор коду для цільової архітектури. У сучасних версіях такий генератор є: OpenJDK, .NET, рушій V8 у Node.js і PyPy підтримують arm64 у Linux. Основний ризик становлять зафіксовані старі версії. Скрипт розгортання, який встановлює версію середовища виконання, випущену кілька років тому, потрібно перевірити за примітками до цієї версії щодо підтримки aarch64, а не вважати, що вона працюватиме.

Бібліотеки з власноруч написаною асемблерною вставкою або інструкціями SSE та AVX — менш очевидний випадок. Більшість із них також мають реалізацію на NEON (NEON — це набір векторних інструкцій ARM) або резервну реалізацію на звичайному C, тому вони компілюються та працюють. Продуктивність може відрізнятися від збірки для x86 у будь-який бік. Виміряйте її на своєму інстансі, а не прогнозуйте за статтею.

Закрите програмне забезпечення є справжньою перешкодою. Агент моніторингу від постачальника, ліцензований драйвер бази даних, комерційна панель керування або daemon антивіруса постачається як скомпільований бінарний файл. Якщо постачальник не публікує збірку для arm64, самостійно вирішити це неможливо. cPanel і WHM — найочевидніший приклад у хостингу: у системних вимогах вказано x86_64, але ARM не зазначено. Тому сервер із панеллю керування слід залишати на x86 (перевірено у August 2026; вимоги варто повторно перевірити на сторінці вимог самого постачальника). Якщо саме це стримує перехід, почніть із альтернатив cPanel, які варто запускати на VPS і так само перевірте підтримку архітектури для кожної з них.

Ядра та розмір сторінки: де ARM-інстанси досі відрізняються

Сервери x86-64 майже взаємозамінні. Сервери ARM менш однорідні, і відмінності розташовані на рівні, нижчому за ваш застосунок.

Розмір сторінки — це відмінність, яка впливає на робоче середовище. Більшість ядер arm64 використовує сторінки розміром 4 KiB, як і x86-64. Деякі використовують 64 KiB. Red Hat Enterprise Linux 8 для aarch64 постачався з ядром із розміром сторінки 64 KiB за замовчуванням, а RHEL 9 повернув типовий розмір до 4 KiB, залишивши окремий пакет kernel-64k для робочих навантажень, яким потрібен більший розмір. Розмір сторінки 64 KiB підвищує мінімальний обсяг пам’яті для процесу з великою кількістю невеликих відображень, оскільки найменший блок, який може виділити ядро, у шістнадцять разів більший. Виконайте getconf PAGESIZE в інстансі та прочитайте отримане значення, а не робіть припущення.

Варто знати ще кілька менш суттєвих відмінностей. В arm64 немає пакета мікрокоду CPU для операційної системи, тому оновлення мікропрограми надходять від постачальника, а не з apt. Сервери ARM завантажуються через UEFI (unified extensible firmware interface) і описують апаратне забезпечення через ACPI (advanced configuration and power interface). Деякі функції x86 взагалі не мають відповідників в ARM, зокрема шифрування пам’яті AMD SEV і віртуалізовані GPU Intel GVT-g.

Чи стала ARM-серверна платформа зрілою?

На рівні програмного забезпечення — так. Debian, Ubuntu, Fedora і RHEL випускають повноцінні збірки arm64, а офіційні образи на Docker Hub зазвичай підтримують кілька архітектур.

Найпереконливіший недавній приклад — Proxmox. 5 August 2026 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, не підтримуються. Гість може працювати лише на вузлі з тією самою архітектурою. Жива міграція працює лише між вузлами з однаковою архітектурою. Кластери зі змішаними архітектурами офіційно не підтримуються.

Станом на August 2026 це чесна оцінка ситуації. Випуск hypervisor із arm64 у тому самому життєвому циклі, що й x86-64, є реальним прогресом для платформи. Перелік обладнання з підтримкою в день випуску охоплює дві родини процесорів.

Чекліст перед остаточним вибором

1. Виконайте uname -m на тестовому інстансі та переконайтеся, що команда виводить aarch64.
2. Виконайте docker buildx imagetools inspect для кожного образу у вашому Compose-файлі та переконайтеся, що для кожного з них виводиться рядок платформи linux/arm64.
3. Виконайте apt update на ARM-інстансі та прочитайте кожне попередження Skipping acquire, яке виводиться.
4. Відкрийте сторінку завантаження кожного пропрієтарного агента, від якого ви залежите, і перевірте, чи є збірка arm64 або aarch64.
5. Виконайте getconf PAGESIZE і зафіксуйте отриману відповідь, перш ніж визначати обсяг пам’яті.
6. Проведіть власне бенчмаркування на ARM-плані та x86-плані, між якими ви обираєте.

Чого цей допис не стверджує

Ми не надаватимемо співвідношення ціни та продуктивності ARM і x86. Ціни за ядро залежать від провайдера та тарифного плану, а показник, отриманий на чужому обладнанні, не прогнозує результати для вашого. Натомість виміряйте їх самостійно. Наш посібник із бенчмаркінгу VPS охоплює sysbench і fio та містить методику, яку можна відтворити. У матеріалі скільки насправді коштує VPS розглянуто цінову сторону порівняння. Сховище — це окреме від архітектури CPU рішення, а в матеріалі як NVMe порівнюється із SATA SSD на VPS розглянуто цю частину. Виконайте однаковий тест на обох тарифних планах, за можливості використовуючи власне робоче навантаження, і керуйтеся отриманими показниками.

FAQ

Чи працюватимуть мої Docker-контейнери на ARM VPS?

Вони працюватимуть, якщо маніфест кожного образу в стеку містить запис 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-бітного набору інструкцій ARM. Ядро повідомляє aarch64 через uname -m, тоді як у пакетах Debian та Ubuntu і в рядках платформ Docker використовується arm64. Аналогічний поділ існує і з іншого боку: uname -m означає x86_64, а в пакетах використовується amd64. Якщо на сторінці завантаження доступні лише файли aarch64, це правильні файли для машини, яку dpkg --print-architecture називає arm64.

Чи є ARM VPS швидшим за x86 VPS?

Загальної відповіді немає. Будь-яке співвідношення, яке ви прочитали, вимірювали на обладнанні, відмінному від вашого. Швидкість залежить від конкретної моделі CPU, кількості виділених вам ядер, способу розподілу ресурсів між клієнтами та того, наскільки добре ваше навантаження використовує векторні інструкції. Порівняйте два плани, між якими ви фактично обираєте, виконавши бенчмарк. Якщо можливо, використайте власне робоче навантаження.

Що потрібно перевірити перед перенесенням production-сервера на arm64?

Виконайте чотири перевірки саме в такому порядку. Переконайтеся, що маніфест кожного образу контейнера містить arm64. Переконайтеся, що кожен сторонній apt-репозиторій публікує binary-arm64. Переконайтеся, що для кожного агента із закритим вихідним кодом доступний пакет для завантаження aarch64. Потім виконайте getconf PAGESIZE на цільовому екземплярі, оскільки ядро зі сторінкою розміром 64 KiB змінює обсяг пам’яті, який використовують процеси з великою кількістю невеликих відображень. Усе, що не проходить одну з цих чотирьох перевірок, є причиною залишити відповідний сервер на x86.