معرفی Ironwood گوگل: رقیب جدید انویدیا در اینفرنس ابری

نگاهی فنی و تحلیلی به TPU Ironwood گوگل؛ چیپ تمرکز یافته روی اینفرنس با حافظه HBM3e، شبکه ICI و SuperPodهای بزرگ که رقابت با انویدیا را در خدمات هوش مصنوعی ابری تغییر می‌دهد.

6 نظرات
معرفی Ironwood گوگل: رقیب جدید انویدیا در اینفرنس ابری

9 دقیقه

خانواده جدید TPU گوگل به‌نام Ironwood بار دیگر رقابت دیرپای سخت‌افزار هوش مصنوعی را داغ کرده است: این‌بار رقیب واقعی برای انویدیا نه ای‌ام‌دی و نه اینتل، بلکه سیلیکون سفارشی گوگل است که برای عملیات اینفرنس بهینه‌سازی شده است. با ظرفیت حافظه چشمگیر، اتصالات متراکم بین تراشه‌ها و ادعاهای تهاجمی در زمینه کارایی انرژی، Ironwood دارد چهره خدمات هوش مصنوعی ابری در مقیاس بزرگ را بازتعریف می‌کند.

Ironwood بر اساس اعداد: حافظه، محاسبه و یک SuperPod که مقیاس‌پذیر است

در بنیاد Ironwood (TPU v7) یک هدف اصلی قرار دارد — سرو کردن مدل‌ها در محیط تولیدی. گوگل آن را یک تراشه «اولویت-اینفرنس» معرفی کرده است؛ مشخصاتی که برای کاهش تأخیر، کم کردن مصرف انرژی به ازای هر پرس‌وجو و ساده‌تر کردن استقرار مدل‌های بزرگ زبانی و سایر خدمات هوش مصنوعی زمان‌واقعی طراحی شده‌اند. این تمرکز بر اینفرنس یعنی طراحی نه فقط برای حداکثر توان خام، بلکه برای هزینه، تأخیر و کارایی در عملیات روزمره.

  • قدرت محاسباتی اوج FP8 به ازای هر چیپ: حدود ~4,614 TFLOPs
  • حافظه درون‌بسته (on-package): 192 گیگابایت HBM3e (حدود 7–7.4 ترابایت بر ثانیه پهنای‌باند)
  • مقیاس پاد: تا 9,216 تراشه در یک SuperPod
  • محاسبه تجمعی به ازای هر پاد: تقریباً ≈42.5 exaFLOPS (FP8)
  • حافظه HBM کل سیستم به ازای هر پاد: حدود ~1.77 پی‌تابایت

این اعداد خام اهمیت دارند، اما داستان به همان اندازه در نحوه ارتباط تراشه‌ها با هم مطرح است. گوگل از یک InterChip Interconnect (ICI) و چینش 3بعدی توروس برای پیوند دادن تعداد زیادی تراشه در یک SuperPod یکپارچه استفاده می‌کند. این طراحی مبتنی بر یک «فابریک مقیاس‌ بالا» و یک شبکه بین‌پاد 1.8 پی‌تابایتی است تا مدل‌های بسیار بزرگ را در حافظه سریع نگه دارد و از حرکت متناوب وزن‌ها روی لینک‌های کندتر جلوگیری کند. نگهداری وزن‌ها نزدیک به واحدهای محاسباتی — با حافظه داخلی زیاد و بین‌اتصال کم latenسی — نقطه‌قوتی است که برای اجرای real-time و سرویس‌های مقیاس‌پذیر حیاتی است.

علاوه بر اعداد خام، نکات عملی و مهندسی وجود دارد که تفاوت‌ها را روشن می‌کند: چگونگی تقسیم کار میان هسته‌ها، هماهنگ‌سازی حافظه توزیع‌شده، مدیریت خطای لینک‌ها در مقیاس پاد، و پروتکل‌های زمان‌بندی که تأثیر قابل‌توجهی روی تأخیر و بهره‌وری انرژی دارند. برای مثال، استفاده از FP8 به عنوان فرمت عددی هدفمند برای اینفرنس، امکان افزایش توان محاسباتی را فراهم می‌کند در حالی که دقت کافی برای اغلب کاربردهای تولیدی حفظ می‌شود.

چرا اینفرنس نقشه رقابت را تغییر می‌دهد

پیش‌تر نبرد اصلی در حوزه هوش مصنوعی بر سر آموزش بود: TFLOPs خالص، استخرهای حافظه عظیم و کرنل‌های بهینه‌سازی‌شده معیارهای مهم بودند و در آن میدان انویدیا با پردازنده‌های گرافیکی خود حکمرانی می‌کرد. اما اقتصاد هوش مصنوعی در حال تغییر است. پس از آموزش مدل‌ها، میلیاردها پرس‌وجوی اینفرنس — نه اجرای آموزش — بار کاری واقعی را تشکیل می‌دهند. این تغییر وزن به معنی ارزش‌گذاری بالاتر روی تأخیر (latency)، توان پردازش پرس‌وجو، انرژی مصرفی به ازای هر پرس‌وجو و کارایی هزینه‌ای است.

Ironwood دقیقاً حول همین معیارها شکل گرفته است. حافظه بزرگ on-package باعث کاهش «همهمه» بین تراشه‌ها برای مدل‌های عظیم می‌شود و در نتیجه تأخیر را پایین می‌آورد. گوگل ادعا می‌کند که Ironwood نسبت به نسل‌های قبلی TPU به‌طور چشمگیری بهبود عملکرد و کارایی انرژی دارد (شرکت تقریباً از افزایش دو برابری کارایی قدرت نسبت به نسل‌های پیشین سخن گفته است). برای هایپراسکیلرها و مشتریان ابری که برای ظرفیت اینفرنس 24/7 هزینه می‌پردازند، این کارایی می‌تواند به صرفه‌جویی قابل توجهی در هزینه‌ها بیانجامد.

از منظر عملیاتی، کاهش مصرف انرژی به ازای هر پرس‌وجو و پایین آوردن تأخیر، اثرات زنجیروار روی طراحی سرویس و تجربه کاربری دارد: زمان پاسخ کوتاه‌تر برای کاربران نهایی، هزینه کمتر برای پردازش حجم بالای درخواست‌ها و امکان اجرای مدل‌های بزرگ‌تر در هزینه‌های عملیاتی مشابه. به‌علاوه، تمرکز روی اینفرنس نوعی بهینه‌سازی نرم‌افزاری-سخت‌افزاری را می‌طلبد؛ runtimeهای سفارشی، کتابخانه‌های بهینه‌شده برای FP8 و ابزارهای مانیتورینگ تاخیر که همگی باید با سخت‌افزار همگام شوند.

اتصالات بین‌تراشه، SuperPodها و قفل شدن در اکوسیستم

یک مزیت رقابتی دیگر ادغام عمودی است. با ارائه Ironwood از طریق Google Cloud، گوگل می‌تواند کل پشته — سخت‌افزار، شبکه و runtime — را برای کاهش هزینه به ازای هر پرس‌وجو بهینه‌سازی کند. رویکرد SuperPod آن‌ها، با بین‌اتصال متراکم و یک فابریک scale-up، برای سرو کردن مدل‌های بسیار بزرگ با جریمه‌های عملکردی کمتر نسبت به یک خوشه GPU پراکنده طراحی شده است.

این یکپارچگی عمودی برای انویدیا ریسک‌های راهبردی ایجاد می‌کند. حتی با وجود رک‌های Rubín انویدیا و GPUهای B200 Blackwell که هدفشان اینفرنس است، ممکن است مشتریان ابری زیر بار صرفه‌جویی محسوس در تأخیر و هزینه عملیاتی، زیرساخت بومی TPU را ترجیح دهند. چنین تغییری می‌تواند به قفل‌شدن قوی‌تر مشتریان به معماری سخت‌افزاری یک ارائه‌دهنده ابری منجر شود؛ یعنی زمانی که هزینه جابه‌جایی مدل‌ها و داده‌ها بین پلتفرم‌ها بالا می‌رود، تمایل به ماندن در یک اکوسیستم بیشتر می‌شود.

از سوی دیگر، برای کاربران سازمانی و توسعه‌دهندگان مدل‌ها نیز پیامدهایی وجود دارد: نیاز به ابزارهای تبدیل مدل (model conversion)، تغییر در شیوه‌های استقرار و احتمالا بهبودهای سطحی در طراحی مدل‌ها برای بهینه شدن روی Ironwood (مثلاً کوانتیزه کردن به FP8 یا طراحی لایه‌هایی که حافظه را بهتر مدیریت کنند). شرکت‌هایی که به دنبال حداکثر کارایی اینفرنس و کمترین هزینه عملیاتی هستند، ممکن است راهکار کامل‌تری را ترجیح دهند که شامل سخت‌افزار و خدمات مدیریت‌شده ابری باشد.

جنسن هوانگ متوجه شده است

مدیرعامل انویدیا به‌صورت علنی اذعان کرده است که ساخت ASIC سفارشی کار دشواری است و TPUs را به‌عنوان رقیبی معنی‌دار نام برده است. این شناسایی اهمیت دارد: زمانی که بازیگر غالب بازار به‌طور عمومی یک فناوری رقیب را تهدید می‌داند، معمولاً به معنای سرمایه‌گذاری متمرکزتر و چرخه‌های سریع‌تر محصول در هر دو سو است. پاسخ بازار می‌تواند شامل بهبودهای سریع در نرم‌افزار، عرضه محصولات جدید و رقابت تنگاتنگ‌تری در سطح خدمات ابری باشد.

ایلّا و واکنش‌های بعدی از سوی اکوسیستم، مانند ادغام مدل‌ها با کتابخانه‌های بهینه‌شده، انتشار SDKهای جدید یا همکاری بین تامین‌کنندگان سرویس ابری، می‌تواند سرعت پذیرش و تکامل این فناوری را تعیین کند. در واقع، توانایی یک رقیب در ایجاد اکوسیستمی از ابزارها، مستندات و پشتیبانی برای توسعه‌دهندگان اغلب تعیین‌کننده موفقیت در بازار است.

آیا انویدیا محکوم به فناست؟

قطعاً خیر — اما قواعد بازی در حال تغییر است. انویدیا هنوز در محاسبات GPU چندمنظوره، اکوسیستم نرم‌افزاری وسیع و پذیرش گسترده بازار برای آموزش مدل‌ها و بسیاری از سناریوهای اینفرنس پیشتاز است. آنچه Ironwood انجام می‌دهد، باز کردن یک محور جدید رقابت متمرکز بر اقتصاد اینفرنس است. برای شرکت‌هایی که استقرارهای زمان‌واقعی عظیم را اجرا می‌کنند، استراتژی TPU گوگل می‌تواند عامل تعیین‌کننده‌ای باشد.

به طور خلاصه: نبرد هوش مصنوعی در حال تحول از «چه کسی بیشترین FLOP را دارد» به «چه کسی بیشترین پرس‌وجو را سریع‌تر و ارزان‌تر سرو می‌کند» است. با ورود Ironwood به فاز تولید، انتظار می‌رود که ارائه‌دهندگان ابری، هایپراسکیلرها و شرکت‌های بزرگ بازنگری‌هایی در محل اجرای بارهای اینفرنس خود داشته باشند — و این موضوع گوگل را به جذاب‌ترین رقیب فعلی تبدیل می‌کند.

در سطح فنی‌تر، رقابت میان معماری‌های GPU و TPU به ترکیبی از عوامل وابسته است: تطبیق‌پذیری معماری برای انواع workloads، هزینه کل مالکیت (TCO)، قابلیت‌های شبکه‌ای برای نگهداری مدل‌ها در حافظه سریع، و سرمایه‌گذاری در نرم‌افزار و ابزارهای مدیریتی. Ironwood با تاکید بر پهنای‌باند حافظه بالا (HBM3e)، اتصال ICI، و SuperPodهای بزرگ، از منظر اینفرنس مزیت‌های متمرکزی ارائه می‌دهد که برای برخی کاربردها قابل چشم‌پوشی نیستند.

برای تیم‌های مهندسی و تصمیم‌گیرندگان فناوری اطلاعات، ارزیابی میان‌مدت شامل تحلیل trade-offهایی است که بین انعطاف‌پذیری GPUها و کارایی بهینه‌شده TPUها وجود دارد. در مواردی که بارهای کاری ترکیبی (مثلاً آموزش و اینفرنس) و نیاز به اکوسیستم نرم‌افزاری گسترده مطرح است، GPUها کماکان جذاب خواهند بود. اما در سناریوهای اینفرنس با حجم بسیار بالا و حساس به تأخیر، Ironwood و زیرساخت‌هایی از این دست می‌توانند انتخاب اقتصادی‌تر و فنی‌تر باشند.

در نهایت، رقابت به نفع مصرف‌کننده و نوآوری خواهد بود: فشار رقابتی بین گوگل و انویدیا احتمالاً به بهبودهای سریع‌تر در کارایی انرژی، کاهش هزینه‌ها و انتشار ابزارهای بهتر برای توسعه‌دهندگان می‌انجامد. این حرکت‌ها همچنین می‌توانند منجر به استانداردهایی تازه برای اینفرنس در ابر شوند و مسیر را برای معماری‌های جدید، بهینه‌سازی‌های نرم‌افزاری و مدل‌های کوچکتر اما کاراتر هموار کنند.

منبع: wccftech

ارسال نظر

نظرات

رضا

احساس می‌کنم کمی هایپ داره، مخصوصا ادعاهای دو برابر کارایی. امیدوارم واقعی باشه، چون رقابت به نفع همه‌ست.

سفرمن

تغییر محور از FLOPs به پرس‌وجوها منطقیه. رقابت احتمالا به نفع مصرف‌کننده‌ست، ولی قفل شدن در اکوسیستم رو هم نباید دست کم گرفت.

لابکور

من تو یه تیم infra دیدم که حتی چند میلی‌ثانیه اختلاف در latency، هزینه‌ها رو بالا می‌برد. Ironwood می‌تونه عالی باشه، اما پیچیدگی هم داره

توربوای

این اعداد خیلی جذابن، ولی واقعا در دنیای واقعی این مقیاس‌ها و reliability جواب میدن؟ لینک‌ها و خطاها مهمن...

کوینپایل

منو قانع نمی‌کنه که انویدیا بی‌خیال شه، ولی Ironwood برای سرویس‌های 24/7 حسابی منطقیه.

دیتاپالس

وااای، فکرش رو نمی‌کردم گوگل اینقدر روی اینفرنس متمرکز بشه! حافظه و SuperPodها... اگه واقعی باشه، بازی عوض میشه.

مطالب مرتبط