اگر برای هر ساعت استفاده از GPUهای ابری هزینه پرداخت می‌کنید، باید بدانید که بخش بزرگی از بودجه شما صرف زمانی می‌شود که این پردازنده‌های گران‌قیمت در انتظار دریافت داده‌ها از حافظه هستند. این «هزینه پنهان»، گلوگاه واقعی استقرار مدل‌های زبانی در مقیاس صنعتی است. در واقع، بهبود کارایی انتقال داده‌ها مستقیماً بر میزان بهره‌وری واقعی واحدهای محاسباتی اجاره شده و عملکرد تأخیر (Latency) در سرویس‌های استنتاج تأثیر می‌گذارد.
طبق گزارش منتشر شده در ۸ سپتامبر ۲۰۲۶ توسط Mingxin، جایگزینی ذخیره‌سازهای سنتی با آرایه‌های All-Flash مبتنی بر NVMe-oF (NVMe over Fabrics) می‌تواند سرعت بارگذاری مدل‌ها را تا ۹.۳ برابر افزایش دهد. در چشم‌انداز فعلی ابر، نمونه‌های GPU از ارائه‌دهندگانی مانند Amazon Web Services (AWS) و Microsoft Azure به‌صورت ساعتی صورت‌حساب می‌شوند. طبق صفحه قیمت‌گذاری EC2 On-Demand در AWS، صورت‌حساب بر اساس خانواده نمونه (Instance Family) و میزان استفاده ساعتی است. همچنین صفحه قیمت‌گذاری ماشین‌های مجازی لینوکس در Microsoft Azure، تفاوت‌های دقیقی بین حالت‌های On-demand، Reserved و Spot قائل شده و تغییرات قابل‌توجهی بر اساس منطقه جغرافیایی و مشخصات نمونه اعمال می‌کند. این وضعیت یک تنش مالی ایجاد می‌کند: هر ثانیه‌ای که یک GPU در حالت انتظار (Idle) می‌ماند، یک هزینه مستقیم و هدررفته برای سازمان است.
برای درک بهتر، واحد پردازش گرافیکی (GPU) را مثل یک موتور جت فوق‌سریع و ذخیره‌ساز شما را مثل یک پمپ سوخت تصور کنید؛ اگر پمپ کند باشد، موتور فارغ از اینکه چه قدر اسب‌بخار دارد، متوقف می‌ماند. همین اتفاق زمانی رخ می‌دهد که وزن‌های مدل یا KV Cache (حافظه کلید-مقدار) از طریق پروتکل‌های قدیمی بارگذاری می‌شوند. همان‌طور که در تحلیل‌های پیشین ما درباره زیرساخت‌های محاسباتی اشاره کردیم، بهینه‌سازی مسیر انتقال داده اکنون اهمیت بیشتری نسبت به افزایش خام قدرت پردازش دارد.
به گزارش Mingxin، برای اکثر سازمان‌ها، گلوگاه اصلی پهنای باند خام شبکه نیست، بلکه عملکرد خواندن تصادفی (Random Read) سیستم ذخیره‌سازی و سربار پشته پروتکل (Protocol Stack Overhead) است. زمانی که وزن‌های مدل، KV Cache یا نقاط بازرسی (Checkpoints) آموزش باید از ذخیره‌ساز راه دور بارگذاری شوند، تأخیر بالای مسیر ذخیره‌سازی باعث می‌شود GPUها به‌طور مکرر وارد حالت انتظار شوند. طبق تحقیقات عمومی Epoch AI، مقیاس محاسبات AI و هزینه‌های آن به‌طور مداوم در حال رشد است، به این معنی که فضای بهینه‌سازی در کارایی انتقال داده‌ها در محاسبه هزینه کل مالکیت (TCO) وزن بیشتری خواهد داشت.
به گزارش Mingxin، اکثر سازمان‌ها با این مشکل روبرو هستند که گلوگاه اصلی، عملکرد خواندن تصادفی سیستم ذخیره‌سازی و سربار پروتکل‌هاست. این شرکت آزمایش‌هایی را روی پلتفرم Huawei Atlas 910B انجام داد و عملکرد NFS را با آرایه FX100 مقایسه کرد. در خوشه‌های محاسباتی سنتی، اغلب از سیستم‌های فایل شبکه (NFS) به عنوان ذخیره‌ساز مشترک استفاده می‌شود که در این محیط‌ها، سربار پشته پروتکل به‌ویژه در سناریوهای خواندن تصادفی با هم‌زمانی بالا بسیار شدید است. نتایج مقایسه NFS با آرایه All-flash NVMe-oF مدل FX100 به‌شدت تکان‌دهنده بود:
- مدل DeepSeek-32B: زمان بارگذاری از ۶۹۱ ثانیه به ۱۱۲ ثانیه کاهش یافت (۶.۲ برابر سریع‌تر).
- مدل DeepSeek-70B: زمان بارگذاری از ۱۳۹۹ ثانیه به ۱۵۰ ثانیه رسید (۹.۳ برابر سریع‌تر).
این مقایسه نشان می‌دهد که عملکرد خواندن تصادفی رسانه ذخیره‌سازی و سادگی مسیر پروتکل، تأثیر بسزایی بر حجم کارهای مبتنی بر خواندن، مانند بارگذاری مدل، دارد. این جهش عملکردی مدیون پروتکل NVMe over Fabrics (NVMe-oF) است. بر اساس استاندارد RFC 5040، این پروتکل مجموعه دستورات NVMe را به لایه انتقال شبکه گسترش می‌دهد. NVMe-oF از RDMA (دسترسی مستقیم به حافظه از راه دور) استفاده می‌کند تا اجازه دهد داده‌ها مستقیماً بین کارت‌های رابط شبکه و حافظه جابه‌جا شوند. این مکانیسم پشته پروتکل شبکه سیستم‌عامل را دور می‌زند و در نتیجه درگیری CPU و تأخیر انتقال را کاهش می‌دهد.
در مقابل، انتقال سنتی TCP طبق استاندارد RFC 9293، نیازمند کپی‌های متعدد داده و مدیریت وقفه‌ها (Interrupt Handling) از طریق پشته پروتکل هسته (Kernel) است. طبق مشخصات معنایی انتقال TCP در RFC 9293، این پروتکل برای انتقال جریان بایت‌های قابل اعتماد طراحی شده است و به‌طور خاص برای سناریوهای دسترسی به ذخیره‌ساز با تأخیر کم بهینه نشده است.
علاوه بر بارگذاری اولیه، عملکرد استنتاج (Inference) — یعنی همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند — به نحوه مدیریت KV Cache بستگی دارد. KV Cache داده‌های حیاتی هستند که در طول استنتاج مدل‌های زبانی بزرگ (LLM) به‌صورت پویا با هر درخواست رشد می‌کنند. از آنجایی که این داده‌ها دارای «موضعیتی» (Locality) واضح هستند — به این معنا که تولید توکن‌های بعدی برای یک توالی مشابه، نیازمند خواندن مکرر حالت‌های کلید-مقدار توکن‌های قبلی است — این بخش کاندیدای اصلی برای بهینه‌سازی است.
Mingxin استراتژی لایه‌بندی حافظه (Cache Tiering) را پیاده کرد تا داده‌های «داغ» را در نزدیک‌ترین فاصله به GPU (مانند دیسک‌های محلی پرسرعت) و داده‌های «سرد» را در استخر ذخیره‌سازی راه دور نگه دارد. آزمایش روی پلتفرم ۸-GPU مدل AMD Instinct MI308X با مدل Qwen3-Coder-480B-FP8 (یک معماری MoE با حدود ۴۵۰ گیگابایت وزن) نتایج زیر را داشت:
- توان عملیاتی (Throughput): بسته به سطح هم‌زمانی، ۲۹٪ تا ۴۰٪ بهبود یافت. به‌طور دقیق‌تر، در سطح هم‌زمانی ۸ (حد پایین) بهبود ۲۹٪، در سطح هم‌زمانی ۱۶ (حد بالا) بهبود ۴۰٪ و در سطح کامل ماشین TP4×2 بهبود ۳۵٪ تا ۳۶٪ مشاهده شد.
- زمان تا نخستین توکن (TTFT): در پیکربندی 480B·TP8 با سه سطح هم‌زمانی، TTFT از بازه ۱۰.۱۷ تا ۳۵.۷۳ ثانیه به ۷.۵۳ تا ۲۶.۳۵ ثانیه کاهش یافت که نشان‌دهنده کاهش ۲۶٪ تا ۳۲٪ است.
همچنین تست‌های مشترک با LMCache نشان داد که یک وصله (Patch) برای خواندن موازی می‌تواند TTFT را در سناریوهای خواندن سرد از دیسک تا ۴.۱ برابر بهبود بخشد. در این تست‌ها، با هم‌زمانی تک-GPU برابر با ۱۶ و خواندن سرد از دیسک، TTFT از ۳۷.۹۷ ثانیه به ۹.۳۰ ثانیه سقوط کرد، در حالی که پهنای باند از ۰.۹۸ گیگابایت بر ثانیه به ۵.۲۳ گیگابایت بر ثانیه جهش کرد. این موضوع نشان می‌دهد که بهینه‌سازی کارایی خواندن در لایه حافظه پنهان هنوز فضای بهبود در مقیاس مرتبه بزرگی (Order-of-magnitude) دارد.
این بهینه‌سازی‌ها یک راهکار واحد برای همه نیستند و استقرار واقعی نیازمند ترکیب آن‌ها بر اساس ویژگی‌های حجم کاری است. Mingxin توصیه می‌کند مسیر انتخاب را بر اساس نوع کاربست مشخص کنید:
- NVMe-oF: بهترین گزینه برای سناریوهای خواندن/نوشتن متوالی فایل‌های حجیم، مانند بارگذاری مدل‌ها یا ذخیره نقاط بازرسی (Checkpoints).
- لایه‌بندی حافظه (Cache Tiering): ضروری برای کارهایی با دسترسی شدید به KV-access مانند استنتاج با متن‌های طولانی (Long-context) و گفتگوهای چند مرحله‌ای.
- RDMA: انتخاب پروتکل شبکه زیربنایی که سقف عملکرد را برای هر دو مورد ذخیره‌سازی و حافظه پنهان تعیین می‌کند.
انتخاب راهکار نیازمند شفاف‌سازی محدودیت‌هاست. طبق صفحه طبقه‌بندی رسمی خانواده‌های نمونه GPU در Alibaba Cloud، خانواده‌های مختلف به‌طور صریح برای سناریوهای آموزش AI، محاسبات سریع (HPC) و رندرینگ گرافیکی دسته‌بندی شده‌اند. ارائه‌دهندگان اجاره محاسباتی باید ابتدا الزامات SLA حجم کاری خود (مانند حد بالای TTFT)، طول متن (Context Length) و الگوهای هم‌زمانی را پیش از انتخاب راهکار تعیین کنند.
برای تأیید این دستاوردها، Mingxin یک فرآیند تست مشترک مبتنی بر گیت (Gate-based) تقریباً ۱۰ هفته‌ای را به کار می‌گیرد. این مسیر از پذیرش اولیه و خط پایه تک-نود شروع شده و به «گیت اصلی» می‌رسد. گیت اصلی مستلزم کاهش TTFT حداقل ۲۵٪ و بهبود توان عملیاتی در بازه اندازه‌گیری شده ۲۹٪ تا ۴۰٪ است. عدم دستیابی به این آستانه‌ها باعث توقف فوری (Stop-loss) می‌شود و از داده‌های تست بازتولیدپذیر برای جلوگیری از سوگیری‌های ناشی از تخمین‌های تجربی استفاده می‌گردد.
این تغییر تمرکز از قدرت پردازش خام به سمت کارایی جابه‌جایی داده‌ها، معیار زیرساخت‌های AI را تغییر می‌دهد. برای کاربر، این به معنای هزینه کل مالکیت (TCO) کمتر و زمان پاسخگویی سریع‌تر برای کاربران نهایی است. صنعت در حال حرکت از افزودن ساده GPUهای بیشتر به سمت بهینه‌سازی کل مسیر داده است. شرکت‌هایی که محاسبات را اجاره می‌کنند باید اکنون SLAهای ذخیره‌سازی و الزامات طول متن خود را بازرسی کنند. مرز بحرانی بعدی احتمالاً تنظیم پویا و در لحظه (Real-time) این سیاست‌های جایگذاری با تکامل معماری‌های مدل خواهد بود.
گام بعدی شما
- اگر از GPUهای ابری استفاده می‌کنید، توافق‌نامه سطح خدمات (SLA) ذخیره‌ساز خود را بررسی کنید تا مطمئن شوید گلوگاه شما پردازنده نیست، بلکه I/O است.
- برای مدل‌های با پارامتر بالا (بالای ۷۰ میلیارد)، استقرار RDMA را در اولویت زیرساخت قرار دهید.
- در استقرار مدل‌های MoE، لایه‌بندی حافظه را برای کاهش TTFT در درخواست‌های تکراری پیاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو