ARM VPS बनाम x86 VPS: क्या अंतर है और क्या बदलता है

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

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

अधिकांश आधुनिक stacks बिना किसी अतिरिक्त कार्य के इस परीक्षण में सफल हो जाते हैं। विफलताएं दो जगहों पर केंद्रित होती हैं: container images जिन्हें केवल एक architecture के लिए बनाया गया था, और closed source सॉफ्टवेयर जिसका कोई 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 field मिलता है, और 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 सपोर्ट नहीं करता है। इसे कोई भी setting ठीक नहीं कर सकती। ये निर्देश silicon में मौजूद ही नहीं हैं।

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

docker buildx imagetools inspect nginx:1.27

आउटपुट manifest list में प्रत्येक image के लिए एक Platform: लाइन दिखाता है, जैसे कि 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 पर किसी अन्य आर्किटेक्चर के लिए build करने हेतु kernel के binfmt_misc handler के साथ पंजीकृत QEMU user mode emulation की आवश्यकता होती है:

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 उपलब्ध हो।

क्या मुझे जिन packages की आवश्यकता है, वे arm64 पर उपलब्ध होंगे?

Ubuntu और Debian अपने लगभग पूरे archive को arm64 के लिए build करते हैं, इसलिए apt install nginx postgresql redis-server दोनों architectures पर एक समान व्यवहार करता है। कमियां अक्सर third-party repositories में होती हैं।

ARM instance पर सीधे apt से पूछें:

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

apt-cache policy द्वारा Candidate: (none) रिपोर्ट करने का अर्थ है कि कोई भी enabled repository इस architecture के लिए उस package का build प्रकाशित नहीं करती है। apt-get install -s install की प्रक्रिया को simulate करता है और कुछ भी write नहीं करता है, और ऐसी स्थिति में यह E: Unable to locate package के साथ समाप्त होता है।

इसके बाद, output को scroll करने के बजाय apt update के output को ध्यान से पढ़ें। यदि कोई vendor repository केवल 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'

Repository configured और reachable है, लेकिन इसमें ऐसा कुछ नहीं है जिसे यह machine install कर सके। source entry की भी जांच करें। [arch=amd64] के साथ pin की गई line को arm64 host पर छोड़ दिया जाता है, इसलिए package अनुपलब्ध दिखाई देता है जबकि वास्तविक कारण वह pin होता है।

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

Interpreted और bytecode runtimes डिज़ाइन के अनुसार पोर्टेबल होते हैं। PHP, Python, Ruby और Node.js सभी के मुख्य distributions में arm64 पैकेज उपलब्ध हैं। 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 को सपोर्ट करते हैं। पुराने pinned versions वास्तविक खतरा हैं। यदि कोई deploy script कई साल पुराना runtime release install करती है, तो यह मानने के बजाय कि वह काम करेगा, उस release के notes में aarch64 सपोर्ट की जाँच कर लेनी चाहिए।

हाथ से लिखी गई x86 assembly, या SSE और AVX intrinsics वाली libraries शांत समस्याएँ हैं। अधिकांश में NEON path (NEON, ARM का vector instruction set है) या plain 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 प्रकाशित नहीं करता है, तो आप इसके बारे में कुछ नहीं कर सकते। Hosting में cPanel और WHM सबसे स्पष्ट उदाहरण है: इसकी system requirements में x86_64 का उल्लेख है और ARM सूचीबद्ध नहीं है, इसलिए control panel सर्वर x86 पर ही रहता है (अगस्त 2026 में जाँच की गई, और vendor के स्वयं के requirements page पर इसे फिर से पढ़ना उचित है)। यदि केवल यही एक चीज़ आपको रोक रही है, तो VPS पर चलाने योग्य cPanel के विकल्प से शुरुआत करें, और प्रत्येक के architecture सपोर्ट की उसी तरह जाँच करें।

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 ने aarch64 के लिए डिफ़ॉल्ट रूप से 64 KiB page kernel प्रदान किया था, जबकि RHEL 9 ने डिफ़ॉल्ट को वापस 4 KiB पर कर दिया, साथ ही उन workloads के लिए एक अलग kernel-64k package भी रखा जिन्हें बड़े size की आवश्यकता होती है। 64 KiB page size कई छोटे mappings वाले process के लिए memory की न्यूनतम आवश्यकता को बढ़ा देता है, क्योंकि kernel द्वारा आवंटित किया जा सकने वाला सबसे छोटा हिस्सा सोलह गुना बड़ा होता है। instance पर getconf PAGESIZE चलाएं और अनुमान लगाने के बजाय संख्या को पढ़ें। Page size एकमात्र kernel निर्णय नहीं है जो आप तक पहुँचता है, क्योंकि आपका provider जो version प्रदान करता है, वह यह भी नियंत्रित करता है कि cores पर काम को कैसे schedule किया जाता है, और Linux 7.2 में जोड़ा गया cache aware scheduling arm64 और x86-64 दोनों पर समान रूप से लागू होता है।

कुछ छोटे अंतरों के बारे में जानना उपयोगी है। arm64 पर कोई operating system CPU microcode package नहीं होता है, इसलिए firmware updates आपके provider से आते हैं, न कि apt से। ARM सर्वर्स UEFI (unified extensible firmware interface) के माध्यम से boot होते हैं और अपने hardware का विवरण ACPI (advanced configuration and power interface) के माध्यम से देते हैं। कुछ 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 वाले केवल single board computers जैसे कि Raspberry Pi समर्थित नहीं हैं। एक guest केवल अपने ही आर्किटेक्चर के नोड पर चलता है, live migration केवल समान आर्किटेक्चर के नोड्स के बीच काम करता है, और मिश्रित आर्किटेक्चर वाले क्लस्टर आधिकारिक तौर पर समर्थित नहीं हैं।

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

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

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 ratio) का कोई निश्चित आंकड़ा नहीं देने जा रहे हैं। प्रति कोर कीमत प्रदाता और प्लान के अनुसार बदलती रहती है, और किसी अन्य के हार्डवेयर पर मापा गया परिणाम आपके हार्डवेयर के लिए सटीक नहीं हो सकता। इसके बजाय, स्वयं मापें। 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 line ढूँढें। Docker Hub पर मौजूद official images आमतौर पर multi-arch होती हैं। छोटे vendors की images, और वे images जिन्हें आपने खुद x86 machine पर build किया है, अक्सर ऐसी नहीं होतीं। अपनी खुद की images के लिए, उन्हें docker buildx build --platform linux/amd64,linux/arm64 ... --push के साथ rebuild करें ताकि एक ही tag दोनों architectures के लिए काम करे।

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

Kernel ने एक ऐसी binary को execute करने का प्रयास किया जिसके ELF header में एक अलग machine type का नाम है, और उसने ऐसा करने से मना कर दिया। arm64 host पर इसका अर्थ लगभग हमेशा एक x86-64 binary या container image होता है। Docker पहले एक चेतावनी देता है, जिसमें कहा जाता है कि अनुरोधित image platform linux/amd64, पहचाने गए 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 प्रदान करता है, तो वे उस machine के लिए सही files हैं जिसे dpkg --print-architecture, arm64 कहता है।

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

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

production server को 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 को बदल देता है। जो भी इन चार जाँचों में से एक में भी विफल हो जाए, वह उस विशिष्ट server को x86 पर ही रखने का एक कारण है।