کش KV برای ایجنت‌های کدنویسی: کش خود vLLM کافیه یا LMCache لازمه؟
هوش مصنوعیخلاصهٔ کامل‌تر
تو این مقاله اومده که چرا ایجنت‌های کدنویسی هرچی جلسه‌شون طولانی‌تر میشه کندتر جواب می‌دن. دلیلش اینه که مدل تو هر نوبت باید کل مکالمه تا اون لحظه رو دوباره پردازش کنه. راه‌حلش KV cache هست، یعنی ذخیرهٔ تنسورهای key و value که مدل موقع خوندن پرامپت می‌سازه، تا متنی که قبلاً دیده رو دوباره نخونه. تو یه جلسهٔ ۳۰ نوبتی بدون کش، بازخوانی تو نوبت آخر به حدود ۱۱۵ هزار توکن رسید و کل جلسه بیشتر از ۲ میلیون توکن شد. با کش، هیچ نوبتی بیشتر از حدود ۱۰ هزار توکن نخوند.
vLLM (سرور متن‌بازی که خیلی‌ها برای اجرای مدل‌های زبانی ازش استفاده می‌کنن) به‌صورت پیش‌فرض prefix caching داره، یعنی اگه پرامپت جدید با همون متنی شروع بشه که قبلاً کش شده، نتیجه رو دوباره استفاده می‌کنه. این کش تو حافظهٔ GPU و داخل خود پروسهٔ vLLM نگه داشته میشه. یه حالت CPU offload هم داره که وقتی GPU پر شد، کش رو می‌ریزه تو RAM سیستم. تو تست، هر دو حالت زمان پاسخ رو از حدود ۱.۳۵ ثانیه به ۱۱۲ تا ۱۲۲ میلی‌ثانیه رسوندن.
ولی وقتی حجم کار از ظرفیت GPU بیشتر شد (۴۸ سند بزرگ)، نرخ hit کش GPU به صفر رسید و عملاً مثل حالت بدون کش شد. روشن کردن CPU offload نرخ hit رو به بالای ۹۹ درصد برگردوند و تأخیر شد حدود ۱۶۴ میلی‌ثانیه. LMCache یه لایهٔ کش جداست که بیرون از vLLM، تو یه سرور مستقل اجرا میشه و می‌تونه از RAM و حتی NVMe استفاده کنه. تو حالت عادی تقریباً هم‌سرعت CPU offload بود: ۱۴۰ در برابر ۱۶۴ میلی‌ثانیه.
فرق اصلی بعد از ری‌استارت معلوم میشه. کش خود vLLM با ری‌استارت کامل پاک میشه و تأخیر برمی‌گرده به ۱.۳۵ ثانیه، ولی LMCache بعد از وصل شدن دوباره با نرخ hit حدود ۹۹.۹ درصد همون ۱۴۱ میلی‌ثانیه جواب داد. البته هزینه هم داره: یه بار LMCache حدود ۸۹ گیگابایت از حافظهٔ GPU پروسهٔ قبلی رو نگه داشت و vLLM جدید بالا نیومد. زمان انتظار برای آزاد شدن این حافظه حداقل ۳۰ ثانیه‌ست و پشتیبانیش از مدل‌های جدیدتر و معماری‌های hybrid هم یکدست نبود.
بیشترین سود مال ایجنت‌هاست. تو تست با جلسه‌های واقعی کدنویسی، انتظار یه ایجنت تو نوبت‌های آخر از حدود ۱۰۴ ثانیه به ۲.۱ ثانیه رسید. با هشت ایجنت روی یه GPU، خروجی کل از حدود ۸ نوبت در دقیقه به نزدیک ۶۰ رسید، یعنی هر ایجنت از یه نوبت به حدود هفت نوبت در دقیقه. نویسنده یه نکته هم می‌گه: درخواستی که کش داره، اگه کنار یه درخواست بزرگ بدون کش batch بشه، باز ممکنه معطل بمونه، چون کش زمان‌بندی GPU رو دور نمی‌زنه.
توصیهٔ نهایی مقاله اینه که prefix cache همیشه روشن بمونه، اگه کش از GPU بزرگ‌تر شد CPU offload رو اضافه کنی، و فقط وقتی سراغ LMCache بری که کش باید بعد از ری‌استارت زنده بمونه یا حجمش از RAM هم بیشتر میشه. کش فقط سرعت رو عوض می‌کنه و روی کیفیت جواب مدل اثری نداره.
نکات کلیدی:
- بدون کش، یه جلسهٔ ۳۰ نوبتی بیشتر از ۲ میلیون توکن بازخوانی داشت؛ با کش، حدود ۱۴ برابر کمتر.
- prefix cache تو vLLM پیش‌فرض روشنه و تأخیر رو از ۱.۳۵ ثانیه به حدود ۱۲۰ میلی‌ثانیه رسوند.
- وقتی کش از GPU بزرگ‌تر بشه، نرخ hit کش GPU به صفر می‌رسه و CPU offload اونو به بالای ۹۹ درصد برمی‌گردونه.
- LMCache بعد از ری‌استارت vLLM کشش رو نگه می‌داره، ولی ری‌استارت باهاش حدود ۲۰ تا ۳۰ ثانیه کندتره.
- با هشت ایجنت روی یه GPU، کش تعداد نوبت‌ها در دقیقه رو حدود ۵.۶ تا ۷.۵ برابر کرد.
