Kurum İçinde LLM Hizmet Verirken Toplu Çıkarım Stratejileri

Kurum içinde toplu işleme neden daha kritik?

Büyük dil modellerini bulut API’si üzerinden kullandığınızda toplu işleme arka planda yapılır. Sağlayıcı, istekler arasındaki boşta kalan GPU döngülerinin maliyetini üstlenir. Kurum içinde ise her boşta geçen milisaniye doğrudan maliyetinize yansır. Bir sonraki isteği beklerken 700 watt çeken tek bir H100 GPU’su saf israftır.

Toplu çıkarımda birden fazla gelen istek bir arada işlenir; GPU bunları tek bir ileri geçişte yürütür. Hesap basittir: tek bir istek için saniyede 15 token üreten bir model, genellikle 8 eşzamanlı isteği her biri için saniyede 12 token hızında sunabilir ve istek başına gecikmeyi fazla büyütmeden toplam iş hacmini yaklaşık 6 kat artırır. Asıl mesele, iş yükünüze uygun toplu işleme stratejisini seçmektir.

Statik toplu işleme: basit ama sınırlayıcı

Statik toplu işlemede sabit sayıda istek toplanır ve birlikte işlenir. Sunucu, N istek gelene veya zaman aşımı dolana kadar bekler. En basit yaklaşımdır; istek uzunlukları birbirine yakınsa ve varış hızları tahmin edilebilirse iyi sonuç verir.

Sorun, uzunluğu değişen girdi ve çıktılarda ortaya çıkar. Statik bir batch’te, herhangi bir yanıt dönmeden önce tüm isteklerin en uzun dizinin bitmesini beklemek gerekir. Kısa bir özet görevi, aynı batch’teki uzun bir kod üretme isteği yüzünden beklemeye alınır. Kullanıcıların akışlı yanıt beklediği etkileşimli uygulamalarda bu, kabul edilemez kuyruk gecikmesi yaratır.

Statik toplu işleme, gecikmenin önemli olmadığı ve yalnızca iş hacmini maksimize etmek istediğiniz çevrimdışı toplu işler için hâlâ uygundur; örneğin geceleri yapılan belge sınıflandırma veya gömme vektörü üretimi.

Sürekli toplu işleme: üretim ortamının standardı

Sürekli toplu işleme, yineleme düzeyinde toplu işleme veya işlem sırasında batch’e ekleme olarak da anılır ve değişken uzunluk sorununu çözer. Tüm batch’in bitmesini beklemek yerine, zamanlayıcı her kod çözme adımında batch’e yeni istekler ekler. Batch’teki bir istek tamamlandığında (dizi sonu token’ını ürettiğinde), yeri bekleyen bir isteğe hemen açılır.

vLLM, TensorRT-LLM ve text-generation-inference gibi çıkarım çatıları sürekli toplu işlemeyi destekler. Pratikte bu, istek uzunlukları çok farklı olsa bile GPU’nun dolu kalması demektir. 20 token çıktıya ihtiyaç duyan bir istek batch’ten çabuk çıkar ve yeri bir yineleme döngüsü içinde doldurulur.

Kurum içinde sürekli toplu işlemeyi ayarlarken üç parametreye odaklanın:

Maksimum batch boyutu — Bir batch’teki eşzamanlı dizi sayısının üst sınırı. Model ağırlıkları ve KV önbelleği düşünüldükten sonra GPU belleğinize göre ayarlayın.

Maksimum bekleme süresi — Bir isteğin, sonraki batch yinelemesine eklenmeden önce kuyrukta ne kadar bekleyebileceği. Gerçek zamanlı uygulamalarda bunu 100 ms’nin altında tutun.

Ön alma ilkesi — Batch dolduğunda ve daha yüksek öncelikli bir istek geldiğinde, çalışan bir isteği kesip yer vermeli misiniz? vLLM gibi çatılar, işi kaybetmeden öncelik tabanlı zamanlamaya izin vermek için CPU belleğine takas desteği sunar.

PagedAttention ve bellek açısından verimli KV önbellekleme

Batch boyutunu en çok sınırlayan şey KV önbellek belleğidir. Her aktif dizi, uzunlukla birlikte büyüyen bir anahtar-değer önbelleği tutar. Geleneksel uygulamalar her dizi için olası en büyük önbelleği baştan ayırır; kısa kalacak diziler için bellek boşa gider.

vLLM projesiyle tanınan PagedAttention, işletim sistemindeki sanal bellek sayfalama fikrini KV önbelleğine uyarlar. Bitişik, baştan ayrılmış bloklar yerine önbellek, gerektikçe ayrılan sabit boyutlu sayfalara bölünür. Bu, iç parçalanmayı azaltır ve aynı donanımda kullanılabilir batch boyutunu 2–4 kat artırabilir.

Kurum içi kurulumlarda bu, GPU başına daha fazla eşzamanlı kullanıcıya hizmet vermek anlamına gelir. Mevcut sisteminiz geleneksel KV önbellekleme ile 16 eşzamanlı diziyi kaldırıyorsa, PagedAttention ortalama dizi uzunluğu dağılımınıza bağlı olarak bunu 40–50 diziye çıkarabilir.

Öncelik kuyruğu ve katmanlı hizmet

Tüm çıkarım istekleri aynı değerde değildir. Gerçek zamanlı özet üreten bir yönetici paneli, saniyenin altında yanıt süresi ister. Binlerce destek kaydını işleyen gece toplu işi dakikalarca kuyrukta beklemeyi tolere edebilir. GPU kapasitesi sabit olduğunda kurum içinde iyi tasarlanmış bir öncelik düzeni şarttır.

En az iki katman kullanın: sıkı gecikme SLO’ları ve ayrılmış GPU kapasitesi olan bir gerçek zamanlı katman ve kalan kapasiteyi kullanan bir toplu iş katmanı. Toplu iş katmanı doğal bir tampon görevi görür; gerçek zamanlı yük düşükken genişler, yoğun saatlerde daralır.

Gelen istekleri yönlendirmek için istek meta verilerini (kaynak uygulama, kullanıcı seviyesi, görev türü) kullanın. Envoy gibi bir ters vekil sunucu veya buna özel bir çıkarım ağ geçidi bu yönlendirmeyi yönetebilir.

Toplu işleme performansını ölçme ve ince ayar

Toplu işleme için önemli ölçümler ilk token süresi (TTFT), token’lar arası gecikme (ITL), iş hacmi (tüm isteklerde saniye başına token) ve GPU kullanım oranıdır. Bunlar çoğu zaman birbiriyle çelişir: iş hacmini maksimize etmek, isteklerin batch oluşmasını beklemesine yol açtığı için TTFT’yi artırabilir.

Gerçek iş yükünüzü profillemeyle başlayın. Girdi ve çıktı uzunlukları, varış zaman damgaları ve kaynak uygulamalar dahil yaklaşık bir haftalık üretim istek günlüklerini toplayın. Bu trafiği farklı toplu işleme ayarlarıyla çıkarım altyapınızda yeniden oynatın.

İki sık görülen soruna dikkat edin. Birincisi, batch’in dolmaması: düşük trafikte istekler hiç dolmayan bir batch için bekler. Bunu agresif zaman aşımı veya yoğun olmayan saatlerde en az 1’lik batch boyutu ile giderin. İkincisi, bellek baskısı zincirleme yavaşlatması: yüksek yükte büyük batch’ler KV önbellek belleğini tüketir ve her şeyi yavaşlatan zorunlu ön almalara yol açar.

Toplu işleme ayarı “bir kez yap, unut” türü değildir. Model karışımınız, devreye giren uygulamalar ve trafik örüntüsü değiştikçe ayarları üç ayda bir gözden geçirin. Aynı donanımda iyi ve kötü ayarlanmış toplu işleme arasındaki fark, etkin iş hacminde kolayca 3–5 kat olabilir.

Görsel: CoolIT Systems, Unsplash.