معماری پروداکشن vLLM: تخلیه کش KV و مسیریابی آگاه از کش

هنگام استقرار مدل‌های بزرگ زبانی در محیط عملیاتی، با افزایش همزمانی درخواست‌ها حافظه‌ی بسیار گران‌قیمت HBM به سقف 100% می‌رسد. در این وضعیت، کارت گرافیک دچار رخدادهای پیش‌دستی (Preemption) می‌شود؛ بدین معنا که بخشی از زمینه‌های متنی پاک شده و سیستم مجبور می‌شود پرامپت‌های چند هزار توکنی را بارها و بارها از نو محاسبه کند. این معضل توان پردازشی مفید (Goodput) را کاهش داده و هزینه محاسباتی را به‌شدت بالا می‌برد.

افزایش تعداد GPU برای جبران کمبود حافظه راه‌حلی خطی، بسیار پرهزینه و برای اغلب زیرساخت‌ها ناممکن است. با این حال، رم سیستم (CPU DRAM) ظرفیت فراوان و قیمت بسیار پایین‌تری دارد. اتصال‌دهنده‌های مدرن تخلیه‌ی کش کلید-مقدار (KV Cache Offloading) مانند LMCache در vLLM امکان می‌دهند داده‌های پردازش‌شده را بدون ایجاد گلوگاه به حافظه سیستم منتقل کرده و از محاسبه‌ی مجدد پیشوندها میان موتورهای مختلف جلوگیری کنید.

یک استک سرویس‌دهی در محیط عملیاتی (پروداکشن)، مسیریاب، موتورها و لایه‌ی پایش‌پذیری را در قالب یک دپلویمنت Kubernetes سرهم می‌کند — و به کش کلید-مقدار (KV cache) به چشم منبعی نگاه می‌کند که می‌تواند از GPU خارج شود. تخلیه‌ی کش کلید-مقدار این کش را از حافظه‌ی GPU بیرون می‌کشد و آن را میان کوئری‌ها و موتورهای مختلف بازاستفاده می‌کند (ابتدا در رم CPU، سپس روی دیسک/Ceph). استک عملیاتی vLLM دپلویمنت مرجع به حساب می‌آید و LMCache لایه‌ی تخلیه است. اتصال‌دهنده‌ی تخلیه‌ی کش کلید-مقدار در vLLM 0.11.0 (ژانویه‌ی 2026) این سازوکار را از طریق API اتصال‌دهنده (v0.9.0+) ناهمگام و ماژولار می‌کند. مسیر تخلیه معمولاً از مسیر پردازش درخواست پنهان می‌ماند، هرچند عدم اصابت به کش (Cache miss) و ارتقا می‌توانند تاخیر سرتاسری را افزایش دهند. LMCache حتی بدون پیشوندهای مشترک هم ارزشمند است — وقتی اسلات‌های کش کلید-مقدار یک GPU پر می‌شود، درخواست‌های پیش‌دستانه‌شده (Preempted) می‌توانند به جای محاسبه‌ی دوباره‌ی پیش‌پرکنی (Prefill)، از CPU بازیابی شوند. بنچمارک‌های منتشرشده روی 16 کارت H100 (با حافظه‌ی 80GB HBM) در 4 ماشین a3-highgpu-4g نشان می‌دهد: وقتی حجم کش کلید-مقدار از ظرفیت HBM فراتر می‌رود، هم تخلیه روی پردازنده‌ی اصلی به‌شکل توکار و هم LMCache به‌طور چشمگیری نرخ پردازش را بهبود می‌دهند؛ در حجم‌های پایین کش، همه‌ی پیکربندی‌ها با اندکی سربار، عملکردی نزدیک به خط مبنا دارند.

اهداف یادگیری

• ترسیم لایه‌های استک عملیاتی vLLM: مسیریاب، موتورها، تخلیه‌ی کش کلید-مقدار و پایش‌پذیری.
• توضیح API اتصال‌دهنده‌ی تخلیه‌ی کش کلید-مقدار (v0.9.0+) و چگونگی پنهان‌سازی تاخیر تخلیه در مسیر ناهمگام نسخه‌ی 0.11.0.
• سنجش دقیق شرایطی که رم پردازنده‌ی LMCache بازدهی دارد (وقتی کش > HBM) در برابر شرایطی که سربار اضافه می‌کند (وقتی کش آن‌قدر کوچک است که در HBM جا می‌شود).
• انتخاب آگاهانه بین تخلیه روی پردازنده‌ی اصلی به‌شکل توکار در vLLM و اتصال‌دهنده‌ی LMCache با توجه به محدودیت‌های دپلویمنت.

صورت مسئله

در سیستم سرویس‌دهی vLLM شما، با بالا رفتن همزمانی (Concurrency)، مصرف HBM کارت‌های گرافیک به 100% می‌رسد و رخدادهای پیش‌دستانه پیاپی ثبت می‌شوند. درخواست‌ها بیرون انداخته می‌شوند، دوباره در صف قرار می‌گیرند و شما مجبور می‌شوید یک پرامپت 2K توکنی یکسان را در طول یک دقیقه چهار بار پیش‌پرکنی کنید. توان محاسباتی GPU صرف پیش‌پرکنی‌های بیهوده می‌شود و نرخ پردازش مفید (Goodput) بسیار پایین‌تر از نرخ پردازش خام قرار می‌گیرد.

اضافه کردن کارت گرافیک بیشتر، هزینه‌ی خطی دارد. افزودن به ظرفیت HBM هم ناممکن است. اما رم CPU ارزان است — یک سوکت به تنهایی بیش از 512GB رم دارد؛ گرچه تاخیر آن چند مرتبه‌ی بزرگی از HBM بدتر است، ولی برای یک کش کلید-مقدار «موقتاً آماده» کاملاً کفایت می‌کند.

ابزار LMCache کش کلید-مقدار را به رم CPU منتقل می‌کند تا درخواست‌های پیش‌دستانه‌شده سریع بازیابی شوند و پیشوندهای تکراری میان موتورهای مختلف به اشتراک گذاشته شوند، بدون اینکه هر موتور مجبور به پیش‌پرکنی دوباره باشد.

مفاهیم پایه

استک عملیاتی vLLM

مخزن github.com/vllm-project/production-stack دپلویمنت مرجع مبتنی بر Kubernetes است:

• مسیریاب (Router) — آگاه از کش (فاز 17 · 11). رویدادهای کش کلید-مقدار را مصرف می‌کند.
• موتورها (Engines) — ورکر‌های vLLM؛ یکی به ازای هر GPU یا به ازای هر گروه موازی‌سازی تنسور/خط‌لوله‌ای (TP/PP).
• تخلیه‌ی کش کلید-مقدار — دپلویمنت LMCache یا اتصال‌دهنده‌ی توکار.
• پایش‌پذیری — جمع‌آوری متریک‌ها با Prometheus، داشبوردهای Grafana، ردگیری محاسبات با OTel.
• کنترل پلین (Control plane) — شناسایی سرویس، پیکربندی، به‌روزرسانی‌های پیوسته (Rolling updates).

این مجموعه در قالب Helm chart به همراه یک Operator عرضه می‌شود.

اتصال‌دهنده‌ی تخلیه‌ی کش کلید-مقدار (v0.9.0+)

نسخه‌ی vLLM 0.9.0 یک API اتصال‌دهنده برای بک‌اندهای ماژولار کش کلید-مقدار معرفی کرد. موتور شما بلوک‌ها را به اتصال‌دهنده منتقل می‌کند؛ اتصال‌دهنده آن‌ها را ذخیره می‌سازد (در RAM، دیسک، فضای ذخیره‌سازی ابری یا LMCache). هر وقت درخواستی به بلوکی نیاز داشته باشد، اتصال‌دهنده دوباره آن را بارگذاری می‌کند.

نسخه‌ی vLLM 0.11.0 (ژانویه‌ی 2026) یک مسیر تخلیه‌ی ناهمگام اضافه کرده است — عملیات تخلیه می‌تواند در پس‌زمینه انجام شود تا در حالت معمول، موتور مسدود (Block) نشود. با این حال، تاخیر سرتاسری و نرخ پردازش همچنان به الگوی بار کاری، نرخ اصابت (Hit rate) کش کلید-مقدار و فشار کلی سیستم بستگی دارد؛ در یادداشت‌های خودِ vLLM اشاره شده که تخلیه با کرنل سفارشی ممکن است در نرخ‌های اصابت پایین به نرخ پردازش ضربه بزند و زمان‌بندی ناهمگام با دیکودینگ حدسی (Speculative Decoding) تداخل‌های شناخته‌شده‌ای دارد.

مقایسه‌ی تخلیه روی پردازنده‌ی اصلی به‌شکل توکار و LMCache

تخلیه روی پردازنده‌ی اصلی به‌شکل توکار در vLLM: محدود به همان موتور (Engine-local). بلوک‌های کش کلید-مقدار را در رمِ میزبان نگه می‌دارد. پیاده‌سازی سریع، بدون هیچ گام لغزش شبکه‌ای. امکان اشتراک‌گذاری بین چند موتور را ندارد.

اتصال‌دهنده‌ی LMCache: در مقیاس کلاستر. بلوک‌ها را در یک سرور مشترک LMCache (لایه‌ی رم CPU + Ceph/S3) ذخیره می‌کند. این بلوک‌ها برای تمام موتورها در دسترس هستند. بنچمارک‌های آن روی 16 کارت H100 منتشر شده است.

اگر تنها یک موتور زیر فشار کمبود HBM قرار دارد، گزینه‌ی توکار را انتخاب کنید. اگر چندین موتور پیشوندهای مشترک دارند (مثل معماری‌های RAG با پرامپت‌های سیستمی یکسان، یا سیستم‌های چندمستاجری با قالب‌های مشترک)، سراغ LMCache بروید.

رفتار در بنچمارک‌ها

آزمایش انجام‌شده روی 16 کارت H100 (با حافظه‌ی 80GB HBM) در 4 سرور a3-highgpu-4g نشان می‌دهد:

• ردپای پایین کش (پرامپت‌های کوتاه، همزمانی کم): تمام پیکربندی‌ها عملکردی مشابه خط مبنا دارند و LMCache حدود 3 تا 5 درصد سربار اضافه می‌کند.
• ردپای متوسط کش: LMCache با استفاده‌ی مجدد از پیشوندها میان موتورهای مختلف، عملکرد را ارتقا می‌دهد.
• فراتر رفتن حجم کش از ظرفیت HBM: هر دو روش تخلیه روی پردازنده‌ی اصلی به‌شکل توکار و LMCache نرخ پردازش را به شکل چشمگیری بالا می‌برند؛ سود LMCache به دلیل اشتراک‌گذاری بین موتورها بیشتر است.

چه زمانی LMCache تعیین‌کننده است؟

• سرویس‌دهی چندمستاجری (Multi-tenant) که پرامپت‌های سیستمی بین کاربران مشترک است.
• خطوط لوله‌ی RAG که تکه‌های اسناد در کوئری‌های متعدد تکرار می‌شوند.
• نسخه‌های فاین‌تیون‌شده‌ی سبک (LoRA) روی یک مدل پایه، که بازاستفاده از کش مدل پایه بارهای محاسباتی تکراری را حذف می‌کند.
• بارهای کاری با پیش‌دستی بالا: بازیابی کش از CPU بسیار ارزان‌تر از پیش‌پرکنی دوباره تمام می‌شود.

چه زمانی نباید آن را فعال کرد؟

• فشار پایین روی HBM — فقط سربار اضافه می‌کنید بدون اینکه سودی ببرید.
• زمینه‌های متنی کوتاه (کمتر از 1K توکن) — زمان انتقال از زمان پیش‌پرکنی دوباره بیشتر می‌شود.
• بارهای کاری تک‌مستاجری با یک پرامپت ثابت — هیچ بازاستفاده‌ای برای بهره‌برداری وجود ندارد.

هماهنگی با سرویس‌دهی تفکیک‌شده

ترکیب سرویس‌دهی تفکیک‌شده (فاز 17 · 17) با LMCache اثر هم‌افزایی دارد: انتقال‌های کش از استخر پیش‌پرکنی به استخر رمزگشایی (Decode) در صورت عدم استفاده در LMCache می‌نشینند؛ کوئری‌های بعدی مستقیماً از LMCache خوانده می‌شوند. مسیریاب آگاه از کش در فاز 17 · 11 هم می‌تواند ترافیک را به موتوری بفرستد که کش آن در حافظه‌ی محلی یا در حافظه‌ی مشترک LMCache تطابق دارد.

اعدادی که باید به خاطر بسپارید

• نسخه‌ی vLLM 0.9.0: ارائه‌ی رسمی API اتصال‌دهنده.
• نسخه‌ی vLLM 0.11.0 (ژانویه‌ی 2026): ارائه‌ی مسیر تخلیه‌ی ناهمگام؛ میزان اثرگذاری بر تاخیر سرتاسری به الگوی بار کاری، نرخ اصابت کش و فشار سیستم بستگی دارد (نه یک تضمین قطعی).
• بنچمارک 16 کارت H100: اثر مثبت LMCache زمانی آشکار می‌شود که حجم کش از ظرفیت HBM عبور کند.
• در فشارهای پایین HBM: ایجاد 3 تا 5 درصد سربار بدون هیچ دستاورد ملموس.

پیاده‌سازی و آزمایش

اسکریپت code/main.py یک بار کاری پر از پیش‌دستی را در دو حالتِ با و بدون LMCache شبیه‌سازی می‌کند. این کد تعداد پیش‌پرکنی‌های حذف‌شده، افزایش نرخ پردازش و نقطه‌ی سربه‌سر مصرف HBM را گزارش می‌دهد.

خروجی این درس

خروجی این درس سند outputs/skill-vllm-stack-decider.md است. این راهنما با دریافت مشخصات بار کاری و معماری دپلویمنت vLLM، بین گزینه‌های تخلیه روی پردازنده‌ی اصلی به‌شکل توکار، LMCache یا هیچ‌کدام تصمیم‌گیری می‌کند.

تمرین‌ها

1. اسکریپت code/main.py را اجرا کنید. LMCache در چه درصدی از مصرف HBM ارزش سرمایه‌گذاری پیدا می‌کند؟
2. یک مستاجر، پرامپت سیستمی 6K توکنی خود را در 200 کوئری در ساعت به اشتراک می‌گذارد. میزان صرفه‌جویی مورد انتظار با LMCache را به ازای هر مستاجر محاسبه کنید.
3. سرور LMCache یک نقطه‌ی تکی شکست (SPOF) به حساب می‌آید. استراتژی پایداری و دسترس‌پذیری بالا (HA) را برای آن طراحی کنید (استفاده از رپلیکاها، طرح پشتیبان به تخلیه‌ی توکار).
4. فرض کنید LMCache داده‌ها را روی دیسک‌های مکانیکی Ceph ذخیره می‌کند. برای یک کش 4K توکنی در مدل 70B با فرمت FP8 (حدود 500 مگابایت)، زمان خواندن چقدر است و چه نسبتی با زمان پیش‌پرکنی دوباره دارد؟
5. تحلیل کنید که آیا مسیر ناهمگام در vLLM 0.11.0 واقعاً «بدون هزینه» است یا خیر — این سربار کجا پنهان می‌شود؟

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• وبلاگ vLLM — اتصال‌دهنده‌ی تخلیه‌ی کش کلید-مقدار (ژانویه 2026)
• مخزن گیت‌هاب vLLM Production Stack — قالب‌های Helm و Operator.
• مقاله LMCache برای سرویس‌دهی مدل‌های زبانی در مقیاس سازمانی (arXiv:2510.09665)
• مخزن گیت‌هاب LMCache — پیاده‌سازی اتصال‌دهنده.
• یادداشت‌های انتشار vLLM 0.11.0 — جزئیات مسیر ناهمگام.