Gemma 4 को तेज़ बनाना: multi-token prediction drafter के साथ तेज़ inference

 (blog.google)
3 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google ने Gemma 4 जारी होने के कुछ ही हफ्तों में 6 करोड़ से अधिक डाउनलोड पार कर लिए, और Gemma 4 परिवार के लिए multi-token prediction (MTP) drafter जारी किया
  • MTP drafter एक विशेष speculative decoding आर्किटेक्चर है, जो output quality या inference logic में गिरावट के बिना inference speed को अधिकतम 3 गुना तक बढ़ाता है, और इसे LiteRT-LM, MLX, Hugging Face Transformers, vLLM इस्तेमाल करने वाले hardware पर test किया गया
  • मानक LLM inference में एक single token बनाने के लिए अरबों parameters को VRAM से compute units तक ले जाना पड़ता है, जिससे memory bandwidth bottleneck बहुत बढ़ जाता है; MTP में एक हल्का drafter कई future tokens का प्रस्ताव रखता है, जिन्हें target model parallel में verify करता है
  • अगर target model draft tokens से सहमत हो, तो वह पूरी sequence को एक single forward pass में स्वीकार करता है और एक अतिरिक्त token भी generate करता है, इसलिए application सामान्यतः single-token समय में draft sequence और एक अतिरिक्त token output कर सकती है
  • MTP drafter target model activations और KV cache साझा करता है, और E2B·E4B edge models पर efficient embedder clustering लागू करता है; weights Hugging Face और Kaggle पर Apache 2.0 लाइसेंस के तहत उपलब्ध हैं

speculative decoding की ज़रूरत क्यों है

  • मानक LLM inference memory bandwidth से बंधा होता है, इसलिए latency bottleneck बड़ा हो जाता है
  • processor single token generate करने के लिए अरबों parameters को VRAM से compute units तक ले जाने में ही अधिकांश समय खर्च करता है
  • यह संरचना खासकर consumer hardware पर compute resources का पूरा उपयोग नहीं होने देती और latency बढ़ाती है
  • speculative decoding token generation और verification को अलग कर देता है
  • भारी target model, जैसे Gemma 4 31B, को MTP जैसे हल्के drafter model के साथ जोड़ा जाता है, ताकि खाली पड़े compute resources से एक साथ कई future tokens predict किए जा सकें
  • drafter, target model के एक token process करने से कम समय में कई tokens propose करता है, और target model उन प्रस्तावित tokens को parallel में verify करता है

MTP कैसे काम करता है

  • मानक large language model autoregressive तरीके से text generate करते हैं और एक बार में ठीक एक ही token बनाते हैं
  • इस तरीके में “Actions speak louder than…” के बाद “words” जैसे आसान continuation और जटिल logic puzzle सुलझाने में समान मात्रा का compute लगाया जाता है
  • MTP, Google researchers द्वारा Fast Inference from Transformers via Speculative Decoding में पेश किए गए speculative decoding का उपयोग करके इस inefficiency को कम करता है
  • अगर target model draft tokens से सहमत हो, तो वह पूरी sequence को एक single forward pass में स्वीकार करता है, और target model खुद भी साथ में एक अतिरिक्त token generate करता है
  • application आम तौर पर उतने समय में, जितने में single token generate होता है, पूरी draft sequence और एक अतिरिक्त token output कर सकती है

डेवलपर्स के लिए performance impact

  • डेवलपर्स के लिए inference speed अक्सर production deployment में एक बड़ा bottleneck बनती है
  • autonomous agents, coding assistants, और पूरी तरह on-device चलने वाले responsive mobile applications, जिन्हें तेज multi-step planning चाहिए, उनमें millisecond स्तर की latency भी मायने रखती है
  • संबंधित drafter के साथ Gemma 4 models इस्तेमाल करने पर ये फायदे मिलते हैं

  • responsiveness में सुधार

    • लगभग real-time chat, immersive voice applications, और agentic workflows की latency को काफी कम किया जा सकता है

  • local development में तेजी

    • personal computers और consumer GPUs पर 26B MoE और 31B Dense models को तेज़ी से चलाकर जटिल offline coding और agentic workflows को support किया जा सकता है

  • on-device performance बेहतर

    • E2B और E4B models edge devices पर तेज़ output देते हैं, जिससे device की battery usage कम करने में मदद मिलती है

  • quality में कोई कमी नहीं

    • क्योंकि final verification मूल Gemma 4 model ही करता है, इसलिए वही reasoning और accuracy स्तर बहुत अधिक speed पर मिलता है
    • NVIDIA RTX PRO 6000 पर Gemma 4 26B चलाने वाले उदाहरण में standard inference और MTP drafter के tokens-per-second की तुलना दिखाई गई है, और यह बताता है कि समान output quality पर latency लगभग आधी रह जाती है
    • तुलना का वीडियो डाउनलोड करके देखा जा सकता है

MTP drafter के internal optimizations

  • MTP drafter को तेज़ और सटीक बनाने के लिए कई architectural improvements लागू किए गए हैं
  • draft model, target model activations का स्वाभाविक रूप से उपयोग करता है और target model का KV cache साझा करता है
  • KV cache sharing की वजह से बड़ा model पहले से process किए गए context को दोबारा compute करने में समय बर्बाद नहीं करता
  • E2B और E4B edge models में final logits calculation बड़ा bottleneck बन जाता है, इसलिए generation को तेज़ करने के लिए embedder में efficient clustering technique लागू की गई है
  • hardware-specific optimizations का भी विश्लेषण किया गया है
  • Apple Silicon पर 26B mixture-of-experts model में batch size 1 पर unique routing challenges होते हैं, लेकिन कई requests को साथ process करने पर local setup में लगभग 2.2x तक speedup मिल सकता है
  • example batch size 4~8 है, और NVIDIA A100 पर भी batch size बढ़ाने पर इसी तरह के improvements दिखते हैं
  • visual architecture, KV cache sharing, और efficient embedder कैसे काम करते हैं, यह गहन तकनीकी विवरण में देखा जा सकता है

उपयोग का तरीका और उपलब्धता

  • Gemma 4 परिवार के लिए MTP drafter, Gemma 4 की तरह ही open source Apache 2.0 लाइसेंस के तहत उपलब्ध है
  • Gemma 4 के साथ MTP कैसे इस्तेमाल करें, यह दस्तावेज़ में देखा जा सकता है
  • model weights Hugging Face और Kaggle से डाउनलोड किए जा सकते हैं
  • तेज़ inference के लिए transformers, MLX, vLLM, SGLang, Ollama पर प्रयोग किया जा सकता है
  • Google AI Edge Gallery में Android या iOS पर इसे सीधे आज़माया जा सकता है
  • Google को उम्मीद है कि Gemma ecosystem, Gemmaverse, में यह speedup development को और तेज़ करेगा

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

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News टिप्पणियाँ

  • Gemma और Gemini दूसरे मॉडलों की तुलना में आउटपुट टोकन बहुत कम इस्तेमाल करते हुए भी टॉप-टियर benchmark performance के काफी करीब पहुँचते हैं
    Gemma और Qwen की तुलना करें तो Qwen थोड़ा बेहतर है, लेकिन किसी काम में 22 मिनट लगा देता है, जबकि Gemma अक्सर वही prompt 4 मिनट में पूरा कर देता है, भले ही button alignment गलत हो जाए
    ऊपर-ऊपर देखें तो Gemma, लीडिंग open model से 5~10% कम performance देता है, लेकिन समय सिर्फ 1/10 लगता है

    • महसूस करने पर, 15 डॉलर प्रति माह वाले Gemini बेसिक प्लान के साथ पूरे दिन coding करने पर भी limit नहीं लगती
      Claude या Codex के लिए लोग जैसे 100 डॉलर प्रति माह वाले प्लान तक upgrade करते हैं, वैसी ज़रूरत कभी महसूस नहीं हुई
      हालांकि Gemini की performance पिछले 1 साल में कुछ बार गिरी है, और rate limit भी कड़ी हुई है, इसलिए आगे भी यह इतना अच्छा रहेगा या नहीं, कहना मुश्किल है
    • Dwarkesh podcast में SemiAnalysis के Dylan Patel ने कहा था कि Google, कहीं ज़्यादा compute resources और TPU access की वजह से प्रतिस्पर्धियों से बड़े मॉडल संभाल सकता है
      एक ही intelligence level पर बड़े मॉडल आम तौर पर कम token इस्तेमाल करते हैं, इसलिए token usage का अंतर इससे समझ में आता है
    • Gemma तेज़ है, इसलिए इसे ऐसे GPU पर भी चलाया जा सकता है जो सामान्यतः इसके लिए छोटे पड़ते
      इसे 4070 पर चलाकर देखा, output बहुत ज़्यादा तेज़ तो नहीं था, लेकिन इस्तेमाल लायक था
      अभी तक जटिल कामों में नहीं आज़माया, वहाँ नतीजा अलग हो सकता है
    • अभी Claude बहुत trend में है, लेकिन Gemini इस्तेमाल करते हुए कभी समस्या नहीं आई और न ही बदलने की ज़रूरत महसूस हुई
      Google I/O के बाद शायद और लोग समझें कि Gemini कितना अच्छा है
    • बात सही है, लेकिन निष्पक्ष तुलना के लिए कुल token output जोड़कर देखना चाहिए
      अगर alignment की समस्या आती है, तो उसे ठीक करने के लिए input·output token एक बार और खर्च करने पड़ते हैं

  • llama.cpp में MTP support जोड़ा जा रहा है, और कम-से-कम Qwen मॉडल के लिए इस पर काम चल रहा है(https://github.com/ggml-org/llama.cpp/pull/20533)
    लगता है Gemma 4 भी जल्द इसमें जुड़ जाएगा
    पिछले कुछ महीनों में local·self-hosted मॉडल की quality और speed में सुधार चौंकाने वाला रहा है

    • एक और नया PR है और लगता है जल्द merge होगा: https://github.com/ggml-org/llama.cpp/pull/22673
    • कुछ दिन पहले निजी उपयोग के लिए Qwen3.6 से फिर Gemma 4 पर वापस आया, और बाद वाले के 26B version ने पहले वाले 27B से औसतन बेहतर performance दिखाई
      जो लोग लंबे समय से local मॉडल चला रहे हैं, उनके लिए यह सच में दिलचस्प दौर है
    • DFlash integration में भी दिलचस्पी बढ़ रही है: https://github.com/ggml-org/llama.cpp/issues/21978
      MTP की तुलना में यह कैसा होगा, जल्दी देखना चाहता हूँ
    • इसे oMLX में भी देखना चाहूँगा
      यह काफ़ी अच्छा tool था
    • MTP inference, inference stack में ठीक कहाँ फिट होता है, यह मुझे साफ़ नहीं है, लेकिन अगर कोई जानता हो कि MLX ecosystem में इसे implement किया जा सकता है या नहीं, तो जानना चाहूँगा

  • पश्चिमी दुनिया के open source मॉडल को लगभग अकेले Google ही संभाल रहा है
    Gemma 4 31B शानदार है
    लेकिन vision capability और जल्द आने वाले drafter सहित इसका सबसे अच्छा version 24GB VRAM में फिट करना काफ़ी तकलीफ़देह है
    मेरी build में और GPU नहीं जोड़े जा सकते, और top performance के लिए शायद एक और 4090 खरीदना पड़ेगा, जो बहुत महँगा है, या फिर पूरा सिस्टम बदलना होगा

    • llama.cpp में --no-mmproj-offload इस्तेमाल करने पर multimodal projector, यानी audio·image·PDF understanding वाला हिस्सा system RAM में रखा जा सकता है
      बेशक तब GPU acceleration नहीं मिलेगा, लेकिन VRAM बचेगा
    • फिर भी मुझे Qwen, Gemma से बेहतर लगता है
      इसे task के हिसाब से और tune भी किया जा सकता है, इसलिए inference speed को प्राथमिकता देनी है या reasoning और accuracy को, यह चुन सकते हैं

  • कंप्यूटर को लिखते हुए देखना पुराने BBS पर modem से connect होने वाले दिनों की याद दिलाता है
    यह 300 baud से 1200 baud पर जाने जैसा लगता है, इसलिए बड़ा सुधार है, लेकिन अभी भी काफ़ी धीमा है, और कभी न कभी हम सोचेंगे कि हम इसे झेल कैसे लेते थे

    • आज की स्थिति सच में dial-up era जैसी लगती है, और यह सोचने पर मजबूर करती है कि आगे का “broadband” दौर कैसा होगा
      token को बहते हुए देखना वैसा लगता है जैसे JPEG कुछ पंक्तियों में pixel लोड करता था, और उन तरह-तरह की loading·connection animations की भी याद आती है जिन्हें apps तब तक खुद implement करते थे जब तक speed पर्याप्त न हो जाए
      Cerebras और Taalas जो काम कर रहे हैं, वह उस दिशा में क्या संभव है, इसका दिलचस्प संकेत देता है
      यह कल्पना करना भी मज़ेदार है कि अगर आज के cutting-edge मॉडल को बेहद कम लागत पर प्रति सेकंड 10 लाख token दिए जा सकें, तो क्या-क्या संभव होगा
    • dial-up era की याद दिलाने वाली बात सही है, लेकिन 300 से 1200 की बजाय यह 4800 baud के ज़्यादा करीब लगता है
      Claude ने modem बनाम Claude की यह तुलना निकाली: 2368 characters के लिए 300 पर 1 मिनट 19 सेकंड, 1200 पर 19.7 सेकंड, 2400 पर 9.9 सेकंड, 14.4K पर 1.6 सेकंड, 33.6K पर 705ms, 56K पर 447ms, और Claude पर 7.9 सेकंड
    • यहाँ पोस्ट हुई एक startup ने AI को तुरंत जवाब देने लायक custom hardware बनाया था
      speed प्रति सेकंड हज़ारों token के स्तर पर थी

  • Google की strategy दूसरे frontier providers से थोड़ी अलग लगती है
    लगता है वह raw performance से ज़्यादा compute के मुकाबले performance efficiency पर ध्यान दे रहा है, और शायद इसी वजह से Gemini ऊपर से पीछे दिखता हो
    दूसरे providers capacity limit से टकरा रहे हैं और inference cost को subsidize करने की भी सीमा है
    Google की strategy इन मॉडलों को अपने मौजूदा अरबों users तक scale और deploy करने की लगती है

    • मुझे नहीं लगता कि Gemini पीछे है
      बल्कि यह नवीनतम GPT-5 और Claude family से अलग तरह की intelligence जैसा लगता है
      वे मॉडल productivity और work automation पर ज़्यादा केंद्रित होते जा रहे हैं, और लंबे, agentic self-correction reasoning loops के लिए optimize किए गए हैं
      Gemini कहीं ज़्यादा smart base model जैसा लगता है, और खासकर Deep Think mode में इसकी intuition कहीं गहरी लगती है, लेकिन long-range self-correcting agent loops में यह उतना अच्छा नहीं है
      पिछले कुछ महीनों में मेरा workflow ऐसा रहा है कि creative leaps और insight के लिए Gemini, और दोहराए जाने वाले या precision वाले काम के लिए Codex, Claude, GPT-5.5 Pro को प्राथमिकता देता हूँ
    • क्या सबकी strategy अब उसी दिशा में नहीं बदल रही?

  • कुछ समय local मॉडल से दूर रहने के बाद हाल में 26B A4B मॉडल को RTX 3090 पर vLLM 4-bit में सेट किया, और 1000 डॉलर से कम निवेश में जो speed और quality मिली, उससे पूरी तरह हैरान रह गया
    पहले Qwen के साथ कोशिश की थी, लेकिन वह unstable था और reasoning traces बेतुके ढंग से लंबे थे

    • qwen3.6 के शुरुआती quantized builds में कुछ टूटे हुए थे
      अभी भी थोड़ा नखरीला है, लेकिन थोड़ा-सा ठीक कर दें तो सच में शानदार है
      local मॉडल ही भविष्य हैं, और यह काफ़ी बढ़िया है
    • turboquant / Q4 इस्तेमाल करें तो यह 3060 पर भी चल जाता है, और लगभग 200 डॉलर के कार्ड पर ठीक-ठाक 40T/s मिल जाता है
    • A4B मॉडल बेहद तेज़ है और सामान्य queries के लिए बहुत अच्छा है
      coding tasks में यह Qwen 3.6 से साफ़ तौर पर पीछे है, लेकिन इसका मतलब ज़्यादा यह है कि Qwen मॉडल बहुत उत्कृष्ट हैं
    • 31B भी dense मॉडल के हिसाब से चौंकाने वाली तेज़ी दिखाता है
      मेरे कंप्यूटर पर दूसरे 30B मॉडल की तुलना में tg कम-से-कम दोगुना तेज़ है, शायद hybrid attention की वजह से
      हालांकि input processing थोड़ी धीमी है

  • क्या किसी ने इसे LM Studio में चलाने में सफलता पाई है, यह जानना चाहूँगा
    UI में option है, लेकिन यह activate होता नहीं दिखता

    • अभी mlx[1] या llama.cpp[2] में implement नहीं हुआ है, इसलिए थोड़ा समय लग सकता है
      [1] https://github.com/ml-explore/mlx-lm/pull/990
      [2] https://github.com/ggml-org/llama.cpp/pull/22673
    • चलता है
      क्योंकि छोटे मॉडल नहीं हैं, इसलिए यह जाँच लें कि आप Gemma sparse मॉडल तो इस्तेमाल नहीं कर रहे
      और मैंने workspace से सभी image मॉडल हटा दिए थे
    • आम तौर पर LM Studio तब समस्या करता है जब folder में mmproj file हो
      कभी-कभी इन्हें हटा देने पर यह दिखने लगता है
      लगता है ये files किसी तरह vision capability से जुड़ी हैं और speculative decoding को रोकती हैं, लेकिन वजह मत पूछिए
      Gemma में speculative decoding के लिए LM Studio की तुलना में llama-server वाला रास्ता बेहतर चला
    • दूसरे मॉडलों के साथ मैंने इसे चलाया है
      आम तौर पर provider, quantization वगैरह का एक-दूसरे से पूरी तरह मेल खाना ज़रूरी होता है
      सही matched set ढूँढने में थोड़ा समय लग सकता है

  • मेरी testing में Gemma 4 31B मॉडल ने coding tasks में Ollama के MLX runner का उपयोग करते समय सबसे बड़ा speedup दिखाया, लगभग 2x
    लेकिन quantization acceptance rate को काफ़ी घटा देता है, इसलिए काफ़ी ताकतवर Mac चाहिए
    बाकी तीन छोटे मॉडलों में draft model validation का समय performance gain का अधिकांश हिस्सा खा गया, इसलिए वे उतने अच्छे नहीं रहे
    अभी देख रहा हूँ कि tuning से और बेहतर performance निकल सकती है या नहीं
    Ollama 0.23.1 में ollama run gemma4:31b-coding-mtp-bf16 चलाकर इसे टेस्ट किया जा सकता है

  • llama.cpp में merge होने के बाद इसे बहुत जल्दी आज़माना चाहूँगा
    मेरे environment में Gemma 4 26B-A4B, Qwen3.6-35B-A3B से लगभग 3 गुना तेज़ है, इसलिए अगर इसमें 1.5x acceleration और जुड़ जाए तो यह बेहद आकर्षक होगा
    draft मॉडल भी आज़माए, लेकिन नतीजे सीमित रहे, और छोटे 3B draft मॉडल तथा dense 14B Ministral मॉडल ने भी पहले से ही बहुत overhead पैदा कर दिया था

    • vLLM में 5090 के साथ awq 4-bit quantization और MTP speculative decoding पर 120~180TPS मिलता है
      Gemma4 26B उसी quantization में 200TPS से ऊपर निकल जाता है
      यह भी महत्वपूर्ण है कि Qwen की inference efficiency बहुत कम है
      इसकी chain of thought औसतन Gemma से लगभग 3 गुना लंबी है

  • क्या यह operating system के branch prediction जैसा है?
    बस फ़र्क इतना है कि probability मॉडल के भीतर ही बनी हुई है, इसलिए यह कहीं अधिक भरोसेमंद रूप है

    • सोच मिलती-जुलती है, लेकिन failure mode बेहतर है
      branch prediction fail होने पर cycles बर्बाद होते हैं, जबकि यहाँ खराब guess का मतलब आम तौर पर सिर्फ bonus token न मिलना होता है
      https://arxiv.org/abs/2211.17192