Netflix LLM sunumunu neden kendi işletiyor — ve hangi takasları yaptı
In-House LLM Serving at Netflix · Netflix Technology Blog
Çoğu kurum LLM'leri barındırılan API'ler üzerinden tüketiyor. Netflix daha ileri gitmiş: model dağıtımından çıkarıma kadar tüm yığını kendisi işletiyor — ve bunu ayrı bir ML silosunda değil, mevcut üretim ortamının içinde yapıyor. Yazının değeri de burada: sadece ne kurduklarını değil, neden öyle kurduklarını ve üretimin tasarım aşamasında görülmeyen neyi ortaya çıkardığını anlatıyor.
Mimari şöyle: üye ölçeğindeki ML, uçtan uca akışı yöneten JVM tabanlı birleşik bir sunum sistemiyle karşılanıyor — yönlendirme ve A/B testi mantığı, aday üretimi, özellik çekme, çıkarım, son işleme ve her aşamada loglama. Çağıranlar çıkarıma iki yoldan ulaşıyor: bu sistem üzerinden gRPC, ya da yeni LLM tabanlı uygulamaların kullandığı doğrudan HTTP yolu.
Çıkarımın nerede çalıştığı modele bağlı. Küçük CPU modelleri süreç içinde çalışıyor — uzak çağrı maliyeti ödenmiyor. Büyük modeller GPU istiyor; sunum sistemi ön ve son işlemeyi yerelde yapıp çıkarımı uzak bir servise devrediyor. Motor olarak vLLM seçilmiş, üstünde Triton, onun da üstünde dağıtım, sürümleme, sağlık kontrolü, otomatik ölçekleme ve çok-bölgeli yayılımı yöneten bir Java kontrol düzlemi var.
Yazı dört kararı bağımlılık sırasına göre işliyor — motor, paketleme, API yüzeyi ve yayılım — çünkü her biri bir sonrakini kısıtlıyor. Bu sıralama tek başına iyi bir mimari dersi.
Öne çıkanlar
- Küçük model süreç içinde, büyük model uzak GPU'da: tek bir dağıtım stratejisi yerine model boyutuna göre farklı yollar.
- İki API yüzeyi bir arada yaşıyor: eski tüketiciler için gRPC, yeni LLM uygulamaları için doğrudan HTTP.
- Kararlar bağımsız değil — motor seçimi paketlemeyi, paketleme API yüzeyini, o da yayılım stratejisini kısıtlıyor.
- Çıktı kısıtlarının uygulanması (output constraints enforcement) ayrı bir tasarım başlığı olarak ele alınmış — modelin serbest metin üretmesine güvenilmiyor.
Neden önemli?
"Kendimiz mi işletelim, hazır API mi kullanalım?" sorusu her ekibin önüne gelecek. Netflix'in cevabı herkes için doğru değil — ölçekleri ve mevcut altyapıları bu kararı mantıklı kılıyor. Ama yazının aktardığı düşünme biçimi evrensel: kararları bağımsız seçimler gibi değil, birbirini kısıtlayan bir zincir olarak görmek.
Sende karşılığı
Bu yazıyı bir mimari kontrol listesi gibi kullan. KlioAI'da LLM çağrılarını Spring Boot backend'inden yapıyorsun; Netflix'in sorduğu soruların küçük ölçekli hâlini sen de sorabilirsin: (1) API yüzeyi — istemci doğrudan mı çağırıyor, yoksa backend üzerinden mi? (Doğrudan çağırırsa API anahtarın istemcide olur, yapma.) (2) Yayılım — model ya da prompt değiştiğinde tüm kullanıcılara birden mi gidiyor? A/B testi ya da kademeli açılış var mı? (3) Çıktı kısıtı — modelin döndürdüğü şeyi şemayla doğruluyor musun? Netflix'in "output constraints" başlığı altında ayrıca ele aldığı şey tam olarak bu, ve senin pipeline'ında da en kritik korumadır.
Sözlük
- vLLM vLLM
- Büyük dil modellerini yüksek verimle sunmak için tasarlanmış açık kaynak çıkarım motoru.
- control plane kontrol düzlemi
- Sistemin ne çalıştıracağına, nerede ve hangi sürümle karar veren yönetim katmanı; veriyi işleyen katmandan (data plane) ayrıdır.
- gRPC gRPC
- HTTP/2 üstünde çalışan, şema tabanlı servisler-arası çağrı protokolü.
- output constraints çıktı kısıtları
- Modelin yalnızca belirli bir şemaya ya da biçime uyan çıktı üretmesini zorlayan mekanizma.