مدل هزینه LHS

tldr;

این صفحه اجزای داخلی مدل هزینه استفاده شده توسط Latency Hiding Scheduler را شرح می دهد. اگر به تنظیم مدل علاقه دارید مستقیماً به بخش تیونینگ بروید.

Latency Hiding Scheduler (LHS) یک پاس کامپایلر است که HLO DAG را به گونه ای زمان بندی می کند که زمان دیوار را به حداقل می رساند.

تصمیمات آن توسط مدل هزینه یکپارچه هدایت می شود که از ترکیبی از جداول عملکرد و مدل های تحلیلی استفاده می کند. به ویژه XLA جداول عملکرد را برای یک GEMM و مجموعه های اتصال سریع تعبیه می کند و از شبکه تحلیلی و مدل هزینه همجوشی برای موارد دیگر استفاده می کند. بقیه سند عملکرد درونی اینها را در سطح بالایی توصیف می کند.

جداول عملکرد - مجموعه های ICI

جدول عملکرد از دو جزء اصلی تشکیل شده است: یک جمع کننده و یک درون یاب.

گردآورنده

کلکتور یک ابزار C++ است که مسئول تولید جداول عملکرد برای عملیات جمعی است. این عملکرد عملکردهای HLO منفرد (به عنوان مثال، all-gather ، all-reduce ) را در یک فضای پارامتری استاتیکی تعریف شده اندازه‌گیری می‌کند.

چگونه کار می کند

این ابزار یک جارو بر روی طیف وسیعی از عملیات های جمعی، اندازه های انتقال و طرح های انتقال برای یک خوشه مشخص انجام می دهد. برای اجرای HLO تولید شده و جمع‌آوری معیارهای عملکرد، از زیرساخت راه‌انداز HLO چند میزبان و داده‌های ExecutionProfile استفاده می‌کند.

پارامترهای جمع آوری داده ها

جداول تأخیر برای یک محصول متقابل پارامترهای زیر جمع آوری می شود:

• نوع جمعی :
  • all-reduce
  • all-gather
  • reduce-scatter
• اندازه انتقال :
  • مقیاس لگاریتمی از 1024B تا 2GiB (به عنوان مثال، 1024B، 2048B، 4096B، ...)
• طرح انتقال :
  • rail-aligned
  • non-rail-aligned

این جارو برای خوشه‌های درون گره‌ای با ۲، ۴ و ۸ دستگاه اجرا می‌شود.

خروجی

نتیجه اجرای مجموعه یک جدول تاخیر در قالب .pbtxt (تقریبا 116 کیلوبایت در هر پلتفرم) است.

Interpolator

درون یابی جزء کامپایلر است که جداول عملکرد تولید شده را برای ارائه تخمین زمان اجرا در طول کامپایل مصرف می کند.

ساختار داده های داخلی

در مرحله اولیه، Interpolator جدول عملکرد را به یک نقشه پردازش می کند. این نقشه از چندین (collective_type, transfer_scheme) به عنوان کلید خود استفاده می کند.

مقدار مربوط به هر کلید یک صفحه اقلیدسی دوبعدی است. این صفحه توان عملیاتی شبکه (اندازه گیری شده توسط کلکتور) را بر اساس دو محور نمایه می کند:

1. اندازه انتقال
2. تعداد دستگاه های درگیر

جستجو و درون یابی

هنگامی که کامپایلر با یک عملیات جمعی مواجه می شود، Interpolator مراحل زیر را انجام می دهد:

1. با استفاده از عملیات (collective_type, transfer_scheme) به عنوان کلید نقشه، صفحه توان عملیاتی دوبعدی صحیح را شناسایی می کند.
2. سپس از یک میانگین وزنی بازیابی (بر اساس فاصله اقلیدسی) در آن صفحه دوبعدی استفاده می کند و از عملیات (transfer_size, num_devices) به عنوان نقطه پرس و جو استفاده می کند.
3. نتیجه این جستجو یک مقدار توان عملیاتی شبکه واحد و منحصر به فرد است.

دلیل: توان عملیاتی و برون یابی

این سیستم برای ذخیره توان عملیاتی شبکه به جای تأخیر خام طراحی شده است. این انتخاب طراحی به طور قابل توجهی عملکرد برون یابی را برای اندازه های انتقال که به صراحت در جدول وجود ندارد، ساده می کند.

اگر جداول تأخیر اشباع پهنای باند شبکه را در اندازه جمعی S دریافت کنند، توان عملیاتی T در آن نقطه حداکثر در نظر گرفته می شود. برای هر مجموعه جدید با اندازه S' > S ، زمان اجرا را می توان به صورت زیر تخمین زد:

\[\text{EstimatedTime}(S') = \frac{S'}{T_{\text{saturated} } }\]

این به مدل اجازه می‌دهد تا عملکرد مجموعه‌هایی را با هر اندازه‌ای، حتی آن‌هایی که بزرگ‌تر از حداکثر ۲ گیگا بایت اندازه‌گیری شده توسط کلکتور اندازه‌گیری می‌شود، تخمین بزند.

• حداکثر توان را دست کم بگیرید .
• در نتیجه، زمان اجرا را برای انتقال های بزرگ بیش از حد برآورد کنید .

به طور کلی تیم‌های XLA:GPU جداول عملکرد را حفظ می‌کنند، اما در مواردی که کاربر تصمیم می‌گیرد جداول خود را تهیه کند، مسئولیت تولید جداول بر عهده کاربر است که از نماینده بودن آنها اطمینان حاصل کند و شامل اندازه‌گیری‌هایی در ناحیه اشباع شده با پهنای باند برای سخت‌افزار هدف باشد.

جداول عملکرد - GEMM

مشابه سیستم جمع‌آوری‌ها، جداول تأخیر GEMM توسط دو جزء پشتیبانی می‌شوند: یک جمع‌کننده و یک درون‌یابی .

گردآورنده

گردآورنده یک ابزار C++ است که جداول عملکرد را برای ضرب‌های ماتریس عمومی (GEMM) محاسبه می‌کند. عملکرد ضرب ماتریس را در سطح عملیات dot HLO اندازه گیری می کند.

چگونه کار می کند

این ابزار یک فضای ثابت از ابعاد GEMM (بعد دسته ای، دو بعد غیر انقباضی و یک بعد انقباضی) و انواع داده را انجام می دهد.

• انواع داده های پیش فرض: LHS = bf16,f32 , RHS = bf16,f32 , OUT = bf16,f32 .
• زیرساخت: از نمایه ساز عملیات HLO دوباره استفاده می کند.

پارامترهای مجموعه

جداول تاخیر برای یک محصول متقاطع با ابعاد زیر جمع آوری می شود:

• دسته: {1, 2, 4}
• m (غیر قراردادی): {256, 512, ..., 4096}
• n (غیر قراردادی): {256, 512, ..., 4096}
• k (پیمانکاری): {256, 512, ..., 4096}

خروجی و ذخیره سازی

یک جاروی کامل یک جدول تأخیر .pbtxt را ایجاد می کند که آماده مصرف توسط interpolator است.

Interpolator

درون یابی جزء کامپایلر است که از جداول تولید شده برای تخمین عملکرد GEMM استفاده می کند.

دلیل: FLOPS Saturation

جداول تأخیر جمع آوری شده به درون یابی اجازه می دهد تا FLOPS را برای هر ورودی بازسازی کند:

\[\text{FLOPS} = \frac{2 \times b \times m \times n \times k}{\text{runtime} }\]

یک بینش کلیدی این است که FLOPS در یک نقطه خاص اشباع می شود . یعنی سخت افزار به اوج FLOPS فراتر از یک شکل ماتریسی خاص می رسد. این اشباع اجازه می دهد تا از همان روش برون یابی استفاده شده برای گروه ها استفاده شود.

جستجو و درون یابی

درون یابی یک فضای اقلیدسی 4 بعدی را از داده های جدول می سازد. برای ارائه یک تخمین عملکرد، درون یابی میانگین وزنی را در این فضای 4 بعدی انجام می دهد. اگر جدولی برای یک نوع داده خاص وجود نداشته باشد، به عنوان یک اکتشافی، هر بعد به تعداد بایت ها نرمال می شود.

مدل هزینه تحلیلی - DCN

مدل هزینه جمعی منحنی S

مدل منحنی S یک مدل خط سقف شبکه کاملاً تحلیلی است.

نمای کلی

این مدل برای تخمین عملکرد عملیات جمعی بر اساس مجموعه ای از ویژگی های شبکه ثابت طراحی شده است.

ورودی های مدل

مدل به دو دسته ورودی نیاز دارد:

1. ویژگی های شبکه ثابت (تعریف شده توسط کاربر):

   • سربار راه اندازی جمعی
   • سرعت NIC
   • RTT (زمان رفت و برگشت)

   به طور پیش فرض، XLA به طور خودکار یک پلت فرم را شناسایی می کند و از مقادیر برای رایج ترین معماری ها استفاده می کند. این ویژگی ها توسط کاربر قابل تنظیم هستند. برای جزئیات بیشتر به بخش تنظیم مراجعه کنید.

2. ورودی های هر جمعی:

   • نوع جمعی (به عنوان مثال، AllGather ، ReduceScatter )
   • اندازه انتقال
   • تعداد گره های درگیر در ارتباط

یکپارچه سازی

مدل منحنی S در XLA:GPU یکپارچه شده است و در هاپر و بلک ول استفاده می شود.

مدل هزینه تحلیلی - فیوژن

برای کرنل های دیگر، ما به مدل هزینه عملکرد GPU برای تخمین زمان اجرا مناسب تکیه می کنیم. در اینجا می توانید در مورد آن بیشتر بخوانید.

تنظیم

مدل منحنی S را می توان با صدور پرچم های راست XLA تنظیم کرد. پیکربندی پیش فرض باید در اکثر موارد به اندازه کافی خوب باشد، اما کنترل مدل در موارد دیگر در معرض نمایش است.

export NIC_SPEED_GBPS=... # NIC speed per GPU in Gigabytes
export GPUS_PER_NODE=... # Num of GPUs per cluster interconnected with fast network (e.g. NVLINK)
export XLA_FLAGS=--xla_gpu_analytical_latency_estimator_options="nic_speed_gbps=$NIC_SPEED_GBPS,gpus_per_node=$GPUS_PER_NODE"