LLMs 101: एक व्यावहारिक गाइड (2026 संस्करण)

लूप से शुरू करें। टेक्स्ट टोकन बन जाता है। टोकन Transformer के माध्यम से चलते हैं। Attention तय करता है कि पिछले कौन से टोकन महत्वपूर्ण हैं। Runtime एक KV cache रखता है ताकि मॉडल हर बार पूरी बातचीत को पुनर्गणना न करे। फिर मॉडल अगला टोकन चुनता है और फिर से ऐसा करता है।

LLM कैसे काम करते हैं, मॉडल एक समय में एक टोकन कैसे सोचते हैं, और उन्हें स्थानीय रूप से कैसे चलाया जाए, इसके लिए एक व्यावहारिक मार्गदर्शिका।

एक बार वह लूप समझ में आ जाए, तो हार्डवेयर और सॉफ्टवेयर विकल्पों के बारे में तर्क करना आसान हो जाता है। VRAM, quantization, context length, chat templates, decoding, RAG, serving engines, और model selection - ये सब उसी यांत्रिकी से उत्पन्न होते हैं।

लूप से शुरू करें: टोकन अंदर, संभावनाएँ बाहर, एक बार में एक अगला टोकन। वेट्स मॉडल को बताते हैं कि उसने कौन से पैटर्न सीखे हैं। कॉन्टेक्स्ट उसे बताता है कि वह अब क्या देख रहा है। KV cache वह कार्यशील मेमोरी है जो लूप को उपयोगी बनाए रखती है। हार्डवेयर, runtimes और model selection तभी समझ में आते हैं जब आप मेमोरी, कॉन्टेक्स्ट और फ़ॉर्मेटिंग नियमों को समझ लेते हैं जिनका मॉडल पालन कर रहा है।

लक्ष्य पहले स्थानीय LLM यांत्रिकी को सहज बनाना है, फिर आपको हार्डवेयर, runtimes, serving और 21 मई, 2026 तक के वर्तमान LLM अनुसंधान के लिए एक व्यावहारिक मार्ग देना है।

Focus

यह मॉडल-प्रथम मार्गदर्शिका है। यह यांत्रिकी से शुरू होती है: inference, tokens, Transformers, attention, KV cache, prefill, decode, decoding controls, model packages, chat templates, model types, long context, RAG, agents, fine-tuning, और multimodal models।

उसके बाद, यह स्थानीय परिनियोजन स्तर पर जाता है: local का वास्तव में क्या अर्थ है, quantization, VRAM गणित, hardware tiers, runtime choices, serving modes, licenses, model selection, गोपनीयता, समस्या निवारण, benchmarks, setup paths, और व्यावहारिक उपयोग के मामले।

वह क्रम मायने रखता है। GPU चुनने से पहले आपको समझना चाहिए कि लंबा प्रॉम्प्ट मेमोरी क्यों खर्च करता है। किसी मॉडल का मूल्यांकन करने से पहले आपको समझना चाहिए कि chat templates क्यों मायने रखते हैं। tokens per second की परवाह करने से पहले आपको समझना चाहिए कि decode अनुक्रमिक क्यों है।

गहन हार्डवेयर और सॉफ्टवेयर पथ के लिए, मेरे पास स्वयं-होस्टेड LLM / स्थानीय AI सिखाने वाली तीन-भाग की श्रृंखला है:

पहले दो भाग हार्डवेयर क्षमता और बैंडविड्थ गणित की व्याख्या करते हैं। तीसरा भाग सॉफ्टवेयर स्तर की व्याख्या करता है जो उस हार्डवेयर को उपयोगी इन्फ्रेंस में बदलता है। यह लेख आपको पहले मॉडल-पक्ष की नींव देता है, फिर एक बार यांत्रिकी स्पष्ट हो जाने पर उन परिनियोजन स्तरों पर वापस इंगित करता है।

What An LLM Actually Does

मॉडल चलाने को इन्फ्रेंस कहा जाता है। एक मानक डिकोडर-ओनली LLM के लिए, इन्फ्रेंस एक ही लूप है जो बार-बार दोहराया जाता है:

अपने टेक्स्ट को टोकन में बदलें।
उन टोकन को मॉडल में फीड करें।
प्रत्येक संभावित अगले टोकन के लिए स्कोर की गणना करें।
एक डिकोडिंग नीति के साथ एक टोकन चुनें।
उस टोकन को अनुक्रम में जोड़ें।
तब तक दोहराएं जब तक मॉडल रुक न जाए, उपयोगकर्ता इसे रोक न दे, या टोकन सीमा तक न पहुंच जाए।

मॉडल एक बार में पूरा उत्तर नहीं लिख रहा है। यह एक समय में एक टोकन उत्पन्न कर रहा है। प्रत्येक नया टोकन अनुक्रम का हिस्सा बन जाता है जो अगले टोकन को प्रभावित करता है।

गणितीय रूप से, मॉडल एक सीखा हुआ फलन है:

f(theta, sequence) -> probability distribution over next_token

जहाँ:

theta का अर्थ है मॉडल वेट्स।
sequence का अर्थ है प्रॉम्प्ट और अब तक उत्पन्न टोकन।
Logits, softmax से पहले के कच्चे स्कोर हैं।
Probabilities, softmax के बाद सामान्यीकृत स्कोर हैं।
Decoding उन probabilities को एक चयनित टोकन में बदलता है।

यही कारण है कि स्थानीय जनरेशन की गति tokens per second में मापी जाती है। आपका सिस्टम बार-बार एक forward pass चलाता है, एक टोकन चुनता है या सैंपल करता है, KV cache को अपडेट करता है, और जारी रखता है।

यहाँ धारणा मायने रखती है। लंबा prefill का अर्थ है पहला शब्द प्रकट होने से पहले लंबा विराम। धीमा decode का अर्थ है उत्तर धीरे-धीरे आता है। स्थानीय निर्माता अक्सर decode गति पर ध्यान देते हैं क्योंकि उपयोगकर्ता इसे महसूस करते हैं, लेकिन prefill का समय तब दर्द देता है जब आप 10K-टोकन दस्तावेज़ चिपकाते हैं।

Tokens

LLM कच्चे टेक्स्ट को शब्दों के रूप में नहीं देखते। वे टोकन देखते हैं: टेक्स्ट के छोटे टुकड़े जो आंतरिक रूप से पूर्णांक IDs के रूप में दर्शाए जाते हैं।

एक टोकन हो सकता है:

एक पूरा शब्द: "hello"
एक शब्द खंड: "inter", "national", "ization"
एक विराम चिह्न
एक व्हाइटस्पेस-उपसर्ग स्ट्रिंग
एक बाइट-स्तरीय फ़ॉलबैक
एक विशेष नियंत्रण मार्कर जैसे <|user|>, <|assistant|>, , या

Tokenizer, टेक्स्ट को टोकन IDs में और टोकन IDs को वापस टेक्स्ट में मैप करता है। सामान्य tokenizer परिवारों में BPE-शैली tokenizer और SentencePiece-शैली tokenizer शामिल हैं। विभिन्न मॉडल परिवार विभिन्न tokenizer का उपयोग करते हैं, और यह मायने रखता है। एक 4,000-शब्द दस्तावेज़ एक tokenizer में 5,000 टोकन और दूसरे में 7,500 टोकन हो सकता है।

शब्दावली का आकार भी मायने रखता है। बड़ी शब्दावली वाला tokenizer कुछ टेक्स्ट को कम टोकन में संपीड़ित कर सकता है, लेकिन यह embedding और output-projection आकार को भी बदलता है। यह एक कारण है कि tokens per second मॉडल परिवारों में पूरी तरह से तुलनीय नहीं है।

टोकन मायने रखते हैं क्योंकि वे निर्धारित करते हैं:

कॉन्टेक्स्ट विंडो में कितना टेक्स्ट फिट होता है।
KV cache कितना बड़ा हो जाता है।
प्रॉम्प्ट प्रोसेसिंग के दौरान आप कितनी विलंबता का भुगतान करते हैं।
क्या बहुभाषी या कोड-भारी टेक्स्ट कुशल है।
क्या मॉडल विशेष चैट मार्करों को सही ढंग से देखता है।

मॉडल की कॉन्टेक्स्ट विंडो टोकन की अधिकतम संख्या है जिस पर वह एक बार में ध्यान दे सकता है। 2026 में, सामान्य स्थानीय-सक्षम मॉडल 8K और 32K कॉन्टेक्स्ट से लेकर 128K, 256K और सर्वर-श्रेणी प्रणालियों में 1M-टोकन कॉन्टेक्स्ट तक होते हैं।

लेकिन समर्थित कॉन्टेक्स्ट लंबाई सस्ते, तेज़ या समान रूप से सटीक कॉन्टेक्स्ट के समान नहीं है। एक मॉडल जो तकनीकी रूप से 128K टोकन संभाल सकता है, 64K पर धीमा हो सकता है और 100K पर सुसंगतता खो सकता है। हमेशा उन कॉन्टेक्स्ट लंबाईयों का परीक्षण करें जिनका आप वास्तव में उपयोग करने की योजना बना रहे हैं।

टोकन काम की इकाई हैं। एक बार जब आप यह समझ जाते हैं, तो लंबा कॉन्टेक्स्ट जादुई दिखना बंद कर देता है और एक बिल की तरह दिखने लगता है जिसका आप अनुमान लगा सकते हैं।

सहायक अभ्यास: मेरा Tokenizer डेमो ऐप आज़माएं यह देखने के लिए कि टेक्स्ट वास्तविक समय में टोकन में कैसे टूटता है।

Transformers

अधिकांश आधुनिक LLM Transformer आर्किटेक्चर पर आधारित हैं। अधिकांश स्थानीय चैट LLM डिकोडर-ओनली Transformer हैं: वे पिछले टोकन को देखते हुए अगले टोकन की भविष्यवाणी करते हैं।

इस बिंदु से ऊपर की सब कुछ, जिसमें token, weights, config और chat templates शामिल हैं, नीचे के वास्तविक इंजन के लिए सेटअप है। Transformer वह कंकाल है जो संख्याओं को इधर-उधर करता है।

एक सरलीकृत Transformer परत में शामिल है:

Token embeddings: Token IDs वेक्टर बन जाते हैं।
स्थितीय जानकारी: मॉडल को टोकन क्रम की आवश्यकता होती है। कई आधुनिक LLM RoPE (Rotary Position Embeddings) का उपयोग करते हैं, जो प्रतिनिधित्व को घुमाकर स्थिति को एन्कोड करता है।
Self-attention: प्रत्येक टोकन प्रतिनिधित्व पिछले टोकन प्रतिनिधित्व को देखता है और तय करता है कि क्या मायने रखता है।
MLP / feed-forward ब्लॉक: एक सघ्न अरैखिक गणना जो प्रतिनिधित्वों का विस्तार और संपीड़न करती है। मापदंडों का एक बड़ा हिस्सा यहाँ रहता है।
Layer normalization और अवशिष्ट कनेक्शन: ये गहरे नेटवर्क को स्थिर करते हैं और कई परतों के माध्यम से सूचना प्रवाह में मदद करते हैं।
Output projection: अंतिम छिपी अवस्था शब्दावली पर logits बन जाती है।

इस रेसिपी को दर्जनों या सैकड़ों बार स्टैक करें और आपको एक भाषा मॉडल मिलता है।

Transformer सारांश: टोकन वेक्टर बन जाते हैं, attention अनुक्रम को जोड़ता है, MLP प्रतिनिधित्व को पुनः आकार देते हैं, RoPE स्थिति को सीधा रखता है, और अंतिम प्रोजेक्शन अंतिम छिपी अवस्था को अगले-टोकन logits में बदल देता है।

Attention

Attention वह तरीका है जिससे एक टोकन तय करता है कि अगली भविष्यवाणी के लिए पिछले कौन से टोकन मायने रखते हैं। यह उन कारणों में से एक है जिनकी वजह से स्थानीय इन्फ्रेंस इतना मेमोरी-संवेदनशील है।

क्लासिक MHA (multi-head attention) कई हेड्स के लिए अलग key/value स्थिति संग्रहीत करता है। यह मॉडल को लचीलापन देता है, लेकिन यह KV cache को बड़ा बनाता है।

आधुनिक स्थानीय मॉडल अक्सर अधिक कुशल attention डिज़ाइन का उपयोग करते हैं:

MQA: कई क्वेरी हेड्स एक key/value हेड साझा करते हैं। यह मेमोरी-कुशल है, लेकिन कम अभिव्यंजक हो सकता है।
GQA: क्वेरी हेड्स के समूह key/value हेड्स साझा करते हैं। यह कई वर्तमान स्थानीय मॉडलों में सामान्य मध्य मार्ग है।
MHA: पूर्ण multi-head attention। यह मजबूत हो सकता है, लेकिन लंबा कॉन्टेक्स्ट जल्दी महंगा हो जाता है।

FlashAttention और SDPA-शैली कार्यान्वयन जैसे आधुनिक कर्नेल attention मेमोरी ट्रैफिक को कम करते हैं और GPU को व्यस्त रखते हैं। अच्छे attention कर्नेल वाला runtime उसके बिना वाले की तुलना में नाटकीय रूप से तेज़ हो सकता है, भले ही एक ही मॉडल और हार्डवेयर पर हो।

यही कारण है कि दो 7B मॉडल लंबे कॉन्टेक्स्ट पर बहुत अलग व्यवहार कर सकते हैं। पैरामीटर गणना पूरी कहानी नहीं है। 128K कॉन्टेक्स्ट पर एक 7B MHA मॉडल 24 GB GPU को खत्म कर सकता है, जबकि समान विज्ञापित कॉन्टेक्स्ट वाला 7B GQA मॉडल खाली जगह के साथ फिट हो सकता है।

मॉडलों की तुलना करते समय, केवल पैरामीटर गणना नहीं, बल्कि attention प्रकार, KV हेड्स, कॉन्टेक्स्ट लंबाई और runtime समर्थन देखें।

KV Cache

KV cache जनरेशन के दौरान मॉडल की कार्यशील मेमोरी है। यह पिछले टोकन के लिए key/value attention स्थितियों को संग्रहीत करता है ताकि मॉडल प्रत्येक उत्पन्न टोकन पर शुरू से पूरे इतिहास की पुनर्गणना न करे।

KV cache के बिना, जनरेशन बेहद अक्षम होगी। KV cache के साथ, जनरेशन उपयोगी है, लेकिन कैश इसके अनुपात में मेमोरी की खपत करता है:

tokens x layers x kv_heads x head_dim x precision x 2

x 2 कुंजी और मान के लिए है।

पुराने Llama-जैसे 7B MHA मॉडल के लिए एक उपयोगी अंगूठे का नियम FP16 KV cache में लगभग 0.5 MiB प्रति टोकन है। इसका मतलब है कि 4K टोकन अकेले KV cache के लिए लगभग 2 GiB खर्च कर सकते हैं। 32K टोकन पर, आप अकेले 16 GiB KV cache देख सकते हैं।

नए GQA/MQA मॉडल इसे काफी कम करते हैं। कुछ runtimes FP8 या INT8 KV cache का भी समर्थन करते हैं। यह अक्सर व्यावहारिक संपीड़न तल है जिसकी मैं 2026 में स्थानीय उपयोगकर्ताओं के लिए अनुशंसा करूंगा।

8-बिट से कम KV cache को डिफ़ॉल्ट न मानें। KIVI, KVQuant और नए संपीड़ित-कैश कर्नेल जैसी शोध प्रणालियाँ दिखाती हैं कि 2-बिट से 4-बिट KV सावधान एल्गोरिदम, कैलिब्रेशन और कस्टम कर्नेल के साथ काम कर सकता है। यह डेस्कटॉप runtime में लापरवाही से Q4 KV टॉगल चालू करने के समान नहीं है। 8-बिट से नीचे, कठोर बेंचमार्क करें, विशेष रूप से कोडिंग, टूल कॉल, JSON, लंबी-कॉन्टेक्स्ट पुनर्प्राप्ति और उन कार्यों के लिए जहां सटीक पिछले टोकन मायने रखते हैं।

इसके अलावा KV-cache quantization को speculative decoding के साथ भ्रमित न करें। DFlash और DDTree, जिसे अक्सर अनौपचारिक रूप से DTree से छोटा किया जाता है, भविष्य के टोकन का मसौदा तैयार करके और उन्हें सत्यापित करके decode विलंबता पर हमला करते हैं। वे गति में सुधार कर सकते हैं, लेकिन वे KV-cache मेमोरी बिल को मिटा नहीं देते।

यही कारण है कि एक मॉडल खाली प्रॉम्प्ट पर फिट हो सकता है लेकिन जब आप एक लंबा दस्तावेज़ लोड करते हैं तो क्रैश हो जाता है। वेट्स फिट होते हैं। कार्यशील मेमोरी नहीं हुई।

Prefill And Decode

LLM इन्फ्रेंस के दो अलग-अलग प्रदर्शन शासन हैं: prefill और decode।

Prefill आपके द्वारा मॉडल को दिए गए प्रॉम्प्ट को प्रोसेस करता है। यदि आप 20,000-टोकन दस्तावेज़ चिपकाते हैं, तो मॉडल को पहला उत्तर टोकन उत्पन्न करने से पहले उन 20,000 टोकन को प्रोसेस करना होगा। Prefill अपेक्षाकृत समानांतर है, इसलिए GPU इसे कुशलतापूर्वक संभाल सकते हैं, लेकिन यह अभी भी महंगा हो सकता है।

पहले टोकन के प्रकट होने की प्रतीक्षा में आप जो समय बिताते हैं वह आमतौर पर prefill समय होता है।

Decode एक समय में एक नया टोकन उत्पन्न करता है। प्रत्येक उत्पन्न टोकन अब तक के अनुक्रम पर निर्भर करता है, इसलिए decode अधिक अनुक्रमिक है। यहीं से स्ट्रीमिंग टाइपिंग प्रभाव आता है, और यह आमतौर पर वह चरण है जो यह निर्धारित करता है कि मॉडल तेज़ है या धीमा।

लंबे प्रॉम्प्ट prefill को दंडित करते हैं। लंबे उत्तर decode को दंडित करते हैं। लंबी बातचीत दोनों को दंडित करती है क्योंकि KV cache बढ़ता है।

चैट सत्र में, प्रत्येक मोड़ कैश में जुड़ता है। यदि आप बातचीत को 16K टोकन तक चलने देते हैं, तो आप प्रत्येक नए उत्पन्न टोकन पर सभी 16K टोकन के लिए मेमोरी लागत का भुगतान कर रहे हैं। यही कारण है कि चैट UI जो अनंत इतिहास रखते हैं, अंततः धीमे हो जाते हैं या क्रैश हो जाते हैं।

Decoding

मॉडल logits उत्पन्न करने के बाद, उसने अभी तक कुछ नहीं लिखा है। उसने केवल प्रत्येक संभावित अगले टोकन को स्कोर किया है। Decoding वह नीति है जो उन स्कोर को एक वास्तविक टोकन में बदलती है, उस टोकन को कॉन्टेक्स्ट में जोड़ती है, और लूप को दोहराती है।

Runtime, या इन्फ्रेंस इंजन, कई तरीकों से टोकन चुन सकता है। यह हर बार सबसे अधिक संभावना वाला टोकन चुन सकता है। यह संभावित टोकन के एक संकुचित सेट से सैंपल कर सकता है। यह पुनरावृत्ति को दंडित कर सकता है। यह एक सीमांकक पर रुक सकता है। यह एक निश्चित बीज का उपयोग कर सकता है ताकि वही प्रॉम्प्ट पुनरुत्पादक रूप से व्यवहार करे।

ये विकल्प मॉडल वेट्स को नहीं बदलते, लेकिन वे मॉडल की आवाज़, नियतत्ववाद, रचनात्मकता, जोखिम प्रोफ़ाइल और लूप करने की प्रवृत्ति को बदलते हैं।

महत्वपूर्ण नॉब तीन व्यावहारिक प्रश्नों का उत्तर देते हैं:

यादृच्छिकता: कितनी भिन्नता की अनुमति है?
पूंछ की पहुंच: सैंपलर कम-संभावना वाले टोकन में कितनी दूर जा सकता है?
सीमाएँ: लूप, रैम्बलिंग, स्कीमा ब्रेक या अनियंत्रित आउटपुट को क्या रोकता है?

सटीक काम के लिए, संकीर्ण शुरू करें: कम तापमान, छोटी अधिकतम-टोकन सीमाएँ, स्पष्ट स्टॉप अनुक्रम, और जब आउटपुट JSON या स्कीमा से मेल खाना चाहिए तो विवश डिकोडिंग। रचनात्मक काम के लिए, उच्च तापमान, top-p और बाद में रैंक किए गए कई उम्मीदवारों के साथ सैंपलर को अधिक जगह दें। कोडिंग के लिए, पहले पास को रूढ़िवादी रखें, फिर केवल तभी विकल्पों का नमूना लें जब आप जानबूझकर खोज कर रहे हों।

Greedy decoding हमेशा अधिक सटीक नहीं होता है। यह अक्सर भंगुर होता है। एक greedy डिकोडर लूप में फंस सकता है या सामान्य उत्तर उत्पन्न कर सकता है क्योंकि यह कभी विकल्पों का पता नहीं लगाता। मूल्यांकन के लिए, नियतात्मक सेटिंग का उपयोग करें। विचार-मंथन के लिए, मॉडल को सांस लेने दें।

What A Model Package Contains

एक चलने योग्य स्थानीय LLM एक बड़ी वेट फ़ाइल से अधिक है। मॉडल पैकेज में आमतौर पर शामिल होता है:

आर्किटेक्चर/कॉन्फ़िग: लेयर काउंट, हिडन साइज़, अटेंशन प्रकार, RoPE सेटिंग्स, शब्दावली आकार, विशेष टोकन और कॉन्टेक्स्ट लंबाई।
वेट्स: सीखे गए पैरामीटर, जिन्हें अक्सर safetensors, GGUF, GPTQ, AWQ, EXL2 या किसी अन्य runtime-विशिष्ट प्रारूप में संग्रहीत किया जाता है।
Tokenizer: वे नियम जो टेक्स्ट को टोकन IDs में और टोकन IDs को वापस टेक्स्ट में बदलते हैं।
Chat template: सिस्टम, उपयोगकर्ता, सहायक, टूल और तर्क संदेशों के लिए सटीक मार्कअप।
जनरेशन कॉन्फ़िग: तापमान, top-p, स्टॉप टोकन, पुनरावृत्ति दंड और अधिकतम टोकन के लिए डिफ़ॉल्ट।
लाइसेंस और मॉडल कार्ड: मॉडल का उपयोग कैसे किया जा सकता है, इसके लिए कानूनी और परिचालन निर्देश।

वेट्स सबसे बड़ी फ़ाइल हैं, लेकिन वे पूरे मॉडल नहीं हैं। यदि tokenizer, config या chat template गलत है, तो वही वेट्स टूटे हुए महसूस हो सकते हैं।

पैकेज अनुभाग आपको बताता है कि एक साथ क्या यात्रा करनी है। अगला भाग बताता है कि chat template वह हिस्सा क्यों है जिसे लोग अक्सर तोड़ते हैं।

Chat Templates

एक चैट मॉडल को एक विशिष्ट वार्तालाप प्रारूप के साथ प्रशिक्षित किया गया था। उदाहरण के लिए, यह कुछ इस तरह की अपेक्षा कर सकता है:

<|system|> आप एक सहायक सहायक हैं। <|user|> KV cache समझाएं। <|assistant|>

दूसरा मॉडल अपेक्षा कर सकता है:

[BOS] [INST] KV cache समझाएं। [/INST]

दूसरा ChatML-शैली मार्कर का उपयोग कर सकता है। दूसरे को विशेष तर्क टोकन की आवश्यकता हो सकती है। दूसरे को टूल-कॉल XML या JSON रैपर की आवश्यकता हो सकती है।

गलत प्रारूप का उपयोग करने से बकवास, भूमिका भ्रम, अनदेखा सिस्टम प्रॉम्प्ट, दोहराए गए प्रॉम्प्ट, इनकार की विचित्रता, टूटी हुई टूल कॉल, खराब बेंचमार्क परिणाम और यह निष्कर्ष हो सकता है कि मॉडल बेवकूफ है जबकि टेम्पलेट वास्तविक बग है।

सर्वोत्तम अभ्यास:

Transformers का उपयोग करते समय tokenizer का apply_chat_template उपयोग करें।
Harbor-समर्थित फ्रंटएंड, llama.cpp, LM Studio, vLLM, या SGLang में मॉडल-विशिष्ट टेम्पलेट का उपयोग करें।
जांचें कि मॉडल base, instruct, chat, reasoning या tool-tuned है या नहीं।
सुनिश्चित करें कि BOS/EOS टोकन सही हैं।
जब तक उन्हें लंबा होने की आवश्यकता न हो, सिस्टम प्रॉम्प्ट को छोटा रखें।
टूल उपयोग के लिए, मॉडल/runtime द्वारा अपेक्षित सटीक स्कीमा का पालन करें।

यदि आप एक ऐसा एप्लिकेशन बना रहे हैं जो उपयोगकर्ताओं को मॉडल स्विच करने देता है, तो आपको टेम्पलेट स्विचिंग की भी आवश्यकता है। एक टेम्पलेट प्रारूप को हार्डकोड करना और फिर एक मॉडल लोड करना जो दूसरे की अपेक्षा करता है, खराब स्थानीय-मॉडल मूल्यांकन का एक सामान्य स्रोत है।

टेम्पलेट को API अनुबंध की तरह मानें। यदि आप इसे गलत करते हैं, तो आप वास्तव में उस मॉडल का परीक्षण नहीं कर रहे हैं जिसे आप सोच रहे हैं।

Model Types

सभी LLM एक ही व्यवहार के लिए ट्यून नहीं किए जाते हैं।

अधिकांश उपयोगकर्ताओं के लिए, डिफ़ॉल्ट प्रारंभिक बिंदु एक हालिया instruct/chat-tuned मॉडल होना चाहिए जो आराम से मेमोरी में फिट बैठता है।

जब तक आपको पता न हो कि क्यों, base मॉडल से शुरू न करें। Base मॉडल आपके प्रॉम्प्ट का उत्तर देने के बजाय उसे पूरा करते हैं। वे शोधकर्ताओं, फाइन-ट्यूनर्स और कस्टम पाइपलाइन बनाने वाले लोगों के लिए उपयोगी हैं। वे बाकी सभी के लिए निराशाजनक हैं।

यदि आप base मॉडल से पूछते हैं फ्रांस की राजधानी क्या है?, तो यह पेरिस का उत्तर देने के बजाय और पेरिस की जनसंख्या क्या है? के साथ जारी रह सकता है।

व्यावहारिक विभाजन सरल है:

Base मॉडल: प्रीट्रेनिंग अनुसंधान, फाइन-ट्यूनिंग और कस्टम पाइपलाइनों के लिए अच्छा।
Instruct मॉडल: प्रत्यक्ष निर्देश पालन के लिए अच्छा।
Chat मॉडल: भूमिका स्वरूपण के साथ बहु-मोड़ संवाद के लिए अच्छा।
Reasoning मॉडल: अच्छा जब कार्य अतिरिक्त सोच टोकन और सत्यापन से लाभान्वित होता है।
Tool-tuned मॉडल: अच्छा जब संरचित कॉल, JSON या फ़ंक्शन उपयोग मायने रखता है।

What Local Really Means

एक स्थानीय LLM वह मॉडल है जिसके वेट्स और इन्फ्रेंस runtime आपके नियंत्रण में हैं। आप तय करते हैं कि कौन सा मॉडल चलता है, यह कैसे चलता है, यह कौन सा डेटा देखता है, और आउटपुट का क्या होता है।

वह स्वतंत्रता काम के साथ आती है। अब आप ops टीम हैं। आप डाउनलोड, अपडेट, संगतता, मेमोरी सीमाएँ और सुरक्षा संभालते हैं। जब कुछ टूटता है, तो दाखिल करने के लिए कोई सहायता टिकट नहीं है। केवल आप, लॉग और दस्तावेज़ीकरण हैं।

Local का अर्थ हो सकता है:

एक फ़ोन पर चलने वाला 2B पैरामीटर मॉडल।
एक उपभोक्ता GPU पर चलने वाला 7B से 14B मॉडल।
एक उच्च-अंत वर्कस्टेशन पर चलने वाला 30B से 70B मॉडल।
एक या अधिक डेटासेंटर GPU पर चलने वाला विरल MoE मॉडल।
vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio या कस्टम PyTorch स्टैक का उपयोग करके एक निजी परिनियोजन।

मुख्य बिंदु: local का स्वचालित रूप से ऑफ़लाइन, निजी, सुरक्षित, सस्ता या ओपन सोर्स होना नहीं है। इसका केवल यह अर्थ है कि आप स्वयं मॉडल चला रहे हैं। एक स्थानीय ऐप अभी भी घर पर कॉल कर सकता है। एक मॉडल ओपन-वेट हो सकता है लेकिन ओपन सोर्स नहीं। एक मॉडल स्थानीय हो सकता है लेकिन लोड करना असुरक्षित हो सकता है। एक क्वांटाइज़्ड मॉडल मेमोरी में फिट हो सकता है लेकिन खराब उत्तर दे सकता है।

यह व्यापार तब सार्थक है जब आपको गोपनीयता, कम विलंबता, कस्टम व्यवहार, ऑफ़लाइन संचालन या पैमाने पर लागत नियंत्रण की आवश्यकता हो। यह तब सार्थक नहीं है जब आपको पूर्ण सर्वश्रेष्ठ मॉडल गुणवत्ता की आवश्यकता हो और आपके पास मेल खाने वाला हार्डवेयर न हो। उस स्थिति में, होस्टेड API सही उपकरण है।

स्थानीय LLM व्यावहारिक हैं जब आप एक समीकरण समझते हैं:

स्थानीय LLM सफलता = मॉडल फिट + सही प्रॉम्प्ट प्रारूप + अच्छा runtime + यथार्थवादी मूल्यांकन।

बाकी सब विवरण हैं। विवरण मायने रखते हैं।

Quantization

Quantization वजन को कम परिशुद्धता में संग्रहीत करता है ताकि मेमोरी कम हो और कभी-कभी थ्रूपुट में सुधार हो।

2026 में स्थानीय उपयोगकर्ताओं के लिए अंगूठे का नियम:

FP16/BF16: जब मेमोरी प्रचुर मात्रा में हो तो सर्वोत्तम गुणवत्ता। मूल्यांकन के लिए इसे आधार रेखा के रूप में उपयोग करें।
Q8 / INT8: कई कार्यों के लिए लगभग दोषरहित, लेकिन फिर भी बड़ा। अच्छा जब आपके पास VRAM हो और न्यूनतम गुणवत्ता हानि चाहते हों।
Q6 / Q5: मध्यम बचत के साथ उत्कृष्ट गुणवत्ता। यह एक मजबूत मध्य मार्ग है।
Q4: कई चैट और दस्तावेज़ कार्यप्रवाहों के लिए डिफ़ॉल्ट उपभोक्ता स्वीट स्पॉट।
Q3 / Q2: केवल जब आपको एक बड़ा मॉडल फिट करना हो। गणित, कोड, संरचित आउटपुट और टूल उपयोग पहले खराब होते हैं।

वेट क्वांटाइज़ेशन, KV-cache क्वांटाइज़ेशन के समान नहीं है। वेट क्वांटाइज़ेशन मॉडल को सिकोड़ता है। KV-cache क्वांटाइज़ेशन लाइव कॉन्टेक्स्ट मेमोरी को सिकोड़ता है।

KV cache के लिए, FP16/BF16 को स्वच्छ आधार रेखा और FP8/INT8 को व्यावहारिक स्थानीय संपीड़न तल के रूप में मानें। 8-बिट से नीचे अनुसंधान-भारी और कार्यभार-संवेदनशील है। इसका उपयोग अपने वास्तविक प्रॉम्प्ट पर गुणवत्ता मापने के बाद ही करें।

क्वांटाइज़ेशन विफलता पहले गणित, बहु-चरण तर्क, कोड शुद्धता, टूल-उपयोग विश्वसनीयता, JSON/स्कीमा अनुपालन, सूक्ष्म निर्देश पालन और लंबी-कॉन्टेक्स्ट पुनर्प्राप्ति में दिखाई देती है।

उच्च परिशुद्धता पर एक छोटा मॉडल बहुत कम बिट्स में कुचले गए बड़े मॉडल को हरा सकता है। पैरामीटर गणना की पूजा न करें। Q6 पर 7B मॉडल, Q2 पर 13B मॉडल को तर्क कार्यों में हरा सकता है जबकि कम मेमोरी का उपयोग करता है और तेज़ चलता है।

File Formats And Load Safety

safetensors एक सुरक्षित टेंसर क्रमांकन प्रारूप है जिसे Python pickle व्यवहार के बिना टेंसर संग्रहीत करने के लिए डिज़ाइन किया गया है। जब संभव हो safetensors का उपयोग करें, विशेष रूप से PyTorch/Transformers मॉडल के लिए।

अविश्वसनीय स्रोतों से यादृच्छिक .bin फ़ाइलों से बचें। PyTorch pickle-आधारित लोडिंग डिसीरियलाइज़ेशन के दौरान मनमाना कोड निष्पादित कर सकती है। स्थानीय AI सुरक्षा नियम नंबर एक: किसी अजनबी की मॉडल फ़ाइल को अजनबी के कोड निष्पादन में न बदलने दें।

GGUF llama.cpp पारिस्थितिकी तंत्र का बाइनरी मॉडल प्रारूप है। GGUF का उपयोग करें जब आप llama.cpp, CPU इन्फ्रेंस, Apple Silicon इन्फ्रेंस, सरल स्थानीय सर्वर, पोर्टेबल क्वांटाइज़्ड मॉडल या LM Studio जैसे डेस्कटॉप टूल चाहते हों।

ONNX मानकीकृत परिनियोजन और हार्डवेयर-विशिष्ट त्वरण के लिए उपयोगी है, विशेष रूप से सामान्य PyTorch स्टैक के बाहर। यदि आप Intel NPU, ARM डिवाइस या कस्टम एक्सेलेरेटर पर परिनियोजित कर रहे हैं, तो ONNX अक्सर कम से कम प्रतिरोध का मार्ग होता है।

TensorRT-LLM उत्पादन GPU परिनियोजन के लिए NVIDIA का उच्च-प्रदर्शन इन्फ्रेंस पथ है। यह शक्तिशाली है, लेकिन llama.cpp या Harbor से अधिक जटिल है। आप आमतौर पर एक चेकपॉइंट को TensorRT इंजन में बदलते हैं, जिसमें समय और GPU मेमोरी लगती है, लेकिन एक बार बनने के बाद उत्कृष्ट थ्रूपुट देता है।

EXL2 / GPTQ / AWQ प्रारूप GPU-केंद्रित स्थानीय इन्फ्रेंस समुदायों में आम हैं, विशेष रूप से बड़े मॉडलों को एकल GPU पर निचोड़ने के लिए।

फ़ाइल प्रारूप का चुनाव कॉस्मेटिक नहीं है। यह निर्धारित करता है कि कौन से runtimes मॉडल लोड कर सकते हैं, आप किस क्वांटाइज़ेशन का उपयोग कर सकते हैं और यह कितनी तेज़ी से चलता है।

Runtimes And Serving Modes

Runtime वह सॉफ्टवेयर है जो मॉडल लोड करता है और इन्फ्रेंस करता है। 2026 में, स्थानीय LLM runtime पारिस्थितिकी तंत्र परिपक्व, उपयोगी और खंडित है।

एक व्यक्ति के लिए स्थानीय रूप से प्रयोग करने के लिए, Harbor, LM Studio या llama.cpp से शुरू करें। Harbor सबसे उपयुक्त है जब आप फ्रंटएंड, बैकएंड और सहायक सेवाओं के साथ एक पूर्ण स्थानीय स्टैक चाहते हैं। LM Studio सबसे आसान डेस्कटॉप-प्रथम पथ है। llama.cpp पोर्टेबल निम्न-स्तरीय वर्कहॉर्स है।

टीम या निजी सेवा के लिए, vLLM या SGLang देखें। अधिकतम NVIDIA उत्पादन प्रदर्शन के लिए, TensorRT-LLM की जाँच करें। ब्राउज़र या मोबाइल परिनियोजन के लिए, MLC या WebLLM देखें।

Runtime चुनाव अक्सर आपको एक प्रारूप पारिस्थितिकी तंत्र में बंद कर देता है। llama.cpp का अर्थ है GGUF। vLLM और SGLang का आमतौर पर अर्थ safetensors या Hugging Face चेकपॉइंट है। TensorRT-LLM का अर्थ ONNX या अनुकूलित इंजन है। पहले runtime चुनें, फिर सही प्रारूप में मॉडल खोजें।

तीन व्यावहारिक सर्विंग मोड हैं।

एकल-उपयोगकर्ता स्थानीय का अर्थ है एक व्यक्ति के लिए डेस्कटॉप ऐप, CLI स्टैक या कमांड-लाइन सर्वर। Harbor, LM Studio, llama.cpp सर्वर, ExLlama/TabbyAPI और छोटे Transformers स्क्रिप्ट सभी यहाँ फिट होते हैं। लक्ष्य त्वरित पुनरावृत्ति है: ops प्लेटफ़ॉर्म बनाए बिना व्यवहार, गति, मेमोरी उपयोग और प्रॉम्प्ट प्रारूपों की तुलना करना।

टीम या निजी API का अर्थ है वर्कस्टेशन या सर्वर पर OpenAI-संगत एंडपॉइंट। vLLM, SGLang, TensorRT-LLM और llama.cpp सर्वर सभी यहाँ मॉडल आकार और थ्रूपुट आवश्यकताओं के आधार पर दिखाई देते हैं। एक बार जब कई लोग या कार्य एक मॉडल साझा करते हैं, तो आपको निगरानी, प्रॉम्प्ट/संस्करण प्रबंधन, रूटिंग और यथार्थवादी विलंबता माप की आवश्यकता होती है।

प्रोडक्शन सर्विसिंग एक अलग ही काम है। अब बातचीत में कंटीन्यूअस बैचिंग, प्रीफिक्स कैशिंग, स्पेक्युलेटिव डिकोडिंग, पेज्ड अटेंशन, टेंसर पैरेललिज़्म, पाइपलाइन पैरेललिज़्म, क्वांटाइज़्ड सर्विसिंग, स्ट्रक्चर्ड आउटपुट, लोड बैलेंसिंग, GPU उपयोग, लेटेंसी परसेंटाइल, प्रॉम्प्ट कैशिंग, एडमिशन कंट्रोल, लॉगिंग, फ़ेलओवर, प्राइवेसी और कॉस्ट कंट्रोल शामिल हैं।

प्रोडक्शन स्केल पर, "क्या मैं मॉडल लोड कर सकता हूँ?" यह आसान सवाल है। मुश्किल सवाल यह है कि "क्या मैं इसे वास्तविक ट्रैफ़िक के तहत विश्वसनीय रूप से सर्व कर सकता हूँ?"

लोकल मॉडल के लिए VRAM गणित

मुख्य तीन मेमोरी उपभोक्ता हैं:

मॉडल वेट्स
KV कैश
रनटाइम ओवरहेड

वेट मेमोरी का मोटा फ़ॉर्मूला है:

वेट_मेमोरी ~= पैरामीटर × बाइट्स_प्रति_पैरामीटर

उपयोगी अनुमान:

FP16/BF16: लगभग 2 बाइट प्रति पैरामीटर।
INT8/Q8: लगभग 1 बाइट प्रति पैरामीटर।
Q4: लगभग 0.5 बाइट प्रति पैरामीटर, प्लस फ़ॉर्मेट ओवरहेड।

फिर जोड़ें:

रनटाइम ओवरहेड: फ्रेमवर्क बफ़र, CUDA ओवरहेड, मेमोरी फ़्रैग्मेंटेशन और अस्थायी टेंसर।
KV कैश: एक्टिव कॉन्टेक्स्ट में हर टोकन के साथ बढ़ता है।
बैच/कंकरेंसी मेमोरी: प्रत्येक समवर्ती अनुरोध को अपने स्वयं के कैश की आवश्यकता होती है।
विज़न एनकोडर मेमोरी: इमेज भी टोकन बन जाती हैं।
स्पेक्युलेटिव डिकोडिंग मेमोरी: ड्राफ्ट मॉडल, ड्राफ्ट हेड्स या अतिरिक्त वेरिफिकेशन स्ट्रक्चर मुफ्त नहीं हैं।
अडैप्टर मेमोरी: LoRA अडैप्टर छोटे होते हैं, लेकिन वास्तविक होते हैं।

MoE मॉडल एक और पेचीदगी जोड़ते हैं। एक मॉडल प्रति टोकन अपने पैरामीटर का केवल एक अंश सक्रिय कर सकता है, लेकिन निष्क्रिय विशेषज्ञों को आमतौर पर मेमोरी में कहीं न कहीं रहना होता है। एक्टिव पैरामीटर कंप्यूट लागत को प्रभावित करते हैं। कुल पैरामीटर अभी भी लोडिंग और क्षमता नियोजन को प्रभावित करते हैं।

एक यथार्थवादी अनुमान इस तरह दिखता है:

कुल_मेमोरी = क्वांटाइज़्ड_वेट्स + KV_कैश_फ़ॉर_कॉन्टेक्स्ट + रनटाइम_ओवरहेड + बैच_या_कंकरेंसी_ओवरहेड + सेफ़्टी_मार्जिन

यहाँ जाल है: एक 13B मॉडल Q4 में 8K कॉन्टेक्स्ट पर आसानी से फ़िट हो सकता है, फिर 32K पर विफल हो सकता है क्योंकि KV कैश चार गुना बढ़ गया। वेट्स नहीं बदले। कॉन्टेक्स्ट बदल गया।

10 से 20 प्रतिशत हेडरूम छोड़ें। 99 प्रतिशत VRAM उपयोग पर चलना आउट-ऑफ-मेमोरी एरर और फ़्रैग्मेंटेशन विफलताओं को निमंत्रण देना है।

व्यवहार में हार्डवेयर स्तर

ये 2026 के व्यावहारिक अंगूठे के नियम हैं, जो क्वांटाइज़्ड इन्फ़रेंस और उचित कॉन्टेक्स्ट लंबाई मानते हैं। सटीक परिणाम रनटाइम, क्वांटाइज़ेशन, मॉडल आर्किटेक्चर, अटेंशन प्रकार, कॉन्टेक्स्ट लंबाई और OS/ड्राइवर ओवरहेड पर निर्भर करते हैं।

2026 में अधिकांश गंभीर लोकल उपयोगकर्ताओं के लिए, 16 GB न्यूनतम आरामदायक GPU स्तर है, 24 GB सबसे अच्छा वैल्यू एन्थुसियास्ट स्तर है, और 48 GB+ वह जगह है जहाँ मजबूत लोकल दुनिया खुलती है।

प्रदर्शन मेमोरी बैंडविड्थ, GPU FLOPs, VRAM क्षमता, KV-कैश आकार, अटेंशन इम्प्लीमेंटेशन, क्वांटाइज़ेशन, बैच आकार, प्रॉम्प्ट लंबाई, जनरेटेड लंबाई और रनटाइम परिपक्वता पर निर्भर करता है।

डिकोड अक्सर मेमोरी-बैंडविड्थ-बाउंड होता है: GPU प्रति बाइट अपेक्षाकृत कम कंप्यूट करते हुए बार-बार मॉडल वेट स्ट्रीम करता है। प्रीफ़िल अधिक कंप्यूट-बाउंड है क्योंकि यह प्रॉम्प्ट को समानांतर में संसाधित कर सकता है। यही कारण है कि समान VRAM क्षमता वाले दो कार्डों की टोकन स्पीड बहुत भिन्न हो सकती है यदि एक में बहुत अधिक मेमोरी बैंडविड्थ हो।

सबसे दर्दनाक लोकल सेटअप वह है जहाँ मॉडल लगभग फ़िट होता है और लेयर को CPU पर स्पिल करता है। यह तकनीकी रूप से चल सकता है, लेकिन टोकन स्पीड गिर सकती है। CPU ऑफ़लोड प्रयोग के लिए स्वीकार्य है। यह प्रदर्शन रणनीति नहीं है।

एक मॉडल चुनें जो फ़िट हो

व्यावहारिक सवाल यह नहीं है कि "सबसे अच्छा मॉडल कौन सा है?" यह है कि "आपके हार्डवेयर पर आपके वास्तविक वर्कलोड को जीतने वाला सबसे छोटा मॉडल कौन सा है?"

हाल के एक इंस्ट्रक्ट/चैट मॉडल से शुरू करें जो आपकी वास्तविक ज़रूरत की कॉन्टेक्स्ट लंबाई के साथ आराम से फ़िट हो। यदि आप 8 GB से 12 GB VRAM या यूनिफ़ाइड मेमोरी पर हैं, तो छोटे से शुरू करें। यदि आप 16 GB से 24 GB पर हैं, तो पहले 7B से 14B क्लास के मॉडल टेस्ट करें। यदि आपके पास 48 GB या अधिक है, तो बड़े डेंस मॉडल और MoE मॉडल यथार्थवादी हो जाते हैं।

किसी चेकपॉइंट से प्यार करने से पहले इस मेमोरी गेट का उपयोग करें:

वेट + KV कैश + रनटाइम ओवरहेड <= उपलब्ध मेमोरी का 80 से 90 प्रतिशत

फिर उम्मीदवारों पर समान 20 से 50 प्रॉम्प्ट चलाएँ। अपने वास्तविक कार्य शामिल करें: कोडिंग एडिट, दस्तावेज़ Q&A, JSON आउटपुट, सारांश, टूल कॉल, लंबा कॉन्टेक्स्ट, या जो कुछ भी आपको वास्तव में चाहिए। उत्तर गुणवत्ता, लेटेंसी, मेमोरी उपयोग, टेम्पलेट विश्वसनीयता और विफलता मोड मापें।

एक व्यावहारिक मॉडल विकल्प आमतौर पर पाँच जाँचों पर आता है:

कार्य फ़िट: चैट, कोडिंग, दस्तावेज़, एजेंट, मल्टीमॉडल, एज या फ़ाइन-ट्यूनिंग।
मेमोरी फ़िट: वेट, KV कैश, रनटाइम ओवरहेड और सेफ़्टी मार्जिन।
इंटरफ़ेस फ़िट: टोकनाइज़र, चैट टेम्पलेट, स्टॉप टोकन, टूल स्कीमा और रीज़निंग मोड।
रनटाइम फ़िट: क्या आपका रनटाइम इस आर्किटेक्चर, क्वांटाइज़ेशन, कॉन्टेक्स्ट लंबाई और सर्विंग मोड का अच्छी तरह से समर्थन करता है?
लाइसेंस फ़िट: क्या आप वास्तव में इसका उपयोग वहाँ कर सकते हैं जहाँ आप इसका उपयोग करने की योजना बनाते हैं?

लीडरबोर्ड खोज के लिए उपयोगी हैं। वे आपके स्वयं के मूल्यांकन का विकल्प नहीं हैं। आपका वर्कलोड ही वह बेंचमार्क है जो मायने रखता है।

एक साधारण लोकल असिस्टेंट के लिए, हाल ही का 7B से 14B इंस्ट्रक्ट मॉडल, Q4/Q5 क्वांटाइज़ेशन, सही चैट टेम्पलेट, 8K से 32K कॉन्टेक्स्ट और Harbor, LM Studio या llama.cpp चुनें। विशाल आकार पर प्रतिक्रियाशीलता को प्राथमिकता दें।

एक लोकल कोडिंग असिस्टेंट के लिए, यदि आपके पास पर्याप्त VRAM है तो कोड-सक्षम 14B से 32B मॉडल चुनें। कम तापमान, रिपॉजिटरी रिट्रीवल, टेस्ट निष्पादन और पैच-आधारित वर्कफ़्लो का उपयोग करें। बिना टूल के कोड मॉडल आधा उत्पाद है।

एक निजी दस्तावेज़ असिस्टेंट के लिए, एक मजबूत इंस्ट्रक्ट मॉडल, एक लोकल एम्बेडिंग मॉडल, एक रीरैंकर, एक RAG पाइपलाइन, साइटेशन प्रवर्तन और मध्यम-से-लंबा कॉन्टेक्स्ट चुनें। 200-पेज का PDF पेस्ट न करें और उम्मीद न करें।

एक रीज़निंग सेटअप के लिए, एक रीज़निंग-ट्यून्ड मॉडल चुनें, अतिरिक्त टोकन का बजट रखें, कम-से-मध्यम तापमान का उपयोग करें, वेरिफिकेशन जोड़ें और गणित, कोड या खोज के लिए टूल का उपयोग करें। रीज़निंग मॉडल अधिक टोकन खर्च करते हैं। तदनुसार बजट बनाएँ।

कम-संसाधन सेटअप के लिए, 1B से 4B मॉडल, Q4/Q5, छोटे प्रॉम्प्ट, संरचित कार्य, रिट्रीवल या टूल और एक सख्त आउटपुट स्कीमा चुनें। जब कार्य बाध्य हो तो छोटे मॉडल उपयोगी हो जाते हैं।

गति को क्या नियंत्रित करता है

टोकन प्रति सेकंड एक चीज़ द्वारा नियंत्रित नहीं होता है। यह मॉडल आकार, मेमोरी बैंडविड्थ, कंप्यूट, अटेंशन कर्नेल, कॉन्टेक्स्ट लंबाई, क्वांटाइज़ेशन, बैचिंग और रनटाइम गुणवत्ता का परिणाम है।

मुख्य लीवर हैं:

मेमोरी बैंडविड्थ: डिकोड अक्सर मॉडल वेट को बार-बार स्ट्रीम करता है, इसलिए बैंडविड्थ एकल-उपयोगकर्ता टोकन गति पर हावी होती है।
GPU FLOPs: प्रीफ़िल और बड़े बैच अधिक समानांतर कंप्यूट का उपयोग करते हैं, इसलिए FLOPs वहाँ अधिक मायने रखते हैं।
VRAM क्षमता: यदि मॉडल या KV कैश CPU पर स्पिल होता है, तो प्रदर्शन गिर सकता है।
अटेंशन इम्प्लीमेंटेशन: FlashAttention, SDPA, पेज्ड अटेंशन और रनटाइम-विशिष्ट कर्नेल गति और मेमोरी व्यवहार दोनों को बदलते हैं।
क्वांटाइज़ेशन: छोटे वेट मेमोरी मूवमेंट को कम करते हैं, लेकिन आक्रामक क्वांटाइज़ेशन गुणवत्ता को नुकसान पहुँचा सकता है और कभी-कभी डीक्वांटाइज़ेशन ओवरहेड जोड़ सकता है।
बैच आकार और कंकरेंसी: बैचिंग थ्रूपुट में सुधार करती है, लेकिन प्रत्येक सक्रिय अनुक्रम को KV कैश की आवश्यकता होती है।
प्रॉम्प्ट लंबाई: लंबे प्रॉम्प्ट प्रीफ़िल समय बढ़ाते हैं।
जनरेटेड लंबाई: लंबे उत्तर डिकोड गति को उजागर करते हैं।
स्पेक्युलेटिव डिकोडिंग: EAGLE-शैली विधियाँ, MTP, DFlash और DDTree समर्थित होने पर प्रति लक्ष्य पास एक से अधिक ड्राफ्ट टोकन को सत्यापित कर सकती हैं।

दर्दनाक सेटअप लगभग-फ़िट सेटअप है। एक मॉडल जो लेयर या कैश को CPU पर स्पिल करता है, तकनीकी रूप से चल सकता है, लेकिन टोकन गति उपयोग योग्य से दयनीय तक गिर सकती है।

उसी रनटाइम, क्वांटाइज़ेशन, कॉन्टेक्स्ट लंबाई, प्रॉम्प्ट आकार और वर्कलोड का बेंचमार्क करें जिसका आप उपयोग करने की योजना बनाते हैं। BF16 लीडरबोर्ड संख्या आपको यह नहीं बताती कि आपका Q4 लोकल स्टैक कैसा लगेगा।

लंबा कॉन्टेक्स्ट

लंबा कॉन्टेक्स्ट जादुई लगता है: एक प्रॉम्प्ट में 128K, 256K या 1M टोकन। यह उपयोगी है, लेकिन इसकी वास्तविक लागतें हैं।

अधिक कॉन्टेक्स्ट का मतलब है अधिक KV कैश मेमोरी, धीमी प्रॉम्प्ट प्रोसेसिंग, अधिक अटेंशन कार्य, कठिन मूल्यांकन और अप्रासंगिक पाठ के लिए मॉडल को विचलित करने के अधिक तरीके। गुणवत्ता दूरी पर भी घट सकती है। एक मॉडल लंबे दस्तावेज़ के अंत को अच्छी तरह से संभाल सकता है, जबकि शुरुआत के पास दबे महत्वपूर्ण विवरणों को याद कर सकता है।

संपूर्ण-दस्तावेज़ विश्लेषण, कोडबेस स्लाइस, कानूनी या तकनीकी समीक्षा, ट्रांसक्रिप्ट सारांशीकरण, मल्टी-फ़ाइल रीज़निंग और RAG फ़ॉलबैक के लिए लंबे कॉन्टेक्स्ट का उपयोग करें जब रिट्रीवल संदर्भ से चूक जाता है।

लंबे कॉन्टेक्स्ट को रिट्रीवल के प्रतिस्थापन के रूप में न मानें। यह एक पूरक है। बड़े कॉर्पोरा के लिए RAG और अंतिम चयनित साक्ष्य के लिए लंबे कॉन्टेक्स्ट का उपयोग करें।

व्यावहारिक आदतें मदद करती हैं:

महत्वपूर्ण निर्देश शुरुआत और अंत के पास रखें।
सेक्शन हेडर और डिलीमीटर का उपयोग करें।
स्रोत खंडों से जुड़े उद्धरण माँगें।
अप्रासंगिक इतिहास को संपीड़ित करें।
अनंत चैट इतिहास के बजाय सारांश मेमोरी का उपयोग करें।

लंबे कॉन्टेक्स्ट को महंगे अटेंशन के रूप में सोचें, न कि एक मुफ्त नोटबुक के रूप में।

मल्टीमॉडैलिटी

मल्टीमॉडल लोकल मॉडल पाठ के अलावा इमेज और कभी-कभी ऑडियो या वीडियो स्वीकार करते हैं। आधुनिक ओपन-वेट इकोसिस्टम में तेजी से ये मॉडल शामिल हैं।

छिपी हुई लागत यह है कि गैर-पाठ इनपुट भी टोकन बन जाता है। विज़न एनकोडर मेमोरी जोड़ते हैं। इमेज पैच कॉन्टेक्स्ट की खपत करते हैं। ऑडियो और वीडियो इनपुट बजट को विस्फोटित कर सकते हैं। मल्टीमॉडल टेम्पलेट भी केवल-पाठ टेम्पलेट की तुलना में गलत होना आसान है।

एक एकल उच्च-रिज़ॉल्यूशन इमेज कॉन्टेक्स्ट विंडो में हजारों टोकन की खपत कर सकती है। यदि आप मल्टीमॉडल मॉडल स्थानीय रूप से चला रहे हैं, तो इमेज टोकन को उसी तरह गिनें जैसे आप पाठ टोकन गिनते हैं। वे उसी बजट से आते हैं।

छोटे VLM दृश्य विवरणों में भ्रम पैदा कर सकते हैं। OCR विश्वसनीयता भिन्न होती है। चार्ट और तालिकाएँ अभी भी कठिन हैं। गंभीर दस्तावेज़ या इमेज वर्कफ़्लो के लिए, वास्तविक नमूनों के साथ मूल्यांकन करें। एक साधारण फोटो के डेमो पर इनवॉइस निष्कर्षण गुणवत्ता साबित करने के लिए भरोसा न करें।

2026 का लोकल मॉडल परिदृश्य

मॉडल परिदृश्य तेज़ी से बदलता है। 21 मई, 2026 तक, लोकल LLM उपयोगकर्ताओं को परिवारों और पारिस्थितिक तंत्रों के संदर्भ में सोचना चाहिए, न कि एक सर्वश्रेष्ठ मॉडल के बारे में।

Qwen 3.5 / Qwen 3.6 एक प्रमुख ओपन-वेट परिवार है क्योंकि यह पूरे स्टैक को कवर करता है: लैपटॉप के लिए छोटे मॉडल, वर्कस्टेशन के लिए डेंस मिड-साइज़ मॉडल, मल्टी-GPU सर्विंग के लिए MoE मॉडल, FP8 वेरिएंट, लंबा कॉन्टेक्स्ट, बहुभाषी कार्य, कोडिंग, टूल और एजेंटिक वर्कफ़्लो। व्यावहारिक निष्कर्ष सरल है: Qwen एक मजबूत डिफ़ॉल्ट परिवार है जब आप एक ऐसा इकोसिस्टम चाहते हैं जो लैपटॉप प्रयोगों और गंभीर लोकल सर्विंग दोनों को कवर करता हो।

Gemma 4 मायने रखता है क्योंकि Google DeepMind परिवार को उपयोगी लोकल डिप्लॉयमेंट की ओर धकेल रहा है: कुशल एज मॉडल, बड़े डेंस और MoE विकल्प, मल्टीमॉडैलिटी, बड़े मॉडलों पर लंबा कॉन्टेक्स्ट, व्यापक भाषा समर्थन, मजबूत कोडिंग/एजेंट व्यवहार और Apache 2.0 लाइसेंसिंग। यह संयोजन इसे परीक्षण के लायक बनाता है जब वाणिज्यिक उपयोग और डिवाइस-साइड डिप्लॉयमेंट मायने रखता है।

Kimi / Moonshot AI, GLM / Z.ai, DeepSeek, MiniMax और Mistral भी ट्रैक करने के लिए मुख्य परिवार हैं। Kimi लंबी अवधि की कोडिंग, मल्टीमॉडल रीज़निंग, टूल उपयोग और एजेंट वर्कफ़्लो के लिए प्रासंगिक है। GLM कोडिंग एजेंटों, लंबी अवधि के कार्यों, MoE सिस्टम और डिप्लॉयमेंट-उन्मुख मॉडल रिलीज़ के लिए महत्वपूर्ण है। DeepSeek बड़े MoE सिस्टम, मल्टी-हेड लेटेंट अटेंशन, DeepSeekMoE, FP8 सर्विंग पथ, स्पार्स अटेंशन और उच्च-थ्रूपुट सेल्फ-होस्टिंग के कारण प्रभावशाली बना हुआ है। MiniMax व्यावहारिक एजेंट वर्कलोड और इन्फ़रेंस-कुशल MoE मॉडल के लिए देखने लायक है। Mistral अभी भी मायने रखता है क्योंकि इसकी लाइनअप जनरलिस्ट, कोडिंग, रीज़निंग, मल्टीमॉडल और विशेषज्ञ उपयोग मामलों को मजबूत डिप्लॉयमेंट समर्थन के साथ कवर करती है।

Nemotron 3 NVIDIA का ओपन मॉडल परिवार है जो NVIDIA हार्डवेयर पर प्रोडक्शन-ग्रेड एजेंट सिस्टम के लिए है। परिवार में Nano, Super और Ultra आकार शामिल हैं, हाइब्रिड Mamba-Transformer MoE डिज़ाइन का उपयोग करता है, और TensorRT-LLM, NIM, Dynamo, Blackwell NVFP4/FP8 पथ और एंटरप्राइज एजेंट डिप्लॉयमेंट से निकटता से जुड़ा हुआ है। इसे एक आकस्मिक डेस्कटॉप-चैट परिवार से कम और एक संकेत के रूप में अधिक मानें कि NVIDIA ओपन-वेट सर्विंग स्टैक को कहाँ ले जाना चाहता है।

ओपन-वेट AI अब केवल Llama बनाम बाकी सब कुछ नहीं है। आप एक इकोसिस्टम चुन रहे हैं: वेट, लाइसेंस, टोकनाइज़र, टेम्पलेट, क्वांटाइज़ेशन, रनटाइम समर्थन, सर्विंग पथ, सामुदायिक उपकरण और विफलता मोड।

Qwen 27B डेंस मॉडल

Qwen 3.5 / 3.6 27B (डेंस) लोकल उपयोगकर्ताओं के लिए सबसे व्यावहारिक पब्लिक-वेट विकल्पों में से एक है जो कोडिंग, बहुभाषी कार्य, टूल उपयोग, सोच/गैर-सोच मोड और लंबे कॉन्टेक्स्ट की परवाह करते हैं। Qwen 3.5 27B और Qwen 3.6 27B मॉडल कार्ड OpenAI-संगत सर्विंग पथ, सोच मोड डिफ़ॉल्ट, टूल उपयोग और 262,144 टोकन तक की कॉन्टेक्स्ट लंबाई का वर्णन करते हैं, समर्थित फ्रेमवर्क में YaRN के माध्यम से लंबे-कॉन्टेक्स्ट विस्तार के साथ।

जब रनटाइम कोडिंग, एजेंट या बहुभाषी कवरेज के लिए सही ढंग से कॉन्फ़िगर किया जाता है, तो Qwen 2x RTX 3090 सेटअप के लिए एक मजबूत डिफ़ॉल्ट है।

इन्फ़रेंस रिसर्च

2026 की सीमा केवल मॉडल गुणवत्ता नहीं है। यह इन्फ़रेंस दक्षता भी है। PagedAttention सर्विंग में KV-कैश मेमोरी बर्बादी पर हमला करता है। FP8 KV कैश अब vLLM जैसी प्रणालियों में एक व्यावहारिक रनटाइम सुविधा है। DFlash और DDTree ब्लॉक डिफ्यूज़न ड्राफ्ट मॉडल और ड्राफ्ट ट्री के साथ स्पेक्युलेटिव डिकोडिंग का पता लगाते हैं। NVFP4 NVIDIA हार्डवेयर पर भी देखने लायक है क्योंकि यह समर्थित स्टैक के लिए व्यावहारिक डिप्लॉयमेंट वार्तालाप को बदलता है।

इसमें से कुछ प्रोडक्शन-रेडी है। इसमें से कुछ अभी भी शोध है। इसमें से कुछ केवल तभी मायने रखता है यदि आपका रनटाइम इसका सफाई से समर्थन करता है। पेपर स्पीडअप को डेस्कटॉप ऐप में एक चेकबॉक्स के रूप में न मानें।

विफलता मोड और समाधान

अधिकांश लोकल LLM विफलताएँ रहस्यमय नहीं हैं। वे आमतौर पर मेमोरी फ़िट, फ़ॉर्मेटिंग, रनटाइम समर्थन, डिकोडिंग सेटिंग्स या रिट्रीवल गुणवत्ता से आती हैं।

मेमोरी खत्म: वेट, KV कैश, रनटाइम ओवरहेड या बैच आकार फ़िट नहीं है। छोटे मॉडल का उपयोग करें, कॉन्टेक्स्ट कम करें, बैच/कंकरेंसी कम करें, बेहतर क्वांटाइज़ेशन चुनें या अधिक हेडरूम छोड़ें।

बकवास या भूमिका भ्रम: चैट टेम्पलेट, टोकनाइज़र, BOS/EOS टोकन, रीज़निंग-मोड स्विच या टूल स्कीमा गलत है। मॉडल गुणवत्ता को दोष देने से पहले मॉडल कार्ड और रनटाइम टेम्पलेट सत्यापित करें।

धीमा पहला टोकन: प्रीफ़िल महंगा है। प्रॉम्प्ट छोटा करें, प्रीफ़िक्स कैशिंग का उपयोग करें, रिट्रीवल में सुधार करें, कॉन्टेक्स्ट कम करें या तेज़ रनटाइम का उपयोग करें।

धीमी स्ट्रीमिंग: डिकोड अड़चन है। मेमोरी बैंडविड्थ, क्वांटाइज़ेशन, CPU स्पिल, अटेंशन बैकएंड, स्पेक्युलेटिव डिकोडिंग समर्थन की जाँच करें और क्या मॉडल हार्डवेयर के लिए बहुत बड़ा है।

खराब दस्तावेज़ उत्तर: रिट्रीवल शायद विफल रहा। पार्स किए गए पाठ, चंक सीमाएँ, मेटाडेटा, टॉप-के रिट्रीवल, रीरैंकिंग और साइटेशन ग्राउंडिंग का निरीक्षण करें।

खराब JSON या टूल कॉल: कम तापमान, बाधित डिकोडिंग, सख्त स्कीमा, बेहतर उदाहरण और टूल उपयोग के लिए ट्यून किए गए मॉडल का उपयोग करें।

दोहराए जाने वाले लूप: तापमान या टॉप-पी कम करें, पुनरावृत्ति दंड जोड़ें, स्टॉप टोकन जाँचें और सुनिश्चित करें कि टेम्पलेट मॉडल को अपने स्वयं के उत्तर को एक नए प्रॉम्प्ट के रूप में देखने का कारण नहीं बना रहा है।

उबाऊ जाँचों से शुरू करें। वे मॉडल बदलने से अधिक समस्याएँ ठीक करते हैं।

स्टैक को कैसे बढ़ाएँ

शुरुआती: सबसे आसान उपयोगी सेटअप

Harbor या LM Studio, हाल ही का 4B से 9B इंस्ट्रक्ट मॉडल, Q4 क्वांटाइज़ेशन, 8K से 32K कॉन्टेक्स्ट और एक अंतर्निहित चैट UI का उपयोग करें। समान आकार वर्ग में दो या तीन मॉडल डाउनलोड करें और उनकी तुलना समान प्रॉम्प्ट पर करें।

लक्ष्य: प्रॉम्प्टिंग सीखें, मॉडलों की तुलना करें, गति और मेमोरी समझें और शुरू में कस्टम कोड से बचें।

मध्यवर्ती: डेवलपर सेटअप

llama.cpp या Transformers, GGUF या safetensors, एक OpenAI-संगत लोकल सर्वर, एक सरल RAG पाइपलाइन और एक छोटा मूल्यांकन सेट का उपयोग करें। केवल चैट UI का उपयोग करने के बजाय अपने लोकल सर्वर को वास्तविक एप्लिकेशन या स्क्रिप्ट से कॉल करें।

लक्ष्य: लोकल ऐप बनाएँ, रिट्रीवल का परीक्षण करें, गुणवत्ता मापें और लोकलहोस्ट से सर्व करें।

उन्नत: निजी सर्विंग सेटअप

vLLM या SGLang, एक या अधिक GPU, एक OpenAI-संगत API, मॉनिटरिंग, प्रॉम्प्ट/संस्करण प्रबंधन, एक मूल्यांकन सूट, रीरैंकिंग के साथ RAG और टूल सैंडबॉक्सिंग का उपयोग करें।

लक्ष्य: वास्तविक उपयोगकर्ताओं या आंतरिक वर्कफ़्लो की सेवा करें, थ्रूपुट और लेटेंसी को अनुकूलित करें और सुरक्षा और अवलोकन क्षमता बनाए रखें।

विशेषज्ञ: कस्टम ऑप्टिमाइज़ेशन

TensorRT-LLM, कस्टम कर्नेल, विशिष्ट रनटाइम, क्वांटाइज़ेशन प्रयोग, स्पेक्युलेटिव डिकोडिंग, मल्टी-GPU समानांतरता, फ़ाइन-ट्यूनिंग, डिस्टिलेशन और प्रोडक्शन मूल्यांकन का उपयोग करें।

लक्ष्य: इन्फ़रेंस दक्षता के लिए इंजीनियरिंग समय का व्यापार करें, लागत कम करें और बड़े पैमाने पर उच्च गुणवत्ता प्राप्त करें।

गोपनीयता स्वचालित नहीं है

लोकल LLM गोपनीयता में सुधार करते हैं क्योंकि प्रॉम्प्ट और आउटपुट आपके हार्डवेयर पर रह सकते हैं। लेकिन लोकल का स्वचालित रूप से सुरक्षित होना ज़रूरी नहीं है।

खतरों में दुर्भावनापूर्ण मॉडल फ़ाइलें, पिकल-आधारित वेट लोडिंग, अविश्वसनीय trust_remote_code, पुनर्प्राप्त दस्तावेज़ों में प्रॉम्प्ट इंजेक्शन, टूल-कॉल दुरुपयोग, लॉग के माध्यम से गुप्त रिसाव, डेस्कटॉप ऐप से टेलीमेट्री, ब्राउज़र एक्सटेंशन या प्लगइन, उच्च-दांव सेटिंग्स में मॉडल भ्रम, लाइसेंस उल्लंघन और फ़ाइन-ट्यूनिंग के दौरान डेटा संदूषण शामिल हैं।

एक कार्यशील लोकल AI सुरक्षा आधार रेखा में चार आदतें हैं:

सावधानी से लोड करें: प्रतिष्ठित स्रोतों से safetensors या GGUF पसंद करें, अविश्वसनीय .bin फ़ाइलों से बचें और casually trust_remote_code सक्षम न करें।
सीमाओं के साथ चलाएँ: एजेंटों के लिए एक अनप्रिविलेज्ड यूज़र, कंटेनर या सैंडबॉक्स का उपयोग करें और जब ऑफ़लाइन गोपनीयता मायने रखती हो तो नेटवर्क एक्सेस अक्षम करें।
गुप्त जानकारी सुरक्षित रखें: क्रेडेंशियल को प्रॉम्प्ट और RAG इंडेक्स से बाहर रखें, डेस्कटॉप ऐप टेलीमेट्री सेटिंग्स की समीक्षा करें और निष्पादन से पहले टूल कॉल को मान्य करें।
जो मायने रखता है उसे संस्करणित करें: मॉडल, प्रॉम्प्ट, अडैप्टर, रनटाइम और क्वांटाइज़ेशन संस्करणों को ट्रैक करें, और गोपनीयता आपदा पैदा किए बिना डीबगिंग के लिए पर्याप्त लॉग करें।

लोकल AI सुरक्षा अधिकतर उबाऊ परिचालन अनुशासन है। इस तरह आप एक यादृच्छिक चेकपॉइंट डाउनलोड करने, इसे रूट के रूप में चलाने और लोकल AI को लोकल समझौते में बदलने से बचते हैं।

बेंचमार्क जो मायने रखते हैं

उस स्टैक का बेंचमार्क करें जिसे आप वास्तव में चलाएँगे। एक मॉडल का BF16 लीडरबोर्ड स्कोर आपकी Q4 लोकल वास्तविकता नहीं है।

गुणवत्ता, लेटेंसी, मेमोरी, विश्वसनीयता और संचालन फ़िट मापें:

गुणवत्ता: आपके वास्तविक कार्यों पर शुद्धता, केवल सामान्य बेंचमार्क नहीं।
लेटेंसी: पहले टोकन का समय, डिकोड टोकन प्रति सेकंड और एंड-टू-एंड समय।
मेमोरी: वेट मेमोरी, KV-कैश वृद्धि, पीक VRAM और लोड के तहत हेडरूम।
फ़ॉर्मेटिंग: चैट टेम्पलेट शुद्धता, JSON/स्कीमा सफलता, टूल-कॉल विश्वसनीयता और स्टॉप-टोकन व्यवहार।
रिट्रीवल: साइटेशन निष्ठा, उत्तर ग्राउंडिंग, लापता-साक्ष्य व्यवहार और रीरैंकर प्रभाव।
संचालन: स्टार्टअप समय, वार्मअप व्यवहार, क्रैश रिकवरी, लॉगिंग, गोपनीयता और संस्करण ट्रैकिंग।

30 से 100 प्रतिनिधि प्रॉम्प्ट के साथ एक छोटा मूल्यांकन सेट बनाएँ। अपेक्षित उत्तर या स्कोरिंग मानदंड, लेटेंसी और मेमोरी माप, विफलता श्रेणियां, RAG-विशिष्ट ग्राउंडिंग जाँच, यदि प्रासंगिक हो तो JSON अनुपालन जाँच और अस्पष्ट कार्यों के लिए मानव समीक्षा शामिल करें।

फिर मॉडलों की तुलना करें। किसी लीडरबोर्ड को आपके लिए आपका लोकल स्टैक चुनने न दें।

लोकल मॉडल के साथ कोडिंग

कोडिंग सबसे अच्छे लोकल LLM उपयोग मामलों में से एक है क्योंकि प्रॉम्प्ट में अक्सर निजी कोड शामिल होता है, लेटेंसी मायने रखती है, पुनरावृत्ति लगातार होती है, API लागत तेज़ी से बढ़ सकती है और लोकल मॉडल एडिटर, शेल, grep, टेस्ट रनर और पैच वर्कफ़्लो के साथ एकीकृत हो सकते हैं।

सबसे मजबूत लोकल कोडिंग सेटअप एक नग्न चैटबॉट नहीं है। यह एक कोड-सक्षम इंस्ट्रक्ट मॉडल है जो लक्षित रिपॉजिटरी कॉन्टेक्स्ट, कोडबेस पर रिट्रीवल, फ़ाइल पथ, प्रासंगिक स्निपेट, टेस्ट निष्पादन और एक पैच लूप से जुड़ा है।

डिकोडिंग को नियतात्मक या कम तापमान पर रखें। अस्पष्ट सलाह के बजाय पैच माँगें। स्वचालित रूप से परीक्षण चलाएँ। वास्तविक बग और कार्यों का एक छोटा मूल्यांकन सेट रखें ताकि आप बता सकें कि कोई नया मॉडल वास्तव में बेहतर है या नहीं।

किसी लोकल मॉडल को बिना समीक्षा के बड़े कोडबेस को फिर से न लिखने दें। लोकल किसी कोडिंग एजेंट को बुद्धिमान नहीं बनाता है। यह केवल कॉन्टेक्स्ट को निजी, लूप को सस्ता और एकीकरण को नियंत्रित करने में आसान बनाता है।

लोकल एजेंटों को गार्डरेल की आवश्यकता है

एक लोकल LLM अधिक उपयोगी हो जाता है जब यह टूल का उपयोग कर सकता है: फ़ाइल खोज, शेल कमांड, ब्राउज़र ऑटोमेशन, डेटाबेस, कोड निष्पादन, कैलेंडर, टिकट सिस्टम, आंतरिक API, वेक्टर डेटाबेस, होम ऑटोमेशन, रोबोटिक्स या एज डिवाइस।

टूल उपयोग सुरक्षा मॉडल को बदल देता है। एक चैटबॉट जो भ्रम पैदा करता है, कष्टप्रद है। फ़ाइलसिस्टम एक्सेस वाला एजेंट चीज़ें हटा सकता है। ब्राउज़र एक्सेस वाला एजेंट गुप्त जानकारी लीक कर सकता है। शेल एक्सेस वाला एजेंट आपके लॉग पढ़ने से तेज़ी से मशीन को नुकसान पहुँचा सकता है।

लोकल एजेंट सुरक्षा में चार परतें हैं। एजेंट को केवल वही निर्देशिकाएँ, API, नेटवर्क एक्सेस और क्रेडेंशियल देकर कसकर स्कोप करें जिनकी उसे वास्तव में आवश्यकता है। सैंडबॉक्स, कंटेनर, कम-से-कम विशेषाधिकार वाले उपयोगकर्ता, विनाशकारी कार्यों के लिए पुष्टिकरण और स्कीमा-मान्य टूल तर्कों के साथ निष्पादन को बाधित करें। इनपुट को शत्रुतापूर्ण मानें क्योंकि पुनर्प्राप्त दस्तावेज़, वेब पेज, टिकट और ईमेल में प्रॉम्प्ट इंजेक्शन हो सकता है। लॉग में गुप्त जानकारी डाले बिना टूल कॉल, मॉडल संस्करण, प्रॉम्प्ट और अनुमोदन लॉग करके एक ऑडिट ट्रेल रखें।

संरचित आउटपुट मदद करते हैं, लेकिन वे सुरक्षा सीमा नहीं हैं। JSON स्कीमा, बाधित डिकोडिंग और फ़ंक्शन हस्ताक्षर टूल कॉल को मान्य करना आसान बनाते हैं। वे यह साबित नहीं करते कि मॉडल ने अनुरोध समझा, सुरक्षित कार्रवाई चुनी या इंजेक्ट किए गए निर्देशों से बचा।

गंभीर टूल उपयोग के लिए, नीति जाँच मॉडल के बाहर रखें।

RAG विशाल प्रॉम्प्ट को मात देता है

RAG का मतलब रिट्रीवल-ऑगमेंटेड जनरेशन है। सभी जानकारी को प्रॉम्प्ट में भरने के बजाय, आप नॉलेज बेस से प्रासंगिक खंड पुनर्प्राप्त करते हैं और मॉडल को केवल वे खंड देते हैं।

एक अच्छी लोकल RAG प्रणाली में आमतौर पर दस्तावेज़ अंतर्ग्रहण, पार्सिंग, चंकिंग, एम्बेडिंग, एक वेक्टर इंडेक्स, रिट्रीवल, रीरैंकिंग, प्रॉम्प्ट निर्माण, उत्तर पीढ़ी, ग्राउंडिंग जाँच और मूल्यांकन शामिल होता है। प्रत्येक चरण एक विफलता बिंदु है।

खराब पार्सिंग तालिकाओं को कचरे में बदल देती है। खराब चंकिंग उत्तर को सीमाओं में विभाजित कर देती है। खराब रिट्रीवल अप्रासंगिक पैराग्राफ लौटाता है। खराब रीरैंकिंग सही उत्तर को रैंक 20 पर दबा देता है। एक अच्छा मॉडल उस साक्ष्य से विश्वसनीय रूप से उत्तर नहीं दे सकता जो उसे कभी प्राप्त नहीं हुआ।

अधिकांश खराब RAG सिस्टम LLM के कारण खराब नहीं हैं। वे चंकिंग, रिट्रीवल, रीरैंकिंग और मूल्यांकन के कारण खराब हैं।

चंकिंग रणनीति साइलेंट किलर है। बिना ओवरलैप के फिक्स्ड-साइज़ चंक वाक्यों को विभाजित कर सकते हैं और संदर्भ खो सकते हैं। सिमेंटिक चंकिंग या पैरेंट-डॉक्यूमेंट रिट्रीवल के साथ पदानुक्रमित चंकिंग अक्सर बेहतर काम करती है, लेकिन कोई सार्वभौमिक उत्तर नहीं है। आपको अपने वास्तविक दस्तावेज़ों पर चंक आकार, ओवरलैप और विभाजन नियमों का मूल्यांकन करना होगा।

एक अच्छा रीरैंकर औसत रिट्रीवल को बचा सकता है। कोई भी रीरैंकर उन चंक को ठीक नहीं कर सकता जिन्होंने अंतर्ग्रहण के दौरान उत्तर खो दिया।

दस्तावेज़ और ज्ञान कार्य

निजी दस्तावेज़ों के लिए, लोकल LLM चमकते हैं: मीटिंग ट्रांसक्रिप्ट सारांश, अनुबंध समीक्षा, तकनीकी दस्तावेज़ीकरण Q&A, शोध नोट संश्लेषण, ईमेल ड्राफ्टिंग, नीति खोज, आंतरिक सहायता सहायक और अनुपालन वर्कफ़्लो सभी स्रोत सामग्री को मशीन या संगठन के करीब रखने से लाभान्वित होते हैं जो इसका मालिक है।

वर्कफ़्लो सरल लेकिन निर्दयी है। दस्तावेज़ों को सावधानीपूर्वक पार्स करें, पृष्ठ और अनुभाग मेटाडेटा संरक्षित करें, सिमेंटिक रूप से चंक करें, एम्बेडिंग और रीरैंकर का उपयोग करें, उद्धरण माँगें, सामान्य रीज़निंग से उत्तर को स्रोतों से अलग करें और उद्धरण निष्ठा का मूल्यांकन करें।

यह न मानें कि मॉडल जानता है कि आपके दस्तावेज़ों में क्या है। यह केवल वही जानता है जो आप प्रॉम्प्ट में डालते हैं या कॉन्टेक्स्ट में पुनर्प्राप्त करते हैं।

मीटिंग ट्रांसक्रिप्ट के लिए, स्पीकर लेबल और टाइमस्टैम्प संरक्षित करें। अनुबंध समीक्षा के लिए, मनमाने टोकन गणना के बजाय खंड या अनुभाग द्वारा चंक करें। तकनीकी दस्तावेज़ीकरण Q&A के लिए, पुनर्प्राप्त खंडों में पृष्ठ संख्या या अनुभाग एंकर शामिल करें ताकि मॉडल सटीक रूप से स्रोतों का हवाला दे सके।

दस्तावेज़ कार्य के लिए, आपका पार्सर और रिट्रीवर उतना ही मायने रखता है जितना मॉडल।

एज डिप्लॉयमेंट

छोटे मॉडल तेजी से फोन, लैपटॉप, रोबोट, IoT गेटवे, फैक्ट्री डिवाइस, वाहन, चिकित्सा उपकरण, ऑफ़लाइन फील्ड उपकरण और ब्राउज़र ऐप पर उपयोगी हो रहे हैं। एज केवल वर्कस्टेशन का एक छोटा संस्करण नहीं है। इसकी अलग बाधाएँ हैं।

एज डिप्लॉयमेंट पर कम मेमोरी, कम पावर, थर्मल सीमाएँ, रुक-रुक कर कनेक्टिविटी, गोपनीयता की आवश्यकताएँ, रियल-टाइम लेटेंसी, छोटे कॉन्टेक्स्ट विंडो और अनुमानित फ़ॉलबैक व्यवहार हावी होते हैं। उन डिवाइसों पर, एक छोटा विश्वसनीय मॉडल एक बड़े कमज़ोर मॉडल को हरा देता है।

एक व्यावहारिक एज सेटअप में अक्सर 0.5B से 4B मॉडल, आक्रामक वेट क्वांटाइज़ेशन, छोटे प्रॉम्प्ट, निश्चित स्कीमा, टूल-असिस्टेड वर्कफ़्लो, स्थानीय एम्बेडिंग, कैशिंग और कोई अनावश्यक चैट हिस्ट्री का उपयोग किया जाता है।

जब कनेक्टिविटी गिर जाती है, तो एक स्थानीय मॉडल जो काम करता रहता है, उस बड़े मॉडल से अधिक मूल्यवान होता है जो विफल हो जाता है। स्थानीय AI का भविष्य केवल विशाल वर्कस्टेशन मॉडल नहीं है। यह छोटे मॉडल भी हैं जो डेटा के पास उपयोगी काम करते हैं।

एक स्थानीय LLM रनबुक

इसे किसी स्थानीय मॉडल को वास्तविक कार्य के लिए भरोसेमंद बनाने से पहले अंतिम गेट के रूप में उपयोग करें।

चुनें और फ़िट करें: कार्य के लिए उपयुक्त मॉडल परिवार चुनें, लाइसेंस पढ़ें, हार्डवेयर आवश्यकताओं की पुष्टि करें, क्वांटाइज़ेशन स्तर चुनें और पूर्ण मेमोरी बिल का अनुमान लगाएँ। केवल वेट साइज़ पर न रुकें। KV कैश, रनटाइम ओवरहेड, बैच/कंकरेंसी और सुरक्षा मार्जिन शामिल करें।

लोड करें और फ़ॉर्मेट करें: प्रतिष्ठित स्रोतों से safetensors या GGUF को प्राथमिकता दें, अविश्वसनीय pickle-आधारित फ़ाइलों से बचें, टोकनाइज़र और चैट टेम्पलेट सत्यापित करें, कॉन्टेक्स्ट लंबाई जानबूझकर सेट करें और कार्य के लिए डिकोडिंग पैरामीटर चुनें। यदि टेम्पलेट गलत है, तो मूल्यांकन अमान्य है।

मूल्यांकन करें और संचालित करें: प्रतिनिधि प्रॉम्प्ट के साथ परीक्षण करें, पहले टोकन तक का समय और डिकोड स्पीड मापें, पीक मेमोरी ट्रैक करें, RAG जोड़ने से पहले रिट्रीवल का मूल्यांकन करें, एजेंट जोड़ने से पहले टूल्स को सैंडबॉक्स करें और सरल तरीके विफल होने के बाद ही फ़ाइन-ट्यूनिंग करें।

हर उस चीज़ का वर्शन करें जो मायने रखती है: मॉडल, क्वांटाइज़ेशन, रनटाइम, प्रॉम्प्ट, चैट टेम्पलेट, एडेप्टर, एम्बेडिंग मॉडल, रीरैंकर, मूल्यांकन सेट और हार्डवेयर प्रोफ़ाइल। स्थानीय सिस्टम को नियंत्रित करना तभी आसान होता है जब आप वह पुन: उत्पन्न कर सकते हैं जो आपने चलाया।

फ़ाइन-ट्यूनिंग

फ़ाइन-ट्यूनिंग अतिरिक्त डेटा पर प्रशिक्षण देकर मॉडल व्यवहार को बदलती है। स्थानीय उपयोगकर्ताओं के लिए, सबसे महत्वपूर्ण विधियाँ LoRA और QLoRA हैं।

LoRA बेस मॉडल को फ़्रीज़ करता है और छोटे लो-रैंक एडेप्टर वेट को प्रशिक्षित करता है। इससे प्रशिक्षित पैरामीटर कम हो जाते हैं और आप कई हल्के एडेप्टर बनाए रख सकते हैं। QLoRA इसे एक फ़्रोज़न 4-बिट क्वांटाइज़्ड मॉडल के माध्यम से LoRA एडेप्टर में फ़ाइन-ट्यून करके विस्तारित करता है।

फ़ाइन-ट्यूनिंग तब करें जब आपको एक सुसंगत लेखन शैली, डोमेन-विशिष्ट आउटपुट फ़ॉर्मेट, बार-बार वर्गीकरण या निष्कर्षण व्यवहार, टूल-कॉल फ़ॉर्मेट विश्वसनीयता, एक विशेष सहायक व्यक्तित्व, RAG द्वारा हल नहीं किए जा सकने वाले डोमेन अनुकूलन या एक संकीर्ण कार्य पर बेहतर छोटे मॉडल प्रदर्शन की आवश्यकता हो।

पहले फ़ाइन-ट्यून न करें। इस क्रम को आज़माएँ: सही चैट टेम्पलेट, बेहतर प्रॉम्प्टिंग, बेहतर मॉडल, बेहतर डिकोडिंग, RAG, रीरैंकिंग, कुछ-शॉट उदाहरण, फिर फ़ाइन-ट्यूनिंग।

अधिकांश समस्याएँ जो ऐसी दिखती हैं कि मॉडल मेरे डोमेन को नहीं समझता, वास्तव में मेरा प्रॉम्प्ट अस्पष्ट है, मेरा टेम्पलेट गलत है, या मेरी रिट्रीवल खराब है।

एक अच्छी फ़ाइन-ट्यूनिंग योजना में साफ़ डेटा, प्रशिक्षण/सत्यापन/परीक्षण विभाजन, बेसलाइन मूल्यांकन, स्पष्ट लक्ष्य व्यवहार, सुरक्षा समीक्षा, ओवरफ़िटिंग जाँच, प्रतिगमन मूल्यांकन, एडेप्टर वर्शनिंग, लाइसेंस समीक्षा और एक रोलबैक योजना शामिल है।

ओपन-वेट का मतलब ओपनसोर्स नहीं है

2026 में, "ओपन मॉडल" वाक्यांश का अक्सर गलत उपयोग किया जाता है। आपको ओपन-वेट, सोर्स-अवेलेबल, ओपनसोर्स और लोकल-कम्पैटिबल के बीच अंतर करना चाहिए।

ओपन-वेट का आमतौर पर मतलब है कि आप वेट डाउनलोड कर सकते हैं। इसका स्वचालित रूप से यह मतलब नहीं है कि आप मॉडल का व्यावसायिक उपयोग कर सकते हैं, इसे स्वतंत्र रूप से संशोधित कर सकते हैं, इसके आउटपुट पर प्रशिक्षण ले सकते हैं, इसे किसी भी पैमाने पर तैनात कर सकते हैं या एट्रिब्यूशन आवश्यकताओं को अनदेखा कर सकते हैं।

सोर्स-अवेलेबल का मतलब है कि कोड या वेट दिखाई देते हैं। इसका ज़रूरी नहीं कि लाइसेंस ओपनसोर्स हो।

ओपनसोर्स AI मॉडल एक मजबूत दावा है। OSI की ओपनसोर्स AI परिभाषा एक AI सिस्टम को आर्किटेक्चर, पैरामीटर/वेट, इन्फ़रेंस कोड और पैरामीटर प्राप्त करने में उपयोग की जाने वाली पर्याप्त डेटा जानकारी और कोड सहित मानती है। यह "वेट हगिंग फेस पर हैं" से कहीं अधिक ऊँचा बार है।

कुछ लाइसेंस अनुमेय दिखते हैं लेकिन इनमें प्रतिबंध होते हैं: कोई प्रतिस्पर्धी उपयोग नहीं, आउटपुट पर प्रशिक्षण नहीं, एक निश्चित पैमाने से ऊपर तैनाती नहीं, भौगोलिक बहिष्करण, एट्रिब्यूशन आवश्यकताएँ, पेटेंट खंड, या डेरिवेटिव पर कॉपीलेफ्ट-जैसे दायित्व।

नियम: किसी भी मॉडल का व्यावसायिक उपयोग करने से पहले मॉडल कार्ड और लाइसेंस पढ़ें। एक मॉडल उत्कृष्ट, डाउनलोड करने योग्य और स्थानीय रूप से चलाने योग्य हो सकता है, लेकिन फिर भी आपकी कानूनी या तैनाती बाधाओं के लिए अनुपयुक्त हो सकता है।

शब्दावली

मॉडल और ट्यूनिंग शब्द

Active Parameters: MoE मॉडल में, किसी दिए गए टोकन के लिए केवल कुछ पैरामीटर उपयोग होते हैं। एक मॉडल में सैकड़ों अरब कुल पैरामीटर हो सकते हैं लेकिन प्रति टोकन कहीं कम सक्रिय पैरामीटर।
Adapter: एक छोटा प्रशिक्षित मॉड्यूल जो बेस मॉडल में जोड़ा जाता है, अक्सर LoRA के माध्यम से।
Base Model: एक प्रशिक्षित मॉडल जो विशेष रूप से चैट या निर्देशों का पालन करने के लिए ट्यून नहीं किया गया है।
Fine-Tuning: अतिरिक्त प्रशिक्षण जो लक्ष्य डोमेन या आउटपुट शैली के लिए मॉडल व्यवहार बदलता है।
Instruct Model: निर्देशों का पालन करने के लिए ट्यून किया गया मॉडल।
LoRA / QLoRA: लो-रैंक एडेप्टर का उपयोग करके कुशल फ़ाइन-ट्यूनिंग विधियाँ, QLoRA क्वांटाइज़्ड बेस मॉडल के माध्यम से प्रशिक्षण।
MoE: मिक्सचर ऑफ़ एक्सपर्ट्स। एक विरल आर्किटेक्चर जहाँ केवल चयनित विशेषज्ञ सबनेटवर्क प्रति टोकन सक्रिय होते हैं।
Weights / Parameters: मॉडल के अंदर सीखे गए संख्यात्मक मान।

इन्फ़रेंस मैकेनिक्स

BOS / EOS: अनुक्रम-आरंभ और अनुक्रम-अंत टोकन।
Chat Template: सिस्टम, उपयोगकर्ता, सहायक और टूल संदेशों को प्रस्तुत करने के लिए उपयोग किया जाने वाला फ़ॉर्मेटिंग।
Context Window: अधिकतम टोकन जिन्हें मॉडल एक बार में संसाधित कर सकता है।
Decode: वह चरण जहाँ मॉडल एक-एक करके नए टोकन उत्पन्न करता है।
DFlash: 2026 की एक अनुमानित डिकोडिंग दृष्टिकोण जो समानांतर ड्राफ्टिंग के लिए ब्लॉक डिफ्यूज़न का उपयोग करती है।
DDTree / DTree: एक अनुमानित डिकोडिंग विधि जो ब्लॉक डिफ्यूज़न वितरण से एक ड्राफ्ट ट्री बनाती है और इसे कुशलतापूर्वक सत्यापित करती है।
GQA / MQA: अटेंशन वेरिएंट जो KV-कैश आकार कम करते हैं और इन्फ़रेंस दक्षता में सुधार करते हैं।
Inference: आउटपुट उत्पन्न करने के लिए मॉडल चलाना।
KV Cache: पिछले टोकन के लिए संग्रहीत की-वैल्यू अटेंशन अवस्थाएँ।
Prefill: वह चरण जहाँ मॉडल उत्पन्न करने से पहले इनपुट प्रॉम्प्ट को संसाधित करता है।
RoPE: रोटरी पोज़ीशन एम्बेडिंग, आधुनिक LLM में सामान्य एक पोज़ीशनल एन्कोडिंग विधि।
Speculative Decoding: एक गति तकनीक जहाँ एक सस्ता ड्राफ्टर टोकन प्रस्तावित करता है और लक्ष्य मॉडल उन्हें सत्यापित करता है।
Tokenizer: वह घटक जो टेक्स्ट को टोकन आईडी में और वापस परिवर्तित करता है।
Top-p / Top-k / Temperature: टोकन उत्पादन के लिए सैंपलिंग नियंत्रण।

रिट्रीवल, फ़ाइलें और सर्विंग

AWQ: एक्टिवेशन-अवेयर वेट क्वांटाइज़ेशन।
Embedding Model: एक मॉडल जो खोज/रिट्रीवल के लिए टेक्स्ट को वेक्टर में परिवर्तित करता है।
FP8 KV Cache: कुछ रनटाइम में समर्थित एक व्यावहारिक 8-बिट KV-कैश कम्प्रेशन मोड।
GGUF: एक मॉडल फ़ाइल फ़ॉर्मेट जो llama.cpp द्वारा भारी उपयोग किया जाता है।
PagedAttention: vLLM-शैली सर्विंग द्वारा उपयोग की जाने वाली KV-कैश मेमोरी प्रबंधन तकनीक।
Quantization: मेमोरी बचाने और दक्षता में सुधार के लिए संख्यात्मक सटीकता कम करना।
RAG: रिट्रीवल-ऑगमेंटेड जनरेशन। प्रासंगिक बाहरी कॉन्टेक्स्ट प्राप्त करें और मॉडल को दें।
Reranker: एक मॉडल जो प्रासंगिकता के अनुसार प्राप्त मार्ग को पुनर्क्रमित करता है।
Safetensors: एक सुरक्षित टेंसर सीरियलाइज़ेशन फ़ॉर्मेट जो pickle-आधारित निष्पादन जोखिमों से बचाता है।

अंतिम शब्द

स्थानीय LLM इकोसिस्टम में कॉम्पैक्ट एज मॉडल, मजबूत 7B से 32B उपभोक्ता मॉडल, बड़े MoE ओपन-वेट सिस्टम, मल्टीमॉडल मॉडल, लंबे-कॉन्टेक्स्ट मॉडल, स्थानीय रीज़निंग मॉडल, परिपक्व इन्फ़रेंस रनटाइम और तेजी से सक्षम निजी सर्विंग स्टैक शामिल हैं।

लेकिन बुनियादी बातें नहीं बदली हैं: मॉडल एक बार में एक टोकन की भविष्यवाणी करता है, टोकन शब्द नहीं हैं, वेट पूरे मॉडल नहीं हैं, चैट टेम्पलेट मायने रखते हैं, KV कैश छिपा हुआ मेमोरी बिल है, क्वांटाइज़ेशन एक समझौता है, लंबा कॉन्टेक्स्ट मुफ़्त नहीं है, RAG गुणवत्ता रिट्रीवल पर निर्भर करती है, फ़ाइन-ट्यूनिंग को मूल्यांकन की आवश्यकता होती है, और स्थानीय गोपनीयता के लिए अभी भी सुरक्षा अनुशासन की आवश्यकता है।

स्थानीय मॉडलों को अच्छी तरह से चलाने के लिए आपको पौराणिक कथाओं की आवश्यकता नहीं है। आपको यह जानना होगा कि मेमोरी में क्या फ़िट बैठता है, मॉडल किस टेम्पलेट की अपेक्षा करता है, रनटाइम कैसे व्यवहार करता है, और क्या आपके मूल्यांकन उस काम से मेल खाते हैं जिसकी आपको परवाह है।

स्थानीय LLM अधिकतर मेमोरी गणित और फ़ॉर्मेटिंग और मूल्यांकन हैं। उन्हें सही करें, और बाकी स्टैक के बारे में तर्क करना बहुत आसान हो जाता है।

अगली बार तक।

-अहमद