GKE Inference Gateway؛ پاسخِ سریعتر با prefix caching
خلاصهٔ کاملتر
به گفتهٔ گوگل، وقتی هوش مصنوعیِ مولد از آزمایش به محیطِ production میرسه، بهرهوریِ زیرساخت به مزیتِ اصلی تبدیل میشه. GKE Inference Gateway یه افزونهٔ بومیِ روی GKE Gateway هست که بهجای load balancingِ ساده و round-robin (که مدام باعثِ محاسبهٔ دوباره و پرشِ latency میشه)، درخواستها رو بر اساسِ متریکهای بلادرنگِ سرورِ مدل و بهشکلِ آگاهبهمدل مسیریابی میکنه.
رازِ کاهشِ latency از نگاهِ مقاله، prefix caching هست. این تکنیک KV cache (حالتهای فعالسازیِ) پیشوندهای طولانی و تکراریِ پرامپت رو ذخیره میکنه؛ پس وقتی چند درخواستِ پشتسرهم یه دستورالعملِ سیستمی یا کانتکستِ مشترک دارن، مدل کاملاً پردازشِ دوبارهٔ اون توکنها رو رد میکنه. گیتوی پیشوندِ درخواستِ ورودی رو میخونه و به همون podای میفرسته که اون داده رو تو حافظه آماده داره.
مقاله دو کاربردِ اصلی رو مثال میزنه: اول پرسشوپاسخ روی مستندات و کدبیس با RAG، که کلِ مجموعهٔ مستندات بهشکلِ یه پیشوندِ کششدهٔ ثابت پین میشه و مدل فقط سؤالِ کوتاه و پویا رو محاسبه میکنه. دوم چتِ چندمرحلهای، که پرامپتِ سیستمیِ ثابت و قوانینِ کسبوکار رو روی سرورِ مدل کش میکنن تا چتبات حتی زیرِ بارِ سنگین هم سریع بمونه.
به گفتهٔ گوگل و بر اساسِ یه بنچمارکِ مستقل از Principled Technologies، این گیتوی نسبت به یه سرویسِ کوبرنتیزِ مدیریتشدهٔ دیگه با round-robin، روی یه ورکلودِ Llama 3.1 8B و با سختافزارِ یکسان (هشت GPUِ NVIDIA A100 40GB) این نتایج رو داده: ۱۵٫۷٪ throughputِ بیشتر، ۹۲٫۸٪ زمانِ انتظارِ کمتر تا اولین توکن (TTFT) و ۶۲٫۶٪ latencyِ بینتوکنیِ کمتر.
تجربهٔ Snap هم با همین راستاست؛ به گفتهٔ یکی از مدیرانِ مهندسیِ Snap، اونها با مسیریابیِ آگاهبهکشِ پیشوند و استفاده از llm-d به نرخِ اصابتِ کشِ پیشوندِ ۷۵ تا ۸۰ درصد رسیدهن و از ماهیتِ متنبازِ llm-d برای یکپارچگی با سرویسمشِ مبتنیبر Envoyشون استقبال میکنن.
نکات کلیدی:
- GKE Inference Gateway درخواستها رو آگاهبهمدل و بر اساسِ متریکهای بلادرنگ مسیریابی میکنه.
- prefix caching با ذخیرهٔ KV cache پیشوندهای مشترک، از پردازشِ دوباره جلوگیری میکنه.
- بنچمارکِ مستقل: ۱۵٫۷٪ throughputِ بیشتر و ۹۲٫۸٪ TTFTِ کمتر روی Llama 3.1 8B.
- Snap با llm-d به نرخِ اصابتِ کشِ پیشوندِ ۷۵ تا ۸۰ درصد رسیده.




