DSpark: speculative decoding का उपयोग करके LLM inference को तेज़ करना [pdf]

 (github.com/deepseek-ai)
1 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DSpark: speculative decoding framework जो semi-autoregressive generation और confidence scheduling को जोड़ता है
  • parallel drafter एक single forward pass में लंबे token block प्रस्तावित करता है, लेकिन tokenों के बीच dependency न होने से बाद के हिस्से में acceptance decay तेज़ी से होता है; DSpark इस समस्या को semi-autoregressive संरचना और load-aware verification से एक साथ हल करता है
  • भारी parallel backbone के साथ हल्का sequential module जोड़कर block के भीतर dependency inject की जाती है, जिससे draft speed बनी रहती है और suffix decay कम होता है
  • confidence head position-wise prefix survival probability का अनुमान लगाता है, और hardware-aware scheduler engine throughput curve के अनुसार हर request के लिए verification length को dynamic रूप से समायोजित करता है
  • offline benchmark में autoregressive baseline (Eagle3) और parallel baseline (DFlash) दोनों की तुलना में accepted length में लगातार सुधार, और DeepSeek-V4 production deployment में verification waste को दबाया गया
  • मौजूदा production baseline MTP-1 की तुलना में समान throughput पर user-level generation speed में 60–85% acceleration, और सख्त interactivity constraints के तहत पहले अप्राप्य performance region खोलकर Pareto frontier का विस्तार

समस्या की परिभाषा — parallel drafter की दो bottleneck

  • LLM tokenों को autoregressive तरीके से generate करता है; हर token के लिए सभी पिछले tokenों पर conditioned forward pass चाहिए, इसलिए inference latency output length के अनुपात में बढ़ती है, और कम GPU utilization तथा अधिक latency production serving की मुख्य bottleneck बनते हैं
  • speculative decoding में हल्का draft model candidate block प्रस्तावित करता है और target model एक single forward pass में verify करता है; rejection sampling के जरिए target distribution से मेल खाने वाला सबसे लंबा prefix accept किया जाता है, इसलिए quality loss के बिना acceleration मिलता है

  • autoregressive drafter की सीमाएँ

    • हर position को पिछले token पर condition करने से modeling power मजबूत होती है, लेकिन drafting cost block size के साथ linear बढ़ती है (𝑇draft ∝ 𝛾), इसलिए यह छोटे block और shallow structure तक सीमित रहता है

  • parallel drafter की सीमाएँ

    • सभी position एक साथ generate होने से draft latency लगभग block size से स्वतंत्र रहती है, इसलिए बड़े block (जैसे 𝛾=16) उपयोग किए जा सकते हैं
    • हर position को independently predict करने के कारण token dependency model नहीं हो पाती, जिससे multi-modal collision और बाद के हिस्से में acceptance rate में तेज गिरावट आती है
    • लंबे block को बिना सोचे-समझे पूरा verify करने पर throughput गिरता है, खासकर high-concurrency वातावरण में rejection risk वाले token batch capacity घेर लेते हैं
    • आदर्श verification length दो अक्षों पर बदलती है — data side पर (जैसे code जैसे structured request में acceptance rate ऊँचा, open-ended chat में कम) और system side पर (low load में अतिरिक्त verification लगभग मुफ्त, high load में यह दूसरे active request की capacity खा लेता है)

आर्किटेक्चर — दो परस्पर पूरक घटक

  • token per latency 𝐿 = (𝑇draft + 𝑇verify)/𝜏 है, और acceleration को तीन lever में घटाया जा सकता है: 𝑇draft कम करना, 𝜏 बढ़ाना, और effective 𝑇verify कम करना

  • decoding cycle: prompt ABC में target model अगला token D generate करता है (anchor की भूमिका) → parallel backbone और sequential head draft EFGH तथा confidence score c1–c4 बनाते हैं → scheduler prefix EFG बनाए रखता है और low-confidence token H हटाता है → target model parallel verification करता है; E·F accept होने और G reject होने पर correction token G* generate किया जाता है

  • semi-autoregressive generation

    • parallel drafter “of course”/“no problem” जैसी multiple continuation में “of problem” जैसे असंगत combination बना सकता है, क्योंकि हर position वास्तविक sampled previous token के बजाय सभी संभावित previous token पर marginalize करती है
    • parallel stage: parallel backbone (DFlash अपनाया गया) पूरे block पर single forward pass चलाता है, hidden state और base logits उत्पन्न करता है, और anchor को ही पहली prediction position मानकर 𝛾 input से 𝛾 logits निकालता है, जिससे draft computation घटती है
    • sequential stage: base logits में prefix-dependent transition bias 𝐵𝑘 जोड़ा जाता है, ताकि हर position block के भीतर पिछले sampled token पर condition करे; autoregressive factorization के जरिए causal block distribution बनती है, और sequential processing होने के कारण यह parallel stage की तुलना में काफी हल्का होना चाहिए (𝑇sequential ≪ 𝑇parallel)
      • Markov head: केवल तुरंत पिछले token पर निर्भर first-order transition तक सरलीकरण, पूरे 𝑉×𝑉 matrix को low-rank factorization 𝐵 = 𝑊1𝑊2 (default 𝑟=256) से approximate किया गया, जिससे storage और per-step computation न्यूनतम रहती है; “of” sample होने के बाद “course” को मजबूत और “problem” को दबाकर cross-mode collision कम होती है
      • RNN head: recurrent state 𝑠𝑘 के जरिए block के भीतर पूरे prefix history को संचित करता है, gated update से पिछले token से पहले की जानकारी तक पहुँचता है, लेकिन implementation जटिलता अधिक है और deployment गुणधर्म कम अनुकूल हैं

  • confidence-scheduled verification

    • draft acceptance rate domain के अनुसार बदलती है (code में ऊँची, open-ended chat में कम), और extra token verification cost engine load के साथ बदलती है; इसलिए केवल positive expected return वाले token की ओर target computation route करने के लिए एक unified mechanism चाहिए
    • confidence head: हर position 𝑘 पर scalar estimate 𝑐𝑘 ∈ (0,1) देता है, जो यह model करता है कि सभी पिछले token accept होने की शर्त पर position 𝑘 का token verification pass करेगा; यह हल्का linear projection + sigmoid संरचना है
      • analytical per-step acceptance rate 𝑐*𝑘 = 1 − ½‖𝑝𝑑𝑘 − 𝑝𝑡𝑘‖1 (draft और target distribution के बीच total variation distance) से supervised learning की जाती है
    • post-hoc calibration — Sequential Temperature Scaling (STS): hardware-aware scheduling को cumulative acceptance probability का absolute मान चाहिए, लेकिन neural confidence अक्सर overconfident होती है; चूँकि हर 𝑐𝑖 conditional probability है, इसे prefix cumulative product के रूप में factorize किया जाता है, और held-out validation set पर बाएँ से दाएँ ECE को न्यूनतम करने के लिए 1D grid search चलाया जाता है; यह order-preserving transform है, इसलिए token ranking बनी रहती है
    • Hardware-Aware Prefix Scheduler: verification length चयन को global throughput maximization समस्या के रूप में formalize किया गया; active request 𝑅 के लिए SPS(𝐵) (engine initialization पर एक बार profile की गई cost table) का उपयोग कर 𝛩 = 𝜏·SPS(𝐵) अधिकतम किया जाता है
      • survival probability 𝑎𝑟,𝑗 का 𝑗 के साथ monotonic non-increasing होना global sorting और greedy selection को block के भीतर prefix dependency स्वाभाविक रूप से मानने देता है, और 𝑂(1) cost-table lookup से incremental admit संभव होता है
      • lossless speculative decoding के लिए non-anticipating property चाहिए; Markov feature पिछले sampled token पर निर्भर करती है, इसलिए post-hoc global search 𝑥𝑟,𝑘 की जानकारी leak कर selection bias ला सकता है
      • early-stopping mechanism throughput गिरते ही तुरंत रुकता है, और admit निर्णय को केवल उस step तक processed prefix पर निर्भर बनाकर causality लागू करता है; global optimum की गारंटी तभी है जब objective 𝛩 unimodal हो

प्रशिक्षण

  • target sequence से कई anchor position को random sample करके 𝛾-token block को training data बनाया जाता है
  • target model पूरी प्रक्रिया में frozen रहता है, draft model embedding layer और LM head साझा करते हुए frozen रहता है, और केवल backbone drafter, sequential block तथा confidence head update होते हैं
  • training objective तीन terms के weighted sum का है — cross-entropy loss Lce, distribution matching loss Ltv, confidence loss Lconf
    • सभी term position weight 𝑤𝑘 = exp(−(𝑘−1)/𝛾) से weighted हैं, ताकि prefix-based verification में expected accepted length में अधिक योगदान देने वाली शुरुआती position पर ज़ोर रहे
    • Ltv total variation distance को penalize करता है; चूँकि per-step acceptance probability 1 − ½‖𝑝𝑑 − 𝑝𝑡‖1 के बराबर है, इसलिए Ltv को न्यूनतम करना expected acceptance rate को अधिकतम करने के बराबर है
    • default weight 𝛼ce = 0.1, 𝛼tv = 0.9, 𝛼conf = 1.0

प्रयोग — offline benchmark

  • सेटअप

    • target model: Qwen3-{4B, 8B, 14B}, Gemma4-12B / तुलना drafter: SOTA parallel drafter DFlash, autoregressive drafter Eagle3
    • पूरे framework और data के साथ सभी को फिर से train किया गया, Eagle3 का TTT horizon (7) DFlash और DSpark के block size (7) के साथ align किया गया, draft layer count Eagle3 के लिए 1 और DSpark तथा DFlash के लिए 5 रखा गया
    • training data: Open-PerfectBlend 13 लाख sample (chat 17.6%, math 39.4%, code 38.9%, instruction-following 4.1%), केवल prompt का उपयोग किया गया और response हर target model ने फिर से generate किए, 10 epoch training हुई
    • evaluation domain: math (GSM8K, MATH500, AIME25), code (MBPP, HumanEval, LiveCodeBench), everyday chat (MT-Bench, Alpaca, Arena-Hard), sampling temperature 1.0, और प्रति round accepted length 𝜏 रिपोर्ट की गई

  • मुख्य परिणाम

    • offline evaluation में confidence scheduler बंद रखा गया ताकि fixed block के साथ केवल draft quality को अलग से मापा जा सके
    • Qwen3-4B·8B·14B पर Eagle3 की तुलना में macro-average accepted length में 30.9%·26.7%·30.0% सुधार, और DFlash की तुलना में 16.3%·18.4%·18.3% सुधार, जबकि Gemma4-12B में भी लगातार लाभ दिखा, जिससे model family के बीच generalization की पुष्टि हुई
    • structured task में accepted length open-ended chat से अधिक रही (Qwen3-4B पर math 5.57·code 5.12 vs chat 3.49), और data predictability का यह अंतर static verification length की बर्बादी पैदा करता है, जो confidence scheduling की प्रेरणा बनता है

प्रयोग विश्लेषण

  • parallel generation autoregressive से बेहतर क्यों

    • यह उल्टा लगने वाला अवलोकन कि parallel और semi-autoregressive drafter पूरी तरह autoregressive Eagle3 से लंबी accepted length देते हैं, position-wise conditional acceptance rate (जहाँ denominator में केवल वे मामले गिने गए जिनमें पहले की सभी position accept हुई हों) से विश्लेषित किया गया
    • position 1 की capacity advantage: पहली position केवल target context पर निर्भर करती है; Eagle3 को 𝑂(𝛾) latency के कारण shallow network तक सीमित रहना पड़ता है, जबकि 𝑂(1) parallel drafter deep network उपयोग कर सकता है; DFlash की शुरुआत Eagle3 से ऊँची है (math 0.88 vs 0.81, chat 0.72 vs 0.53), और क्योंकि पहला token reject होने पर पूरा block बेकार हो जाता है, शुरुआती बढ़त अंतिम accepted length पर बड़ा प्रभाव डालती है
    • बाद की position में independence की सीमा: position 2–7 पर Eagle3 conditional certainty का उपयोग कर स्थिर या बेहतर होता है (chat 0.53→0.74), जबकि DFlash तेज़ी से गिरता है (code 0.87→0.78, chat 0.72→0.63), क्योंकि multi-modal collision असंगत suffix पैदा करती है
    • semi-autoregressive द्वारा suffix collapse में कमी: DSpark deep parallel backbone की ऊँची शुरुआती acceptance (math में 0.93 से शुरुआत) बनाए रखता है और हल्के sequential head से बाद की गिरावट को दबाता है, जिससे पूरे block में ऊँची और स्थिर conditional acceptance rate मिलती है

  • थोड़े से autoregression से भी बड़ा असर

    • drafter depth: block size 7 fix रखते हुए, DSpark की layer 1→5 बढ़ाने पर performance monotonic रूप से सुधरी, 1→2 layer पर marginal gain सबसे अधिक थी, और 2-layer DSpark ने 5-layer DFlash को सभी domain में पीछे छोड़ा, जिससे sequential head की parameter efficiency साबित हुई
    • proposal length: depth 5 fix रखते हुए, draft length {4,8,12,16} तक बढ़ाने पर DSpark हर length पर DFlash से बेहतर रहा, और 𝛾 बढ़ने के साथ अंतर और बढ़ा (𝛾=7 पर math 16%·code 15%·chat 18%, 𝛾=15 पर 30%·26%·22%), जबकि RNN head ने लंबी length पर केवल थोड़ा अतिरिक्त लाभ दिया, इसलिए default के रूप में Markov head अपनाया गया
    • latency overhead: batch 128 और context length {512,1024,2048,4096} के औसत में sequential block latency नगण्य रही, और draft length 4→16 बढ़ाने पर कुल round latency में केवल 0.2–1.3% जोड़ते हुए accepted length में अधिकतम 30% सुधार मिला

  • confidence head की भूमिका — सिर्फ लंबा नहीं, बल्कि अधिक समझदारी से verify करना

    • Qwen3-4B पर static threshold sweep से निदान किया गया; threshold बढ़ाने पर reject होने वाले token filter होने से acceptance rate बढ़ी, और chat में इसका प्रभाव सबसे बड़ा था (45.7%→95.7%), जबकि math (76.9%→92.5%) और code (67.6%→92.0%) में वृद्धि अधिक gradual थी
    • static threshold system load को नज़रअंदाज़ करती है, इसलिए dynamic serving में suboptimal है; confidence model में मजबूत discriminative power (ROC-AUC 0.81–0.90) है, लेकिन overconfidence (ECE 3–8%) भी है; STS लागू करने के बाद average ECE लगभग 1% तक घट गई, जिससे भरोसेमंद survival estimate मिले

production deployment

  • scalable training

    • DeepSeek-V4-Flash·Pro preview के साथ संयुक्त deployment किया गया; parallel backbone में mHC लागू MoE की 3 layer और sliding window attention 128 शामिल हैं, अधिकतम block size 𝛾=5 और Markov head उपयोग किया गया, confidence head को end-to-end train कर STS से calibrate किया गया
    • hidden state communication: पूरे vocabulary logits (𝑉≈10⁵) भेजने के बजाय LM head से ठीक पहले के hidden state ही communicate किए जाते हैं, और sampled position पर ही LM head को draft worker पर local रूप से चलाया जाता है, जिससे प्रति token communication complexity 𝑂(𝑑) तक घटती है
    • anchor-bounded sequence packing: fixed संख्या में draft anchor sample कर अलग-थलग prediction block को dense batch packing में रखा जाता है, और token-level attention index से कई independent sequence के बीच causal masking बनाए रखते हुए padding overhead से बचा जाता है

  • scheduler का वास्तविक उपयोग

    • दो टकराव थे — algorithm smooth unimodal capacity curve मानता है, लेकिन वास्तविक SPS(𝐵) discrete और stepwise गिरावट दिखाता है; और step-wise dynamic token scheduling continuous CUDA graph replay तथा Zero-Overhead Scheduling (ZOS) से टकराती है
    • asynchronous scheduling से अनुकूलन किया गया; ZOS को current step खत्म होने से पहले अगले batch size की ज़रूरत होती है, इसलिए दो step पहले के confidence output से verification capacity का अनुमान लगाया जाता है; current step के candidate को नवीनतम cumulative confidence से sort किया जाता है, और पिछले prediction केवल dynamic truncation length (𝐾) तय करने के लिए उपयोग होते हैं, जिससे dynamic top-𝐾 selection में cast किया जाता है
    • early-stopping हटाकर unconstrained global search सक्षम की गई; चूँकि मूल्यांकन केवल दो step पुराने history पर आधारित है, यह current token 𝑥𝑟,𝑘 की realization से अलग रहता है और causal barrier बनाता है, जिससे hardware cliff पार कर physical throughput अधिकतम करने और target distribution को सही-सही बनाए रखने दोनों का मेल संभव होता है

  • high-throughput, low-latency inference

    • production serving में per-request latency और total throughput दोनों का साथ में optimization होता है; इस deployment में KV-cache capacity और user traffic constraints के कारण effective batch size GPU saturation threshold से नीचे रहा, इसलिए दोनों लक्ष्य परस्पर विरोधी नहीं बल्कि उच्च सहसंबंध वाले रहे
    • variable-length query support एक चुनौती थी; fixed-length decode kernel में सीधे process करने पर padding और uneven load से GPU utilization घटती है, इसलिए सभी request token को flatten कर independent element की तरह process किया गया और sequence के भीतर dependency sparse attention के marker tensor से pass की गई; DeepSeek-V4 में केवल index-attention और compress kernel बदलकर variable-length routing support जोड़ा गया

  • वास्तविक user traffic पर प्रदर्शन

    • DSpark-5 (𝛾=5) की तुलना MTP-1 baseline से V4-Flash·Pro production engine में की गई; MTP-1 static multi-token drafter (MTP-3/5) high concurrency पर throughput घटाता था, इसलिए single-token setting बनाए रखी गई थी, और DeepSeek-V4-preview जारी होने के 2 हफ्ते बाद उसे DSpark से बदल दिया गया
    • V4-Flash: 80 tok/s/user SLA पर throughput में 51% सुधार, 120 tok/s/user पर MTP-1 operating limit के पास पहुँचने से नाममात्र 661% बढ़त (इसे absolute multiplier नहीं बल्कि interactivity frontier के विस्तार के प्रमाण के रूप में समझना चाहिए), और समान throughput पर प्रति user generation 60–85% तेज़
    • V4-Pro: 35 tok/s/user पर 52% सुधार, 50 tok/s/user पर नाममात्र 406% बढ़त, समान capacity पर 57–78% acceleration, और कुल मिलाकर throughput–interactivity frontier बाहर की ओर शिफ्ट हुई
    • load-adaptive behavior: मध्यम concurrency (V4-Flash में 200 से कम, V4-Pro में 150 से कम request) पर scheduler MTP-1 के static 2 token को बढ़ाकर प्रति request लगभग 4–6 token तक ले जाता है, जिससे प्रति forward pass accepted token बढ़ते हैं; concurrency saturation पर verification length को smoothly घटाया जाता है ताकि low-confidence token batch capacity पर कब्ज़ा करने से पहले prune हो जाएँ

  • सीमाएँ

    • prefix scheduler target verification waste को कम करता है, लेकिन parallel backbone द्वारा शुरुआती 𝛾-token block generate करने की fixed draft cost बनी रहती है; मूल रूप से low-acceptance वाले जटिल query में यह upfront computation वापस नहीं मिलती
    • भविष्य में draft model के भीतर difficulty-aware early exiting से ऐसे request को पूरे block generation को bypass करने की दिशा में सुधारा जा सकता है

निष्कर्ष

  • संरचनात्मक रूप से, भारी parallel backbone और हल्के sequential head को जोड़ने वाला semi-autoregressive paradigm स्वतंत्र parallel drafter में होने वाले तेज़ suffix collapse को कम करता है
  • system स्तर पर verification length selection को global throughput maximization समस्या के रूप में formalize किया गया, और calibrated survival probability तथा real-time engine load पर आधारित hardware-aware prefix scheduler के जरिए verification budget को dynamic रूप से समायोजित किया गया
  • व्यापक offline evaluation में SOTA autoregressive और parallel baseline दोनों को पार किया गया, और DeepSeek-V4 के वास्तविक deployment में high-load concurrency बनाए रखते हुए user-level generation acceleration तथा LLM serving Pareto frontier विस्तार के साथ इसकी practical value सिद्ध हुई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 6 시간 전
Hacker News की राय

  • DeepSeek सिर्फ सीमाओं को आगे नहीं बढ़ा रहा, बल्कि उसने प्रदर्शन सुधार कैसे हासिल किए, यह समझाने वाला बेहतरीन पेपर भी जारी कर रहा है
    अफसोस है कि अमेरिकी लैब अब ऐसे खुले खुलासे ज़्यादा नहीं करतीं, और लगता है AI में अभी सबसे दिलचस्प काम चीनी लैब कर रही हैं

    • Google अब भी काफी LLM आर्किटेक्चर रिसर्च सार्वजनिक कर रहा है
      उसने 2022 में LLM के लिए speculative decoding पेश किया था[1], और इस साल Gemma 4 मॉडल में speculative decoding करने वाला code भी जारी किया[2]

      [1] https://arxiv.org/abs/2211.17192

      [2] https://github.com/google-gemma/cookbook/blob/main/docs/mtp/...

    • अमेरिकी AI कंपनियों को भारी निवेश का हिसाब देना है, इसलिए वे valuation को सही ठहराने के लिए किसी जादुई moat की तलाश में लगती हैं
      ऐसी optimizations सार्वजनिक करने से उनका competitive advantage काफी घट जाएगा

    • शायद यह मजबूरी में किया गया खुलापन भी हो सकता है
      अनुमान यह है कि चूंकि अमेरिकी लैब frontier पर रास्ता बना रही हैं, DeepSeek अपने पास की चीजों को open source कर playing field को बराबर करना चाहता है

    • DeepSeek उन performance gains को commoditize कर रहा है जिन पर अमेरिकी लैब अपने investors को पैसा कमाकर देने के लिए निर्भर हैं

    • अब पश्चिमी दुनिया के लिए भी यह धारणा छोड़ने का समय है कि चीनी लोग सिर्फ “तानाशाही के तहत रहने वाले बहुत बुरे लोग” हैं

  • Hugging Face मॉडल पहले ही आ चुके हैं, और लगता है कि मूल मॉडल में speculative decoding module built-in है, जो काफी बढ़िया है

    Flash: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-DSpark

    Pro: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

    उम्मीद है यह local inference के लिए DwarfStar में भी आएगा
    antirez द्वारा 2-bit quantization जारी करने के बाद से Flash मॉडल का खूब इस्तेमाल कर रहा हूं

    • क्या इसके Qwen 27B पर भी लागू होने की संभावना है?

  • अभी तो लगता है कि DeepSeek लगभग इकलौती AI कंपनी है जो सिर्फ benchmark में नंबर 1 बनने के बजाय सच में innovate करने की कोशिश कर रही है
    OpenAI, Anthropic, Google जैसी जगहें लगातार innovation करने से ज़्यादा आपस में competition करने पर ध्यान देती लगती हैं

    • मुझे लगता है Moonshot(Kimi की developer) और Z.ai(GLM की developer) जैसी दूसरी चीनी लैब्स को भी इसमें शामिल करना चाहिए
      वे भी innovate कर रही हैं और अपनी research लगातार openly share कर रही हैं
      जहां तक पता है, Moonshot founder ने Kimi को चलाने वाली techniques समझाने वाला 40-minute video Twitter पर भी डाला था

    • अमेरिका की कई कंपनियों ने लंबे समय से अपनी strategy किसी भी तरीके से users को lock-in रखने को बनाया हुआ है
      quality और innovation दूसरे नंबर की चीजें हैं; वे market पर कब्जा करके users को बंद कर देना चाहती हैं, फिर regulation और lobbying पर असर डालकर अपनी power बनाए रखना चाहती हैं

    • वे कंपनियां भी innovation के जरिए आपस में compete कर रही हैं
      innovation customers को ज्यादा utility देता है, बस technology सार्वजनिक नहीं की जाती
      trade secrets किसी वजह से secrets होते हैं

      DeepSeek “सबसे innovative” इसलिए दिख सकता है क्योंकि बाहर से observe की जा सकने वाली चीज वही है
      यह वैसी ही गलतफहमी है जैसे यह निष्कर्ष निकाल लेना कि public में जिन लोगों ने अपनी तस्वीरें डाली हैं, वे पूरी आबादी में सबसे सुंदर हैं, सिर्फ इसलिए क्योंकि बाकी सब अपनी तस्वीरें public नहीं करते

    • बड़े research labs कम से कम 1 साल पहले से ही ऐसी चीजें कर रहे थे

    • Qwen भी वैसा ही है

  • मैं पिछले एक महीने से Kilo Code में DeepSeek v4 pro इस्तेमाल कर रहा हूं और यह शानदार है
    तेज, stable, बड़ा context window, और वाकई सस्ता
    इस महीने मैंने 1.5 अरब tokens इस्तेमाल किए और 40 डॉलर लगे; ज्यादातर cached थे, फिर भी सस्ता है

    • omp में DeepSeek को task और quicktask agents के लिए, और Sonnet को बाकी कामों के लिए इस्तेमाल कर रहा हूं
      AI खर्च काफी घट गया है, 40 डॉलर/day से 10 डॉलर/day पर आ गया
    • उत्सुक हूं कि आपने कौन सा provider इस्तेमाल किया
      OpenRouter पर 40 डॉलर जल्दी खत्म हो गए
      round-trip conversations ज्यादा नहीं थीं, context करीब 300k था, output लगभग 15 हजार lines
      opencode इस्तेमाल कर रहा था, लेकिन पता नहीं total token count दिखाया जा सकता है या नहीं
    • क्या आपने Kilo की तुलना Pi या OpenCode से की है?
      मैं उन दोनों से परिचित हूं, लेकिन हमेशा alternatives ढूंढता रहता हूं
    • Claude Code Pro में कितने tokens इस्तेमाल हुए, यह देखने का कोई तरीका है?

  • क्या यह 2022 के speculative decoding से ज्यादा नया या बेहतर है? https://arxiv.org/abs/2211.17192

    • उस paper को इस paper के ‘introduction’ और ‘background’ sections में cite किया गया है
      यह paper कुछ bottlenecks हटाकर improvement करने के बारे में है
    • लगता है focus draft model और verification policy को बेहतर करने पर है, ताकि DeepSeek के scale पर speculation wasteful verification work न बनकर pure speedup में बदल जाए

  • timing संयोग नहीं लगती
    लगता है वे openness और कड़े regulation का contrast दिखा रहे हैं

    • China = open, US = कड़ा regulation, यह अजीब timeline है
      हालांकि यह इसलिए संभव है क्योंकि यह Xi के goals से aligned है
    • Anthropic को नए AI models के जोखिमों को बढ़ा-चढ़ाकर पेश करने वाला media offensive चलाने के लिए किसी ने मजबूर नहीं किया
      सच कहें तो यह खुद की करनी है

  • title अच्छा नहीं है
    यह paper का title नहीं, बल्कि abstract की पहली line उठाई गई है
    LLM inference के लिए speculative decoding 2022 में ही प्रकाशित हो चुका था: https://arxiv.org/abs/2211.17192

    यह paper speculative decoding में improvement लगता है, लेकिन मैंने अभी पढ़ा नहीं है

  • नाम की वजह से पहले लगा कि यह DGX Spark से जुड़ा है
    संयोग से, हाल में DGX Spark की inference performance सुधारने पर काफी काम हुआ है, और MTP से 50~100% speedup मिला है, इसलिए DSpark भी उस उद्देश्य में काफी मददगार लग सकता है

  • शायद यह कुछ समय से production में इस्तेमाल हो रहा था, और एक महीने पहले कीमतें काफी घटा पाने की वजहों में से एक रहा होगा

    • सही
      section 5 actual deployment पर है
      5.1 में लिखा है “DSpark draft models are co-deployed with the preview versions of DeepSeek-V4-Flash and DeepSeek-V4-Pro”, और 5.4 में “MTP-1 represents the former production setup, having been superseded by DSpark two weeks following the DeepSeek-V4-preview release” लिखा है
    • Lookahead Sparse Attention ने भी बड़ी भूमिका निभाई होगी
      क्योंकि यह memory usage काफी कम कर देता है
    • सही पकड़ा
      उन्होंने कीमत 75% घटाई, और यह speed तथा inference optimization gains से बिल्कुल match करता लगता है

  • लगता है जल्द ही ऐसी दुनिया आएगी जहां use case, company, यहां तक कि individual के हिसाब से खास speculative decoding के लिए छोटे models की बहुत विविधता होगी

    • काश ऐसा हो, और hardware पाना असंभव न हो जाए

    • हां
      यह sophisticated guardrails से बहुत ज्यादा constrained रूप में होगा

      निश्चित रूप से दिशा यही है
      पूरी दुनिया निगल जाने की कोशिश करने वाले विशाल models की तुलना में returns तेजी से घटते हैं

    • लगता है आपने हाल के speculative decoding papers निश्चित रूप से नहीं पढ़े हैं
      किसी भी model को दूसरे model के लिए speculation में इस्तेमाल करना पहले से ही कुछ समय से संभव है
      पहले जो tokenization issue इसमें बाधा था, वह solve हो चुका है