ARM VPS बनाम x86 VPS: क्या अंतर है और क्या चुनें

ARM VPS पर जाने पर क्या बदलता है

एक ARM VPS वही Linux और वही Nginx चलाता है जो एक x86 VPS चलाता है, और यह आमतौर पर प्रति कोर कम खर्चीला होता है। स्विच करने में जोखिम अनुकूलता (compatibility) का है। x86-64 के लिए compile किया गया कोई भी प्रोग्राम arm64 पर बिल्कुल नहीं चल सकता, इसलिए आपके stack के हर software का arm64 build उपलब्ध होना चाहिए या उसे फिर से build करने की क्षमता होनी चाहिए।

अधिकांश आधुनिक stacks बिना किसी अतिरिक्त प्रयास के इस परीक्षण में सफल हो जाते हैं। विफलताएं मुख्य रूप से दो जगहों पर होती हैं: container images जो केवल एक architecture के लिए बनाए गए थे, और closed source software जिसका कोई arm64 download उपलब्ध नहीं है। नीचे दिए गए commands किसी instance के लिए भुगतान करने से पहले आपके अपने stack के लिए इन दोनों सवालों का जवाब देते हैं। यदि आप अभी भी यह तय कर रहे हैं कि आपको किस प्रकार के सर्वर की आवश्यकता है, तो VPS क्या है और यह shared hosting से कैसे अलग है से शुरुआत करें।

arm64, aarch64, amd64: कौन सा नाम क्या दर्शाता है

किसी भी अन्य कार्य से पहले किसी भी instance पर इन्हें चलाएं।

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

uname -m कमांड ARM मशीन पर aarch64 और Intel या AMD मशीन पर x86_64 प्रिंट करता है। dpkg --print-architecture कमांड उन्हीं दो मशीनों के लिए क्रमशः arm64 और amd64 प्रिंट करता है। दोनों उत्तर सही हैं। Linux kernel और Debian पैकेजिंग सिस्टम ने एक ही instruction set के लिए अलग-अलग नाम चुने हैं, इसलिए aarch64 और arm64 का अर्थ एक है, और x86_64 और amd64 का अर्थ दूसरा। Docker, Debian शैली के नामों का उपयोग करता है, यही कारण है कि image platform linux/arm64 दर्शाता है।

arm64 पर /proc/cpuinfo में कोई model name लाइन नहीं होती है। इसके बजाय आपको Features फील्ड मिलता है, और hardware crypto वहां aes pmull sha1 sha2 जैसे flags के रूप में दिखाई देता है। ये ARMv8 Cryptographic Extensions हैं, और ये वही काम करते हैं जो Intel और AMD पार्ट्स पर AES-NI करता है: ये TLS (transport layer security) और disk encryption को hardware स्तर पर तेज बनाते हैं। VPS पर AES hardware acceleration की जांच करना लेख दोनों architectures पर इसके परीक्षण को कवर करता है।

कंटेनर सबसे पहले क्यों टूटते हैं, और त्रुटि कैसी दिखती है

प्रत्येक Docker image manifest उस आर्किटेक्चर को रिकॉर्ड करता है जिसके लिए उसे बनाया गया था। यदि आप केवल amd64 manifest वाली image को arm64 host पर pull करते हैं, तो pull सफल हो जाता है। विफलता तब होती है जब पहली बार process start होती है:

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 उस file को चलाने से मना कर रहा है, क्योंकि उसका ELF (executable and linkable format) header एक ऐसे machine type का नाम बताता है जिसे यह CPU implement नहीं करता है। कोई भी setting इसे ठीक नहीं कर सकती। निर्देश silicon में मौजूद ही नहीं हैं।

deploy करने से पहले manifest की जाँच करें:

docker buildx imagetools inspect nginx:1.27

आउटपुट manifest list में प्रत्येक image के लिए एक Platform: line दिखाता है, जैसे कि linux/amd64 और linux/arm64। यदि linux/arm64 अनुपस्थित है, तो वह tag ARM VPS पर start नहीं होगा। docker manifest inspect --verbose nginx:1.27 भी वही जानकारी दिखाता है, लेकिन Docker docker manifest को एक experimental command के रूप में document करता है जिसका व्यवहार releases के बीच बदल सकता है, इसलिए imagetools को प्राथमिकता दें।

जो images आप स्वयं बनाते हैं, उनके लिए एक ही command में दोनों आर्किटेक्चर के लिए build करें और एक manifest list push करें:

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

एक ही host पर foreign architecture के लिए build करने हेतु QEMU user mode emulation की आवश्यकता होती है, जो kernel के binfmt_misc handler के साथ registered हो:

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

Emulation का उपयोग build करने और test करने के लिए करें। traffic serve करने के लिए इसका उपयोग न करें। Docker के अपने documentation में कहा गया है कि QEMU के साथ emulation "native builds की तुलना में बहुत धीमा हो सकता है, विशेष रूप से compilation और compression या decompression जैसे compute-heavy कार्यों के लिए", इसलिए ARM instance पर emulated x86 service चलाने से वह बचत खत्म हो जाती है जिसके कारण आपने migration किया था। Native case के लिए host setup दोनों आर्किटेक्चर पर समान है: VPS पर Docker चलाना इसे कवर करता है, और एक मौजूदा Compose file बिना किसी बदलाव के काम करती है, बशर्ते उसमें मौजूद प्रत्येक image का arm64 manifest उपलब्ध हो।

Will the packages I need exist on arm64?

Ubuntu and Debian build nearly the whole archive for arm64, so apt install nginx postgresql redis-server behaves the same on both architectures. Third party repositories are where the gaps are.

Ask apt directly, on the ARM instance:

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

apt-cache policy reporting Candidate: (none) means no enabled repository publishes a build of that package for this architecture. apt-get install -s simulates the install and writes nothing, and in the same case it ends with E: Unable to locate package.

Then read the output of apt update instead of scrolling past it. A vendor repository that is amd64 only says so:

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

The repository is configured and reachable, and it holds nothing this machine can install. Check the source entry itself too. A line pinned with [arch=amd64] is skipped on an arm64 host, so the package looks missing when the real cause is the pin.

कौन से वर्कलोड सुरक्षित हैं और किनकी पहले जाँच करनी चाहिए

Interpreted और bytecode runtimes को डिज़ाइन के अनुसार ही पोर्टेबल बनाया गया है। PHP, Python, Ruby और Node.js, सभी के मुख्य distributions में arm64 packages उपलब्ध हैं। Go और Rust को केवल एक target सेट करके arm64 के लिए cross-compile किया जा सकता है। LEMP stack, Node API, Nginx के पीछे चलने वाली Go binary या Postgres database, ये सभी arm64 पर सामान्य काम हैं।

Just-in-time (JIT) compiler प्रोग्राम चलते समय machine code तैयार करता है, इसलिए इसे target architecture के लिए एक code generator की आवश्यकता होती है। वर्तमान versions में यह सुविधा है: OpenJDK, .NET, Node.js के अंदर मौजूद V8 engine और PyPy, ये सभी Linux पर arm64 को सपोर्ट करते हैं। पुराने versions को पिन करके रखना ही असली खतरा है। यदि कोई deploy script कई साल पुराना runtime release install करती है, तो यह मान लेने के बजाय कि वह काम करेगा, आपको उस release के notes में aarch64 support की जाँच करनी चाहिए।

हाथ से लिखी गई x86 assembly, या SSE और AVX intrinsics वाली libraries एक शांत समस्या हैं। अधिकांश में NEON path (NEON, ARM का vector instruction set है) या एक साधारण C fallback होता है, इसलिए वे compile और run हो जाती हैं। performance x86 build से कम या ज्यादा हो सकती है। किसी लेख से अनुमान लगाने के बजाय अपने instance पर इसे मापें।

Closed source software ही असली बाधा है। कोई vendor monitoring agent, licensed database driver, commercial control panel या anti-virus daemon एक compiled binary के रूप में आते हैं, और यदि vendor ने arm64 build जारी नहीं किया है, तो आप इसके बारे में कुछ नहीं कर सकते। cPanel और WHM होस्टिंग में इसका सबसे स्पष्ट उदाहरण है: इसकी system requirements में x86_64 का उल्लेख है और ARM सूचीबद्ध नहीं है, इसलिए control panel सर्वर x86 पर ही रहता है (अगस्त 2026 में जाँचा गया, और vendor के अपने requirements page पर इसे फिर से पढ़ना उचित है)। यदि केवल यही एक चीज आपको रोक रही है, तो VPS पर चलाने योग्य cPanel के विकल्प से शुरुआत करें, और प्रत्येक के architecture support की उसी तरह जाँच करें।

Kernels और page size: जहाँ ARM instances अभी भी अलग हैं

x86-64 सर्वर लगभग एक जैसे होते हैं। ARM सर्वर उतने एकसमान नहीं हैं, और इनके अंतर आपके application के स्तर से नीचे मौजूद होते हैं।

Page size वह कारक है जो production को प्रभावित करता है। अधिकांश arm64 kernels 4 KiB pages का उपयोग करते हैं, जो x86-64 के समान है। कुछ 64 KiB का उपयोग करते हैं। Red Hat Enterprise Linux 8 for aarch64 में डिफ़ॉल्ट रूप से 64 KiB page kernel आता था, और RHEL 9 ने डिफ़ॉल्ट को वापस 4 KiB कर दिया है, जबकि बड़े size की आवश्यकता वाले workloads के लिए एक अलग kernel-64k package उपलब्ध रखा है। 64 KiB page size कई छोटे mappings वाले process के लिए memory की न्यूनतम आवश्यकता को बढ़ा देता है, क्योंकि kernel द्वारा आवंटित किया जा सकने वाला सबसे छोटा हिस्सा सोलह गुना बड़ा होता है। instance पर getconf PAGESIZE चलाएं और अनुमान लगाने के बजाय संख्या को पढ़ें।

कुछ छोटे अंतरों को जानना उपयोगी है। arm64 पर कोई operating system CPU microcode package नहीं होता है, इसलिए firmware updates आपके provider से आते हैं, न कि apt से। ARM सर्वर UEFI (unified extensible firmware interface) के माध्यम से बूट होते हैं और ACPI (advanced configuration and power interface) के माध्यम से अपने hardware का विवरण देते हैं। कुछ x86 features का ARM में कोई समकक्ष नहीं है, जिसमें AMD SEV memory encryption और Intel GVT-g mediated GPUs शामिल हैं।

क्या ARM सर्वर प्लेटफॉर्म परिपक्व हो गया है?

सॉफ्टवेयर के पक्ष से, हाँ। Debian, Ubuntu, Fedora और RHEL सभी प्रथम श्रेणी के arm64 बिल्ड प्रदान करते हैं, और Docker Hub पर आधिकारिक इमेजेस स्वाभाविक रूप से multi-arch होती हैं।

हालिया सबसे स्पष्ट प्रमाण Proxmox है। 5 August 2026 को Proxmox ने Proxmox Virtual Environment के पहले आधिकारिक तौर पर समर्थित arm64 संस्करण, version 9.2 की घोषणा की, जो x86-64 संस्करण के साथ पैकेज रिपॉजिटरी और release lifecycle साझा करता है। यह Debian 13.5 पर Linux 7.0, QEMU 11.0, LXC 7.0 और ZFS 2.4 के साथ बनाया गया है, और आर्किटेक्चर-विशिष्ट वस्तुओं के एक छोटे सेट को छोड़कर कॉन्फ़िगरेशन और टूलिंग x86-64 से मेल खाते हैं।

उसी घोषणा में दी गई चेतावनियों को पढ़ें, क्योंकि वे दिखाती हैं कि आधिकारिक तौर पर समर्थित ARM सर्वर हार्डवेयर अभी भी कितना सीमित है। Proxmox ने Grace Hopper हार्डवेयर पर NVIDIA और Supermicro के साथ संयुक्त परीक्षण के बाद, पहले दिन ही NVIDIA Grace और NVIDIA Vera सिस्टम को मान्य किया। अन्य UEFI आधारित ARMv8-A और ARMv9-A हार्डवेयर को best effort support मिलता है। केवल device tree वाले सिंगल बोर्ड कंप्यूटर जैसे Raspberry Pi समर्थित नहीं हैं। एक guest केवल अपने स्वयं के आर्किटेक्चर के नोड पर चलता है, live migration केवल समान आर्किटेक्चर के नोड्स के बीच काम करता है, और मिश्रित आर्किटेक्चर वाले क्लस्टर आधिकारिक तौर पर समर्थित नहीं हैं।

August 2026 तक यही वास्तविक स्थिति है। एक हाइपरवाइजर वेंडर का x86-64 के समान lifecycle पर arm64 प्रदान करना प्लेटफॉर्म के लिए वास्तविक प्रगति है। पहले दिन समर्थित हार्डवेयर सूची में दो CPU परिवार शामिल हैं।

Commit करने से पहले पूरी की जाने वाली चेकलिस्ट

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 के बीच मूल्य-से-प्रदर्शन (price to performance) अनुपात नहीं देने जा रहे हैं। प्रति कोर कीमतें प्रदाता और प्लान के अनुसार बदलती रहती हैं, और किसी अन्य के हार्डवेयर पर मापा गया आंकड़ा आपके हार्डवेयर के लिए सटीक नहीं हो सकता। इसके बजाय, स्वयं मापें। VPS की बेंचमार्किंग के लिए हमारी गाइड में sysbench और fio को एक ऐसी विधि के साथ समझाया गया है जिसे आप दोहरा सकते हैं, और VPS की वास्तविक लागत क्या है तुलना के मूल्य पक्ष को कवर करती है। स्टोरेज, CPU आर्किटेक्चर से एक अलग निर्णय है, और VPS पर NVMe की SATA SSD से तुलना उस पहलू को देखती है। जहाँ संभव हो, अपने स्वयं के वर्कलोड के साथ दोनों प्लान पर समान परीक्षण चलाएं, और अपने आंकड़ों को निर्णय लेने दें।

FAQ

क्या मेरे Docker containers ARM VPS पर चलेंगे?

वे तब चलेंगे यदि stack में मौजूद हर image के manifest में linux/arm64 entry हो। प्रत्येक image को docker buildx imagetools inspect <image> के साथ जाँचें और Platform: linux/arm64 लाइन ढूँढें। Docker Hub पर मौजूद आधिकारिक images आमतौर पर multi-arch होती हैं। छोटे vendors की images, और x86 मशीन पर आपके द्वारा बनाई गई images, अक्सर ऐसी नहीं होतीं। अपनी खुद की images के लिए, उन्हें docker buildx build --platform linux/amd64,linux/arm64 ... --push के साथ rebuild करें ताकि एक ही tag दोनों architectures के लिए काम करे।

ARM सर्वर पर exec format error का क्या अर्थ है?

kernel ने एक ऐसी binary को execute करने का प्रयास किया जिसके ELF header में एक अलग machine type का नाम है, और उसने इसे अस्वीकार कर दिया। arm64 host पर इसका लगभग हमेशा मतलब x86-64 binary या container image होता है। Docker पहले एक चेतावनी देता है, जिसमें कहा जाता है कि अनुरोधित image platform linux/amd64, detected host platform linux/arm64/v8 से मेल नहीं खाता है। इसका समाधान सही architecture के लिए build करना है। कोई भी configuration परिवर्तन x86-64 binary को ARM पर natively नहीं चला सकता।

क्या arm64 और aarch64 एक ही हैं?

हाँ। ये 64-bit ARM instruction set के दो नाम हैं। kernel aarch64 के माध्यम से uname -m रिपोर्ट करता है, जबकि Debian और Ubuntu packaging, और Docker platform strings, arm64 का उपयोग करते हैं। यही विभाजन दूसरी तरफ भी मौजूद है, जहाँ uname -m कहता है x86_64 और packaging कहती है amd64। यदि कोई download page केवल aarch64 files प्रदान करता है, तो वे उस मशीन के लिए सही files हैं जिसे dpkg --print-architecture, arm64 कहता है।

क्या ARM VPS, x86 VPS से तेज़ है?

इस प्रश्न का कोई सामान्य उत्तर नहीं है, और आपने जो भी अनुपात पढ़ा है, उसे उस hardware पर मापा गया था जो आपका नहीं है। गति विशिष्ट CPU model, आपको दिए गए cores की संख्या, provider द्वारा tenants के बीच contention को संभालने के तरीके, और आपका workload vector instructions का उपयोग कितनी अच्छी तरह करता है, पर निर्भर करती है। उन दो plans का benchmark करें जिन्हें आप वास्तव में चुन रहे हैं, यदि संभव हो तो अपने स्वयं के workload के साथ, और उन numbers की तुलना करें।

production सर्वर को arm64 पर ले जाने से पहले मुझे क्या जाँच लेना चाहिए?

इस क्रम में चार जाँचें करें। पुष्टि करें कि प्रत्येक container image में arm64 manifest है। पुष्टि करें कि प्रत्येक third party apt repository binary-arm64 प्रकाशित करती है। पुष्टि करें कि प्रत्येक closed source agent का aarch64 download उपलब्ध है। फिर target instance पर getconf PAGESIZE चलाएँ, क्योंकि 64 KiB page kernel कई छोटे mappings वाली processes के memory footprint को बदल देता है। जो भी इन चार जाँचों में से एक में विफल रहता है, वह उस विशिष्ट सर्वर को x86 पर रखने का एक कारण है।