مسیریابی حافظه نهان KV: کاهش کار اضافی پیش‌پر کردن LLM

مسیریابی حافظه نهان KV زمانی اهمیت پیدا می‌کند که پیشوندهای تکراری درخواست‌ها در ترافیک LLM شما ظاهر شوند. اگر درخواست مناسب به نمونه مناسب برسد، موتور سرویس‌دهی می‌تواند از حالت توجه ذخیره‌شده استفاده کند و نیازی به محاسبه مجدد توکن‌های پیش‌پرکننده نداشته باشد.

این ممکن است جزئیات زیرساخت به نظر برسد، اما به سرعت به یک مسئله محصول تبدیل می‌شود. درخواست‌های طولانی سیستم، زمینه RAG، مثال‌های چند‌شات و تاریخچه چت چند‌مرحله‌ای می‌توانند کار پیش‌پرکننده را پرهزینه کنند. وقتی هر نمونه پیشوند مشابهی را دوباره محاسبه می‌کند، تیم‌ها هزینه تأخیر، زمان GPU و برنامه‌ریزی ظرفیت را پرداخت می‌کنند.

ShareAI به توسعه‌دهندگان یک API برای بیش از 150 مدل، دیدگاه بازار، مسیریابی و بازیابی خرابی ارائه می‌دهد. مسیریابی حافظه نهان KV یک لایه پایین‌تر، در زیرساخت سرویس‌دهی مدل قرار دارد. نکته مفید برای خوانندگان ShareAI ساده است: تصمیمات مسیریابی در هر لایه از پشته هوش مصنوعی اهمیت دارند، از انتخاب مدل تا اینکه کدام نمونه GPU یک درخواست تکراری را مدیریت کند.

چرا مسیریابی حافظه نهان KV اهمیت دارد

در زمان استنتاج LLM، مدل ابتدا درخواست ورودی را در مرحله پیش‌پرکننده پردازش می‌کند. این یک حافظه نهان کلید-مقدار، که معمولاً حافظه نهان KV نامیده می‌شود، ایجاد می‌کند تا توکن‌های تولید‌شده بعدی بتوانند به زمینه پردازش‌شده قبلی مراجعه کنند.

حافظه نهان پیشوند به موتورهای سرویس‌دهی اجازه می‌دهد که از آن حافظه نهان استفاده کنند وقتی درخواست بعدی همان ابتدای درخواست را به اشتراک می‌گذارد. مستندات حافظه نهان پیشوند خودکار vLLM این را به عنوان استفاده مجدد از حافظه نهان KV برای پیشوندهای مشترک توصیف می‌کند تا درخواست جدید بتواند محاسبات مربوط به بخش مشترک را نادیده بگیرد. حافظه نهان پیشوند SGLang از ایده مشابهی برای اشتراک حافظه نهان KV برای توالی‌های توکن مشترک استفاده می‌کند.

این به ویژه برای بارهای کاری که بسیاری از درخواست‌ها به یک شکل شروع می‌شوند اهمیت دارد: عوامل پشتیبانی با درخواست‌های بزرگ سیستم، برنامه‌های RAG که از بخش‌های مستندات تکراری استفاده می‌کنند، عوامل کدنویسی با دستورالعمل‌های مخزن، یا محصولات چت که تاریخچه مکالمه را در مراحل مختلف حمل می‌کنند.

جایی که Round-Robin شکست می‌خورد

حافظه نهان پیشوند در یک نمونه آسان‌تر است. همان فرآیند پیشوند تکراری را می‌بیند و می‌تواند از حافظه نهان خود استفاده کند اگر حافظه موجود باشد. مشکل زمانی ظاهر می‌شود که سرویس به صورت افقی مقیاس‌بندی شود.

با یک متعادل‌کننده بار استاندارد Round-Robin، درخواست اول ممکن است حافظه نهان را در نمونه A گرم کند، در حالی که درخواست دوم با همان پیشوند به نمونه B برسد. نمونه B آن حالت ذخیره‌شده را ندارد، بنابراین همان کار پیش‌پرکننده را دوباره محاسبه می‌کند. درخواست سوم ممکن است به نمونه C برود و دوباره از دست بدهد.

با افزایش تعداد نمونه‌ها، متعادل‌سازی بار ساده می‌تواند درخواست‌های مرتبط را در ماشین‌های بیشتری پخش کند. ناوگان سرویس‌دهی مدل ممکن است متعادل به نظر برسد، اما نرخ برخورد حافظه نهان پیشوند کاهش می‌یابد. این همان شکافی است که مسیریابی حافظه نهان KV تلاش می‌کند آن را پر کند.

سه سطح عملی مسیریابی

1. وابستگی جلسه

وابستگی جلسه ترافیک را از یک کاربر، فضای کاری، مستأجر یا مکالمه به همان نسخه هدایت می‌کند. این ساده‌ترین نقطه شروع برای چت چند نوبتی است زیرا درخواست‌های پیگیری اغلب زمینه قبلی را به اشتراک می‌گذارند.

معاوضه این است که هویت کاربر همیشه با شباهت درخواست یکسان نیست. دو کاربر ممکن است یک درخواست طولانی سیستم را به اشتراک بگذارند و همچنان به نسخه‌های مختلف هدایت شوند. وابستگی جلسه همچنین ممکن است زمانی که نسخه‌ها اضافه یا حذف می‌شوند مختل شود.

2. مسیریابی هش پیشوند

مسیریابی هش پیشوند از خود درخواست به عنوان کلید مسیریابی استفاده می‌کند. مسیریاب ابتدای پایدار درخواست را هش می‌کند و پیشوندهای مطابق را به همان نسخه ارسال می‌کند.

این روش زمانی بهتر عمل می‌کند که درخواست‌های سیستم تکراری، مثال‌های چند شات، یا زمینه بازیابی‌شده مشترک بیشتر از هویت کاربر اهمیت داشته باشند. بخش سخت انتخاب مرز پیشوند است. اگر هش شامل یک زمان‌بندی، شناسه درخواست، یا فیلد خاص کاربر باشد، کلید مسیریابی تکه‌تکه می‌شود و استفاده مجدد از کش از بین می‌رود.

3. مسیریابی آگاه از رویداد کش

پیشرفته‌ترین روش، ردیابی می‌کند که کدام بلوک‌های کش در کدام نسخه مقیم هستند، سپس هر درخواست را به نسخه‌ای هدایت می‌کند که بهترین همپوشانی کش را دارد در حالی که همچنان بار را در نظر می‌گیرد. پروژه مسیریاب llm-d یک انتخاب‌کننده نقطه پایانی را توصیف می‌کند که محلی بودن کش KV، بار فعلی و اولویت را هنگام انتخاب مقصد درخواست در نظر می‌گیرد.

این پیچیده‌تر است، اما برای ناوگان‌های با توان بالا که خطاهای کش اندازه‌گیری‌شده، گران و مکرر هستند، جهت درستی است.

زمان‌هایی که باید از آن صرف‌نظر کرد

مسیریابی کش KV به طور خودکار ارزش این پیچیدگی را ندارد. این روش زمانی ضعیف است که درخواست‌ها کوتاه، عمدتاً منحصربه‌فرد یا به صورت دسته‌ای با ساختار تکراری کم پردازش شوند.

خلاصه‌سازی اسناد، تولید خلاقانه، استخراج یک‌باره و بسیاری از کارهای دسته‌ای غیرهمزمان ممکن است پیشوندهای مشترک کافی برای توجیه مسیریابی آگاه از کش نداشته باشند. در این موارد، تعادل بار ساده‌تر ممکن است تمیزتر باشد.

آزمون عملی اندازه‌گیری است: نرخ برخورد کش، زمان تا اولین توکن، توان عملیاتی، عمق صف، فشار حافظه GPU، و هزینه به ازای هر وظیفه تکمیل‌شده. اگر مسیریابی آگاه به کش این اعداد را تغییر نمی‌دهد، ابتدا ساختار درخواست را اصلاح کنید.

چگونه این با ShareAI سازگار است

ShareAI یک بازار و API هوش مصنوعی است، نه متعادل‌کننده بار مدل‌سازی در داخل خوشه GPU شما. توسعه‌دهندگان از ShareAI برای دسترسی به مدل‌های متعدد از طریق یک API، مقایسه سیگنال‌های بازار، مسیریابی درخواست‌ها، مدیریت استفاده، و انتقال در صورت کاهش کیفیت مسیر استفاده می‌کنند.

این همچنان مسیریابی کش KV را مرتبط می‌کند. اگر شما پشته استنتاج خود را اجرا می‌کنید، به شما کمک می‌کند سوالات زیرساختی بهتری بپرسید. اگر از مدل‌های میزبانی‌شده استفاده می‌کنید، به شما کمک می‌کند ارزیابی کنید چرا دو مسیر با نام‌های مدل مشابه ممکن است تحت بارهای کاری واقعی رفتار متفاوتی داشته باشند.

برای سازندگان، این همچنین به قیمت‌گذاری مرتبط است. یک برنامه با درخواست‌های طولانی، زمینه RAG تکراری، یا حلقه‌های عامل می‌تواند استفاده بسیار نامنظم هوش مصنوعی ایجاد کند. ShareAI Builder به صاحبان برنامه اجازه می‌دهد ترافیک استنتاج هوش مصنوعی را از طریق ShareAI مسیریابی کنند، یک حاشیه یا هزینه اضافی تعیین کنند، مشتریان هزینه استفاده مسیریابی‌شده را به ShareAI پرداخت کنند، و پرداخت‌های ماهانه بر اساس استفاده تولیدشده دریافت کنند. خود برنامه خارج از ShareAI ساخته می‌شود.

برای انتخاب مدل و ارزیابی مسیر، با بازار مدل ShareAI. برای اصول پیاده‌سازی، از مرجع API ShareAI.

چک‌لیست مسیریابی کش KV

• محتوای پایدار درخواست را ابتدا قرار دهید: درخواست سیستم، قوانین ابزار، مثال‌ها، و زمینه تکراری.
• فیلدهای پویا را بعداً قرار دهید: زمان‌بندی‌ها، شناسه‌های درخواست، حقایق خاص کاربر، و دستورالعمل‌های یک‌باره.
• نرخ برخورد کش را قبل و بعد از تغییرات مسیریابی اندازه‌گیری کنید.
• زمان تا اولین توکن، توان عملیاتی، عمق صف، و فشار VRAM را با هم مشاهده کنید.
• با مسیریابی پیشوند-هش شروع کنید قبل از ساخت مسیریابی آگاه به رویداد کش.
• قوانین مسیریابی را بر اساس بار کاری تقسیم کنید به جای اینکه یک سیاست جهانی را تحمیل کنید.
• هزینه و تأخیر را در سطح برنامه قابل مشاهده نگه دارید، نه فقط در داخل خوشه استنتاج.

سوالات متداول

مسیر‌یابی حافظه نهان KV چیست؟

مسیر‌یابی حافظه نهان KV یک استراتژی مسیر‌یابی است که درخواست‌هایی با پیشوندهای تکراری را به نسخه‌هایی ارسال می‌کند که احتمالاً حافظه نهان KV مطابقت‌دهنده را دارند. هدف کاهش محاسبات پیش‌پرکردن اضافی است.

مسیر‌یابی حافظه نهان KV چگونه با حافظه نهان پیشوند متفاوت است؟

حافظه نهان پیشوند توانایی موتور سرویس‌دهی مدل برای استفاده مجدد از حالت ذخیره‌شده برای پیشوندهای مشترک است. مسیر‌یابی حافظه نهان KV استراتژی تخصیص ترافیک است که کمک می‌کند درخواست‌های مطابقت‌دهنده به جایی برسند که آن حالت ذخیره‌شده قبلاً وجود دارد.

چرا مسیر‌یابی چرخشی به حافظه نهان پیشوند آسیب می‌زند؟

مسیر‌یابی چرخشی درخواست‌ها را بین نسخه‌ها پخش می‌کند بدون اینکه بداند کدام نسخه کدام پیشوند ذخیره‌شده را دارد. یک پیشوند تکراری ممکن است حافظه نهان را از دست بدهد فقط به این دلیل که روی نسخه دیگری قرار می‌گیرد.

کدام بارهای کاری بیشترین بهره را از مسیر‌یابی حافظه نهان KV می‌برند؟

چت چند‌مرحله‌ای، RAG، عوامل کدنویسی، عوامل پشتیبانی، درخواست‌های چند‌نمونه‌ای، و اپلیکیشن‌هایی با درخواست‌های سیستم طولانی مشترک قوی‌ترین گزینه‌ها هستند زیرا پیشوندهای درخواست قابل توجهی را مجدداً استفاده می‌کنند.

چه زمانی یک تیم باید مسیر‌یابی حافظه نهان KV را کنار بگذارد؟

زمانی که درخواست‌ها کوتاه، عمدتاً منحصر‌به‌فرد، یا دسته‌محور با ساختار تکراری کم هستند، آن را کنار بگذارید. در این موارد، پیچیدگی مسیر‌یابی ممکن است ارزش کمی اضافه کند.

آیا vLLM و SGLang از حافظه نهان پیشوند پشتیبانی می‌کنند؟

بله. مستندات vLLM حافظه نهان پیشوند خودکار را توضیح می‌دهد و مستندات SGLang حافظه نهان پیشوند برای حافظه نهان مشترک KV در دنباله‌های توکن رایج را توضیح می‌دهد. موتور سرویس‌دهی همچنان به کمک مسیر‌یابی نیاز دارد وقتی نسخه‌های متعدد درگیر هستند.

آیا مسیر‌یابی حافظه نهان KV همان حافظه نهان معنایی است؟

خیر. مسیر‌یابی حافظه نهان KV با استفاده مجدد دقیق یا تقریباً ساختاری پیشوندها در سرویس‌دهی استنتاج کار می‌کند. حافظه نهان معنایی پاسخ‌ها یا نتایج میانی را بر اساس معنا ذخیره و استفاده مجدد می‌کند، معمولاً با جاسازی‌ها یا آستانه‌های شباهت.

آیا ShareAI یک متعادل‌کننده بار آگاه به حافظه نهان KV را جایگزین می‌کند؟

خیر. ShareAI بازار هوش مصنوعی و لایه API برای دسترسی به مدل‌ها، مسیریابی، پشتیبانی، استفاده و صورتحساب است. مسیریابی آگاه به KV-cache زیرساخت سطح پایین ارائه مدل برای تیم‌هایی است که نسخه‌های استنتاج را اجرا می‌کنند.

سازندگان چگونه باید درباره مسیریابی کش KV فکر کنند؟

سازندگان باید رفتار کش را به‌عنوان یکی از عوامل هزینه در برنامه‌های سنگین هوش مصنوعی در نظر بگیرند. اگر برنامه آن‌ها استفاده نابرابر دارد، ShareAI می‌تواند به مسیریابی و کسب درآمد از آن ترافیک هوش مصنوعی کمک کند، در حالی که برنامه خارج از ShareAI ساخته و مالکیت می‌شود.

تیم‌ها باید قبل از تغییر مسیریابی چه چیزی را اندازه‌گیری کنند؟

نرخ ضربه کش، زمان تا اولین توکن، توان عملیاتی، عمق صف، فشار VRAM، هزینه هر وظیفه و کیفیت خروجی را اندازه‌گیری کنید. تغییرات مسیریابی باید بار کاری را بهبود دهد، نه فقط داشبورد را.

آیا مسیریابی کش KV می‌تواند هزینه‌های API هوش مصنوعی را کاهش دهد؟

این می‌تواند هزینه زیرساخت را برای تیم‌هایی که خودشان مدل‌ها را ارائه می‌دهند کاهش دهد، زیرا کار پیش‌پر کردن کمتر تکراری می‌تواند کارایی GPU را بهبود بخشد. برای API‌های میزبانی‌شده، اثر آن بستگی به این دارد که آیا ارائه‌دهنده آن صرفه‌جویی‌ها را در قیمت یا عملکرد نشان می‌دهد یا خیر.