Büyük Dil Modelleri'ni (LLM) üretim ortamına almak, klasik bir mühendislik ödünleşim sorunudur. Bir yandan, token başına maliyeti düşürmek amacıyla mümkün olan en fazla isteği hizmet verebilmek için maksimum verimlilik istersiniz. Diğer yandan, sorunsuz bir kullanıcı deneyimi sağlamak için düşük gecikme süresine ihtiyaç duyarsınız. Sadece belirli bir sayıda isteği topladıktan sonra işleme başlayan statik toplu işleme (static batching), bu rekabetçi ihtiyaçları etkili bir şekilde dengelemekte genellikle başarısız olur. İşte burada dinamik toplu işleme (dynamic batching) öne çıkar.
Dinamik toplu işleme, istekleri anlık olarak akıllıca gruplandırır ve mevcut yüke ile istek özelliklerine adapte olur. Bu yazıda, dinamik toplu işlemenin mimarisini, ilgili kritik gecikme eşiklerini ve modern LLM sunum çerçevelerinde etkili stratejilerin nasıl uygulanacağını keşfedeceğiz.
Temel Zorluk: Toplu İşleme Gecikme Eğrisi
LLM'leri sunarken toplu işleme, hesaplama birimlerini meşgul tutarak donanım kullanımını (özellikle GPU'lar üzerinde) iyileştirir. Ancak, bir toplu işlemin dolmasını beklemek bekleme gecikmesi (waiting latency) oluşturur. Bir toplu işlemin boyut sınırına ulaşması için çok uzun beklerseniz, kuyruk uç gecikme metrikleriniz (p99) gökyüzüne tırmanır. Tersine, toplu işlemleri çok aceleyle işlerseniz verimlilikten ödün verirsiniz.
Dinamik toplu işlemenin amacı, toplu işleme başka bir istek eklemenin sağladığı marjinal verimlilik kazanımı ile o toplu işleme dahil tüm isteklerin marjinal gecikme artışı arasında denge kuran "ideal nokta"yı bulmaktır.
Bir Dinamik Toplu İşleyicinin Temel Bileşenleri
Güçlü bir dinamik toplu işleme sistemi genellikle üç ana bileşenden oluşur: bir istek kuyruğu, bir zamanlayıcı (scheduler) ve bir gecikme kısıt yöneticisi.
- Kuyruk: Gelen çıkarım (inference) isteklerini tutar. Hafif ve hızlı olmalıdır; genellikle bir öncelik kuyruğu veya basit bir FIFO (ilk giren ilk çıkar) arabelleği kullanılarak uygulanır.
- Zamanlayıcı: Bir sonraki toplu işleme hangi isteklerin dahil edileceğine karar verir. Gelişmiş zamanlayıcılar, daha kısa istekleri veya yüksek öncelikli kullanıcıları önceliklendirebilir.
- Gecikme Yöneticisi: "Durdurma" koşulunu belirler. Bir istek çok uzun süre beklemişse, toplu işleme tam olmasa bile bu isteği bir sonraki toplu işleme zorla dahil etmesini sağlar.
Uygulama Stratejisi: Zaman Aşımı Tabanlı Toplu İşleme
En yaygın ve etkili strateji, zaman aşımı tabanlı toplu işlemedir. Sistem, bir toplu işlemin maksimum boyuta ($N_{max}$) ulaşmasını veya en eski isteğin maksimum bekleme süresini ($T_{max}$) aşmasını bekler; hangisi önce olursa o gerçekleşir.
Bu mantığı gösteren, basitleştirilmiş bir kavramsal Python uygulaması aşağıdadır:
class DynamicBatcher:
def __init__(self, max_batch_size=32, max_wait_time_ms=50):
self.max_batch_size = max_batch_size
self.max_wait_time_ms = max_wait_time_ms
self.request_queue = []
def add_request(self, request):
self.request_queue.append(request)
def get_next_batch(self):
batch = []
if not self.request_queue:
return batch
# FIFO önceliğini işlemek için varış zamanına göre sırala
self.request_queue.sort(key=lambda x: x.arrival_timestamp)
start_time = self.request_queue[0].arrival_timestamp
for request in self.request_queue:
# Gecikme kısıtını kontrol et
current_wait = (now() - request.arrival_timestamp)
if current_wait > self.max_wait_time_ms:
break
# Boyut kısıtını kontrol et
if len(batch) >= self.max_batch_size:
break
batch.append(request)
# İşlenen istekleri kuyruktan kaldır
# (Uygulama detayları uzunluk nedeniyle atlanmıştır)
return batch
Gelişmiş Optimizasyon: Spekülatif Çıkarım ve KV Önbelleği Yönetimi
Toplu işleme girdi işlemini verimli bir şekilde ele alırken, çıkarım (decoding) aşaması genellikle darboğaz oluşturur. Çeşitli prompt uzunlukları toplu işleme yapıldığında, GPU'nun çıkarım aşamasındaki boşta kalma süresi artar. Gelişmiş sistemler artık dinamik toplu işlemeyi spekülatif çıkarım (speculative decoding) ile birleştirir; burada daha küçük bir "taslak" model, büyük modelin doğrulaması için tokenler önerir. Bu, sıralı çıkarım adımlarının sayısını azaltarak dinamik toplu işleyicinin, sıkı gecikme kısıtlamalarına rağmen bile yüksek verimliliği korumasını sağlar.
Sonuç
Dinamik toplu işleme sadece bir özellik değil; ölçeklenebilir LLM altyapısı için bir zorunluluktur. Maksimum toplu işleme boyutu ve maksimum bekleme süresini dikkatle ayarlayarak mühendisler, sunum altyapılarını belirli Hizmet Seviyesi Hedeflerine (SLO) göre özelleştirebilir. İster 100 ms'nin altında gecikme gerektiren bir sohbet botu sunuyor olun, ister verimliliğin kral olduğu arka plan özetleme hizmeti sunuyor olun; toplu işleme ile gecikme arasındaki etkileşimi anlamak, başarılı bir dağıtım için anahtardır.