Ask HN: क्या किसी ने रोज़मर्रा की coding में Claude/GPT को local models से replace किया है?

 (news.ycombinator.com)
6 पॉइंट द्वारा GN⁺ 9 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • डेटा privacy और LLM के मुफ़्त उपयोग के कारण कुछ developers पूरी तरह cloud models छोड़ रहे हैं, और containerized·sandboxed offline coding harness के साथ बिना external network calls के काम कर रहे हैं
  • मुख्य मॉडल Qwen3.6 35B-A3B है (3b active parameters की वजह से तेज़), साथ में 27B dense model भी; coding accuracy और token generation speed के बीच trade-off मौजूद है
  • Pi harness और llama.cpp का संयोजन सबसे ज़्यादा उल्लेखित है, और local models में tool calling का पहली बार लगातार काम करना user experience को काफ़ी बेहतर बनाता है
  • Claude Opus की तुलना में local models का फ़र्क "guidance चाहने वाले junior बनाम साथ में design करने वाले senior" जैसा बताया गया, इसलिए precise prompts और task decomposition ज़रूरी हैं
  • अभी local models को लगभग 8~18 महीने पुराने frontier स्तर का माना जा रहा है, लेकिन मुफ़्त, privacy, और quota की चिंता न होने जैसे व्यावहारिक फ़ायदे मिलते हैं

local models पर switch करने के उदाहरण और hardware configuration

  • Qwen3.6 35B-A3B को Mac Studio 128GB या MacBook 36GB RAM पर Pi harness के साथ चलाकर Django + Wagtail आधारित website के homepage और blog का पूरा redesign किया गया
    • internet access के बिना कम-ज्ञात Wagtail development में model को हमेशा तरीका नहीं पता होता
    • complex tasks के लिए Qwen3.5 122b इस्तेमाल होता है, लेकिन 10b active parameters के बावजूद काफ़ी धीमा है
  • Strix Halo 128GB unified memory environment में Pi को container के रूप में isolate किया गया, जहाँ credentials के बिना सिर्फ़ working directory access की अनुमति है
    • chat·translation के लिए Gemma 4 31B, audio के लिए Gemma 4 12B इस्तेमाल होता है
    • Qwen 3.5 122B-A10B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, GPT-OSS 120B जैसे कई models मौजूद हैं, लेकिन coding के लिए 35B-A3B सबसे बेहतर माना गया
  • 5 साल पहले बनी dual RTX3090 machine पर Qwen·Gemma models को UD-Q4_K_XL quantization के साथ चलाकर ~150tok/s हासिल किया गया, और पूरा 300k context VRAM में ही process हुआ
    • इससे $100/माह Claude subscription की ज़रूरत ख़त्म हुई, और personal use के लिए मुफ़्त होना प्राथमिकता है
    • Android TV launcher, k8s management portal, Home Assistant integration, grocery·meal management जैसे कई projects किए गए
  • RTX 6000 पर Qwen 3.6 27b + Open Code का उपयोग कर 90% coding work किया गया, लेकिन बहुत complex tasks और UI polishing के लिए फिर Codex पर लौटना पड़ा
    • 256k context में 100k से ऊपर quality·speed गिरती है, और 150k के बाद गिरावट गंभीर हो जाती है
  • RTX 5090 पर Qwen 3.6 27b(Q6 quantization) + llama.cpp, और GPU को 600W→450W तक limit करके शोर कम रखा गया
    • branch commit·PR generation, Stripe CLI invoice settlement, Elasticsearch load analysis जैसे रोज़मर्रा के कामों तक उपयोग बढ़ा

model के प्रकार और performance characteristics

  • MoE vs dense models का अंतर coding quality पर सीधे असर डालता है
    • Qwen3.5-122B वास्तव में 122B-A10B है, जहाँ सिर्फ़ 10B active होते हैं; जबकि Qwen3.6-27B एक dense model है जिसमें पूरे 27B हमेशा active रहते हैं
    • MoE के active·total parameters के geometric mean से dense-equivalent quality का मोटा अनुमान लगाया जा सकता है, sqrt(35×10)≈18.7
    • MoE का quality level समान size की तुलना में कम हो सकता है, लेकिन speed तेज़ होती है, और CPU RAM offload के साथ बड़े MoE भी चल सकते हैं
  • quantization level loop बनने और accuracy पर असर डालता है
    • Q8 quantization धीमा है, लेकिन loops कम करता है और कुल समय बचाता है
    • KV cache के K हिस्से की quantization के प्रति model बहुत sensitive है; F16 K + Q8 V से loops काफ़ी कम हो जाते हैं
  • dual GPU जोड़ने का उद्देश्य inference speed नहीं बल्कि VRAM capacity बढ़ाना है
    • Gemma-4 31B dense और 26B MoE दोनों Q4 quantization पर लगभग समान quality देते हैं, लेकिन MoE ~3 गुना तेज़ है (150tok/s vs 46tok/s)

local models की सीमाएँ और उनसे निपटने की रणनीतियाँ

  • precise prompts की ज़रूरत

    • अगर assumptions खुली छोड़ दी जाएँ, तो model सबसे छोटा रास्ता चुन लेता है, जैसे HTML के अंदर CSS, जो architecture के लिहाज़ से सबसे अच्छा न हो
    • architecture स्पष्ट न होने पर तेज़ लेकिन गंदे edits करता है, और debug statements हटाने को न कहें तो उन्हें छोड़ देता है
    • Claude Opus user intent का अनुमान लगा लेता है, लेकिन छोटे Qwen models केवल वही करते हैं जो निर्देशित किया गया हो; design knowledge को explicitly "activate" करना पड़ता है

  • loops और editing tools की errors

    • edit tool calls अक्सर ग़लत हो जाते हैं, और retry करने के बजाय model thinking tokens खर्च कर file को फिर से पढ़ता है
    • direct retry कई बार edit call को ठीक कर देता है, लेकिन model समस्या को ज़्यादा बुनियादी मानकर बेकार tokens खर्च करता है
    • hash-based editing approach (हर code line के hash reference) से edit errors कम हो सकते हैं, लेकिन context quality ख़त्म होने पर model किसी और तरह से टूट जाता है
    • AGENTS.md rules से rewrite की जगह edits सीमित करने पर आंशिक सुधार मिलता है

  • context window management

    • 65,000 window सिर्फ़ code file structure पढ़ने में ही भर सकती है; 200k से ज़्यादा की ज़रूरत पड़ती है
    • Qwen3.6-35b, 16gb VRAM में 256k context को 128k पर ठीक से संभालता है
    • Qwen3.6-27B 10 लाख token context support करता है, और DGX Spark पर f16 KV cache के साथ लगभग 100GB memory चाहिए

prompt caching और reasoning preservation की समस्या

  • Qwen hybrid models में prompt caching ठीक से काम न करने की समस्या आई, जिससे हर turn पर पूरा context दोबारा process करना पड़ता है
    • ज़्यादातर local models turn-to-turn पूरा reasoning preserve करना नहीं सीखते, इसलिए लंबे tool-calling chains के बाद reasoning हटे हुए state में reprocess करना पड़ता है
    • Qwen 3.6 ने reasoning preservation सीखा है, और chat-template-kwargs = {"preserve_thinking": true} setting से cache reuse बेहतर होता है
  • आधुनिक LLM केवल full attention नहीं बल्कि local attention भी इस्तेमाल करते हैं (sliding window, Mamba-2 state space model)
    • full attention की लागत O(n²) है और समय के साथ overwrite होने वाली reasoning के लिए कमज़ोर है
    • local attention snapshots save करता है और cache recalculation में आख़िरी snapshot से शुरू करता है, हालाँकि snapshot बड़े हों तो storage limits आ सकती हैं
    • Qwen 3.5 और उसके बाद के versions attention और SSM layers को alternating करने वाला Gated DeltaNet इस्तेमाल करते हैं
  • Vulkan कभी-कभी ROCm से उल्टा तेज़ निकलता है, और llama.cpp का latest version बनाए रखना reprocessing problems हल करने में अहम है
  • autoregressive generation tokens के prefill के दौरान अलग parsing होने वाली tokenizer divergence समस्या को हल करना कठिन है

लागत·power economics पर बहस

  • 2x RTX3090 की कीमत लगभग $4400 है, जो $100/माह Claude के हिसाब से 3.6 साल के बराबर है; इसमें बिजली और बाकी parts शामिल नहीं हैं
    • 3.6 साल बाद भी high-capacity GPU की कीमत ऊँची रहने की संभावना है
    • कुछ high-electricity-cost क्षेत्रों में break-even लगभग 1 साल का भी हो सकता है
  • power consumption अपेक्षा से कम बताई गई
    • 1.2kw full load पर लगभग $0.12/घंटा, और solar से जुड़े होने पर इससे भी कम
    • inference load gaming जैसा नहीं होता, इसलिए power concern सीमित है; system idle 200W और inference 350-450W के आसपास रहता है
  • hardware खरीदने का timing
    • अभी खरीदना सबसे अच्छा समय नहीं माना गया, और 24-36 महीनों बाद अगला अच्छा window बताया गया
    • 48gb unified RAM वाला M4 Pro Mac mini ~$2k में budget inference machine के रूप में सुझाया गया, ~150tok/s के साथ अगले 10 साल तक उपयोगी बताया गया
    • AMD R9700 32gb VRAM ~$1200-1400, AI use के लिए 2x 9070 से बेहतर माना गया
  • rent करना यानी cloud subscription लेना भी एक वैध रणनीति है; हर कोई hardware पर भारी रकम नहीं लगा सकता

frontier models की तुलना में मूल्यांकन

  • local models को बार-बार "8~12 महीने पुराने edge model quality" के स्तर का बताया गया
    • benchmarks में Qwen 3.6 35B-A3B, Claude 4 Opus से आगे दिखता है, लेकिन कुछ open source models में benchmark gaming की संभावना बताई गई
    • एक YouTube browser OS test में Qwen 3.6 ने Claude 4 Opus से ज़्यादा working features बनाए
    • लेकिन यह 1 साल पुराने frontier model मानक पर आधारित है, और 3B active MoE की तुलना ताज़ा Opus·Sonnet से नहीं हो सकती, ऐसा भी मज़बूत तर्क दिया गया
  • "Opus-level" की परिभाषा पर असहमति ही बहस का केंद्र है
    • 2024 के Claude 3 Opus से यह नाम इस्तेमाल हो रहा है, और Opus 4.8·4.6 जैसे latest models से अभी भी काफ़ी फ़ासला है
    • पिछले साल नवंबर में Opus 4.5·GPT 5.2 के साथ frontier models में चरणबद्ध छलांग आई, और आम तौर पर "Opus-level" अब 4.5 के बाद वाले स्तर को माना जाता है
    • सबसे बड़े open-weight models के लिए 8x H100 server-level hardware चाहिए; home setups अभी उस स्तर तक नहीं पहुँचे हैं
  • कुछ लोग local models को Haiku 4.5~Sonnet 4.5 के बीच मानते हैं, जहाँ micromanagement के साथ अच्छे नतीजे मिलते हैं
  • frontier और local के बीच gap हमेशा रहने की संभावना है, लेकिन बहुत से users के लिए local अब पहले से ही practical है

harness और workflow strategies

  • Pi harness सबसे ज़्यादा recommended है; इसे agent development kit जैसा माना गया और इसे "Claude के vscode के लिए neovim" से तुलना की गई
    • यह default tools (file access·edit·bash) देता है, और MCP adapters·web search extensions भी जोड़ी जा सकती हैं
    • /tree command से failed tool call से पहले वाले context पर लौटा जा सकता है, और /new से context reset किया जा सकता है
  • hierarchical·role-based workflow से सीमाओं की भरपाई की जाती है
    • frontier model से spec·design·execution plan बनवाकर, implementation local model से कराया जाता है
    • agents को roles के हिसाब से जोड़ा जाता है (project manager·schema agent·coding agent), और orchestrator व Playwright सिर्फ़ errors को अगले चरण तक भेजते हैं
    • tasks को atomic TODOs में तोड़कर और reference files साफ़ बताकर context बचाया जाता है
  • OpenCode कभी-कभी हर turn पर system prompt बदल देता है, जिससे KV cache compatibility टूट सकती है, और local LLM support settings manual·complex लगती हैं
  • Ollama पर cloud models जोड़ने और monetization के कारण आलोचना हुई, इसलिए llama.cpp·llama-swap की सिफ़ारिश की गई; macOS पर llm-mlx 10-15% तेज़ बताया गया

specific setup shares के उदाहरण

  • AMD 7900xtx 24gb + 5950x + 64gb DDR4 environment में Qwen3.6-27B-MTP-UD-Q4_K_XL को llama.cpp Vulkan के साथ चलाया गया
    • मुख्य flags: -ngl 99(सभी layers GPU offload), -c 80000(80K context), --cache-type-k q8_0 --cache-type-v q8_0(8-bit KV cache), -fa on(flash attention), --spec-type draft-mtp(MTP draft)
    • sampling: --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0(Qwen coding recommended values)
    • performance: token generation ~65t/s, prompt processing ~600t/s, cold start ~30 seconds
    • Crush harness + Headroom + Exa MCP web search combination के साथ personal Claude Code subscription बंद कर दिया गया
  • V100 32GB पर Qwen3.6-27B-UD-Q4_K_XL + Pi, llama-cpp-turboquant fork और MTP patch के साथ
    • 200,000 context, --spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3 पर 45-60 t/s
  • Strix Halo 128GB पर Qwen3.6-35B-A3B, prompt processing ~800tps और token generation 50tps, idle में power draw लगभग न के बराबर
    • 122B version के न आने का अफ़सोस, और unified memory environment में dense models memory bandwidth limit के कारण धीमे हैं
  • detailed information की कमी पर शिकायत भी उठी, और quantization·parameters·context·GPU·VRAM·harness configuration को स्पष्ट रूप से बताने की माँग की गई

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

2 टिप्पणियां

 
b89kim 1 시간 전

जब मैंने Pi-coding-agent+Qwen3.6-27B-MTP-GGUF इस्तेमाल किया, तो इसकी परफॉर्मेंस लगभग Sonnet 4.5 जैसी थी। साधारण ऐप बनाने के लिए यह काफी था, और ज़रूरत पड़ने पर मैंने कभी-कभी free API (GLM5.1 आदि) भी जोड़कर इस्तेमाल किए। 4090/5090-स्तर के GPU की power consumption ज़्यादा है, लेकिन अगर agent ठीक से बनाया गया हो तो उसे घंटों तक चलाने की ज़रूरत अक्सर नहीं पड़ती।
 
GN⁺ 9 시간 전
Hacker News की राय

  • Greenpants: डेटा प्राइवेसी और मुफ्त LLM अहम हैं, इसलिए Pi coding harness को container·sandbox में रखकर पूरी तरह offline इस्तेमाल करता हूँ
    Mac Studio 128GB या MacBook 36GB पर Qwen3.6 35B चलाता हूँ, और active parameters 3B होने की वजह से यह काफ़ी तेज़ है। Django + Wagtail के साथ वेबसाइट और ब्लॉग को पूरी तरह redesign किया, लेकिन Wagtail कम जाना-पहचाना है, इसलिए इंटरनेट के बिना agent को यह हमेशा अच्छे से पता नहीं होता
    जटिल कामों के लिए Qwen3.5 122B भी इस्तेमाल किया, लेकिन active 10B होने से यह बहुत धीमा है। Claude जैसे बड़े models की तुलना में सवाल बहुत सटीक पूछने पड़ते हैं, और जो assumptions खाली छोड़ दो उन्हें यह अक्सर आसान रास्ते से निपटाता है, जैसे CSS को HTML में डाल देना, यानी architecture के लिहाज़ से कुछ अफ़सोसजनक चुनाव करता है
    edit tool calls भी अक्सर ग़लत करता है और loop में फँस जाता है। Qwen3.6 35B को मैं ऐसे junior की तरह देखता हूँ जिसके पास सामान्य ज्ञान तो है लेकिन उसे लगातार guide करना पड़ता है, जबकि Claude Opus उस senior जैसा है जो architecture पर साथ सोचता है। अगर Opus 15x acceleration देता है, तो पूरी तरह offline Qwen लगभग 5x acceleration देता है, लेकिन मुफ्त होने को देखें तो यह फिर भी चौंकाने वाला है

    • lambda: मैं भी लगभग इसी तरह Pi को container में चलाता हूँ, और दूसरे container की llama.cpp से जोड़कर इस्तेमाल करता हूँ
      network access की अनुमति है, लेकिन credentials ब्लॉक हैं, और सिर्फ working directory तथा ~/.pi तक पहुँच दी गई है। Strix Halo 128GiB unified memory laptop इस्तेमाल करता हूँ, और proprietary tools से programming करना पसंद नहीं है, इसलिए frontier models से गंभीर तुलना नहीं कर पाया
      अभी भी AI skeptic हूँ, इसलिए वास्तविक उपयोग से ज़्यादा समय models को तोड़ने और उनकी ताकत-कमज़ोरियाँ देखने में जाता है, लेकिन agent coding के लिए Qwen 3.6 35B-A3B को सबसे ज़्यादा चुनता हूँ। सामान्य chat·translation के लिए Gemma 4 31B, और audio के लिए Gemma 4 12B अक्सर इस्तेमाल करता हूँ
      Qwen 3.5 122B-A10B, Qwen 3.6 27B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, Minimax M2.7, GPT-OSS 120B भी रखे हैं, लेकिन इस setup में coding के लिए Qwen 3.6 35B-A3B अभी sweet spot के सबसे करीब है
    • geophile: मेरा अनुभव भी लगभग यही है। planning बहुत सावधानी से करनी पड़ती है, उसे छोटे-छोटे independent steps में बाँटना पड़ता है, और design भी इंसान को साफ़-साफ़ लिखकर देना पड़ता है
      अगर details qwen पर छोड़ दो तो यह लिखने से ठीक पहले loop में फँस जाता है। edit न कर पाने की समस्या भी अजीब लगी, इसलिए AGENTS.md में rewrite के बजाय editing को सीमित करने के लिए बदला, और इससे थोड़ा फ़ायदा हुआ
    • adyavanapalli: edit tool के लिए हर code line को hash करके, replacement के समय उसी hash से reference करने वाला hash-based तरीका विचार करने लायक है
      यह approach https://blog.can.ac/2026/02/12/the-harness-problem/ में देखी जा सकती है। ठीक से benchmark नहीं किया, लेकिन अनुभव से edit errors कम लगे, हालांकि environment के हिसाब से फ़र्क हो सकता है

  • horsawlarway: व्यक्तिगत इस्तेमाल के लिए मैंने Claude का $100/महीना subscription बंद कर दिया और unsloth studio की ओर इशारा करने वाले pi harness के साथ Qwen·Gemma models से उसे replace कर दिया
    लगभग 5 साल पहले बनाई गई dual RTX3090 machine पर unsloth/Qwen3.6-35B-A3B-MTP-GGUF और unsloth/gemma-4-26B-A4B-it-GGUF को UD-Q4_K_XL quantization में चलाता हूँ, और दोनों लगभग 150tok/s तथा 300k full context को VRAM के भीतर संभाल लेते हैं
    Claude जितना अच्छा नहीं है, लेकिन मुफ्त है, और निजी उपयोग में यह फ़र्क बहुत बड़ी समस्या नहीं बनता। उसी inference server पर OpenClaw भी जोड़कर इस्तेमाल करता हूँ, और यह local models के लिए काफ़ी अच्छी use case साबित होती है
    उदाहरण के तौर पर Android TV replacement launcher, k8s services के लिए admin portal, Home Assistant integration·automation, grocery shopping·meal planning, ComfyUI 3D asset generation workflows जैसी चीज़ें बनाई हैं। अगर सॉफ़्टवेयर से कमाई करनी हो तो मैं अब भी paid providers की सिफारिश करूँगा, लेकिन local models भी काफ़ी शानदार काम कर सकते हैं

    • rootlocus: दो RTX3090 की कीमत लगभग $4,400 है, यानी बिजली बिल और दूसरे parts को छोड़ भी दें तो Claude के $100/महीना हिसाब से यह 3.6 साल के बराबर है
    • kpw94: अगर gemma को UD-Q4_K_XL पर quantize करके चला रहे हैं, तो unsloth/gemma-4-26B-A4B-it-qat-GGUF जैसे QAT model भी देखना चाहिए
      https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF और https://blog.google/innovation-and-ai/technology/developers-... देखें। 9 जून के update में MTP support भी जोड़ा गया है
    • twothreeone: मैंने भी वही unsloth/Qwen3.6-35B-A3B-MTP-GGUF single 3090, 128k context, Q4_K quantization पर चलाकर देखा, और लगभग 40~60tok/s मिला
      सबसे खटकने वाली चीज़ मध्यम जटिलता वाले असली coding tasks में output quality थी। “prompt से आगे बढ़ाना” और “खुद implement करना” के बीच लगातार स्विच करना पड़ता था, जिससे context switching का मानसिक बोझ काफ़ी बढ़ गया, और हर कुछ मिनट में तय करना पड़ता था कि गलती मेरी instruction में है या model की क्षमता में
      low-level implementation details से high-level design की तरफ़ बढ़ना भी यह ठीक से नहीं कर पाया, और tables जैसी चीज़ें भी आसानी से render नहीं कर सका। Claude में ये समस्या नहीं है, इसलिए अभी इसे replacement कहना मुश्किल है, लेकिन उम्मीद है कुछ महीनों बाद यह संभव हो। aider से Claude CLI को replace किया, हालांकि यह चुनाव भी शायद सबसे बेहतर न हो

  • bluejay2387: अपनी coding का लगभग 90% Qwen 3.6 27B + Open Code, custom skills और Semble से करता हूँ
    यह CC या Codex जितना smart नहीं है, लेकिन ज़्यादातर काम पूरे कर देता है। मेरे पास RTX 6000 है, इसलिए TPS काफ़ी तेज़ है, और मूल रूप से यह GPU किसी और काम के लिए था
    यह बस इस बात का experiment था कि frontier models के कितने करीब पहुँचा जा सकता है, लेकिन यह इतना अच्छा निकला कि इस्तेमाल जारी रखा। सच में complex काम या UI polishing के लिए मैं अब भी Codex पर लौटता हूँ, और Qwen में UI सबसे कमज़ोर लगता है
    मैं इसे recommend नहीं करूँगा। RTX 6000 हर किसी के पास नहीं होता, और इसकी लागत MAX CC या Codex subscription के कई सालों के बराबर है। फिर भी संभावना दिखती है, और कुछ साल बाद यह practical हो सकता है
    256k context में compact target को 75% पर सेट किया था, और जब बातचीत 100k से ऊपर जाती है तो quality और speed गिरने लगती है, 150k के बाद तो बहुत problematic हो जाता है। Qwen 3.5 122B भी आज़माया, लेकिन coding में वह 3.6 27B से काफ़ी खराब था। Gemma 4 31B दूसरे कामों में अच्छा है, लेकिन coding में Qwen आगे है, और हैरानी की बात यह रही कि Nemotron Super 120B भी coding में Qwen से पीछे था

    • heipei: RTX 5090 पर llama.cpp से Qwen 3.6 27B Q6 चला रहा हूँ, और अब सिर्फ pi agent ही इस्तेमाल करता हूँ
      Local होने की वजह से token pricing, quotas, time zones या data sensitivity की बिल्कुल चिंता नहीं करनी पड़ती। GPU power को 600W से 450W तक limit किया, तो inference के दौरान भी यह काफ़ी शांत रहता है
      सिर्फ coding नहीं, रोज़मर्रा के छोटे-मोटे कामों में भी इसे बहुत इस्तेमाल करने लगा हूँ। जैसे branch में commit करना और PR बनाना, Stripe CLI से unpaid/overdue invoices निकालकर बैंक CSV से मिलाना, Elasticsearch credentials से current load का कारण summarize करना, या codebase में X support है या नहीं और implementation कहाँ है, यह ढूँढना
    • bo1024: Qwen3.5-122B असल में Qwen3.5-122B-A10B है
      A10B एक mixture-of-experts model है, इसलिए एक समय में सिर्फ 10B parameters ही activate होते हैं, जबकि Qwen3.6-27B एक dense model है जिसमें सभी 27B parameters हमेशा activate रहते हैं। इसलिए कई tasks में 27B dense model, 122B-A10B से बेहतर हो सकता है
    • user43928: काम पर हमें ज़बरदस्ती Qwen 3.6 27B इस्तेमाल करना पड़ता है, और मुझे यह लगभग बेकार लगता है
      खुद कर लेना बेहतर है, और यह implementation बिगाड़ देता है या debugging पूरी तरह गलत करता है। थोड़ी smarter search functionality को छोड़ दें, तो Sonnet से नीचे कुछ भी मुझे समय की बर्बादी लगता है
      UI polishing के लिए Codex इस्तेमाल करना भी अजीब है। Codex की UI quality खराब होने के लिए मशहूर है और Claude Opus से बहुत पीछे है। Altman ने भी पोस्ट किया था कि अगला model इस हिस्से को improve कर रहा है

  • pierotofy: Llama.cpp + Qwen3.6-35B(MTP) + OpenCode का संयोजन single RTX 3090 पर काफ़ी सक्षम है, और ज़्यादातर cloud models से तेज़ है
    Quality ऐसी लगती है जैसे 8~12 महीने पुराने edge models इस्तेमाल कर रहे हों। Setup को https://github.com/pierotofy/LocalCodingLLM/ में संकलित किया है

    • jacobgold: अगर “8~12 महीने पुराने edge model quality” है, तो hobby use के लिए यह शानदार है, लेकिन professional developer के coding agent के main driver के रूप में इस्तेमाल करने के लिए मुझे लगता है Opus 4.6 के आने से करीब 6 महीने पहले ही threshold पार हो चुकी थी
    • trueno: मेरे पास 128GB M4 Max MacBook Pro है, इसलिए इसे आज़माने का मन है, लेकिन समय निकालना मुश्किल हो रहा है
      ऐसे ही setup इस्तेमाल करने वाले Mac users का अनुभव जानना चाहता हूँ। Local को लेकर बहुत बहस देखी है, लेकिन benchmarks लगातार बदलते रहते हैं और terminology भी अब तक परिचित नहीं है। Local पर जाने से objectively क्या खोते और क्या पाते हैं, इस पर वास्तविक अनुभव जानना चाहता हूँ
    • atomicnumber3: अब Claude इस्तेमाल करने का बिल्कुल मन नहीं होता

  • codinhood: इस सवाल पर शायद बहुत ज़्यादा “असली” जवाब नहीं मिलेंगे। अभी latest/best models का इस्तेमाल न करने की opportunity cost बहुत ज़्यादा है
    हर महीने फिर से देखता हूँ, लेकिन निष्कर्ष वही रहता है। Local models और आसपास के coding tools को Claude Code के Sonnet/Opus के करीब लाने में जो समय, मेहनत और खर्च लगता है, वह अभी worth it नहीं है
    अगर यह worth it होता, तो अब तक इतना disruptive हो चुका होता कि खबर बन जाती। मैं यह नहीं कह रहा कि किसी ने इसे solve नहीं किया होगा, लेकिन यह ज़्यादा Occam’s razor जैसा लगता है ताकि बहुत गहरे rabbit hole में न फँसें

    • pyeri: उस opportunity-cost FOMO train की भी saturation point आएगी, और मेरे हिसाब से शायद आ भी चुकी है
      Mythos-स्तर के models reasoning के frontier पर हैं, लेकिन जिन problem spaces को ज़्यादातर developers solve करना चाहते हैं, उनमें उनकी उपयोगिता बहुत ज़्यादा नहीं है। मौजूदा Sonnet/Opus family के लगभग 4.8 स्तर के models ही शायद आखिरकार वह स्तर होंगे जो कंपनियों में व्यापक रूप से इस्तेमाल होंगे
      Local models अभी वहाँ तक नहीं पहुँचे, लेकिन NVIDIA, OpenRouter, Groq जैसी APIs पर DeepSeek, Kimi, GPT, MiniMax families को सस्ते में इस्तेमाल किया जा सकता है, और ये काफ़ी Sonnet-level हैं
    • mark_l_watson: यही निष्कर्ष सही लगता है। मैं layered system की ओर बढ़ना चाहता हूँ: local, OpenCode + DeepSeek v4 flash जैसी commercial APIs, और DeepSeek v4 Pro
      इससे ज़रूरी काम चलते रहेंगे और धीरे-धीरे ज़्यादा चीज़ें local पर लाई जा सकेंगी। एक ही hardware पर भी local setup 2 महीने पहले की तुलना में बहुत बेहतर हो गया है, और 6 महीने पहले से तुलना करें तो नाटकीय रूप से बेहतर है
    • gunapologist99: Occam से ज़्यादा Pareto के बारे में सोचना चाहिए
      अगर आपको सच में लगता है कि कुछ सालों में हम वहाँ पहुँच जाएंगे, तो अभी से इसे हाथ लगाना बेहतर है, और खासकर छोटे या short-lived projects, या अच्छी तरह modularized बड़े projects में, यह काफ़ी surprising हो सकता है

  • sosodev: यह सवाल क्षमता और अपेक्षाओं की सीमा के लिहाज़ से बहुत व्यापक है। अगर आप सिर्फ 8B model चला रहे हैं और vibe coding या one-shot की उम्मीद कर रहे हैं, तो मुश्किल होगी
    अगर आप लगभग 30B-स्तर का model चला सकते हैं, तो उचित scope और अच्छी तरह परिभाषित tasks में यह काफ़ी अच्छा काम करता है। अभी इस range में Gemma4-31B और Qwen3.6-27B सबसे अच्छे लगते हैं
    अगर तेज़ inference चाहिए तो MoE model पर जा सकते हैं, लेकिन ज़्यादातर tasks में quality साफ़ तौर पर गिरती है। छोटे दायरे के tasks में one-shot·vibe coding भी संभव है, लेकिन फिर भी guidance हो तो कहीं बेहतर रहता है
    अगर frontier-स्तर की क्षमता चाहिए, तो कम-से-कम 128GB memory और बहुत बड़ा compute या बहुत धैर्य चाहिए। ज़्यादातर लोगों के पास या तो पैसे कम होते हैं या patience कम। local model के लिए patience का मतलब सिर्फ token का इंतज़ार करना नहीं, बल्कि अपने workflow और hardware के हिसाब से उसे सेट करना और ठीक से चलाना भी है

    • argee: M4 Pro, 48GB RAM MacBook पर Gemma 4 26B A4B के साथ Rust सीखने और तरह-तरह के सवालों के जवाब लेने का काम करता हूँ
      मुझे नहीं लगता कि यह IDE या harness में बहुत मामूली बदलावों के अलावा one-shot में अच्छा करेगा। फिर भी, अगर इंसान steering wheel पकड़े रहे, सड़क देखता रहे और speed limit से नीचे चलाए, तो छोटे~मध्यम context वाले कामों में copilot के रूप में यह तेज़ और काफ़ी अच्छा है
      कुछ साल पहले के मुकाबले यह चौंकाने वाला है, और अगर यह न होता तो शायद मैं AI से coding लगभग करता ही नहीं। internet connection कट जाने पर बेवकूफ़ या अटका हुआ महसूस होना मुझे पसंद नहीं है
    • user43928: मैंने छोटे models, खासकर GPT 5.4 Mini, से 10~20 lines के code changes को दूसरी file में port करने को कहा, लेकिन उसने दूसरी कोशिश में भी code बदल दिया और bug डाल दिया
      मुझे perfect reliability की उम्मीद नहीं थी, लेकिन लगा था कि differences बता दूँ तो कम-से-कम दूसरी बार सही कर लेगा। असल में उसने बड़े confidence से कहा कि code अब same है, और साथ में एक और subtle bug जोड़ दिया
      मुझे समझ नहीं आता कि ऐसे घटिया models किस काम के लिए काफ़ी हैं। कुछ मिनटों तक वे competent होने का नाटक कर सकते हैं, लेकिन नतीजा आख़िरकार सही नहीं होता। ज़्यादा-से-ज़्यादा, मुझे लगता है कि ये smarter search या autocomplete जैसी चीज़ों के लिए ठीक हैं

  • mgsram: लगभग 1 साल local LLMs इस्तेमाल करने के बाद अब मैं Mac Studio 512GB RAM पर Qwen3.6 27B dense GGUF, OpenCode, llmster(LM Studio) के combination पर टिक गया हूँ
    Qwen 3.6 35B-A3B भी आज़माया, लेकिन dense model की accuracy एक स्तर ऊपर है, हालाँकि इसके बदले token/sec कम मिलते हैं। Qwen3.6 27B आम तौर पर लगभग 25~40tok/s देता है
    शुरुआत में इसे simple tools के लिए इस्तेमाल किया, लेकिन पिछले 3~4 महीनों से C/C++ automotive software stack और Python tools में production-grade coding के लिए सचमुच इस्तेमाल कर रहा हूँ। इसकी कम speed उल्टा मुझे सही रफ़्तार से आगे बढ़ने में मदद करती है
    नए development·rewrite के लिए मैं Sonnet के साथ design·architecture·reasoning·detailed execution plan बनाता हूँ, फिर उसे टुकड़ों में बाँटकर सटीक prompts के रूप में देता हूँ। existing code पर काम करते समय judgment चाहिए होता है, और जब local model की limits महसूस होती हैं तो Claude Code पर लौट जाता हूँ
    हाल में Qwen 3.6 से existing C++ code को reference बनाकर C-आधारित power management service का पूरा rewrite, complex Excel spec parser, और CJK content को English में translate करके KG में डालने वाला tool बनाया है

    • russelg: अगर आपके पास 512GB है, तो deepseek4 चलाना भी देखने लायक है: https://github.com/antirez/ds4

  • 3abiton: सब लोग Qwen का ज़िक्र कर रहे हैं, तो मैं भी Qwen 3.6 35B Q8(MTP) को Strix Halo और llama.cpp के साथ चलाता हूँ
    लगभग 40~50t/s मिलता है और performance सचमुच बहुत अच्छी है। मैंने इसे zsh में forge-code के साथ सीधे इस्तेमाल किया है, और लंबे context 150k+ पर quality गिर जाती है और यह चीज़ें भूलने लगता है

  • wsintra2022: यहाँ comments पढ़कर समझ नहीं आता कि local के ख़िलाफ़ AI providers की तरफ़ से बोलने वाले bots हैं, या वे लोग हैं जिन्हें local AI models के साथ सच में बुरा अनुभव हुआ है
    Mac Studio 64GB पर Qwen 3.6 27B 8k quantization चलाना frontier-स्तर की सर्वशक्तिमान सुपरपावर नहीं है, बस अच्छा है। यह मुफ़्त है, private है, और एक skilled engineer को आलसी से और ज़्यादा आलसी बना देने वाली magic यही है
    मैं llama.cpp और opencode इस्तेमाल करता हूँ, code changes की plan बनवाता हूँ और उन्हें execute करवाता हूँ, फिर hammock पर लेट जाता हूँ, बर्तन धोता हूँ या कोई और काम करता हूँ। tmux और ssh से लॉगिन करके चेक करता हूँ। यही हिस्सा सच में हैरान करने वाला है

    • epolanski: software “engineering” industry में baseline बहुत नीचे है, क्योंकि अक्सर MIT Leetcode ninja लोग React+Tailwind में memory leak वाला बेकार slop लिखते हैं

  • garethsprice: Ada 4000 20GB VRAM पर OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM इस्तेमाल करता हूँ, और generation लगभग 55tok/s आती है
    OpenCode बहुत context जोड़ता है, इसलिए महसूस होने वाली speed numbers से धीमी लगती है। Pi का भी बहुत ज़िक्र हो रहा है, इसलिए शायद जल्द उसे भी देखूँगा
    मैं Opus से plan बनवाता हूँ, local agent से उसे follow करवाता हूँ, फिर Opus से verify करवाता हूँ। यह 100% local नहीं है, लेकिन ये models धीरे-धीरे production workflow का हिस्सा बनते जा रहे हैं
    अभी के लिए, अगर आप hobby के तौर पर time और money लगाकर tinkering पसंद नहीं करते, तो शायद यह करने लायक न लगे। यह Opus या दूसरे frontier models जितना अच्छा नहीं है, लेकिन जहाँ repetitive work बढ़ रहा है, वहाँ “काफ़ी अच्छा” है
    Rolls Royce न होने पर भी इस्तेमाल की हुई Corolla से supermarket तो जाया जा सकता है। frontier LLMs के साथ जो नए workflows cost की वजह से भारी पड़ते, वे भी इससे संभव हो जाते हैं। मैंने इसे रात भर Chrome devtools MCP के साथ user की तरह fuzz testing करने दी, और multimodal से screenshots भी चेक करवाए; Claude+screenshots की लागत सोचकर यह काफ़ी चौंकाने वाला है
    “frontier से 12~18 महीने पीछे” वाली बात सही लगती है। 12~18 महीनों में शायद 5,000 डॉलर से कम में local Opus-स्तर का model चलाया जा सकेगा, लेकिन frontier models तब भी और आगे होंगे

  • arjie: यह न पूरी तरह local है और न ही conversational coding, लेकिन RTX Pro 6000 Blackwell दो कार्ड के साथ DeepSeek V4 Flash चलाता हूँ
    raw speed 160tok/s है, लेकिन यह reasoning model है। मेरा इस्तेमाल code auto-writing और दूसरे systems की auto-review के लिए है। Pi से कभी-कभी code लिखवाता हूँ तो वह बहुत तेज़ है, लेकिन आदत की वजह से ज़्यादातर CC और Codex ही इस्तेमाल करता रहता हूँ

    • akersten: जानना चाहूँगा कि RTX Pro 6000 Blackwell कहाँ से मिला
      जिन sites को मैंने देखा, वे सब sold out थीं, या सिर्फ enterprises को बेच रही थीं, या फिर संदिग्ध लग रही थीं
    • leptons: जानना चाहूँगा कि क्या आपने इस hardware की power consumption नापी है। मुझे इसकी monthly cost की चिंता है

  • stymaar: Qwen3.6-35B-A3B को Strix Halo 128GB Bosgame M5 पर चलाता हूँ
    इस मॉडल के हिसाब से VRAM बहुत ज़्यादा है, लेकिन Qwen ने अभी तक Qwen3.6 का 122B वर्ज़न नहीं निकाला जो मेरे हार्डवेयर पर सबसे बेहतर बैठता। बदले में बिजली का बिल लगभग नज़रअंदाज़ करने लायक है। मूल रूप से यह लैपटॉप चिप है, इसलिए idle पर लगभग कुछ नहीं खाता, और prompt processing के दौरान भी बस 120W से थोड़ा ऊपर जाता है
    Qwen3.6 उम्मीद से ज़्यादा असरदार निकला, इसलिए Claude का इस्तेमाल सिर्फ कभी-कभार, कुल ज़रूरत का लगभग 10% ही करता हूँ। सबसे सस्ते प्लान में भी quota के नीचे रह सकता हूँ। स्पीड prompt processing में लगभग 800tps और token generation में 50tps है, और speculative decoding का इस्तेमाल नहीं करता

    • manmal: क्या आपने 27B dense version भी आज़माया है? कोडिंग के लिए वह कहीं बेहतर है

  • Kostic: निजी इस्तेमाल के लिए VSCode को llama.cpp से जोड़कर Qwen 3.6 27B या Gemma 4 31B चलाता हूँ, और यह cloud subscription छोड़ देने लायक काफ़ी है
    Qwen पहले GPU पर q4@176k context, MTP के साथ लगभग 70~50tok/s देता है, इसलिए कोडिंग के लिए काफ़ी अच्छा है। Gemma दोनों GPU इस्तेमाल करता है और q8@64k context पर document sentiment analysis, summarization, proofreading, और translation को 25tok/s पर संभालता है
    batch workflow के लिए थोड़ा धीमा है, लेकिन काम चल जाता है। अगर llama.cpp tensor split mode में MTP support करे तो इसे और बढ़ाया जा सकता है
    काम पर मैं अभी भी frontier LLMs इस्तेमाल करता हूँ क्योंकि उसका खर्च मैं नहीं देता, और वे जाहिर है बेहतर हैं। उम्मीद है कि लगभग एक साल में Sonnet 4.6/Opus 4.5 स्तर का 30B model आ जाएगा
    prompt processing 800t/s से शुरू होकर 400t/s तक गिरती है। मेरा शुरुआती prompt आम तौर पर 16k~24k tokens का होता है, इसलिए processing में 60~90 सेकंड लगते हैं; बढ़िया तो नहीं, लेकिन स्वीकार्य है

  • jodoherty: RTX Pro 6000 Blackwell पर Gemma 4 31B को Pi के ज़रिए चलाकर अपनी सारी agent coding में इस्तेमाल करता हूँ
    यह मुझे उपयोगी लगता है, और यह side project उस तरीके से मिलता-जुलता है जिससे मैं काम पर projects को scope और execute करता हूँ: https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
    इसमें काफ़ी सावधानी से architecture बनानी पड़ती है और TDD का बहुत इस्तेमाल करना पड़ता है। मुश्किल हिस्सों को शुरुआत में निपटाकर उन्हें simple, easy-to-use interface में wrap कर देता हूँ, ताकि technical risk हट जाए
    कुछ projects में यह खुद लिखने की तुलना में 2~3 गुना तेज़ है, और उबाऊ या बहुत बड़े scope वाले projects में ideas जल्दी इकट्ठे करने और आज़माने देता है, जिससे 5~10 गुना समय बच जाता है
    सेटअप में nvidia/Gemma-4-31B-IT-NVFP4 वाला vLLM और MTP के साथ unsloth/gemma-4-31B-it-qat-GGUF वाला llama.cpp दोनों चलाता हूँ। GPU power को 400W पर limit किया है। अभी llama.cpp config में MTP draft acceptance rate के हिसाब से 60~150t/s मिलता है, और prefill context length/depth के हिसाब से 1500~4000t/s आता है

  • jborak: चार RTX 5070 और 1st-gen AMD Threadripper 1950X के साथ Qwen3.6 27B MTP Q6_K को llama.cpp में चलाता हूँ, और Pi को daily driver की तरह आराम से इस्तेमाल करता हूँ
    स्पीड लगभग 50~60tok/s है। OpenWeb UI जैसे दूसरे apps भी जोड़े हैं, और हाल ही में model access के default entry point के रूप में LLM gateway Bifrost सेट किया है
    Qwen3.6 35B A3B भी आज़माया, लेकिन coding के लिए 27B ज़्यादा फिट बैठता है। dense model होने की वजह से यह धीमा है, लेकिन quality काफ़ी बेहतर लगती है। 35B A3B non-MTP पर 130~140tok/s देता है, यानी पागलों जैसी तेज़ स्पीड
    Qwen3.6 27B चलाने के लिए चार 5070 ज़रूरी नहीं हैं; तीन, शायद दो से भी काम चल सकता है। लेकिन अगर 27B को तेज़ करने के लिए MTP इस्तेमाल करते हैं, तो draft model को अपना context चाहिए होता है, इसलिए memory ज़्यादा लगती है
    यह भी याद रखना चाहिए कि tool का system prompt हर conversation में model पर load होता है। Pi शुरू में बहुत responsive रहता है, लेकिन Hermes CLI से interact करने पर हर prompt skills, tools वगैरह का बहुत सारा context साथ लाता है और conversation के अंत तक बना रहता है, इसलिए काफ़ी धीमा हो जाता है
    privacy अच्छी है ही, लेकिन quota न होना और usage की चिंता न करनी पड़े, यह भी बढ़िया है। अगर भविष्य “loop engineering” का है, तो cloud models में tokens और पैसा दोनों जलेंगे। मेरा सिस्टम idle पर 200W लेता है, और भारी inference load पर 350~450W तक जाता है; decoding बहुत efficient नहीं है, इसलिए GPU उम्मीद से ज़्यादा बार खाली भी रहते हैं। diffusion जैसी प्रगति decoding को तेज़ कर सकती है और idle GPU utilization बढ़ा सकती है

    • zakisaad: जानना चाहता हूँ कि 4-GPU setup में आपने 5070 ही क्यों चुना
      पहली नज़र में यह compute performance की तरफ़ झुका हुआ और VRAM में कमज़ोर लगता है, इसलिए gamers के लिए अच्छा लेकिन LLM चलाने के लिए उतना अच्छा नहीं लगता। मेरे desktop में भी 5070 है

  • cuttysnark: local models के साथ कई agents को workflow में जोड़कर कुछ हद तक सफलता मिली है
    हर agent अपनी भूमिका के हिसाब से अलग prompt और अलग ollama model इस्तेमाल करता है। project manager या schema agent (qwen3:14b) coding agent (qwen2.5-coder:7b) जैसा model इस्तेमाल नहीं करते
    हर step के बीच orchestrator और Playwright task होते हैं, और कोशिश रहती है कि जिस agent ने पिछला code block बनाया था उसे errors दिखा दिए जाएँ। सिर्फ error-free blocks ही अगले step में जाते हैं
    सबसे बड़ा सुधार यह रहा कि backend-for-agents service definition जोड़ दी, ताकि schema agent सिर्फ task-based manifest बनाए और उसे अगले agent को दे दे। संक्षेप में, workflow को define करके agents को बहुत specific कामों में बाँट देते हैं और फिर अगले step को handoff करते हैं। इससे वे track नहीं खोते, और 25% या 90% सफल flow में इंसान के दखल का एक बिंदु भी बन जाता है

    • pianopatrick: अगर ऐसे workflow benchmarks और competitions हों तो पता चल सकता है कि क्या अच्छा काम करता है
      जैसे, “इस consumer GPU तक सीमित रहो, अपनी पसंद का model और workflow इस्तेमाल करो, और देखो कि xyz benchmark को कितना अच्छे से हल कर पाते हो।” प्रतिभागियों को अधिकतम 1 घंटा दिया जाए, और answered ratio, accuracy, तथा total time के आधार पर score किया जाए — “The Local AI challenge” जैसा कुछ अच्छा रहेगा
    • sowbug: क्या आपने agents को आपस में प्रतिस्पर्धा कराने की कोशिश की है?
      उदाहरण के लिए, एक ही coding task दो models को या एक ही model के अलग-अलग seeds को दिया जाए, और reviewer बेहतर नतीजा चुने। एक विचार यह भी है कि मानव मस्तिष्क हज़ारों mini cortical columns की तरह काम करता है जो स्थिति को थोड़ा-थोड़ा अलग देखते हैं और फिर बहुमत से वोट करते हैं

  • HappySweeney: मेरे पास Optane और बहुत सारा RAM है, इसलिए मैंने रात भर functions लिखने के लिए लगभग पूरे मॉडल के बराबर एक मॉडल को 0.7t/s की रफ़्तार पर चलाकर देखा।
    अभी मैं Scala function को AVX512 इस्तेमाल करने वाले bit matrix transpose function में बदलने की टेस्टिंग कर रहा हूँ। cloud models इसे आसानी से कर लेते हैं, लेकिन Kimi 2.6 और GLM 5.1 बुरी तरह फेल हो जाते हैं

  • etoxin: अभी तक इसे replace नहीं कर पाया हूँ। काम के project में openspec इस्तेमाल करता हूँ, और local hardware खरीदने पर बहुत पैसा खर्च किए बिना उसकी नकल करने के लिए नए लोकप्रिय local models के hosted version का paid इस्तेमाल करता हूँ।
    ज़्यादातर छोटे local models tool calling ठीक से नहीं कर पाते, लेकिन बड़े models अब यह काफ़ी ठीक से करने लगे हैं। local side पर एक बात जिस पर अभी ध्यान नहीं गया है, वह यह है कि productive engineers आम तौर पर git worktree के साथ कई CLI chats एक साथ चलाते हैं। मैं आम तौर पर 3 worktree और CLI chats चलाता हूँ

  • blurbleblurble: मुझे लगता है कि अभी सीमा model की खुद की नहीं, बल्कि alternative harnesses की usability की है, जिनमें queue management, interruption, subagents, goals जैसी चीज़ें अजीब तरह से गायब हैं

    • coder543: पूरी तरह सहमत। यह भी परेशान करता है कि OpenCode local LLMs को ठीक से support करने की कोशिश नहीं करता।
      OpenCode को चलाना संभव है, लेकिन configuration बहुत manual और भद्दा है। मैंने llama-server config को OpenCode config में अपने-आप बदलने वाली एक script बनाई है, जो मदद करती है, लेकिन यह ideal नहीं है।
      मैंने खाली समय में एक और coding harness बनाने के बारे में गंभीरता से सोचा है। इसे बेहतर बनाने के लिए मेरे पास कुछ ideas हैं
    • horsawlarway: Pi ठीक-ठाक है
      मैंने Claude, Cursor, Pi के CLI agents, खुद बनाए custom harnesses, यहाँ तक कि gastown भी इस्तेमाल किया है, और Pi बस काफ़ी है। यह ज़रूरी काम कर देता है, इसके default tools ठीक हैं, दूसरे tools के साथ अच्छी तरह integrate होता है, और दिमाग़ कम खाता है।
      अगर आप लगभग 30B के model को अच्छी speed पर चला सकते हैं, तो Pi के साथ बहुत लोग काफ़ी हैरान होंगे। https://pi.dev/packages/pi-mcp-adapter?name=mcp और https://pi.dev/packages/pi-web-access?name=search जैसे extensions जोड़ दें, तो आपको web tools, perplexity search, Chrome control के लिए https://browsermcp.io/, और Firefox के लिए https://github.com/mozilla/firefox-devtools-mcp जैसे MCP access भी मिल जाता है।
      यह subsidy वाले top-tier models जितना अच्छा नहीं है, लेकिन free है और फिर भी काफ़ी capable है। व्यक्तिगत रूप से मैं https://pi.dev/docs/latest/sdk का भी बहुत मज़े से इस्तेमाल कर रहा हूँ, जबकि दूसरे providers इस तरह की API access के लिए हर महीने हज़ारों डॉलर लेते हैं
    • Insanity: मैंने pi.dev के बारे में अच्छी बातें सुनी हैं, लेकिन अभी तक खुद इस्तेमाल नहीं किया है। यह शायद उन missing features में से कुछ को हल कर सके जिनका आपने ज़िक्र किया

  • _bobm: जब आप Claude/GPT models कहते हैं, तो यह सोचना चाहिए कि वह “model” असल में है क्या।
    बस यह याद कीजिए कि GPT कैसे अपनी thinking को एक-एक करके भेज सकता है, और thinking block के लिए Markdown header summary भी जोड़ सकता है। API endpoints और output behavior को देखकर लगता है कि तथाकथित SOTA models वैसे नहीं हैं जैसे वे दिखते हैं, और infrastructure के लिहाज़ से उनकी local models से बिल्कुल तुलना नहीं की जा सकती।
    इस scale के operation में भारी orchestration शामिल है, और उसकी सीमाएँ ऐसी innovation तक ले जाती हैं जिनकी खुलकर चर्चा नहीं होती। मुझे नहीं लगता कि इसे पकड़ पाना नामुमकिन है, लेकिन llama या vLLM से local model serve करना अभी बस alphabet के A, B, C स्तर पर है।
    मेरे हिसाब से असली ज़रूरत ऊपर इशारे किए गए orchestration की नकल करने की है। SOTA “model” एक single model नहीं, बल्कि कई models का गहरा orchestration है जो साथ काम करते हैं। इसलिए single model तब तक बराबरी नहीं कर पाएगा जब तक training और architecture में इस orchestration को दोहराया न जाए।
    आम उपभोक्ताओं को दिए जाने वाले इस orchestration stack का कोई एक model अपने-आप में Qwen 3.6 से बहुत बेहतर नहीं होगा। नज़रिए को बदलें तो “magic” का असली scale दिखने लगता है

    • XCSme: समझ नहीं आता कि आपको क्यों लगता है कि SOTA models कई models के deep orchestration से बने हैं।
      मैं GPT के thinking part को Markdown header summary के साथ भेजने वाला आपका example भी ठोस रूप में देखना चाहूँगा

  • cheekygeeky: हमारे software developer, जिनसे मैं मिला हूँ उनमें सबसे स्मार्ट लोगों में से एक हैं, OpenCode और Tmux को open source models के साथ इस्तेमाल करते हैं।
    coding के लिए वे DeepSeek को सबसे ज़्यादा पसंद करते हैं और उसे “काफ़ी अच्छा” कहते हैं। इसे i9, 128GB RAM, और दो 3090 पर चलाते हैं। https://www.msn.com/en-us/news/technology/china-s-open-deeps...

  • pianopatrick: अगर ऐसे workflow के लिए benchmarks और competitions हों, तो पता चल सके कि क्या अच्छी तरह काम करता है।
    जैसे, “सिर्फ इस consumer GPU का इस्तेमाल करके, अपनी पसंद के model और workflow के साथ xyz benchmark को कितनी अच्छी तरह solve किया जा सकता है।” मैं “The Local AI challenge” जैसी competition देखना चाहूँगा, जहाँ participants को अधिकतम 1 घंटा मिले, और scoring answer ratio, accuracy, और completion time के आधार पर हो

  • bravetraveler: मैं लगभग “natural food” तरीके से काम करता हूँ, और LLM का जितना भी कम इस्तेमाल करता हूँ, वह सब local है।
    128GB Strix system पर कम dense Qwen या Gemma variants 50~80tok/s output देते हैं। Anthropic/OpenAI वगैरह subscribe करने का मेरा कोई इरादा नहीं है, और अगर यही आख़िरी local model भी हो, तब भी इसकी ज़रूरत नहीं पड़ेगी। model के भीतर tool use currentness की चिंता को cover कर देता है

  • GodelNumbering: जो व्यक्ति पूरे दिन LLMs से बात करता है, उसके नज़रिए से open source frontier models + अच्छा harness का combination पहले से ही काफ़ी है।
    local deployment पर पूरी तरह switch करने के लिए hardware की एक-दो और पीढ़ियाँ चाहिए होंगी। लेकिन hardware companies datacenter segment को इतनी मज़बूती से प्राथमिकता दे रही हैं कि वह समय जल्दी आए, यह ज़रूरी नहीं

  • milchek: 36GB MacBook Pro पर कोशिश की, लेकिन बहुत बेसिक कामों से आगे कोई बड़ी सफलता नहीं मिली
    छोटे मॉडल इस्तेमाल करने पर भी context जल्दी खत्म हो जाता था और धीमापन समस्या था। कुछ हद तक ठीक performance के लिए 128GB memory चाहिए लगती है, और hardware cost काफी बढ़ जाती है
    आखिर में सवाल यही है कि frontier model subscription लिया जाए या वही पैसा hardware पर लगाया जाए। बेशक, अगर privacy महत्वपूर्ण है तो high-end hardware पर पैसा खर्च करने के अलावा लगभग कोई विकल्प नहीं है

  • acc_297: सोच रहा हूँ कि क्या medium-size model पर हर prompt के साथ नियमित रूप से RLHF लागू करके उसे व्यक्तिगत usage habits के हिसाब से fine-tune करना मददगार होगा
    पता नहीं manually model को fine-tune करना उसे बिगाड़ेगा या सुधार देगा। अच्छा होगा अगर ईमानदारी से feedback देने पर generic models की आदतें—जैसे ज़रूरत से ज़्यादा चापलूसी, verbosity, या हर बात को analogy से समझाने की परेशान करने वाली आदत—कम हो सकें, लेकिन नहीं पता कि सिर्फ एक व्यक्ति के prompt feedback से यह पर्याप्त होगा या नहीं
    यह भी सुना है कि internal documents पर fine-tune किए गए in-house agents भी अजीब व्यवहार दिखाते हैं और standard models से ज़रूरी नहीं कि अधिक उपयोगी हों। अच्छा होगा अगर agent के सभी responses को edit किया जा सके, और original तथा edited versions के अंतर पर fine-tune किया जा सके
    व्यक्तिगत रूप से मैं बहुत से adjectives हटाकर जवाब को core response तक refine करूँगा, लेकिन Owain Evans जैसे alignment researchers के काम को देखकर चिंता होती है कि ऐसे बदलाव model को अप्रत्याशित प्रवृत्तियों की ओर धकेल सकते हैं

    • htrp: Cursor ऐसा कर रहा है। शायद provider के रूप में Fireworks का उपयोग करता है: https://cursor.com/blog/real-time-rl-for-composer
    • rolisz: ऐसा ही कुछ OpenClaw agent पर आज़माना चाहता हूँ
      लगता है Owain Evans का काम SFT था। Twitter पर किसी को कहते देखा था कि RL उस तरह की घटना के प्रति कम संवेदनशील है जो उसने दिखाई थी, इसलिए खुद experiment करके देखना चाहता हूँ

  • heisenbit: setup work की ज़रूरत पड़ती है, लेकिन उस प्रक्रिया में बहुत कुछ सीख रहा हूँ
    48GB M4 MBP पर मुख्य रूप से qwen/qwen3.6-35b-a3b mlx इस्तेमाल करता हूँ, और Docker dev-container तथा basic कामों के लिए बस थोड़ी-सी spare capacity बचती है। इसे LM Studio में चलाता हूँ और VSCode में इस्तेमाल करता हूँ
    system prompt बदलकर tool integration बेहतर करना बड़ा फ़र्क लाया। उससे पहले यह changes apply करने के बजाय code को फिर से generate कर देता था, जिससे मदद कम और नुकसान ज़्यादा होता था
    noise और heat से बचने के लिए power connected होने पर भी ज़्यादातर low power mode में इस्तेमाल करता हूँ। maximum performance पर speed लगभग दोगुनी होती है, लेकिन power consumption दो गुने से भी ज़्यादा हो जाता है
    जो काम हो पाए, वे page की simple restructuring तक सीमित थे, और Pinia store split करना असफल रहा। GPT-5.4 यह काम बिना समस्या के कर देता है। मुझे लगता है कि tool usage guide और आसपास के support tools को और tune करने पर performance और बेहतर हो सकती है

  • nfrankel: कोशिश की थी, और सिद्धांत रूप में यह काम करता है: https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
    नतीजे model के अनुसार अलग-अलग होते हैं, और आखिरकार सीमा computer ही है। मेरा setup अफसोस की बात है कि इसे संभाल नहीं पाया

  • K0balt: qwen 3.6 27b dense के साथ काफ़ी अच्छे results मिले
    task के हिसाब से यह Claude Haiku 4.5 के समान लगता है, और शायद कभी-कभी Sonnet level का भी

    • kadoban: जानना चाहता हूँ कि आप काम चलाने के लिए कौन-सा tool इस्तेमाल करते हैं
    • kandros: coding tasks के लिए तो मैं Haiku से बेहतर कसाई से पूछना पसंद करूँगा

  • jderekw: रोज़मर्रा के setup में AMD Lemonade इस्तेमाल करता हूँ
    Ollama से शुरू किया, फिर LMStudio पर गया, और अब cRAM, CPU, GPU, gRAM monitoring में मदद करने वाले AMD Lemonade पर standardize किया है। Lemonade की multi-model functionality की वजह से LLM, speech-to-text, NPU और image generation stack को आसानी से चला सकता हूँ
    platform Nvidia, Apple, Intel और AMD chipsets पर भी चलता है

  • redox99: घर पर चलाए जा सकने वाले Qwen 35B जैसे models Opus या GPT 5.5 के बिल्कुल भी करीब नहीं हैं
    उनके आसपास के open models लगभग 1T parameters के हैं, इसलिए उन्हें घर पर चलाना भूल जाइए। यह किसी पुराने खटारा वाहन को चलाने जैसा है—कुछ लोग कह सकते हैं कि A से B तक पहुँचने के लिए यह काफी है, लेकिन यह ठीक नहीं है
    जब तक privacy बिल्कुल अनिवार्य न हो, या आप सिर्फ मज़े के लिए न कर रहे हों, या airplane जैसी कोई विशेष स्थिति न हो, इसका कोई तार्किक कारण नहीं है। अगर आप Codex पर भारी subsidy वाले 20 डॉलर भी खर्च नहीं कर सकते, तो Chinese model API इस्तेमाल करना इन छोटे models से कहीं बेहतर है

    • pbasista: यह जानना चाहता हूँ कि “घर पर चलाए जा सकने वाले Qwen 35B जैसे models Opus या GPT 5.5 के बिल्कुल करीब नहीं हैं” वाला आकलन किस objective fact या benchmark पर आधारित है
    • xgulfie: office जाने के लिए Ferrari की ज़रूरत नहीं होती

  • sj_tech: Mac Mini 128GB पर GitHub Copilot Extension for VSCode के साथ Qwen 3.6 35B A3B को agent coding के लिए इस्तेमाल करता हूँ
    model size के हिसाब से यह ठीक है, लेकिन जब समस्या बहुत बड़ी हो जाती है तो इसे loop में फँसते देखा है। यह उन कामों में अच्छा है जो आपको खुद आते हैं और जहाँ आप समय बचाना चाहते हैं

  • julianlam: Framework 13 में 32GB memory पर Qwen 3.6 35B-A3B को llama.cpp से चलाता हूँ और 15tok/s मिलते हैं
    यह code और text मेरे पढ़ने की गति से तेज़ output करता है

  • moezd: अभी नहीं। जब तक pure Apple setup या ठीक-ठाक GPU न हो, बहुत RAM और threads होने पर भी बस 30~50tok/s ही मिलता है, और वह भी thinking बंद होने पर
    इन optimizations के बिना model MCP, skills, और agent descriptions को बेहिसाब खा जाता है, और first output token देखने से पहले पेंट सूखते देखना पड़ता है
    local model serving में context window के हर token को बचाना पड़ता है, और यह Claude/GPT/Copilot द्वारा industry को ले जाए जा रहे direction के बिल्कुल उलट है

    • amarshall: thinking output speed नहीं बदलता। Anthropic models की median output speed लगभग 40~60t/s होती है

  • mitchell_h: कोशिश की, लेकिन context window काफ़ी बड़ी नहीं थी

    • coder543: Qwen3.6-27B 10 लाख token context window को support करता है
      बेशक, ऐसे context window को चलाने के लिए hardware चाहिए, और मेरे DGX Spark में q4_k_xl model पर full f16 KV cache इस्तेमाल करने पर लगभग 100GB memory चाहिए होती है
    • lysace: मेरा भी लगभग यही अनुभव था। मेरी RTX 4070 में सिर्फ 12GB है, इसलिए सोच रहा हूँ कि 24/32GB पर क्या वास्तव में इतना सुधार मिलता है कि वह उपयोगी हो
    • deadbabe: इसे open-ended सवाल की तरह पूछने के बजाय ज़्यादा सीधे तरीके से prompt करना चाहिए

  • drnick1: जिज्ञासा है कि अभी हाई-एंड consumer GPU पर चल सकने वाला सबसे अच्छा coding model कौन सा है।
    अगर मान लें कि RTX 3090/4090 है, तो आप कौन-सा stack recommend करेंगे, यह भी जानना चाहता हूँ। क्या यह Llama.cpp + OpenCode जैसी कोई combination है?

  • bijowo1676: महंगे frontier models से ऐप की spec, product requirements, architecture जैसी Markdown documents लिखना और अपडेट करना, फिर सस्ते या local models से उन specs को implement करवाना — यह setup दिलचस्प लगा।
    Markdown सैकड़ों source files की तुलना में जानकारी को बेहतर तरीके से compress कर देता है, इसलिए वह context window में अच्छी तरह फिट हो जाता है, लेकिन खुरदरे हिस्सों को तराशने के लिए 2nd और 3rd pass की ज़रूरत पड़ती है। जानना चाहता हूँ कि क्या किसी ने यह तरीका अपनाया है।

  • grmnygrmny2: OpenAI या Anthropic products के इस्तेमाल को लेकर नैतिक आपत्ति थी, इसलिए LLM अपनाने से ही हिचक रहा था।
    Local models उस नैतिक असहजता का ज़्यादातर हिस्सा दूर कर देते हैं, इसलिए पिछले लगभग एक महीने से मैं उन्हें काम और personal projects में इस्तेमाल कर रहा हूँ। मेरे पास 32GB Mac systems और 10GB 3080 gaming PC है, इसलिए अलग-अलग quantizations में Qwen3.6-35B-A3B तक ही मेरी सीमा है, लेकिन यह काफी है।
    लगभग 200~400 PP और 20~30 TG मिलते हैं, और इन्हें सही तरह से इस्तेमाल करना सीखने में थोड़ा समय लगा। कुछ कामों में इसे संभालना या दिशा देना पड़ता है, लेकिन फिर भी यह काफी उपयोगी है।
    मैंने CC कभी इस्तेमाल नहीं किया, इसलिए तुलना नहीं कर सकता, लेकिन embedded C++ से लेकर Vue तक यह एक अच्छा assistant या pair programmer बन जाता है। काश मैं 27B चला पाता, और कभी-कभी ऐसा लगता है कि यह model किसी चीज़ को लगभग समझ ही गया है, फिर नहीं कर पाता — लेकिन ऐसा कम होता है।
    कई कामों में यह बड़ा time-saver रहा है, और काफी अस्पष्ट निर्देशों के साथ भी bugs में गहराई तक जाकर उन्हें ठीक करने की इसकी क्षमता अच्छी रही। Harness के लिए मैं Pi इस्तेमाल करता हूँ।