Mimari ve çalışma modeli
LLM sunum katmanı model ağırlığını yüklemekten daha fazlasıdır: istek kuyruğu, sürekli veya dinamik batching, KV cache, tokenizer, streaming, paralellik, sağlık sinyalleri ve geri basıncı yönetir. Aynı GPU'da yüksek token/s hedefi ile düşük ilk-token gecikmesi çatışabilir; seçim gerçek istem uzunluğu dağılımıyla yapılmalıdır.
vLLM, LLM odaklı PagedAttention, sürekli batching ve OpenAI uyumlu API ile genel amaçlı üretim sunumuna odaklanır. Triton, farklı çerçeve ve model türlerini ensemble, model instance ve dinamik batching altında birleştirir. TGI olgun bir LLM sunucusudur; ancak bakım ve destek durumu kullanılan sürüm için resmi belgelerden ayrıca doğrulanmalıdır.
Platform seçimi marka listesiyle bitmez. Tensor/pipeline paralelliği, quantization desteği, LoRA yaşam döngüsü, çoklu model yerleşimi, GPU mimarisi, gözlemlenebilirlik ve operasyon ekibinin hata alanı değerlendirilir. Taşınabilir bir dış API ve sürümlü test seti geçiş maliyetini azaltır.
- 1API ve kimlik geçidi
- 2Scheduler, queue ve batching
- 3Model workers ve GPU belleği
- 4Streaming, metrik ve hata sonucu
Tasarım parametreleri
- Kuyruk politikası
- Maksimum kuyruk, zaman aşımı, öncelik ve iptal davranışını ürün trafiğine göre belirleyin.
- Batch penceresi
- Daha büyük batch throughput'u artırabilir; p95 TTFT bütçesini ihlal etmeyen mikro-saniye/milisaniye aralığını ölçün.
- KV cache payı
- Ağırlık, çalışma alanı ve KV cache için GPU belleğini ayrı bütçeleyin; uzun bağlam eşzamanlılığı azaltır.
- API taşınabilirliği
- Kimlik, streaming, hata kodları ve kullanım sayaçlarını sağlayıcıdan bağımsız sözleşmeyle sarın.
Hesap ve uygulama örneği
Tek GPU 18.000 output token/s üretiyor ve ortalama cevap 450 token ise teorik tavan 40 cevap/s'dir. %70 sürdürülebilir kullanım ve 6 saniyelik ortalama üretim süresiyle Little yasası yaklaşık 168 eşzamanlı iş verir; KV cache bu eşzamanlılığı taşıyamıyorsa gerçek kapasite daha düşüktür.
A/B yük testinde batch gecikmesi 0'dan 2 ms'ye çıkarıldığında throughput %28 artıp p95 TTFT 420 ms'den 510 ms'ye geliyorsa 800 ms SLO içinde kabul edilebilir olabilir. Aynı ayar kısa etkileşimli isteklerle uzun toplu istekler karıştığında yeniden ölçülür.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
llm-bench run --targets vllm,triton,tgi --trace production-sample.jsonl --concurrency 1,8,32,128
llm-bench report --metrics ttft_p95,tpot_p95,tokens_per_second,error_rateHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| GPU dolu, throughput düşük | Küçük batch, tokenizer CPU darboğazı veya bellek bant genişliği sınırı vardır. | Queue, batch size, prefill/decode süresi ve GPU SM/bellek sayaçlarını birlikte alın. |
| TTFT tepe saatte sıçrıyor | Kuyruk büyüyor veya uzun prefill istekleri kısa işleri bloke ediyor. | Girdi token dağılımını ve per-request queue/prefill sürelerini ayırın. |
| OOM rastgele görünüyor | KV cache, uzun context ve eşzamanlılık birlikte sınırı aşıyor. | Model ağırlığı sonrası serbest bellek ve aktif sequence başına KV büyümesini ölçün. |
Kabul ve doğrulama kontrolleri
- Motorları aynı model, tokenizer ve hassasiyetle karşılaştırın.
- Gerçek input/output token dağılımından yük izi üretin.
- TTFT, TPOT, token/s, hata ve iptal oranlarını kaydedin.
- OOM ve worker restart sırasında kuyruk davranışını test edin.
- Canary ve hızlı geri dönüş için model sürümünü sabitleyin.
- Maliyet hesabına boşta GPU, replikasyon ve gözlem yükünü ekleyin.
İlgili kavramlar
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Kuyruk ve eşzamanlılık
Kuyruk, bir kaynağın işleyebildiğinden daha hızlı gelen işleri tutar. Eşzamanlılığı artırmak belirli bir noktaya kadar kapasite kullanımını yükseltir; sonra bekleme süresini büyütür. Durağan durumda Little yasası L = λ × W ilişkisidir: ortalama sistemdeki iş sayısı, tamamlanan iş hızı ile ortalama toplam sürenin çarpımıdır. Birimler tutarlı olmalıdır. 2.000 işlem/s ve 5 ms toplam süre yaklaşık 10 eşzamanlı iş demektir. Bu ilişki tasarım tahminidir; kuyruk sınırları, ani yük ve çok değişken servis süreleri ayrıca ölçülmelidir.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Kaynak rekabeti
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.