تیم گوگل در کنفرانس PyTorch North America نسخه ۱.0 llm-d را منتشر کرد؛ اولین نسخه پایدار این استک استنتاج توزیع‌شده. llm-d یک لایه متن‌باز و Kubernetes-native است که سرورهای مدل vLLM یا SGLang را به یک استخر هماهنگ تبدیل می‌کند و هدف مشخص آن بارهای کاری خودمیزبان ایجنت و RL است که در آن‌ها بارگذاری round-robin شکست می‌خورد.

پروژه و مجوز#

llm-d در ۲۰۲۵ توسط Red Hat، IBM، Google Cloud، CoreWeave و NVIDIA بنیان‌گذاری شده و بیش از ۵۰۰ مشارکت‌کننده از ۲۵ سازمان دارد. این پروژه از ۱۲ مارس ۲۰۲۶ در CNCF Sandbox پذیرفته شده و تحت مجوز Apache 2.0 منتشر می‌شود. Red Hat، IBM و Google نگهدارندگان اصلی هستند.

آنچه در ۱.0 جدید است#

  • کیفیت خدمت چندمستأجیره: کنترل جریان اولویت‌محور و منصفانه که جلوی گرسنگی‌دادن درخواست‌های حساس به تأخیر را می‌گیرد.
  • ارتقای بدون قطعی: Router با hot standby و DisaggregatedSet که استخرهای prefill و decode را هم‌زمان رول می‌کند.
  • سروینگ ایجنت‌آگاه: مسیریابی نشست‌محور، زمان‌بندی اولویت نوبت و پشتیبانی بومی از وضعیت Responses API.
  • استنتاج ناهمگام: llm-d-async-processor کارها را از Google Cloud Pub/Sub یا Redis به ظرفیت آزاد می‌کشد.
  • پشتیبانی گسترده‌تر TPU: TorchTPU مدل‌های PyTorch را به‌صورت بومی در vLLM و SGLang اجرا می‌کند.

نتایج بنچمارک (خودگزارشی)#

گوگل و کاربران llm-d اعداد زیر را گزارش کرده‌اند:

  • روی TPU Ironwood (TPU 7x): کاهش بیش از ۸۵٪ در TTFT میانی و ۲.۴ برابر افزایش throughput نسبت به Kubernetes Service ساده.
  • روی پلتفرم Gemini: نرخ اصابت پیشوند کش از ۳۵٪ به ۷۰٪ دو برابر شد؛ TTFT ایجنت‌های کدنویسی بیش از ۳۵٪ کاهش یافت.
  • بنچمارک ۱۷٬۰۰۰ گره‌ای روی GKE چندناحیه‌ای: scaling تا ۲.۹ برابر throughput در ۳ خوشه، موفقیت ۹۹.۹٪ و سربار کمتر از ۱٪.
  • RL time-slicing: چرخه کارایی شتاب‌دهنده از حدود ۴۰٪ به بالای ۷۰٪ رسید؛ یعنی هنوز حدود ۳۰٪ زمان بیکاری باقی است.

کاربران بیرونی هم الگوهای مشابهی گزارش کرده‌اند: Snap نرخ اصابت پیشوند کش ۷۵ تا ۸۰٪، و Zenteiq بیش از ۴ برابر افزایش throughput (از ۱.۴۷ به ۵.۹۷ میلیارد توکن روزانه به ازای هر ۱٬۰۰۰ تراشه TPU v6e).

مقایسه با NVIDIA Dynamo و AIBrix#

این سه پروژه رقیب مستقیم نیستند. CoreWeave همزمان llm-d و Dynamo را اجرا می‌کند و NVIDIA اجزای Dynamo را به llm-d کمک می‌کند. تفاوت کلیدی llm-d در پشتیبانی از TPU گوگل و ادغام با اکوسیستم Kubernetes-native است.

تحلیل تحریریه#

برای کسی که همین حالا ایجنت‌های خودمیزبان روی Kubernetes اجرا می‌کند، llm-d 1.0 یک لایه مسیریابی و مدیریت کش اضافه می‌کند که قبلاً دستی می‌نوشت. عدد ۸۵٪ کاهش TTFT و ۲.۹ برابر scaling توجه‌برانگیز است، اما همه خودگزارشی‌اند و روی بارهای کاری مشخص (کدنویسی، چت) تست شده‌اند. مهم‌تر اینکه هنوز حدود ۳۰٪ بیکاری شتاب‌دهنده در سناریوی RL باقی است؛ یعنی این ابزار مشکل idle time را حل نکرده، بلکه کاهش داده. اگر از vLLM یا SGLang استفاده می‌کنید و با مشکل starving درخواست‌ها در بار ایجنتی دست‌وپنجه نرم می‌کنید، افزودن prefix-aware routing مرحله اول معقولی است. اما اگر ناوگان شما زیر ۱۰۰ گره است، احتمالاً هزینه عملیاتی اضافه‌کردن این لایه به‌اندازه سودش نیست.

منبع: MarkTechPost