‏چهار پروندهٔ واقعی از افت کارایی کلاسترهای انویدیا

انویدیا توی یه پست فنی نوشته که دو کلاستر آموزشی با سخت‌افزار کاملاً یکسان — چه H100، چه GB200 NVL72 یا GB300 NVL72 — می‌تونن روی همون مدل و همون batch size، خروجی‌های واقعاً متفاوتی بدن. به گفتهٔ نویسنده‌ها معمولاً ۸ تا ۱۲ درصد فاصله بین استقرار شرکا و معماری مرجع (RA) دیده می‌شه، و مقصر یه دسته تنظیم ریز توی کرنل، هایپروایزر، بایوس و NCCL هست که هر کدوم چند درصد می‌خورن و روی هم جمع می‌شن.

پروندهٔ اول یه کلاستر GB200 NVL72 بوده که pre-training مدل DeepSeek-V3 داخل ماشین مجازی رو ۱۲ تا ۱۴ درصد کندتر از bare-metal اجرا می‌کرده، در حالی که مدل‌های dense مثل Llama 3 70B مشکلی نداشتن. پروفایل perf روی هاست نشون داد ۲۴٪ سیکل‌های CPU صرف تابع arm_smmu_cmdq_issue_cmdlist می‌شه؛ یعنی هر map/unmap مهمان از هایپروایزر رد می‌شده و توی یه صف فرمان سریالایز می‌شده. راه‌حل، فعال‌کردن CMDQV/VCMDQ توی کرنل هاست و باز کردنش برای مهمان بود.

پروندهٔ دوم یه کلاستر H100 با ۱۲٪ افت روی Llama 3 70B بود. turbostat نشون داد هسته‌ها روی ۳.۰ گیگاهرتز گیر کردن، در حالی که توربوی اسمی ۳.۸ بوده — چون بایوس C-state رو روی C1 قفل کرده بود؛ یه پیش‌فرض «کم‌تأخیر» که برای بار کاری آموزش اشتباهه. اجازه دادن به هسته‌های بیکار برای رفتن تا C6 حدود ۴٪ برگردوند، و جدا کردن سرویس‌های هاست از پروسه‌های آموزش با cpuset بقیهٔ فاصله رو تا ۳٪ کم کرد.

پروندهٔ سوم یه کلاستر GB300 NVL72 با ConnectX-8 بود که تا ۵۱۲ GPU حدود ۳۱٪ عقب می‌افتاد و زمان AllGather و ReduceScatter توش لخت مونده بود. زیاد کردن NCCL_IB_QPS_PER_CONNECTION از ۱ به ۴، زمان هر iteration رو روی کلاستر مرجع از حدود ۱.۰۹ به ۰.۸۳ ثانیه رسوند. ولی نویسنده تأکید می‌کنه این تنظیم رو همه‌جا بالا نبرین: QPS به فابریک و اندازهٔ پیام وابسته‌ست و جای دیگه ممکنه فقط سربار CPU اضافه کنه.

پروندهٔ چهارم از همه ساکت‌تر بود: توی یه استقرار مجازی B200، تست‌های NCCL روی هاست سالم بودن ولی داخل کانتینر enroot، کالکتیوها ۲ تا ۴ برابر کندتر می‌شدن. علتش این بود که NCCL_TOPO_FILE و خود فایل توپولوژی به کانتینر نرسیده بودن و NCCL بی‌سروصدا به تشخیص خودکار برمی‌گشت — نتیجه‌ش ۱۳ تا ۵۳ درصد افت. درس نویسنده اینه که چک‌ها رو از داخل همون کانتینر و همون allocation اسلورمی بزنین که بنچمارک قراره اونجا اجرا بشه.

نکات کلیدی:

• فاصلهٔ ۸ تا ۱۲ درصدی بین کلاسترهای شریک و معماری مرجع انویدیا معمولاً از چند تنظیم ریز جمع می‌شه، نه یه خرابی بزرگ
• روی Grace، نبود CMDQV/VCMDQ زیر مجازی‌سازی به بارهای MoE تا ۱۲٪ ضربه می‌زنه
• قفل‌کردن C-state روی C1 توی بایوس جلوی توربوی هسته‌ها رو می‌گیره؛ اجازهٔ C6 حدود ۴٪ برمی‌گردونه
• مقدار ۴ برای NCCL_IB_QPS_PER_CONNECTION روی فابریک ۱.۶ ترابیتی جواب داد، ولی تنظیم عمومی نیست
• متغیرهای محیطی NCCL و فایل توپولوژی باید داخل کانتینر هم دیده بشن، وگرنه افت بی‌صدا اتفاق می‌افته