Açıkçası şaşırdım. İki DGX Spark ünitesini bir kümede birleştirip DeepSeek-V4-Flash'i çalıştırdığımda, sonuç Mac Studio M3 Ultra'ya kıyasla toplam üretim süresinde (gerçek duvar saati süresi) 1.78 kat daha hızlıydı - yani görevi yaklaşık yarı sürede tamamladı. Üstelik bu, DGX Spark resmi FP8 modelini ek bir niceleme olmadan çalıştırırken elde edildi.
Bu kıyaslamaları yaparken, sürekli dile getirdiğim noktanın bir kez daha sayılarla desteklendiğini hissettim. Şöyle ki:
LLM performansı yalnızca bellek bant genişliğine bağlı kod çözme hızı (saniye başına token, TPS) ile ölçülemez.
GPU işlem gücü, düğümler arası iletişim, bellek hiyerarşisi, niceleme kalitesi, bağlam uzunluğu, paralel işleme vb. tüm bu faktörlerin "dengesi" gerçek kullanıcı deneyimini belirler. Ve DGX Spark'ın dengesi açıkça daha iyiydi.
Kullanılan Kıyaslama: shi3z'ün Kodlama Kıyaslaması
Ölçüm için shi3z'ün Japonca LLM Kıyaslaması'ndaki kodlama kıyaslamasını kullandım. Görev, "React üzerinde çalışan bir sohbet uygulamasını tek seferde tamamlamak." Üretilen kod aslında Docker'da başlatılıyor ve Playwright kullanılarak giriş, arkadaşlar, DM ve gerçek zamanlı güncellemeler için otomatik olarak test ediliyor ve 80 puan üzerinden bir işlevsellik puanı alınıyor.
Mac Studio M3 Ultra'da antirez'in ds4 çıkarım motoru aracılığıyla DeepSeek-V4-Flash Q4 (4-bit niceleme) çalıştırmanın sonuçları shi3z'ün deposunda listelenmiştir. Aşağıdaki tablo, bu sonuçları bu seferki DGX Spark 2 üniteli küme + resmi FP8 sonuçlarıyla karşılaştırmaktadır.
Kıyaslama Sonuçları
Neden "tok/s'de Kaybettiği Halde Duvar Saati Süresinde Kazanıyor"
Tabloya bakıp "Dur bak, Mac tok/s'de daha hızlı" diye düşünüyorsanız, haklısınız. Sadece bir token üretmenin anlık hızına (kod çözme TPS) bakıldığında, Mac Studio M3 Ultra 1.58 kat daha hızlıdır. Bunun nedeni Apple Silicon'un devasa bellek bant genişliğidir.
Ancak burada bir tuzak var. Aynı "80/80 mükemmel puan" sohbet uygulamasını tamamlamak için Mac 8.036 token yazarken, DGX Spark 2.866 token yazdı. Bu yaklaşık 2.8 katlık bir farktır.
Her ikisi de resmi kalite düşüşü olmayan DeepSeek-V4-Flash'i kullandı, ancak Mac tarafının Q4'e nicelenmiş olmasının gereksiz uzunlukta yazmasına yol açarken, Spark tarafının tam kaliteli FP8'de çalışmasının özlü kalmasına neden olduğu yorumu yapılabilir. Nicelemenin çıktı dağılımı üzerindeki etkisinin kod çözme hızında görülmediği, ancak üretim stratejisini sessizce etkilediği yaygın bir olgudur.
Sonuç olarak hesaplama şu şekilde oluyor:
Gerçek Duvar Saati Süresi = (Çıktı Tokenleri) ÷ (tok/s)
Mac: 8.036 ÷ 26,2 = 307 saniye Biz: 2.866 ÷ 16,6 = 172 saniye
Tok/s'de kaybetmek ama duvar saati süresinde kazanmak, "daha az adımda aynı doğru cevaba ulaşmak" anlamına gelir. Pratik kullanımda, insanların deneyimlediği şey anlık tok/s değil, "görevin tamamlanma süresi"dir.
Kullanılan Yapılandırma
- Donanım: DGX Spark × 2 (NVIDIA GB10, Blackwell tabanlı, her biri 128 GB birleşik bellek)
- Düğüm Bağlantısı: ConnectX-7 200 Gbps RoCE ile doğrudan bağlantı (Tensor Paralel = 2, PyTorch dağıtık arka uç)
- Çıkarım Motoru: b12x'i (GB10'a özel CuTe DSL çekirdekleri seti) vLLM 0.21.1dev'e entegre eden Aiden'in tarifi
- Model: DeepSeek-V4-Flash resmi FP8 (154 GB, FP8 dikkat, MXFP4 MoE - bu DeepSeek tarafından yayınlanan resmi formattır)
- Bağlam: 524.288 token (512K), util 0,82, KV önbelleği 19,85 GiB, eşzamanlılık 3,89×
- Çoklu Token Tahmini (MTP): Yaklaşık %62 kabul oranıyla spekülatif kod çözme (çıktı kalitesinden ödün vermeden hız kazanma)
Performansa Daha Yakından Bakış
Bu kıyaslamadaki rakamların ötesinde, saf kod çözme ve ön doldurma hızlarını ayrıca ölçtüm:
- Saf Kod Çözme Hızı (Kısa metin, TTFT hariç): Yaklaşık 39 tok/s'de sabit
- Ön Doldurma Hızı (Geniş bağlam): 1.277 tok/s (Bu, b12x çekirdekleri olmayan eski yapılandırmanın 196 tok/s'sinden yaklaşık 6,5 kat daha hızlıdır)
- Uzun Bağlamla Kod Çözme: 8K → 64K → 128K → 256K → 512K → 768K'ya çıkardıkça bile kod çözme hızı keskin bir şekilde düşmedi; tam tersine hızlandı (768K'da 106 tok/s). Bunun nedeni, DeepSeek'in Seyrek Dikkat (DSA) mekanizmasının b12x çekirdeklerinde yerel olarak uygulanması ve dikkat hesaplamalarının bağlam uzunluğundan neredeyse bağımsız olmasıdır.
Bu, "Niceleme Olmadan, Tam Kalitede" Bir Sonuçtur
Vurgulamak istediğim bir diğer nokta da DGX Spark tarafının modelde herhangi bir ek niceleme kullanmamış olmasıdır. HuggingFace'de dağıtılan resmi 154 GB dosyayı olduğu gibi yükledik ve DeepSeek tarafından tasarlanan resmi niceleme formatında çalıştırdık: FP8 dikkat + MXFP4 MoE.
Yerel LLM dünyasında, devasa modelleri çalıştırmak için IQ2 (2-bit) veya Q4'e sıkıştırmak yaygın bir bilgelik haline geldi, ancak bunlar kesinlikle kaliteden ödün verir. Aslında, daha önce DeepSeek-V4-Flash'in IQ2XXS (2-bit) sürümünü denemiş ve aynı kıyaslamada 55/80 + ajan davranışı çökmesi sonucunu görmüştüm. Niceleme bedava bir öğle yemeği değildir.
İki DGX Spark ile 256 GB birleşik bellek elde edebilen bir yapılandırma, "devasa modelleri tam kalitede çalıştırma" seçeneğini ilk kez gerçeğe dönüştürüyor. Bunun, rakamların önerdiğinden daha anlamlı bir ilerleme olduğunu düşünüyorum.
Spark'ın "Dengesi" Neden İşe Yaradı
Bu sonucu destekleyen teknik unsurları parçalara ayıralım:
- b12x Çekirdek Paketi: CuTe DSL kullanılarak GB10 / SM12.x için özel olarak yazılmış dört tip çekirdek (NVFP4 birleşik MoE GEMM, NVFP4 yoğun GEMM, FP8 sayfalı dikkat ve seyrek MLA dikkat). Genel vLLM'deki MARLIN yolunun aksine, bunlar nicelemeyi kaldırmadan doğrudan birleşik modda hesaplama yapar.
- 200 Gbps RoCE Doğrudan Bağlantı: TP=2 düğümler arası toplama- yayın her katmanda iki kez gerçekleşse de, 200 Gbps doğrudan bağlantı etkin gecikmeyi düşük tutar ve kod çözme için bir darboğaz haline gelmez.
- 128 GB Birleşik Bellek × 2: HBM ve DDR'yi ayırmayan Grace Blackwell'in bir avantajı. 154 GB resmi FP8 modelinin, 512K bağlam için 19,85 GiB KV önbelleğine yetecek kadar alanla birlikte iki üniteye bölünerek olduğu gibi yerleştirilmesine olanak tanır.
- DeepSeek Seyrek Dikkat'in (DSA) Yerel Uygulaması: b12x çekirdekleri, dikkat karmaşıklığının GB10'un yerel seyrek işlemlerini kullanarak bağlam uzunluğuna bağlı olmadığı tasarımı doğru şekilde ele alır. Bu, kod çözme hızının bağlam uzunluğuyla birlikte düşmemesi sonucuna yol açtı.
Başka bir deyişle, bu unsurlardan yalnızca biri - bellek bant genişliği, bilgi işlem gücü, düğüm iletişimi, uzun bağlam optimizasyonu veya niceleme kalitesi - olağanüstü olsaydı, bu sonuç gerçekleşmezdi. Spark tüm bu unsurları aynı fiyat aralığındaki herhangi bir tek makine yapılandırmasından daha yüksek bir seviyede sunar. "Dengesinin" gerçek doğası budur.
Pratik Kullanımda Ne Değişir?
Soyut teorinin ötesine geçmek için bazı somut faydalar şunlardır:
- Büyük belgelerin özetlenmesi ve kod analizi gerçekçi hale gelir: 512K bağlam ve 1.277 tok/s ön doldurma hızıyla, tüm bir kitabı (~300.000 token) yaklaşık 4 dakikada yükleyip özetleyebilirsiniz.
- Ajan döngüleri takılıp kalmaz: 3,89× eşzamanlılık ile sohbet ve uzun biçimli özetlemeyi aynı anda çalıştırabilirsiniz (örneğin, Hermes Agent ile) ve kod çözme çökmez.
- Niceleme hatası nedeniyle "Ajan boş konuşuyor" sorunları olmaz: IQ2 serisi modellerde birçok kez düştüğüm bir tuzaktı; tam kalitede bu basitçe olmaz.
- Güç tüketiminde Mac ile rekabet edebilir: Çıkarım sırasında iki GB10'un toplam güç tüketimi yaklaşık 100W–140W'tır ve bu, tam güçteki Mac Studio M3 Ultra'ya yakındır. 1.78 kat performans göz önüne alındığında, güç verimliliği de fena değildir.
Sonuç: LLM Performansını Yalnızca TPS ile Değerlendirme Dönemi Sona Erdi
Bir token üretmenin anlık hızı - kod çözme TPS - kesinlikle önemli bir metriktir. Ancak bu, "100 metre sprintinin azami hızı" gibidir. Pratikte ihtiyaç duyulan şey "aynı doğru cevaba ulaşma süresi", "cevabın kalitesi", "kaç tanesinin aynı anda çalıştırılabileceği", "ne kadar uzun bir bağlamın işlenebileceği" ve "ajan döngülerinin çalışıp çalışmadığı"dır. Bunlar toplam puanlardır.
Bu sonucun gösterdiği şey, DGX Spark'ın bu toplam puanda öne geçmeye başladığıdır. Sadece iki üniteyi bir kümede birleştirerek, Mac Studio'nun duvar saati hızının 1.78 katı hızında, resmi kalitede, uzun bağlamda ve ajan uyumluluğunu koruyarak devasa bir modeli çalıştırabileceğiniz bir döneme girdik.
Son birkaç yıldır insanlar "LLM'lerin her şeyi bellek bant genişliğidir" ve "kod çözme TPS her şeydir" dediler, ancak Spark'ı fiilen çalıştırdıktan sonra, "dengenin pratik performans olduğu" iddiamın nihayet sayılarla kanıtlandığını hissediyorum.
RTX Spark da duyuruldu ve işlerin beklenenden daha fazla ısındığına dair bir his var (gerçi fiyat açıklandığında hava biraz soğuyabilir...). Topluluğun büyüyeceğine ve daha fazla optimizasyon ve uzmanlık bilgisinin birikeceğine dair büyük beklentilerim var!
Jensen gerçekten inanılmaz... Acaba onun saltanatı uzun süre daha devam edecek mi?
**
**
**
**
**
Bonus
Keskin görüşlü okuyucular şu eleştiriyi yapabilir:
"O zaman Mac Studio'da da ham resmi FP8'i çalıştırsaydınız daha adil bir karşılaştırma olmaz mıydı?"
"Karşılaştırma haksız değil mi? Mac Studio yalnızca Q4'e nicelenmiş olduğu için gereksiz uzunlukta yazdı. Mac Studio'da ham resmi FP8'i çalıştırsaydınız, kalite açısından aynı seviyede olmaz mıydı?" Bu makul bir soru.
Direkt cevap: Şu anda Mac Studio'da 'ham resmi FP8 + MXFP4 MoE'yi pratik hızlarda çalıştırmanın bir yolu yok.
- Her şeyden önce, uyumlu bir çıkarım motoru yok.
Apple Silicon'da DeepSeek-V4-Flash'in resmi formatını (FP8 dikkat + MXFP4 MoE + Lightning Indexer + DSA Seyrek Dikkat) tam olarak destekleyen bir motor bulunmuyor gibi görünüyor (bir Claude Code aramasına göre).
- MLX (Apple'ın resmi Apple Silicon LLM çerçevesi): MXFP4 MoE birleşik GEMM'in yerel bir uygulaması, FP8 sayfalı dikkat ve DeepSeek'in DSA Seyrek Dikkat'inin MLX uygulaması yok. Çalıştırmayı denerseniz, muhtemelen bf16'ya yükseltmeniz gerekir.
- llama.cpp: MXFP4'ü doğrudan yükleyemez, bu nedenle GGUF'a yeniden niceleme gerektirir = sonuçta Q4 / Q5 / IQ2 vb.'ye dönüştürülür ve artık "ham resmi" sürüm olmaz.
- vLLM: Apple Silicon desteği baştan sınırlıdır ve b12x gibi GB10'a özel çekirdekler Mac'te çalışmaz.
- antirez/ds4: Bu, Q4 varsayımıyla DeepSeek V4 Flash için MLX tabanlı olarak yazılmış özel bir motordur. Mac Studio'da çalıştırmak için mevcut en uygun çözümdür, ancak "ham FP8"i işlemek üzere inşa edilmemiştir.
Antirez'in DeepSeek V4 Flash için özel olarak Q4 için özel bir motor yazmış olması, Apple Silicon'da resmi kaliteyi olduğu gibi çalıştırmak için şu anda pratik bir yol olmadığı gerçeğini göstermektedir.
- bf16 yükseltme ile çalıştırılsa bile, bant genişliği neredeyse tamamen tüketilirdi.
Diyelim ki biri, resmi ağırlıkları bf16'ya yükselten bir MLX uygulaması oluşturdu. Kaba bir bant genişliği hesaplamasıyla ne olacağını tahmin edebilirsiniz:
- DeepSeek-V4-Flash, yaklaşık 30B aktif parametre içeren bir MoE yapılandırmasına sahiptir.
- Q4'te (4-bit), aktif parametreler yaklaşık 15 GB yer kaplar ve ds4 26,2 tok/s (ölçülen) elde eder.
- Aynı model FP8'de (8-bit) tutulursa, aktif parametreler yaklaşık 30 GB = 2x bant genişliği gereksinimi = teorik olarak aynı motorda ~13 tok/s.
- Ayrıca, MLX'te bf16'ya yükseltme, aktif parametreler için yaklaşık 60 GB = 4x bant genişliği gereksinimi = teorik olarak ~6,5 tok/s.
- Mac Studio M3 Ultra'nın efektif bellek bant genişliği yaklaşık 800 GB/s olduğundan, her token için 60 GB okumak bant genişliği sınırına ulaşacaktır.
Başka bir deyişle, Apple Silicon'da "ham kaliteyi" tercih etmek şu anda "hızdan iki kat daha fazla ödün verme" maliyetiyle geliyor. ds4 + Q4 ile 26,2 tok/s'de çalıştırmak, tam kaliteli bf16 ile yalnızca 6 tok/s almak yerine daha pratik bir seçimdi.
- Spark'ın yapısal avantajı işte burada devreye giriyor.
Öte yandan, bu DGX Spark yapılandırması "ham resmi FP8 + MXFP4 MoE'yi yerel olarak" çalıştırır. Bu, aşağıdakiler tarafından desteklenmektedir:
- GB10'a özel b12x çekirdek paketi, NVFP4 birleşik MoE GEMM ve FP8 sayfalı dikkati "nicelemeyi kaldırmadan" çalıştıracak uygulamalara sahiptir.
- Bu henüz Apple Silicon için yazılmamıştır.
- Sonuç olarak, Spark şu anda "resmi kaliteyi olduğu gibi" ve "pratik hızlarda" çalıştırmak için mevcut tek gerçekçi çözümdür.
Özetlemek gerekirse, yalnızca donanım bant genişliğine bakarsanız, Mac Studio'nun tek bir ünite için mutlak değeri benzer bir seviyededir, ancak "resmi niceleme formatlarını yerel olarak çalıştıran çekirdek uygulamalarının varlığı veya yokluğu" belirleyici bir fark yaratır. Spark'ın avantajı yalnızca çipten değil, b12x gibi GB10'a özel yazılım yığınıyla birlikte tüm kombinasyondan gelir.
Gelecekte birisi Apple Silicon için MLX'te MXFP4 birleşik MoE GEMM, FP8 sayfalı dikkat ve DSA Seyrek Dikkat yazarsa, bu önerme çökecektir. Ortam, topluluk uygulamalarına bağlı olarak değişecektir. Şimdilik, gerçek şu ki Spark, "resmi kalite × pratik hız" kombinasyonunu elde etmede bir adım öndedir.
Bunlar, Claude Code tarafından sağlanan analizin sonuçlarıdır.
