Ask HN: क्या किसी ने दैनिक कोडिंग के लिए Claude/GPT को किसी लोकल मॉडल से बदला है?

Hacker News चर्चा ↗

समग्र भावना

  • बहुत कम लोगों ने दैनिक कोडिंग के लिए पूरी तरह Claude/GPT को लोकल मॉडलों से बदला है।
  • कई लोग हाइब्रिड तरीका अपनाते हैं: अधिकांश काम के लिए लोकल ओपन-वेट्स, और योजना, कठिन बग्स, या रिव्यू के लिए फ्रंटियर मॉडल (Claude/GPT/DeepSeek/Kimi/GLM)।
  • सहमति: लोकल “अच्छा है और बेहतर हो रहा है,” लेकिन विश्वसनीयता, तर्कशक्ति, और बड़े-रिपो काम के लिए अभी भी आम तौर पर शीर्ष क्लाउड मॉडलों से पीछे है।

हार्डवेयर और प्रदर्शन

  • उपयोगी सेटअप अक्सर इनमें शामिल होते हैं:
    • हाई‑VRAM GPUs (RTX 3090/4090/6000, 4×5070, Radeon 7900XTX/R9700)।
    • हाई‑RAM Apple silicon (M4/M5/Mac Studio 64–512 GB) या Strix Halo 128 GB।
  • सामान्य प्रदर्शन रिपोर्ट:
    • ~30–35B मॉडलों पर, MTP, quant, और concurrency के अनुसार, ~40–150 tok/s decode, 400–4000 tok/s prefill।
  • बिजली का खर्च मामूली नहीं है, लेकिन आम तौर पर हार्डवेयर CAPEX से काफी सस्ता होता है; कुछ अनुमानित TCO दिखाते हैं कि कई उपयोगकर्ताओं के लिए cloud APIs अभी भी सस्ते हैं।

मॉडल चयन और महसूस की गई गुणवत्ता

  • कोडिंग के लिए सबसे अधिक सराहे गए लोकल मॉडल:
    • Qwen 3.6 27B dense (अक्सर Q4–Q6 quant)। इसे अक्सर Haiku और पुराने Sonnet के बीच कहीं के रूप में तुलना किया जाता है।
    • गति के लिए Qwen 3.6 35B A3B (MoE); कोडिंग में अक्सर 27B dense से थोड़ा कमजोर।
    • Gemma 4 (26–31B, QAT variants सहित) एक मजबूत सामान्य मॉडल के रूप में, कभी-कभी tool-use में Qwen से कमजोर।
    • DeepSeek V4 Flash / ds4 उच्च-स्तरीय Apple या GPU rigs पर reasoning-heavy काम के लिए।
  • बड़े MoE open models (Qwen 3.5 122B‑A10B, Nemotron, MiniMax) मजबूत हो सकते हैं लेकिन बड़े RAM की जरूरत होती है और वे धीमे होते हैं; कुछ लोग उन्हें अच्छी तरह ट्यून किए गए 27B–35B dense से भी कमजोर पाते हैं।

Harnesses, tooling और workflows

  • Harness की गुणवत्ता को मॉडल जितना ही महत्वपूर्ण माना जाता है:
    • लोकप्रिय: pi.dev, Claude Code (लोकल endpoints की ओर pointed), OpenCode, Crush, Aider, custom CLIs, VS Code/Copilot to local llama.cpp servers।
  • प्रभावी पैटर्न:
    • सख्त tools, sub-agents, या multi-step plans के साथ agentic workflows।
    • फ्रंटियर मॉडल spec/plan लिखता है; लोकल मॉडल implement करता है।
    • संकीर्ण भूमिकाओं वाले कई लोकल agents (plan, schema, code, tests, review)।

सीमाएँ और दर्द के बिंदु

  • सामान्य समस्याएँ:
    • loops, over-thinking, और broken tool/edit calls, खासकर aggressive quantization या खराब sampling के साथ।
    • context limits और cache quirks; बड़े nominal windows के बावजूद लंबे contexts पर quality गिरती है।
    • लैपटॉप पर धीमापन और fan/noise; complex repos cloud की तुलना में “हमेशा” जैसे लगते हैं।
    • सेटअप की जटिलता: drivers, quant choices, KV cache settings, batching, harness config।
  • कई लोगों के अनुसार लोकल मॉडल एक सक्षम लेकिन junior dev जैसे लगते हैं; फ्रंटियर मॉडल विशेष रूप से architecture और tricky bugs के लिए strong mid/senior जैसे लगते हैं।

गोपनीयता, लागत, और रणनीति

  • लोकल अपनाने के कारण:
    • डेटा privacy/compliance, lock-in से बचना, भविष्य में price hikes या regulation का डर, tinkering का आनंद।
    • व्यक्तिगत projects, scripting, glue code, document tasks के लिए “good enough”।
  • लोकल न अपनाने के कारण:
    • हार्डवेयर लागत बनाम भारी सब्सिडी वाले $20–$100/mo frontier subs।
    • Cloud models (विशेषकर DeepSeek/Kimi/GLM) प्रति token बेहद सस्ते और स्पष्ट रूप से अधिक सक्षम हैं।
  • उभरता हुआ पैटर्न: layered approach—पहले local, फिर cheap open-weights APIs, और frontier केवल तब जब वास्तव में ज़रूरत हो।