सच कहूँ तो, मैं हैरान था। जब मैंने दो DGX Spark इकाइयों को एक क्लस्टर में कनेक्ट किया और DeepSeek-V4-Flash चलाया, तो परिणाम Mac Studio M3 Ultra की तुलना में कुल जनरेशन टाइम (वास्तविक वॉल-क्लॉक टाइम) में 1.78x तेज़ था—मतलब इसने काम लगभग आधे समय में पूरा कर दिया। और यह DGX Spark के साथ बिना किसी अतिरिक्त क्वांटाइज़ेशन के ऑफिशियल FP8 मॉडल चलाने पर हुआ।
ये बेंचमार्क लेते समय, मुझे लगा कि मैं जिस बिंदु को बार-बार उठा रहा हूँ वह एक बार फिर संख्याओं द्वारा समर्थित हो गया है। वह यह है:
LLM प्रदर्शन को केवल मेमोरी बैंडविड्थ के आधार पर डिकोड स्पीड (टोकन प्रति सेकंड, TPS) से नहीं मापा जा सकता है।
GPU प्रोसेसिंग पावर, नोड-टू-नोड कम्युनिकेशन, मेमोरी पदानुक्रम, क्वांटाइज़ेशन गुणवत्ता, कॉन्टेक्स्ट लंबाई, समानांतर प्रोसेसिंग, इत्यादि—इन सभी कारकों का "संतुलन" वास्तविक उपयोगकर्ता अनुभव निर्धारित करता है। और DGX Spark के पास बस एक बेहतर संतुलन था।
उपयोग किया गया बेंचमार्क: shi3z का कोडिंग बेंचमार्क
मापने के लिए, मैंने shi3z के जापानी LLM बेंचमार्क से कोडिंग बेंचमार्क का उपयोग किया। कार्य "एक ही जनरेशन में React पर चलने वाला एक चैट ऐप पूरा करना" है। जनरेट किया गया कोड वास्तव में Docker में शुरू किया जाता है और लॉगिन, फ्रेंड्स, DM और रियल-टाइम अपडेट के लिए Playwright का उपयोग करके स्वचालित रूप से परीक्षण किया जाता है, जिसमें 80 अंकों में से एक कार्यात्मक स्कोर होता है।
antirez के ds4 इंफ़रेंस इंजन के माध्यम से Mac Studio M3 Ultra पर DeepSeek-V4-Flash Q4 (4-बिट क्वांटाइज़ेशन) चलाने के परिणाम shi3z के रिपॉजिटरी में सूचीबद्ध हैं। नीचे दी गई तालिका उन परिणामों की तुलना इस बार के DGX Spark 2-यूनिट क्लस्टर + ऑफिशियल FP8 परिणामों से करती है।
बेंचमार्क परिणाम
यह "tok/s में हारता है लेकिन वॉल-क्लॉक टाइम में जीतता है" क्यों
यदि आप तालिका को देखते हैं और सोचते हैं, "रुको, Mac tok/s में तेज़ है," तो आप सही हैं। केवल एक टोकन निकालने की तात्कालिक गति (डिकोड TPS) को देखते हुए, Mac Studio M3 Ultra 1.58x तेज़ है। यह Apple Silicon के विशाल मेमोरी बैंडविड्थ के कारण है।
हालाँकि, यहाँ एक जाल है। उसी "80/80 परफेक्ट स्कोर" चैट ऐप को पूरा करने के लिए, Mac ने 8,036 टोकन लिखे, जबकि DGX Spark ने 2,866 टोकन लिखे। यह लगभग 2.8x का अंतर है।
दोनों ने बिना किसी आधिकारिक गुणवत्ता ह्रास के DeepSeek-V4-Flash का उपयोग किया, लेकिन यह व्याख्या करना स्वाभाविक है कि Mac की ओर, Q4 में क्वांटाइज़्ड, अनावश्यक हो गया, जबकि Spark की ओर, पूर्ण-गुणवत्ता वाले FP8 में चलने वाला, संक्षिप्त रहा। यह एक सामान्य घटना है जहाँ आउटपुट वितरण पर क्वांटाइज़ेशन का प्रभाव डिकोड स्पीड में दिखाई नहीं देता है, लेकिन चुपचाप जनरेशन रणनीति को प्रभावित करता है।
परिणामस्वरूप, गणना इस प्रकार दिखती है:
वास्तविक वॉल-क्लॉक टाइम = (आउटपुट टोकन) ÷ (tok/s)
Mac: 8,036 ÷ 26.2 = 307 सेकंड हम: 2,866 ÷ 16.6 = 172 सेकंड
tok/s में हारना लेकिन वॉल-क्लॉक टाइम में जीतने का मतलब है "कम चरणों में समान सही उत्तर तक पहुँचना।" व्यावहारिक उपयोग में, इंसान जो अनुभव करता है वह "कार्य पूरा होने तक का समय" है, न कि तात्कालिक tok/s।
उपयोग किया गया कॉन्फ़िगरेशन
- हार्डवेयर: DGX Spark × 2 (NVIDIA GB10, Blackwell-आधारित, प्रत्येक 128 GB यूनिफ़ाइड मेमोरी)
- नोड इंटरकनेक्ट: ConnectX-7 200 Gbps RoCE के माध्यम से डायरेक्ट कनेक्शन (Tensor Parallel = 2, PyTorch डिस्ट्रीब्यूटेड बैकएंड)
- इंफ़रेंस इंजन: Aiden की रेसिपी, जो vLLM 0.21.1dev में b12x (GB10-विशिष्ट CuTe DSL कर्नेल का एक सेट) को एकीकृत करता है
- मॉडल: DeepSeek-V4-Flash ऑफिशियल FP8 (154 GB, FP8 अटेंशन, MXFP4 MoE—यह DeepSeek द्वारा जारी आधिकारिक प्रारूप है)
- कॉन्टेक्स्ट: 524,288 टोकन (512K), util 0.82, KV कैश 19.85 GiB, concurrency 3.89×
- मल्टी-टोकन प्रेडिक्शन (MTP): लगभग 62% की स्वीकृति दर के साथ स्पेक्युलेटिव डिकोडिंग (आउटपुट गुणवत्ता का त्याग किए बिना गति प्राप्त करना)
प्रदर्शन पर एक करीबी नज़र
इस बेंचमार्क के आंकड़ों से परे, मैंने अलग से शुद्ध डिकोड और प्रीफिल गति को मापा:
- शुद्ध डिकोड स्पीड (छोटा टेक्स्ट, TTFT को छोड़कर): लगभग 39 tok/s पर स्थिर
- प्रीफिल स्पीड (बड़ा कॉन्टेक्स्ट): 1,277 tok/s (यह b12x कर्नेल के बिना पुराने कॉन्फ़िगरेशन के 196 tok/s से लगभग 6.5x तेज़ है)
- लंबे कॉन्टेक्स्ट के साथ डिकोड: जैसे-जैसे मैंने इसे 8K → 64K → 128K → 256K → 512K → 768K तक बढ़ाया, डिकोड स्पीड में तेज गिरावट नहीं आई; वास्तव में, इसमें तेजी आई (768K पर 106 tok/s)। ऐसा इसलिए है क्योंकि DeepSeek का Sparse Attention (DSA) b12x कर्नेल में मूल रूप से लागू किया गया है, जिससे अटेंशन गणनाएँ कॉन्टेक्स्ट लंबाई से लगभग स्वतंत्र हो जाती हैं।
यह "बिना क्वांटाइज़ेशन, पूर्ण गुणवत्ता" वाला परिणाम है
एक और बिंदु जिस पर मैं जोर देना चाहता हूँ वह यह है कि DGX Spark की ओर मॉडल पर किसी भी अतिरिक्त क्वांटाइज़ेशन का उपयोग नहीं किया गया। हमने HuggingFace पर वितरित आधिकारिक 154 GB को ज्यों-का-त्यों लोड किया और DeepSeek द्वारा डिज़ाइन किए गए आधिकारिक क्वांटाइज़ेशन प्रारूप में चलाया: FP8 अटेंशन + MXFP4 MoE।
स्थानीय LLM की दुनिया में, विशाल मॉडलों को चलाने के लिए उन्हें IQ2 (2-बिट) या Q4 में संपीड़ित करना आम बात हो गई है, लेकिन ये निश्चित रूप से गुणवत्ता को कम करते हैं। वास्तव में, मैंने पहले DeepSeek-V4-Flash के IQ2XXS (2-बिट) संस्करण की कोशिश की थी और उसी बेंचमार्क पर 55/80 + एजेंट व्यवहार के पतन का परिणाम देखा था। क्वांटाइज़ेशन मुफ्त लंच नहीं है।
दो DGX Sparks के साथ 256 GB यूनिफ़ाइड मेमोरी सुरक्षित करने वाला एक कॉन्फ़िगरेशन पहली बार "पूर्ण गुणवत्ता पर विशाल मॉडल चलाने" के विकल्प को वास्तविकता बनाता है। मुझे लगता है कि यह संख्याओं से परे एक अधिक सार्थक प्रगति है।
Spark का "संतुलन" क्यों काम कर गया
इस परिणाम का समर्थन करने वाले तकनीकी तत्वों को तोड़ना:
- b12x कर्नेल सूट: CuTe DSL का उपयोग करके विशेष रूप से GB10 / SM12.x के लिए लिखे गए चार प्रकार के कर्नेल (NVFP4 फ़्यूज़्ड MoE GEMM, NVFP4 डेंस GEMM, FP8 पेजेड अटेंशन और स्पार्स MLA अटेंशन)। सामान्य vLLM में MARLIN पथ के विपरीत, ये डीक्वांटाइज़ किए बिना सीधे फ़्यूज़्ड मोड में गणना करते हैं।
- 200 Gbps RoCE डायरेक्ट कनेक्शन: हालाँकि TP=2 नोड-टू-नोड ऑल-रिड्यूस प्रति लेयर दो बार होता है, 200 Gbps डायरेक्ट कनेक्शन प्रभावी लेटेंसी को पतला रखता है, इसलिए यह डिकोडिंग के लिए अड़चन नहीं बनता है।
- 128 GB यूनिफ़ाइड मेमोरी × 2: Grace Blackwell का एक लाभ, जो HBM और DDR को अलग नहीं करता है। यह 154 GB ऑफिशियल FP8 मॉडल को दो इकाइयों में विभाजित करने की अनुमति देता है, जिसमें 512K कॉन्टेक्स्ट के लिए 19.85 GiB KV कैश के लिए पर्याप्त जगह होती है।
- DeepSeek Sparse Attention (DSA) का मूल कार्यान्वयन: b12x कर्नेल उस डिज़ाइन को सही ढंग से संभालते हैं जहाँ अटेंशन जटिलता GB10 के मूल स्पार्स ऑपरेशंस का उपयोग करके कॉन्टेक्स्ट लंबाई पर निर्भर नहीं करती है। इससे वह परिणाम सामने आया जहाँ कॉन्टेक्स्ट लंबाई के साथ डिकोड स्पीड नहीं गिरती है।
दूसरे शब्दों में, यदि इनमें से केवल एक तत्व—मेमोरी बैंडविड्थ, कंप्यूटिंग पावर, नोड कम्युनिकेशन, लॉन्ग कॉन्टेक्स्ट ऑप्टिमाइज़ेशन, या क्वांटाइज़ेशन गुणवत्ता—उत्कृष्ट होता, तो यह परिणाम नहीं होता। Spark इन सभी तत्वों को समान मूल्य सीमा में किसी भी सिंगल-मशीन कॉन्फ़िगरेशन की तुलना में उच्च स्तर पर प्रदान करता है। यही इसके "संतुलन" का वास्तविक स्वरूप है।
व्यावहारिक उपयोग में क्या बदलता है?
अमूर्त सिद्धांत से आगे बढ़ने के लिए, यहाँ कुछ ठोस लाभ दिए गए हैं:
- विशाल दस्तावेज़ों का सारांश और कोड विश्लेषण यथार्थवादी हो जाता है: 512K कॉन्टेक्स्ट और 1,277 tok/s की प्रीफिल स्पीड के साथ, आप लगभग 4 मिनट में एक पूरी किताब (~300,000 टोकन) लोड और सारांशित कर सकते हैं।
- एजेंट लूप फंसते नहीं हैं: 3.89× concurrency के साथ, आप चैट और लंबे-फ़ॉर्म सारांश एक साथ चला सकते हैं (उदाहरण के लिए, Hermes Agent के साथ) बिना डिकोड के ढहे।
- क्वांटाइज़ेशन विफलता के कारण कोई "एजेंट सिर्फ बातें कर रहा है" समस्या नहीं: यह एक जाल है जिसमें मैं IQ2-श्रृंखला मॉडलों के साथ कई बार फँसा; पूर्ण गुणवत्ता के साथ, ऐसा बस नहीं होता है।
- बिजली की खपत के मामले में Mac के साथ प्रतिस्पर्धी: इंफ़रेंस के दौरान दो GB10s की कुल बिजली खपत लगभग 100W–140W है, जो पूर्ण बूस्ट पर Mac Studio M3 Ultra के करीब है। 1.78x प्रदर्शन को देखते हुए, बिजली दक्षता भी बुरी नहीं है।
निष्कर्ष: TPS द्वारा LLM प्रदर्शन का न्याय करने का दौर खत्म हुआ
एक टोकन निकालने की तात्कालिक गति—डिकोड TPS—निश्चित रूप से एक महत्वपूर्ण मीट्रिक है। हालाँकि, यह "100 मीटर स्प्रिंट की टॉप स्पीड" जैसा है। व्यवहार में जिस चीज़ की आवश्यकता है वह है "समान सही उत्तर तक पहुँचने का समय," "उत्तर की गुणवत्ता," "एक साथ कितने चल सकते हैं," "कितना लंबा कॉन्टेक्स्ट संभाला जा सकता है," और "क्या एजेंट लूप काम करते हैं।" ये कुल स्कोर हैं।
इस परिणाम ने जो दिखाया वह यह है कि DGX Spark इस कुल स्कोर में आगे बढ़ने लगा है। हम एक ऐसे युग में प्रवेश कर चुके हैं जहाँ आप एक विशाल मॉडल को आधिकारिक गुणवत्ता पर, लंबे कॉन्टेक्स्ट के साथ, एजेंट अनुकूलता बनाए रखते हुए, Mac Studio की वॉल-क्लॉक स्पीड से 1.78x गति पर, सिर्फ दो इकाइयों को एक क्लस्टर में जोड़कर चला सकते हैं।
पिछले कुछ वर्षों में, लोगों ने कहा है कि "LLM सब कुछ मेमोरी बैंडविड्थ के बारे में है" और "डिकोड TPS ही सब कुछ है," लेकिन वास्तव में Spark चलाने के बाद, मुझे लगता है कि मेरा दावा कि "संतुलन ही व्यावहारिक प्रदर्शन है" अंततः संख्याओं द्वारा सिद्ध हो गया है।
RTX Spark की भी घोषणा की गई है, और ऐसा लग रहा है कि चीजें उम्मीद से अधिक गर्म हो रही हैं (हालाँकि कीमत आने के बाद माहौल शांत हो सकता है...)। मेरी उच्च उम्मीदें हैं कि समुदाय बढ़ेगा और अधिक ऑप्टिमाइज़ेशन और जानकारी जमा होगी!
Jensen वास्तव में अद्भुत हैं... क्या उनका शासन लंबे समय तक जारी रहेगा?
**
**
**
**
**
बोनस
तेज़-तर्रार पाठकों के पास यह आलोचना हो सकती है:
"तो क्या Mac Studio पर भी रॉ ऑफिशियल FP8 चलाना उचित तुलना नहीं होगी?"
"क्या तुलना अनुचित नहीं है? Mac Studio केवल इसलिए अनावश्यक हो गया क्योंकि इसे Q4 में क्वांटाइज़ किया गया था। यदि आप Mac Studio पर रॉ ऑफिशियल FP8 चलाते, तो क्या यह गुणवत्ता के मामले में समान स्तर पर नहीं होता?" यह एक उचित प्रश्न है।
सीधे मुद्दे पर आते हैं: वर्तमान में, Mac Studio पर व्यावहारिक गति से 'रॉ ऑफिशियल FP8 + MXFP4 MoE' चलाने का कोई तरीका नहीं है।
- सबसे पहले, कोई संगत इंफ़रेंस इंजन नहीं है।
ऐसा कोई इंजन नहीं लगता है जो Apple Silicon पर DeepSeek-V4-Flash के आधिकारिक प्रारूप (FP8 अटेंशन + MXFP4 MoE + Lightning Indexer + DSA Sparse Attention) का पूरी तरह से समर्थन करता हो (Claude Code खोज के अनुसार)।
- MLX (Apple का आधिकारिक Apple Silicon LLM फ्रेमवर्क): MXFP4 MoE फ़्यूज़्ड GEMM का कोई मूल कार्यान्वयन नहीं, कोई FP8 पेजेड अटेंशन नहीं, और DeepSeek के DSA Sparse Attention का कोई MLX कार्यान्वयन नहीं। यदि आप इसे चलाने की कोशिश करते हैं, तो आपको संभवतः bf16 में अपकास्ट करना होगा।
- llama.cpp: MXFP4 को सीधे लोड नहीं कर सकता, इसलिए इसे GGUF में पुनः-क्वांटाइज़ेशन की आवश्यकता है = इसका मतलब है कि यह Q4 / Q5 / IQ2 आदि में परिवर्तित हो जाता है, और अब "रॉ ऑफिशियल" संस्करण नहीं रह गया है।
- vLLM: Apple Silicon समर्थन सीमित है, और GB10-विशिष्ट कर्नेल जैसे b12x Mac पर नहीं चलेंगे।
- antirez/ds4: यह Q4 की धारणा के साथ DeepSeek V4 Flash के लिए विशेष रूप से MLX के आधार पर लिखा गया एक विशेष इंजन है। यह इसे Mac Studio पर चलाने का वर्तमान इष्टतम समाधान है, लेकिन यह "रॉ FP8" को संभालने के लिए नहीं बनाया गया है।
antirez ने विशेष रूप से Q4 के लिए DeepSeek V4 Flash के लिए एक समर्पित इंजन लिखा इस वास्तविकता को बताता है कि वर्तमान में Apple Silicon पर ज्यों-का-त्यों आधिकारिक गुणवत्ता चलाने का कोई व्यावहारिक रास्ता नहीं है।
- भले ही इसे bf16 अपकास्ट के साथ चलाया जाए, बैंडविड्थ लगभग पूरी तरह से समाप्त हो जाएगी।
बहस के लिए, मान लें कि किसी ने एक MLX कार्यान्वयन बनाया है जो आधिकारिक वेट को bf16 में अपकास्ट करता है। आप अनुमान लगा सकते हैं कि मोटे बैंडविड्थ गणना के साथ क्या होगा:
- DeepSeek-V4-Flash में लगभग 30B सक्रिय पैरामीटर के साथ MoE कॉन्फ़िगरेशन है।
- Q4 (4-बिट) पर, सक्रिय पैरामीटर लगभग 15 GB लेते हैं, और ds4 26.2 tok/s (मापा गया) प्राप्त करता है।
- यदि उसी मॉडल को FP8 (8-बिट) पर रखा जाता है, तो सक्रिय पैरामीटर लगभग 30 GB लेते हैं = 2x बैंडविड्थ आवश्यकता = सैद्धांतिक रूप से उसी इंजन पर ~13 tok/s।
- इसके अलावा, MLX में bf16 में अपकास्ट करने पर सक्रिय पैरामीटर के लिए लगभग 60 GB लगता है = 4x बैंडविड्थ आवश्यकता = सैद्धांतिक रूप से ~6.5 tok/s।
- चूँकि Mac Studio M3 Ultra की प्रभावी मेमोरी बैंडविड्थ लगभग 800 GB/s है, प्रत्येक टोकन के लिए 60 GB पढ़ने से बैंडविड्थ सीमा लग जाएगी।
दूसरे शब्दों में, Apple Silicon पर "कच्ची गुणवत्ता" लेने का विकल्प वर्तमान में "दोगुनी से अधिक गति का त्याग" करने की कीमत पर आता है। ds4 + Q4 के साथ 26.2 tok/s पर चलाना, पूर्ण-गुणवत्ता वाले bf16 के साथ केवल 6 tok/s प्राप्त करने की तुलना में अधिक व्यावहारिक विकल्प था।
- यहीं पर Spark का संरचनात्मक लाभ आता है।
दूसरी ओर, यह DGX Spark कॉन्फ़िगरेशन "रॉ ऑफिशियल FP8 + MXFP4 MoE नेटिवली" चलाता है। यह इसके द्वारा समर्थित है:
- b12x सूट के GB10-विशिष्ट कर्नेल, जिसमें NVFP4 फ़्यूज़्ड MoE GEMM और FP8 पेजेड अटेंशन को "बिना डीक्वांटाइज़ेशन के" चलाने के लिए कार्यान्वयन हैं।
- यह अभी तक Apple Silicon के लिए नहीं लिखा गया है।
- परिणामस्वरूप, Spark वर्तमान में "ज्यों-का-त्यों आधिकारिक गुणवत्ता" और "व्यावहारिक गति" पर चलाने का एकमात्र यथार्थवादी समाधान है।
संक्षेप में, यदि आप केवल हार्डवेयर बैंडविड्थ को देखते हैं, तो एकल इकाई के लिए Mac Studio का पूर्ण मान समान स्तर पर है, लेकिन "आधिकारिक क्वांटाइज़ेशन प्रारूपों को मूल रूप से चलाने वाले कर्नेल कार्यान्वयन" की उपस्थिति या अनुपस्थिति एक निर्णायक अंतर पैदा करती है। Spark का लाभ केवल चिप से नहीं, बल्कि b12x जैसे GB10-विशिष्ट सॉफ्टवेयर स्टैक के साथ पूरे संयोजन से आता है।
यदि कोई भविष्य में MLX में Apple Silicon के लिए MXFP4 फ़्यूज़्ड MoE GEMM, FP8 पेजेड अटेंशन और DSA Sparse Attention लिखता है, तो यह धारणा ध्वस्त हो जाएगी। परिदृश्य सामुदायिक कार्यान्वयन के आधार पर बदल जाएगा। अभी के लिए, तथ्य यह है कि Spark "आधिकारिक गुणवत्ता × व्यावहारिक गति" के संयोजन को प्राप्त करने में एक कदम आगे है।
ये Claude Code द्वारा प्रदान किए गए विश्लेषण के परिणाम हैं।
