İşlem Hacmi (Throughput)

Throughput (işlem hacmi), bir AI sisteminin birim zamanda ne kadar iş işleyebildiğini ölçer — tipik olarak saniye başına token (tek bir isteğin üretim hızı için) veya saniye/dakika başına istek (belirli bir altyapı parçasının kaç eşzamanlı kullanıcıya hizmet verebileceği için) olarak ifade edilir. Throughput ve gecikme birbiriyle ilişkili ama farklı kavramlardır ve bu fark pratik açıdan önemlidir: gecikme tek bir isteğin ne kadar hızlı tamamlandığıyla ilgiliyken, throughput sistemin sürdürebileceği toplam hacimle ilgilidir — ve birini optimize etmek bazen diğerinin pahasına olabilir. LLM çıkarımına hizmet veren bir GPU, genellikle birden fazla isteği "batch" haline getirerek (birkaç kullanıcının promptlarını modelden aynı ileri geçişte çalıştırarak) eşzamanlı işleyebilir; bu toplam throughput'u önemli ölçüde artırır ama herhangi bir bireysel isteğin yaşadığı gecikmeyi hafifçe artırabilir, çünkü bir batch'in dolması için kısaca beklemesi gerekebilir. Bu, bir AI özelliğini bir prototipten (bir avuç test isteğini işleme) üretime (binlerce eşzamanlı kullanıcıyı işleme) ölçeklendiren SaaS geliştiricileri için önemlidir: 10 test kullanıcısıyla sorunsuz çalışan bir özellik ölçekte throughput tavanlarına çarpabilir — ya kendi kendine barındırdığınız altyapınız istekleri yeterince hızlı işleyecek GPU kapasitesinden yoksun kalır ya da yük altında uygulamanızı kısıtlayan sağlayıcı taraflı hız limitlerine (API sağlayıcıları genellikle hesap/katman başına hem dakika başına istek hem de dakika başına token sınırları uygular) çarparsınız. Somut bir örnek: bir SaaS şirketi AI destekli bir e-posta özetleme özelliği başlatıyor ve başlangıçta sınır bir model API'sini kullanıcı isteği başına doğrudan çağırıyor; 50 eşzamanlı kullanıcıda bu sorunsuz çalışıyor ama bir ürün lansmanı trafik artışı sırasında 5.000 eşzamanlı kullanıcıda, API sağlayıcısının dakika başına token hız limitine çarpmaya başlıyorlar; bu da isteklerin kuyruğa girmesine veya başarısız olmasına neden oluyor. Çözüm, birkaç throughput odaklı mimari değişikliği içerir: sağlayıcıdan daha yüksek bir hız limiti katmanı talep etmek, zarif geri basınç (backpressure) ile istek kuyruklama uygulamak (böylece UI hata vermek yerine "işleniyor" gösterir), mümkün olduğunda batch işleme yapmak ve potansiyel olarak yüksek hacimli/düşük karmaşıklıktaki istekleri, sınır modeli buna ihtiyaç duyan durumlar için saklarken daha küçük, daha hızlı, daha yüksek throughput'lu bir model katmanına yönlendirmek. Model katmanını, sağlayıcı hız limitlerini ve kendi kendine barındırma ile API mimarisini seçmeden önce, yalnızca istek başına gecikmeyi değil, beklenen throughput gereksinimlerinizi anlamak esastır. Throughput planlaması ayrıca, farklı görev türlerinin çok farklı token profillerine ve dolayısıyla aynı istek hacminde çok farklı throughput maliyetlerine sahip olduğu gerçeğini de hesaba katmalıdır: basit bir evet/hayır sınıflandırma görevi istek başına bir avuç çıktı token'ı üretirken, uzun biçimli bir rapor üretme özelliği binlerce üretebilir — yani "saniye başına istek" tek başına eksik bir kapasite metriğidir ve altyapı boyutlandıran veya sağlayıcı hız limitleri müzakere eden ekipler, yalnızca ham istek sayılarına değil, kendi özellik karışımları için gerçekçi çıktı uzunluğu dağılımlarına dayalı beklenen dakika başına token değerini modellemelidir.