Mimari ve çalışma modeli
GPU kapasitesi üç ayrı bütçeden oluşur: model ağırlıkları, çalışma alanı ve aktif sequence'lerin KV cache'i. Parametre sayısı × bayt/hassasiyet yalnız ağırlığın alt sınırını verir. Tensor paralelliği ağırlığı bölebilir fakat iletişim, topology ve kopyalanan tamponlar ek yük getirir.
Kubernetes device plugin GPU'yu genişletilmiş kaynak olarak bildirir; scheduler bellek miktarını veya performans sınıfını kendiliğinden anlamaz. Node label/affinity, taint/toleration, topology, runtime class ve sağlık denetimiyle uygun yerleşim tanımlanır. Bir GPU'yu paylaşmak desteklenen MIG/time-slicing ve izolasyon özelliklerine göre açıkça tasarlanır.
Autoscaling yalnız CPU veya genel istek sayısıyla yapılırsa LLM kuyruğunu geç görür. Queue depth, bekleyen token, TTFT ve KV doluluğu birlikte izlenir. Yeni replikanın model indirme ve yükleme süresi dakikalar sürebileceğinden min replica, sıcak havuz veya model ön yükleme kararı SLO ile bağlanır.
- 1İstek/token talep modeli
- 2GPU bellek ve topology profili
- 3Kubernetes yerleşimi ve autoscaling
- 4SLO, maliyet ve arıza doğrulaması
Tasarım parametreleri
- Ağırlık belleği
- Örneğin 8 milyar parametre BF16'da teorik yaklaşık 16 GB; runtime ve KV payı ayrıca eklenir.
- KV bütçesi
- Katman, hidden size, context, veri tipi ve eşzamanlı sequence sayısıyla ölçün; motorun gerçek allocator metriğini kullanın.
- Topology
- Çoklu GPU'da NVLink/PCIe, NUMA ve NIC yakınlığını worker yerleşimiyle eşleyin.
- Başlatma süresi
- İmaj çekme, ağırlık indirme, doğrulama ve warmup sürelerini ayrı ölçüp scale-up eşiğine katın.
Hesap ve uygulama örneği
24 GB GPU'da 15 GB ağırlık ve 2 GB runtime ayrılırsa KV için 7 GB kalır. Laboratuvarda 8k context sequence başına 420 MB ölçülüyorsa bellek tavanı yaklaşık 16 sequence'dir; fragmentation ve güvenlik payıyla 12-13 eşzamanlı sequence hedeflenir.
Trafik 12 istek/s, ortalama servis 5 saniye ise Little yasası 60 aktif istek bekletir. Bir replika 12 sequence taşıyorsa en az beş etkin replika gerekir; N+1 toleransı ve bakım için altıncı replikaya yer ayrılır.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu
kubectl describe pod llm-worker-0
llm-capacity profile --context 1024,4096,8192 --concurrency 1,8,16Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Pod Pending kalıyor | GPU kaynağı, label/taint veya plugin sağlığı eşleşmiyor. | Node allocatable, pod events, device-plugin DaemonSet ve runtime class'ı kontrol edin. |
| Scale-up yetişmiyor | Model yükleme süresi alarm ufkundan uzundur. | Queue büyüme hızını cold-start aşamalarıyla karşılaştırıp min replica veya sıcak havuz belirleyin. |
| Bir node diğerinden yavaş | GPU modeli, clock/power, PCIe/NVLink veya NUMA yerleşimi farklıdır. | Node özelliklerini ve aynı benchmark sonuçlarını topology kimliğiyle karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Gerçek prompt ve output token histogramını çıkarın.
- Ağırlık, runtime ve KV cache belleğini ayrı ölçün.
- GPU modeli/topology etiketlerini scheduler politikasına bağlayın.
- Cold start ve model indirme yolunu kesinti altında test edin.
- Autoscaling'i queue ve token metrikleriyle doğrulayın.
- N+1 arıza, bakım ve kapasite güvenlik payını maliyete ekleyin.
İlgili kavramlar
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
NUMA yerelliği
NUMA sistemlerde işlemci, kendisine yakın bellekle uzak düğüm belleğine farklı maliyetle erişebilir. Bir sanal makinenin vCPU ve bellek boyutu, fiziksel düğüm kapasitesi ve hypervisor yerleştirmesiyle birlikte değerlendirilir. Daha fazla vCPU vermek her zaman hız kazandırmaz; yerellik kaybı ve zamanlama beklemesi performansı düşürebilir. Fiziksel topolojiyi, VM içindeki görünen topolojiyi ve gerçek iş yükünün bellek davranışını birlikte kaydedin. Değişikliği aynı yük altında önce/sonra karşılaştırın; yalnız CPU yüzdesi yerine uygulama gecikmesini ve uzak bellek etkisini inceleyin.
Kaynak rekabeti
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.