70B, 405B ve DeepSeek R1 için kaç GPU gerekir?

Üretim çıkarımında pay bırakarak çalışmak için 70B bir model FP8'de 2× H100 80 GB (veya 1× H200 141 GB), 405B bir model FP8'de 8× H100 (veya 4× H200) ve DeepSeek R1 (671B MoE, FP8 olarak yayımlandı) tek bir 8× H200 düğümü veya 16× H100 gerektirir. Her rakam, parametre sayısı çarpı ağırlık başına bayttan, artı KV önbelleği ve çalışma zamanı ek yükü için yüzde 20–50 paydan gelir ve 1, 2, 4 veya 8'lik bir tensor-parallel dereceye yuvarlanır. Bağlam uzunluğu ve eşzamanlı kullanıcı sayısı payı belirler, dolayısıyla aynı 70B model kısa bağlamlı bir sohbet botu için 2 GPU, 128k token'lık bir belge hattı için ise 8 GPU gerektirebilir.

Bellek formülü: ağırlıklar, KV önbelleği ve ek yük

Her boyutlandırma sorusu tek bir eşitsizliğe indirgenir: ağırlıklar, uçuştaki tüm token'lar için KV önbelleği ve çalışma zamanının çalışma belleği, modele atanan GPU'ların toplam VRAM'ine sığmalıdır. Ağırlıklar yükleme anında sabittir, KV önbelleği sunulan her token ile büyür ve ek yük GPU başına kabaca sabittir.

GPU memory needed  =  weights + KV cache + overhead

weights   = parameters × bytes per weight
            FP16/BF16 = 2 bytes, FP8 = 1 byte, INT4 ≈ 0.55 bytes (incl. scales)
KV cache  = 2 × layers × KV heads × head_dim × bytes per value × tokens in flight
overhead  = CUDA context + activations + kernel workspace ≈ 5–10% of VRAM

70B'lik dense bir model için bu, FP16'da yaklaşık 140 GB, FP8'de 70 GB ve INT4'te yaklaşık 38 GB anlamına gelir (INT4, birkaç gigabaytlık ölçek [scale] metaverisi taşır). vLLM, VRAM'in sabit bir kısmını ayırır (--gpu-memory-utilization, varsayılan 0.9) ve ağırlıklardan sonra kalan her şeyi KV önbelleğine verir. Hopper ve Blackwell FP8'i doğal olarak çalıştırır, dolayısıyla FP8 belleği yarıya indirir ve bant genişliği sınırlı decode'u neredeyse hiç kalite maliyeti olmadan hızlandırır; INT4 (AWQ, GPTQ) bunu küçük, modele bağlı bir maliyetle bir kez daha yarıya indirir. Ağırlıklar tek başına toplam VRAM'in yaklaşık yüzde 75–80'inden fazlasını tüketiyorsa, eşzamanlı kullanıcılar için yer kalmaz: GPU ekleyin veya hassasiyeti düşürün.

Boyutlandırma tablosu: H100, H200, B200 ve RTX PRO 6000'de 7B'den 671B'ye

İlk tablo yalnızca ağırlık belleğini verir. İkincisi, KV önbelleği ve ek yük için yaklaşık yüzde 30 pay bırakan (Nanobase AI'ın müşteri boyutlandırmasında kullandığı marj) minimum GPU sayısını verir; bu sayı bir düğüm içinde 1, 2, 4 veya 8'lik bir tensor-parallel dereceye, düğümler arasında ise 8'in katlarına yuvarlanır. Resmi kapasiteler H100 için 80 GB HBM3, H200 için 141 GB HBM3e, B200'de yaklaşık 180 GB HBM3e ve RTX PRO 6000'de 96 GB GDDR7'dir.

En küçük GPU sayısı FP16 / FP8 / INT4 olarak verilmiştir; "n/r" tavsiye edilmediği (NVLink olmadan 8'den fazla PCIe GPU'su veya iki düğümden fazlası) anlamına gelir.

Üç hücre yorum gerektiriyor: 70B FP16'da 2× H100'e yüklenir (160 GB'ın 140'ı) ve bir B200'e de yüklenir, ancak öyle az KV önbelleği bırakır ki yalnızca kısa bağlamlı, düşük eşzamanlılıklı kullanım çalışır, dolayısıyla 4 ve 2. 405B FP8'de 8× H100'de (640 GB'ın 405'i) klasik tek düğüm düzenidir. DeepSeek R1 doğal FP8'de 8× H100'e sığmaz (671 GB ağırlık); yanıtlar bir 8× H200 düğümü, iki düğümde 16× H100 veya 8× H100 üzerinde bir INT4 kontrol noktasıdır (checkpoint). GPU'yu seçebiliyorsanız belleği satın alın: bir H200 veya B200, 70B sınıfı modeller için iki H100'ün yerini alır ve bir 8× H200 düğümü, DeepSeek R1 için en küçük temiz evdir.

KV önbelleği: bağlam uzunluğu ve eşzamanlılık cevabı nasıl değiştirir

KV önbelleği, modelin her decode adımında yeniden hesaplamaması için her aktif dizideki her token'ın anahtar ve değer tensörlerini saklar. Token başına boyutu istemden değil mimariden etkilenir: gruplu sorgu dikkati (GQA) modelleri yalnızca 8 KV başlığı tutar ve DeepSeek V3 ile R1'deki çok başlı gizil dikkat (MLA) önbelleği daha da sıkıştırır.

Önemli olan yapılandırılmış maksimum bağlam değil, tüm eşzamanlı dizilerde uçuştaki token sayısıdır, çünkü vLLM ve TensorRT-LLM'deki sayfalanmış dikkat (paged attention), token'lar geldikçe KV bloklarını ayırır: --max-model-len 128k olsa bile 4k token'lık sohbetlere sahip 20 kullanıcı 80k token'lık önbelleğe mal olur. FP8 KV önbelleği (--kv-cache-dtype fp8) çoğu modelde ihmal edilebilir kalite etkisiyle ayak izini yarıya indirir ve önek önbellekleme (prefix caching), paylaşılan bir sistem isteminin maliyetini ortadan kaldırır.

Yukarıdan aşağıya bütçeleyin: kullanılabilir VRAM (toplam × 0.9) eksi ağırlıklar eksi birkaç gigabaytlık ek yük, token başına KV'ye bölünür. 2× H100 üzerinde FP8'de 70B için, 144 GB eksi 70 GB eksi yaklaşık 6 GB yaklaşık 68 GB bırakır, yani kabaca 200k token'lık FP16 KV önbelleği: her biri 8k token'da yaklaşık 25 eşzamanlı kullanıcı veya 32k'da 6 kullanıcı, FP8 KV önbelleğiyle bunun iki katı. Uzun bağlam ağırlıkları değiştirmez; pay bırakarak fonlamanız gereken eşzamanlılığı çarpar ve genellikle 2 GPU'luk bir planın 4 GPU'luk bir plana dönüşmesinin nedeni budur.

MoE modelleri: toplam parametreler belleği, etkin parametreler hızı belirler

Bir mixture-of-experts (uzman karışımı) modeli her token'ı ileri besleme uzmanlarının küçük bir alt kümesinden geçirir. DeepSeek V3 ve R1'in 671B toplam parametresi vardır ancak token başına yaklaşık 37B'sini etkinleştirir (61 katmanın her birinde 256 yönlendirilen uzmandan 8'i artı 1 paylaşılan uzman); Llama 4 Maverick'in 400B toplamı ve 17B etkini, Qwen3-235B-A22B'nin ise 235B ve 22B'si vardır. Bellek toplam parametreleri izler çünkü herhangi bir token herhangi bir uzmana yönlendirilebilir, dolayısıyla her uzman bellekte olmalıdır: R1 için FP8'de yaklaşık 671 GB ve Maverick için yaklaşık 400 GB.

Hız etkin parametreleri izler, ancak bir uyarıyla. Grup boyutu 1'de bir decode adımı R1'in kabaca 37B parametresini okur, dolayısıyla token başına gecikme 671B'lik bir modelden çok 37B'lik bir modele yakındır; büyük grup boyutunda ise çoğu uzmana her adımda dokunulur ve bant genişliği talebi dense duruma doğru tırmanır. Uzman paralelliği (EP), uzmanları GPU'lara yayar ve vLLM ile SGLang'ın MoE sunumunu ölçeklendirme biçimi budur; yine de 2026 itibarıyla tek bir 8 GPU'lu düğüm için düz TP=8 en basit çalışan kurulum olmayı sürdürür.

R1'i damıtılmış (distilled) varyantlarıyla karıştırmayın: R1-Distill-Llama-70B ve R1-Distill-Qwen-32B dense modellerdir ve yukarıdaki 70B ve 32B satırları gibi boyutlandırılır. MoE için belleği toplam parametrelere göre bütçeleyin ve gecikmenin etkin parametrelere yakın olmasını bekleyin; hiçbir yapılandırma yalnızca ihtiyaç duyacağınızı düşündüğünüz uzmanları yüklemez.

Tensor ve pipeline paralelliği temelleri

Tensor paralelliği (TP), her ağırlık matrisini GPU'lar arasında dilimler, böylece her biri her katmanın 1/TP'sini tutar. Her katman daha sonra bir all-reduce gerektirir; bu yüzden TP bir düğüm içinde NVLink üzerinde yaşar (H100'de GPU başına 900 GB/s, B200'de 1.8 TB/s); PCIe üzerinde, RTX PRO 6000'de olduğu gibi, TP=2 veya 4 çalışır ama ara bağlantı beklemelerine verim kaybeder. TP ayrıca bant genişliğini toplar: H100'de TP=2, ağırlıkları birleşik 6.7 TB/s'de okur, dolayısıyla bir H200'e sığan 70B bir model genellikle iki GPU'da daha hızlı decode eder. TP, dikkat başlıklarını eşit olarak bölmelidir; Llama 70B'nin 64 sorgu başlığı ve 8 KV başlığı vardır, dolayısıyla 1, 2, 4 veya 8'lik TP temizdir ve TP=16, KV başlıklarını çoğaltarak belleği israf eder.

Pipeline paralelliği (PP), ardışık katman gruplarını farklı GPU'lara veya düğümlere atar ve yalnızca aktivasyonlar bir aşama sınırını geçer. Çok daha az bant genişliğine ihtiyaç duyar, bu da onu InfiniBand üzerinde düğümler arasında doğru araç yapar, ancak düşük grup boyutlarında pipeline balonları ekler; Llama 405B'nin FP16'da 16× H100 dağıtımı genellikle --tensor-parallel-size 8 --pipeline-parallel-size 2'dir. Bir model sığdıktan sonra, ek GPU'lar daha geniş bir TP grubundan çok veri-parallel kopyalara harcanmalıdır (motor farkları vLLM vs TensorRT-LLM vs Ollama vs SGLang yazısında ele alınmıştır). Modeli, yüzde 30 pay bırakan en küçük TP ile sığdırın, ardından verimi kopyalarla ölçeklendirin.

Uygulamalı örnek: 200 kullanıcı için 70B dağıtımını boyutlandırma

Hopper GPU'larında 16k token'lık bir bağlam sınırıyla 200 iç kullanıcı için Llama 3.3 70B'nin şirket içi bir dağıtımını varsayalım (çevredeki yığın şirket içi LLM dağıtım rehberinde bulunur). Boyutlandırma altı adımda ilerler.

1. Hassasiyet: FP8, Hopper üzerinde doğaldır ve 70B'de neredeyse kayıpsızdır, dolayısıyla ağırlıklar yaklaşık 70 GB'tır.
2. Eşzamanlılık: zirvede 200 kullanıcının yüzde 10–15'inin aktif olmasını planlayın, dolayısıyla ortalama 6k token uçuşta (4k istem, 2k üretim) olan 20–30 eşzamanlı dizi, en kötü durumda 16k.
3. KV önbelleği: token başına yaklaşık 320 KB'ta, 30 × 6k token ortalama yaklaşık 58 GB'tır ve 30 × 16k en kötü durumda yaklaşık 154 GB'tır; FP8 KV önbelleği ikisini de yaklaşık 29 GB ve 77 GB'a indirir.
4. Ek yük: yüzde 10'luk vLLM ayrımı artı aktivasyonlar ve CUDA grafikleri için GPU başına yaklaşık 3 GB.
5. Toplam: FP8 KV önbelleğiyle en kötü durum yaklaşık 70 + 77 + 10 = 157 GB'tır. İki H100 (kullanılabilir 144 GB) zirveyi karşılayamaz; iki H200 (kullanılabilir yaklaşık 254 GB) büyüme payıyla karşılayabilir ve dört H100 eşdeğer H100 düzenidir.
6. Verim kontrolü: iki H200, 70 GB ağırlığı birleşik 9.6 TB/s'de okur, saniyede yaklaşık 137 decode adımlık bir üst sınır; gerçek motorlar bunun kabaca yüzde 30–40'ına ulaşır, dolayısıyla 30 kullanıcı aktifken kullanıcı başına saniyede yaklaşık 40–55 token beklenebilir. Bu bir bant genişliği tahminidir, bir kıyaslama değil; bir yük testiyle doğrulayın.

vLLM için ortaya çıkan başlatma komutu (bayrak ayrıntıları vLLM belgelerinde yer alır):

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 2 \
  --quantization fp8 \
  --kv-cache-dtype fp8 \
  --max-model-len 16384 \
  --max-num-seqs 64 \
  --gpu-memory-utilization 0.90

Aynı prosedür diğer manşet rakamları da verir. Bu yük altında FP8'de Llama 405B yaklaşık 405 GB artı yaklaşık 250 GB FP16 KV önbelleği gerektirir, dolayısıyla 8× H100 zirveyi yalnızca FP8 KV önbelleğiyle karşılar ve 8× H200 rahattır; DeepSeek R1, MLA sayesinde yaklaşık 671 GB artı yalnızca yaklaşık 35 GB KV önbelleği gerektirir, dolayısıyla 8× H200'de boyutu önbellek değil model belirler. Bir GPU sayısını token başına maliyete dönüştürmek kendi GPU'larınız vs bulut API'leri yazısında ele alınmıştır. Ortalama için değil zirve için boyutlandırın ve bir GPU sayısına karar vermeden önce bant genişliğinden türetilen saniyedeki token sayısının gecikme hedefinizi karşıladığını kontrol edin.

Sıkça sorulan sorular

70B bir modeli tek bir GPU'da çalıştırabilir miyim?

Evet, düşürülmüş hassasiyette. FP8'de 70 GB ağırlık bir H200, B200 veya RTX PRO 6000 96 GB'a sığar, ancak 96 GB'lık kart KV önbelleği için yalnızca yaklaşık 20 GB bırakır; INT4'te (yaklaşık 38 GB) bir H100 80 GB işe yarar. FP16 ağırlıklar 140 GB'tır ve iki GPU gerektirir. Tek GPU'lu 70B, düşük eşzamanlılığa ve yaklaşık 16k token'a kadar bağlamlara uygundur.

DeepSeek R1 ne kadar GPU belleğine ihtiyaç duyar?

Yalnızca ağırlıklar için yaklaşık 671 GB, çünkü R1, FP8 olarak yayımlanmış 671B parametreli bir MoE'dir. En küçük standart dağıtım, MLA sayesinde cömert bir KV önbelleği de bırakan tek bir 8× H200 düğümüdür (1,128 GB). FP8'de 8× H100'e (640 GB) sığmaz; iki düğümde 16× H100 veya 8× H100 ya da 4× H200 üzerinde bir INT4 kontrol noktası (yaklaşık 350 GB) kullanın.

FP8 veya INT4 kuantizasyonu model kalitesine zarar verir mi?

FP8, 8B ve üzeri modeller için neredeyse kayıpsızdır ve Hopper ile Blackwell üzerinde varsayılan tercihtir. AWQ ve GPTQ gibi yalnızca-ağırlık INT4 yöntemleri genellikle küçük bir doğruluk maliyetine yol açar, küçük modellerde ve çok adımlı akıl yürütme görevlerinde daha fazla, ve ölçekler için birkaç yüzde bellek ekler. Donanıma karar vermeden önce kuantize kontrol noktasına karşı kendi değerlendirme setinizi çalıştırın.

KV önbelleği boyutunu nasıl hesaplarım?

Token başına önbellek için 2 (anahtarlar ve değerler) × katmanlar × KV başlıkları × başlık boyutu × değer başına bayt çarpın, ardından tüm eşzamanlı isteklerdeki uçuştaki tüm token'larla çarpın. Llama 3.3 70B (80 katman, 8 KV başlığı, 128 başlık boyutu), FP16'da token başına yaklaşık 320 KB'a, yani 32k token'lık tek bir dizi için yaklaşık 10.7 GB'a mal olur. FP8 KV önbelleği bunu yarıya indirir; DeepSeek V3 gibi MLA modelleri kabaca dörtte birine ihtiyaç duyar.

70B bir model için H200, H100'e göre değer mi?

Genellikle evet. 141 GB'ı, 70B bir FP8 modelinin iki yerine tek bir GPU'da çalışmasını sağlar ve 4.8 TB/s bant genişliği (3.35 TB/s'ye karşı) GPU başına daha hızlı decode sağlar; iki H200, 30 eşzamanlı kullanıcı için 16k bağlamda 70B'yi sunarken aynı yük dört H100 gerektirir. Zaten H100'lere sahipseniz, fark değiştirmeyi haklı çıkarmaz. Tam karşılaştırma için H100 vs H200 vs B200 yazısına bakın.

Veri merkezi GPU'ları yerine RTX PRO 6000 kartları kullanabilir miyim?

Evet, yaklaşık 70B'ye kadar modeller ve orta düzey eşzamanlılık için. 96 GB'lık GDDR7 kart, tek başına 70B bir FP8 modeli ve dört kart üzerinde 405B bir INT4 modeli barındırır. Sınırlar, PCIe üzerinde tensor paralelliğini yavaşlatan NVLink eksikliği ve HBM parçalarına göre daha düşük bellek bant genişliğidir (yaklaşık 1.8 TB/s), dolayısıyla kullanıcı başına token oranları daha düşüktür. Geliştirme, departman düzeyi dağıtımlar ve model başına çok fazla GPU gerektirmeyen iş yükleri için uygundur.

Nanobase AI nasıl yardımcı olabilir

Nanobase AI, özel LLM dağıtımları için GPU altyapısını boyutlandırır, kurar ve işletir. Modellerinizden, bağlam uzunluklarınızdan ve eşzamanlılık hedeflerinizden başlar, yukarıdaki gibi bir bellek ve verim planı hazırlar ve siparişi vermeden önce H100, H200, B200 veya RTX PRO 6000 sistemlerinde yük testleriyle doğrularız. Ardından sunum yığınını (vLLM, TensorRT-LLM veya NVIDIA NIM) doğru paralellikle, Kubernetes GPU Operator veya Slurm zamanlaması ve izlemeyle devreye alır, kuantizasyon ve KV önbelleği ayarlarını kendi değerlendirme setinize göre ince ayarlarız.

Nanobase AI, Silikon Vadisi merkezlidir ve NVIDIA Inception Programı'nın bir üyesidir. Boyutlandırılmış bir dağıtımın çalıştığını görmek için çözümlerimize göz atın veya bir canlı demo rezervasyonu yapın.

Projenizi görüşmeye hazır mısınız? Nanobase AI ile iletişime geçin veya hello@bumu.tech adresine e-posta gönderin.