LLM inference में nondeterminism को कैसे हराया जाए

 (thinkingmachines.ai)
2 पॉइंट द्वारा GN⁺ 2025-09-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM (Large Language Model) inference में एक nondeterminism समस्या होती है, जिसमें एक ही input और condition होने पर भी अलग-अलग result आ सकते हैं
  • पहले concurrency और floating-point calculation की non-associativity को nondeterminism का मुख्य कारण माना जाता था
  • लेकिन वास्तविक निर्णायक कारण batch size बदलने पर kernel (operation code) के अंदर computation order का बदलना है
  • अगर kernel के भीतर सभी operation को batch invariance के साथ implement किया जाए, तो पूरी reproducibility की गारंटी दी जा सकती है
  • data-parallel operation, split reduction, fixed-size split strategy आदि के जरिए मुख्य operations (RMSNorm, matmul, attention) के लिए batch-invariant kernel बनाए जा सकते हैं

परिचय और समस्या का सार

  • reproducibility, जो वैज्ञानिक प्रगति का एक मुख्य तत्व है, LLM inference में ठीक से बनी नहीं रहती
  • ChatGPT से एक ही सवाल कई बार पूछने पर अक्सर अलग-अलग जवाब बनते हैं
  • ऐसा इसलिए होता है क्योंकि LLM में result sampling की प्रक्रिया probability distribution पर आधारित probabilistic selection से होती है
  • लेकिन temperature को 0 पर सेट करने के बाद भी व्यवहार में LLM API ज़रूरी नहीं कि deterministic हो, यानी एक ही input पर हर बार वही output आए, यह तय नहीं है
  • open source inference libraries (vLLM, SGLang आदि) और अपने hardware पर चलाने पर भी nondeterminism की समस्या बनी रहती है

पुरानी परिकल्पनाएँ और उनकी सीमाएँ

  • प्रचलित परिकल्पना: concurrency + floating-point की non-associativity के कारण nondeterminism होता है
    • GPU पर floating-point calculation में operation order और thread completion order के अनुसार result थोड़ा बदल सकता है
  • लेकिन वास्तव में एक ही data पर एक ही तरीके से matrix multiplication बार-बार चलाने पर भी हमेशा वही (bitwise equal) result मिलता है
  • असली कारण समझने के लिए और गहरा विश्लेषण ज़रूरी है

LLM inference में nondeterminism के कारण का गहन विश्लेषण

floating-point non-associativity का मूल स्वभाव

  • floating-point operation में (a+b)+c ≠ a+(b+c) संबंध हो सकता है
  • अलग-अलग magnitude (exponent) वाले values पर operation करने पर precision loss, information loss होता है और operation order के अनुसार result बदल सकता है
  • क्योंकि operation order बदल सकता है, कई बार sums को random order में करने पर अलग-अलग result निकलते हैं, जिसे प्रयोग में भी देखा गया

kernel के operation order में बदलाव और concurrency

  • आम तौर पर atomic add जैसी concurrency समस्याओं को nondeterminism का मुख्य कारण बताया जाता है
  • लेकिन LLM inference में इस्तेमाल होने वाले ज़्यादातर kernels, खासकर forward pass में, atomic add के बिना भी काम करते हैं
  • पहले से सही parallel strategy, split (reduction) आदि के जरिए एक जैसा operation order सुनिश्चित किया जा सकता है

असली मुख्य कारण: batch invariance की कमी

  • हर individual kernel, अगर input वही हो, तो हमेशा वही result देता है (run-to-run deterministic)
  • लेकिन कई users के simultaneous request का batch size nondeterministically बदलता रहता है, इसलिए हर request के लिए व्यावहारिक रूप से output स्थिर नहीं रहता
  • batch size के अनुसार अंदरूनी रूप से operation को split या merge करने का order बदल जाता है, जिससे nondeterminism पैदा होता है
  • यानी server load और parallelism (batch size) का nondeterministic होना ही असली मुख्य कारण है

batch-invariant kernel design और मुख्य operations के उदाहरण

RMSNorm

  • data-parallel strategy लागू की जाती है: हर batch element को स्वतंत्र रूप से एक core process करता है
  • batch size बड़ा हो तो पर्याप्त parallelism बना रहता है, यानी parallel strategy स्थिर रहती है और batch invariance सुनिश्चित होती है
  • batch size बहुत छोटा होने पर split reduction जैसी वैकल्पिक strategy इस्तेमाल की जाती है, लेकिन इस स्थिति में कुछ batch invariance छोड़नी पड़ सकती है

matrix multiplication (matmul)

  • tile के आधार पर parallelize करके data-parallel strategy का उपयोग किया जाता है
  • Tensor Core optimization के लिए 2D tile split करना पड़ता है, और बहुत छोटे batch में split-K जैसी विशेष strategy की ज़रूरत होती है
  • split-K strategy इस्तेमाल करने पर batch invariance टूट सकती है
  • performance का कुछ हिस्सा छोड़कर भी एक जैसा kernel configuration मजबूर किया जा सकता है, जिससे स्थिर और reproducible operation order मिलता है

attention

  • FlashAttention2 आदि में query-direction parallelization, Key/Value simultaneous reduction strategy से batch invariance सुनिश्चित की जा सकती है
  • batch size और sequence split (chunked prefill, prefix caching आदि) के अनुसार reduction order बदल जाए तो invariance टूट जाती है
  • split-KV (FlashDecoding) जैसे split-reduction strategy में split size को fixed रखकर operation order को समान रखा जाता है
  • अंदरूनी कामकाज में key/value cache और नए token को अलग-अलग process न करके, हर operation में key/value layout को एक जैसा रखना चाहिए

implementation

  • vLLM और torch.Library का उपयोग करके batch-invariant kernels लागू किए गए deterministic inference demo उपलब्ध है
  • संबंधित replacement kernels GitHub repo (thinking-machines-lab/batch-invariant-ops) में देखे जा सकते हैं

प्रयोग और performance

nondeterminism measurement experiment

  • Qwen/Qwen3-235B-A22B-Instruct-2507 model पर temperature 0 की condition में वही prompt (“Tell me about Richard Feynman”) 1000 बार generate किया गया
  • 80 अलग-अलग completions बने, यानी same prompt पर भी nondeterminism मौजूद था
  • पहले 102 tokens तक result समान थे, और 103वें token पर पहली branching हुई (“Queens, New York” vs “New York City”)
  • batch-invariant kernels इस्तेमाल करने पर 1000ों बार बिल्कुल वही result मिला, यानी पूरी reproducibility हासिल हुई

performance evaluation

  • 1 GPU पर Qwen-3-8B चलाकर, 90~110 लंबाई वाली sequence के 1000 request चलाए गए
    • default vLLM: 26 सेकंड
    • unoptimized deterministic vLLM: 55 सेकंड
    • improved attention kernel लागू करने पर: 42 सेकंड
  • optimization अभी पर्याप्त नहीं है, लेकिन व्यावहारिक रूप से उपयोगी performance स्तर बना रहता है

on-policy RL में महत्व

  • पहले training और inference के बीच सूक्ष्म numerical difference के कारण on-policy RL को सटीक रूप से implement नहीं किया जा सकता था
  • deterministic inference संभव होने पर sampling और training दोनों को bitwise identical बनाया जा सकता है, जिससे वास्तविक on-policy RL implement करना संभव होता है
  • KL-divergence, reward जैसे मुख्य metrics पर पूरी तरह मेल खाते result देखे गए

निष्कर्ष

  • LLM inference systems में nondeterminism और numerical error को नज़रअंदाज़ करना आसान है, लेकिन इस समस्या के मूल कारण (batch invariance की कमी) को समझकर सुधार लिया जाए तो पूरी reproducibility और determinism हासिल की जा सकती है
  • यह शोध LLM inference की nondeterminism समस्या के समाधान का रास्ता दिखाता है, जिससे developers अपनी systems में पूरी reproducibility हासिल कर सकते हैं

citation जानकारी

  • इस शोध को cite करते समय नीचे दी गई जानकारी का उपयोग करें
He, Horace and Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference", 
Thinking Machines Lab: Connectionism, Sep 2025.

या

@article{he2025nondeterminism,
  author = {Horace He and Thinking Machines Lab},
  title = {Defeating Nondeterminism in LLM Inference},
  journal = {Thinking Machines Lab: Connectionism},
  year = {2025},
  note = {https://thinkingmachines.ai/blog/…},
  doi = {10.64434/tml.20250910}
}

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

1 टिप्पणियां

 
GN⁺ 2025-09-12
Hacker News टिप्पणियाँ

  • भले ही "सैद्धांतिक" non-determinism को पूरी तरह बंद, व्यक्तिगत input-output जोड़ों में हल कर लिया जाए, फिर भी व्यवहार में non-determinism की दो समस्याएँ बचती हैं: एक, वही input पिछले context के अनुसार अलग result देता है; और दूसरी, थोड़ा बदला हुआ input सही तरह बदला हुआ result नहीं देता। जब तक ये समस्याएँ हल नहीं होतीं, तब तक बंद सिस्टम में non-determinism का लाभ बहुत सीमित है, सिवाय उन मामलों के जहाँ lookup table ही काफी हो। जिन inputs का test नहीं किया गया, उनके लिए "सही" unit tests या eval set से कुछ साबित करना मुश्किल है

    • "ठीक वही input होने पर भी अलग पिछले context के कारण result बदलता है" — ऐसी स्थिति वास्तव में होती ही नहीं। पिछला context खुद input का हिस्सा है। अगर किसी input prompt पर हमेशा वही result आता है, तो कहा जा सकता है कि context को ignore किया जा रहा है। यानी यह वैसा ही है जैसे session state से स्वतंत्र होकर हमेशा खाली context से शुरू करना। कुछ लोग असल में यह चाहते हैं कि,

      • एक ही अर्थ वाले अलग-अलग prompt वाक्य (जैसे "What is the capital of France" और "What is France's capital") बिल्कुल एक जैसा जवाब दें
      • जब पिछला context सवाल के साथ interact नहीं करता, तब उसका result पर असर न पड़े। उदाहरण के लिए, prompt "what is 2 + 2" का हमेशा वही जवाब आना चाहिए, और जब तक context में 2 + 2 = 5 न कहा गया हो, वह न बदले। ऐसी मांगें दिखाती हैं कि लोग LLM क्या है, इसे लेकर गलतफहमी में हैं

    • यह समस्या क्यों है कि 'पिछला context' अलग result बनाता है? अगर context का result पर असर ही नहीं होना चाहिए, तो context को फेंक ही दीजिए। ऐसा behavior चाहने की वजह क्या है? असल tools से तो हम उम्मीद करते हैं कि वे हमारी intent या mode switch के अनुसार अलग react करें, जैसे vim में insert mode में जाकर behavior बदलना। intelligence भी कुछ ऐसी ही होनी चाहिए। context को ignore करना तो उल्टा अत्यधिक confirmation bias जैसा लगता है

    • bugs reproduce करने में यह बहुत उपयोगी है

    • मैं "ज़्यादा मददगार नहीं" वाली बात तक सहमत था। शायद उसका मतलब "यह समस्या को पूरी तरह हल नहीं करता" था

  • मुझे समझ नहीं आता कि probabilistic systems में determinism को लेकर इतनी चिंता क्यों है। user के नज़रिए से, अगर "How do I X?" पर हर बार बिल्कुल वही deterministic जवाब मिले, लेकिन "how do i x?", "how do I x", "how do I X??" जैसे अर्थ में एक जैसे inputs पर पूरी तरह अलग results मिलें, तो उसका खास मतलब नहीं। LLM में असल ज़रूरत यह है कि semantically same inputs पर हमेशा semantically same outputs की guarantee हो। यह उस determinism से बिल्कुल अलग concept है जिसके बारे में हम आम तौर पर algorithms में बात करते हैं

    • हर LLM-based application सिर्फ user के ad-hoc chat interface वाली नहीं होती। जैसे tool calling को evaluation के लिए 10 बार लगातार चलाना, या DSPy Optimizer जैसे tools लिंक से prompts को बार-बार test करना — अगर token-level input तक पूरी तरह मेरे control में है, तो unpredictability कम करना महत्वपूर्ण है। ऐसे माहौल में अगर token level variability हटाकर सिर्फ input की ambiguity बचाई जा सके, तो system के behavior को कहीं अधिक भरोसेमंद tree या graph structure में map किया जा सकता है

    • आपकी बात गलत नहीं है, लेकिन इसका यह मतलब नहीं कि इस स्तर का determinism बेकार है। अगर वही input tokens देने पर भी हर बार result अलग हो, तो साथियों के साथ results reproduce और share करना मुश्किल हो जाता है, और उन स्थितियों का test करना भी कठिन होता है जहाँ LLM बहुत rare और unpredictable outputs देता है, जैसे red teaming

    • मैं LLM output में steganography से जानकारी embed करने वाले एक project पर काम कर रहा हूँ: innocuous। इसमें model के top 10 tokens के आसपास से ही चुना जाता है, और क्योंकि testing मुख्यतः CPU-based 8B model पर होती है, hardware के कारण token ordering बदलने की चिंता कम है, लेकिन फिर भी eventually guard conditions जोड़ने का सोच रहा हूँ ताकि precision loss के कारण choice set न बदल जाए

    • AI platform के customers के लिए यह बहुत उपयोगी हो सकता है। temperature 0 पर prompt को कई बार चलाकर यह verify किया जा सकता है कि result हमेशा same है या नहीं, ताकि पता चले कि AI provider कहीं PRO model की जगह चुपके से कोई सस्ता दूसरा model तो नहीं चला रहा

    • "bug" reproduce करने के लिए यह अनिवार्य है। अगर वही input string देने पर वही गलत या अजीब output हर बार reproduce हो सके, तो debugging बहुत आसान हो जाती है। अगर result 100 में 1 बार बदल जाए, तो काम बहुत कठिन हो जाता है

  • (JAX/XLA पर काम का अनुभव) यह काफी जाना-पहचाना मामला है। मैं खुद कई बार इस तरह की घटना (batch-level variability) से टकराया हूँ, और नीचे दिए गए issues में इसकी explanation देखी थी: penzai issue #82, jax issue comment

    • मुझे लगता है यह top comment होना चाहिए

  • कभी-कभी non-determinism का कारण implementation details होती हैं। उदाहरण के लिए, GPT-2 source code में GUI पर temperature को 0 सेट करने पर भी वास्तव में non-zero "epsilon" (बहुत छोटा मान) दिया जाता है। यह division by zero error से बचने के लिए समझ में आने वाली बात है। non-determinism कई applications में "बेकार" है। LDA topic models में भी यह पुरानी समस्या है। खासकर legal, finance, और regulated domains में non-deterministic methods का उपयोग अवैध भी हो सकता है। या फिर इससे अनचाहे अतिरिक्त obligations आ सकते हैं, जैसे हर screen recording को सहेजकर रखना ताकि बाद में क्या हुआ था, उसे एक-एक करके reconstruct किया जा सके

  • "किसी और के साथ Thinking Machines में काम करना" वाली बात आई। इससे मुझे पुराने दिनों की याद आ गई जब MIT AI Lab के सामने उस मशीन के लाल LED cubes चमकते दिखते थे। Richard Feynman ने सच में शानदार काम किया था, और इस पर एक लेख भी है: Feynman and the Connection Machine. अमेरिका में “THINKING MACHINES” का trademark Hillis के नाम पर नहीं बल्कि उसकी स्थापित company के नाम पर registered था, और 1998–1999 में cancel हो गया। company 1994 में bankrupt हो गई थी, और assets Sun Microsystems (बाद में Oracle) वगैरह के पास चले गए। Amira Murati द्वारा स्थापित Thinking Machines Lab Inc. 2025 में नया “THINKING MACHINES” trademark application आगे बढ़ा रही है

    • हर बार उस company का नाम देखकर मुझे यही confusion होता है

  • हाल में high-quality blog-style research discussions देखना सच में अच्छा लग रहा है। Anthropic इस culture को आगे बढ़ा रहा है और यह धीरे-धीरे फैलती दिख रही है, जो उत्साहजनक है। पहले RL research के दौर में OpenAI भी ऐसा ही था

  • natural language खुद inherently ambiguous है। उसे ambiguous होना ही चाहिए। यहाँ जो कोशिश हो रही है — 'गोले को चौकोर बनाना और फिर समझाना कि ऐसा क्यों होना चाहिए' — मुझे वह गलत लगती है। ऐसी चर्चाएँ आखिरकार भाषा और randomness की प्रकृति को बेहतर स्वीकार करने की तरफ जाएँगी, और भाषा को QKV projection matrix जैसे mini-grammar subpatterns से आगे समझने की चर्चा बनेंगी

    • सही बात है। लेकिन determinism ambiguity नहीं है। determinism का मतलब है "ठीक इस input पर ठीक यह output guaranteed होना चाहिए"। मैं उम्मीद करता हूँ कि एक ही model से एक ही सवाल पूछने पर हर बार वही जवाब आए। हाँ, अगर सवाल को थोड़ा अलग wording में पूछा जाए, तो कुछ अलग जवाब आना समझ में आता है

  • मुझे अभी भी company का नाम पसंद नहीं है। समझ नहीं आता इस तरह की naming बार-बार क्यों दोहराई जाती है। शायद यह उम्मीद होती है कि किसी legendary organization का aura किसी नई venture में भी आ जाएगा। लेकिन अगली startup का नाम PARC रख देने से आपकी networking innovation अपने-आप थोड़े ही आ जाएगी

    • आप 1994 में खत्म हुई “Thinking Machines” company की बात कर रहे हैं, सही? मुझे तो इसे खोजकर देखना पड़ा, और यह उतनी मशहूर भी नहीं निकली, इसलिए शायद इरादा वह नहीं है। बस नाम cool और intuitive लगा होगा

    • सिर्फ naming से marketing free में मिल जाती है, और यही तो trademark system होने की वजह भी है

  • सच में बहुत दिलचस्प सामग्री है। जिन लोगों को नहीं पता, उनके लिए: यह company पूर्व OpenAI CTO Mira Murati ने शुरू की है