تراشه‌های سفارشی سرور ARM در حال تصاحب سهم x86 از بازار دیتاسنترهای ابری هستند

برای دو دهه، واژه «سرور» مترادف با x86 بود — یک پردازنده Intel یا AMD که همان مجموعه دستورالعمل‌ها را اجرا می‌کرد، چه در مرکز داده یک بانک باشد چه در رک یک استارتاپ در یک colocation facility. این فرض پیش‌پاافتاده حالا دارد در دل سه غول بزرگ ابر فرو می‌ریزد. AWS، Google Cloud و Microsoft Azure هر کدام طی چند سال گذشته مشغول طراحی server CPU های مبتنی بر Arm بوده‌اند، و تا اواسط سال ۲۰۲۶ این تراشه‌ها سهم قابل توجهی از ظرفیت محاسباتی جدید hyperscaler ها را به خود اختصاص داده‌اند؛ به‌طوری که x86 دیگر آن انتخاب خودکار و بلامنازع سابق نیست.

اعداد پشت این تحول

نفوذ Arm در محموله‌های server CPU از حدود ۵٪ در سال ۲۰۲۰ به محدوده ۱۵ تا ۲۳٪ در سال ۲۰۲۵ رسیده است؛ این را تحلیلگران نیمه‌هادی که این بازار را رصد می‌کنند تأیید می‌کنند. رقم شگفت‌انگیزتر اما در جلسات Computex 2026 رونمایی شد: تحقیقات ارائه‌شده در آن رویداد نشان داد که تراشه‌های مبتنی بر Arm به نزدیک نیمی از ظرفیت محاسباتی hyperscaler ها رسیده‌اند — نه تعداد محموله، بلکه ظرفیت واقعاً مستقرشده در AWS، Google و Microsoft به‌صورت ترکیبی. بازار server های مبتنی بر Arm نیز از حدود ۵.۸ میلیارد دلار در سال ۲۰۲۳ به تخمین ۸.۲ میلیارد دلار در سال ۲۰۲۶ رشد کرده است.

جالب اینجاست که این رشد به قیمت عقب‌نشینی AMD نبوده است. پیش‌بینی رشد محموله server CPU برای AMD از ۱۴٪ به ۲۳٪ برای سال ۲۰۲۶ تجدیدنظر شد، و پیش‌بینی اولیه Intel نیز از کاهش ۳٪ به رشد ۳٪ تغییر یافت. بازار آنقدر سریع بزرگ می‌شود که دستاوردهای Arm و AMD همزمان محقق می‌شوند — آنچه بیشترین سهم را از دست می‌دهد، سهم قدیمی Intel x86 است، نه معماری x86 به‌طور کلی.

سه تراشه، سه شرط‌بندی متفاوت

AWS زودتر از همه و با فاصله بیشتری پیش رفت. Graviton5 که از ۱۰ ژوئن ۲۰۲۶ به‌صورت عمومی در دسترس است، ۱۹۲ هسته Arm Neoverse V3 را در چهار chiplet ساخته‌شده با فرآیند ۳ نانومتری TSMC جای داده، با ۱۹۲ مگابایت حافظه L3 cache، حافظه DDR5 و PCIe Gen 6 — افزایش پنج‌برابری cache نسبت به Graviton4 و بهبود عملکرد ۲۵٪ که خود AWS ادعا می‌کند. AWS این تراشه را صریحاً برای بارهای کاری «عصر AI عاملی» طراحی کرده است: inference serving، پایپ‌لاین‌های بازیابی اطلاعات، و الگوهای درخواست ناپیوسته و حافظه‌بر که AI agent ها تولید می‌کنند، نه محاسبات batch کلاسیک.

Google Axion رویکرد متفاوتی دارد و به‌عنوان نیمه CPU یک جفت هماهنگ در کنار رک‌های TPU v8 گوگل معرفی شده است. گوگل مدعی است Axion عملکردی ۳۰٪ بهتر از نمونه‌های Arm رقیب در ابر و بازده انرژی ۶۰٪ بهتر از نمونه‌های x86 مشابه ارائه می‌دهد — و «بازده» کلیدواژه اصلی است، چون وظیفه اصلی Axion تغذیه داده به TPU ها و دریافت آن از آن‌هاست، بدون اینکه به گلوگاه مصرف برق یا دمایی در این پایپ‌لاین تبدیل شود.

Cobalt مایکروسافت از این سه آرام‌ترین است، اما احتمالاً در این مقطع بیش از بقیه در محیط تولید آزموده شده: امروز بارهای کاری واقعی را در سراسر Azure region ها اجرا می‌کند و مشتریانی مثل Databricks پلتفرم‌های داده تولیدی خود را روی آن می‌چرخانند، نه صرفاً استقرارهای آزمایشی. بر خلاف Graviton و Axion که چارچوب‌بندی AI-محور دارند، مایکروسافت Cobalt را صادقانه‌تر به‌عنوان یک گزینه کاهش هزینه و افزایش بازده برای محاسبات عمومی Azure معرفی کرده است.

چرا hyperscaler ها حالا silicon خودشان را کنترل می‌کنند

طراحی یک server CPU از صفر تصمیمی نیست که ارائه‌دهندگان ابر به‌سادگی گرفته باشند — این کار به سال‌ها سرمایه‌گذاری در مهندسی تراشه نیاز دارد که اکثر شرکت‌های نرم‌افزاری هرگز به آن نزدیک هم نمی‌شوند. سود این سرمایه‌گذاری، کنترل بر متغیری است که پیش از این کاملاً در اختیار نقشه راه محصولات Intel و AMD بود: performance-per-watt در مقیاس مرکز داده. حالا برق قید اصلی تعیین‌کننده این است که یک hyperscaler چقدر ظرفیت محاسباتی می‌تواند فیزیکاً مستقر کند — با توجه به محدودیت‌های اتصال به شبکه برق و مصرف هنگفت انرژی خوشه‌های آموزش و inference هوش مصنوعی. یک CPU طراحی‌شده در داخل شرکت می‌تواند دقیقاً برای ترکیب بارهای کاری که همان ارائه‌دهنده واقعاً اجرا می‌کند بهینه شود، نه برای پروفایل عمومی که یک تراشه‌ساز تجاری باید برای پاسخ به همه مشتریان هدف قرار دهد.

به همین دلیل است که Grace CPU انویدیا — یک تراشه مبتنی بر Arm ساخته‌شده برای نشستن مستقیم کنار GPU های انویدیا روی یک برد — نیز در این بحث اهمیت دارد، حتی اگر انویدیا یک ارائه‌دهنده ابر نباشد. این وضوح‌بخش‌ترین شاهد است که مزیت Arm در این چرخه واقعاً به هزینه‌های لایسنس مجموعه دستورالعمل‌ها مربوط نمی‌شود؛ بلکه به این مربوط است که کدام معماری به طراح تراشه اجازه می‌دهد دقیقاً همان ترکیب CPU-حافظه-interconnect را که شتاب‌دهنده یا بار کاری خاصش نیاز دارد بسازد، به‌جای اینکه هر چه Intel یا AMD آن سال عرضه کرده بخرد.

این تحول چه معنایی برای AMD، Intel و فروشندگان مستقل Arm دارد

شتاب رشد سرور AMD نشان می‌دهد که این شرکت سهم را از Intel گرفته نه اینکه در برابر Arm عقب‌نشینی کرده باشد — EPYC همچنان انتخاب پیش‌فرض تجاری x86 برای بارهای کاری است که توسط یک hyperscaler دارای برنامه silicon اختصاصی اجرا نمی‌شوند. بازگشت Intel به رشد مثبت دستاورد کوچک‌تری است، اما پس از سال‌ها از دست دادن سهم سرور، دستاوردی واقعی به‌شمار می‌رود. شرکتی که از روند silicon اختصاصی hyperscaler ها کنار مانده Ampere Computing است — طراح مستقل تراشه Arm برای سرور که پردازنده‌های AmpereOne آن مستقیماً با Graviton و Axion برای مشتریانی رقابت می‌کند که نمی‌خواهند تراشه خودشان را بسازند — ارائه‌دهندگان ابر زیر رده سه بزرگ، و سازمان‌هایی که بارهای کاری Arm را در colocation به‌جای ابرهای hyperscaler اجرا می‌کنند.

این تحول برای کسانی که باید محل اجرای بارهای کاری را انتخاب کنند چه معنایی دارد

برای تیم‌های مهندسی که انواع instance های ابر را ارزیابی می‌کنند، سؤال عملی از «آیا Arm به اندازه کافی بالغ شده؟» به «کدام بارهای کاری باید اول منتقل شوند؟» تغییر کرده است. سرویس‌های stateless و horizontally-scaled — لایه‌های web، API gateway ها، inference serving — تمایل دارند واضح‌ترین دستاوردهای price-performance را روی instance های Graviton یا Axion تجربه کنند، اغلب با هزینه‌ای ۲۰ تا ۴۰٪ پایین‌تر برای throughput معادل — مشروط بر اینکه پایپ‌لاین build شما از قبل باینری‌های Arm64 تولید کند یا runtime زبان شما تفاوت را انتزاع کند (Go، Java و اکثر زبان‌های interpreted با تغییرات حداقلی مهاجرت می‌کنند؛ کدبیس‌های C/C++ با intrinsic های مختص معماری به کار واقعی porting نیاز دارند). تراشه‌هایی که زمانی یک بهینه‌سازی هزینه طاقچه‌ای برای زیرمجموعه‌ای از بارهای کاری بودند، حالا پیش‌فرضی هستند که AWS، Google و مایکروسافت می‌خواهند ظرفیت جدید روی آن اجرا شود — و این یعنی benchmark گرفتن از بار کاری خودتان روی instance های Arm دیگر یک due diligence اختیاری نیست، بلکه رسیدن به جایی است که زیرساخت از قبل در آن قرار دارد.