‏نتفلیکس چطور خودش LLM سرو می‌کنه

تیم‌های Model Runtime و Inference نتفلیکس تو بلاگ فنی این شرکت نوشتن که برخلاف بیشتر سازمان‌ها که LLM رو از طریق APIهای میزبانی‌شده مصرف می‌کنن، کل پشته رو خودشون اجرا می‌کنن؛ اون هم نه تو یه جزیرهٔ جدا برای ML، بلکه داخل همون محیط تولیدی موجود. به گفتهٔ نویسنده‌ها تمرکز مقاله روی تصمیم‌هاییه که واقعاً گزینهٔ رقیب داشتن: موتور، بسته‌بندی، سطح API و استراتژی انتشار.

سرویس‌دهی ML تو نتفلیکس پشت یه سیستم JVM قرار داره که مسیریابی، منطق تست A/B، تولید کاندیدا، واکشی فیچر و لاگ‌برداری رو مدیریت می‌کنه. مدل‌های کوچیکِ CPU همون‌جا داخل پروسه اجرا می‌شن، ولی مدل‌های بزرگ می‌رن سراغ سرویس مشترک Model Scoring Service که Triton زیرش بارگذاری مدل، بچینگ و زمان‌بندی GPU رو به عهده داره.

پلتفرم اولش روی TensorRT-LLM ساخته شده بود، ولی تا تابستون ۲۰۲۵ دو چیز عوض شد: موتورهای متن‌باز فاصلهٔ کارایی رو تقریباً پر کردن و ترکیب بارکاری هم متنوع‌تر شد. بعد از بنچمارک دوباره، vLLM شد موتور اصلی — بیشتر به خاطر تناسب عملیاتی: بارگذاری معماری‌های سفارشی بدون پایپ‌لاین کامپایل چندمرحله‌ای، قلاب‌های توسعه برای منطق decode سفارشی، دیباگ‌پذیری بهتر و آشنایی قبلی تیم پژوهش.

برای بسته‌بندی، بک‌اند vLLM تو Triton انتخاب درست بود چون آرتیفکت فقط یه کانفیگ JSON ساده‌ست که به وزن‌ها و توکنایزر اشاره می‌کنه و مشخصات تنسور ورودی/خروجی موقع دیپلوی ساخته می‌شن. ولی دو چیز تو تولید گاز گرفت: ناسازگاری نسخهٔ Triton با vLLM (مثلاً ماژول متریکی که تو نسخهٔ جدیدتر vLLM حذف شده بود) و مدل‌هایی با پیش/پس‌پردازش سفارشی که مجبورن برگردن به بک‌اند پایتون.

یه اصل طراحی این بود که LLM نباید موجود خاصی باشه: هر مدلی، از XGBoost تا مدل‌های بزرگ، با همون فراخوانی gRPC اسکور می‌شه. کنارش API سازگار با OpenAI هم به عنوان فرانت‌اند دوم اضافه شده تا مهاجرت از یه مدل میزبانی‌شده به نسخهٔ خودمیزبان تقریباً بدون تغییر کد انجام بشه. برای انتشار هم دو مسیر هست: Red-Black ارزون‌تر و پیش‌فرضه، Versioned برای وقتی که اسکیمای ورودی/خروجی می‌شکنه.

عمیق‌ترین بخش مقاله به constrained decoding برمی‌گرده: به جای اینکه خروجی نامعتبر تولید و بعد تعمیر بشه، محدودیت‌ها همون داخل حلقهٔ decode اعمال می‌شن. پیاده‌سازی اول روی vLLM V0 به خاطر GIL و اجرای ترتیبی برای هر درخواست، روی CPU گیر کرد و تأخیر با بزرگ‌تر شدن بچ بالا می‌رفت. تو V1 که پردازش logits سطح-بچ شد، تیم مسیر داغ رو با C++ و چندنخی بازنویسی کرد و این زمان تقریباً ثابت موند.

دو نکتهٔ عملیاتی هم ارزش گفتن دارن: مدل‌ها موقع اعلام روی Amazon FSx آماده می‌شن تا دانلود از S3 کولد استارت رو طولانی نکنه، و چون Triton فقط ۹ تا از بیش از ۴۰ متریک vLLM رو منتقل می‌کرد، تیم یه پراکسی HTTP سبک نوشت که هر دو رو تو یه endpoint واحد ادغام کنه تا داشبوردهای قبلی دست‌نخورده کار کنن.

نکات کلیدی:

• کل پشتهٔ سرو LLM داخل زیرساخت تولیدی موجود اجرا می‌شه، نه تو یه سیلوی جدا برای ML
• انتخاب vLLM به جای TensorRT-LLM بر اساس تناسب عملیاتی بود، نه فقط سرعت خام
• بک‌اند vLLM مدل و فرانت‌اند رو از هم جدا نگه می‌داره؛ بک‌اند پایتون فقط برای مدل‌های سفارشی می‌مونه
• API سازگار با OpenAI کنار gRPC، مسیر آزمایش تا تولید رو کوتاه می‌کنه
• محدودسازی خروجی داخل حلقهٔ decode، بعد از سطح-بچ شدن logits تو vLLM V1 مقیاس‌پذیر شد