LLM Sunumu ve Dağıtımı için En İyi Bulut GPU'ları

Kiralanan bir GPU’dan LLM servisinin aslında ne talep ettiğine dair

Büyük bir dil modelini servis etmek, onu eğitmekten temelde farklı bir iş yüküdür. Eğitim, işlem hacmiyle sınırlıdır ve gecikmeye toleranslıdır; servis ise gecikmeye duyarlıdır, bellekle sınırlıdır ve ani yüklenmeler yaşar. Bir LLM’yi bir API arkasında dağıtmak için bir GPU kiraladığınızda, darboğaz nadiren ham FLOPS’tur. Asıl sorun, modelin ve onun KV önbelleğinin ne kadarını VRAM’de tutabildiğiniz, bu belleğin ne kadar hızlı veri akışı sağladığı ve kullanıcı başına saniyedeki token sayısı düşmeden kaç eşzamanlı isteği gruplayabildiğinizdir.

KV önbelleği, çoğu kişinin hafife aldığı kısımdır. Her aktif istek, bağlamı için dikkat anahtarlarını ve değerlerini depolar ve bu ayak izi, dizi uzunluğu ve eşzamanlı kullanıcı sayısıyla büyür. Boşta rahatça sığan bir model, uzun istemlerle gerçek trafik geldiğinde anında belleği tükenebilir. Bu yüzden servis dağıtımları genellikle sadece model ağırlıklarının önerdiğinden daha fazla VRAM boşluğuna ihtiyaç duyar.

GPU’yu modele göre nasıl boyutlandırmalı

Pratikte ilk soru, modelin tek bir GPU’ya sığıp sığmadığı ya da birkaç GPU’ya bölünmesi gerekip gerekmediğidir. Yukarıdaki karşılaştırmayı modelinizle karşılaştırırken şu faktörleri değerlendirin:

• VRAM kapasitesi hangi modellerin sığabileceğini belirler. FP8 veya INT8 ile kuantize edilmiş 7B–13B model, tek bir orta seviye hızlandırıcıdan servis edilebilirken, BF16 formatındaki 70B model genellikle yüksek bellekli bir kart veya çoklu GPU düğümü gerektirir. Çok büyük sınır sınıfı modeller ise etkili şekilde birden fazla üst düzey GPU’nun birbirine bağlanmasını zorunlu kılar.
• Bellek bant genişliği token üretim hızınızı belirler. Otoregresif kod çözme, üretilen her token için tüm ağırlıkları okur, bu yüzden veri merkezi kartlarında bulunan HBM sınıfı bellek, aynı model boyutundaki GDDR tabanlı tüketici kartlarından çok daha hızlı token üretir. Etkileşimli sohbet için bant genişliği genellikle hesaplamadan daha önemlidir.
• Desteklenen hassasiyetler modeli ne kadar agresif küçültebileceğinizi belirler. FP8 ve INT8 tensör desteği olan kartlar, servis yığını ve modelin kuantizasyon şeması uyumlu olduğu sürece, daha az VRAM ile daha büyük modelleri ve daha yüksek işlem hacmini desteklemenizi sağlar.
• Bağlantı altyapısı model birden fazla GPU’ya yayıldığında önem kazanır. Tensör paralel serviste her katmanda GPU’lar arasında aktivasyonlar değiş tokuş edilir, bu yüzden bir düğüm içindeki NVLink sınıfı bağlantılar, sadece PCIe bağlantılı konfigürasyonlara kıyasla anlamlı şekilde daha iyi gecikme sunar. Tek GPU dağıtımlarında bağlantı altyapısı önemsizdir.

Tek GPU mu yoksa çoklu GPU mu servis yapılmalı?

Modeliniz ve en yüksek KV önbelleği tek bir GPU’ya sığıyorsa, onu orada tutun. Tek GPU servisi, cihazlar arası iletişim yükünü tamamen ortadan kaldırır ve işletmesi daha basittir. Model gerçekten sığmadığında tensör paralelliğe veya çoklu düğüm servisine geçin, çünkü eklediğiniz her GPU senkronizasyon maliyeti getirir ve otomatik ölçeklendirmeyi karmaşıklaştırır. Çoklu GPU gerektiğinde, yukarıdaki listede yüksek bellekli kartları hızlı düğüm içi bağlantı ile eşleştiren örnekleri tercih edin; gevşek bağlı kartları birleştirmekten kaçının.

Eğitim için değil servis için önemli olan sağlayıcı özellikleri

Yonga dışında, sağlayıcının operasyonel modeli bir dağıtımın uygulanabilir olup olmadığını belirler. Yukarıdaki karşılaştırmayı eğitim çalışması yerine servis iş yükü için incelerken önceliklerinizi farklı belirleyin:

• Soğuk başlatma ve kurulum süresi birinci sınıf endişeler haline gelir. Trafik dalgalanmaları arasında sıfıra ölçeklenen bir servis uç noktası, her ölçeklendirmede soğuk başlatma maliyetini öder; bu yüzden hızlı sağlama ve imaj önbellekleme doğrudan kuyruk gecikmesini etkiler.
• Faturalandırma ayrıntısı ani trafik için ekonomiyi değiştirir. Saniye veya dakika bazlı faturalandırma, örnekleri açıp kapatan otomatik ölçeklendirme uç noktalarına uygundur; saatlik kaba faturalandırma bu modeli cezalandırır.
• Talep üzerine güvenilirlik, spot yerine genellikle doğru tercihtir. Kesintiye uğrayabilir veya spot örnekler eğitim ve toplu işler için mükemmeldir ancak kullanıcıya yönelik uç noktalar için risklidir; çünkü istek ortasında geri alınması canlı trafiği düşürür. Spot, etkileşimsiz toplu çıkarım için hâlâ iyi hizmet verir.
• Kalıcı depolama ve hızlı model yükleme yeniden başlatma sıkıntısını azaltır. Her yeniden başlatmada soğuk nesne depolamadan tekrar yüklenen çok gigabaytlık ağırlıklar dakikalarca kesinti ekler; önbelleğe alınmış veya bağlı hacimler bunu kısaltır.
• Ağ ve çıkış trafiği ölçeklendiğinde maliyeti etkiler. Yüksek bant genişlikli çıkarım çok fazla veri dışarı taşıyabilir; yüksek trafikli dağıtımlara başlamadan önce çıkış koşullarını kontrol edin.

Toplu mu yoksa gerçek zamanlı mı, ve maliyet nerede yoğunlaşır

Hangi moda optimize edeceğinize erken karar verin. Gerçek zamanlı etkileşimli servis düşük ilk token süresi ve kullanıcı başına sabit token oranlarını değerli kılar; bu da yüksek bant genişlikli bellek ve makul toplu boyutları destekler. Toplu veya çevrimdışı çıkarım toplam işlem hacmini önceler ve daha ucuz veya kesintiye uğrayabilir donanımlarda büyük toplu işlemler yapabilir; her istek gecikmesini feda ederek token başına maliyeti çok düşürür. Birçok ekip her ikisini de çalıştırır: canlı kullanıcılar için yanıt veren talep üzerine katman ve toplu üretim için spot destekli toplu katman.

Kiralanan maliyette, servis tüm spektrumda yer alır. Orta seviye bir kartta küçük kuantize model ucuz ve yaygınken; çoklu GPU yüksek bellekli düğümlerde sınır sınıfı modeller nadir, daha pahalı ve talep zirvelerinde bazen kapasite kısıtlıdır. Oranlar sürekli değiştiği ve bölge ile taahhütlere göre farklılık gösterdiği için, yukarıdaki canlı karşılaştırmayı sabit bir rakamdan ziyade gerçek kaynak olarak kabul edin; örnekleri sadece fiyat değil, VRAM, bant genişliği sınıfı, bağlantı altyapısı ve faturalandırma modeli açısından birlikte karşılaştırın.

Sıkça sorulan sorular

Bir LLM’yi servis etmek için ne kadar VRAM gerekir?

Seçtiğiniz hassasiyette model ağırlıkları için bütçe ayırın ve bağlam uzunluğu ile eşzamanlı kullanıcı sayısıyla büyüyen KV önbelleği için önemli bir boşluk bırakın. Kabaca rehber olarak, kuantize edilmiş küçük ve orta boy modeller tek bir orta seviye karttan servis edilirken, yüksek hassasiyette büyük modeller yüksek bellekli kart veya birkaç GPU gerektirir. Her zaman boşta değil, en yüksek eşzamanlılık için boyutlandırın.

Spot veya kesintiye uğrayabilir GPU’lar LLM servisi için uygun mu?

Kullanıcıya yönelik gerçek zamanlı uç noktalar için genellikle hayır, çünkü geri alma canlı istekleri düşürür ve soğuk yeniden başlatmalara zorlar. Spot örnekler, kesintiler sadece işlem hacmini geciktirdiği çevrimdışı veya toplu çıkarım için uygundur ve etkileşimli oturumu bozmaz. Birçok ekip canlı trafik için talep üzerine kapasite tutar ve toplu işler için spot kullanır.

Neden servis için bellek bant genişliği hesaplamadan daha önemli?

Token token kod çözme, üretilen her token için model ağırlıklarını bellekten okur; bu yüzden üretim hızı GPU’nun belleği ne kadar hızlı akıtmasına bağlıdır, en yüksek FLOPS’a değil. Bu nedenle HBM donanımlı veri merkezi kartları aynı modeli tutan tüketici kartlarından daha hızlı token üretir ve bant genişliği yukarıdaki karşılaştırmada önemli bir sütundur.

Tek GPU’da mı servis yapmalı yoksa birkaç GPU’ya mı bölmeli?

Model ve en yüksek KV önbelleği sığdığı sürece tek GPU kullanın; bu, cihazlar arası iletişimi önler ve ölçeklendirmeyi basitleştirir. Model gerçekten sığmadığında çoklu GPU tensör paralelliğine geçin ve geçerken yüksek bellekli kartları hızlı düğüm içi bağlantı ile birleştiren örnekleri tercih edin.