ARM حالا نیمی از Cloud را اداره می‌کند: Graviton 4، Ampere Altra Max، و اعداد پشت عقب‌نشینی x86

اشتراک‌گذاری:
ARM حالا نیمی از Cloud را اداره می‌کند: Graviton 4، Ampere Altra Max، و اعداد پشت عقب‌نشینی x86

این تغییر دیگر نظری نیست

در بیشتر دهه گذشته، ARM در server room یک وعده بود — همیشه دو سال با production-ready شدن فاصله داشت. آن زمان گذشته است. AWS اعلام می‌کند که instance‌های مبتنی بر Graviton حالا سهم قابل‌توجه و رو به رشدی از fleet محاسباتی‌اش را تامین می‌کنند. چیپ‌های Altra Max شرکت Ampere روی Oracle Cloud، Microsoft Azure، و Google Cloud workload‌های production را اجرا می‌کنند. Grace CPU شرکت NVIDIA در قالب Grace Hopper Superchip در AI cluster‌های سراسر جهان مستقر شده است. دیگر سوال این نیست که آیا ARM می‌تواند workload‌های server را مدیریت کند. سوال این است که کدام workload‌ها هنوز توجیه دارند که هزینه اضافی x86 را بپردازند.

تز اصلی ساده است و با اعداد پشتیبانی می‌شود: چیپ‌های server ARM در workloadهایی که بیشترین هزینه cloud مدرن را تشکیل می‌دهند — web serving، containerized microservices، in-memory caching، و Machine Learning inference — throughput بیشتری به ازای هر watt و هر دلار نسبت به معادل‌های x86 ارائه می‌دهند. x86 در نرم‌افزارهای legacy تک‌رشته‌ای، workload‌های Windows Server، و اپلیکیشن‌هایی با وابستگی سخت به x86 ISA extension واقعاً برتری دارد. بقیه موارد یک مکالمه مهاجرت هستند.

AWS Graviton 4: Benchmarkی که مکالمه را تغییر داد

AWS Graviton 4 که اواخر ۲۰۲۳ عرضه شد و خانواده‌های instance R8g، C8g، و M8g را تامین می‌کند، بر پایه هسته سفارشی ARM Neoverse V2 با فرآیند ۳ نانومتری TSMC ساخته شده است. این چیپ با ۹۶ core، پشتیبانی از حافظه DDR5-5600، و یک system-level cache 75 مگابایتی عرضه می‌شود. AWS اعلام می‌کند Graviton 4 تا ۳۰ درصد performance محاسباتی بهتر نسبت به Graviton 3 و تا ۴۰ درصد performance per watt بهتر نسبت به instance‌های x86 مشابه در fleet خودش ارائه می‌دهد.

در SPECrate2017_int_base، تست‌های third-party روی instance‌های Graviton 4 در محدوده ۶۵۰ تا ۷۰۰ aggregate در تمام core‌ها امتیاز می‌گیرند — رقابتی با Intel Xeon Sapphire Rapids در قیمت‌های مشابه، در حالی که مصرف برق کمتری در مرز instance دارد. برای workload‌های مبتنی بر Java — بخش عمده‌ای از هزینه cloud سازمانی — Graviton 4 در SPECjbb2015 تقریباً ۲۰ تا ۲۵ درصد throughput بالاتری نسبت به Graviton 3 کسب می‌کند، که خود Graviton 3 هم از نظر benchmark روی instance‌های Intel مشابه پیشی گرفته بود.

استدلال قیمتی مستقیم است. یک AWS m8g.4xlarge با ۱۶ vCPU و Graviton 4 تقریباً ۰.۶۱۶ دلار در ساعت on-demand در us-east-1 هزینه دارد. یک m7i.4xlarge مشابه با ۱۶ vCPU و Intel Sapphire Rapids تقریباً ۰.۸۰۶ دلار در ساعت است. این ۲۴ درصد کاهش هزینه است، پیش از اینکه حساب کنید instance ARM اغلب throughput بالاتری به ازای هر vCPU روی workload‌های stateless مدیریت می‌کند.

Ampere Altra Max: 128 Core، قابلیت پیش‌بینی تک‌رشته‌ای

Altra Max شرکت Ampere Computing از نظر معماری به شکل عمدی با Graviton 4 متفاوت است. جایی که AWS از یک طراحی core با کارایی بالا مشتق‌شده از Neoverse V2 استفاده می‌کند، Ampere از core‌های تک‌رشته‌ای اختصاصی خود استفاده می‌کند — بدون simultaneous multithreading یا SMT. Altra Max با تا ۱۲۸ core عرضه می‌شود که هر کدام تا ۳.۰ گیگاهرتز اجرا می‌شوند، با L3 cache 128 مگابایتی و حافظه ۸ کاناله DDR4-3200. TDP نسخه ۱۲۸-core روی ۲۵۰ تا ۲۷۰ وات قرار دارد.

نبود SMT یک انتخاب طراحی با پیامدهای واقعی است. Cloud providerهایی که از Altra Max استفاده می‌کنند می‌توانند vCPUهایی تبلیغ کنند که ۱ به ۱ به core‌های فیزیکی نگاشت می‌شوند، و واریانس noisy-neighbor که SMT-enabled x86 instance‌ها را زیر بار مختلط آزار می‌دهد را از بین می‌برند. Oracle Cloud Infrastructure از instance‌های Ampere A1 (نسل قبلی Altra) با قیمت ۰.۰۱ دلار در ساعت به ازای هر OCPU استفاده می‌کند و این ارزان‌ترین گزینه compute از هر cloud provider بزرگی است. نتایج benchmark از Phoronix روی node‌های Altra Max نشان‌دهنده مقیاس‌پذیری خطی تا ۱۲۸ thread روی workload‌های embarrassingly parallel است — چیزی که چیپ‌های x86 با SMT از تعداد core فیزیکی به بعد به خوبی ارائه نمی‌دهند.

فهرست workload هدف Ampere مثل کاتالوگ زیرساخت مدرن است: NGINX، HAProxy، Redis، Memcached، PostgreSQL با workload‌های read-heavy، و containerized microservices روی Kubernetes. برای تیم‌هایی که این stack‌ها را اجرا می‌کنند، instance‌های Altra Max هزینه per-request را به طور قابل اندازه‌گیری کاهش می‌دهند.

NVIDIA Grace: ARM با HBM3 برای AI Workloadها

Grace CPU شرکت NVIDIA که در پیکربندی‌های Grace Hopper و Grace Blackwell Superchip استفاده می‌شود، یک طراحی ۷۲-core ARM Neoverse V2 است که از طریق NVLink-C2C به GPU dieهای NVIDIA متصل شده است. خود Grace CPU دارای bandwidth حافظه ۵۰۰ گیگابایت بر ثانیه با استفاده از LPDDR5X است که چیزی که کانال‌های DDR5 متعارف روی پلتفرم‌های server x86 ارائه می‌دهند را به شدت پشت سر می‌گذارد.

در Grace Hopper Superchip مدل GH200، CPU و H100 GPU یک unified memory fabric با ۹۰۰ گیگابایت بر ثانیه بین خود به اشتراک می‌گذارند. این یک ادعای بازاریابی نیست — این گلوگاه PCIe که استفاده از GPU را در workload‌های LLM inference محدود می‌کند — جایی که مدل باید مکرراً داده را بین حافظه CPU و GPU جابجا کند — را از بین می‌برد. برای inference مدل‌های زبانی بزرگ و مدل‌های multimodal، GH200 tokens-per-second بالاتری به ازای هر دلار نسبت به پیکربندی‌های معادل H100 SXM5 با host CPU‌های x86 ارائه می‌دهد، عمدتاً با کاهش تاخیر انتقال داده.

Apple M4 Ultra در Mac Pro: ARM در سطح Professional Workstation

Apple M4 Ultra که برای Mac Pro 2025 اعلام شده، دو die M4 Max را از طریق interconnect UltraFusion ترکیب می‌کند و چیپی با تا ۸۰ CPU core (۶۰ performance، ۲۰ efficiency)، تا ۸۰ GPU core، و یک معماری unified memory با پشتیبانی از تا ۱۹۲ گیگابایت با bandwidth aggregate بیش از ۸۰۰ گیگابایت بر ثانیه تولید می‌کند. TDP سیستم M4 Ultra حدود ۳۰۰ وات کل مصرف سیستم است که با یک die Intel Xeon W high-end به تنهایی قابل مقایسه است.

Mac Pro یک server cloud نیست، اما benchmark‌هایش مستقیماً بحث server را مطلع می‌سازند. در Cinebench R24 nT، M4 Ultra تقریباً ۹۰۰۰ تا ۹۵۰۰ امتیاز multi-core کسب می‌کند — قابل مقایسه با Threadripper 7970X در حدود دو برابر مصرف برق. توسعه‌دهندگانی که اپلیکیشن‌های containerized ARM-native را روی M4 Ultra Mac Pro می‌سازند و تست می‌کنند، قبل از استقرار روی Graviton 4 یا Altra Max در production، workload‌های معادل production را به صورت local اجرا می‌کنند. همسویی اکوسیستم نرم‌افزاری به سرعت در حال بسته شدن است.

مزایای معماری ARM برای کارهای Server

دلایل پیروزی ARM در بحث efficiency ساختاری است، نه موقتی. ARM ISA footprint دستوری کوچک‌تری نسبت به x86 تولید می‌کند که فشار روی instruction cache را کاهش می‌دهد. نبود منطق x87 legacy و decode با طول متغیر پیچیده به این معناست که سطح بیشتری از هر die به execution unit و cache اختصاص می‌یابد. core‌های مدرن server ARM مانند Neoverse V2 و Neoverse N2 اجرای out-of-order با pipeline‌های wide پیاده‌سازی می‌کنند که در throughput per-clock برای workload‌های integer و memory-intensive با Intel Golden Cove و AMD Zen 4 برابری یا از آن‌ها پیشی می‌گیرند.

اعداد power efficiency در تست‌های مستقل ثابت هستند. نتایج SPECpower_ssj2008 — که performance-per-watt را در سطوح مختلف بار اندازه می‌گیرد — نشان می‌دهد پلتفرم‌های server ARM از AWS، Ampere، و NVIDIA ۱۵ تا ۴۰ درصد کارآمدتر از معادل‌های x86 بسته به workload و سطح بار کار می‌کنند. در مقیاس data center، این تفاوت به megawatt و میلیون‌ها دلار در سال اندازه‌گیری می‌شود.

جایی که x86 هنوز پیروز می‌شود

صداقت ایجاب می‌کند که بپذیریم x86 کجا برتری خود را حفظ کرده است:

  • Windows Server workloadها — AWS Graviton Windows instance ارائه نمی‌دهد؛ Azure Cobalt 100 ARM instance‌ها تا ۲۰۲۴ فقط Linux اجرا می‌کنند. SQL Server و .NET Framework (نه .NET Core) در عمل به x86 وابسته باقی می‌مانند.
  • اپلیکیشن‌های legacy تک‌رشته‌ای — AMD EPYC Genoa و Intel Sapphire Rapids هر دو به boost clock‌های single-core بالاتری (تا ۴.۵ گیگاهرتز) نسبت به چیپ‌های فعلی server ARM می‌رسند، که برای workload‌های serialize‌شده اهمیت دارد.
  • Workloadهای وابسته به AVX-512 — کدهای HPC و برخی Pipeline‌های video transcoding به صورت دستی برای Intel AVX-512 SIMD extension بهینه‌سازی شده‌اند. SVE2 شرکت ARM رقابتی است اما نیاز به recompile و re-tuning دارد.
  • نرم‌افزار ISV با license اختصاصی x86 — Oracle Database، SAP HANA، و چندین ابزار تجاری EDA یا از ARM پشتیبانی نمی‌کنند یا شرایط license جداگانه‌ای دارند که مزیت هزینه را از بین می‌برد.

نتیجه‌گیری عملی برای مهندسان در انتخاب Cloud Instance

  • مهاجرت ARM خود را با workload‌های stateless HTTP شروع کنید. NGINX، Node.js، Go، و containerized Python API به صورت تمیز به ARM64 کامپایل می‌شوند و سریع‌ترین بازگشت سرمایه را نشان می‌دهند. از instance‌های AWS C8g یا OCI Ampere A1 استفاده کنید و یک A/B load test در مقابل baseline x86 فعلی‌تان قبل از تعهد اجرا کنید.
  • برای سرویس‌های Java، به طور جدی Graviton 4 را فعال کنید. JVM سال‌هاست ARM64 را پشتیبانی می‌کند. benchmark‌های خود AWS نشان می‌دهند ۲۰ تا ۳۰ درصد افزایش throughput روی workload‌های Spring Boot و Quarkus روی Graviton 4 در مقابل instance‌های Intel مشابه با هزینه کمتر وجود دارد.
  • برای AI inference در مقیاس، قبل از اینکه به H100 + x86 پیش‌فرض بروید، GH200 را ارزیابی کنید. معماری unified memory یک گلوگاه واقعی را برای مدل‌های بالای ۷۰ میلیارد پارامتر از بین می‌برد. از طریق AWS، CoreWeave، یا NVIDIA DGX Cloud درخواست دسترسی بدهید تا مدل خاص خود را benchmark کنید.
  • Windows Server یا AVX-512 HPC workloadها را هنوز مهاجرت ندهید مگر اینکه build‌های ARM-native را تأیید کرده و آزمایش کرده باشید. اگر workload عملکرد پایین‌تری داشته باشد یا به library‌های ISA-specific نیاز داشته باشد که port نشده‌اند، صرفه‌جویی هزینه محقق نمی‌شود.
  • برای Redis، Memcached، و NGINX از Ampere Altra Max instance استفاده کنید. نگاشت ۱ به ۱ vCPU به core و مقیاس‌پذیری خطی thread باعث می‌شوند قابلیت پیش‌بینی تاخیر زیر بار متغیر به طور قابل اندازه‌گیری بهتر از x86 instance‌های SMT-enabled باشد.

لحظه server ARM در راه نیست — رسیده است. کار باقیمانده مهاجرت سیستماتیک workload‌هایی است که هنوز از روی اینرسی نه ضرورت روی x86 اجرا می‌شوند.

اشتراک‌گذاری:
ARM Server در مقابل x86: Benchmark‌های Graviton 4 و Ampere Altra Max | AIO APEX