تصور کنید می‌خواهید یک مدل هوش مصنوعی را برای مهندسی نرم‌افزار آموزش دهید، اما نیمی از قدرت پردازش شما تنها به این دلیل تلف می‌شود که سخت‌افزار منتظر پاسخ کندی یک کد است. Prime Intellect با انتشار نسخه 0.6.0 از چارچوب prime-rl، این گلوگاه محاسباتی را برای مدل‌های عظیم تریلیون-پارامتری از بین برده است. این پیشرفت به مدل‌های ترکیب خبره‌ها (Mixture-of-Experts یا MoE) اجازه می‌دهد تا برای وظایف عامل‌محور (Agentic) تنها با استفاده از ۲۸ گره H200 پس‌آموزش (Post-train) ببینند.
آموزش عامل‌های هوشمند اساساً با آموزش چت‌بات‌ها متفاوت است. در بارهای کاری عامل‌محور، برخی از اجراهای کدنویسی (Rollouts) ممکن است ساعت‌ها زمان ببرند، در حالی که برخی دیگر در عرض چند ثانیه به پایان می‌رسند. در یادگیری تقویتی (RL) سنکرون و همزمان، GPUها بیکار می‌مانند تا کندترین اجرا به پایان برسد و سپس به‌روزرسانی سیاست بعدی انجام شود. این مشکل «دم‌دراز» (Long-tail)، مقیاس‌بندی مدل‌های تریلیون-پارامتری را برای اکثر آزمایشگاه‌ها به دلیل هزینه‌های گزاف، غیرممکن می‌کرد. این چالش در مدیریت زمان‌بندی‌های نامتقارن، مشابه پیچیدگی‌هایی است که در رویکردهای بهینه‌شده برای تولید نیمه‌رساناها با RL رویداد-محور برای مدیریت بازه‌های زمانی گسسته دیده می‌شود.
نقش یادگیری تقویتی نامتقارن
برای حل این معضل، prime-rl 0.6.0 یادگیری تقویتی نامتقارن (Asynchronous RL) را پیاده‌سازی کرده است. این معماری، سیستم‌های آموزش‌دهنده (Trainer) و استنتاج (Inference) را از یکدیگر تفکیک (Disaggregate) می‌کند و به آن‌ها اجازه می‌دهد به صورت مستقل مقیاس‌بندی شده و اجرا شوند. در این ساختار، سیاست استنتاج به محض اینکه گام بهینه‌ساز (Optimizer step) به پایان برسد، به‌روز می‌شود و منتظر تکمیل شدن یک دسته کامل از اجراها نمی‌ماند. در واقع، تنها یک نقطه همگام‌سازی وجود دارد و آن به‌روزرسانی سیاست است.
چارچوب prime-rl وزن‌های جدید را به محض تولید ارسال می‌کند. اجراهای اعزام‌شده، پیشوند حافظه فعال (Active prefix cache) خود را حفظ می‌کنند؛ این بدان معناست که یک اجرای واحد ممکن است توکن‌هایی از چندین نسخه مختلف سیاست مدل را با هم ترکیب کند. اجراهای جدید نیز حافظه KV خود را از طریق یک «نمک KV-cache» (KV-cache salt) بازسازی می‌کنند، حتی اگر پیشوندها یکسان باشند. برای حفظ پایداری سیستم، درخواست‌هایی که از سیاست‌های بسیار قدیمی پیروی می‌کنند، بر اساس مقدار تنظیم شده در max_off_policy_steps حذف می‌شوند.
پشته بهینه‌سازی فنی
کارایی این چارچوب توسط چندین مکانیسم خاص استنتاج و آموزش هدایت می‌شود که هدف آن‌ها به حداکثر رساندن توان عملیاتی (Throughput) و در عین حال محدود کردن تأخیر است:
- جداسازی P/D: این سیستم کارکنان پیش‌پُرکردن (Prefill) و رمزگشایی (Decode) را جدا می‌کند. این کار از خفه شدن تأخیر رمزگشایی توسط خروجی‌های طولانی ابزارها جلوگیری می‌کند؛ موضوعی که وقتی نسبت توکن‌های پیش‌پُرکردن به رمزگشایی در مدل-محیط به ۴:۱ می‌رسد، حیاتی است.
- موازات گسترده خبره‌ها (Wide EP): خبره‌ها روی ۳۲ یا تعداد بیشتری GPU پخش می‌شوند و با یک رتبه موازی داده (Data-parallel rank) بزرگ جفت می‌شوند. هر GPU به عنوان یک نقطه انتهایی عمل کرده و خبره‌های مجزایی را نگه می‌دارد. برای کاهش حافظه لایه‌های فعال از DeepEP در ارتباطات چندگره ای استفاده می‌شود، زیرا عملیات all2all بومی torch تنها در داخل یک گره سریع است.
- بازپخش مسیریاب (R3): این مکانیسم تصمیمات مسیریابی استنتاج را ثبت کرده و آن‌ها را مستقیماً روی آموزش‌دهنده بازپخش می‌کند. این کار ناهماهنگی KL را تقریباً یک مرتبه بزرگی (۱۰ برابر) کاهش می‌دهد. از آنجایی که خبره‌های مسیریابی شده (با شکل
[num_layers, top_k, seq_len]) می‌توانند به صدها گیگابایت در سرعت‌های ده‌ها گیگابیت بر ثانیه برسند، prime-rl با آن‌ها به عنوان محموله‌های کدر (Opaque payloads) رفتار می‌کند که توسط عملیات‌های بهینه PyTorch پردازش می‌شوند. - حافظه KV لایه‌ای: هم‌زمانی بالا به فضای عظیمی نیاز دارد. در حالی که vLLM از یک استخر برای هر کارکن استفاده می‌کند، prime-rl از Mooncake Store برای تجمیع متمرکز RAM و دیسک در تمام گره‌ها استفاده می‌کند.
- استنتاج FP8: با استفاده از هسته‌های DeepEP و DeepGEMM، دقت FP8 سرعت هر دو مرحله پیش‌پُرکردن و رمزگشایی را افزایش می‌دهد.
- مسیریابی منعطف: این چارچوب به طور پیش‌فرض یک فورک از vllm-router را ارائه می‌دهد اما از مسیریاب NVIDIA Dynamo نیز به عنوان جایگزین پشتیبانی می‌کند. مسیریاب‌ها کارکنان را بر اساس بار زنده، عمق صف و استفاده مجدد از حافظه KV امتیازدهی می‌کنند.
معماری آموزش و موازات سه‌بعدی
در سمت آموزش، prime-rl بر پایه torchtitan بنا شده و بر یک استراتژی موازات سه‌بعدی برای مدیریت توزیع حافظه تکیه دارد:
- FSDP (FSDP2): پارامترها، گرادیان‌ها و حالت‌های بهینه‌ساز را تکه‌تکه (Shard) کرده و وزن‌ها را بر اساس نیاز در هر لایه جمع‌آوری می‌کند.
- موازات خبره‌ها (EP): خبره‌ها را در داخل یک لایه تکه‌تکه می‌کند. این موضوع حیاتی است زیرا با ۸۰۰ میلیارد پارامتر در float32 و ۷۸ لایه، جمع‌آوری تمام (all-gather) یک لایه به حدود ۴۰ گیگابایت حافظه نیاز دارد و همپوشانی لایه‌ها به ۸۰ گیگابایت می‌رسد. تنظیم EP=8، جمع‌آوری کامل را با ارسال توکن‌ها (Token dispatch) جایگزین می‌کند.
- موازات زمینه (CP): بعد توالی را با استفاده از Ulysses یا Ring Attention تکه‌تکه می‌کند. این امر در طول توالی‌های بالای ۱۳۱ هزار توکن، جایی که فعال‌سازها (Activations) حافظه را تسخیر می‌کنند، ضروری است.
برای پایدار کردن آموزش، از دقت FP8 با مقیاس بلوکی (block-scaled)—تکنیکی که توسط DeepSeek V3 پیشنهاد شده—استفاده می‌شود. هدف این کار افزایش توان عملیاتی نیست، بلکه تطبیق دقت آموزش‌دهنده و استنتاج برای کاهش ناهماهنگی KL است. این رویکرد در توزیع حافظه و مدیریت لایه‌ها، شباهت‌های ساختاری با سیستم Piper دارد که با حذف وابستگی استراتژی به اجرا، پیچیدگی‌های موازی‌سازی توزیع‌شده را کاهش می‌دهد.
در یک مطالعه موردی اصلی، تیم مذکور مدل zai-org/GLM-5.1 را روی وظایف مهندسی نرم‌افزار (SWE) آموزش داد. این اجرا به طول توالی ۱۳۱ هزار رسید در حالی که زمان هر گام زیر ۵ دقیقه باقی ماند. این تنظیمات از اندازه دسته ۲۵۶ اجرا در ۲۸ گره H200 استفاده کرد و با یک فرمان ساده در خوشه Slurm آغاز شد: uv run rl @ examples/glm5_llmd/rl.toml --output-dir /shared/outputs/glm5-llmd.
این تغییر در معماری، گلوگاه را از «دسترس به قدرت پردازش خام» به «بهینه‌سازی توان عملیاتی» منتقل کرده است. با استفاده از یک پیاده‌سازی سفارشی موازات زمینه برای DSA (که Ulysses و Ring Attention نمی‌توانند مستقیماً موازات کنند)، prime-rl اجازه می‌دهد مدل‌های تریلیون-پارامتری روی بخشی کوچک از سخت‌افزاری که معمولاً نیاز است، آموزش ببینند.
برای توسعه‌دهندگان، این بدان معنای این است که مانع ایجاد عامل‌های کدنویسی بسیار توانمند، دیگر صرفاً مالکیت یک خوشه عظیم نیست، بلکه پیاده‌سازی ارکستراسیون صحیح حافظه و مسیریابی است. باید منتظر ماند و دید که این چارچوب چگونه با سایر مدل‌های بزرگ MoE مانند moonshotai/Kimi-K2.7-Code یا nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B-BF16 ادغام می‌شود، زیرا تیم Prime Intellect پیشنهاد می‌کند که این بهینه‌سازی‌ها به طور گسترده در سراسر اکوسیستم MoE کاربرد دارند.
گام بعدی شما
- اگر روی توسعه عامل‌های کدنویسی کار می‌کنید، مستندات prime-rl را برای پیاده‌سازی Mv-cache مطالعه کنید.
- بررسی کنید که آیا مدل‌های MoE شما با استفاده از FP8 می‌توانند نرخ تأخیر را کاهش دهند.
- نحوه ادغام این بهینه‌سازی‌ها با مدل‌های بزرگ‌تر مانند Kimi-K2.7 را دنبال کنید.
اما تأثیر این معماری بر مدل‌های متن‌باز کوچک‌تر حتی می‌تواند چشمگیرتر باشد؛ برای درک این موضوع به بررسی ما درباره‌ی مدل‌های SLM مراجعه کنید.
گفتگو