Kurum İçi LLM Dağıtımları için Kapasite Planlama: Modelleri Donanıma Boyutlandırmak

LLM kapasite planlaması neden farklıdır?

Klasik kurumsal kapasite planlaması CPU, bellek ve IOPS ile başlar. LLM servisi ise GPU belleği, token verimi ve kuyruk gecikmesi ile başlar ve bu üç büyüklüğün arasındaki ilişki çok daha az sezgiseldir. Toplu iş yüklerinde etkileyici sonuç veren bir küme, yirmi eşzamanlı sohbet oturumu altında çökebilir; iyi parti (batching) yapılandırılmış mütevazı bir model, kötü yapılandırılmış donanımda çok daha büyük bir modeli geride bırakabilir. Kurum içi LLM'ler için kapasite planlaması bir hesap tablosu değil, küçük bir mühendislik araştırmasıdır.

Bu rehberin amacı pratik bir işlem sırası sunmaktır: iş yükü şeklini tanımlayın, bellek ve verim bütçelerini çıkarın, eşzamanlılığı boyutlandırın ve büyümeyi planlayın. Hiçbiri egzotik araç gerektirmez. Gereken şey, model kartının pazarladığı iş yükünü değil, gerçekten sahip olduğunuz iş yükünü ölçme disiplinidir.

Model boyutundan önce iş yükü şekliyle başlayın

GPU seçmeden önce iş yükünü tarif edin. En kritik değişkenler şunlardır:

• İstek karışımı: etkileşimli sohbet, toplu doküman işleme, ajan araç döngüleri ve RAG cevap üretimi çok farklı davranır. Hepsine hizmet eden tek bir küme mümkündür ama açık önceliklendirme gerekir.

• Girdi ve çıktı token dağılımları: istem uzunluğunun ve yanıt uzunluğunun ortalaması ile p95'i. RAG iş yükleri genellikle uzun girdi ve kısa çıktıya, ajan iş yükleri ise tersine sahiptir.

• Eşzamanlılık profili: pik eşzamanlı aktif oturum sayısı, geliş paterni ve isteklerin etkileşimli (gecikme duyarlı) mı yoksa asenkron (verim duyarlı) mı olduğu.

• Kalite tabanı: her akış için kabul edilebilir en küçük model. Her iş 70B sınıfı model gerektirmez; pek çok doküman işi, alan farkında istemlerle 7B-14B modellerle çözülür.

Bunları — iki haftalık bir günlükleme çalışmasından çıkan kabaca rakamlar bile olsa — sayılar hâline getirmek sonraki her kararı değiştirir. Sağlayıcılar sizi kendi benchmark'larına göre boyutlandırır; faturayı gerçekten belirleyen ise kendi iş yükü şeklinizdir.

GPU belleği: model ağırlıkları bütçenin yalnızca bir parçasıdır

Yaygın bir boyutlandırma hatası yalnızca model ağırlıklarını saymaktır. Cihaz belleği şunları tutmak zorundadır:

• Model ağırlıkları, seçilen hassasiyette (FP16, BF16, FP8 veya nicemli INT8/INT4).

• Uzun bağlamlı iş yüklerinde sıklıkla belleğe hakim olan, dizi uzunluğu ve eşzamanlılıkla doğrusal büyüyen KV önbelleği.

• İstek başına daha küçük ama geniş parti boyutlarında hâlâ anlamlı olan aktivasyon belleği.

• Servis çerçevesinin kendi çalışma zamanı yükü — vLLM, TGI, SGLang ve TensorRT-LLM her biri kendi defter tutmasını taşır.

Pratikte sohbet ve ajan iş yüklerinde KV önbelleğinin bağlayıcı kısıt hâline geldiğini bekleyin. Sayfalı KV önbelleğini açmak (vLLM'in yaptığı gibi), KV önbelleğini nicemlemek ve her akış için maksimum bağlam uzunluğunu sınırlamak elinizdeki kaldıraçlardır. Hassasiyeti bilinçli seçin: FP8 veya iyi kalibre edilmiş INT8 sıklıkla kaliteyi korur ve FP16'ya göre bellek baskısını yaklaşık yarıya indirir.

Her zaman çalışma payı bırakın. Belleğinin yüzde 95'inde çalışan bir GPU'nun ara sıra gelen uzun bir istem ya da spekülatif kod çözme taslak modeli için yeri yoktur. Normal varyansın gece 2'de sizi uyandırmaması için kalıcı durumda yüzde 70-80 bellek kullanımını hedefleyin.

Verim, gecikme ve kuyruğun tiranlığı

Manşet verim rakamları (parti 64'te saniyede token) nadiren üretim rakamlarıyla (patlamalı gelişlerde parti 3'te saniyede token) eşleşir. Etkileşimli iş yüklerinde algılanan kaliteyi ilk token süresi ve tokenlar arası gecikme belirler; toplu iş yüklerinde ise toplam saniyede token önemlidir.

Büyük etki yaratan iki yapılandırma seçeneği:

• Sürekli parti (continuous batching): modern servis motorları token düzeyinde dinamik parti yapar. Doğru yapılandırıldığında etkileşimli gecikmeye zarar vermeden yararlı verimi statik partiye göre birkaç kat artırabilir.

• Spekülatif kod çözme: küçük bir taslak model tokenlar önerir, ana model bunları paralel olarak doğrular. Uygulanabilir olduğunda gecikmeyi anlamlı biçimde azaltır; kısa çıktılı etkileşimli trafikte özellikle işe yarar.

Gerçekçi eşzamanlılık altında hem ortalama hem p95 gecikmeyi ölçün. Güçlü ortalama ama çirkin kuyruk performansına sahip bir yapı, tam da transkriptleri vaka çalışmasına dönüşen kullanıcılardan destek kaydı üretir. Kapasite planlaması ortalamaya değil, kuyruğa göre boyutlandırılmalıdır.

Eşzamanlılık, izolasyon ve filo şekli

GPU başına bütçeler netleştikten sonra küme şekli eşzamanlılık hedeflerinden çıkar. Birkaç pratik kural:

• Etkileşimli trafik için birkaç çok büyük yerine birden fazla küçük düğüm tercih edin. Filo çapında arıza alanları daha küçük olur ve sırayla güncellemeler kapasitenin orantısız bir kısmını karartmaz.

• Tek GPU belleğini aşan çok büyük modeller için tensor veya pipeline paralelliği kaçınılmazdır. Rahatça sığan en küçük paralellik derecesini seçin; her ekstra parça, ağ bağımlılığı ve arıza yüzeyi ekler.

• Toplu ve etkileşimli iş yüklerini zamanlayıcı düzeyinde izole edin. Sabah 10'da gelen büyük bir toplu iş, bir yöneticinin sohbet isteğinin ilk token'ını geciktirmemeli.

• Değerlendirme, canary ve kırmızı takım trafiği için küçük, ayrı bir havuz tutun. Bu amaçlarla üretim GPU'larını paylaşmak hem gürültülü benchmark'lar hem de mutsuz kullanıcılar üretir.

Her akışın eşit şartlarda yarıştığı tekçe bir küme yerine; farklı kuyruklarla, farklı nicemleme veya model seçimleriyle desteklenen servis sınıfları düşünün.

Büyüme ve bilinmezlikler için planlama

Kurum içi donanım tedariği çeyreklerle, LLM benimsenmesi ise haftalarla işler. Erken talep sıçramalarının acil satın alma gerektirmemesi için platformu bu beklentiyle tasarlayın. Yararlı kaldıraçlar:

• Nicemleme katmanları: aynı modeli farklı servis seviyelerinde FP16 veya INT8 olarak sunabilme yeteneği, baskı altında tedarik döngüsü olmadan kapasite geri kazandırır.

• Model kaskadları: rutin işi küçük modellere yönlendirin, yalnızca gerektiğinde büyük modellere yükseltin. Çoğu istek rutin olduğunda — kurumsal iş yüklerinin tipik durumu — kaskadlar etkin kapasiteyi dramatik biçimde artırır.

• Hibrit taşma: iç kapasite doyduğunda hassas olmayan trafik için güvenilen bir dış sağlayıcıya patlamaya olanak tanıyan, önceden onaylı ve veri sınıflandırmalı bir yol. Burada darboğaz genellikle teknoloji değil, yönetişimdir.

• Rezervasyon ve geri ödeme (chargeback): kapasiteyi iş sahiplerine görünür kılın ki büyüme konuşmaları olaylardan önce yapılsın. Paylaşımlı platformlarda zaten kurulu GPU kota ve chargeback kalıplarıyla hizalayın.

Planı çeyrek bazında yeniden gözden geçirin. Yeni modeller, yeni servis özellikleri ve yeni iş yükleri yıllık planlama döngülerinin varsaydığından daha hızlı gelir; her çeyrek kapasite matematiğini yeniden çalıştıran ekipler hem aşırı provizyondan hem de alarm yükseltmelerinden kaçınır.

Hepsini bir araya getirmek

Sağlam bir kurum içi LLM kapasite planlaması donanım özelliklerinden değil, iş yükü şeklinden başlar. Oradan ağırlıklar, KV önbellek, aktivasyonlar ve çalışma zamanı yükü arasında bilinçli pay ile GPU belleği bütçelenir. Verim ve gecikme gerçekçi eşzamanlılık altında ölçülür; sürekli parti ve spekülatif kod çözme birinci sınıf araçlar olarak değerlendirilir. Eşzamanlılık hedefleri filo şeklini, izolasyonu ve servis sınıflarını belirler. Son olarak nicemleme katmanları, kaskadlar, hibrit taşma ve görünür chargeback platformu bilinmezliğe karşı korur. Bunu iyi yapan ekipler kapasiteyi halka açık platformlarda nadiren tartışır; yapmayanlar genellikle olay sonrası incelemelerde tartışır.

Öne çıkan görsel: Dimitris Chapsoulas tarafından Unsplash'te.