DeepSeek neden büyük ölçekte ucuz ama yerelde pahalı?

• DeepSeek-V3 gibi bazı yapay zeka modelleri, büyük ölçekte sunulduğunda ucuz ve hızlıdır; ancak yerelde çalıştırıldığında yavaş ve pahalıdır
• Bunun nedeni, GPU kullanım verimliliği ile ilişkili throughput (iş hacmi) ve latency (gecikme) arasındaki temel ödünleşimdir
• Batch boyutu büyütüldüğünde GPU daha verimli çalışır, ancak kullanıcı tokenların birikmesini beklemek zorunda kaldığı için gecikme artar
• Mixture-of-Experts yapısı ve derin pipeline kullanan modeller, yüksek batch ve yüksek gecikme gerektirir
• Yerelde tek kullanıcılı ortamlarda yeterince büyük batch oluşturmak zor olduğundan performans düşer ve maliyet artar
• OpenAI, Anthropic vb. şirketler, mimarinin kendisini daha verimli hale getirerek, gelişmiş batch stratejileri kullanarak veya aşırı miktarda GPU ayırarak hızlı yanıt sunar

---

Batch inference ve GPU verimliliği

• GPU, büyük ölçekli matris çarpımı (GEMM) için optimize edilmiş bir donanımdır
• Birden çok kullanıcının tokenları tek seferde büyük bir matris halinde batch olarak çalıştırıldığında, düşük round-trip overhead ve bellek verimliliği sayesinde iş hacmi keskin biçimde artar
• Inference sunucusu, birden fazla isteğin tokenlarını kuyrukta toplar ve uygun boyutta bir batch seçerek büyük ölçekli GEMM işlemleri yürütür
• Bu süreçte sunucu, batch boyutu (throughput artışı) ile bekleme süresi (latency artışı) arasındaki ödünleşimi seçmek zorunda kalır

Neden bazı modeller büyük batch için optimize edilmiştir?

Mixture of Experts (MoE) ve batch

• MoE yapısı (DeepSeek-V3, GPT-4 olduğu tahmin ediliyor), düşük GPU verimliliğinin başlıca nedenidir
• Yüzlerce “uzman” bloğun her biri ayrı matris çarpımları gerektirdiğinden, küçük batch'lerde her uzmana düşen iş az olur ve verim düşer
• Tüm uzmanları yeterince kullanabilmek için çok sayıda eşzamanlı istek gerekir; bu nedenle servis düzeyinde büyük batch zorunludur
• Kısa beklemede (5 ms pencere) uzmanlar sık sık boşta kalırken, uzun beklemede (200 ms pencere) yüksek verimlilik en üst düzeye çıkarılabilir

Derin pipeline modellerde batch sorunu

• Yüzlerce katmandan oluşan büyük transformer'lar, katmanlara göre birden fazla GPU'ya bölünerek (pipeline) çalıştırılır
• Tek bir batch içindeki token sayısı pipeline adımı sayısından az olduğunda, pipeline bubble denen durum oluşur ve bu da iş hacminin düşmesine yol açar
• Bunu önlemek için büyük batch'ler (yani uzun bekleme) gerekir; bunun sonucu olarak modelin yanıt süresi uzar

Neden kuyruk her zaman tam doldurulamıyor?

• Teoride yüksek eşzamanlı trafik varsa kuyruğu sürekli dolu tutarak bubble etkisinden kaçınılabileceği düşünülebilir
• Ancak pratikte transformer Attention aşamasında matris boyutlarının (uzunluklarının) aynı olması gerektiği için ancak o zaman batch yapılabilir; bu yüzden tek bir kuyrukla kusursuz çalışma zordur
• Ayrıca FFN ile attention aşamalarını ayırmak, bellek overhead'inin keskin biçimde artmasına ve veri taşımada verimsizliğe yol açar

Özet ve sonuç

• Büyük batch işleme, GPU maliyetini düşürmek ve iş hacmini artırmak için gereklidir; ancak kullanıcı daha uzun bekler
• Mixture-of-Experts ve büyük pipeline yapısına sahip modeller, doğaları gereği beklemeye dayalı yüksek verimli batch ortamlarına optimize edilmiştir
• Yerel gibi trafiğin az olduğu ortamlarda, optimize edilmiş büyük batch yapılandırması mümkün olmadığından GPU verimliliği keskin biçimde düşer ve çalıştırma maliyeti yükselir
• OpenAI, Anthropic vb. şirketler hızlı yanıt verebiliyorsa bunun nedeni şunlar olabilir:
  • (1) MoE olmayan, daha verimli bir mimari kullanıyor olabilirler
  • (2) Batch/pipeline optimizasyonu ve gelişmiş çıkarım hileleri uyguluyor olabilirler
  • (3) Gerekenden daha fazla GPU ayırarak hızı satın alıyor olabilirler

Ek: prefill batch ile asıl gövde batch'i arasındaki fark

• Transformer'lar, tek bir kullanıcının prompt'undaki prefill (uzun giriş) aşamasını da batch halinde çalıştırarak ilk inference'ı hızlandırabilir
• Ancak bu yazıda tartışılan batch, birden fazla kullanıcının isteğinde asıl token üretim aşamasında ortaya çıkan iş hacmi-gecikme ödünleşimiyle ilgili batch'tir
• Prefill batch'i, yazıda sözü edilen eşzamanlı büyük batch ile doğrudan ilişkili değildir

Notlar

• Gerçek inference sistemleri, batch dolduğu anda çalıştırmak için continuous batching yöntemini de birlikte kullanır
• Ancak temel throughput-latency ödünleşimi yine aynı şekilde geçerlidir

[GN⁺]

Hacker News görüşleri

• Ben DeepSeek V3'ü evde doğrudan çalıştırıyorum; maliyet yükünün düşük, hız ve performansın da tatmin edici olduğunu düşünüyorum. Birçok kişi GPU olmadan büyük modellerin çalıştırılamayacağını sanıyor ama benim deneyimime göre CPU sunucusu hem daha az güç tüketiyor hem de daha pratik. Ev sunucum orta seviye EPYC 9004 serisi tabanlı, 384GB RAM takılı bir Supermicro kart kullanıyor; toplam maliyet yaklaşık 4000 dolar. GPU olmadan yalnızca bol RAM kullanılırsa güç tüketimi çoğu zaman bir oyun masaüstünden bile düşük olabiliyor. Unsloth Dynamic GGUF modeliyle yaklaşık 270GB RAM kullanıyorum ve pratikte orijinale çok yakın kaliteyle çeşitli işleri destekleyebiliyor. Genelde 16k context ile çalıştırıyorum, gerekirse 24k'ye çıkarıyorum. Token üretim hızı saniyede 9~10, context büyüyünce 7'ye kadar düşüyor. 2 CPU kullanılan ortamlarda bunun da üstünde token hızıyla tüm modeli çalıştıran örnekler var
  • Unsloth Dynamic GGUF'un gerçekte orijinale ne kadar yakın performans verdiğini merak ediyorum. Benim deneyimimde basit işlerde fark büyük değil ama karmaşık görevlerde ya da uzun context'te fark bazen net biçimde ortaya çıkıyor. Unsloth'un çok iyi iş çıkardığı doğru ama orijinal kuantize edilmemiş modelle doğrudan kıyaslayan değerlendirme verilerinin az olması üzücü. Birçok kişi ve şirketin orijinal modeli doğrudan çalıştıracak imkâna sahip olmaması da gerçek bir sınırlama
  • Ollama gibi araçlarla DeepSeek'i kod üretimi amacıyla 40 çekirdekli CPU ve 256GB RAM üzerinde çalıştırmanın mümkün olup olmadığını merak ediyorum. Model için yaklaşık 200GB bellek ayırmayı düşünüyorum
  • Kişisel sitene erişilemiyor. Ben DigitalOcean kurucu ortaklarından Jeff Carr'ım; sana ulaşabilmeyi umuyorum
  • Yüksek hızlı belleğe sahip GPU'nun şart olduğunu sanıyordum; gerçekten GPU olmadan yalnızca büyük bellekle inference yapılabiliyor mu diye soruyorum. Unified olmayan bellekle bunun nasıl mümkün olduğunu merak ediyorum
  • DeepSeek V3'ün open-weight modeller arasında gerçekten oldukça pratik olduğuna katılıyorum. Birçok iş sanıldığından daha yüksek seviyede reasoning token'ı gerektirmiyor ve beklemek zorunda olmamak büyük avantaj. Gerekirse daha yüksek reasoning seçeneğine her zaman geçebilmek de çekici. Kendin çalıştırmayacaksan, bazı sağlayıcıların tam context (16k) ve 80tps sunduğu, veriyi kullanmama sözü verdiği hizmetler de var. 9004 ev sunucusu örneği hoş, güzel kurulum
• Bu blog yazısının içeriği etkileyici. Sonuca (“batching gerekiyor”) katılıyorum ama MoE model inference'ına dair tartışmanın daha çok boyutlu olması gerektiğini düşünüyorum. Büyük batch'in önemli olmasının nedeni, LLM inference'ının hesaplama eksikliğinden değil, tüm weight'leri VRAM'den yüklemenin darboğaz olmasından kaynaklanıyor. H100'ün TFLOPS'u ile bellek bant genişliği karşılaştırılınca, gerçekte byte başına 300 FLOP işleyebilecek alan olduğu hesaplanabiliyor. Batch ne kadar büyükse yüklenen her parametre için o kadar fazla hesap yapılabildiğinden batch boyutunu maksimize etmek gerekiyor. Bu yüzden “roofline model” terimi kullanılıyor. Model büyüdükçe tamamı VRAM'e sığmıyor, bu yüzden birden fazla GPU'ya ya da node'a dağıtmak gerekiyor. NVLink ya da Infiniband bile doğrudan VRAM yükleme kadar hızlı olmadığından darboğaz oluşuyor. MoE'nin gücü expert parallelism'de; yani farklı node'larda farklı expert'leri belleğe alıp node'lar arası iletişimi en aza indirebilmekte. Tabii bunun için tüm expert'lerin VRAM'e sığması ve KV cache gibi ek yüklerin karşılanabilmesi için yeterli sayıda node olması gerek. Sonuç olarak batch boyutu doğal olarak büyümek zorunda ve ancak böyle olursa her GPU verimli çalışabiliyor
  • Farklı "expert"leri aynı node'a round-robin yöntemiyle atayıp, yalnızca birden fazla istek aynı expert'i kullanınca fırsatçı biçimde batch'e toplama yaklaşımını öneriyorum. Bir bakıma batch yerine kuyruk koymak gibi; gecikme artar ama derin araştırma iş akışları gibi ortamlarda bu gayet kaldırılabilir
  • Model tek bir GPU'ya sığmadığında, katmanlara bölüp sonraki katmandan sorumlu GPU'ya küçük vektörler göndererek inference yapılabildiğine dair gerçek uygulama örneği var. Cerebras bunu Llama 4 Maverick'te kullanarak saniyede 2500 trilyon token üretiyor. Fabric üzerinde vektör taşımak çok hızlı olduğundan neredeyse hiç idle time kalmıyor
  • Tüm node'lar ve weight'ler analog devrelere yerleştirilse çok daha hızlı çalışmanın mümkün olup olmayacağını hayal ediyorum
  • AMD'ye yatırım tezlerinden biri, modelin tamamının tek bir kasaya sığabilmesi; böylece map/reduce yaklaşımının avantajları korunurken ağ ekipmanı maliyeti de azalıyor. Karşı görüş varsa içgörü duymak isterim
• Vakit kazanmak isteyenler için tek cümlelik özet: cevap batch inference. Birden fazla kişinin prompt'unu aynı anda model örneğine vermek, sadece sıkı zaman paylaşımlı çalıştırmaya kıyasla pratikte çok daha verimli. Bu yüzden sıcaklık ve seed sabit olsa bile hizmet yanıtları her seferinde farklı olabilir; çünkü kendi prompt'unuzun hangileriyle birlikte batch'leneceğini kontrol edemezsiniz. Bunun veri sızdırma saldırıları için bir saldırı vektörü olabileceği de düşünülebilir
  • Batch'in avantajlarından biri, aynı içeriğin değerlendirmesini tekrar tekrar yapıp gerçekten "hallucination" olup olmadığını kontrol etmek istediğinizde batch-size kadar örneği bir kerede gönderebilmek. Aslında batch kavramı en başından beri LLM'lerde vardı ama değeri zamanla daha iyi anlaşılıyor
  • Ben sağlayıcıların tüm modellerde her zaman batch kullandığını varsaymıştım; bunun yalnızca belirli model ailelerinde mi uygulandığını merak ediyorum
  • Diğer prompt'larla aynı batch'e girmek neden model yanıtında değişkenlik yaratıyor diye merak ediyorum
  • Prompt'lar başka insanlarla birlikte gruplanabiliyorsa bunun çok etkili bir saldırı vektörü olabileceğine dair endişem var
• Kısa özetle:<br>- Yüksek sparsity'ye sahip modellerde, tek bir matris çarpımını yeterince hesaplama yoğun hâle getirmek için büyük batch'ler (eşzamanlı istek sayısı) gerekir<br>- Bu kadar büyük batch'i kaldırmak için model weight'lerini ve MLA/KV cache'i HBM'e sığdıracak yaklaşık 8~16 GPU gerekir. Ama 8~16 GPU ile toplam throughput düşük kalır, bu da kullanıcı başına yanıt hızını gerçekten yavaşlatır. İyi bir deneyim için yaklaşık 256 GPU gerekir
  • Ben 16 H100'lü (2 node) bir ortamda DeepSeek hizmeti veriyorum. İstek başına 50~80 token/saniye ve toplamda birkaç bin token'a kadar istikrarlı throughput görüyorum. İlk token üretim süresi de kararlı ve bu, kullanabildiğimiz tüm bulut hizmetlerinden daha hızlı bir deneyim
  • Yüksek sparsity = büyük batch ihtiyacı deniyor ama bu bağlantıyı tam anlayamıyorum. Sparse matmul'u fiilen sıfırı çok olan bir matmul gibi görüp biraz alay ediyorum
• LLM perspektifinden mükemmel bir açıklama. Hyperscale LLM şirketlerinin gerçek hesaplama trace'lerini çok dikkatli analiz edip darboğaz noktalarını bulduğunu, load balancer, pipeline mimarisi, scheduler gibi araçlarla iş yükü optimizasyonunu son derece ciddiye aldığını tahmin ediyorum. Verimlilik için gerekli olan bu "batch önkoşulu", güvenliğin yüksek olduğu uygulamalarda dezavantaj olabilir; çünkü sorgu izolasyonu aşırı pahalı hâle geliyor. nVidia'nın vGPU sanallaştırması GPU belleğini zaman dilimli bölüyor ama her context switch'te unload/reload gerektiğinden ve deduplication olmadığından şüpheleniyorum. MIG de belleği kullanıcıya göre sabit bölüyor, yeniden ayarlamak için GPU'yu yeniden başlatmak gerekiyor; 96GB GPU'yu 4x24GB'e bölmek istememeyi anlıyorum. GPU kartına ikincil bellek (DRAM) eklenirse çeşitli matris verilerini PCIe'den daha hızlı yüklemek mümkün olur mu diye düşünüyorum (HBM'i cache gibi kullanarak).<br>Software Engineering hayatta kalma odaklı pratik rehber kitabı'ndaki dürüst anlatım da övgüyü hak ediyor
• DeepSeek için yazılım optimizasyonu tarafında hâlâ çok alan olduğunu düşünüyorum. Şu anda erişilebilirlik odaklı optimizasyonlar ya küçük GPU + büyük RAM sistemleri (ktransformers) ya da aşırı VRAM'e sahip sistemler için var. 192GB VRAM + geri kalanı normal bellek olan yapılar (DGX station, 2xRTX Pro 6000 vb.) MoE gücü sayesinde DeepSeek 4bit'i oldukça hızlı çalıştırabilir. DeepSeek'te Çince prompt kullanılmıyorsa çoğu expert zaten aktive olmuyor. Pruning de daha kolay olabilir. Gelecekte enthusiast sistemlerin yönü bu tür yazılımsal optimizasyonlarla uyumlu görünüyor. Reddit'te 16x3090(Pcie 3.0 x4) sistemle llama.cpp üzerinde saniyede yaklaşık 7 token elde edildiğine dair örnek de var; ayrıca tek bir 3090 bile tüm VRAM'i saniyede 39 kez tarayabildiğine göre başka performans darboğazları da olmalı
  • 16x3090 sistemin güç tüketimi tam 5KW. Bu seviyede elektrik maliyeti düşünülünce API kullanmak daha ucuz olur. DeepSeek'te Çince prompt kullanılmadığında aktive olmayan çok sayıda expert olduğu için, modelin hafifletilmesi ve token'ların daha yakın expert'lere yönlendirilmesi gibi fikirler akla geliyor
  • Tek bir MI300x 192GB VRAM sağlayabiliyor
• ML araştırmacısı ya da mühendis olmadığımı baştan söyleyeyim. DeepSeek V3/R1, önceki yerel modellere göre o kadar büyük ki yerelde çalıştırmak gerçekten pahalı. Aktif parametre sayısı toplam boyuttan düşük olsa da bu sadece hesaplama gereksinimini azaltıyor; bellek gereksinimi aynı kaldığından, devasa GPU'lar olmadan pratik kullanım çoğu zaman neredeyse imkânsız. Başlıca frontier (proprietary) modellerle de doğrudan kıyas yapılamıyor; boyut gibi bilgiler açıklanmıyor. O modellerin yerelde daha ucuza çalışacağını varsaymak için de bir neden yok. Hatta MoE, yerel/tek kullanıcı senaryosunda batch verimsizliği o kadar büyük olmadığından daha uygun bir ödünleşim sunuyor. Batch büyüdükçe token başına gecikme 200ms'ye kadar çıkabiliyor ama buna karşılık feed-forward hesaplama (GEMM) daha büyük hâle geliyor ve daha verimli işleniyor. Batch büyüyünce matrisin kendisi de mi büyüyor diye merak ediyorum. Kafamdaki modelde batch'in amacı “girdi matrisinin boyutunu artırmak” değil, “bellek bant genişliği kısıtını hesaplama darboğazına çevirmek” gibi. Zaten weight'ler katman katman HBM → SRAM'e alınıyor, parçalar üzerinde matris çarpımı yapılıyor ve en sonda sonuçlar birleştiriliyor. Batch ile aynı weight'lerle aynı anda birçok hesap yapmak mümkün oluyor ve FLOPS daha verimli kullanılıyor. OpenAI, Anthropic gibi büyük modellerin gerçekten hızlı yanıt verip vermediği konusunda da şüpheliyim; blog yazısında time to first token için sayısal veri olmadığı için dayanağı zayıf geliyor
  • Ben orijinal yazının yazarıyım. ML araştırmacısı değilim, konuya ilgi duyan bir mühendis olarak yazdım. MoE'nin yerel tek kullanıcı senaryosundaki sorunu, çok kullanıcılı batch avantajı olmayınca GPU başına throughput'un dramatik biçimde düşmesi. Yani çok büyük miktarda paralel inference isteği olmadığı sürece durum bu. Batch ile girdi matrisinin boyutunu büyüttüğünüzde, batch 1 ise hesaplama 1xdim'lik bir matris olur; batch arttıkça batch-size x dim hâline gelir ve GPU kullanım oranı hızla artar, yani darboğaz hesaplamaya kayar. Ayrıca DeepSeek'in başka modellere kıyasla gerçekten daha yavaş olduğunu çok kullandığınızda hissediyorsunuz
• mixture of experts yüksek batch istiyor ama Apple Silicon kullanılırsa batch size 1'de bile kullanılabilir diye düşünüyorum. Unified memory sayesinde büyük modeller yerelde çalıştırılabiliyor ama bant genişliği ve FLOPS düşük olduğu için görece yavaşlar. MoE'nin özelliği, her adımda işlenmesi gereken parametre sayısının az olması; dolayısıyla hesaplama yükü daha düşük. Gerçekte DeepSeek'i Mac'te tek batch inference ile kullanılabilir hızda çalıştırmış birçok kişi var. Tabii yeterli bellek almak için satın alma maliyeti hâlâ yüksek. Gelecekte Mac ya da benzeri yapıda daha fazla makine gelirse MoE modellerle mükemmel uyum yakalayabilir. Büyük RAM yükseltmesi yapılmış Mac'te dense model çalıştırmak ise çok daha sancılı
• Bir meslektaşımla konuşurken, programlama desteği için LLM kullanıldığında modellerin aslında özdeki optimizasyon hedefinden uzak bir yöne evrildiği sonucuna vardık. Şirket içi kurallar nedeniyle ben neredeyse tüm işlerde yerel 4~30B modelleri çeşitli GPT serileriyle karşılaştırıyorum; özellikle GPT-4o ortalamada harika sonuç veriyor ama “yanıtın bir kısmını uydurma” eğilimi de var, bu yüzden doğrulama ve yineleme için epey zaman harcamak gerekiyor. Sonuçta “düşük parametreli yerel modellerle fark, harcanan emeğe göre sanıldığı kadar büyük değil” diye düşünüyorum. Sorun şu ki ikisi de gerçekten yavaş, dolayısıyla hızlı iterasyon yapılamıyor. Bana göre kalite düşük olsa bile büyük context'li ama şimşek gibi anında yanıt veren bir model çok daha kullanışlı olurdu. Sadece kalite metriklerindeki artıştan daha önemli olan şeyin “hissedilen iterasyon hızı” olduğunu düşünüyorum
• "Yavaş ve pahalı" iddiasına katılmıyorum. DDR4 bellek tabanlı eski bir workstation'da bile llama.cpp kullanılarak yaklaşık 1000 dolarlık bir sistemde saniyede 3 token üretilebildiğine dair örnek var
  • Belki de gerçek DeepSeek modeliyle değil, distill edilmiş bir sürümle karıştırıp onu kullanıyorsundur. 192GB RAM ya da üzeri yoksa gerçek modeli çalıştırmak mümkün değil diye bir itiraz var