Netflix’in şirket içi LLM serving platformu

• Netflix, LLM’leri ayrı bir silo olarak ayırmak yerine mevcut ML altyapısında birlikte çalıştırıyor ve vLLM ile Triton’ı birleşik serving sistemine bağlıyor
• Varsayılan motor olarak seçilen vLLM; özel model desteği, hata ayıklama kolaylığı, genişletme hook’ları ve araştırma ortamlarına aşinalık sunuyor. Triton’un vLLM backend’iyle model ile frontend arasındaki bağlılık azaltılıyor
• Mevcut gRPC ve OpenAI uyumlu API birlikte sunuluyor; ancak response_format eksikliği, Triton·vLLM sürüm uyumsuzluğu, standart dışı modellerin işlenmesi gibi prodüksiyonda ortaya çıkan boşlukların doğrudan kapatılması gerekti
• Kararlı dağıtımlar için önce düşük maliyetli Red-Black stratejisi uygulanıyor; Versioned stratejisi ise yalnızca uyumsuz I/O değişiklikleri kaçınılmaz olduğunda birden fazla sürümü aynı anda tutmak için kullanılıyor
• İstek bazlı kısıtları decoding döngüsünde zorunlu kılan logit processor’lar, vLLM V1’in batch işleme yapısı ve çok iş parçacıklı C++ ile yeniden uygulandı; ileride GPU fusion kernel’ları, asenkron zamanlama ve düşük hassasiyetli modellere genişletilmesi planlanıyor

---

Mevcut ML altyapısına entegre edilen serving yapısı

• Netflix’in JVM tabanlı birleşik serving sistemi routing ve A/B testleri, aday üretimi, özellik sorgulama, inference, son işleme ve aşama bazlı logging’i yönetiyor; hem gerçek zamanlı hem de cache’lenmiş batch yollarını destekliyor
• Çağıranlar, mevcut serving sisteminin gRPC yolu veya yeni LLM uygulamaları için doğrudan HTTP yolu üzerinden inference’a erişiyor
• Çalıştırma yeri model ölçeğine göre değişiyor
  • Küçük CPU modelleri, uzaktan çağrı maliyetinden kaçınmak için proses içinde çalıştırılıyor
  • Büyük GPU modellerinde ön ve son işleme yerelde yapılıyor, inference ise uzaktaki Model Scoring Service(MSS)’e devrediliyor
• MSS; XGBoost, TensorFlow, PyTorch ve LLM’leri tek bir arayüzle sunuyor; alttaki NVIDIA Triton Inference Server model yükleme, batch işleme ve GPU zamanlamasından sorumlu oluyor
• Triton üzerindeki Java kontrol düzlemi dağıtım, sürüm yönetimi, sağlık kontrolleri, otomatik ölçekleme ve çok bölgeli rollout’ları yönetiyor
  • Model geliştiricisi artifact’leri ve dağıtım ayarlarını paketlediğinde GPU instance’ları provision ediliyor ve Triton yapılandırılıyor
  • Yükseltmeler kesintisiz şekilde koordine ediliyor

Varsayılan inference motoru olarak vLLM’in seçilmesi

• İlk platform, o dönemde yüksek performanslı olan ve MSS’in Triton’ı ile zaten entegre çalışan TensorRT-LLM’i kullanıyordu
• 2025 yazına gelindiğinde açık kaynak motorlar, özel amaçlı stack’lerle olan performans farkının çoğunu kapattı; iş yükleri de aşağıdaki alanlara genişledi
  • Embedding üretimi
  • Sıralama ve arama için prefill-only inference
  • Otoregresif decoding
  • Aşama bazlı kısıt mantığı karmaşık olan özel modeller
• Bu iş yükleri yeniden benchmark edildikten sonra, operasyonel uygunluk kriterlerine göre vLLM varsayılan yol motoru olarak seçildi
  • Özel model mimarilerini çok aşamalı derleme olmadan yükleyebildiği için standart dışı modellerde iterasyon hızlanıyor
  • Özel decoding mantığı için genişletme hook’ları sunuyor
  • Derleme motoru olan erken dönem TensorRT-LLM’e kıyasla arızaları ve ara durumları incelemek daha kolay
  • Araştırma aşamasında vLLM’e zaten aşina olan çok sayıda ML uygulayıcısı bulunduğundan prodüksiyona geçiş maliyeti azalıyor

Triton ve vLLM’in paketleme yöntemi

• Triton’da Python backend ve vLLM backend olmak üzere iki paketleme yolu var; temel fark, frontend yükseltmeleri ile model artifact’lerinin ne kadar güçlü bağlandığı
• Python backend’de geliştirici paketleme sırasında giriş/çıkış tensor spesifikasyonlarını tanımlıyor
  • Spesifikasyon artifact’e sabitleniyor ve dış frontend’in istek builder’ı ile eşleşmek zorunda
  • Frontend yükseltmesi I/O’yu değiştirirse paketleme kodunun da birlikte değiştirilmesi gerekiyor; aksi halde runtime istekleri başarısız oluyor
• vLLM backend artifact’i, model ağırlıklarını ve tokenizer’ı gösteren JSON ayarlarından oluşuyor
  • Dağıtım sırasında Triton backend, I/O tensor spesifikasyonlarını dinamik olarak oluşturuyor
  • Model geliştiricisinin tensor spesifikasyonu tanımlaması gerekmiyor; model ve frontend bağımsız olarak değiştirilebiliyor
• Varsayılan tercih vLLM backend, ancak prodüksiyonda iki kısıt ortaya çıktı
  • Sürüm uyumsuzluğu: Triton backend belirli bir vLLM API’si temel alınarak derlendiğinden, iki sürüm ayrışırsa backend’in tamamı yüklenemiyor
    • Örneğin Triton 25.09 vllm.engine.metrics’i import ediyor, ancak bu modül vLLM 0.11.2’de kaldırıldı
    • Servis imajı oluşturulurken uyumlu sürümler sabitlenmeli ve model geliştiricisinin paketleme aşamasında vLLM sürümünü override etmesi engellenmeli
  • Özel yürütme mantığı: vLLM backend standart HuggingFace uyumlu modelleri ve tam inference yaşam döngüsünü varsayıyor
    • Özel ön/son işleme, ensemble pipeline’ları, ayrı tokenization gibi standart dışı yürütmeler için execute() üzerinde kontrol sağlayan Python backend gerekiyor
    • Bazı modellerde bu bypass yolu hâlâ gerekli

gRPC ve OpenAI uyumlu HTTP API

• XGBoost ensemble’larından büyük ölçekli LLM’lere kadar her şey aynı gRPC çağrısı ile değerlendiriliyor; böylece mevcut client kütüphaneleri, sağlık kontrolleri ve dağıtım pipeline’ları yeniden kullanılıyor
• LLM ekosistemindeki inference motorları, orchestration framework’leri, değerlendirme araçları ve client kütüphaneleri OpenAI uyumlu arayüz kullandığı için bu arayüz gRPC ile yan yana sunuluyor
• Aynı API korunduğundan, kalite, gecikme, maliyet veya veri gizliliği nedenleriyle barındırılan bir modelden ince ayar yapılmış self-hosted modele geçerken kod değişikliği az oluyor
• Uygulama, NVIDIA’nın Triton OpenAI uyumlu frontend’ini yeniden kullanıyor
  • Yerleşik Triton sunucusunu başlatıyor
  • TritonLLMEngine, istek şemasını Triton inference isteğine dönüştürüyor
  • FastAPI üzerinden yanıt sunuyor
  • KServe HTTP/gRPC frontend’i de birlikte etkinleştirilerek Java kontrol düzleminin aynı Triton instance’ına gRPC ile erişmesi sağlanıyor
• Frontend’in şemada izin verilen response_format alanını vLLM’e iletmeden önce sessizce attığı bir sorun bulundu
  • JSON çıktı istense bile guided decoding kısıtları olmadan çalışıp geçersiz JSON döndürebiliyor ve platform hatası da görünür olmuyordu
  • Frontend Git subtree olarak içeri alındı ve response_format isteklerini vLLM’in guided decoding parametrelerine dönüştürecek şekilde patch’lendi

Kesintisiz model dağıtım stratejisi

• GPU dağıtımlarının başlangıç süresi CPU servislerine göre daha uzun ve model sürümleri arasında I/O şeması bile değişebildiği için, istekleri kesmeden rollout yapmak ek koordinasyon gerektiriyor
• Red-Black dağıtım, mevcut sürümün yanına yeni sürümü kaldırıyor ve sağlık kontrollerini geçtikten sonra trafiği kademeli olarak aktarıyor
  • Yeni sürüm ile mevcut sürümün ölçek büyütme/küçültmesi aynı oranda yürütülüyor
  • Herhangi bir aşamada hata olursa atomik olarak rollback yapılıyor
  • Model arayüzü kararlı olduğunda uygun
• Yeni tensor boyutu gibi I/O şeması değiştiğinde Red-Black’te koordinasyon boşluğu oluşuyor
  • Yeni model tamamen etkinleşmeden üst tüketici ayar değiştiremiyor
  • Geçiş aralığında eski formattaki istekler yeni dağıtıma yönlendirilirse başarısız oluyor
• Versioned dağıtım, her (modelId, modelVersion) çifti için bağımsız bir dağıtım tutarak bu sorunu çözüyor
  • Birden fazla sürüm aynı anda servis verdiğinden model dağıtımı ile tüketici güncellemeleri ayrılıyor
  • Tüketici, yeni sürüm tamamen hazır olduktan sonra ayarını değiştiriyor; eski sürüm ise legacy trafiği işlemeye devam ediyor
  • Pasif hale gelen eski dağıtımlar temizleniyor, ancak en yeni sürüm her zaman korunuyor
  • Geçiş sırasında sürümlerin çakıştığı dönemde GPU maliyeti geçici olarak artıyor
• Tensor şekli gibi değişebilecek ayarların doğrudan inference modelinin içine konularak sürümden bağımsız hale getirilmesi ve düşük maliyetli Red-Black’in kullanılması öneriliyor
• Versioned yalnızca uyumsuz arayüz değişikliklerinden kaçınmak mümkün olmadığında kullanılıyor

Başlatma prosedürü ve model cache’i

• vLLM-on-Triton instance’ları gRPC portunu açabilmek için birden fazla başlangıç adımını tamamlamak zorunda
• Büyük LLM başlatılırken S3 veya Hugging Face’ten doğrudan indirme yapılırsa cold start, scheduler’ın izin verdiği aralığı aşacak kadar uzuyor
  • Model yayımlandığı anda model Amazon FSx üzerinde önceden somutlaştırılıyor
  • Sonraki başlatma sürecinde nesne depolama yerine yüksek performanslı dosya sistemi kullanılıyor
• OpenAI uyumlu API gereken dağıtımlarda Triton, ilgili frontend prosesinin içinde yerleşik sunucu olarak çalıştırılıyor
  • Diğer dağıtımlarda Triton bağımsız çalışıyor
  • Çalıştırma yöntemi paketleme sırasında dağıtım bazında ayarlanıyor
• Kalan başlatma adımları arasında model paketinin açılması, Python entry_points üzerinden özel vLLM eklentilerinin kurulması, Prometheus çoklu proses dizininin temizlenmesi ve motor hazır olana kadar gRPC portunun kapalı tutulması yer alıyor

Triton ve vLLM metriklerinin birleştirilmesi

• vLLM metrikleri PROMETHEUS_MULTIPROC_DIR içine .db dosyaları olarak yazıyor; Triton ise sunucu metriklerini ayrı bir Prometheus endpoint’i üzerinden sunuyor
• İki sistem birbirinin metriklerinden haberdar değil; Triton’un yerleşik bridge’i vLLM’in 40’tan fazla metriğinin yalnızca 9’unu dışa açıyor
  • Token throughput’u
  • KV cache kullanım oranı
  • Prefix cache hit oranı gibi temel göstergeler eksik kalıyor
• Hafif bir HTTP proxy, Triton metriklerini HTTP ile alıyor; Prometheus MultiProcessCollector ile diskteki vLLM metriklerini okuyup tek bir /metrics yanıtında birleştiriyor
• Mevcut dashboard’lar ve alarmlar değişiklik gerektirmeden kullanılabiliyor

Decoding sırasında çıktı kısıtlarının zorunlu kılınması

• Bazı prodüksiyon iş yükleri token üretimi üzerinde ince denetim gerektiriyor; bu yüzden inference sonrasında hatalı sonuçları yeniden denemek veya onarmak yerine decoding döngüsünün içinde kısıtlar uygulanıyor
• Her kısıt, üretilen token geçmişine göre durumu değişen ve her adımda izin verilen token maskesini çıkaran bir durum makinesi olarak modelleniyor
• vLLM’in özel logit processor arayüzü kullanılıyor; kurallar istek bazında değiştiği için ayrı yapılandırılmış processor atanıyor
• Başta özellik farkı nedeniyle vLLM V0 kullanıldı; V1 olgunlaştıktan sonra 2025’in 4. çeyreğinde geçiş yapıldı

vLLM V0’da ortaya çıkan ölçeklenme darboğazı

• İlk saf Python uygulaması işlevsel olarak çalıştı ancak eşzamanlı istekler arttığında ölçeklenmedi
• vLLM V0’ın özel logit processor’ı istek bazında çalışıyor
  • GPU tüm batch’in logit’lerini üretiyor
  • CPU bunları kopyalıyor ve aktarım bitene kadar bekliyor
  • Her isteğin kısıt mantığı sırayla çalıştırılıyor
• Python’un GIL’i nedeniyle istek bazlı işler paralelleştirilemiyor; bu yüzden logit işleme CPU süresi batch boyutuyla orantılı artıyor ve kuyruk gecikmesi büyüyor
• GPU’nun model forward pass’i verimli şekilde batch işlense de toplam gecikme CPU’ya bağlı kalıyor
• Bu darboğaz tek istekli benchmark’larda görünmüyor, yalnızca gerçek seviyedeki concurrency’de ortaya çıkıyor

vLLM V1’de batch düzeyinde işleme

• vLLM V1, logit işlemeyi istek bazlı yöntemden batch düzeyine taşıyor
• Özel processor, batch veri yapısına dayalı olarak yeniden yazıldı ve birden fazla isteğin maskesi birlikte hesaplanıyor
• Performansın kritik yolu GIL’den kaçınmak için çok iş parçacıklı C++ ile yeniden uygulandı; batch boyutu büyüse de logit işleme süresi sabit kalıyor
• V1 API’sinde update_state(batch_update) ile batch üyeliğindeki değişiklikleri açıkça izlemek gerekiyor
  • V0’ın istek bazlı arayüzünden daha karmaşık
  • Dinamik değişen batch’lerde istek bazlı durumu doğru korumak için gerekli

Durum tabanlı kısıt işlemede operasyonel güçlendirmeler

• Performans darboğazı çözüldükten sonra bile durum taşıyan decoding mantığında iki sorun ortaya çıktı

• Kısmi prefill

  • V1 chunk bazlı prefilling yaptığı için bir isteğin prefill’i birden fazla motor adımına yayılabiliyor
  • BatchUpdate tek başına tam prefill ile kısmi prefill’i ayırt edemediğinden dahili takip eklendi

• Preemption

  • Bellek yetersiz kaldığında vLLM, kısmen tamamlanmış bazı isteklerin KV cache’ini kaldırıp daha sonra farklı prompt ve çıktı token listesiyle yeniden zamanlayabiliyor
  • Bu, durum makinesinin çıktı token listesinin sürekli büyüyeceği varsayımını bozuyor
  • Decoding adımları arasında token geçmişinin kısalıp kısalmadığı algılanıyor; durum makinesi sıfırlanıp yeni prompt ile yeniden kuruluyor

Sonraki yatırım alanları

• Mevcut platform düşük gecikme, derin özelleştirme ve mevcut altyapı entegrasyonunu hedefliyor; vLLM ve Triton ile tutarlı API’ler sayesinde deneyden prodüksiyona uzanan bir yol sunuyor
• Sürüm sabitleme, sessizce atlanan API alanları ve paketleme tercihlerindeki trade-off’lar giderilerek platform kararlılığı ve geliştirici deneyimi iyileştiriliyor
• Şu dört iyileştirme planlanıyor
  • Kaliteden ödün vermeden prompt uzunluğunu azaltan sistem prompt sıkıştırma
  • vLLM V1’in asenkron zamanlaması
  • CPU kodu yerine GPU fusion kernel’larıyla çalışan vektörleştirilmiş logit processor
  • Bellek kullanımını azaltıp throughput’u artıran düşük hassasiyetli model varyantları
• Triton, vLLM, PyTorch gibi açık kaynak ML kütüphanelerinden yararlanmaya ve ilgili topluluklarla iş birliği yapmaya devam edilmesi planlanıyor