‏همگام‌سازی وزن‌ها تو RL با کمتر از ۰.۲۳ ثانیه توقف

تو RL بزرگ، وزن‌های trainer و وزن‌های sampler (یعنی موتورهایی که با مدل نمونه تولید می‌کنن) باید تا جای ممکن یکی باشن. پس بعد از هر قدم آموزش، باید ترابایت‌ها وزن جابه‌جا بشه. تیم humans& تو این مقاله روشی معرفی می‌کنه که به گفتهٔ خودشون تو اکثر کارهای واقعی از P2P RDMA داخل کلاستر (یعنی انتقال مستقیم و پرسرعت بین GPUها) هم سریع‌تره، حتی وقتی trainer و samplerها تو یه کلاستر نیستن.

پایهٔ کار delta weight sync هست. trainer بین وزن قدیم و جدید یه XOR بیتی می‌گیره و یه mask هم‌اندازهٔ مدل می‌سازه که هر بیت ۱ یعنی اون بیت عوض شده. sampler همین mask رو با وزن قدیمش XOR می‌کنه و به وزن جدید می‌رسه، بدون هیچ محاسبهٔ اعشاری. چون سیگنال RL پراکنده‌ست، فقط بخش خیلی کوچیکی از وزن‌ها عوض می‌شه، پس mask تقریباً همه‌ش صفره و خیلی خوب فشرده می‌شه. تو workload مقاله (مدل GLM-5.3 با فرمت NVFP4 و ۴۴۵ گیگابایت وزن، با تغییر ۰.۰۸۵٪ تو هر قدم) نسخهٔ ساده که از checkpoint روی دیسک استفاده می‌کنه، payload رو به ۰.۸۷۶ گیگابایت می‌رسونه ولی رفت‌وبرگشت دیسک و reload کامل مدل این مزیت رو از بین می‌بره.

قدم بعدی بردن کل مسیر روی GPU بود. کارت‌های Blackwell یه Decompression Engine یا DE دارن، یعنی یه بخش سخت‌افزاری ثابت که بعضی الگوریتم‌ها مثل LZ4 و Snappy رو خیلی سریع باز می‌کنه. تیم LZ4 رو انتخاب کرد، XOR رو با یه kernel تو Triton مستقیم تو حافظهٔ HBM اعمال کرد و فشرده‌سازی رو بین همهٔ GPUهای trainer پخش کرد. این baseline قوی بود (۰.۸۳۴ ثانیه سمت trainer و ۶.۰۴۱ ثانیه سمت گیرنده)، ولی دو مشکل داشت: payload با LZ4 به ۵.۳۶ گیگابایت می‌رسید که ۶.۱ برابر Zstd روی CPU بود، و بافرهای بزرگ GPU مجبورشون می‌کرد KV cache رو خالی کنن.

راه‌حل نهایی فشرده‌سازی دولایه بود: اول Snappy روی GPU و بعد یه لایه Zstd روی اون. Snappy به‌تنهایی ۱۹.۷۸ گیگابایت می‌ده ولی بعد از Zstd به ۲.۶۵ گیگابایت می‌رسه، یعنی ۰.۶٪ اندازهٔ مدل. لایهٔ Zstd رو CPU باز می‌کنه و نتیجه رو تو حافظهٔ pinned می‌ذاره، پس تو این مرحله inference بدون توقف ادامه پیدا می‌کنه. بعد DE مستقیم از حافظهٔ CPU می‌خونه و تو HBM می‌نویسه. با یه pipeline دوبافره، DE تو یه بافر باز می‌کنه و همزمان kernel مربوط به XOR روی SMها بافر دیگه رو اعمال می‌کنه. این بافرها فقط دو لایهٔ مدل رو نگه می‌دارن، پس دیگه لازم نیست KV cache خالی بشه.

نتیجه: سمت trainer ۰.۷۸۹ ثانیه، آماده‌سازی گیرنده ۲.۳۵۵ ثانیه که inference رو متوقف نمی‌کنه، و فقط ۲۱۹.۶ میلی‌ثانیه توقف واقعی. همین زیرساخت برای eval، بازیابی موتورهایی که crash می‌کنن، و deploy هم کاربرد داره: کافیه delta کوچیک فرستاده بشه و موتور با یه فراخوانی /update_weights_from_gpu_delta آپدیت بشه. نویسنده این رو تا حدی جایگزین بهتری برای LoRA می‌دونه، چون delta کامل پارامترها رو بدون محدود کردن rank منتقل می‌کنه. کد تو Miles و SGLang متن‌باز شده و تیم معتقده الان گلوگاه خود سخت‌افزاره.

نکات کلیدی:

• توقف sampler زیر ۰.۲۳ ثانیه و کل همگام‌سازی زیر ۴ ثانیه برای مدل ۴۴۵ گیگابایتی.
• پایهٔ روش، XOR بیتی بین وزن قدیم و جدیده که بدون محاسبهٔ اعشاری و lossless کار می‌کنه.
• Snappy به‌همراه Zstd payload رو به ۲.۶۵ گیگابایت (۰.۶٪ مدل) می‌رسونه، در برابر ۵.۳۶ گیگابایت با LZ4 خالی.
• Decompression Engine تو Blackwell همزمان با kernelهای Triton روی SMها کار می‌کنه.
• نیازی به خالی کردن KV cache نیست، چون بافرها فقط دو لایهٔ مدل رو نگه می‌دارن.
• پیاده‌سازی تو Miles و SGLang متن‌باز شده.