llm-d 1.0: Inference Altyapısında Asıl İş Modeli Ayağa Kaldırdıktan Sonra Başlıyor
Bir modeli tek GPU üzerinde çalıştırmak ile aynı modeli değişken trafik altında bir servis olarak işletmek farklı mühendislik problemleri. İlkinde bir yanıt almak yeterli olabilir. İkincisinde bir müşterinin uzun isteği diğer müşterilerin gecikmesini artırmamalı; sürüm geçişi devam eden akışları kesmemeli.
Güncel gelişme: llm-d 1.0
20 Ekim 2026 tarihli llm-d 1.0 duyurusu, çok kiracılı hizmet kalitesi, kesintisiz işletim ve agent oturumlarını dikkate alan serving üzerinde duruyor. Prefill/decode ayrımı ve prefix-aware routing önceki sürümlerde de vardı. Yeni sürümün odağı bu bileşenleri gerçek trafik ve sürüm geçişleri altında birlikte yönetmek. Çok kiracılı trafik politikaları ise yapılandırılmalı; sürüm yükseltmek tek başına müşteri önceliklerini tanımlamıyor.
İstek sayısı neden yeterli bir yük sinyali değil?
İki endpoint düşünelim. Birinde az sayıda ama uzun prompt, diğerinde çok sayıda kısa prompt var. Sadece kuyruktaki istekleri saymak, yapılacak hesaplamayı yanlış temsil edebilir. Buna karşılık sürekli cache eşleşmesine göre seçim yapmak da sıcak bir endpoint üzerinde trafik yığabilir.
llm-d ekibinin 17 Ağustos 2026 tarihli routing incelemesi, prefix yakınlığını kapasite sınırına kadar koruyan bir yaklaşımı anlatıyor. Prefill ağırlıklı trafikte işlenmemiş token yükü, decode ağırlıklı trafikte aktif akışlar öne çıkıyor. Buradaki değer tek bir evrensel skor bulmakta değil; yük sinyalini darboğaza göre seçmekte.
Prefill ve decode ne zaman ayrılmalı?
Prefill prompt'u işler ve KV cache üretir; decode bu durum üzerinden çıktı token'larını üretir. Dynamo dokümantasyonu bu iki aşamanın bağımsız worker havuzlarına ayrılmasını açıklıyor. Ayrı havuzlar bağımsız ölçeklenebilir, ancak aralarında KV cache taşımak gerekir. Kısa istekler ve düşük eşzamanlılıkta bu ek yolun maliyeti, ayrıştırmanın kazancını aşabilir.
Benim mimari değerlendirmem şu: önce hangi aşamanın gecikme bütçesini tükettiğini belirlemek gerekir. Prefill kuyruğu büyürken decode kapasitesi boş kalıyorsa ayrı havuzları denemek anlamlıdır. Her iki aşama da rahat çalışıyorsa yeni servisler, yeni hata noktaları ve ağ bağımlılığı eklemek için güçlü bir gerekçe yoktur.
Bir geçişi nasıl değerlendirirdim?
- Başlangıç ölçümü: Aynı model ve donanım üzerinde birleşik serving ile p50/p95 ilk token gecikmesini, token arası gecikmeyi ve hata oranını kaydederdim.
- Trafik ayrımı: Uzun prompt, uzun çıktı ve tekrar eden agent oturumlarını ayrı senaryolar olarak oynatırdım.
- Tek değişken: Önce routing politikasını, ardından gerekirse havuz ayrımını değiştirirdim. İkisini aynı anda değiştirerek sonucun nedenini belirsizleştirmezdim.
- İşletim deneyi: Yoğun trafik sırasında bir worker'ı boşaltıp sürüm değiştirir; yarıda kalan akışları ve cache soğumasını izlerdim.
Başarı ölçütü yalnızca toplam token/s olmamalı. Belirlenen gecikme sınırları içinde tamamlanan istek sayısını GPU-saat maliyetiyle birlikte değerlendirmek, kullanıcıya ulaşan kapasiteyi daha iyi anlatır. Bu yazı bir kaynak incelemesi ve mimari değerlendirmedir; burada bağımsız bir performans deneyi sunulmuyor.