लोकल मॉडल चलाना अब सच में बेहतर हो गया है
(vickiboykis.com)- 2022 के M2 Mac वातावरण में भी लोकल LLM का प्रदर्शन इतना बेहतर हो गया है कि उसे डेवलपमेंट सवालों, कोड कार्यों और दस्तावेज़ जाँच में व्यावहारिक रूप से इस्तेमाल किया जा सकता है
- शुरुआती लोकल मॉडल धीमे थे, इस्तेमाल में कठिन थे, और प्रोग्रामिंग कार्यों में उनकी सटीकता भी कम थी, लेकिन GPT-OSS के बाद API मॉडल से दोबारा पुष्टि करने की ज़रूरत कम हो गई
- Gemma 4 परिवार की नवीनतम रिलीज़ के साथ लोकल agent coding loop frontier models की तुलना में लगभग 75% सटीकता और गति पर काम कर रहा है
- Pi और LM Studio का संयोजन लोकल inference endpoint, model artifact, और Docker isolation कॉन्फ़िगरेशन के ज़रिए agent workflow चलाता है
- लोकल मॉडल में अभी भी inference latency, छोटा context window, और hardware constraints जैसी सीमाएँ हैं, लेकिन token processing, system prompt, quantization, और harness को सीधे देखा और बदला जा सकता है
लोकल मॉडल की वर्तमान स्थिति
- शुरुआती लोकल मॉडल अधिकांश प्रोग्रामिंग कार्यों में धीमे, उपयोग में कठिन, और सटीक नहीं थे
- यह आकलन कि लोकल मॉडल काफी पीछे हैं, व्यक्तिगत उपयोग के मानदंड पर GPT-OSS के आने से पहले तक काफी हद तक सही था
- “काफ़ी अच्छा मॉडल” का व्यक्तिगत मानदंड यह था कि क्या उसे API मॉडल से फिर जाँचना पड़ता है, और GPT-OSS पहला मॉडल था जिसने इस पुनर्पुष्टि की आवृत्ति को काफी कम किया
- हाल तक लोकल मॉडल मुख्यतः उन डेवलपमेंट सवालों के लिए एक तेज़ और व्यक्तिगत Google की तरह इस्तेमाल होते थे जिनमें ताज़ा जानकारी ज़रूरी नहीं होती थी
- Gemma 4 परिवार की नवीनतम रिलीज़ के बाद लोकल में agent coding loop frontier models की तुलना में लगभग 75% सटीकता और गति से चलने लगा है {p:75}
इस्तेमाल किए गए मॉडल और रनटाइम वातावरण
- 2022 के M2 Mac, 64GB RAM, और 1TB स्टोरेज वाले वातावरण में कई लोकल मॉडल चलाए गए
- इस्तेमाल किए गए मॉडल थे Mistral 7B, Gemma 3, OpenAI OSS-20B, Qwen 3 MOE, Qwen 2.5 Coder आदि
- रन कॉन्फ़िगरेशन raw llama.cpp, Open WebUI, llama-cpp-python, Ollama, llamafiles, और LM Studio से होकर गुज़रा
- डिफ़ॉल्ट लोकल मॉडल के रूप में LM Studio की
gemma-4-26b-a4bimplementation का उपयोग किया गया
वास्तविक लोकल agent कार्यों के उदाहरण
- एक notebook-आधारित Python script को 5–6 modules वाले repository में refactor किया गया
- उन modules को PEP 585 मानक के अनुसार generic type hints इस्तेमाल करने के लिए lint किया गया
- ब्लॉग पोस्ट प्रूफ़रीडिंग, unit test लिखने, और recommendation के लिए two-tower model repository की शुरुआती संरचना बनाने में भी लोकल सेटअप इस्तेमाल किया गया
- खाली स्थिति से agent द्वारा बनाई गई two-tower model repository बुनियादी थी, लेकिन यह पिछले साल संभव मानी जाने वाली सीमा से आगे थी
- सभी agent workflows सीमित execution access वाले Docker container के अंदर चलाए गए
संसाधन उपयोग और नवीनतम छोटे मॉडल
- किए गए कार्य क्रांतिकारी कम और व्यक्तिगत Google या दस्तावेज़ lookup के अधिक क़रीब थे
- कार्यों के दौरान GPU और RAM उपयोग बढ़ा, और K-V cache 64GB RAM तक पहुँच गया
- साधारण कार्य भी इस तरह के लोकल मॉडल सेटअप पर सिर्फ़ 6 महीने पहले तक संभव नहीं थे
Gemma-4-12b-qatरिलीज़ होते ही अपने आकार के मुकाबले प्रभावशाली प्रदर्शन दिखाता था- मॉडल आर्किटेक्चर यह सवाल खड़ा करता है कि प्रदर्शन और लागत सीमाओं के बीच किस तरह के आर्किटेक्चरल समझौते ज़रूरी होते हैं
लोकल agent मॉडल रन कॉन्फ़िगरेशन
- लोकल agent flow चलाने के लिए लोकल model inference engine, agent harness, और लोकल model artifacts की ज़रूरत होती है
- harness को लोकल inference endpoint की ओर सेट करना होता है, और डाउनलोड किए गए model artifacts को inference engine के माध्यम से serve करना होता है
- वर्तमान लोकल सेटअप में Pi को agent harness और LM Studio को inference server के रूप में इस्तेमाल किया गया है
- Pi और LM Studio के साथ Gemma 4 agent coding सेट करने वाली पोस्ट का अनुसरण किया गया, लेकिन कुछ सेटिंग्स बदली गईं
- पोस्ट के
Gemma 26B A4Bकी जगह अधिक नया, छोटा, और तेज़gemma-4-12b-qatमॉडल इस्तेमाल किया गया, और सटीकता में बड़ा नुकसान नहीं हुआ - सुरक्षा के लिए सभी Pi sessions को Docker container में चलाया गया और केवल bash permissions दी गईं, ताकि Python code execution और web browsing रोकी जा सके
- research कार्यों के लिए अलग image में curl अनुमति देने की योजना है
- Docker के भीतर चलने के कारण Pi के
models.jsonको संशोधित किया गया ताकि Pi मॉडल के साथ संचार कर सके
- पोस्ट के
Docker-आधारित isolation तरीका
- Pi कॉन्फ़िगरेशन में
baseUrlकोhttp://host.docker.internal:1234/v1और API कोopenai-completionsपर सेट किया गया - Docker Compose कॉन्फ़िगरेशन
models.json, working directory, Pi settings, और session directory को container में mount करता है - रन स्क्रिप्ट वर्तमान working directory को container workspace से जोड़ती है, और ज़रूरत पड़ने पर अधिक सुरक्षित sandbox Compose file भी जोड़ी जा सकती है
- Pi जिस repository पर काम कर रहा होता है, उसी से Docker चलाता है, इसलिए वह physical disk की files या directories को सीधे delete नहीं कर सकता
- custom model
jsonकॉन्फ़िगरेशन को container के भीतर भेजा जा सकता है, इसलिए यह experimental environment में काफ़ी अच्छा चला
बची हुई सीमाएँ
- लोकल मॉडल में अभी भी inference धीमा हो सकता है, context window छोटा होता है, और उपलब्ध context आपके hardware से सीमित होता है
- ecosystem अब LM Studio और Hugging Face के Use This Model button जैसे टूल्स की वजह से कहीं अधिक आसान हो गया है
- शुरुआती रिलीज़ में prompt template mismatch जैसी समस्याएँ आती हैं, लेकिन ऐसे मुद्दे आमतौर पर बहुत जल्दी patch हो जाते हैं
- यह कहना अभी भी मुश्किल है कि यह सीधे production software development में इस्तेमाल के लिए पूरी तरह तैयार है
लोकल मॉडल के फायदे और प्रयोग की संभावनाएँ
- लोकल मॉडल में लगभग हर चीज़ को अंदर तक देखा जा सकता है, और token inference प्रक्रिया को real time में देखा जा सकता है
- input और output token flow को सीधे जाँचा जा सकता है
- लोकल context window बदलते हुए प्रदर्शन के बेहतर या बदतर होने की प्रक्रिया देखी जा सकती है
- यह भी समझा जा सकता है कि tokens GPU पर कैसे process होते हैं, और system prompt व quantization settings को भी बदला जा सकता है
- मॉडलों को एक-दूसरे के खिलाफ़ चलाया जा सकता है, harness-side settings बदली जा सकती हैं, और उनके असर को देखा जा सकता है, इसलिए प्रयोग की संभावनाएँ लगातार बढ़ रही हैं
1 टिप्पणियां
Hacker News की राय
पता नहीं यह कितना अच्छा है। मैं लोकल मॉडल बहुत इस्तेमाल करता हूँ, लेकिन लोकल रन अभी भी काफ़ी तकलीफ़देह है
Qwen 27B, Gemma 31B जैसे dense models काफ़ी स्मार्ट हैं लेकिन धीमे हैं, और Gemma 26B, Qwen 35B, North Mini Code 30B जैसे mixture-of-experts (MoE) models तेज़ हैं लेकिन ग़लतियाँ ज़्यादा करते हैं
इन्हें ठीक से चलाने के लिए बहुत memory चाहिए, और quantization करने पर tool calling कमज़ोर हो जाती है। ज़्यादातर लोग इन्हें 4-bit quantization पर चलाकर सोचते हैं कि ये इतने खराब क्यों हैं, लेकिन असल में यह मॉडल की मानो lobotomy करने जैसा है। मैं Unsloth quantization की सिफारिश करता हूँ, और MoE के लिए 6-bit, dense models के लिए 5-bit सुझाता हूँ
prefill तेज़ करने के लिए compute performance चाहिए, decode तेज़ करने के लिए bandwidth चाहिए, और पूरे मॉडल को समाने के लिए बहुत memory भी चाहिए। ऊपर से laptop गरम और शोर करने वाली मशीन बन जाता है, जिससे उस पर काम करना असुविधाजनक हो जाता है
तो क्या यह अच्छा है? बहुत नहीं। काम तो करता है
जोड़कर कहूँ तो मुझे लगता है कि open models ही भविष्य हैं और मैं ecosystem में लगातार योगदान भी दे रहा हूँ। अच्छा होगा अगर लोग ऐसे models को छूकर देखें और
piका इस्तेमाल करके समझें कि ये कैसे काम करते हैं, लेकिन सिर्फ़ मॉडल डाउनलोड कर लेने से ही सब बढ़िया हो जाएगा, ऐसी उम्मीद नहीं करनी चाहिए। ज़्यादातर लोगों के मन के “coding agent” की जगह लेने लायक बनाने के लिए इसमें काफ़ी tuning और setup चाहिएजो models coding-specialized नहीं थे, वे अक्सर असली tool calling करने के बजाय सिर्फ़ इतना कहते थे कि “मैं ऐसा करूँगा”, और जब मैंने पूछा कि उस व्यवहार को बदलने के लिए क्या सेट करना होगा, तो भी कोई मदद नहीं मिली। Qwen यह मानने को ही तैयार नहीं था कि वह ollama में चल रहा है; वह ज़िद करता रहा कि वह Alibaba cloud पर चल रहा है और उसके पास local system access नहीं है
coding models भी बस मेरी typing speed से थोड़ा ही तेज़ सोच पा रहे थे, और कई मामलों में वे अपना thought process दिखा भी नहीं सकते थे
अब तक मुझे सबसे अच्छा “free” अनुभव OpenCode + Big Pickle के साथ मिला है। यह बहुत ज़्यादा स्मार्ट नहीं है, इसलिए पहला result अक्सर ग़लत होता है, लेकिन इसका free tier इतना उदार है कि लगभग एक महीने तक रोज़ कई घंटे इस्तेमाल करने पर भी मैं सिर्फ़ दो बार ही limit से टकराया। अगर असली लक्ष्य सचमुच local run है, तो यह सही विकल्प नहीं है, लेकिन अगर लक्ष्य “subscription या token cost के बिना सबसे अच्छा अनुभव” है, तो अब तक यही सबसे कम बुरा विकल्प लगा है
unified memory वाले Mac, AI Max AMD processors, या DGX Spark जैसी मशीनों पर यह करने की कोशिश करना काफ़ी हद तक खुद मुसीबत मोल लेने जैसा है। prefill performance को बिगाड़ देता है
सही GPU लगा दें तो हालत बहुत बेहतर होती है, लेकिन फिर भी यह Sonnet या DeepSeek 4 Flash के स्तर तक नहीं पहुँचता, और Opus / DeepSeek Pro या Mythos/Fable/GPT-5.5 से तो और भी दूर है
अगर budget, power और cooling पर्याप्त हों, तो काफ़ी अच्छा data pipeline चलाया जा सकता है, लेकिन code के लिए ज़्यादातर मामलों में अभी भी API provider को पैसे देना ज़्यादा तर्कसंगत है
फिर भी centralized services पर बहुत ज़्यादा निर्भर न रहने के लिए इसे आज़माने की क़ीमत है
मेरे अनुभव में यह rule-following या automation-style tasks में Qwen models, यहाँ तक कि 100B+ models से भी बेहतर है। image interpretation भी बहुत अच्छा है और benchmark में यह Opus से ऊपर आता है
Qwen निर्देशों को नज़रअंदाज़ करने की प्रवृत्ति रखता है, और अगर token generation format को साफ़ तौर पर सीमित न किया जाए तो यह लगातार गलत format आउटपुट करता है
लेकिन DGX Spark पर Gemma 31B Q4 + MTP लगभग 20 tokens/sec, और Gemma 26B A4B लगभग 60 tokens/sec देता है, इसलिए यह अभी भी काफ़ी धीमा है। उन्नत Nvidia cards पर यह काफ़ी तेज़ चलेगा और memory में भी आ जाएगा
जो लोग local models से शुरुआत कर रहे हैं, उन्हें मैं RAM से ज़्यादा memory bandwidth पर ध्यान देने की सलाह दूँगा। अब 100B से छोटे models भी automation के लिए काफ़ी हैं और बहुत उपयोगी हैं
coding/creative use cases में local models इस्तेमाल करने का अभी भी कोई बहुत मज़बूत कारण नहीं है, इस बात से मैं सहमत हूँ। लेकिन stock lists देखना, news high-pass filtering करना, logs की व्याख्या करना, या screenshots की व्याख्या जैसे कामों के लिए local models अब काफ़ी हैं
M6 Mac Studio में 256GB RAM लगाकर कुछ लोगों को किसी एक agreed model तक पहुँच देना शायद उचित ठहराया जा सकता है। इस काम के लिए laptop बहुत गरम और सुस्त लगता है
कुछ हफ़्तों तक Qwen3.6-27B को संतोषजनक रूप से इस्तेमाल करने के बाद अब हार्डवेयर से दूर होने की वजह से मुझे फिलहाल Claude Sonnet 4.6 इस्तेमाल करना पड़ रहा है, और यह बहुत बड़ा downgrade लगता है
समझ नहीं आता यह कैसे संभव है। इसमें बिना मांगे बहुत ज़्यादा प्रबल राय होती है, यह बहुत ज़्यादा बोलता है, और कुल मिलाकर ज़्यादा बेवकूफ़ महसूस होता है
बेशक यह कहीं बड़ा मॉडल है, इसलिए इसमें ज़्यादा knowledge encoded होगी, लेकिन अगर उससे बातचीत करना ही नापसंद हो तो उससे मदद नहीं मिलती। ऊपर से उससे बात करने में असली पैसे भी लगते हैं
सोचता हूँ मुझे यह इतना नापसंद क्यों है। शायद इसलिए कि यह खुद को tool की जगह लगभग बराबरी के अस्तित्व की तरह देखता है। जैसे इसकी अपनी राय का कुछ वज़न हो
Qwen भी कभी-कभी ज़रूरत से ज़्यादा उत्साही intern की तरह बर्ताव कर सकता है, लेकिन अगर आप उसे कहें कि बेवकूफ़ मत बनो, तो वह अपना ego छोड़ देता है। मेरे अनुभव में Claude ऐसा नहीं था
कुल मिलाकर, शीर्षक से मैं पूरी तरह सहमत हूँ
पिछले डेढ़ महीने से मैं इसे M2 Ultra या RTX 5090 मशीन पर लगभग हर दिन इस्तेमाल कर रहा हूँ। मैं इसे ggml-org [0] में छोटे और साधारण कामों के लिए इस्तेमाल कर रहा हूँ, कोई बहुत बड़ी चीज़ नहीं, लेकिन maintainer के लिए यह स्पष्ट रूप से एक उपयोगी tool है
अगर मैं PR review पर इतना समय न खर्च करता, तो शायद इसे और भी ज़्यादा इस्तेमाल करता। अभी मैं बहुत हल्का harness इस्तेमाल करता हूँ, जिसमें सब कुछ हटाया हुआ pi agent(
pi -nc --offline) और मेरी शैली के मुताबिक़ ढालने के लिए एक छोटा system prompt [1] हैgeneration speed RTX 5090 पर लगभग 100~150 tokens/second और Mac पर लगभग 40 tokens/second है। यह काफ़ी तेज़ है, इसलिए मैं साफ़ तौर पर RTX मशीन पर चलाना पसंद करता हूँ, लेकिन local setup testing और व्यापक अनुभव के लिए Mac पर भी अक्सर चलाता हूँ
[0] - https://github.com/search?q=%22Assisted-by%22+user%3Aggml-or...
[1] - https://github.com/ggml-org/llama.cpp/blob/master/.pi/gg/SYS...
Opus की तरह “बड़ा feature X जोड़ दो” वाले कामों में यह शायद कमज़ोर हो, लेकिन मैं मॉडल से वैसे काम चाहता भी नहीं हूँ। मैं सोचना चाहता हूँ और मॉडल टाइप कर दे, बस। उस काम के लिए Qwen 3.6 27B पूरी तरह काफ़ी है। मेरे अनुभव में 35A3B या Gemma family काफ़ी बड़ा downgrade थे
और इसमें speed limit, quota, या peak-time queue की चिंता भी नहीं होती। आप हमेशा पूरी सोच-प्रक्रिया देख सकते हैं, यह चिंता नहीं करनी पड़ती कि data कहाँ भेजा जा रहा है, और performance चुपचाप ख़राब भी नहीं होगी
मैं 2×3090 पर llama.cpp के साथ Q6_K_XL + MTP setup इस्तेमाल करता हूँ, जिसमें prefill 500~1000 tokens/second, output 60 tokens/second, और context window 220k tokens है। 160k tokens के बाद यह थोड़ा बेवकूफ़ होना शुरू हो जाता है, और मैं KV quantization इस्तेमाल नहीं करता
यह शायद thinking feature का side effect हो सकता है, लेकिन मैं चाहूँगा कि यह अपनी thought process का बहुत छोटा summary दे। ऐसे हालात में भी जहाँ एक वाक्य का जवाब काफ़ी हो, state-of-the-art models कम से कम 5 paragraph लिख देते हैं और 3~5 नई directions सुझाने लगते हैं
भले ही आप कहें कि एक बार में सिर्फ़ एक step, एक बार में सिर्फ़ एक विकल्प, और आगे की दिशा proactively मत सुझाओ, फिर भी prompt से इसे ठीक से control करना सच में मुश्किल है
लेकिन अभी-अभी मैंने भी वही कर दिया जिसकी शिकायत कर रहा था
programmers इस बात के आदी हैं कि tools के लिए पैसे न देने पड़ें। एक बुनियादी laptop (SSD, multicore, RAM 16GB) भी C/C++/Rust, यहाँ तक कि Python development के लिए बेहद शक्तिशाली है
लेकिन अचानक वह काफ़ी नहीं रहता, और हम फिर से किसी और के कंप्यूटर का इस्तेमाल करते हुए रोज़ tools किराए पर लेने वाली स्थिति में पहुँच जाते हैं। इससे भी बुरा यह है कि हर दिन अलग मॉडल इस्तेमाल करना पड़ सकता है, और किसी दिन किसी mafia-जैसी ताक़त के निर्माता पर दबाव डालने की वजह से हो सकता है कि आपको अच्छा tool किराए पर भी न मिले
ज़्यादातर दूसरे पेशों में tools पर काफ़ी निवेश करना पड़ता है। अगर आपको अच्छे tools चाहिए, तो GPU memory 64GB (उदाहरण: 2×5090) और लगभग RAM 96GB चाहिए होगी। अगर आप किसी विशेषज्ञ engineer को $200k दे रहे हैं, तो हर 2 साल में tools पर $50k खर्च करना काफ़ी तर्कसंगत लगता है
यह ऐसा रुझान है जिससे Anthropic जैसी कंपनियों को चिंतित होना चाहिए। जैसे-जैसे local model चलाना आसान होगा, वे जो price ceiling वसूल सकती हैं वह लगातार नीचे जाएगी
हर महीने $$$$$ देने वाले लोग पूरी तरह गायब नहीं होंगे, लेकिन बहुत से लोग मासिक शुल्क को 12 या 24 से गुणा करके सोचेंगे, “क्या मैं इससे कम पैसे में local model सेटअप कर सकता हूँ और 1~2 साल में लागत वसूल कर सकता हूँ?”
अगर ग्राहकों का बड़ा हिस्सा किराये के बजाय खरीदना चुनता है, तो rental-केंद्रित business model वाली कंपनियाँ अचानक ग्राहकों की कमी झेल सकती हैं
यह अब लगभग अमेरिकी business model में गहराई से बैठ चुका है। हर चीज outsource कर दो। कोई भी खुद server room संभालना नहीं चाहता, और 2~3 गुना ज़्यादा देकर भी उस सिरदर्द और जिम्मेदारी को साथ में outsource करना चाहता है
AI में भी यही होगा। वह premium चाहे Anthropic को दो या AWS को, बात एक ही है
मैं अपेक्षाकृत छोटी कंपनी में हूँ, और हाल ही में local infrastructure से जुड़ी एक outage हुई थी। पिछले 5 साल में हमारा कुल internal downtime हाल की एक बड़ी AWS outage से भी बहुत कम रहा है, फिर भी CEO अब दबाव डाल रहा है कि self-hosted infrastructure भरोसेमंद नहीं है
हर कोई छोटे-मोटे झंझट और जिम्मेदारी से छुटकारा चाहता है
आम mainstream user शायद उसी चीज़ के लिए पैसे देगा जो पहले से सेट हो और तुरंत इस्तेमाल हो सके। ज़्यादा technical या ज़्यादा दृढ़ लोग खुद करेंगे, लेकिन इन दोनों समूहों का अनुपात क्या होगा, यह जानने की उत्सुकता है
पता नहीं कहीं पहले से ऐसा आइडिया आया है या नहीं कि engineering team के लिए कोई 4GPU machine बेची जाए, जिसे कहीं किसी closet में रखकर मनचाहा model चलाया जा सके
यह सबके लिए आकर्षक नहीं होगा, लेकिन जब hyperscalers लोगों का data खींचकर model training में इस्तेमाल करते हैं, इस भरोसे के संकट के बीच कुछ जगहों को ऐसी machine और model में मूल्य दिख सकता है जिसे पारदर्शी रूप से नियंत्रित किया जा सके और जरूरत पड़े तो जाकर खुद plug खींचा जा सके
सिर्फ Sonnet 4.6 इस्तेमाल करूँ तब भी 20 डॉलर की मासिक योजना पर लगभग पूरा दिन काम किया जा सकता है। और Sonnet अभी भी M2 Mac पर self-host किए जा सकने वाले model से काफी ज्यादा शक्तिशाली है
अगर सब लोग token-usage billing पर चले जाएँ तो शायद मेरी राय बदल जाए, लेकिन subscription के हिसाब से यह आर्थिक रूप से सही नहीं बैठता
मज़ेदार है। लेकिन आर्थिक रूप से उचित नहीं है
OpenAI अगर spot market की सारी RAM खरीद ले, RAM/VRAM की कीमतें 6 गुना बढ़ जाएँ, और GPU व ठीक-ठाक कंप्यूटर ज़्यादातर लोगों की पहुँच से बाहर हो जाएँ
कुछ अमीर लोग 512GB Mac Studio या 13,000 डॉलर में RTX Pro 6000 खरीदकर काफी अच्छा local model चला पाएँगे, लेकिन ज़्यादातर लोगों को API ही इस्तेमाल करनी पड़ेगी
किसी बिंदु पर Nvidia यह भी कह सकती है, “6000 इतना बिक नहीं रहा, data center-only GPU पर 4 गुना मुनाफा है, तो इसे बस रद्द कर देते हैं।” तब वह मिलना ही बंद हो सकता है, और आम लोगों के लिए local पर ऐसे अच्छे model चलाना असंभव हो सकता है जो cutting edge से लगभग 1 साल पीछे हों
अच्छा होगा अगर वे उससे निकला code दिखाएँ। मैं local model इस्तेमाल करना चाहता हूँ और hardware भी है, लेकिन GPT 5.5 xhigh या Opus जैसे state-of-the-art model के विकल्प के रूप में आज़माया तो अभी वह उस जगह लेने के लिए तैयार नहीं लगा
quality और अड़चनों की वजह से workflow बहुत धीमा हो जाता है, और कभी-कभी tool-calling syntax तक बिगाड़ देता है
फिर भी छोटे और अच्छी तरह परिभाषित flow, या “इस हिस्से को ठीक ऐसे बदलो” जैसे edit के लिए यह काफी लगता है। मैं इंतज़ार कर रहा हूँ कि यह इतना mature हो जाए कि आज के state of the art को replace कर सके, और वही turning point होगा
अगर local model की बात है, तो DiffusionGemma और सामान्य रूप से diffusion model को local use में कम करके नहीं आँकना चाहिए। local की आम समस्या यह है कि LLM hardware का कुशल उपयोग नहीं कर पाते जब तक requests को batch में बाँधकर कई साथ न चलाए जाएँ, और उसके लिए पूरा approach बदलना पड़ता है। इसके उलट diffusion model एक single prompt पर काफी तेज़ होते हैं, और यह फर्क छोटा नहीं है
आज ही मैंने diffusiongemma-26B-A4B-it सपोर्ट को Transformers से Candle में port किया, और कुछ optimization जोड़ने के बाद inference के दौरान Candle पर यह लगभग 450 टोकन/सेकंड (लगभग 19 iterations/second) तक उड़ रहा है। HF Transformers library में यह लगभग 180 टोकन/सेकंड (लगभग 11 iterations/second) था। ऐसा नहीं लगता कि इसी आकार के LLM को vLLM में चलाकर single prompt पर मैंने कभी 250 टोकन/सेकंड से ऊपर देखा हो, इसलिए local model के लिहाज से यह दिलचस्प है
2600 डॉलर में आप AMD 9700 GPU के दो कार्ड खरीद सकते हैं, जिनमें प्रति कार्ड 32GB RAM है और बिजली खपत लगभग 285W है। लागत और बिजली दोनों 5090 से कम हैं
AITER patch लगे VLLM build के साथ Qwen3.6 27B FP8 को Opencode या PI के वास्तविक coding session में full context window के साथ लगभग 45~50TPS पर चलाया जा सकता है
मैं सच में चाहता हूँ कि 30B-क्लास dense model और आते रहें, लेकिन सिर्फ Qwen3.6 से भी काफी agent work संभाला जा सकता है
हालांकि ROCm stack उन लोगों के लिए नहीं है जो खुद गहराई में जाकर patch करने को तैयार नहीं हैं
मुझे हैरानी होती है कि हर व्यक्ति के लिए “अच्छी” agent coding की कसौटी इतनी अलग क्यों है
एक तरफ यह सचमुच चौंकाने वाली बात है कि हम “Apple Music में ‘Set a Timer’ चलाओ” स्तर की बुद्धिमत्ता से लेकर Turing test पास कर सकने वाले स्तर तक पहुँच गए हैं, लेकिन व्यावहारिक नज़रिए से देखें तो छोटे models को tech demo से आगे बढ़कर “अच्छा” कहना अभी बहुत जल्दबाज़ी होगी
मेरे लिए 7B model बस Wikipedia की धुंधली गूंज जैसा है। 4-bit Gemma model tool-calling के लिए JSON को भरोसेमंद तरीके से generate करने या patch लागू करने के लिए code की एक पंक्ति कॉपी करने में भी बहुत कमजोर है
Qwen को विनाशकारी loop में फँसने या context खोने से बचाने के लिए इतनी ज़्यादा बारीक हिदायतें और देखभाल चाहिए होती है कि कई बार मुझे जो निर्देश देने पड़ते हैं, वे आखिर में बनने वाले code से भी लंबे हो जाते हैं
क्या कोई जादुई prompt है जो मुझे नहीं पता? या फिर दूसरे लोग मुझसे कहीं ज़्यादा धैर्यवान हैं, या उनकी अपेक्षाएँ बहुत कम हैं?
छोटे scripts, glue code, और साधारण CRUD बदलावों में Qwen3.6-27B जैसा छोटा model, बड़े और बेतरतीब codebase की तुलना में कहीं बेहतर काम कर सकता है
27/35B श्रेणी के Qwen/Gemma को FP8 में चलाने पर वे gemini-2.5 से बेहतर होते हैं, लेकिन gemini-3.1 से कमतर। DS4-flash FP8 को दो DGX Spark पर चलाया जा सकता है, और स्थिति लगातार बेहतर हो रही है। DiffusionGemma ने हाल में token generation speed में 4x दिखाया है
सार यह है कि लगता है आपने जिन models का इस्तेमाल किया, वे या तो बहुत छोटे हैं या उनमें quantization बहुत ज़्यादा है
मुझे local पर दो models चलाना पसंद है: qwen3.6 27B 8-bit (dense) और qwen3.6 35B 4-bit (mixture of experts)
27B ज़्यादा स्मार्ट और भरोसेमंद है, लेकिन धीमा है। 35B तेज़ है और फिर भी काफ़ी स्मार्ट है, लेकिन 27B से नीचे है और थोड़ा कम स्थिर भी। वजह यह है कि mixture of experts (MoE) architecture में सिर्फ़ कुछ parameters सक्रिय होते हैं, इसलिए model काफ़ी तेज़ हो जाता है
27B को मैं MacBook Pro M5 Max + 40 GPU cores + 128GB RAM पर चलाता हूँ। इस दैत्य जैसी मशीन पर 27B और 35B दोनों को एक साथ memory में लोड करके भी दूसरे कामों के लिए जगह बची रहती है। लेकिन क्योंकि यह laptop है, इसलिए local LLM को हमेशा चलाते रहना संभव नहीं है। यह बहुत गर्म और शोर वाला हो जाता है
इससे भी दिलचस्प बात MacMini M4 64GB RAM पर 35B model चलाना है। यह तेज़ है और बहुत काम संभाल लेता है। उदाहरण के लिए, यह emails को scan, extract और classify करता है, और mailbox पर लगातार नज़र रखते हुए काम करता रहता है। मैं इसे अपने निजी Hermes assistant की तरह भी इस्तेमाल करता हूँ, और पूछता हूँ, “अगला Starship launch कब है?”, “आज World Cup में कौन खेल रहा है? थोड़ा trivia भी बताओ”
अगली योजना basement में रखने के लिए एक RTX Pro 6000 Blackwell workstation की है। मैं Qwen को बहुत तेज़ी से, कई threads/prompts/agents के साथ एक साथ चलाना चाहता हूँ। अगर budget ने साथ दिया तो 2×RTX Pro 6000 setup में DeepSeek v4 flash चलाकर research में इस्तेमाल करना चाहूँगा
रोज़मर्रा में मैं Qwen3.6:27b host करता हूँ, लेकिन deepseekv4 flash को सच में host करना चाहता हूँ। size/speed/price के हिसाब से यह बहुत “अच्छा” model है
मुझे हैरानी है कि कंपनियाँ हर developer के लिए subscription देने के बजाय, रोज़मर्रा के कामों के लिए models को on-premises host करना कब शुरू करेंगी। यह काफ़ी अच्छा है और अपेक्षाकृत सस्ता भी
आपने पूछा नहीं, लेकिन हममें से कोई भी यह नहीं मानता कि code लिखने या लगभग किसी भी काम के लिए सबसे नए, top-tier models का इस्तेमाल करना चाहिए
इसकी जगह हमें खास कामों के लिए open models विकसित करने चाहिए, और हड्डियों वाली उंगलियों और मांस वाले दिमाग़ से coding, writing और drawing करना सीखना चाहिए
बड़ी कंपनियाँ और research facilities शायद code, math वगैरह generate करने के लिए इनका इस्तेमाल कर सकती हैं, बशर्ते output सही है या नहीं यह जाँचने के लिए विशेषज्ञ मौजूद हों, लेकिन तब भी हो सकता है कि लागत के हिसाब से इसकी वैल्यू न बनती हो। उदाहरण के लिए, OpenAI ने पिछले साल 36 अरब डॉलर का शुद्ध घाटा किया, open models पहले ही काफ़ी करीब आ चुके हैं, और पूरे AI प्लान से खींचने लायक धोखाधड़ी अब लगभग खत्म हो चुकी है
बहुत छोटे models से भी बहुत से काम किए जा सकते हैं, और ऐसे भी बहुत से काम हैं जिनके लिए पागलपन वाली compute power और memory की ज़रूरत नहीं होती, लेकिन उस दिशा में ठीक से research करने वाले लोग बहुत कम हैं