DiffusionGemma: 4 गुना तेज़ टेक्स्ट जनरेशन

 (blog.google)
3 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DiffusionGemma टेक्स्ट diffusion तरीके से पूरे टेक्स्ट ब्लॉक को एक साथ जनरेट करने वाला Apache 2.0 लाइसेंस का 26B MoE प्रयोगात्मक ओपन मॉडल है
  • सामान्य autoregressive LLM की क्रमिक token generation के बजाय यह 256-token parallel generation का उपयोग करता है, जिससे dedicated GPU पर अधिकतम 4 गुना तेज़ टेक्स्ट जनरेशन मिलती है
  • inference के दौरान पूरे 26B में से केवल 3.8B parameters सक्रिय होते हैं, और quantization के बाद यह 18GB VRAM सीमा के भीतर उन्नत consumer dedicated GPU पर चल सकता है
  • bidirectional attention और iterative self-correction की वजह से inline editing, code infilling, amino acid sequence, mathematical graph जैसे non-linear structure वाले कामों में लाभ मिलता है
  • यह speed और parallel layout generation को प्राथमिकता देने वाला एक प्रयोगात्मक मॉडल है, इसलिए overall output quality मानक Gemma 4 से कम है; जिन applications में सर्वोच्च गुणवत्ता चाहिए, वहाँ मानक Gemma 4 deployment की सिफारिश की जाती है

डेवलपर्स के लिए नई वैल्यू

  • DiffusionGemma टेक्स्ट diffusion को खोजने वाला एक प्रयोगात्मक ओपन मॉडल है, जो सामान्य autoregressive LLM की token-by-token sequential processing से आगे बढ़कर पूरे टेक्स्ट ब्लॉक को एक साथ जनरेट करता है
  • यह मॉडल Apache 2.0 लाइसेंस के तहत उपलब्ध 26B Mixture of Experts(MoE) मॉडल है और GPU पर अधिकतम 4 गुना तेज़ टेक्स्ट जनरेशन देता है
  • यह Gemma 4 परिवार की per-parameter intelligence और Gemini Diffusion research पर आधारित है, और generation speed को अधिकतम करने के लिए एक नया diffusion head एकीकृत करता है
  • autoregressive Gemma 4 मॉडल high-quality production output के standard बने रहते हैं, जबकि DiffusionGemma उन researchers और developers के लिए डिज़ाइन किया गया है जो speed-critical interactive local workflow को explore करना चाहते हैं

  • मुख्य trade-off

    • तेज़ inference decoding bottleneck को memory bandwidth से compute की ओर ले जाता है, जिससे dedicated GPU पर अधिकतम 4 गुना तेज़ token output मिलता है
    • यह एकल NVIDIA H100 पर प्रति सेकंड 1000 से अधिक token और NVIDIA GeForce RTX 5090 पर प्रति सेकंड 700 से अधिक token जनरेट करता है
    • hardware accessibility उस architecture से आती है जिसमें पूरे 26B MoE में से inference के समय केवल 3.8B parameters सक्रिय होते हैं
    • quantization के बाद यह उन्नत consumer dedicated GPU की 18GB VRAM सीमा के भीतर फिट हो जाता है
    • bidirectional attention हर forward pass में 256 token को parallel जनरेट करता है, जिससे सभी token एक-दूसरे को refer कर सकते हैं
    • inline editing, code infilling, amino acid sequence, mathematical graph जैसे non-linear क्षेत्रों में इसका लाभ है
    • self-correction में मॉडल पूरे टेक्स्ट ब्लॉक को एक साथ evaluate करते हुए real time में गलतियों को सुधारने के लिए output को बार-बार refine करता है
    • इसकी experimental स्थिति और production recommendation स्पष्ट हैं; speed और parallel layout generation को प्राथमिकता देने के कारण overall output quality मानक Gemma 4 से कम है

  • fine-tuning उदाहरण

    • किसी खास task का performance fine-tuning से बेहतर किया जा सकता है
    • Unsloth ने DiffusionGemma को Sudoku हल करने के लिए fine-tune किया है; Sudoku ऐसा task है जिसमें हर token भविष्य के token पर निर्भर करता है, इसलिए autoregressive model के लिए यह कठिन होता है
    • DiffusionGemma की bidirectional attention Sudoku जैसे task को कहीं अधिक आसान बना देती है

टेक्स्ट के लिए diffusion क्यों

  • AI research community कई वर्षों से diffusion-based text generation को explore कर रही है, लेकिन इसे बड़े मॉडल पर लागू करना एक चुनौती बना हुआ था
  • DiffusionGemma इस समस्या को मॉडल के hardware उपयोग के तरीके को बदलकर हल करता है

  • मौजूदा मॉडलों के साथ trade-off

    • अधिकांश language model typewriter की तरह बाएँ से दाएँ एक बार में एक token जनरेट करते हैं
    • cloud में यह तरीका कुशल होता है, क्योंकि server हज़ारों user request को एक साथ batch करके hardware load साझा कर सकते हैं
    • लेकिन जब कोई single user इसे local पर चलाता है, तो word-by-word generation dedicated GPU या TPU का पूरा उपयोग नहीं कर पाती, और hardware अगले “key press” का इंतज़ार करते हुए अधिक समय बिताता है
    • DiffusionGemma 256-token paragraph का पूरा draft एक साथ बनाता है, जिससे computer processor को एक बार में बड़ा काम मिलता है
    • यह architecture model inference को sequential typewriter से बदलकर ऐसे बड़े printing press जैसा बना देता है जो पूरे टेक्स्ट ब्लॉक को एक साथ छापता है

  • local और low-concurrency inference के लिए speed-up

    • DiffusionGemma का speed-up local inference और low-concurrency inference के लिए डिज़ाइन किया गया है
    • high-QPS cloud serving में autoregressive model भी compute को कुशलता से saturate करने के लिए deploy किए जा सकते हैं
    • high-QPS environment में DiffusionGemma का parallel decoding लाभ कम हो जाता है, और serving cost अधिक हो सकती है
    • throughput का लाभ single accelerator पर low से medium batch size में सबसे अधिक मज़बूत होता है

टेक्स्ट diffusion कैसे काम करता है

  • text diffusion टेक्स्ट पर ऐसी प्रक्रिया लागू करता है जो AI image generation की उस विधि जैसी है जिसमें visual noise से शुरू करके बार-बार सुधार कर स्पष्ट चित्र बनाया जाता है
  • पहले चरण, canvas में, मॉडल random placeholder token से बने canvas से शुरू करता है
  • iterative refinement चरण में मॉडल कई pass चलाता है, सही token को स्थिर करता है, और उन्हें contextual clue की तरह उपयोग करके बाकी हिस्से को refine करता है
  • अंतिम refinement चरण में टेक्स्ट high-quality output की ओर converge करता है
  • चूँकि मॉडल generation के दौरान पूरे paragraph को प्रोसेस कर सकता है, इसलिए complex Markdown formatting को सही ढंग से बंद करना या लगभग real time में code जनरेट और render करना संभव हो जाता है

शुरुआत कैसे करें

  • प्रयोगात्मक model weights permissive Apache 2.0 लाइसेंस के तहत उपलब्ध हैं और Hugging Face पर एक्सेस किए जा सकते हैं
  • DiffusionGemma developer guide में integration का तरीका देखा जा सकता है, और A Visual Guide to DiffusionGemma में इसके internal mechanism को और गहराई से समझा जा सकता है
  • model serving MLX, vLLM, Hugging Face Transformers का उपयोग करके की जा सकती है
  • vLLM integration को Red Hat का समर्थन मिला है
  • तेज़ प्रयोग के लिए composability के लिए डिज़ाइन किए गए modular JAX toolbox Hackable Diffusion पर आधारित fine-tuning tutorial उपलब्ध है
  • fine-tuning को Unsloth और NVIDIA NeMo के साथ भी explore किया जा सकता है
  • llama.cpp का आधिकारिक समर्थन जल्द आने वाला है

optimization और runtime environment

  • NVIDIA के साथ सहयोग में पूरे hardware stack पर optimization किया गया है, जिससे consumer environment और enterprise system दोनों में compatibility और performance मिलती है
  • consumer environment में GeForce RTX 5090 और 4090 GPU के लिए quantization support है
  • enterprise environment में उन्नत NVFP4 kernel का उपयोग करने वाले Hopper और Blackwell पर high performance मिलती है
  • local desk-side deployment के लिए NVIDIA DGX Spark और DGX Station, तथा AI professionals के लिए RTX PRO भी लक्षित हैं
  • NVFP4 4-bit floating point native support compute throughput को तेज़ करता है, जिससे मॉडल अधिक गति और लगभग lossless accuracy के साथ चल सकता है
  • runtime विकल्प desktop dedicated GPU, Gemini Enterprise Agent Platform Model Garden, और NVIDIA NIM में से चुने जा सकते हैं

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

1 टिप्पणियां

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

  • हाल ही में OpenCode पर शिफ्ट होने के बाद मैंने अमेरिकी बड़े frontier research labs के मॉडल्स के अलावा कई मॉडल इस्तेमाल किए, और उम्मीद के उलट मुझे सबसे ज़्यादा पसंद Mercury आया।
    इसलिए नहीं कि वह “बहुत स्मार्ट” था, बल्कि इसलिए कि वह बेहिसाब तेज़ था। Prompt डालकर इंतज़ार करने वाले हालिया agent-style अनुभव की बजाय यह pair programming के ज़्यादा करीब लगा, और AI का फायदा लेते हुए भी AI से पहले वाली coding की कुछ feeling वापस आ गई, जिससे काम ज़्यादा मज़ेदार हो गया। यह prompt डालकर दिशा सही निकले, इस उम्मीद में बैठे रहने वाली slot machine जैसा नहीं लगा, और Gemini Flash Lite या GPT Mini/Nano जैसे छोटे मॉडल भी मैं ज़्यादा बार इस्तेमाल करने लगा। Open weights मॉडल आ रहा है, यह उत्साहजनक है और मैं इसे तुरंत टेस्ट करने वाला हूँ

    • अगर टेस्ट तेज़ी और कम लागत में चलाए जा सकें, और खराब या जल्दबाज़ी में लिखे गए कोड को पहचानने वाले low-cost metrics भी जल्दी बनाए जा सकें, तो जब समय महत्वपूर्ण हो, तब धीमे लेकिन बहुत बेहतर मॉडल की तुलना में तेज़ लेकिन थोड़ा कमज़ोर मॉडल बेहतर हो सकता है।
      मैंने cyclic complexity नहीं बल्कि वास्तविक complexity को मापने वाला metric रखा, और feature के मुकाबले जोड़ी गई अतिरिक्त complexity उचित सीमा में आने तक अपने-आप rollback होने दिया, तो LLM इस्तेमाल के नतीजे काफ़ी अच्छे रहे
    • Mercury-2 शानदार है। मैं इसे llm-consortium में अक्सर arbiter की भूमिका में इस्तेमाल करता हूँ।
      इसका context window अपेक्षाकृत छोटा है, इसलिए इसे बड़े consortium में इस्तेमाल करने के लिए इसे किसी recursive meta-consortium जैसा सेटअप किया जा सकता है:
      llm consortium save cns-glm -m glm-5.2 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-kimi -m k2.6 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-meta-glm-kimi -m cns-glm -m cns-kimi --arbiter mercury-2 --judging-method synthesis
      अब अगर cns-meta-glm-kimi को prompt दिया जाए, तो वह kimi और glm में से हर एक के 5 में सबसे अच्छा चुनकर, दोनों winning responses को synthesize करता है
    • यह coding के लिए local models पर कितना असर डालेगा, यह जानने की उत्सुकता है। अगर Qwen या Gemma 4 से कई गुना तेज़ diffusion model इस्तेमाल किया जाए, तो AI से पहले की तरह मुझे खुद ज़्यादा तैयारी करनी पड़ेगी, लेकिन हो सकता है वही बेहतर हो, और local में बहुत तेज़ और सस्ते मॉडल के साथ काम करना संभव हो।
      अगर लंबे और भारी computation n करने पड़ें, तो local hardware पर चलाने की लागत भी शायद कम होगी
    • मैं ठीक-ठीक समझता हूँ कि आपका क्या मतलब है। अपने personal project में Claude बहुत धीमा होने की वजह से परेशान कर रहा था, इसलिए मैंने Google Antigravity और Flash models पर स्विच किया, और speed difference बहुत बड़ा है।
      flow बेहतर बना रहता है और काम पर ज़्यादा ध्यान लगा रहता है। मुझे पता नहीं था कि speed इतना बड़ा फर्क ला सकती है। बहुत complex और बड़े codebase में Claude का धीमा response time task complexity के बदले स्वीकार किया जा सकता है, लेकिन Antigravity या दूसरे तेज़ मॉडल तब कहीं बेहतर बैठते हैं जब आप छोटे और हल्के तरीके से code लिखना, चलाना और debug करना बार-बार दोहराना चाहते हों
    • बिल्कुल, speed ही सब कुछ है। Boilerplate POJO या data classes को 300+ tok/s की पागलपन भरी speed से generate करना शानदार है, और ऐसे में Flash-Lite, GPT-5.5 से ज़्यादा उपयोगी लगता है।
      अगर बहुत धीमा हो, तो आप उस कमबख्त asynchronous waiting loop में फँस जाते हैं

  • Google लगातार अपनी ताकत दिखा रहा है। यह हैरान करने वाली बात है कि code या agent use cases में Gemini, Claude या OpenAI मॉडल्स से ज़्यादा प्रतिस्पर्धी नहीं दिखता, लेकिन यह साफ़ है कि Google के पास अब भी इंडस्ट्री-स्तर की बेहतरीन AI talent है।
    हालांकि Google का फोकस बड़े reasoning LLMs की बजाय ऐसे use cases पर लगता है जो फोन पर चलें या लगभग real-time हों। ऐसी efficiency improvements आगे चलकर AI में बहुत महत्वपूर्ण हो सकती हैं। किसी खास ecosystem में बाँधे रखने के लिए tokens को subsidy की तरह सस्ता देने का दौर खत्म होता दिख रहा है, और अब वास्तविक लागत चुकाने का समय आ रहा है। जो कंपनी सचमुच स्मार्ट मॉडल्स को cost-effective तरीके से चलाने का तरीका ढूँढ लेगी, वही जीतेगी। DeepSeek, GPT 5.5 या Opus 4.8 की तुलना में एक अंक वाले गुणक से भी ज़्यादा सस्ता है, और भले ही वह दोनों से कमजोर है, लेकिन खतरनाक रूप से कमजोर नहीं है। अगर सबसे अच्छा coding model इंसानी समय को काफ़ी बचाता हो, तो मैं 10 गुना ज़्यादा कीमत देने को तैयार हूँ, लेकिन जब हालिया benchmarks में GPT 5.5 Pro, DeepSeek से 200 गुना से भी ज़्यादा और Opus 4.8 से लगभग 30 गुना महँगा पड़ता है, तो 100 गुना का अंतर स्वीकार करना मुश्किल है

    • Fable की लागत Opus से दोगुनी है और यह GPT-Pro से भी काफ़ी प्रतिस्पर्धी लगता है, इसलिए अगर अत्यधिक संवेदनशील safety guardrails बड़ी समस्या न हों, तो यह ठीक-ठाक विकल्प हो सकता है।
      Google के पास भी इस क्षेत्र में अपना “Deep Research” विकल्प है और लगता है कि वह अच्छी तरह काम करता है। DeepSeek की अच्छी बात यह है कि इसे API लागत के बिना local hardware पर चलाया जा सकता है। अगर यह बात आपके लिए महत्वपूर्ण है, तो Opus या GPT से थोड़ा पीछे होना कोई बड़ी समस्या नहीं है
    • आखिरकार लगता है कि Google ही जीतेगा। वह performance per watt और performance per dollar जैसे महत्वपूर्ण हिस्सों पर ध्यान दे रहा है।
      वह अपना inference hardware खुद बना रहा है, और latency तथा computation overhead घटाने के लिए edge computing की ओर बढ़ रहा है। बड़े LLMs अभी भी cost-effective नहीं हैं, और Google अपने प्रतिस्पर्धियों को उपभोक्ताओं को लागत से कम पर “बेचने” के लिए निवेश की पूँजी जलाने दे रहा है। AI bubble फटने के बाद भी Google जैसी कंपनियाँ ठीक-ठाक बची रहेंगी, और यह bubble कुछ बड़ी कंपनियों की बाहरी परतें उतार देने जैसा लगता है

  • कुछ प्रतिक्रियाएँ diffusion approach के फ़ायदों को नज़रअंदाज़ कर रही हैं। फ़ोन या कंप्यूटर GPU जैसे edge devices पर इसका बड़ा असर हो सकता है
    LLM decoder को पहले के सभी tokens को ध्यान में रखना पड़ता है, इसलिए वह tokens को एक-एक करके compute करता है। मौजूदा LLM decoders तब अच्छी तरह scale होते हैं जब load इतना हो कि कई inference को batch में जोड़ा जा सके, और उस माहौल में diffusion का फ़ायदा सीमित रहता है। Edge पर समस्या अलग है। Inference accelerator RAM से GB-स्तर के weights बार-बार लाने में भूखा रह जाता है। LPDDRx/GDDRx जैसी consumer RAM में HBM की तुलना में कम bandwidth होती है, और requests serial होती हैं, इसलिए shared weight computation को batch में नहीं जोड़ा जा सकता। Diffusion tokens को parallel में compute कर सकता है, इसलिए यह memory bandwidth bottleneck को कम करता है

    • Edge devices में सिर्फ memory bandwidth की कमी नहीं होती, compute performance भी बहुत सीमित होती है। व्यवहार में, बहुत batch न होने पर भी उपलब्ध compute जल्दी saturate हो जाता है और साफ़ thermal तथा power limits से टकराता है
      Edge inference में यह कहना भी सही नहीं कि “requests स्वभाव से serial हैं।” एक ही समय में कई requests, यानी कई chats चल सकती हैं, और अगर KV cache रखने लायक memory capacity हो तो batching लागू की जा सकती है। अगर diffusion model ज़्यादा compute लेकर कम quality दे रहा है, और memory bandwidth की बचत भी अस्पष्ट है, तो यह कैसे मदद करेगा समझना मुश्किल है
    • बात कुल मिलाकर सही है, लेकिन इसमें attention और autoregressive/causal structure को मिलाकर कहा जा रहा है। ज़्यादा compute इस्तेमाल न कर पाने की असली समस्या autoregressive/causal structure है
      Diffusion में भी attention इस्तेमाल हो सकता है, और यह model वास्तव में attention का उपयोग करता है

  • NVIDIA इस model के लिए free endpoint दे रहा है। विवरण https://build.nvidia.com/google/diffusiongemma-26b-a4b-it पर है, और account बनाकर शायद phone verification भी करनी होगी
    इससे pelican बनवाकर भी देखा: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

    • अगर model काफ़ी तेज़ हो, तो animation frames भी माँगे जा सकते हैं। जैसे frame 1 में दायाँ पैर 12 बजे, बायाँ पैर 6 बजे, frame 2 में दायाँ पैर 3 बजे, बायाँ पैर 9 बजे
      फिर tokens per second नहीं, बल्कि स्वाभाविक रूप से pelican frames per second रिपोर्ट करना चाहिए
    • मैंने कुछ हफ़्ते पहले sign up किया था, लेकिन प्रक्रिया पूरी करने के बाद भी account अभी तक verify नहीं हुआ। जब तक account verify न हो, API इस्तेमाल नहीं की जा सकती

  • DiffusionGemma जैसे text diffusion models कैसे काम करते हैं, इसका अच्छा visual explanation: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

  • कुछ दिन पहले तक मुझे लगता था कि Google, एक साल पहले I/O में demo दिखाने के बाद, diffusion text generation models के बारे में बिल्कुल बात नहीं कर रहा है
    अफ़वाह थी कि इसे चलाना बहुत महँगा है, लेकिन अगर दिए गए chart की तरह उसी 1x H100 hardware पर DiffusionGemma और सामान्य Gemma की तुलना करें, तो ऐसा नहीं लगता। Gemma से थोड़ा कमज़ोर होने के अलावा, इतनी speed की कमी क्या है यह जानने की उत्सुकता है

    • “इतनी speed की कमी क्या है” का जवाब शायद यह हिस्सा है:
      “DiffusionGemma की speedup local और low-concurrency inference के लिए design की गई है। High-QPS cloud serving में autoregressive models को efficiently batch करके compute saturate किया जा सकता है, इसलिए DiffusionGemma का parallel decoding advantage कम हो जाता है और serving cost अधिक हो सकती है”
    • एक standard autoregressive model में, अगर 256 users हों, तो उदाहरण के लिए एक बार में 256 tokens generate किए जा सकते हैं। यह तरीका एक user के लिए 256 tokens generate कर सकता है, लेकिन इसमें कई forward-pass steps की ज़रूरत होती है
      इसलिए diffusion process ज़्यादा GFLOPs इस्तेमाल करती है, और अगर users काफ़ी हों तो memory और compute का संतुलन पहले ही बनाया जा सकता है

  • “DiffusionGemma इस inefficiency को उलट देता है। शब्दों को क्रम से predict करने के बजाय, यह पूरे 256-token paragraph का draft एक साथ बनाता है। Computer processor को एक बार में काम के बड़े chunks देकर यह hardware का अधिकतम उपयोग करता है। यह model inference को एक-एक अक्षर टाइप करने वाली typewriter से upgrade करके ऐसा विशाल printing press बना देता है जो पूरे text blocks एक साथ छापती है”
    “Inference के दौरान कुल 26B आकार के mixture-of-experts (MoE) model की तरह काम करता है, जिसमें सिर्फ 3.8B parameters active होते हैं, और quantization के बाद यह high-end consumer dedicated GPU की 18GB VRAM सीमा के भीतर आराम से फिट हो जाता है”
    यानी Gemma 4 26B, ollama के साथ मेरे 24GB GPU पर बहुत तेज़ चलने वाला MoE model है। यह speculative decoding जैसा लगता है, लेकिन मेरा ख़याल था कि MoE models में वह काम नहीं करता। जो लोग इसे नियमित रूप से follow नहीं करते, उनके लिए बदलाव इतने ज़्यादा हैं कि साथ बने रहना मुश्किल है

    • यह मौजूदा gemma4 MoE से अलग दूसरा model है, जिसका parameter count थोड़ी उलझन पैदा करने वाले तरीके से लगभग वही है। तेज़ी से देखने पर यह स्पष्ट नहीं है कि दोनों में से कोई एक दूसरे से किसी रूप में trained है या नहीं
      इसका mechanism speculative decoding जैसा नहीं है। Speculative decoding क्रमिक रूप से चलती है, आमतौर पर कुछ tokens के समूहों में। Diffusion ऐसा नहीं करता, बल्कि पूरे text block को एक साथ संभालता है। मैंने अभी सामग्री नहीं पढ़ी है, लेकिन मेरा अनुमान है कि इसे इस तरह train किया गया होगा कि diffusion block के पूरे हिस्से में कुछ experts स्थिर बने रहें

  • मेरे 3090 Ti पर यह advertised speed के आसपास भी नहीं पहुँचता, लेकिन जवाब को “भरते हुए” देखना मज़ेदार है
    मैंने Simon का “साइकिल चलाता SVG pelican” test किया, और नतीजा काफ़ी minimal था लेकिन requirements पर खरा उतरा: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- यह patched llama.cpp में Q4 quantization के साथ चलाया गया नतीजा था। यह भी जानना दिलचस्प होगा कि Simon का नतीजा कितना अलग है

  • डिफ्यूज़न-आधारित reasoning model कैसा दिखेगा? क्या यह पहले से तय लंबाई वाले [thinking] ब्लॉक को लंबे समय तक डिफ्यूज़ करेगा, और अंतिम output ब्लॉक उस thinking ब्लॉक की सामग्री को input के हिस्से की तरह इस्तेमाल करेगा?
    और डिफ्यूज़न मॉडल मूल रूप से output की लंबाई कैसे तय करता है? क्या यह पहले से तय किया गया parameter होता है, या फिर बीच में कहीं [end] token को डिफ्यूज़ करता है — यह जानने की जिज्ञासा है

    • बाकी टिप्पणियाँ पढ़कर एक जवाब मिला। यह बात समझ में आती है कि डिफ्यूज़न प्रक्रिया खुद ही मूल रूप से reasoning जैसी प्रक्रिया है: https://www.inceptionlabs.ai/blog/introducing-mercury-2

  • यह शानदार तो है, लेकिन local model अब ठीक-ठाक होने पर भी अनुभव में सबसे सस्ते API से भी साफ़ तौर पर पीछे लगते हैं, इसलिए सिर्फ़ speed के लिए quality में ज़रा भी समझौता करने का मन नहीं होता
    कुछ use case में इसकी निश्चित ही value होगी, लेकिन वास्तव में production में deploy करने के लिए कोई ठोस उदाहरण क्या है — यह जानने की उत्सुकता है

    • unit test लिखने या bootstrap के लिए यह ठीक हो सकता है
      Opus-स्तर का न भी हो तो भी लिखा जा सकता है, और iteration करना भी आसान है