تصور کنید گلوگاه اصلی در اجرای مدلهای زبانی کوچک، نه قدرت پردازشی خام، بلکه کارایی مدیریت حافظه VRAM باشد. بنچمارکهای منتشر شده در ۸ سپتامبر ۲۰۲۶ این فرضیه را از طریق معرفی Mingxin FX100 تأیید میکنند؛ این سیستم نشان میدهد که بهینهسازی دسترسی به حافظه از طریق لایهبندی KV Cache (حافظه موقت کلید-مقدار) میتواند توان عملیاتی (Throughput) را تا ۴۰٪ افزایش دهد.
بسیاری از توسعهدهندگان به اشتباه تصور میکنند که افزودن قدرت پردازشی بیشتر، مشکل تأخیر (Latency) را حل میکند. اما در مدلهای کوچک، نسبت دسترسی به حافظه نسبت به محاسبات بسیار بالاتر از مدلهای غولپیکر است. با افزایش طول متن (Context Length)، حجم KV Cache بهصورت خطی رشد میکند و در نتیجه، جابهجایی دادهها بین حافظه و پردازنده به عامل اصلی کندی و فشار بر عملکرد تبدیل میشود. این چالشها در واقع ادامه بحثهای فنی ما پیرامون راهکارهای کاهش تأخیر از طریق رمزگشایی گمانهزنانه و بهینهسازی حافظه KV است که پیشتر بررسی کرده بودیم.
چرا حافظه گلوگاه است، نه محاسبات؟
محاسبات هسته در مکانیزم توجه (Attention) شامل عملیات ماتریسی است. با این حال، گلوگاه واقعی در خواندن و نوشتنهای مکرر در KV Cache نهفته است. طبق مقاله FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness، محاسبات توجه توسط پهنای باند حافظه HBM (حافظه پهنایباند بالا) محدود میشود، نه توسط قدرت پردازشی. دستاوردهای حاصل از بهینهسازیهای آگاه از ورودی/خروجی (IO-aware) دقیقاً از همین محدودیت نشأت میگیرد.
مدلهای کوچک پارامترهای کمتر و محاسبات هر مرحله (per-forward compute) پایینتری دارند. با این حال، هنگام تولید توالیهای طولانی، KV Cache بهصورت خطی با طول متن رشد میکند. این امر باعث میشود دسترسی به حافظه سهم بسیار بزرگتری از کل فرآیند را به خود اختصاص دهد. هرچه مدل کوچکتر باشد، این گلوگاه دسترسی به حافظه مشهودتر و شدیدتر میشود.
این واقعیت دو پیامد حیاتی دارد: اول اینکه صرفاً افزودن قدرت پردازشی نمیتواند مشکل تأخیر را حل کند. دوم اینکه روش مدیریت KV Cache — بهویژه صفحهبندی (Paging)، بازاستفاده (Reuse) و لایهبندی (Tiering) — مستقیماً کارایی دسترسی به حافظه را تعیین میکند.
با تکیه بر پوششهای قبلی ما درباره نحوه استقرار عاملهای هوش مصنوعی توسط کسبوکارهای کوچک برای اتوماسیون کارهای اداری، چالش فنی اکنون به مقیاسبندی این عاملها تغییر یافته است. محیطهایی با همزمانی (Concurrency) بالا اغلب از تکهتکه شدن VRAM رنج میبرند. بر اساس مقاله Efficient Memory Management for Large Language Model Serving with PagedAttention، انگیزه اصلی برای مدیریت صفحهبندی شدهی KV Cache دقیقاً رسیدگی به تکهتکه شدن و اتلاف VRAM است؛ اتلافی که با افزایش تعداد درخواستهای همزمان تشدید میشود. در همین راستا، ابزارهایی مانند اولاما با معرفی حافظه متاداده تلاش کردهاند تا تأخیر استنتاج در محیطهای محلی را کاهش دهند.
سازوکار لایهبندی KV Cache
لایهبندی KV Cache با جداسازی دادههای «داغ» (Hot) و «سرد» (Cold) عمل میکند. دادههای داغ در VRAM پرسرعت باقی میمانند، در حالی که دادههای سرد به حافظههای ذخیرهسازی نزدیک به حافظه (Near-memory storage) منتقل (Offload) میشوند. این روش مانع از اتلاف VRAM برای دادههای غیرفعال میشود و در عین حال از تأخیر شدید خواندن از دیسکهای استاندارد جلوگیری میکند.
به نقل از معماری توزیعشده Mooncake، این رویکرد از طریق بازاستفاده از حافظه پیشوند (Prefix-cache reuse) و استخر KV بین گرهها (Cross-node KV pooling)، محاسبات تکراری را کاهش میدهد. این یک انتخاب طراحی معماری است و به سختافزار خاصی وابسته نیست.
دستاوردهای اندازهگیری شده
آزمایشهای انجام شده روی پلتفرم AMD MI308X با استفاده از مدل Qwen3-Coder-480B-FP8 (که پلتفرم اصلی تست برای گزارشهای R1 تا R4 بود) بهبودهای قابل توجهی را نشان داد. دادههای اندازهگیری شده از Mingxin FX100 در یک پیکربندی استقرار تولیدی 480B، مراجع زیر را ارائه میدهد:
- توان عملیاتی (همزمانی ۸): توان عملیاتی طبق اندازهگیریهای گزارشهای R2 و R3، ۲۹٪ (حد پایین) افزایش یافت.
- توان عملیاتی (همزمانی ۱۶): در نقطه بهینه عملیاتی، این افزایش به ۴۰٪ (حد بالا) رسید (گزارشهای R2 و R3).
- عملکرد در مقیاس کامل: در یک پیکربندی ماشین کامل TP4×2، توان عملیاتی ۳۵ تا ۳۶ درصد بهبود یافت (اندازهگیری شده در گزارشهای R2 و R3).
- تأخیر: زمان تا نخستین توکن (p50 TTFT) در سه سطح همزمانی در مدل 480B·TP8، از بازه ۱۰.۱۷ تا ۳۵.۷۳ ثانیه به ۷.۵۳ تا ۲۶.۳۵ ثانیه کاهش یافت. این یک کاهش ۲۶ تا ۳۲ درصدی است (اندازهگیری شده در گزارش R2).
حذف محاسبات تکراری
یکی از شدیدترین ضربات به عملکرد زمانی رخ میدهد که سیستم مجبور است یک پیشوند را دوباره محاسبه کند، زیرا KV Cache از VRAM حذف (Evict) شده و نمیتوان آن را سریعاً بازخوانی کرد. این بازمحاسبه (Recomputation)، زمانبرترین مسیر در چرخه استنتاج است.
در یک مقایسه مستقیم بدون بازمحاسبه در حافظه خارجی، TTFT p50 برای ۱۶ درخواست همزمان در حالت پایه (Baseline) ۱۴۹.۵ ثانیه اندازهگیری شد. Mingxin FX100 این مقدار را به ۱۱.۸۵ ثانیه کاهش داد. توان عملیاتی نیز از ۴.۱ به ۷۴.۹ توکن بر ثانیه جهش کرد (اندازهگیری شده در گزارش R2). این نشاندهنده یک شتاب بین ۸.۶ تا ۲۰ برابر است و ثابت میکند توانایی بازخوانی سریع دادههای حذفشده، بسیار حیاتیتر از مقدار خام FLOPS است.
بهینهسازیهای سطح نرمافزار مانند RadixAttention در SGLang این دستاوردها را بیشتر تقویت میکنند. با استفاده از بازاستفاده از درخت پیشوند (Prefix-tree reuse)، سیستم نرخ موفقیت (Hit rate) را در گفتگوهای چندمرحلهای و سناریوهای پیشوند مشترک افزایش میدهد. این بازاستفاده در سطح نرمافزار و بازخوانی سریع در سطح سختافزار، مکمل یکدیگر هستند. اگر مدلهای کوچک در سناریوهای متنی طولانی و گفتگوهای چندمرحلهای مستقر شوند، این افزایش نرخ موفقیت، شتاب سختافزاری را بیشتر تقویت میکند.
معیارهای پیادهسازی
هر استقراری از این معماری سود نمیبرد. طبق نتایج MLPerf Inference: Datacenter Benchmark Suite Results، مقایسههای عمومی باید بر اساس تستهای استاندارد تحت دقت (Precision) ثابت و محدودیتهای تأخیر باشد؛ برونیابی عددی بین پلتفرمهای مختلف فاقد مبنای علمی است. تصمیمگیرندگان باید سه عامل خاص را ارزیابی کنند:
- زمینه و همزمانی: لایهبندی برای متون طولانی (۳۲ هزار توکن و بیشتر) و همزمانی بالا بیشترین اثربخشی را دارد. این سناریوها فشار قابل توجهی به ظرفیت KV Cache وارد میکنند. در مقابل، وظایفی با متن کوتاه و همزمانی پایین، بهبودهای محدودی را تجربه میکنند.
- محدودیتهای SLA: اگر پروژهای الزامات سختگیرانهای برای TTFT دارد، لایهبندی «فضای مانور همزمانی» (Concurrency headroom) مورد نیاز برای رسیدن به آن اهداف را کاهش میدهد. گیتهای اصلی G3 در Mingxin، استانداردهای اندازهگیری شدهی کاهش TTFT ≥۲۵٪ و افزایش توان عملیاتی ۲۹ تا ۴۰٪ را تعیین کردهاند.
- مسیر ذخیرهسازی: سازگاری با NVIDIA GPUDirect Storage یا ذخیرهسازهای پشتیبانیکننده از RDMA ضروری است. طبق مستندات NVIDIA GPUDirect Storage، این فناوری با دور زدن بافر CPU (Bounce buffer)، مسیر دادهها را کوتاه میکند. سازگاری بین پشتههای ذخیرهسازی و شبکه باید حتماً تأیید شود.
انرژی و کارایی
کاهش تأخیر مستقیماً مصرف انرژی را کاهش میدهد. وقتی فضای مانور همزمانی مورد نیاز برای رسیدن به همان SLA کاهش یابد، ساعتهای GPU مصرفی برای هر درخواست نیز کاهش مییابد. این یک تفسیر مکانیکی بر اساس مقادیر اندازهگیری شده است، نه یک برونیابی به ارقام خاص انرژی.
در حالی که پلتفرم CMX شرکت NVIDIA (که به عنوان یک لایه ذخیرهسازی متن بومی AI تعریف شده) ادعای افزایش تا ۵ برابری توان عملیاتی و ۵ برابری کارایی انرژی نسبت به ذخیرهسازی سنتی را دارد، اینها ارقام گزارش شده توسط فروشنده هستند. این اعداد به عنوان یک مرجع برای جهتگیری صنعت عمل میکنند اما بنچمارکهای شخص ثالث بازتولیدپذیر نیستند.
جوهر بهینهسازی انرژی، کاهش محاسبات تلفشده و زمان انتظار است. هرچه نرخ موفقیت KV Cache بالاتر و بازخوانی سریعتر باشد، انرژی تلفشده به ازای هر توکن کمتر خواهد بود.
این تغییر تمرکز از طراحی «محاسبهمحور» به «حافظهمحور»، نحوه بنچمارک کردن مدلهای کوچک را تغییر میدهد. این امر نشان میدهد که جهش بعدی در عملکرد SLMها نه از تنظیم پارامترها، بلکه از ارکستراسیون ذخیرهسازی حاصل خواهد شد.
برای اعتبارسنجی این مرزها، Mingxin حدود ۱۰ هفته تست مشترک مبتنی بر گیت (از پذیرش ورود G1 تا پایداری ۷۲ ساعته G4) را ارائه میدهد، که در صورت عدم دستیابی به اهداف، دارای مکانیسم توقف ضرر (Stop-loss) است تا این افزایشهای توان عملیاتی تحت بارهای کاری واقعی تولید را اندازهگیری کند.
گام بعدی شما
- اگر از مدلهای کوچک برای پردازش متون طولانی (Long-context) استفاده میکنید، استراتژی مدیریت KV Cache را در اولویت قرار دهید.
- سازگاری سختافزار خود را با پروتکلهای GPUDirect Storage بررسی کنید تا گلوگاه CPU را حذف کنید.
- در بنچمارکهای خود، بهجای تمرکز بر FLOPS، روی نرخ بازخوانی دادههای evicted تمرکز کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو