‏llm-d 1.0 منتشر شد: سرو کردن توزیع‌شده‌ی LLM روی Kubernetes

گوگل تو کنفرانس PyTorch نسخه‌ی llm-d 1.0 رو منتشر کرد. llm-d یه استک متن‌باز و Kubernetes-native برای inference توزیع‌شده هست، یعنی اجرای یه مدل زبانی روی کلی سرور به شکل هماهنگ. این پروژه رو گوگل با Red Hat و IBM و بقیه راه انداخته، بیش از ۵۰۰ مشارکت‌کننده از ۲۵ سازمان داره و جزو پروژه‌های Sandbox بنیاد CNCF هست. llm-d روی موتورهای vLLM و SGLang سوار می‌شه.

به گفته‌ی گوگل، مشکل اصلی اینه که ترافیک از چت ساده به ایجنت‌های چندمرحله‌ای و RL rollout (یعنی تولید انبوه جواب برای آموزش با یادگیری تقویتی) رسیده. این بارها پیشوند پرامپت مشترک و طولانی دارن و یهو هجوم میارن. با یه load balancer معمولی round-robin، هر سرور همون پرامپت رو از اول حساب می‌کنه، حافظه‌ی شتاب‌دهنده پر از داده‌ی تکراری می‌شه و یه ایجنت پرترافیک می‌تونه کاربرهای تعاملی رو معطل کنه.

روتر llm-d روی Gateway API Inference ساخته شده و می‌دونه KV cache (یعنی نتیجه‌ی محاسبه‌ی بخش‌های قبلی پرامپت که مدل نگه می‌داره) هر پیشوند روی کدوم سرور هست. موقع انتخاب سرور، بار و تأخیر پیش‌بینی‌شده رو هم حساب می‌کنه. وقتی حافظه‌ی شتاب‌دهنده پر بشه، کش دور ریخته نمی‌شه و به RAM میزبان، بعد SSD یا Google Cloud Managed Lustre منتقل می‌شه. تو یه بار کاری کدنویسی ایجنتی روی Ironwood TPU، این ترکیب میانه‌ی TTFT (زمان رسیدن اولین توکن) رو بیش از ۸۵ درصد کم کرده و throughput رو ۲.۴ برابر کرده.

چیزهای جدید نسخه‌ی ۱.۰ ایناست: flow control برای اولویت‌بندی و تقسیم منصفانه بین درخواست‌های حساس به تأخیر و بارهای پرهجوم، APIهای پایدار v1، high availability برای روتر و آپدیت بدون downtime. ابزار DisaggregatedSet هم اضافه شده که روی LeaderWorkerSet ساخته شده و استخرهای prefill و decode رو مثل یه واحد آپدیت می‌کنه. prefill سنگینِ محاسبه‌ست و decode سنگینِ حافظه، برای همین جدا اجرا می‌شن تا معطل هم نشن.

برای ترافیکی که عجله نداره، llm-d-async-processor معرفی شده که درخواست‌ها رو از صف‌هایی مثل Pub/Sub یا Redis برمی‌داره و فقط تو ظرفیت خالی اجرا می‌کنه. یه قابلیت time-slicing هم اضافه شده که تو زمان‌های بیکاری آموزش RL (که به گفته‌ی گوگل ۴۰ تا ۶۰ درصد وقت شتاب‌دهنده‌ست) inference اجرا می‌کنه و بهره‌وری رو از حدود ۴۰ به بیش از ۷۰ درصد می‌رسونه. داشبورد متن‌باز Prism هم برای مقایسه‌ی بنچمارک‌ها هست.

روی Google Cloud، سرویس GKE Inference Gateway همین روتر رو به شکل مدیریت‌شده اجرا می‌کنه و امکان توزیع بین چند کلاستر و منطقه رو می‌ده. طبق گزارش، پلتفرم Gemini با این سرویس نرخ hit کش پیشوند رو از ۳۵ به ۷۰ درصد رسونده. Snap هم از نرخ hit تا ۷۵ تا ۸۰ درصد و ZenteiQ از بیش از ۴ برابر throughput خبر دادن. گوگل پیشنهاد می‌کنه اول routing آگاه از پیشوند رو جلوی vLLM فعلیت بذاری و بعد بقیه‌ی قابلیت‌ها رو کم‌کم اضافه کنی.

نکات کلیدی:

• llm-d 1.0 پروژه‌ی Sandbox در CNCF هست با بیش از ۵۰۰ مشارکت‌کننده از ۲۵ سازمان.
• روی vLLM و SGLang و ترکیبی از TPU و GPU گوگل کار می‌کنه.
• routing آگاه از پیشوند به همراه offload کش به RAM میزبان، TTFT رو روی Ironwood TPU بیش از ۸۵ درصد کم و throughput رو ۲.۴ برابر کرده.
• DisaggregatedSet استخرهای prefill و decode رو با هم و بدون قطع session آپدیت می‌کنه.
• time-slicing بهره‌وری شتاب‌دهنده تو آموزش RL رو از حدود ۴۰ به بیش از ۷۰ درصد رسونده.
• پلتفرم Gemini با GKE Inference Gateway نرخ hit کش پیشوند رو از ۳۵ به ۷۰ درصد رسونده.