Mercury - Diffusion-आधारित अल्ट्रा-फास्ट भाषा मॉडल

 (arxiv.org)
10 पॉइंट द्वारा GN⁺ 2025-07-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Mercury diffusion पद्धति का उपयोग करने वाला एक नया वाणिज्यिक बड़े भाषा मॉडल (LLM) है
  • यह मॉडल Transformer संरचना पर आधारित है और कई tokens को parallel में predict करने की विशेषता रखता है
  • Mercury Coder पहला diffusion LLM सेट है, जिसे code writing के लिए विकसित किया गया है, और यह Mini तथा Small दो आकारों में उपलब्ध है
  • NVIDIA H100 GPU पर इसने 1109 (Mini) और 737 (Small) tokens/second का throughput दर्ज किया है, और समान quality पर मौजूदा speed-केंद्रित मॉडलों की तुलना में अधिकतम 10 गुना तेज़ प्रदर्शन दिखाता है
  • वास्तविक उपयोग benchmarks और Copilot Arena जैसे developer evaluations में भी इसने गुणवत्ता में 2वाँ स्थान और गति में सर्वोच्च स्थान दर्ज किया है, और public API तथा playground भी प्रदान करता है

अवलोकन

  • Mercury एक diffusion-आधारित नई बड़े भाषा मॉडल श्रृंखला है, जो commercial scale पर काम करने वाली अगली पीढ़ी की LLM है
  • सभी मॉडल Transformer architecture के रूप में parameterized हैं और कई tokens को parallel में predict करने के लिए trained हैं
  • यह रिपोर्ट मुख्य रूप से code generation apps के लिए डिज़ाइन की गई Mercury Coder की पहली lineup का परिचय देती है
  • Mercury Coder फिलहाल Mini और Small दो model sizes में उपलब्ध है

प्रमुख योगदान

  • Mercury Coder ने गति और गुणवत्ता के संतुलन में नया state-of-the-art स्तर हासिल किया है
  • बाहरी मूल्यांकन संस्था Artificial Analysis के अनुसार:
    • Mercury Coder Mini: 1109 tokens प्रति सेकंड
    • Mercury Coder Small: 737 tokens प्रति सेकंड का प्रदर्शन NVIDIA H100 GPU पर दर्ज किया गया
    • सबसे तेज़ frontier models की तुलना में औसतन अधिकतम 10 गुना तेज़ और समान गुणवत्ता दिखाई
  • विभिन्न programming languages और use cases के code benchmarks पर अतिरिक्त मूल्यांकन परिणाम भी दिए गए हैं
  • वास्तविक developer environment (Copilot Arena) में भी
    • गुणवत्ता के आधार पर 2रा स्थान
    • गति के आधार पर कुल 1ला स्थान हासिल किया गया
  • सभी के उपयोग के लिए public API ( platform.inceptionlabs.ai ) और free chat playground ( chat.inceptionlabs.ai ) उपलब्ध हैं

विषय-सूची संरचना विवरण

  • Introduction (परिचय)
    • प्रमुख योगदान (Contributions)
  • Inception Mercury Model Family (मॉडल परिवार का विवरण)
    • training process (Training)
    • inference method (Inference)
  • Capabilities (मॉडल क्षमताएँ)
    • baseline performance (Baselines)
    • code generation capability (Coding Capabilities)
      • evaluation benchmarks (Evaluation Benchmarks)

सार

  • Mercury नवोन्मेषी diffusion-आधारित LLM डिज़ाइन और parallel prediction संरचना को मिलाकर code generation क्षेत्र में बेहद तेज़ गति और उच्च गुणवत्ता हासिल करता है
  • अलग-अलग model sizes, मजबूत production benchmarks और आसान accessibility के ज़रिये यह commercial और developer environments दोनों के लिए एक प्रतिस्पर्धी विकल्प प्रदान करता है

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

1 टिप्पणियां

 
GN⁺ 2025-07-08
Hacker News टिप्पणियाँ

  • यह ज़ोर दिया गया कि LLM एजेंट्स के आने से टेस्ट परफ़ॉर्मेंस और भी गंभीर CPU bottleneck में बदल सकती है, और अभी भी लगभग सभी टीमें CI speed की वजह से bottleneck झेल रही हैं
    अगर एजेंट इंसानों से 100 गुना तेज़ी से code लिख भी दें, तब भी अगर test चलने में एक घंटा लगे तो उसका कोई मतलब नहीं
    जिन कई projects पर मैंने काम किया, उनमें बदलाव लागू होने का इंतज़ार करते हुए developers का बहुत समय बर्बाद होता था, और कई runs I/O या workers की कमी की वजह से bottleneck हो जाते थे
    जब coding agents साधारण tickets को तेज़ी से PR में बदलें और test failures पर real time में प्रतिक्रिया देकर fixes करें, तो CI bottleneck और बिगड़ेंगे
    ज़्यादातर projects के test environments में सुधार की बहुत गुंजाइश है, लेकिन हक़ीक़त में सालों से बिना खास प्रगति के धीमे CI और ऊँची cost को सामान्य मान लिया गया है
    build को पूरी तरह isolate करने के लिए caching बंद कर देना, या on-premise से धीमे cloud VM पर जाना, CI को उल्टा और धीमा बना देता है
    Mercury की speed पागलपन वाली तेज़ है, और कुछ बार test करने पर code quality भी शानदार और accurate लगी, लेकिन अब चुनौती यह है कि test execution भी इस speed के साथ चल सके

    • जिन ज़्यादातर projects पर मैंने काम किया, वहाँ PR approval का इंतज़ार करते हुए developers का समय बर्बाद होता है — यह बात मुझे आसानी से समझ नहीं आती
      कंपनी के नज़रिए से developer time, machine time से कहीं ज़्यादा महँगा होता है, इसलिए अगर developers शिकायत करें तो CI workers को दोगुना करना संभव है
      Google में test flakiness debug करते समय कभी-कभी 10,000 machines पर 10,000 बार test चलाकर rare failures ढूँढे जाते थे
      मेरी मौजूदा workplace में भी ऐसा ही setup है, जहाँ एक command से सारे tests को 1,000 workers पर parallel चलाया जा सकता है ताकि 1M LOC project में भी 5 मिनट के भीतर feedback मिल सके
      build को पूरी तरह isolate करना और caching न इस्तेमाल करना अलग बातें हैं; build isolation बनाए रखते हुए भी हर संभव cache का पूरा उपयोग करना चाहिए

    • जैसे-जैसे implementation speed बढ़ेगी, bottleneck PM side पर शिफ्ट होगा, और इस स्थिति में बदलाव ज़्यादा serial हो जाने से conflicts काफ़ी कम हो सकते हैं
      specification languages (जैसे TLA+) के फिर से लोकप्रिय होने की संभावना भी है, क्योंकि agents इन्हें तेज़ी से लिख और verify कर सकते हैं, जिससे end-to-end integration tests की कुल संख्या घट सकती है
      background agents जब duplicate code साफ़ करेंगे, तब duplicate tests भी साथ में साफ़ हो सकते हैं
      AI, मानव engineering teams के विपरीत, monolithic structures में ज़्यादा कुशलता से काम कर सकती है; इससे local में चलने योग्य test coverage बढ़ेगा, flaky tests घटेंगे और CI load कम होगा
      भले ही AI efficiency बढ़ा दे, उतनी ही मात्रा में और ज़्यादा code, तेज़ code generation और execution से नए problems लगातार पैदा होंगे, और इंसानी engineers को हल करने के लिए नए मुद्दे आते रहेंगे — इस पर पूरा भरोसा है

    • LLM, 100 lines से कम वाले छोटे fixes या rubber duck की भूमिका तक तो ठीक हैं, लेकिन बड़े project के CI pipeline में LLM को सीधे डालने से सैकड़ों घंटों के स्तर की productivity गिरने का डर है
      अगर code लिखने की skill बढ़ाने के समय की जगह सिर्फ prompt tuning और context adjustment ही करना पड़े, तो उसका कोई अर्थ नहीं
      मुझे लगता है कि LLM tooling को लेकर आत्मविश्वास कुछ ज़्यादा ही है, और यह complex systems पर ठीक से लागू नहीं होता
      किसी महत्वपूर्ण repository में बिना supervision के LLM छोड़ देना, 'बंदूक ताने बिना' संभव नहीं — ऐसा बहुत गहरा अविश्वास
      आख़िरकार LLM के output को आधा फिर से ठीक करना ही पड़ता है, और अगर ऐसा है तो खुद करना बेहतर है

    • कारों से पहले ईंधन, oil और maintenance पर लगभग कोई पैसा नहीं लगता था, लेकिन जैसे-जैसे systems आगे बढ़ते हैं, उनके साथ सहायक infrastructure और cost भी आती है
      AI से bottlenecks हल करना या ज़्यादा features बनाकर revenue बढ़ाना, और फिर उसी अतिरिक्त revenue से और CI resources लेना — यह एक चक्र जैसा है
      AI जोड़ना 10 developers बढ़ाने से अलग नहीं, इसलिए support cost का बढ़ना स्वाभाविक है
      क्या आप efficiency को तार्किक रूप से समझाकर ज़्यादा CI resources ले सकते हैं, या optimization की दिशा सुझा सकते हैं — इस पर दोबारा सोचने का नज़रिया
      जिज्ञासा है कि एक CI resource machine की cost कितनी पड़ती है

    • Python app में astral.sh toolchain और uv package install + caching का उपयोग करके CI speed को काफ़ी बढ़ाने का अनुभव
      जल्द ही mypy की जगह astral के type checker पर जाने की योजना है, जिससे और speed मिलने की उम्मीद है
      frontend वाले apps में Playwright tests सबसे धीमा हिस्सा होंगे, लेकिन कई दूसरे apps में यह समस्या होती ही नहीं
      (पुनश्च: अगर Mike वही हैं जो मैं सोच रहा हूँ, तो शायद वे 2000s की शुरुआत में Google Maps पर मेरे साथ काम करने वाले SRE हैं, इसलिए उनकी राय भरोसेमंद लगती है)

  • जब मैंने Mercury playground में एक regular expression pattern माँगा, तो model ने खुद plan बनाया, pattern लिखा, फिर tests generate करना शुरू कर दिया
    लेकिन वह लगातार tests बढ़ाता गया, और context limit पर पहुँचते ही response कट गया
    करीब 30 tests के बाद उसने test result comments ग़लत लगाने शुरू कर दिए, और 120 से ऊपर जाते-जाते test inputs ही अजीब हो गए, जिनमें random characters भरे थे
    pattern खुद भी सही जवाब नहीं था, लेकिन यह 'infinite loop' जैसा व्यवहार और ज़्यादा दिलचस्प मुद्दा था

    • वैसे, याद है कि कुछ समय पहले तक सामान्य LLM भी इस तरह का output देते थे जो 'लगभग infinite loop' जैसा लगता था
      वे ऐसे pattern में फँस जाते थे जहाँ output बस थोड़ा-थोड़ा बदलता रहता था

    • मुझे लगता है यह केस इस बात का प्रतिनिधि सबूत है कि 'सिर्फ token prediction से code को सही तरह नहीं बनाया जा सकता'
      यह आकलन भी है कि LLM मूल रूप से code reasoning के लिए डिज़ाइन ही नहीं किए गए

  • तकनीकी रिपोर्ट पढ़कर मैंने पुष्टि की कि Mercury, पेपर Lou et al. 2023, SEDD पर आधारित है
    मैंने (शायद) सबसे पहले SEDD को from-scratch reimplement किया था, code public है
    मैंने complex denoising method भी खुद implement किया
    इसे मौजूदा SEDD implementations से ज़्यादा साफ़ और readable बनाया, और single GPU पर toy dataset के लिए कुछ घंटों में चलाया जा सकता है

  • जानकारी के लिए, DeepMind के पास भी diffusion आधारित Gemini model है (लिंक)
    मैंने खुद test किया, और Mercury की तरह इसकी speed भी पागलपन वाली तेज़ थी, लेकिन जवाबों की quality दूसरे Gemini models की तुलना में काफ़ी कम लगी

    • थोड़ी देर इस्तेमाल करके भी मैं सहमत हूँ कि speed प्रभावशाली है, लेकिन accuracy काफ़ी गिर जाती है

    • जानना चाहता हूँ कि Gemini Diffusion demo free है या नहीं
      मैं कई दिनों से waiting list में हूँ, इसलिए अभी तक इसे वास्तव में आज़मा नहीं पाया

  • व्यक्तिगत रूप से मैं इस तरह की प्रगति को लेकर बहुत उत्साहित हूँ
    हाल में game jam के दौरान मैंने AI से एक simple game code कराया, और नतीजों का इंतज़ार करने में ही आधे से ज़्यादा समय चला गया
    अगर हर prompt पर result आने में 1–2 मिनट लगने की जगह सिर्फ 10 सेकंड लगें, तो जहाँ पहले एक test होता था, वहाँ 5–10 experiments किए जा सकते हैं
    अभी Mercury इतना mature नहीं है कि practical इस्तेमाल में पूरी तरह उतारा जा सके, लेकिन Claude 3.0 भी एक साल पहले अधूरा था, इसलिए आगे सुधार की उम्मीद है
    आने वाला समय सच में रोमांचक लग रहा है

  • Mercury playground इस्तेमाल किया तो speed सचमुच कमाल की लगी
    diffusion mode visualization नया-सा लगा, लेकिन व्यवहार में यह जैसे visualized line noise से धीरे-धीरे ज़्यादा accurate state की ओर refine होने की प्रक्रिया दिखाता है
    असल में यह शायद arbitrary vector space में धीरे-धीरे अधिक निश्चित tokens की ओर converge होने की प्रक्रिया है

    • कुछ text diffusion models continuous latent space का उपयोग करते हैं, लेकिन उनका performance बहुत अच्छा नहीं होता
      हाल के समय में ज़्यादातर models actual token output prediction पर ध्यान देते हैं और हर step में पिछले values को सुधारते हुए final result तक converge करते हैं
      मेरे लिखे text diffusion कैसे काम करता है, इस explanation link को देखना उपयोगी हो सकता है

    • लिंक : https://chat.inceptionlabs.ai/

    • सच में अविश्वसनीय रूप से तेज़ लगा

  • ज़्यादातर GPU-adjacent code में performance optimization की बहुत गुंजाइश है
    लेकिन यह सवाल उठा कि arXiv paper असली research से ज़्यादा marketing जैसा तो नहीं
    दूसरों की राय का स्वागत है

    • यह बात पूरी तरह ग़लत नहीं, लेकिन arXiv पर ऐसे मामले पहली बार नहीं हो रहे

  • Mercury model की pricing
    output tokens के प्रति 1 million पर $1, और input tokens के प्रति 1 million पर $0.25
    विस्तृत pricing यहाँ देखी जा सकती है

    • कीमत थोड़ी ज़्यादा लगती है
      performance-sensitive मामलों में Mercury और Groq (Llama 3.1 8b, Llama 4 Scout) की तुलना में performance काफ़ी मिलती-जुलती थी, लेकिन Groq की pricing कहीं बेहतर थी
      open source diffusion models आने की उम्मीद के साथ मैं इसे दिलचस्पी से देख रहा हूँ

  • playground code और API response में gpt-3.5-turbo और "openai": true जैसे items दिखे, इसलिए सवाल है कि क्या यह वास्तव में अपना dLLM नहीं बल्कि OpenAI को call कर रहा है
    ऊपर दाईं ओर का diffusion effect feature सिर्फ animation effect जैसा लगता है

    • real-time जैसी speed देखकर यह मानना मुश्किल है कि पीछे सच में OpenAI backend चल रहा है

  • सब कुछ सुनने में शानदार लगता है, लेकिन
    service में user posts submit करने पर terms के मुताबिक़ Inception को दुनिया भर में non-exclusive, permanent, royalty-free, no-cost, fully transferable license मिल जाता है
    यानी user content को AI model training के लिए इस्तेमाल किया जा सकता है
    (हालाँकि OpenRouter के ज़रिए किए गए access के लिए एक exception clause है कि उन्हें training में इस्तेमाल नहीं किया जाएगा)