Yazı
Şirket İçi LLM Sunumunda GPU Bellek Yönetimi ve KV Önbellek Optimizasyonu
Büyük dil modellerini şirket içinde sunarken GPU belleğini yönetmek ve KV önbellek tahsisini optimize etmek için pratik stratejiler: sayfalı dikkat mekanizmasından dinamik bellek havuzlamaya kadar.
Şirket içi LLM sunumunda GPU belleği neden darboğazdır?
Büyük dil modellerini şirket içinde sunarken GPU belleği neredeyse her zaman kısıtlayıcı kaynaktır. Talep üzerine ek GPU örneği oluşturabileceğiniz bulut ortamlarının aksine, şirket içi dağıtımlar sabit bir bellek bütçesiyle çalışır. Tek bir NVIDIA A100, 80 GB HBM2e bellek sunar. FP16 formatında 13B parametreli bir model yalnızca ağırlıklar için yaklaşık 26 GB kaplar ve geriye aktivasyonlar, KV önbelleği, framework ek yükü ve CUDA bağlamı için 54 GB kalır.
KV önbelleği, işlerin ilginçleştiği noktadır. Otoregresif üretim sırasında model, dizideki her token için her dikkat katmanındaki anahtar ve değer tensörlerini depolar. 40 dikkat katmanlı ve 5120 gizli boyutlu 13B bir model için KV önbelleğindeki her token FP16'da yaklaşık 800 KB tüketir. Her biri 2048 token uzunluğunda dizi üreten 32 eşzamanlı istek grubu, yalnızca KV önbelleği için 50 GB'ın üzerinde bellek gerektirir. Bu, KV önbelleğinin sıklıkla model ağırlıklarından daha fazla bellek tükettiği anlamına gelir.
Kötü bellek yönetimi iki sonuca yol açar ve her ikisi de üretimde kabul edilemez: ya yetersiz bellek hatalarından kaçınmak için eşzamanlılığı ve verimi sınırlarsınız, ya da tüm sunum sürecini çökerten öngörülemeyen OOM çökmelerıyla karşılaşırsınız. Etkili GPU bellek yönetimi, bir araştırma prototipini üretim düzeyinde şirket içi LLM dağıtımından ayıran şeydir.
KV önbellek bellek dinamiklerini anlamak
KV önbelleği, her istek üretim sürecinde ilerledikçe dinamik olarak büyür. Çıkarımın başlangıcında, 500 tokenlik bir komut isteği olan bir istek, tüm dikkat katmanları boyunca bu 500 token için KV önbellek girdileri gerektirir. Model her yeni token ürettikçe önbellek, katman başına bir girdi büyür. Bu, geleneksel ML modellerinin sunumundan temelden farklı bir bellek tahsis modeli oluşturur; çünkü geleneksel modellerde bellek kullanımı öngörülebilir ve statiktir.
Zorluk, değişken dizi uzunlukları tarafından daha da artırılır. Tipik bir kurumsal dağıtımda istek uzunlukları büyük ölçüde değişir. Bir sınıflandırma görevi toplamda 100 token kullanabilirken, bir belge özetleme isteği 8192 token veya daha fazlasına ulaşabilir. Her istek için mümkün olan maksimum dizi uzunluğu kadar KV önbellek belleği önceden tahsis ederseniz, kısa isteklerde muazzam miktarda bellek israf edersiniz. Muhafazakar tahsis yaparsanız, uzun istekler üretim ortasında başarısız olur.
Ayrıca KV önbellek belleği, model ağırlık belleğiyle değiştirilebilir değildir. Model ağırlıkları bir kez yüklenir ve tüm istekler arasında paylaşılır. KV önbelleği istek başınadır ve istekler geldikçe ve tamamlandıkça tahsis edilip serbest bırakılmalıdır. Bu, KV önbellek yönetimini işletim sistemlerindeki yığın yönetimine benzer bir dinamik bellek tahsis problemi haline getirir; ancak GPU bellek tahsisi ve serbest bırakmanın CPU bellek işlemlerinden önemli ölçüde daha pahalı olduğu ek kısıtlamasıyla.
Bu dinamikleri anlamak, doğru optimizasyon stratejisini seçmenin ön koşuludur. Aşağıdaki teknikler bu sorunun farklı yönlerini ele alır: token başına bellek tüketimini azaltmak, tahsis verimliliğini artırmak ve önbelleğe alınmış hesaplamaların daha akıllı paylaşımını sağlamak.
Sayfalı dikkat: bellek parçalanmasını çözmek
KV önbellek yönetimindeki en önemli ilerleme, vLLM projesi tarafından tanıtılan sayfalı dikkat (paged attention) mekanizmasıdır. Temel fikir doğrudan işletim sistemi sanal belleğinden ödünç alınmıştır: her isteğin KV önbelleği için bitişik bellek blokları tahsis etmek yerine, GPU belleğini sabit boyutlu sayfalara (tipik olarak sayfa başına 16 token) bölün ve her isteğin mantıksal KV önbelleğini GPU belleğinin herhangi bir yerinde dağılmış olabilecek fiziksel sayfalara eşleyin.
Sayfalı dikkat olmadan, KV önbellek tahsisi dış parçalanmadan muzdariptir. GPU belleğini uzun bir şerit olarak düşünün: istekler geldikçe ve tamamlandıkça çeşitli boyutlarda boşluklar bırakırlar. 4 GB bitişik KV önbelleğine ihtiyaç duyan yeni bir istek, 6 GB boş olmasına rağmen başarısız olabilir; çünkü boş bellek 500 MB'lık parçalara dağılmıştır. Sayfalı dikkat bu sorunu tamamen ortadan kaldırır.
Pratik etki önemlidir. Sayfalı dikkat, iç parçalanmadan kaynaklanan KV önbellek bellek israfını naif bitişik tahsise kıyasla %95'e kadar azaltır. Bu doğrudan daha yüksek verime dönüşür: aynı GPU, bellek daha verimli kullanıldığı için 2 ila 4 kat daha fazla eşzamanlı istek sunabilir.
Şirket içi dağıtımlar için sayfalı dikkati uygulamak basittir. vLLM, TensorRT-LLM ve SGLang gibi frameworkler sayfalı dikkati doğal olarak destekler. Bu frameworkleri yapılandırırken ayarlanacak temel parametreler blok boyutu (sayfa başına token sayısı) ve GPU bellek kullanım oranıdır (KV önbelleğine ayrılan GPU belleğinin model ağırlıkları ve ek yüke kıyasla oranı). 0,85 ila 0,90 arasında bir kullanım oranı iyi bir başlangıç noktasıdır.
KV önbellek sıkıştırma ve nicemleme
Mükemmel bellek yönetimiyle bile, KV önbelleğinin ham boyutu verimi sınırlar. KV önbelleğini sıkıştırmak, aynı GPU belleğine daha fazla eşzamanlı istek sığdırmanızı sağlar. En pratik yaklaşım KV önbellek nicemleme'dir: anahtar ve değer tensörlerini daha düşük hassasiyet formatlarında depolamak.
KV önbelleğini FP16 yerine FP8 veya INT8 formatında depolamak, çıktı kalitesi üzerinde minimum etkiyle bellek tüketimini yarıya indirir. Birden fazla model ailesi üzerindeki ampirik değerlendirmeler, 8 bite KV önbellek nicemlemenin çoğu görevde FP16 çıkarımından neredeyse ayırt edilemez çıktılar ürettiğini göstermektedir.
Daha agresif bir teknik olan gruplu sorgu dikkati (GQA), sonradan uygulanan bir optimizasyon değil, mimari bir özelliktir. Llama 3 ve Mistral gibi GQA ile eğitilmiş modeller, sorgu başlıklarından daha az anahtar-değer başlığı kullanır ve standart çok başlıklı dikkate kıyasla KV önbellek boyutunu 4 ila 8 kat azaltır. Şirket içi dağıtım için model seçerken, GQA etkinleştirilmiş mimarilere öncelik vermek diğer optimizasyonlarla birleşen önemli bir bellek avantajı sağlar.
Maksimum verim gerektiren dağıtımlar için, buna tolerans gösterebilecek kullanım durumlarında kayan pencere dikkati'ni düşünün. Tüm bağlam için KV çiftlerini önbelleğe almak yerine, yalnızca en son N token önbelleğe alınır. Bu, dizi uzunluğundan bağımsız olarak KV önbellek bellek kullanımını sınırlar ve eski bağlamın daha az ilgili hale geldiği akış veya konuşma iş yükleri için özellikle kullanışlıdır.
Dinamik bellek havuzlama ve öncelik stratejileri
Çok kiracılı bir şirket içi ortamda GPU belleği, farklı bellek gereksinimlerine sahip çeşitli iş yükleri arasında paylaşılmalıdır. Dinamik bellek havuzu, tüm etkin istekler arasında GPU belleğini yöneten ve bellek baskısını ele almak için politikalar uygulayan merkezi bir tahsis edici sağlar.
Bellek havuzu rezervasyon ve limit politikaları uygulamalıdır. Her kiracı veya iş yükü sınıfına minimum garantili bellek tahsisi (rezervasyon) ve maksimum limit atanır. Rezervasyonlar, yüksek öncelikli iş yüklerinin temel çalışma için her zaman yeterli belleğe sahip olmasını sağlar. Limitler, herhangi bir tek iş yükünün GPU belleğini tekelleştirmesini ve diğer kiracıları aç bırakmasını engeller.
Bellek baskısı mevcut kapasiteyi aştığında, sistem hangi isteklerin önceleneceğine karar vermelidir. İki temel önceleme stratejisi takas ve yeniden hesaplama'dır. Takas, bir isteğin KV önbelleğini GPU'dan CPU belleğine aktarır ve daha sonra devam ettirmek için önbelleğe alınmış durumu korur. Yeniden hesaplama, KV önbelleğini basitçe atar ve istek yeniden başlatıldığında komutu yeniden işler.
Pratik bir önceleme politikası, istek önceliğini, önceleme maliyetini (KV önbellek boyutu ve üretim sürecindeki ilerlemeyle orantılı) ve GPU belleğinin ne zaman müsait olacağını değerlendirir. Maliyet ağırlıklı öncelik tabanlı önceleme iyi çalışır: eşit öncelikli istekler arasında, KV önbelleğini geri yüklemenin en ucuz olduğu isteği önceleyin.
vLLM dağıtımları için --preemption-mode bayrağı bu davranışı kontrol eder. swap modu KV önbelleğini CPU belleğine aktarır, recompute modu ise atar ve yeniden işler. Sunum metriklerinizde önceleme sıklığını izleyin; yüksek bir önceleme oranı daha fazla GPU belleğine, daha az eşzamanlı isteğe veya daha kısa maksimum dizi uzunluklarına ihtiyaç duyduğunuzu gösterir.
KV önbelleği için izleme ve kapasite planlaması
Etkili GPU bellek yönetimi sürekli izleme gerektirir. Takip edilmesi gereken temel metrikler şunlardır: KV önbellek kullanımı (kullanımdaki tahsis edilmiş KV önbellek sayfalarının yüzdesi), önceleme oranı (dakika başına öncelenen istekler), bellek parçalanma oranı (boş sayfalar ile en büyük bitişik boş blok karşılaştırması) ve tepe bellek filigranı (belirli bir pencerede gözlemlenen en yüksek bellek kullanımı).
Bu metrikleri mevcut izleme yığınınıza (Prometheus, Grafana veya eşdeğeri) aktarın. Uyarılar için %85 KV önbellek kullanımında ve kritik uyarılar için %95'te alarmlar ayarlayın. Uyarı eşiği, ekibinize bir iş yükü değişikliğinin artan bellek baskısını yönlendirip yönlendirmediğini araştırma zamanı verir.
Kapasite planlaması için, haftalık desenleri yakalamak üzere iş yükünüzün bellek gereksinimlerini en az iki hafta boyunca profilleyin. P95 ve P99 tepe KV önbellek kullanımını hesaplayın ve GPU belleğini %15 pay ile P99 tepeyi karşılayacak şekilde tahsis edin. Bu pay, trafik artışlarını emer ve bellek baskısının öncelemeyi tetiklediği, öncelemenin yeniden denemelere neden olduğu ve yeniden denemelerin bellek baskısını daha da artırdığı çığ etkisi başarısızlıkları önler.
Son olarak, model seçimlerini ve sunum yapılandırmalarını değerlendirirken GPU belleğinin toplam maliyetini göz önünde bulundurun. %10 daha doğru olan ancak istek başına %50 daha fazla KV önbelleği gerektiren bir model, şirket içi dağıtımınız için doğru seçim olmayabilir. Model seçimi, nicemleme tercihleri ve eşzamanlılık hedeflerini somut GPU donanım gereksinimlerine eşleyen kapasite modelleri çalıştırın.
Öne çıkan görsel: alireza edalati tarafından Unsplash'ta paylaşılmıştır.
SysArt AI
Bu YZ konusuna devam edin
Aynı karar alanını destekleyen ticari sayfalara ve konu arşivine geçmek için bu bağlantıları kullanın.
Okuyucuların sık sorduğu sorular
Model ağırlıkları yerine KV önbellek neden GPU bellek kullanımına hâkim olur?
Model ağırlıkları yüklendikten sonra sabittir; KV önbellek ise toplu boyut, dizi uzunluğu ve dikkat katmanı sayısıyla doğrusal büyür. 13B'lik bir model yaklaşık 26 GB ağırlık tutarken 4K bağlamda 16 eş zamanlı kullanıcı için onlarca GB ek bellek harcanır. 80 GB'lık bir A100'da etkin verimi sınırlayan ağırlıklar değil önbellektir.
Sayfalı dikkat mekanizması, statik KV önbellek tahsisine göre ne zaman tercih edilmelidir?
Sayfalı dikkat (vLLM'deki uygulamada olduğu gibi) istek uzunluklarının ve geliş sürelerinin öngörülemez olduğu durumlarda parçalanmayı ortadan kaldırır ve daha yoğun toplu paketlemeye olanak verir. Statik tahsis edici, sabit uzunluklu ve homojen iş yükleri için (çevrimdışı toplu özetleme gibi) marjinal ölçüde hızlı olabilir; ancak çoğu üretim trafiği değişkendir ve sayfalama avantajından yararlanır.
FP8 veya INT8 nicemleme üretim için güvenli midir?
Belirli görevlerde doğrulandıktan sonra çoğu kurumsal kullanım için evet. FP8 KV önbellek, özetleme, sınıflandırma ve çıkarım gibi görevlerde belleği yaklaşık yüzde 50 azaltırken kalite kaybı ihmal edilebilir düzeydedir. INT8 ağırlık nicemlemesi benzer bellek tasarrufu sağlar; muhakeme yoğun görevlerde küçük bir doğruluk farkı oluşur. Üretim trafiğine geçmeden önce karşılaştırmalı bir değerlendirme yapın.
GPU belleğinin verim tavanı haline geldiğini hangi ölçütler gösterir?
Yük altında p95 ilk-token süresi yükselirken GPU kullanımı yüzde 80'in altında kalıyorsa, vLLM kayıtlarında sık KV önbellek tahliyeleri görülüyorsa ve istek hızıyla bağdaşmayan kuyruk derinliği artışları varsa zamanlayıcı boş bellek bloğuna aç demektir; sınırlayıcı faktör hesaplama değil bellektir.