Phase 17: Infrastructure & Production

تولید خدمت استیک KV بارگذاری و راه اندازی حافظه کش

یک تولید که به راه اندازی یک کابل، موتورها و مشاهده پذیری در یک کاربری Kubernetes خدمت می کند و KV را به عنوان یک منبع که می تواند GPU را ترک کند، در نظر می گیرد. KV خارج کردن KV کش از حافظه GPU خارج می کند و آن را در میان سوالات و موتورها (CPU DRAM، سپس دیسک / Ceph) مجددا استفاده می کند. دسته تولید vLLM، انتشار مرجع است؛ LMCache، لایه تخلیه است. اتصال دهنده تخلیه vLLM 0.11.0 KV (جنوری 2026) این را غیرمسلق و قابل وصل از طریق API اتصال (v0.9.0+) می کند. مسیر تخلیه معمولا از مسیر درخواست پنهان می شود، اگرچه از دست دادن کش و تبلیغات می تواند تاخیر پایان به پایان را اضافه کند. LMCache حتی بدون پیشگویی های مشترک ارزشمند است هنگامی که GPU از سلاٹس KV تمام می شود، درخواست های پیشگیری شده را می توان از CPU به جای محاسبه مجدد prefill بازگرداند. شاخص های مرجع منتشر شده در 16x H100 (80GB HBM) در 4 a3-highgpu-4g: هنگامی که حافظه حافظه KV از HBM فراتر می رود، هم بارگذاری CPU بومی و هم LMCache به طور قابل توجهی تولید را بهبود می بخشد؛ در پایین KV، تمام پیکربندی ها با خط پایه با هزینه های کوچک مطابقت دارند.

Type: Learn

Languages: Python (stdlib, toy KV-spill simulator)

Prerequisites: Phase 17 · 04 (Serving Engine Internals), Phase 17 · 06 (SGLang/RadixAttention)

Time: ~60 minutes

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

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

مشکل

سرویس vLLM شما GPU ها را در 100٪ HBM با رویدادهای پیشگیری در هر زمان که هم زمان افزایش می یابد نشان می دهد. درخواست ها اخراج می شوند، رد می شوند و شما چهار بار در یک دقیقه از همان درخواست 2K-token دوباره پر می کنید. محاسبه GPU برای پر کردن پیش افزوده هزینه می شود؛ تولید خوب بسیار پایین تر از تولید خام است.

اضافه کردن GPU ها به صورت خطی هزینه دارد. اضافه کردن HBM های بیشتر امکان پذیر نیست. اما CPU DRAM ارزان است یک سوکت دارای 512 GB + در دستورات تاخیر بزرگتر از HBM است اما برای "حالی گرم" KV حافظه ی خوب است.

LMCache KV cache را به CPU DRAM استخراج می کند تا درخواست های پیش فرض سریع بازیابی شوند و پیش فرض های مکرر در سراسر موتورها بدون اینکه هر موتور دوباره پر شود، حافظه را به اشتراک می گذارند.

مفهوم

دسته تولید vLLM

github.com/vllm-project/production-stackاین است که استفاده از Kubernetes:

  • Router cache-aware (فاز 17 · 11) ، رویدادهای KV را مصرف می کند.
  • Engines کارکنان vLLM. یک نفر در هر GPU یا هر گروه TP/PP.
  • KV cache offload انتشار LMCache یا اتصال بومی.
  • Observability سکریپ پرومیتوس، داشبورد های گرافانا، ردیابی OTel
  • Control plane کشف سرویس، تنظیم، بروزرسانی های جاری

به عنوان کارگر نقشه Helm + ارسال شد

API اتصال KV (v0.9.0+)

vLLM 0.9.0 یک API اتصالگر برای پشتیبانهای cache KV قابل وصل را معرفی کرد. موتور شما بلوک ها را به اتصالگر خارج می کند؛ اتصالگر آنها را ذخیره می کند (RAM، دیسک، ذخیره اشیاء، LMCache). درخواست نیاز به یک بلوک دارد، اتصالگر آن را دوباره بار می زند.

vLLM 0.11.0 (جنوری 2026) یک مسیر تخلیه غیرمسلسل را اضافه می کند تخلیه می تواند در پس زمینه اتفاق بیفتد تا موتور در حالت عادی آن را مسدود نکند. تاخیر و تولید پایان تا پایان هنوز هم به شکل بار کاری، نرخ ضربه کش KV و فشار سیستم بستگی دارد؛ یادداشت های vLLM خود می گویند که بارگذاری هسته سفارشی می تواند در نرخ ضربه های پایین باعث کاهش تولید شود و برنامه ریزی async مشکلات تعامل با رمزگذاری حدس زده شده را دارد.

تخفیف CPU بومی در مقابل LMCache

Native vLLM CPU offload: محرکه محرکه. بلوک های KV را در رام میزبان ذخیره می کند. سریع برای پیاده سازی، صفر شبکه. موتورهای متقابل را عبور نمی کند.

LMCache connector: مقیاس کلستر. بلوک ها را در یک سرور LMCache مشترک (CPU DRAM + Ceph / S3 سطح) ذخیره می کند. بلوک ها برای هر موتور قابل دسترسی هستند. 16x H100 معیار منتشر شده است.

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

رفتار معیار

16x H100 (80 GB HBM) در 4 آزمون a3-highgpu-4g پخش شده است:

  • نقش کم KV (تغییر کوتاه، همزمان کم): تمام پیکربندی ها با خط پایه مطابقت دارند، LMCache شامل ~ 3-5% هزینه های عمومی می شود.
  • نقش متوسط: LMCache شروع به کمک به استفاده مجدد از پیشگام در موتور ها می کند.
  • KV HBM را فراتر می برد: بارگذاری CPU بومی و LMCache هر دو تولید را به طور قابل توجهی بهبود می بخشند؛ LMCache به دلیل اشتراک گذاری موتورهای مختلف، سود بیشتری می یابد.

وقتی LMCache مهم است

  • سرویس چند نفر که در آن پیام های سیستم بین مستاجران به اشتراک گذاشته می شود.
  • RAG که در آن قطعات سند در میان سوالات تکرار می شوند.
  • انواع تنظیم شده (LoRA) در همان پایه که استفاده مجدد KV مدل پایه کار اضافی را کاهش می دهد.
  • بار کاری سنگین پیشگیری: از CPU بازگردانید ارزان تر از دوباره پر کردن.

وقتی که فعال نشدن

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

ادغام با خدمت های تقسیم شده

مرحله 17 · 17 سرویس های تجزیه شده + ترکیبات LMCache: KV از مخزن پر کردن قبل به زمین مخزن در LMCache اگر استفاده نشده باشد منتقل می شود؛ سوالات بعدی از LMCache خارج می شوند. مرحله 17 · 11 روتر آگاه از کش می تواند به موتور که OR محلی LMCache با بخش کش مطابقت دارد، مسیر دهد.

شماره هایی که باید به یاد داشته باشی

  • vLLM 0.9.0: API اتصال ارسال شده
  • vLLM 0.11.0 (جنوری 2026): مسیر تخلیه غیرمسلسل؛ تاثیر تاخیر پایان به پایان بستگی به بار کاری، سرعت KV و فشار سیستم دارد (هیچ تضمینی مطلق نیست).
  • 16x H100 معیار: LMCache زمانی که اثر KV HBM را فراتر می برد کمک می کند.
  • فشار کوچک HBM: 3-5% هزینه های بالای بدون سود.

ازش استفاده کن

code/main.pyگزارش های پر کردن مجدد اجتناب شده، افزایش تولید و استفاده از HBM های شکست خورده.

-باده

این درس به ما کمک می کندoutputs/skill-vllm-stack-decider.mdبا توجه به شکل بار کاری و انتشار vLLM، تصمیم می گیرد که native vs LMCache vs neither.

تمرینات

  1. فرار کنcode/main.pyLMCache با چه استفاده از HBM شروع به پرداخت می کند؟
  2. یک مستاجر یک سیستم 6K-توکن را در 200 سوال/ساعت به اشتراک می گذارد.
  3. سرور LMCache یک نقطه شکست است. استراتژی HA را طراحی کنید (ردوب ها، بازگشت به بومی).
  4. LMCache به Ceph در دیسک چرخش ذخیره می کند. برای یک KV 4K-توکن در 70B FP8 (500 MB) ، زمان خواندن در مقابل پر کردن مجدد چقدر است؟
  5. استدلال کنید که آیا مسیر غیر هماهنگ vLLM 0.11.0 "آزاد" است کجا سرنشین پنهان شده است؟

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

TermWhat people sayWhat it actually means
Production-stack"the reference deployment"vLLM's Kubernetes Helm chart + operator
Connector API"KV backend interface"vLLM 0.9.0+ pluggable KV store interface
Native CPU offload"engine-local spill"Store KV in host RAM of same engine
LMCache"cluster KV cache"Cross-engine KV cache server on CPU DRAM + disk
0.11.0 async"non-blocking offload"Offload hidden behind engine stream
Preemption"evict to make room"KV cache shuffle when HBM full
Prefix reuse"same system prompt"Multiple queries share beginning; cache hit
Ceph tier"disk tier"Durable storage below DRAM in the cache hierarchy

خواندن بیشتر

This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.

Browse the complete course catalog or open this lesson on GitHub.