- Google द्वारा घोषित Gemini Diffusion पहला LLM है जो Transformer के बजाय diffusion तरीके का उपयोग करता है
- यह Imagen या Stable Diffusion जैसे image models में इस्तेमाल होने वाले तरीके से मिलता-जुलता है
- यह मॉडल पारंपरिक autoregressive तरीके के बजाय, noise को चरणबद्ध तरीके से refine करने वाली diffusion प्रक्रिया के माध्यम से text generate करता है
- नतीजतन response speed बहुत तेज़ है, और प्रयोगों में इसने 857 tokens प्रति second के स्तर का प्रदर्शन दिखाया
- सटीक benchmark अभी पर्याप्त नहीं हैं, लेकिन Google का दावा है कि यह Gemini 2.0 Flash-Lite की तुलना में 5 गुना तेज़ है
Gemini Diffusion का अवलोकन
- Gemini Diffusion Google द्वारा हाल ही में पेश किया गया एक large language model (LLM) है
- यह पारंपरिक Transformer-आधारित LLM के autoregressive तरीके के बजाय, diffusion approach अपनाता है
- यह diffusion तरीका image generation models (Imagen, Stable Diffusion आदि) की तरह काम करता है, लेकिन इसे text generation पर लागू किया गया है
- इसकी प्रमुख विशेषताओं में तेज़ response speed और generation process के दौरान errors को कुशलता से सुधारने की क्षमता शामिल है
- उपयोग उदाहरण में "Build a simulated chat app" prompt पर यह कुछ ही seconds में HTML+JavaScript परिणाम देता है, और अधिकतम 857 tokens प्रति second की generation speed दर्ज करता है
Diffusion language model कैसे काम करता है
- पारंपरिक autoregressive language models tokens को एक-एक करके क्रमवार generate करते हैं, इसलिए उनकी speed धीमी होती है और output consistency की भी सीमाएँ होती हैं
- इसके विपरीत, diffusion models noise से शुरू होकर धीरे-धीरे परिणाम को बेहतर बनाते हैं और पूरे वाक्य या paragraph को कई चरणों में एक साथ process करते हैं
- इससे parallel token generation संभव होती है, जिसके कारण बहुत तेज़ result generation हासिल होती है
- text editing, mathematics, code जैसे वे क्षेत्र जहाँ तुरंत feedback महत्वपूर्ण होता है, वहाँ यह प्रभावी है
समान मॉडल और performance comparison
- पहले commercial diffusion LLM लगभग नहीं थे, और फरवरी 2024 में Inception Mercury project पहला उदाहरण बनकर सामने आया
- speed और performance के लिहाज़ से Gemini Diffusion, Google के अनुसार, Gemini 2.0 Flash-Lite के समान है, लेकिन speed लगभग 5 गुना अधिक है
- यह Cerebras Coder की तरह उच्च generation speed दिखाता है, और आगे objective benchmark data जोड़े जाने की उम्मीद है
अतिरिक्त विवरण और सुधार
- diffusion language model Transformer architecture को पूरी तरह replace नहीं करता, बल्कि autoregressive के स्थान पर diffusion तरीके से text generation संरचना को बदलता है
- Mercury और Gemini Diffusion दोनों Transformer-आधारित हैं, लेकिन पूरे input को एक साथ process करते हैं और उनका generation तरीका अलग है
- यह पारंपरिक BERT-style masking और restoration तरीके का विकसित रूप है, जिसमें masking ratio को धीरे-धीरे बढ़ाया जाता है, और सभी tokens masked होने की स्थिति में भी परिणाम को क्रमिक रूप से पूरा किया जाता है
- diffusion तरीका कई चरणों में केवल कुछ tokens को final करता है, और बार-बार final tokens का अनुपात बढ़ाकर पूरी sequence को पूरा करता है
- ऐसे diffusion LLM का मुख्य विचार क्रमिक restoration और parallel generation है
निष्कर्ष
- Gemini Diffusion speed और generation quality, दोनों में क्रांतिकारी विशेषताएँ दिखाने वाला नया LLM है
- यह image generation में सिद्ध diffusion model के लाभों को सफलतापूर्वक text generation क्षेत्र तक विस्तारित करता है
- विभिन्न practical applications में इसके उपयोग-मूल्य और भविष्य के benchmark results को लेकर उम्मीदें बढ़ रही हैं
1 टिप्पणियां
Hacker News की राय
Google के अंदर यह वास्तव में कैसे काम करता है, यह तो ठीक से नहीं पता, लेकिन हाल में RWKV तरफ़ कुछ काफ़ी दिलचस्प हुआ है। मौजूदा attention mechanism को पूरी तरह WKV (linear attention) से बदलने का प्रयोग किया गया, और यह पूरा काम सिर्फ़ post-training से किया गया। इससे यह संकेत मिलता है कि ज़्यादातर उपयोगी knowledge वास्तव में FFN (feedforward network) में हो सकती है, और attention ख़ुद शायद उतना unique या महत्वपूर्ण तत्व नहीं है जितना हम सोचते हैं। संबंधित लिंक भी देखना दिलचस्प होगा। दूसरी ओर, पहले से trained attention का उपयोग करते हुए GPT-2 speed training में सिर्फ़ FFN अलग से कितना तेज़ है, यह आज़माना भी नियमों के ख़िलाफ़ होते हुए एक रोचक प्रयास होगा, और मैं इस पर पेपर पढ़ना चाहूँगा। कल जो पढ़ा, उसमें कहा गया था कि किसी विशेष बिंदु पर सभी मॉडलों की embeddings आपस में बहुत मिलती-जुलती हो जाती हैं, इसलिए एक simple translator train किया जा सकता है, और अगर ये दोनों बातें सही हैं, तो embeddings और attention साझा करके पूरी training को कहीं तेज़ बनाया जा सकता है
पूरी इज़्ज़त के साथ कहूँ तो, मेरे हिसाब से attention का मतलब यह है कि नेटवर्क की सारी पिछली जानकारी को इनपुट बनाकर एक reverse-MoE neural network में डाल दिया जाए। यहाँ expert नेटवर्क के हिस्से नहीं बल्कि इनपुट के हिस्सों को execution target के रूप में चुनता है। यह तरीका काम करेगा, यह तो सबको पता था, लेकिन यह इतना inefficient था कि R या Python user भी इसे चलाने की नहीं सोचते। training ख़ुद इतनी धीमी थी कि इसे व्यावहारिक रूप से आज़माना भी मुश्किल था
ऐसा लगने लगा है कि 'Attention is all you need' का अर्थ वास्तव में किसी और तरह से भी निकाला जा सकता है
यह बात कि model embeddings आपस में बहुत मिलती-जुलती हो जाती हैं और उन्हें simple translator से map किया जा सकता है, यहाँ से आई है
मेरे हिसाब से attention नेटवर्क को बाँटकर parallel learning संभव बनाने का एक पूरी तरह arbitrary तरीका है। असली सफलता में योगदान देने वाली चीज़ layers के बीच की 'shortcut connection' है। training के दौरान यही शुरुआती layers को ज़्यादा प्रभाव देती है
आजकल transformer में इस्तेमाल होने वाले SDPA attention की relative importance कम होना पहले से जाना हुआ है। FFN, normalization, residual connection पूरी तरह अपरिवर्तनीय हैं, लेकिन attention को tokens के बीच जानकारी बाँटने वाली किसी और layer से आसानी से बदला जा सकता है, जैसे pooling, convolution, random mixing आदि
गति वाकई अविश्वसनीय रूप से तेज़ है। अब तक मुझे लगता है कि मॉडल का सबसे अच्छा उपयोग पूरी तरह नया code लिखना और तेज़ prototyping है। लेकिन बड़े codebase को, जिसे पहले से कई बार दोहराकर सुधारा गया हो, बेहतर बनाने में यह उतना मज़बूत नहीं लगा। इसका एक कारण यह है कि परिभाषा के अनुसार मॉडल उन चीज़ों के बारे में नहीं जान सकता जो codebase में 'शामिल नहीं' हैं। किसी चीज़ का code में 'न होना' भी अर्थपूर्ण signal होता है, और इसे व्यक्त करना काफ़ी कठिन समस्या है। मॉडल कितना भी smart हो, उस बिंदु पर उसके पास 'आंतरिक context और अनुभव' की कमी रहती है, इसलिए एक बुनियादी सीमा बनी रहती है। उदाहरण के लिए, अगर किसी बेहद कुशल developer को एक विशाल codebase देकर कोई खास समस्या तुरंत हल करने को कहा जाए, तब भी उस codebase को अच्छी तरह जानने वाला साधारण developer उसी समय में ज़्यादा मूल्यवान नतीजा दे सकता है
अगर communication style पर ध्यान दिया जाए, तो यह समस्या हल हो सकती है। आजकल मेरा मुख्य workflow यह है कि जब किसी बड़े काम, जैसे नई feature या refactoring, की ज़रूरत होती है, तो मैं o3 के साथ एक colleague की तरह बातचीत शुरू करता हूँ। context देने के लिए ज़रूरी source files बार-बार paste करता हूँ, और लक्ष्य तथा मौजूदा code की स्थिति पर high-level discussion करता हूँ। इस प्रक्रिया में मुझे लगता है कि मैं क्या करना चाहता हूँ और codebase का context दोनों स्पष्ट हो जाते हैं। उसके बाद मैं o3 से implementation plan माँगता हूँ, और उसे Codex को देकर source पढ़ने, files बदलने, tests चलाने जैसी automation की श्रृंखला चलवाता हूँ। PR आने पर कभी थोड़ी manual editing करनी पड़ती है, और कभी उसे सीधे merge भी किया जा सकता है। मैं मानता हूँ कि मॉडल को rich context चाहिए, लेकिन यह कोई मूलभूत सीमा नहीं बल्कि प्रभावी सहयोग की शैली का सवाल है। अभ्यास हो जाए तो productivity बढ़ती है, और मेरे लिए यह काम करने का ज़्यादा सुखद तरीका भी है
'जो चीज़ codebase में मौजूद नहीं है, वही एक अर्थपूर्ण signal रखती है' — इस दृष्टिकोण से मुझे गहरी सहमति है। मैं लंबे समय से software में हूँ, लेकिन इस मूलभूत सच्चाई को मैंने कभी इतनी स्पष्टता से महसूस नहीं किया था। यह एक शानदार insight है
अब तक के मेरे अनुभव में LLM मौजूदा अच्छे code की नकल करने में अच्छे हैं, लेकिन जब तक उनसे स्पष्ट रूप से नया और मौलिक हिस्सा न माँगा जाए, वे ख़ुद से उसे अच्छी तरह नहीं बना पाते। कई बार वे codebase को पर्याप्त रूप से ingest नहीं कर पाते, इसलिए प्रोजेक्ट के दूसरे हिस्सों को सीधे निर्दिष्ट करना पड़ता है। फिर भी, अगर Stable Diffusion की तरह 'negative prompt' दिया जा सकता, तो वह वाकई कमाल होता
मुझे जिज्ञासा है कि अगर LLM पूरा git history, issue tracker और meeting recordings तक context के रूप में पढ़ सके, तो कैसा परिणाम निकलेगा। बहुत बड़े context input से वास्तव में उपयोगी नतीजे मिलते हैं या नहीं, यह अभी देखना बाकी है
इस announcement ने सच में चौंका दिया। मुझे लगता है कि IO event की यह सबसे बड़ी घोषणा थी, लेकिन Veo 3 जैसी दूसरी ख़बरों के बीच दब गई, यह अफ़सोस की बात है। code generation में diffusion model का उपयोग बहुत बड़ा मायने रखता है। अगर transformer का उपयोग हो, तो यह DiT (diffusion transformer) परिवार में आएगा। कुछ साल पहले मैंने U-Net आधारित diffusion को मिलाकर बने एक hybrid model पर काम किया था, और उसके बाद भी इस क्षेत्र में बहुत प्रगति हुई है। आगे diffusion क्षेत्र में बड़ी छलाँग देखने को मिल सकती है
vision transformer की intuition को code पर लागू करने पर यह कैसे काम करेगा, यह जानने की उत्सुकता है। vision में हम noise से शुरू करके layer दर layer target image को अधिक स्पष्ट बनाते हैं। अगर यही सिद्धांत code generation पर लागू करें, तो उदाहरण के लिए 'Django इस्तेमाल करना है', 'endpoint list तय करना', 'ठोस code बनाना' जैसी abstraction को धीरे-धीरे नीचे लाने वाली hierarchical structure चाहिए होगी। लेकिन diffusion में backtracking mechanism नहीं होता, इसलिए अगर lower-level समस्या मिल भी जाए तो upper layer को तुरंत feedback देना सीमित हो जाता है। दूसरी ओर transformer हर token पर पूरे model को चलाता है, इसलिए समस्या के अनुसार backtracking और design change करना आसान होता है। मेरे mental model में कमी हो सकती है, इसलिए अतिरिक्त insight सुनना चाहूँगा
Veo 3 का performance और differentiation बहुत सहज रूप से दिखाई देता है, इसलिए वह चर्चा में आया। इसके उलट, text completion में हुई महत्वपूर्ण प्रगति का मूल्य समझने के लिए पहले से मौजूद उपलब्धियों और संभावित उपयोगों को समझना पड़ता है। अभी भी बहुत से लोग इस बात को लेकर आश्वस्त नहीं हैं कि LLM coding में वास्तव में उपयोगी हैं
diffusion आधारित code generation model सचमुच disruptive है। ऐसे model क्या कर सकते हैं, इसके कुछ सरल विचार ये हैं। function signature और result को fix रखकर बीच के tokens generate करना, यानी bidirectional information का उपयोग। दूसरा, पहले function layout की मोटी रूपरेखा लिखना, जैसे LLM को किसी लेख के 'chapter' लिखने को कहना, और फिर implementation की ओर धीरे-धीरे विस्तार करना। बड़े context में linters, AST information और तरह-तरह के signals की मदद से दिशा तय करते हुए iterative generation करना। आज़माने के लिए बहुत कुछ है
सिद्धांत रूप में इस तरीके के बड़े फायदे लगते हैं, और LLaDA जैसे मॉडल जिन्हें मैंने वास्तव में आज़माया, कम training resources के बावजूद प्रभावशाली थे। लेकिन perplexity जैसे मानकों पर वे अभी पीछे हैं। generation के दौरान जल्दी fixed हो जाने की प्रवृत्ति भी मज़बूत है, इसलिए text को गहराई से संशोधित करने में सीमा हो सकती है, खासकर जब masking probability बढ़ती है और simultaneous edits कठिन हो जाते हैं। फिर भी, वास्तविक प्रयोगों में काफ़ी व्यावहारिक परिणाम मिले
InceptionLabs वगैरह में डेमो पहले ही देख चुका हूँ, इसलिए मेरे लिए यह इतना चौंकाने वाला नहीं था
ऐसा लगता है कि इस ख़बर का मुख्य बिंदु दब गया है। यह एक बेहद तेज़ और शानदार InstructGPT है। आगे चलकर इसका उपयोग spelling check, codemod, code editor आदि में ज़रूर होगा। Instant edits feature की वजह से बिना बेकार additions और suggestions के बहुत तेज़ और सटीक text editing संभव है। मैंने ShaderToy sample code में variable names को ज़्यादा समझने लायक बनाने को कहा, फिर नतीजा copy करके चलाया, और वह अब भी सही चला — यह काफ़ी चौंकाने वाला था
diffusion का फ़ायदा सिर्फ़ speed नहीं है। शुरुआती benchmarks के अनुसार, समान parameters पर भी inference और planning में यह AR से बेहतर है। diffusion बीच में edits की अनुमति देता है, और उसे शुरुआती token bias की समस्या भी नहीं होती
दिलचस्प दावा है। क्या आप संबंधित benchmark या supporting material का लिंक साझा कर सकते हैं
AR ख़ुद लंबी planning में बाधा नहीं डालता, लेकिन आज के लोकप्रिय AR models के implementation में ऐसी सीमाएँ अक्सर होती हैं। सही distribution सीखने के लिए AR मूल रूप से बहुत महत्वपूर्ण है
व्यक्तिगत रूप से मैं इस दावे से सहमत हूँ या कम से कम चाहता हूँ कि यह सच हो, लेकिन revise diffusion text पर कोई paper या demo मैंने अभी तक नहीं देखा। मैं इसे इस्तेमाल करना चाहता हूँ, इसलिए paper की जानकारी साझा करें तो अच्छा होगा
text generation में diffusion technology लागू करने में मेरी लंबे समय से दिलचस्पी रही है। आखिरकार Google ने ऐसा model पेश किया, तो ऐसा लगा जैसे मेरी सोच की पुष्टि हो गई हो। प्रयोगों में इस्तेमाल होने वाले hardware के मामले में ज़्यादातर लोग paid services या high-end, कम से कम consumer grade के ऊपरी स्तर वाले, उपकरणों का उपयोग करते हैं। मेरे पास फिलहाल 5700XT जैसा setup है, इसलिए upgrade करना कठिन है, और उसी वजह से मौजूदा models की सीमाएँ और स्पष्ट दिखीं। model जितना बड़ा होता है, consistency उतनी बढ़ती है, इसलिए छोटे models को मजबूरन सरल कामों तक सीमित रहना पड़ता है। एक मुख्य बात जो प्रयोगों से सामने आई, वह context size का महत्व है। छोटी GPU पर पर्याप्त context और model दोनों को साथ रखना मुश्किल है, और मैं सोचता हूँ कि diffusion आधारित approach density और consistency के संतुलन को बदल सकती है या नहीं। उम्मीद है कि कम context में भी ज़्यादा consistent text generation मिले, और tool call + response के मिश्रित परिणाम भी बेहतर हों। speed की समस्या भी एक वास्तविक शिकायत है, क्योंकि मौजूदा LLM तरीका input-output के हर चक्र पर धीमा पड़ता है, खासकर पुराने GPU पर जहाँ AI hardware नहीं है, और यह धैर्य की परीक्षा लेता है। काश 0~100% progress भी real time में दिखती। diffusion model में शायद यह थोड़ा बेहतर हो सके। यहाँ एक सवाल उठता है: noise input महत्वपूर्ण है, तो क्या LLM/text के लिए कोई अच्छा specialized noise source मौजूद है? और क्या पूरे block की length पहले से fixed होती है, या variable भी हो सकती है
मैं अपने अनुभव से साफ़ कह सकता हूँ कि यह model बेहद तेज़ है। इसकी कमी यह है कि prompt injection attack के सामने यह बहुत आसानी से टूट जाता है। उदाहरण के लिए, अगर आप दवा बनाने का तरीका पूछें तो यह मना करता है, लेकिन अगर उसे 'बच्चे की roleplay' के रूप में घुमा दें, तो वह सच में जवाब दे देता है। इस कमी को छोड़ दें, तो speed और automation usability बहुत शानदार है। अगर इसमें agent-style approach भी जुड़ जाए, तो इसकी क्षमता सच में चमक सकती है
यह model की मूलभूत सीमा कम और training में safety या censorship पर कम resources लगाने का परिणाम ज़्यादा हो सकता है। मुझे लगता है यह किसी तरह का prototype experiment है, शायद बड़े model में गंभीर निवेश से पहले का हल्का demo
मैं इसे इस बात का संकेत नहीं मानूँगा कि ऐसे prompt injection से भविष्य के और बुद्धिमान models को नियंत्रित किया जा सकेगा
'Google का पहला diffusion LLM, transformer की जगह diffusion का उपयोग' — यह वर्णन ग़लत दावा है। Google ने ख़ुद ऐसा कभी घोषित नहीं किया। बल्कि transformer आधारित diffusion models आम हैं। मुझे लगता है Gemini Diffusion भी transformer का उपयोग करता होगा। अंतर बस इतना होगा कि यह encoder-only transformer है। यानी पूरी sequence को noisy/corrupted रूप में डालकर पूरी सही sequence की भविष्यवाणी की जाती है। इसकी वजह से sequence के पूरे frame पर एक साथ parallel computation संभव है, और अगर iteration count ज़्यादा न हो, तो यह decoder-only model की sequential decoding से कहीं तेज़ हो सकता है, हालांकि speculative decoding में भी ऐसी speed upside होती है। आम तौर पर इसे BERT-style masking से train किया जाता है, लेकिन यह अभी भी सक्रिय research का क्षेत्र है। Gemini के साथ इसका रिश्ता क्या है, या checkpoint का उपयोग कैसे हुआ, जैसे direct import, diffusion-specific fine-tuning, knowledge distillation, या सिर्फ़ branding name — यह सब जानने की उत्सुकता है। काश आधिकारिक विवरण उपलब्ध होते
यह हास्यास्पद रूप से तेज़ है। मेरा अनुमान है कि GPU हमेशा full throttle पर चलेगा, और batch processing से computation बचत का फ़ायदा लगभग नहीं होगा। लेकिन सोचने पर लगता है कि उसे सच में tradeoff कहना भी थोड़ा अजीब है। एक चिंता यह है कि diffusion objective, AR की तुलना में performance में पीछे रह सकता है। अगर ऐसा हुआ, तो multi-token AR model diffusion जैसी speed दे सकते हैं, या diffusion model को speculative decoding के draft generator की तरह इस्तेमाल किया जा सकता है
मैं जानना चाहूँगा कि आपको क्यों लगता है कि dLLM की quality arLLM से कम होगी। output को 'structured whole' — जैसे topic, key points, concepts, word tree — के रूप में बार-बार process किया जाता है, इसलिए quality उलटे बेहतर भी हो सकती है
यह structural tradeoff self-hosting environment में कहीं ज़्यादा फायदेमंद है। वहाँ बड़े batch की ज़रूरत नहीं होती, इसलिए cloud में लाभ कम है, लेकिन local LLM के लिए यह बड़ा advantage है
diffusion LLM को लेकर मैं बेहद उत्साहित हूँ। हमारी टीम voice → code आधारित game mechanics का सपना देख रही है, और diffusion शायद उसका missing piece बन सकता है। Cerebras और Groq शानदार हैं, लेकिन custom hardware होने की वजह से fine-tuning और scaling में सीमाएँ हैं। बाकी विकल्प active parameters 0.5b स्तर के MoE हैं, लेकिन फिलहाल उस प्रोजेक्ट में resources झोंकने की गुंजाइश नहीं है। अगर Google/DeepMind का कोई व्यक्ति यह देख रहा हो, तो कृपया API उपलब्ध कराएँ। हमारी टीम generative sandbox game बना रही है, और हमारा पहला काम ऐसा है जिसमें real time में monsters को command दी जाती है। prototype video भी है, जिसे देखना उपयोगी हो सकता है