लोकल Qwen कोई बदतर Opus नहीं, बल्कि एक अलग टूल है

 (blog.alexellis.io)
2 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लोकल Qwen 3.6 27B ऐसे कामों में वास्तविक मूल्य देता है जिन्हें customer data और internal telemetry की तरह cloud पर भेजना मुश्किल होता है, लेकिन यह cloud SOTA models का विकल्प नहीं बन पाता
  • लोकल models की ताकत top-performance models से score की होड़ में नहीं, बल्कि fixed cost, privacy, और vendor risk को कम करने में है, और heavy usage तथा SaaS के internal features में यह अंतर खास तौर पर दिखता है
  • SWE-Bench Verified में Qwen 3.6 27B ने 77.2 score किया, जबकि Claude Opus 4.8 ने 88.6% हासिल किया; इसलिए "लोकल SOTA से सिर्फ 12% पीछे है" जैसा दावा benchmark tuning की संभावना और Go जैसे वास्तविक domain differences को नज़रअंदाज़ करता है
  • लगभग 12,000 डॉलर में खरीदा गया RTX 6000 Pro Blackwell 96GB हार्डवेयर सिर्फ customer license underreporting पकड़कर की गई revenue recovery से ही अपनी लागत निकाल चुका
  • सबसे बड़ी सीमा लंबे कामों में दोहराए जाने वाले output और hallucination पैदा करने वाली loop problem है; long-horizon unattended coding की तुलना में लोकल Qwen customer support, narrowly scoped maintenance, और codebase पढ़ने-समझाने के लिए ज्यादा उपयुक्त है

AI उपयोग की पृष्ठभूमि और बिज़नेस संदर्भ

  • OpenFaaS से शुरू होकर SlicerVM, Actuated, Inlets जैसे low-level infra और Linux primitives पर केंद्रित products एक छोटी टीम चला रही है
    • यह container, Firecracker microVM, network protocols, tunnel, CLI, Kubernetes पर आधारित हैं और मुख्यतः Go में लिखे गए हैं, साथ में कुछ React UI भी है
  • VS Code tab autocomplete के समय से AI tools का उपयोग किया जा रहा है, और अब अधिकांश code Claude या Codex से बनता है; हाथ से coding लगभग नहीं के बराबर है
  • tmux में लंबे समय तक चलने वाले workflow को मैनेज करने के लिए Superterm.dev बनाया गया, और इसका उपयोग session, notes management तथा coding agents के visual feedback के लिए होता है

frontier intelligence का turning point

  • 2025 के नवंबर से 2026 के जनवरी के बीच turning point आया, जब X पर कई developers ने कहा कि Claude Opus उनका पूरा काम संभाल सकता है
  • top-tier coding plan की कीमत व्यक्ति के लिए लगभग 200 USD प्रति माह पर स्थिर हुई, और बहुत अधिक unattended work से बचा जाए तो 5-hour weekly limits के भीतर इसका उपयोग संभव है

लोकल models दिलचस्प क्यों हैं

  • 2026 ऐसा समय है जब कोई भी व्यक्ति सिर्फ एक subscription से रातोंरात ideas की नकल कर सकता है; SlicerVM और Superterm ने भी clone cases देखे हैं
    • ऐसे बाज़ार में जहाँ software cost शून्य के करीब पहुँच रही है, "free और good enough" निर्णायक हो सकता है
  • leading models का आकार 0.5~2T parameters माना जा रहा है, जो top local hardware से बिल्कुल अलग स्तर है

  • Benchmaxxing

    • benchmarks public होते हैं, इसलिए score बढ़ाने के लिए उन्हें tune किया जा सकता है, और इस वजह से उन्हें absolute metric मानना कठिन है
    • SWE-Bench Verified Python issues पर आधारित है, जहाँ अधिकांश code single-threaded और synchronous है; इसके विपरीत Go distributed systems में channel, context, struct बड़े execution surface में फैले रहते हैं
    • सिर्फ benchmark scores देखकर यह कहना कठिन है कि “लोकल SOTA से 12% पीछे है”, क्योंकि वास्तविक काम में language और system characteristics सफलता-असफलता को बहुत प्रभावित करते हैं

  • Cost

    • “लोकल models में cost issue नहीं है” जैसी बात हर user पर लागू नहीं होती
    • व्यक्तिगत coding plan 200 डॉलर प्रति माह में high usage और SOTA-level intelligence देता है, लेकिन ऐसा लगता है कि coding plans को subsidy मिल रही है
    • GitHub Copilot पहले 39 डॉलर प्रति माह में 1,500 requests देता था, लेकिन बाद में token-based pricing पर गया और इसका काफी विरोध हुआ
    • अगर billing API token cost के आधार पर हो, तो breakeven जल्दी आ सकता है
      • Uber ने developer per tool 1,500 डॉलर प्रति माह तक AI spend limit रखी है
      • Uber की median salary 330,000 डॉलर मानें, तो कोई developer दो tools को पूरी limit तक उपयोग करे तो यह salary का लगभग 12% बैठता है
    • heavy usage, loops, agent analysis, और SaaS embedded features में open weight तथा local models महत्वपूर्ण value दे सकते हैं

  • Sovereignty and privacy

    • customer data और contract terms के कारण कई बार data को cloud plans पर भेजना कठिन होता है
    • ChatGPT Pro और Claude Max में 30-day retention सेट किया जा सकता है, लेकिन लेखक के अनुसार यह स्तर भी customer contracts को अमान्य कर सकता है
    • अमेरिका के बाहर users के लिए Anthropic का Fable 5 model रातोंरात हटा दिया गया था; यह vendor risk का उदाहरण है
    • लोकल models, “अगर frontier lab X कर दे तो?” जैसे जोखिम का जवाब हैं

blade forging analogy — लोकल model की असल प्रकृति

  • जैसे steel heat treatment में एक चरण ज़्यादा निकल जाए तो फिर शुरुआत से करना पड़ता है, वैसे ही लोकल models भी बहुत गरम चलने पर लक्ष्य पार करके loop में फँस जाते हैं
    • इसका एकमात्र उपाय harness को बंद करना और खाली context के साथ दोबारा शुरू करना है
  • जैसे blade forging को unattended नहीं छोड़ा जाता, वैसे ही Qwen 3.6 27B को long-horizon tasks नहीं दिए जाते

  • मैं क्या खोज रहा था

    • लक्ष्य privacy, fixed cost, और vendor risk से बचाव था
    • जब लोकल models को Claude और Codex की तरह इस्तेमाल किया गया, तब निराशा हुई
    • Claude बहुत छोटी instruction (“do it and test it end to end”) से 5~15 मिनट में PR लिखने, automated code review और iteration का प्रभावी loop चला सकता है

3090 से मिले सबक

  • 2023 में एक single 3090 से शुरुआत हुई, लेकिन model load और पर्याप्त context के लिए एक और card की ज़रूरत पड़ी
    • यही वह समय था जब पहली बार Qwen 3.5 को agent की तरह वास्तविक काम करते हुए देखा गया
  • जब निर्देश दिया गया, “machine को हर angle से explore करके forensic report लिखो”, तब इसने हर file को एक-एक करके पढ़ते हुए context भर दिया और file names तथा tool calls hallucinate करने लगा (~/faas-netes→~/faaned)
    • scope को सीमित कर “बस हल्का-सा survey करो” कहा गया, तो लगभग 40~50 tok/s की गति से एक स्पष्ट रिपोर्ट बनी
  • 27B model एक single 3090 में full precision पर फिट नहीं होता, इसलिए tuning variables हैं weight quantization, context length, और KV cache compression
    • आम समझ यह है कि KV cache के keys हिस्से में Q4_0 पर समस्या आती है, इसलिए सबसे aggressive setup भी keys Q8_0 / values Q4_0 तक सीमित रहा
  • vLLM + NVLink + tensor parallelism के प्रयोगों में generation speed llama.cpp से 3 tokens/sec धीमी थी, साथ ही loops हुए और weight loading में कई मिनट लगे
    • vLLM large-scale concurrent serving के लिए अच्छा है, लेकिन prosumer environment में startup time, simplicity और single-user latency अधिक महत्वपूर्ण हैं

बड़ा खर्च — RTX 6000 Pro अपनाना

  • customer support tickets को तेजी से हल करने के लिए लगभग 12,000 USD का RTX 6000 Pro Blackwell (96GB VRAM) खरीदा गया
    • बाद में कीमत लगभग 15,400 USD तक बढ़ गई, इसलिए दूसरा card जोड़ना मुश्किल हो गया
    • PCI lanes, bandwidth, card spacing और PSU load जैसी वजहों से इसे consumer machine में बस जोड़ देना संभव नहीं था
  • यह एक calculated bet थी और सफल भी रही, लेकिन इसने Claude subscription को replace नहीं किया

data leak के बिना आसान customer support

  • operators आसानी से चला सकें, इसके लिए diag नाम का CLI tool बनाया गया जो OpenFaaS Kubernetes installation का पूरा snapshot कैप्चर करता है
    • मिले हुए dump को Slicer द्वारा बनाए गए ephemeral VM के अंदर airgapped local model से analyze किया जाता है

  • Revenue recovery

    • telemetry DB को local model में डालकर एक customer की 12 महीनों से अधिक license underreporting और 4~5x underpayment पकड़ी गई; सिर्फ इसी recovery ने card की लागत निकाल दी
    • telemetry और diag dumps को data retention policy की परवाह किए बिना किसी भी cloud plan में नहीं डाला जाता
    • ChatGPT Pro और Claude Max में 30-day retention सेट किया जा सकता है, लेकिन यह स्तर भी customer contracts को अमान्य कर सकता है
    • शुरुआती models arithmetic में विफल रहे (27.3K को 273,000 गिनना), और कम function count देखकर frequent execution को नज़रअंदाज़ कर churn risk का गलत अनुमान लगाया
    • नतीजा यह निकला कि interpretation की बजाय analysis पर focus कराना बेहतर है

मौजूदा setup

  • RTX 6000 rig पर Qwopus की latest generation और base Qwen 3.6 27B साथ चलाए जाते हैं, और नए finetune या point releases के साथ setup बदलता रहता है
    • Qwopus Qwen के ऊपर Chain of Thought tracing जोड़कर reasoning और coding performance बढ़ाने की कोशिश करने वाला finetuned model है
    • हाल तक thinking को पूरी तरह बंद रखा गया था, और इसे दोबारा चालू करने का समय loops बढ़ने के साथ मिला
  • full context length बनाए रखने के लिए दो अलग-अलग llama.cpp instances से serving की जाती है; --parallel 2 context को आधा कर देता है
  • speculative decoding (MTP) में लगभग 93% acceptance rate मिली, और speed स्थिर 67 tok/s से बढ़कर 130~200 tok/s हो गई, जिससे यह cloud से तेज महसूस हुआ
    • model card tuning guide का पालन महत्वपूर्ण है; Qwopus में thinking off रखकर temperature 0.85~1.0 पर बहुत गरम सेट करने पर सबसे अच्छे नतीजे मिले

दोहराए जाने वाले output और लंबे कामों की सीमा

  • Qwen की सबसे बड़ी समस्या लंबे दायरे वाले कामों में loop में फँस जाना है
  • faas-cli में जोड़ने के लिए command पूछी गई तो इसने पहले उचित सुझाव दिए, लेकिन बाद में वही command list दोहरानी शुरू कर दी और लगभग 30 मिनट तक 600W बिजली खपत की
  • जब get और list commands में --json जोड़ने को कहा गया, तो शुरुआत के एक-दो steps ठीक लगे और tests भी लिखे गए, लेकिन बाद में समस्याएँ बढ़ीं
  • --json output में http:// remote endpoints के insecure TLS warning को रोकने के लिए Python reverse proxy इस्तेमाल कराया गया; पहला version ठीक-ठाक था, लेकिन indentation गलत थी, और fix करते-करते file खराब कर दी गई, फिर भी यह अटका रहा और बार-बार दोहराता रहा
  • टीम के सदस्य Han ने भी ऐसे loops देखे, खासकर तब जब model या agent अपनी capability boundary पर पहुँचकर भी मदद नहीं माँगते थे
  • इसी कारण local Qwen पर customer support और renewal telemetry/diag analysis के अलावा आसानी से भरोसा करना मुश्किल है

access measurement और distribution

  • शुरुआत में single inlets tunnel इस्तेमाल हुआ; जब दो agents एक ही llama.cpp instance से जुड़ते थे, तो cached prefixes एक-दूसरे को invalidate कर देते थे और पूरा prompt फिर से process करना पड़ता था
  • कई लोग उपयोग करें तो यह prototype से आगे की समस्या बन जाती है: कौन किस instance का उपयोग कर रहा है, कितना, कौन-सा model, power cost क्या है, churn पर क्या करना है आदि
  • opencode.json को हाथ से edit और distribute करने के बजाय opencode के लिए "Toilgate" provider लिखा गया, जिससे model picker में base model से लेकर experimental Qwopus variants तक चुने जा सकते हैं
    • Toilgate पूरी तरह vibe-coded है और इसे open source करना भारी काम लगेगा
  • दीवार के socket पर 2 Shelly Plus Plug से power consumption मापा गया; RTX 6000 Pro inference के दौरान 600W पर शांत रहा, जबकि दो 3090 मिलकर लगभग 750W लेते थे और बहुत शोर करते थे

  • गलत तुलना

    • million tokens के input/output cost की GPT-5.5 API pricing से तुलना करना मौजूदा capability के हिसाब से गलत तुलना है
    • “local AI” अंततः identity, access control, metering, quota, model routing और power monitoring की ज़रूरत वाला operations problem बन जाता है

वास्तव में उपयोगी रहे usage patterns

  • local model और harness को specialized tasks के लिए ढालना महत्वपूर्ण है
    • customer support
    • स्पष्ट दायरे वाला maintenance
    • end-to-end testing
  • AGENTS.md में detailed instructions जोड़ने से local model नए CLI को तेज़ और ज्यादा कुशलता से जोड़ सका और खुद tests भी चला सका
  • local models सीधे code लिखने में सीमित हो सकते हैं, लेकिन वे codebase को जल्दी पढ़ने और समझाने में मजबूत हैं
  • Agent Skills भी मददगार रहे, और एक मामले में local agent ने नए mini PC पर Slicer को scratch से setup किया
  • local models और cloud models दोनों पर एक ही काम चलाकर तुलना करने की आदत सामान्य बनानी चाहिए
    • एक जैसे task comparison case की तरह, कभी results निराशाजनक होते हैं और कभी किस्मत अच्छी लगती है
  • लंबे दायरे वाले unattended agent tasks से बचना चाहिए; लगभग 15,000 डॉलर का hardware भी इस समस्या को हल नहीं कर पाया

मौजूदा निष्कर्ष और model selection की सीमाएँ

  • local Qwen “Opus-level के करीब” होने से ज़्यादा, कुछ खास tasks और workflows में मूल्य देने वाला एक अलग tool है
  • Qwen 3.5 को पहला ऐसा model माना गया जिसने उपयोगी नतीजे दिए; 3.7 की अफवाहें हैं, लेकिन क्रांतिकारी बदलाव की बजाय incremental improvement की अपेक्षा है
  • 70B models को ज़्यादातर पुराना और generation में पीछे माना गया
  • Qwen 35-A3B MacBook पर तेज़ दिखने के कारण लोकप्रिय है, लेकिन generation के समय सिर्फ 3B active parameters होने से लेखक speed पर quality को प्राथमिकता देता है
  • GLM 5.2, Kimi 2.7, Minimax M3, Deepseek V4 Flash जैसे बड़े models कुछ local hardware पर संभव हैं, लेकिन उनके quantized versions भी लोड करने के लिए अक्सर RTX 6000 Pro की 4~6 cards चाहिए होती हैं, इसलिए वे दायरे से बाहर हैं
  • मौजूदा 27B dense models पूरे दिन Go code लिखने के लिए पर्याप्त नहीं हैं, और उनका सीमित knowledge तथा attention code review में तुरंत दिख जाता है
  • Qwen संक्षिप्त रहने के निर्देश का अच्छे से पालन नहीं करता, और automated code review में बेवजह बहुत विस्तार लिखता है या concurrency issues और race conditions hallucinate करता है, जिससे प्रयोग जल्दी रोकने पड़ते हैं
  • सस्ता और तेज़ Grok Coder Fast 1 deprecate होने से पहले कई महीनों तक अच्छी तरह काम करता रहा
  • संबंधित उदाहरण code review bot और OpenFaaS का painless customer support and architecture review में संकलित हैं

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की टिप्पणियाँ

  • इन models को लंबे समय तक इस्तेमाल करने पर समझ आता है कि बात सिर्फ इतनी नहीं है कि “X, Y से ज़्यादा स्मार्ट है” या “Y, Z से सस्ता है।” ये अलग-अलग tools हैं, और इनकी prompting style भी अलग होती है, इसलिए ये काफ़ी हद तक कोई वाद्ययंत्र बजाने जैसा है
    Claude के साथ कभी-कभी जानबूझकर कम स्पष्ट या थोड़ा अप्रत्यक्ष होना पड़ता है, ताकि implementation में रंग आ सके या ज़्यादा creative नतीजे मिलें। और यह अजीब लग सकता है, लेकिन Claude के साथ विनम्र रहने पर फायदा मिलता है, और रूखे होने पर नुकसान। Claude tone को ज़्यादा मज़बूती से mirror करता है, इसलिए negative loop में न फँसना बेहतर है
    GPT के साथ सटीक होना पड़ता है और ambiguity कम करनी पड़ती है। GPT ambiguity को “X करूंगा, लेकिन Y नहीं होने दूँगा” जैसी min-max शैली से सुलझाने की कोशिश करता है, और अगर scope साफ़ न बताओ तो यह हर edge case को पकड़ने की कोशिश में over-engineer करने लगता है
    Qwen के साथ पहले structure तय करके उसके भीतर भरने देना पड़ता है। Qwen को XML, JSON, lists पसंद हैं, और अगर उसे पहले के काम के बहुत से examples दिखाओ तो यह अच्छा करता है। यह कोई वैज्ञानिक बात नहीं है, बस अनुभव है, इसलिए नतीजे अलग हो सकते हैं

    • “वैज्ञानिक नहीं, बस अनुभव” होना ही असली समस्या है। अच्छा होता अगर हर model के strengths और weaknesses के साथ कोई product manual होता, जिसमें “ऐसे काम के लिए X model” या “Y model को Z तरीके से इस्तेमाल करना चाहिए” जैसी decision tree दी होती
      लेकिन ऊपर से सब काफ़ी एक जैसे दिखते हैं, और कहाँ कौन-सा थोड़ा बेहतर है यह समझने के लिए खुद ही बहुत व्यापक, समय लेने वाले, और शायद महंगे tests करने पड़ते हैं
    • पहले मैंने एक ही input पर same prompt दोबारा चलाकर, या ऐसे inputs देकर जो अर्थ में एक जैसे हों लेकिन अभिव्यक्ति या संरचना में अलग हों, बहुत test किया कि नतीजे कितने अलग हो जाते हैं। खासकर Sonnet और Opus के बीच, और अलग-अलग Qwen models के बीच यह बहुत किया
      मैं सबको यह करने की सलाह देता हूँ। इसके लिए आप जो data पहले से इस्तेमाल करते हैं उसके अलावा कोई खास data नहीं चाहिए, और नतीजे काफ़ी चौंकाने वाले होते हैं। जितना आप सोचते हैं उससे कहीं ज़्यादा randomness या instability होती है, और जो बेहतर prompting technique या खास तौर पर अच्छा या बुरा result लगता है, वह सिर्फ संयोग भी हो सकता है, या model version और size के हिसाब से behavior का फ़र्क हो सकता है। input में छोटे बदलाव भी result को बहुत bias कर सकते हैं। हमारी कंपनी में हम इनमें से कुछ को magic words कहते हैं, क्योंकि सिर्फ किसी खास technical term, reference, या technique का ज़िक्र करने से result बहुत बेहतर हो जाता है
      इसमें एक technique भी है। अगर agent loop में model को ऐसी self-evaluation structure में रखा जाए जहाँ उसके लिए cheating या shortcuts लेना मुश्किल हो, और वह उसकी trained structure या domain से मेल खाए, तो यह बहुत अच्छा काम करता है। लेकिन सही sweet spot ढूँढना मुश्किल है। एक tip दूँ तो Opus 4.8 से PyTorch model को ONNX या quantized model में convert करवाना, या उसे दूसरे hardware पर चलवाना, ऐसा है जैसे उसकी कोई special ability on हो गई हो। दूसरी तरफ, उसे सामान्य भाषा या format की EBNF formalization बिना cheating के ठीक से लिखवाना और test करवाना मेरे लिए लगभग असंभव रहा है
      सबसे बुरी बात यह है कि इस तरह की जानकारी बहुत जल्दी बदल जाती है, इसलिए अगर आप सच में model को train करने वाले व्यक्ति नहीं हैं, तो इसमें बहुत गहराई तक जाने का फ़ायदा लगभग नहीं है। काश training में output की stability पर ज़्यादा ज़ोर दिया जाता ताकि चीज़ें ज़्यादा predictable बनें। overfitting या exploration-exploitation loop को बिगाड़े बिना यह करना मुश्किल होगा, लेकिन अगर batch jobs ज़्यादा स्थिरता से चल सकें, तो मैं LLMs पर कहीं ज़्यादा पैसा खर्च करूँगा
    • यह वाद्ययंत्र बजाने से ज़्यादा slot machine घुमाने जैसा लगता है, बाकी सब हम अपनी तरफ़ से कल्पना कर लेते हैं
    • ज़्यादातर बातों से सहमत हूँ, लेकिन एक बिंदु पर अलग राय है। सही समय पर Claude से रूखे ढंग से बात करना कभी-कभी बहुत असरदार होता है। खासकर F-bomb कभी-कभी Claude को अटकी हुई स्थिति से बाहर निकालने में काफ़ी मददगार लगता है
    • मैंने GLM 5.2 से एक पुराने C#/XNA game को HTML5 में port करने को कहा, तो उसने code लगभग वैसा का वैसा उठा लिया, और JS में न होने वाले operator overloading को छोड़कर उसे चलाने के लिए ऊपर से कुछ extra code जोड़ दिया
      वही request जब Claude Sonnet 4.6 से की, तो result ऐसा आया मानो वह game शुरू से ही JS में लिखा गया हो। ऊपर से उसने जाने क्यों उसे single HTML file बना दिया, सारे assets हटा दिए, graphics और music को dynamically generate किया, और एक बेहतर नया background भी बना दिया
      मैंने तो बस game porting माँगी थी, इसलिए यह हैरान करने वाला था। उसके choices मुझे काफ़ी पसंद आए, लेकिन मुझे नहीं पता कि इस तरह के behavior को on और off कैसे किया जाए। कभी creativity चाहिए होती है, और कभी सचमुच वही चाहिए होता है जो आपने कहा हो

  • इस लेख और इसकी तारीफ़ को देखकर नंगा बादशाह जैसी भावना आती है। यह वाक्य शुरू से ही समझ में नहीं आता
    “These products use very low level Linux primitives like containers, Kubernetes, Firecracker microVMs, and networked protocols.”
    “low-level Linux primitives” कहने लायक चीज़ों में शायद networking protocols को किसी तरह गिना जा सकता है। और यह साफ़ तौर पर AI-generated writing जैसा दिखता है। अगर सिर्फ content पर भरोसा किया जा सके तो कोई बात नहीं, लेकिन उस पर भरोसा नहीं हो रहा

    • आजकल low-level का मतलब TypeScript की जगह JavaScript हो गया है
    • यह सही है कि वह वाक्य ज़रूरत से ज़्यादा compressed था। मैंने उसे दोबारा लिखा है और मतलब वही है
      लेख AI-generated नहीं है, code मैं AI से generate करवाता हूँ लेकिन लेखन खुद करता हूँ। मुझे जानना है कि कौन-सा हिस्सा समझ में नहीं आया। यह लेख हमारे अपने अनुभव और सफ़र का वर्णन है, और किसी खास दावे पर मैं खुशी से सबूत दे सकता हूँ

  • मुझे अब भी लगता है कि AI की असली ताकत किसी ऐसे और cloud service में नहीं है जिसके लिए अंतहीन पैसे चुकाने पड़ें और जो समय के साथ corporate shareholders के लालच को संतुष्ट करते-करते और खराब होती जाए, बल्कि तब है जब उसे लोकल पर सुरक्षित और निजी रूप से लागू किया जाए।
    ChatGPT या Anthropic को मैं कभी भी अपना health data उनके सिस्टम से बाँधने नहीं दूँगा, लेकिन AI की उस क्षमता पर मेरा भरोसा अब भी है कि वह ऐसे data patterns ढूँढ सकता है जिन्हें मैं चूक सकता हूँ। इसलिए Qwen या Gemma जैसी चीज़ों के लिए एक सिर्फ-लोकल ecosystem की बहुत ज़रूरत है, जहाँ data को सुरक्षित और निजी रूप से उपलब्ध कराकर process किया जा सके।
    Smart home और personal assistant पर भी यही बात लागू होती है। वह corporate तरीका, जिसमें Company A, Company B में stored data तक पहुँचती है, Company D और E उसे process करती हैं, और फिर उसे advertisers और data brokers को बेच दिया जाता है, जबकि मैं उसे अपने local hardware पर न निकाल सकता हूँ न देख सकता हूँ — ऐसे निजी उपयोगों के लिए टिकाऊ नहीं है। मेरा data मेरी शर्तों पर owned, controlled और exposed होना चाहिए, और पहले मेरे जीवन को बेहतर बनाने में इस्तेमाल होना चाहिए, किसी और की profit-and-loss sheet सुधारने में नहीं। मैं चाहता हूँ कि technology फिर से मेरा समय मुझे लौटाए और नतीजों को बेहतर बनाए, और Big Tech से पर्याप्त चोट खा चुका हूँ, इसलिए मैं इस धारणा को पूरी तरह ठुकराता हूँ कि AI-as-a-Service business model में कोई महानता या जनहित निहित है।
    क्षमता पहले से मौजूद है, और जो लोग local tools बना रहे हैं ताकि local models की क्षमता को support और unlock किया जा सके, वे सही दिशा में हैं। वे जो बना रहे हैं, उसे देखना अच्छा लगता है।

    • “लोकल” models की कुंजी आम तौर पर यह है कि वे open weights होते हैं, और कभी-कभी open source भी। इसलिए उन्हें local पर इस्तेमाल किया जा सकता है, लेकिन independent providers द्वारा host भी किया जा सकता है।
      Qwen, DeepSeek जैसे models इस्तेमाल करने पर आप किसी एक company से बँधे नहीं रहते, और ऐसे independent providers के बीच जा सकते हैं जो शायद बेहतर privacy guarantees दें। तब internet connection होने पर उन devices पर भी model इस्तेमाल किया जा सकता है जहाँ आप उसे सीधे चला नहीं सकते।
      AI की ताकत open source models में है। ऐसे models इस्तेमाल करने चाहिए जो vendor lock-in से बचाएँ और local use के साथ-साथ independent-provider hosting दोनों की अनुमति दें।

  • अच्छा लेख है। लेकिन मुझे लगता है कि यह सुधार की संभावना को कम करके आँकता है।
    लेखक खुद मानते हैं कि local models को एक साल पहले की स्थिति से आज की स्थिति से तुलना करना बहुत अर्थपूर्ण नहीं है। वास्तव में, बहुत से लोग पिछले साल नवंबर में Opus 4.5 — यानी 8 महीने पहले — को वह पहला बिंदु मानते हैं जब frontier hosted models में agentic coding व्यापक रूप से संभव हुई।
    फिर अभी के समय में local models क्या अच्छा करते हैं और क्या नहीं, इसकी धारणा को हम ज़बरदस्ती स्थिर क्यों कर दें? अभी जो भी है, एक साल बाद शायद अलग होगा। यह सोचना कि consumer और professional hardware पर लंबी-रेंज वाले tasks भी संभव हो जाएँगे, भोला आशावाद लग सकता है, लेकिन अब तक तो वही भोले आशावादी जीतते आए हैं।

    • सही बात। अगर Opus 4.5, 8 महीने पहले agentic coding के लिए पर्याप्त हो गया था, तो open weights models कितने पीछे हैं? क्या 8 महीने से भी ज़्यादा पीछे? कितना ज़्यादा? क्या वे कुछ महीनों में Opus 4.5 के स्तर तक पहुँच जाएँगे, एक साल में, या फिर कभी नहीं?
    • जो बड़ी चीज़ छूट रही है वह harness comparison है। इसका बहुत बड़ा असर पड़ता है। मैं forge इस्तेमाल कर रहा हूँ, और local models की सारी सीमाओं को ध्यान में रखने के बावजूद वह जो कर पाया, वह प्रभावशाली था।
    • क्योंकि लेखक एक खास model की बात कर रहा है, इसलिए मुझे लगता है कि समय के साथ वह model या सामान्य रूप से local models कैसे बेहतर होंगे, इसे नज़रअंदाज़ करना ठीक है।
      यह कुछ वैसा है जैसे कार खरीदना। आप उस कार को चलाते हैं और उसकी विशेषताओं के अभ्यस्त होते हैं; यह नहीं सोचते कि वह कार या वैसी कारें आगे चलकर कैसे सुधरेंगी। वह आपका tool है, और आप उसका अधिकतम उपयोग करना चाहते हैं।
      बेशक local model बदलने की तकनीकी लागत बहुत कम होती है, लेकिन किसी model से अधिकतम performance निकालने में काफ़ी समय लगता है, और संभव है कि वह मेहनत नए version पर काम ही न करे।
    • मैं 100% सहमत हूँ कि Claude 4.5 agentic coding का turning point था। उसी model की वजह से मेरी सोच पूरी तरह बदल गई।

  • दिलचस्प लेख है। व्यक्तिगत रूप से मुझे लगता है कि लेखक ने दो चीज़ें बेहतर कर सकता था।
    पहला, llama.cpp की जगह vLLM इस्तेमाल करना चाहिए था। NVIDIA hardware पर multi-user load और caching में vLLM का अंतर बहुत बड़ा है। जहाँ वह दो या उससे ज़्यादा users के model इस्तेमाल करने या cache गायब हो जाने की शिकायत करता है, वहाँ मेरी प्रतिक्रिया थी: “अरे, यह तो होना ही था।”
    दूसरा, single card पर जो budget खर्च किया गया, वह SPARK पर कहीं बेहतर इस्तेमाल हो सकता था। 2 x GX10 cluster इस्तेमाल किया जा सकता है, जिसकी कुल लागत अभी भी लेखक द्वारा चुकाई गई कीमत के आधे से कम है, और उस पर vLLM और Deepseek v4 Flash चल रहा है। Qwen से तुलना करें तो फ़र्क बहुत बड़ा है। मैंने उसे एक बार भी loop में फँसते नहीं देखा, और अब तक जिन चीज़ों का मैंने प्रयोग किया है उनमें यह सबसे Sonnet-जैसा model है। लगता है antirez भी सहमत है, शायद इसी वजह से उसने ds4 fork बनाया।
    2 GX10 पर इसे कैसे सेट किया गया, वह यहाँ है: https://forums.developer.nvidia.com/t/deepseek-v4-flash-offi...
    Performance prefill में 2K tokens/sec है, इसलिए यह विशाल context window में बहुत सारा source code डालने के लिए बेहद उपयोगी है, और pi.dev harness पर coding करते समय generation लगभग 50~60 tokens/sec है। लेखक ने जितना पैसा दिया, उतने में 4 GX10 खरीदे जा सकते थे, और vLLM tensor parallelism में लगभग linear scale करता है, इसलिए दोनों आँकड़े दोगुने किए जा सकते थे।

    • मैंने 3090 पर भी vLLM चलाकर देखा है। हमारे जैसे usage pattern में, जहाँ एक से कुछ ही users होते हैं, generation लगभग 3 tokens/sec धीमा था, quantization flexibility कम थी, और startup भी single-digit seconds की बजाय सचमुच कई मिनट लेता था।
      बाद में शायद इसे और आज़माऊँ, लेकिन मेरे पास अनंत समय नहीं है कि बस यही छेड़छाड़ करता रहूँ, और मैं अब तक की अपनी यात्रा और निर्णय साझा कर रहा हूँ।
      Concurrent batch serving के लिए vLLM सही विकल्प है, और नीचे barrkel ने जो कहा है वह बिल्कुल सही है। लेकिन हमारे उपयोग के तरीके में llama.cpp अब भी बेहतर है।
      Spark/GX10 वाला रास्ता सचमुच एक अलग दाँव है, और आँकड़े साझा करने के लिए धन्यवाद। कुछ महीने पहले तक आम धारणा यही थी कि GX10 सिर्फ fine-tuning के लिए है और उसके performance numbers बहुत खराब हैं।
      और वह card Claude Max subscription को replace करने के लिए बिल्कुल नहीं खरीदा गया था। जिन कामों के लिए वह वास्तव में खरीदा गया, उनमें वह 140~200 tokens/sec दे रहा है, और वही महत्वपूर्ण है।

  • लेख लंबा था, लेकिन फिर भी मुझे समझ नहीं आया कि लेखक असल में कहना क्या चाहता है, सिवाय उस बात के जो शीर्षक से अनुमान लगाई जा सकती है।
    हाँ, इतना ज़रूर समझ आया कि लेखक काफ़ी दिलचस्प इंसान है जो physical चीज़ें भी बनाता है और software भी, और दूसरे लोग उसे पैसे भी देते हैं। बस यह नहीं समझ आया कि इसका शीर्षक से संकेतित विषय से क्या संबंध है।

    • आजकल हर चीज़ advertisement है। लेख बेकार नहीं था, लेकिन उसने जितनी जानकारी दी, उसके हिसाब से दो paragraphs काफ़ी होते।

  • यह लेख local models का अच्छा सार देता है। कभी-कभी इन्हें coding और agent के local काम के लिए किसी शानदार टूल की तरह बढ़ा-चढ़ाकर पेश किया जाता है, लेकिन असल में ये काफ़ी सीमित हैं, और लंबे या जटिल कामों में कमज़ोर पड़ते हैं, loop में फँस जाते हैं या काम भूल जाना आसान होता है
    लेख में जो बात छूट गई, वह यह है कि इनकी लागत भी काफ़ी होती है। सिर्फ़ hardware cost ही नहीं, बिजली का बिल भी होता है। 3090 या 5090 machine बहुत बिजली खाती हैं, और ऐसे machine पर model काफ़ी धीमे होते हैं, इसलिए प्रति token बिजली खपत और बढ़ जाती है
    जहाँ ये चमकते हैं, वह है controllability, privacy, और predictability। उदाहरण के लिए photo·video library classification जैसे दोहराए जाने वाले कामों में ये अच्छे हैं, और बिजली दर के हिसाब से लागत के मामले में भी फ़ायदा हो सकता है

    • मेरा मानना है कि local model personal computer का ज़रूरी विस्तार हैं। लगता है शुरुआती personal computer पर भी इसी तरह की आलोचनाएँ हुई होंगी
    • सपना यह है कि ऐसा local model हो जो रोज़मर्रा के लगभग 80% काम संभाल सके। जैसे, “X Handler, Y storage से कैसे जुड़ा है?”, “उस feature को commit कर दो, लेकिन payment से जुड़ा हिस्सा छोड़ दो” जैसी चीज़ें
      tool calling 99% भरोसेमंद होना चाहिए, और सबसे बढ़कर उसे यह कहने में सक्षम होना चाहिए कि “यह काम मेरी क्षमता से बाहर है”, और फिर इसे किसी बड़े data center में मौजूद online high-performance model को सौंप सके
      तब सारे आसान काम device पर ही निपटेंगे, साथ में data इकट्ठा होगा और problem context समझ में आएगा, और आसान काम ख़त्म होने के बाद smart model आकर समस्या हल करेगा
      जब local model 100% कर सकने वाली /commit जैसी चीज़ के लिए online model को बुलाना पड़े, तो वह सचमुच बेवकूफ़ी जैसा लगता है। हालाँकि यह ज़्यादातर harness की समस्या है, इसलिए इसका काफ़ी हिस्सा सुलझाया जा सकता है
    • local model बहुत से उपयोगों में सचमुच शानदार हैं, और मेरे हिसाब से ज़्यादातर लोगों को state-of-the-art model की ज़रूरत नहीं होती। छोटे 4070 12GB पर Qwen model को personal email agent में चलाते समय privacy सबसे महत्वपूर्ण होती है
      यह काफ़ी अच्छा काम करता है, और coding के कामों में भी, अगर आप इसे इस्तेमाल करना जानते हैं और कोई बहुत बड़ा plan एक साथ नहीं फेंकते, तो यह बढ़िया है
    • MTP बदलाव आने के बाद 350W पर सीमित 4090 में qwen3.6:27b पर 40~50 token/second मिल रहे हैं। ऊपरी सीमा के हिसाब से यह लगभग 8.75J/token है
      यह दूसरी चीज़ों की तुलना में कैसा है, पता नहीं, लेकिन उम्मीद है कि 5090 उसी power limit में ज़्यादा तेज़ होगा, इसलिए थोड़ा सस्ता भी पड़ेगा
    • यह सब मौजूदा hardware के आधार पर है। भविष्य के hardware का क्या? inference-optimized hardware का क्या? ऐसे hardware का क्या जो किसी खास model को चलाने के लिए optimized हो?

  • यह दिलचस्प था कि vLLM को llama.cpp से धीमा बताकर खारिज कर दिया गया
    मेरे अनुभव में vLLM, llama.cpp से काफ़ी तेज़ है, और खासकर concurrent load batching में तो बहुत आगे है। इसकी कमी यह है कि tuning flexibility बहुत कम हो जाती है। quantized weights चलाने के विकल्प बहुत कम हैं, और compute graph optimize करने की वजह से startup time भी काफ़ी लंबा हो जाता है। इसलिए अगर कोई एक उपयोगकर्ता अपने hardware से थोड़ा बड़ा model आज़मा रहा हो, तो vLLM परेशान करने वाला लग सकता है

    • इसे ऐसे कहा जा सकता है। vLLM, खराब Llama.cpp नहीं है, बल्कि एक अलग टूल है
    • vLLM continuous batching और production model serving के लिए शानदार है, लेकिन prosumer category में यह कहीं कम versatile, और बिल्कुल अलग चीज़ है
      “खारिज कर दिया” कहना थोड़ा सख़्त है, लेकिन थोड़ा विस्तार से कहूँ तो 2x 3090 setup पर load होने में 4 मिनट से ज़्यादा लगे, और single request में यह 3 token/second धीमा था
      सबसे बुरी बात यह थी कि setup और tuning की सारी मेहनत के बाद भी यह loop में फँसता रहा। इधर-उधर से जो “बस vLLM इस्तेमाल करो” वाली सलाह सुनता हूँ, चाहता था कि वह कोई universal solution निकले
      यहाँ एक सावधानी यह है कि लोगों को Ollama के साथ जैसा किया था, वैसा llama.cpp को घटिया बताना शुरू नहीं कर देना चाहिए। llama.cpp बहुत सक्षम टूल है, और जिस काम के लिए हम वास्तव में उस card का इस्तेमाल करना चाहते हैं, उसके लिए ज़्यादा उपयुक्त है
      अगर किसी बड़ी team को Claude subscription बदलना हो, तो vLLM शायद एकमात्र विकल्प हो सकता है, लेकिन GLM 5.2 जैसी चीज़ चलानी हो तो शायद RTX 6000 card के लगभग 5 और जोड़ने पड़ेंगे
    • जहाँ तक मुझे याद है, आम सहमति यही थी कि single user के लिए llama.cpp, और multi-user या enterprise के लिए vLLM। दोनों मिलते-जुलते हैं, लेकिन उपयोग अलग है
    • यह थोड़ा उलझाने वाला था कि कई users के model hit करने पर cache prefix टूटने की शिकायत की गई, फिर भी llama.cpp पर टिके रहे और vLLM पर नहीं गए

  • एक तरफ़ कहा गया कि “model बहुत गरम चल रहा है, इसलिए लक्ष्य पार करके loop में जा रहा है”, और बाद में कहा गया कि vLLM को latest experiment के रूप में set किया, लेकिन NVLink और tensor parallelism चालू होने के बाद भी generation, llama.cpp से 3 token/second धीमी थी
    मेरे सारे tests में vLLM चलाना फ़ायदेमंद रहा है। loop की समस्या, agent के अजीब हो जाने की समस्या, काम पर focus खोने की समस्या, और लंबे context के लगभग बेकार हो जाने की समस्या—इन सब में सबसे बड़ा असर डालने वाला एकल factor यही था
    vLLM में FP8 model और non-quantized cache इस्तेमाल करने पर overall experience किसी भी दूसरे stack से एक स्तर बेहतर हो जाता है। उसके बाद settings के साथ छेड़छाड़ बंद करके model को दूसरे कामों में इस्तेमाल करने पर ध्यान दिया जा सकता है

    • यह हिस्सा मुझे सचमुच जानने लायक लग रहा है। असहमति की वजह से नहीं, बल्कि agent के अजीब व्यवहार से बचना चाहता हूँ। जानना चाहता हूँ कि vLLM आप अकेले इस्तेमाल कर रहे हैं, team के लिए, या application के लिए
      और यह भी जानना चाहता हूँ कि क्या आपको लगता है कि vLLM के इस तरह उपयोगी होने के लिए कोई minimum hardware requirement है। मैं weekend project के तौर पर पुराने data center parts से home inference server बनाने वाला हूँ, और दिमाग में final configuration को लगातार refine कर रहा हूँ
    • यह जानने की जिज्ञासा है कि non-quantized cache को Q8 के बजाय क्यों इस्तेमाल करते हैं

  • जो लोग अपना AI hardware ख़रीदकर बनाना चाहते हैं, उन्हें मैं सलाह दूँगा कि पहले कुछ समय तक कई inference providers में से किसी एक से जुड़कर अलग-अलग model खुद इस्तेमाल करें
    इसकी लागत लगभग कुछ नहीं होती, लेकिन इससे यह काफ़ी अच्छा preview मिल जाता है कि अपने hardware से आप क्या हासिल कर सकते हैं। बस एक दोस्ताना सलाह है