DeepSeek बड़े पैमाने पर सस्ता है, लेकिन लोकल में महंगा क्यों है

• DeepSeek-V3 जैसे कुछ AI मॉडल बड़े पैमाने पर उपलब्ध कराए जाने पर सस्ते और तेज़ होते हैं, लेकिन लोकल रन में धीमे और महंगे पड़ते हैं
• इसका कारण GPU उपयोग दक्षता से जुड़ा throughput (प्रोसेसिंग क्षमता) और latency (विलंबता) के बीच का मूलभूत trade-off है
• बैच साइज़ बढ़ाने पर GPU अधिक कुशलता से काम करता है, लेकिन यूज़र को टोकन इकट्ठा होने तक इंतज़ार करना पड़ता है, जिससे latency बढ़ती है
• Mixture-of-Experts संरचना और deep pipeline वाले मॉडल को उच्च बैच और अधिक latency की आवश्यकता होती है
• लोकल single-user environment में काफी बड़ा बैच बनाना मुश्किल होता है, जिससे performance घटती है और लागत बढ़ती है
• OpenAI, Anthropic आदि आर्किटेक्चर की अपनी दक्षता, उन्नत batching strategy, या बहुत अधिक GPU लगाने जैसी विधियों से तेज़ response देते हैं

---

बैच inference और GPU दक्षता

• GPU बड़े matrix multiplication (GEMM) के लिए optimized hardware है
• कई यूज़रों के टोकन को एक साथ बड़े matrix में बैच करके चलाने पर कम round-trip overhead और memory efficiency की वजह से throughput तेज़ी से बढ़ता है
• inference server कई requests के टोकन को queue में जमा करता है, फिर उपयुक्त आकार का बैच चुनकर बड़े GEMM operations चलाता है
• इस प्रक्रिया में server को batch size (throughput बढ़ना) और waiting time (latency बढ़ना) के बीच trade-off चुनना पड़ता है

कुछ मॉडल बड़े बैच के लिए optimized क्यों होते हैं

Mixture of Experts (MoE) और बैच

• MoE संरचना (DeepSeek-V3, अनुमानित GPT-4) GPU दक्षता कम होने का एक प्रमुख कारण है
• सैकड़ों ‘expert’ blocks में से हर एक को अलग matrix multiplication चाहिए, इसलिए छोटे बैच में हर expert के पास कम काम होता है और दक्षता गिरती है
• सभी experts का पूरा उपयोग करने के लिए बहुत सारी concurrent requests चाहिए होती हैं, इसलिए service level पर बड़े बैच अनिवार्य हो जाते हैं
• कम wait (window 5ms) में experts बार-बार idle रहते हैं, जबकि लंबे wait (window 200ms) में उच्च दक्षता को अधिकतम किया जा सकता है

deep pipeline मॉडल के बैच संबंधी मुद्दे

• सैकड़ों layers वाले बड़े transformer कई GPUs में layer-wise split (pipelining) करके चलाए जाते हैं
• अगर एक बैच के भीतर टोकन की संख्या pipeline steps से कम हो, तो ‘pipeline bubble’ की समस्या आती है, जिससे throughput घटता है
• इसे रोकने के लिए बड़ा बैच (यानी लंबा इंतज़ार) ज़रूरी है, और इससे model response time बढ़ जाता है

queue को हमेशा पूरा भरा क्यों नहीं जा सकता

• सिद्धांत रूप में, अगर पर्याप्त concurrent traffic हो और queue हमेशा भरी रहे, तो bubble से बचा जा सकता है
• लेकिन व्यवहार में transformer attention चरण में batch करने के लिए matrix size (length) समान होना चाहिए, इसलिए single queue से इसे पूरी तरह चलाना कठिन है
• इसके अलावा FFN और attention चरणों को अलग करने पर memory overhead तेज़ी से बढ़ता है और data movement में inefficiency आती है

सारांश और निष्कर्ष

• बड़े बैच की प्रोसेसिंग GPU लागत घटाने और throughput बढ़ाने के लिए ज़रूरी है, लेकिन यूज़र के लिए waiting time लंबा हो जाता है
• Mixture-of-Experts और बड़े pipeline architecture वाले मॉडल स्वभावतः wait-based high-efficiency batching environment के लिए optimized होते हैं
• लोकल जैसे कम-traffic वाले environment में optimized बड़े बैच बन नहीं पाते, इसलिए GPU दक्षता तेज़ी से गिरती है और execution cost बढ़ती है
• OpenAI, Anthropic आदि तेज़ responsiveness दिखाते हैं, उसके कारण हो सकते हैं:
  • (1) वे MoE नहीं, बल्कि अधिक कुशल architecture इस्तेमाल करते हों
  • (2) batching/pipeline optimization और उन्नत inference tricks लागू करते हों
  • (3) ज़रूरत से भी अधिक GPU लगाकर speed खरीदी जाती हो

अतिरिक्त: prefill batch और मुख्य batch में अंतर

• transformer एक यूज़र prompt के prefill (लंबा input) को भी batch में चलाकर तेज़ initial inference दे सकता है
• लेकिन इस लेख में चर्चा किया गया batch कई यूज़रों की requests के वास्तविक token generation चरण में होने वाला throughput-latency trade-off batch है
• prefill batch का इस लेख में बताए गए concurrent large batch से सीधा संबंध नहीं है

संदर्भ बिंदु

• वास्तविक inference systems अक्सर continuous batching पद्धति भी साथ में इस्तेमाल करते हैं, जिसमें बैच भरते ही उसे तुरंत चलाया जाता है
• लेकिन मूल throughput-latency trade-off की संरचना वही रहती है

[GN⁺]

Hacker News राय

• मैं घर पर खुद DeepSeek V3 चला रहा हूँ, और मुझे लगता है कि इसकी लागत का बोझ कम है और इसकी गति व प्रदर्शन संतोषजनक हैं। बहुत से लोग सोचते हैं कि GPU के बिना बड़े मॉडल नहीं चल सकते, लेकिन मेरे अनुभव में CPU server उल्टा कम बिजली खपत करता है और ज़्यादा व्यावहारिक है। मेरा होम server मिड-रेंज EPYC 9004 series आधारित है, जिसमें 384GB RAM लगी Supermicro board इस्तेमाल हो रही है, और कुल लागत लगभग 4000 डॉलर है। अगर GPU के बिना सिर्फ़ भरपूर RAM इस्तेमाल की जाए, तो बिजली खपत कई बार gaming desktop से भी कम हो सकती है। मैं Unsloth Dynamic GGUF model का उपयोग कर रहा हूँ, जो लगभग 270GB RAM लेता है, और व्यवहार में मूल मॉडल जैसी लगभग समान quality के साथ कई तरह के काम सपोर्ट कर सकता है। मैं सामान्यतः इसे 16k context पर चलाता हूँ और ज़रूरत होने पर 24k तक बढ़ाता हूँ। token generation speed 9~10 प्रति सेकंड है, और context बड़ा करने पर 7 तक गिरती है। 2CPU वाले environment में इससे भी तेज़ token speed पर पूरा मॉडल चलाने के उदाहरण भी मौजूद हैं
  • जिज्ञासा है कि Unsloth Dynamic GGUF वास्तव में मूल मॉडल के कितना करीब performance देता है। मेरे अनुभव में साधारण कामों में फ़र्क़ ज़्यादा नहीं होता, लेकिन जटिल tasks या लंबे context में अंतर साफ़ दिख सकता है। यह सच है कि Unsloth बेहतरीन काम कर रहा है, लेकिन मूल non-quantized model से सीधी तुलना वाले evaluation data की कमी खलती है। यह भी एक व्यावहारिक सीमा है कि बहुत से लोगों और कंपनियों के पास मूल मॉडल सीधे चलाने की क्षमता नहीं है
  • जिज्ञासा है कि क्या Ollama जैसे tool से DeepSeek को code generation के लिए 40-core CPU और 256GB RAM पर चलाना संभव है। मॉडल के लिए लगभग 200GB memory allocate करने का विचार है
  • किसी ने कहा कि personal site खुल नहीं रही। अपना परिचय DigitalOcean के सह-संस्थापक Jeff Carr के रूप में देते हुए, संपर्क हो सके ऐसी उम्मीद जताई
  • मुझे लगा था कि high-speed memory वाले GPU अनिवार्य होंगे, इसलिए सवाल है कि क्या सच में GPU के बिना सिर्फ़ बड़ी memory से inference संभव है। non-unified memory के साथ यह कैसे संभव है, इसे लेकर जिज्ञासा है
  • इस बात से सहमति कि DeepSeek V3 open-weight models में वास्तव में बहुत practical है। कई कामों में उम्मीद से कम reasoning tokens की ज़रूरत पड़ती है, और इंतज़ार न करना इसका फ़ायदा है। ज़रूरत पड़े तो कभी भी higher reasoning option चुना जा सकता है, यह भी आकर्षक है। अगर खुद नहीं चलाना हो, तो कुछ providers पूरे context (16k) और 80tps के साथ, data का उपयोग न करने का वादा करने वाली service भी देते हैं। 9004 home server का उदाहरण काफ़ी बढ़िया setup लगा
• इस blog post की सामग्री प्रभावशाली लगी। निष्कर्ष (“batching की ज़रूरत है”) से सहमति है, लेकिन MoE model inference पर चर्चा और बहुआयामी होनी चाहिए, ऐसा मत है। बड़े batch के महत्वपूर्ण होने की वजह यह है कि LLM inference में bottleneck compute की कमी नहीं, बल्कि सारे weights को VRAM से लोड करना है। H100 के TFLOPS और memory bandwidth की तुलना करें, तो गणना के हिसाब से प्रति byte लगभग 300 FLOP तक की गुंजाइश दिखती है। batch जितना बड़ा होगा, लोड किए गए parameters पर उतना अधिक compute किया जा सकता है, इसलिए batch size को अधिकतम करना ज़रूरी है। इसी वजह से “roofline model” शब्द इस्तेमाल होता है। जैसे-जैसे model बड़े होते जाते हैं, पूरा model VRAM में नहीं समाता, इसलिए कई GPU या nodes में distribute करना पड़ता है। NVLink या Infiniband भी VRAM direct loading जितने तेज़ नहीं हैं, इसलिए bottleneck पैदा होता है। MoE की ताकत expert parallelism है, यानी अलग-अलग node पर अलग expert memory में रखकर node के बीच communication कम किया जा सकता है। लेकिन यह तभी संभव है जब सभी experts VRAM में आ जाएँ और KV cache जैसी overhead को संभालने लायक पर्याप्त nodes हों। आख़िरकार batch size को स्वाभाविक रूप से बड़ा होना ही पड़ता है, और ऐसा करना ही पड़ता है ताकि हर GPU कुशलतापूर्वक काम कर सके
  • अलग-अलग "expert" को एक node पर round-robin तरीके से assign करने और कई requests जब एक ही expert का उपयोग करें तभी मौक़े के अनुसार batch में बाँधने का सुझाव। यह batch की बजाय queue रखने जैसा है, इसलिए latency बढ़ेगी, लेकिन deep research workflow जैसे environment में यह काफ़ी स्वीकार्य हो सकता है
  • जब model एक GPU में नहीं समाता, तो इसे layer के हिसाब से बाँटकर, अगली layer संभालने वाले GPU को छोटा vector भेजते हुए inference किया जा सकता है—ऐसे वास्तविक उपयोग का उदाहरण दिया गया। Cerebras ने इसी तरह Llama 4 Maverick पर 2500 trillion tokens per second हासिल किए। fabric पर vector transfer बहुत तेज़ होता है, इसलिए idle time लगभग नहीं के बराबर रहता है
  • यह कल्पना कि अगर सभी nodes और weights analog circuit पर रखे जाएँ, तो शायद काम बहुत तेज़ हो सके
  • AMD में निवेश करने के तर्कों में से एक यह बताया गया कि पूरा model एक single chassis में समा सकता है, जिससे map/reduce शैली के फ़ायदे और network equipment लागत में कमी मिल सकती है। असहमति हो तो insight देने का अनुरोध
• जो लोग समय बचाना चाहते हैं, उनके लिए एक-पंक्ति सार: जवाब है batched inference। इसमें कई लोगों के prompts को एक model instance में एक साथ डाला जाता है, और यह सिर्फ़ घने time-slicing की तुलना में व्यवहार में कहीं अधिक कुशल है। इसी वजह से temperature और seed value फ़िक्स होने पर भी service response हर बार अलग हो सकता है, क्योंकि यह नियंत्रित नहीं किया जा सकता कि आपका prompt किन दूसरे prompts के साथ batch होगा। इस घटना को data exfiltration attack vector के रूप में भी कल्पना किया गया
  • batching का एक फ़ायदा यह भी है कि एक ही content की evaluation कई बार चलाकर यह देखना आसान होता है कि वास्तव में "hallucination" है या नहीं; बस batch-size जितने requests एक साथ डाल सकते हैं। सच तो यह है कि batching का विचार LLM में शुरू से था, लेकिन समय के साथ उसकी असली अहमियत महसूस होती है
  • मैंने सहज रूप से मान लिया था कि service providers हर model में हमेशा batching करते होंगे, लेकिन जिज्ञासा है कि क्या यह सिर्फ़ कुछ model families पर लागू होता है
  • जिज्ञासा है कि दूसरे prompts के साथ batch होने पर model response में बदलाव क्यों आता है
  • चिंता है कि अगर prompts दूसरे लोगों के साथ batch हो सकते हैं, तो यह एक बहुत प्रभावी attack vector बन सकता है
• संक्षेप में कहें तो:<br>- high sparsity वाले models में एक matrix multiplication को पर्याप्त compute-intensive बनाने के लिए बड़े batch (simultaneous request count) की ज़रूरत होती है<br>- इतना बड़ा batch संभालने के लिए लगभग 8~16 GPU चाहिए, ताकि model weights और MLA/KV cache को HBM में फ़िट कराया जा सके। लेकिन 8~16 GPU से कुल throughput कम रहता है, इसलिए हर user के लिए response speed वास्तव में बहुत धीमी हो जाती है। अनुभव अच्छा करना हो तो लगभग 256 GPU चाहिए
  • मैं 16 H100 (2 nodes) वाले environment में DeepSeek service दे रहा हूँ। प्रति request 50~80 tokens/second, और कुल मिलाकर हज़ारों tokens तक stable throughput देख रहा हूँ। first token generation time भी स्थिर है, और यह अनुभव हमारी पहुँच में किसी भी cloud service से तेज़ है
  • यह बात कि high sparsity = बड़े batch की ज़रूरत, इसकी कड़ी समझ में नहीं आ रही—ऐसी राय। sparse matmul को असल में बहुत सारे 0 वाले matmul जैसा मानकर थोड़ी व्यंग्यात्मक टिप्पणी की गई
• LLM के दृष्टिकोण से यह शानदार व्याख्या लगी। अनुमान है कि hyperscale LLM कंपनियाँ वास्तविक compute trace का बारीकी से विश्लेषण करके bottleneck ढूँढती होंगी, और load balancer, pipeline architecture, scheduler आदि से workload optimization को गंभीरता से लेती होंगी। efficiency के लिए ज़रूरी यह "batching precondition" high-security applications में नुकसानदेह हो सकती है, क्योंकि query isolation बेहद महँगी हो जाती है। nVidia की vGPU virtualization GPU memory को time-slicing से बाँटती है, लेकिन शक है कि हर context switch पर unload/reload करना पड़ता होगा और deduplication नहीं होता होगा। MIG भी memory को users के हिसाब से स्थायी रूप से बाँटता है, और दोबारा adjust करने के लिए GPU reboot चाहिए—96GB GPU को 4x24GB में बाँटना अच्छा नहीं लगता, यह भावना समझ आती है। यह भी कल्पना की गई कि अगर GPU board में secondary memory (DRAM) जोड़ दी जाए, तो PCIe से तेज़ी से तरह-तरह का matrix data ऊपर लाया जा सकेगा (HBM को cache की तरह इस्तेमाल करते हुए)।<br>Software Engineering जीवित रहने की व्यावहारिक गाइडबुक की साफ़गोई भरी लेखन शैली की भी प्रशंसा हुई
• राय है कि DeepSeek के लिए software optimization की गुंजाइश अभी बहुत है। अभी वास्तव में accessibility-केंद्रित optimization सिर्फ़ दो तरह के systems के लिए है: छोटे GPU + बड़ी RAM system (ktransformers), या बहुत बड़ी VRAM वाले system। 192GB VRAM + बाकी सामान्य memory वाली संरचना (DGX station, 2xRTX Pro 6000 आदि) में MoE की ताकत से DeepSeek 4bit काफ़ी तेज़ चल सकता है। DeepSeek में अगर prompt Chinese में न हो, तो ज़्यादातर experts सक्रिय नहीं होते। pruning भी इस माहौल में आसान है। आगे enthusiast systems का रुझान ऐसे software optimization के अनुकूल हो सकता है। Reddit पर 16x3090 (Pcie 3.0 x4) system में llama.cpp से लगभग 7 tokens/second हासिल करने का उदाहरण भी है, और एक 3090 अकेला भी पूरी VRAM को प्रति सेकंड 39 बार scan कर सकता है, इसलिए लगता है कि performance bottleneck कहीं और है
  • 16x3090 system की power consumption पूरे 5KW है। इस स्तर पर बिजली बिल देखें तो API इस्तेमाल करना ज़्यादा सस्ता पड़ेगा। इस बिंदु से कि DeepSeek में Chinese prompt न होने पर कई experts सक्रिय नहीं होते, model slimming और tokens को नज़दीकी experts की ओर route करने का विचार सामने आता है
  • एक MI300x अकेला 192GB VRAM दे सकता है
• मैं ML researcher भी नहीं हूँ और engineer भी नहीं, इसलिए उसी हिसाब से सुनें—ऐसा disclaimer। DeepSeek V3/R1 पुराने local models की तुलना में इतने बड़े हैं कि local run अपने-आप में महँगा होना सच है। active parameters कुल आकार से कम हैं, लेकिन इससे सिर्फ़ compute requirement घटती है, memory requirement नहीं, इसलिए ज़्यादातर मामलों में विशाल GPU के बिना व्यावहारिक उपयोग लगभग असंभव है। प्रमुख frontier (proprietary) models से सीधी तुलना भी नहीं हो सकती, क्योंकि उनके size जैसी जानकारी सार्वजनिक नहीं है। यह मानने का भी कोई आधार नहीं कि वे models local पर ज़्यादा सस्ते चलेंगे। उल्टा, MoE local/single-user environment के लिए बेहतर tradeoff दे सकता है, क्योंकि वहाँ batching की inefficiency उतनी बड़ी समस्या नहीं होती। batch बढ़ाने पर हर token की waiting latency 200ms तक पहुँच सकती है, लेकिन उसके बदले feed-forward compute (GEMM) बड़ा हो जाता है, जिससे गणना अधिक कुशल हो जाती है। जिज्ञासा है कि क्या batch बड़ा होने पर matrix खुद बड़ा हो जाता है। मेरे दिमाग़ में मॉडल यह है कि batching का उद्देश्य “input matrix size बढ़ाना” नहीं, बल्कि “memory bandwidth constraint को compute bottleneck में बदलना” है। weights को पहले से ही layer-दर-layer टुकड़ों में HBM → SRAM लाया जाता है, हर टुकड़े पर matrix multiplication होता है, और अंत में result जोड़ा जाता है। batching का फ़ायदा यह है कि वही weights इस्तेमाल करके कई computations साथ में की जा सकती हैं, जिससे FLOPS को अधिक कुशलता से भरा जा सके। OpenAI, Anthropic जैसे बड़े models सचमुच तेज़ जवाब देते हैं या नहीं, इस पर भी संदेह जताया गया, क्योंकि blog post में time to first token के आँकड़े नहीं थे, इसलिए दावा कमज़ोर लगा
  • मैं मूल पोस्ट का लेखक हूँ। ML researcher नहीं, बल्कि दिलचस्पी रखने वाला engineer हूँ। local single-user scenario में MoE का मतलब यह है कि multi-user batching का लाभ नहीं मिलता, इसलिए प्रति GPU throughput नाटकीय रूप से गिर जाता है। जब तक बहुत बड़े पैमाने की parallel inference requests न हों, तब तक ऐसा ही रहेगा। batching से input matrix का आकार बढ़ता है—अगर batch 1 हो तो compute 1xdim matrix पर होता है, और batch बढ़ने पर यह batch-size x dim बन जाता है, जिससे GPU utilization तेज़ी से बढ़ता है और bottleneck compute की तरफ़ शिफ़्ट हो सकता है। आख़िर में, DeepSeek अन्य models की तुलना में सचमुच धीमा है, यह बहुत इस्तेमाल करने पर महसूस होता है
• mixture of experts में बड़े batch की ज़रूरत होती है, लेकिन Apple Silicon का उपयोग करें तो batch size 1 पर भी यह काफ़ी उपयोगी हो सकता है—ऐसा विचार। unified memory की वजह से बड़े models local पर चल सकते हैं, लेकिन bandwidth और FLOPS कम होने से यह अपेक्षाकृत धीमा रहता है। MoE की विशेषता यह है कि हर बार process होने वाले parameters की संख्या कम होती है, इसलिए compute load कम होता है। वास्तव में कई लोगों ने Mac पर single-batch inference में DeepSeek को उपयोगी गति से चलाने का अनुभव साझा किया है। बेशक, पर्याप्त memory वाला setup खरीदना अभी भी महँगा है। अगर आगे Mac या ऐसी मिलती-जुलती architecture वाली मशीनें और आती हैं, तो उन्हें MoE models के लिए आदर्श जोड़ी कहा जा सकता है। तुलना के लिए, बड़ी RAM upgrade वाले Mac पर dense models चलाना काफ़ी अधिक पीड़ादायक है
• एक सहकर्मी से बात करते हुए निष्कर्ष निकला कि programming assistance के लिए LLM का विकास शायद अब उस दिशा में जा रहा है जो मूलभूत optimization से हटकर है। आंतरिक नियमों के कारण मैं लगभग हर काम में local 4~30B models और कई GPT series की तुलना करता हूँ। खासकर GPT-4o औसतन शानदार नतीजे देता है, लेकिन इसमें “जवाब के कुछ हिस्से गढ़ देने” की प्रवृत्ति भी है, इसलिए verification और iteration में काफ़ी समय लगता है। अंत में लगा कि “कम-parameter local models के मुकाबले effort के अनुपात में फ़र्क़ उतना बड़ा नहीं”। समस्या यह है कि दोनों ही बहुत धीमे हैं, इसलिए तेज़ iteration संभव नहीं। मुझे लगता है कि भले quality थोड़ी कम हो, लेकिन lightning-fast तुरंत जवाब देने वाला बड़ा-context model कहीं अधिक सुविधाजनक है। उम्मीद है कि वास्तविक quality metrics के सुधार से भी ज़्यादा “महसूस होने वाली iteration speed” को महत्व दिया जाए
• "धीमा और महँगा" कहने से असहमति। DDR4 memory वाले पुराने workstation पर भी llama.cpp से लगभग 1000 डॉलर के system में 3 tokens/second निकालने का उदाहरण दिया गया
  • इशारा किया गया कि हो सकता है आप असली DeepSeek model नहीं, बल्कि उसके distilled version को भ्रम में इस्तेमाल कर रहे हों। 192GB RAM से कम में असली model चलाना संभव नहीं