- ऐप फीचर्स में OpenAI या Anthropic API जोड़ना आम हो गया है, लेकिन cloud-hosted AI models पर निर्भरता का मतलब है कि server outage या payment समस्या भर से फीचर बंद हो सकता है, और privacy का बोझ भी बढ़ता है
- आधुनिक devices में Neural Engine जैसी शक्तिशाली on-device compute क्षमता है, लेकिन ज़्यादातर समय वह बेकार पड़ी रहती है और सिस्टम सिर्फ server response का इंतज़ार करता रहता है
- उदाहरण के लिए, Apple के FoundationModels framework का उपयोग करके बिना server के सीधे device पर summarization, classification और extraction जैसी AI capabilities लागू की जा सकती हैं
- The Brutalist Report का native iOS client article summaries को Apple local model API से on-device generate करता है, जिससे server bypass हो जाता है और prompt·user logs, vendor account, या content retention footnote की ज़रूरत नहीं रहती
- local models cloud models जितने स्मार्ट न हों, फिर भी summarization, classification, extraction, rewriting, normalization जैसे data transformation कार्यों के लिए पर्याप्त हो सकते हैं, और cloud models का उपयोग केवल तब होना चाहिए जब सचमुच ज़रूरत हो
cloud AI पर निर्भरता की समस्याएँ
- developers के बीच app features में OpenAI या Anthropic API calls को बिना सोचे-समझे जोड़ने का ट्रेंड फैल रहा है
- यह तरीका software को नाज़ुक, privacy-भंग करने वाला और बुनियादी रूप से अस्थिर बना देता है
- server outage या credit card expiry होने पर app काम करना बंद कर देता है
- जैसे ही user content को third-party AI provider तक stream किया जाता है, product की प्रकृति ही बदल जाती है
- इसके साथ data retention, consent, audit, leakage, government requests, training data use जैसी समस्याएँ जुड़ जाती हैं
- इससे पूरा stack network condition, external vendor uptime, rate limit, account billing और अपने backend की स्थिति—सब पर निर्भर हो जाता है
- नतीजतन, एक साधारण UX feature cost-incurring distributed system में बदल जाता है
- जो काम local में हो सकता है, उसे बेवजह cloud में भेजना आत्मघाती फैसला है
local devices के उपयोग का औचित्य
- आज जेब में रखा device silicon, 10 साल पहले की तुलना में कहीं अधिक तेज़ है, और उसका dedicated Neural Engine ज़्यादातर समय निष्क्रिय पड़ा रहता है
- ऐसे में Virginia के server farm से JSON response का इंतज़ार करना अव्यावहारिक है
- लक्ष्य "AI everywhere" नहीं, बल्कि उपयोगी software होना चाहिए
- अगर कोई feature local में चल सकता है, तो external dependency चुनना अपने आप में अनावश्यक नुकसान है
The Brutalist Report का on-device summarization
- The Brutalist Report 1990s-style web से प्रेरित एक news aggregator service है
- हाल ही में native iOS client बनाते समय high-density news reading experience को बनाए रखना एक design goal था
- iOS client में strong-contrast headline list, web को पढ़ना मुश्किल बनाने वाले elements हटाने वाला reader mode, और चुनिंदा articles का summary दिखाने वाला “intelligence” view शामिल है
- सबसे अहम बात यह है कि summaries Apple के local model API के ज़रिए on-device generate होती हैं
- server bypass हो जाता है, और prompt या user logs, vendor account, या “content 30 दिनों तक रखा जाता है” जैसे footnotes की ज़रूरत नहीं पड़ती
- यह मान लेना बहुत सामान्य हो गया है कि AI का हर उपयोग server-side ही होगा, और इसे बदलने के लिए industry-level effort चाहिए
- कुछ use cases को cloud-hosted models द्वारा ही दी जा सकने वाली intelligence चाहिए, लेकिन हर use case ऐसा नहीं होता, इसलिए सावधानी से निर्णय लेना चाहिए
Apple ecosystem के local AI tools
- Apple ecosystem में पिछले एक साल के दौरान इस बात पर निवेश हुआ है कि developers built-in local AI models का आसानी से उपयोग कर सकें
- मूल flow यह है:
FoundationModels import करें, SystemLanguageModel.default की availability जाँचें, फिर LanguageModelSession से prompt बनाकर response लें
import FoundationModels
let model = SystemLanguageModel.default
guard model.availability == .available else { return }
let session = LanguageModelSession {
"""
Provide a brutalist, information-dense summary in Markdown format.
- Use **bold** for key concepts.
- Use bullet points for facts.
- No fluff. Just facts.
"""
}
let response = try await session.respond(options: .init(maximumResponseTokens: 1_000)) {
articleText
}
let markdown = response.content
- लंबे content के लिए plain text को लगभग 10,000 characters के chunks में बाँटकर, हर chunk से संक्षिप्त “facts only” notes बनाए जा सकते हैं, और फिर दूसरे pass में final summary जोड़ी जा सकती है
- इस तरह के काम local model के लिए बहुत उपयुक्त हैं
- input data वही content है जिसे user पहले से device पर पढ़ रहा है
- output हल्का है
- processing तेज़ और private है
- यह उस page का summary बनाना है जिसे user ने अभी खोला है, न कि दुनिया का नया ज्ञान गढ़ना; इसलिए अतिमानवीय स्तर की intelligence की ज़रूरत नहीं है
- local AI तब सबसे अधिक प्रभावी होता है जब model का काम पूरे ब्रह्मांड में खोज करना नहीं, बल्कि user के अपने data को transform करना हो
भरोसा बनाने का तरीका
- email summarization, notes से to-do extraction, document classification जैसे AI features वे चीज़ें हैं जिन्हें लोग चाहते तो हैं, लेकिन उन पर भरोसा नहीं कर पाते
- सामान्य cloud approach इन सबको इस सवाल में बदल देता है: “क्या data को server पर भेजना ठीक है?”
- local AI इस ढाँचे को बदल देता है, क्योंकि जो data पहले से device पर है, उसी पर वहीं processing होती है
- user trust 2,000 शब्दों की privacy policy से नहीं बनता
- भरोसा उस architecture से बनता है जिसमें ऐसी privacy policy की ज़रूरत ही न पड़े
structured output और type-based AI
- Apple की हाल की अच्छी पसंदों में से एक यह है कि उसने “AI output” को बिना संरचना वाले text blob से typed data की ओर शिफ्ट किया है
- “model से JSON माँगो और उम्मीद करो कि सही आए” वाले तरीके की जगह, इच्छित result को दर्शाने वाला Swift
struct define करना एक नया और बेहतर pattern है
- हर field के लिए natural-language guide दी जाती है, और model से उस type का instance generate कराया जाता है
import FoundationModels
@Generable
struct ArticleIntel {
@Guide(description: "One sentence. No hype.") var tldr: String
@Guide(description: "3–7 bullets. Facts only.") var bullets: [String]
@Guide(description: "Comma-separated keywords.") var keywords: [String]
}
let session = LanguageModelSession()
let response = try await session.respond(
to: "Extract structured notes from the article.",
generating: ArticleIntel.self
) {
articleText
}
let intel = response.content
- इस तरीके में UI को Markdown bullets को scrape करने या यह उम्मीद करने की ज़रूरत नहीं पड़ती कि model को JSON schema याद रहेगा
- app को वास्तविक fields वाला वास्तविक type मिलता है, जिसे वह लगातार एकसमान तरीके से render कर सकता है
- इससे structured output बनता है जिसे app वास्तव में उपयोग कर सकता है, और यह पूरी प्रक्रिया local में चलती है
- यह सिर्फ सुविधाजनक interface नहीं, बल्कि engineering quality में सुधार है
- यही वह अंतर है जो local-first apps में AI को “मज़ेदार feature” नहीं, बल्कि “विश्वसनीय subsystem” बनाता है
“local models कम स्मार्ट होते हैं” पर जवाब
- यह सही है कि local models cloud models जितने स्मार्ट नहीं होते, लेकिन ज़्यादातर app features के लिए यह बात लागू नहीं होती
- अधिकांश features को Shakespeare लिखने या quantum mechanics समझाने की नहीं, बल्कि summarization, classification, extraction, rewriting, normalization में से किसी एक काम को भरोसेमंद ढंग से करने की ज़रूरत होती है
- ऐसे कामों के लिए local models काफी अच्छे हैं
- अगर local models को पूरे internet के विकल्प की तरह उपयोग करेंगे तो निराशा होगी, लेकिन app के भीतर “data transformer” की तरह उपयोग करें तो सवाल उठता है कि इसे server पर भेजने की ज़रूरत ही क्या थी
- cloud models का उपयोग केवल तब करें जब वास्तव में ज़रूरत हो, और user data को वहीं रहने दें जहाँ वह है
- AI का उपयोग chat box जोड़ने के रूप में नहीं, बल्कि typed output और predictable behavior वाले वास्तविक subsystem की तरह होना चाहिए
privacy और trust का निर्माण
- email summarization, notes से action items extraction, document classification जैसी कई AI features ऐसी हैं जिन्हें लोग चाहते हैं, लेकिन उन पर भरोसा नहीं करते
- cloud approach इन्हें trust experiment में बदल देता है: “कृपया अपना data server पर भेजिए, हम उसे ठीक से संभालेंगे”
- local AI इसे बुनियादी रूप से बदल देता है — data पहले से device पर है, और processing भी वहीं तुरंत होती है
- भरोसा 2,000 शब्दों की privacy policy लिखने से नहीं, बल्कि ऐसी policy की ज़रूरत ही न पड़े ऐसी संरचना बनाने से बनता है
1 टिप्पणियां
Hacker News की राय
मुख्यधारा के यूज़र्स आज local AI को लगभग उसी नज़र से देखते हैं, जैसे कुछ दशक पहले open source को देखते थे
कुछ प्रोडक्ट्स में paid solutions बहुत आगे थे, इसलिए open source को अक्सर पूरी तरह नज़रअंदाज़ किया जाता था, और माहौल कुछ ऐसा था: “आख़िर इसकी ज़रूरत ही क्या है?”
फिर dependency बढ़ाने वाले SaaS और platforms आए, और अब यह काफ़ी साफ़ है कि वह आकलन ज़्यादातर ग़लत था
coding में Anthropic और OpenAI पर निर्भरता बेतुकी हद तक ज़्यादा है, लेकिन बहुत से लोग या तो इसकी परवाह नहीं करते, या बस उम्मीद करते हैं कि चीन open weights देना बंद न करे
open weights का business model बहुत नया है, इसमें देशों और research labs के बीच शक्ति-संघर्ष भी मिला हुआ है, और बिना किसी ठोस सार्वजनिक निगरानी के बेहिसाब पैसा घूम रहा है
अभी बहुत बड़ा value लगभग सभी के लिए खुला हुआ है, लेकिन यह एक ख़तरनाक दांव है जो हमारे नियंत्रण से बाहर किसी वजह से बिना चेतावनी के रुक सकता है
95% use cases के लिए वे काफ़ी हैं, और उनकी कोई expiry date भी नहीं है
“risk” बस इतना है कि आप अगली पीढ़ी के models नहीं चला पाएंगे, और उसका असर काफ़ी कम लगता है
ज़्यादा से ज़्यादा यह और महंगे models बेचने के लिए advertising की तरह काम करता है
open source से बड़ा फ़र्क यह है कि सिर्फ़ खाली समय और इच्छाशक्ति से LLM train नहीं किया जा सकता
इसके लिए बहुत सारा data और भारी compute resources चाहिए
इस मामले में मैं ग़लत साबित होना चाहूँगा, और भविष्य open weights की तरफ़ जाए तो वह मुझे कहीं ज़्यादा पसंद होगा
local AI को एक अलग product की तरह देखना चाहिए, और जो काम सच में cloud AI के बिना हो सकते हैं उन्हें local पर करके, cloud AI को fallback की तरह इस्तेमाल किया जाए, तो ख़र्च बहुत कम हो सकता है
चूँकि वह tax money से बनेगा, इसलिए आख़िरकार उसके open source होने की संभावना है, और NSA के पास दशकों का internet data है, तो अगर उसी पर training हो, तो open weights किसी कंपनी के model जितने अच्छे हो सकते हैं
photo background removal या PDF OCR जैसे काम देखें, तो रोज़मर्रा के उपयोग के लिए ऐसे कामों पर paid services इस्तेमाल करने वाले लोग लगभग नहीं के बराबर हैं
वह पल आएगा, और इतना दूर भी नहीं है
रुझान पहले ही साफ़ है। शुरुआत में अच्छे performance वाले LLM सिर्फ़ बड़े datacenters में चल सकते थे, अब हम साफ़ तौर पर कुछ H100 cards लगे कई servers वाले स्तर तक आ चुके हैं, और धीरे-धीरे “MacBook Pro या Strix Halo में 128GB VRAM” वाली दिशा में बढ़ रहे हैं
अगले 1 साल के भीतर कंपनियों में “planning महंगे remote LLM से, execution local लेकिन इंसान से तेज़ LLM से” वाला pattern standard बन जाएगा, और फिर धीरे-धीरे “सब कुछ local LLM से ही काफ़ी है” की तरफ़ बढ़ेगा
आख़िरकार वही संतुलन बनेगा जो मौजूदा cloud में है: या तो ख़ुद host करो, या flexibility और speed के लिए पैसे दो
सवाल यह है कि local hosting मौजूदा compute resource overheating को कितनी हद तक ख़त्म करेगी, और उसका market पर क्या असर होगा
मैं 3 साल पुराने ठीक-ठाक gaming PC, लगभग RTX 3080 12GB और 32GB RAM पर quantized Qwen और Gemma चला रहा हूँ
यह धीमे हैं और context window भी छोटी है, लेकिन सही runtime environment के साथ ये travel photos छाँटकर classify कर सकते हैं
receipts पर OCR कर सकते हैं, expenses summarize कर सकते हैं, आसान सवालों का जवाब दे सकते हैं, code analyze कर सकते हैं, और जहाँ कम context चाहिए वहाँ code भी लिख सकते हैं
अगर VS Code integration पर थोड़ा ध्यान दिया जाए, तो ठीक-ठाक autocomplete भी बनाया जा सकता है
मेरी नज़र में “MacBook Pro या Strix Halo में 128GB VRAM” agent-style coding के लिए minimum viable setup है
हालाँकि अभी स्थिति उलटी है। cloud versions self-hosting की तुलना में कई orders of magnitude सस्ते हैं, क्योंकि sharing के ज़रिए server utilization बहुत अधिक किया जा सकता है
अगर कोई कंपनी GLM 5.1 चलाने वाले hardware पर 5 लाख डॉलर ख़र्च करती है, तो उसे data security, flexibility और no censorship तो मिलेगी, लेकिन Anthropic की seat-based pricing की तुलना में यह बहुत महंगा पड़ेगा
ठीक कुछ पंक्तियाँ नीचे वाले पोस्ट में लोग इस बात पर हंगामा कर रहे थे कि Chrome ने local inference के लिए कुछ GB space लेने वाला local LLM model जोड़ दिया
यानी करो तो भी बुरा, न करो तो भी बुरा
कुछ समय पहले image generation से खेलने के लिए मैंने ऐसा ही किया था
लोग local model install होने पर नहीं, बल्कि user autonomy की कमी पर नाराज़ हैं
चुपचाप install मत करो; बस विकल्प दे दो कि model डाउनलोड करना है या नहीं
यह कोई मुश्किल काम नहीं है, और बाकी सभी local options ऐसे ही काम करते हैं
अगर यह opt-in नहीं है, या browser में जबरन ठूँस दिया गया है, तो यह बेकार है
किसी app को local LLM चलाने के लिए ज़रूरी data डाउनलोड करते देख कोई नाराज़ नहीं होता
यह comment बहस की प्रकृति को काफ़ी बेईमानी से पेश कर रहा है
मेरा मानना है कि private AI पर बहस और local AI पर बहस को अलग रखना चाहिए
बड़े LLM चलाने के लिए व्यावहारिक विकल्प online बड़े servers, एक या कई, ही हैं; लेकिन इसका मतलब यह नहीं कि उन्हें सिर्फ़ private companies ही चलाएँ
privacy के लिए एक विकल्प ऐसा self-hosted inference solution हो सकता है जो tenant isolation की मज़बूत guarantees दे, आदर्श रूप से zero-trust दे, और deployment व maintenance इतना आसान हो कि वह AI के लिए Plex जैसा लगे
सच कहूँ तो मैंने इस हिस्से पर बिल्कुल research नहीं की है, इसलिए यह कितना संभव है, पता नहीं। शायद यह पहले से मौजूद हो और कोई Discord server हो जिसमें मुझे शामिल होना चाहिए
और हाँ, यह यहाँ अलग से कहने की ज़रूरत भी नहीं होनी चाहिए, लेकिन हैरानी की बात यह है कि open models सबसे अच्छे commercial models के क़रीब पहुँच गए हैं, इसलिए सबसे मुश्किल हिस्सा काफ़ी हद तक पहले ही हल हो चुका है
इसमें NVIDIA confidential computing का उपयोग होता है, enclave code open source होता है, और connect करते समय remote attestation के ज़रिए verify किया जाता है कि inference provider cryptographically यह साबित कर सके कि वह आपका data नहीं देख सकता
Tinfoil: https://tinfoil.sh/ इसका एक अच्छा उदाहरण है। disclosure के तौर पर कहूँ तो मैं इसका co-founder हूँ
यह कैसे काम करता है, यहाँ और पढ़ सकते हैं: https://docs.tinfoil.sh/verification/verification-in-tinfoil
यह कहना कि open models सबसे अच्छे commercial models के क़रीब पहुँच गए हैं, कुछ ख़ास tasks में काफ़ी हद तक सही है
उदाहरण के लिए, chat interfaces में model intelligence की एक सीमा के बाद उसका लाभ उठाना मुश्किल हो जाता है, और सबसे अच्छे open source models उस स्तर तक पहले ही पहुँच चुके हैं
लेकिन coding environments अब भी अधिक model intelligence से फ़ायदा उठाते हैं, ख़ासकर जब provider का coding runtime environment और model का tool-calling interface, जैसे claude-code या codex में, reinforcement learning के ज़रिए काफ़ी क़रीब से जुड़े हों; इसलिए model intelligence को अलग रख देने पर भी performance gap रह सकता है
कई model providers को support करने वाले open source coding environment opencode के founder ने भी हाल में provider-specific tuning की कठिनाई पर बात की थी: https://x.com/thdxr/status/2053290393727324313
इस लेख के examples मेरे उस विचार की पुष्टि करते हैं कि local models को सफल होने के लिए frontier models जितना बड़ा होने की ज़रूरत नहीं, बस काफ़ी अच्छा होना चाहिए
इन्हें छोटे tasks अच्छी तरह करने चाहिए, और consumer devices पर उचित ढंग से चलना चाहिए
अगर phones पर भी चल जाएँ तो और अच्छा
local LLMs के साथ प्रयोग करते हुए मुझे लगा कि model size बढ़ाना अच्छा है, लेकिन लगभग बेकार model को उपयोगी बनाने वाली असली चीज़ tools इस्तेमाल करने की क्षमता थी
जब मैंने web search और webpage fetching की अनुमति दी, तो इससे hallucination कम करने में बड़े model का उपयोग करने से कहीं अधिक मदद मिली, और training cutoff date की समस्या भी नहीं रही
बेशक बड़े models tools को बेहतर इस्तेमाल कर सकते हैं, लेकिन कई बार छोटे models भी काफ़ी होते हैं
मैंने Chrome की नई Prompt API के साथ demo बनाया है कि local model क्या कर सकता है: https://adsm.dev/posts/prompt-api/#what-could-you-build-with...
मूल लेख की तरह, यह user-owned data को transform करने वाले सीमित environment में सबसे अच्छा चमकता है
ज़्यादा खुले-ended tasks में यह निश्चित रूप से कम उपयोगी है
यह ठीक है, लेकिन सच में काफ़ी कमज़ोर है
1 साल पहले के 8B models कुछ मामलों में इससे बेहतर थे, और हाल के models तो अर्थपूर्ण रूप से इससे आगे निकल चुके हैं
local model भी चाहिए और webpage भी चाहिए
बाक़ी सब लोग electricity और hardware degradation की लागत उठाएँ, और vendor को मिले और ज़्यादा, और बेहतर, और सस्ती ad-tech exploitation और surveillance
क्या कमाल है
मौजूदा हितधारक local को रोकने के लिए हर संभव कोशिश करेंगे, लेकिन कुछ तकनीकी कारण ऐसे हैं जिनकी वजह से माना जा सकता है कि छोटे और specialized models आख़िरकार standard बन सकते हैं
अगर ऐसा हुआ, तो local भी साथ आएगा
मूल लेख इस बात पर केंद्रित है कि यूज़र जो चाहते हैं, उसके लिए क्या बड़े model की सचमुच ज़रूरत है
लेकिन यह तर्क भी है कि बड़े models शायद a) mechanistic interpretability के पर्याप्त परिपक्व होने तक, या b) multi-agent systems पूरी तरह multi-model होने तक, कभी सच में पर्याप्त भरोसेमंद नहीं होंगे
a के मामले में mechanistic interpretability की प्रगति बड़े models की समस्याएँ ठीक भी कर सकती है, लेकिन साथ ही integrated representations लेकर विशाल model के सिर्फ़ उपयोगी हिस्सों को काटकर इस्तेमाल करना भी संभव बना सकती है
यानी जो चाहिए वही लो, अनावश्यक हिस्सा फेंक दो, और cost व problem surface दोनों कम करो
सिर्फ़ logic चाहिए? सिर्फ़ vision चाहिए? उस विशाल दानव से वही हिस्सा काटकर इस्तेमाल कर लो
problems को isolate करने की क्षमता, functional subsystems को isolate करने की क्षमता के बिना आना मुश्किल है
b के मामले में evil vectors या tool use के लिए विशेष hallucination categories को देखिए
अगर helpful/honest/harmless alignment का कोई पूर्ण समाधान नहीं है, तो creativity और rigor, और कई अन्य गुण, बुनियादी तौर पर आपस में टकरा सकते हैं
और अगर वैसे भी हर काम के लिए कई models चाहिए होंगे, तो फिर महंगे और विशाल general-purpose model की ज़रूरत ही क्या है
इसलिए specialization भी सब कुछ कम-से-कम भरोसेमंद expert models तक समेटने का दबाव बनाती है
LLMs को लेकर मेरी बुनियादी चिंता, दार्शनिक पहलू और आर्थिक प्रभावों से अलग, यह है कि local स्तर पर functional models को train करना मुश्किल दिखता है
toy LLMs बन सकते हैं, लेकिन सच में उपयोगी चीज़ें मुश्किल लगती हैं
न सिर्फ़ बहुत भारी compute चाहिए, बल्कि ज़्यादातर मामलों में ग़ैरक़ानूनी तरीक़े से जुटाए गए datasets भी चाहिए
मैं व्यक्तिगत रूप से शायद कोई असाधारण बुद्धिमत्ता नहीं हूँ, लेकिन अपनी मौजूदा बुद्धि तक पहुँचने के लिए मुझे अब तक लिखी गई सारी किताबें, Wikipedia के सारे लेख, सारे blog posts, सारे reference manuals, या code की हर पंक्ति नहीं पढ़नी पड़ी
सच तो यह है कि मैंने उसका 1% तो दूर, 0.00000000001% भी नहीं देखा
यह काफ़ी स्पष्ट है कि text ख़ुद intelligence की अनिवार्य शर्त नहीं है
कम-से-कम अगर मैं सिर्फ़ 20 साल तक अपने आस-पास की दुनिया को ढीले तौर पर observe करके intelligence जैसी चीज़ तक पहुँचा हूँ, तो यह एक मज़बूत संकेत है कि ज़रूरी “dataset” सिर्फ़ sensors और आसपास की दुनिया ही हो सकती है
बेशक मानव मस्तिष्क शून्य से शुरू नहीं होता; उस ज़मीन को तैयार करने में, जिसमें intelligence जड़ पकड़ सके, लाखों साल का evolution लगा है
लेकिन वह बुनियादी संरचना काफ़ी सामान्य लगती है, किसी ख़ास training set पर निर्भर नहीं
शायद इसे कृत्रिम रूप से evolve करना भी संभव हो
अगर base model मेरी भाषा को support करता हो, तो मेरे पास मौजूद electronic devices की spare compute capacity से हर महीने कुछ LoRA train करने की अच्छी संभावना है
भविष्य में जब सामान्य home computers आज के servers जैसी क्षमता रखेंगे, तो घर पर पूरे LLM भी train किए जा सकेंगे
उसे किससे train किया गया, training data को कैसे label किया गया, कौन-से guardrails हैं, या उसमें कौन-से biases हो सकते हैं — इनमें से किसी पर भी मेरा कोई नियंत्रण नहीं होता
बाकी सब चीज़ों की तरह यहाँ भी बड़े LLM निर्माता होंगे, छोटे LLM निर्माता होंगे, artisan-style LLM makers होंगे, LLM hobbyists होंगे, और LLM consumers होंगे
काफ़ी ऐसे use cases हैं जहाँ personal या non-commercial use के लिए ज़रूरी training data हासिल किया जा सकता है
उसके बाद सवाल training के लिए चाहिए compute और समय का रह जाता है; अगर आप इंतज़ार करने को तैयार हैं, तो consumer hardware से भी उपयोगी models बनाए जा सकते हैं
“cloud models सिर्फ़ तब इस्तेमाल करो जब सच में ज़रूरत हो” — यह बात सही है, लेकिन दिक्कत यह है कि local models की settings ठीक करने में समय लगाने से कहीं आसान subsidized state-of-the-art models का इस्तेमाल करना है
coding agents में मुझे अभी-अभी इसका एहसास हुआ
ज़रूरी नहीं कि हमेशा latest version को xhigh पर चलाया जाए, लेकिन आख़िरकार ऐसा हो ही जाता है
क्योंकि कम समय, कम मेहनत, और लगभग उसी कीमत में काम पूरा हो जाता है
मुझे लगता है कि local AI पर गंभीर प्रयास तभी दिखेंगे जब बड़े vendors actual token usage के हिसाब से billing शुरू करेंगे
मैंने free-tier provider tabs के लगभग 8 पेज खोल रखे हैं, और ChatGPT, Claude, Gemini frontier पर हैं
एक की limit ख़त्म होने पर अगले पर जाना मेरे लिए कोई समस्या नहीं है
मैं पूरे दिन ऐसा करके अपने code की किसी specific function या class को implement करवा सकता हूँ
चूँकि मुझे सच में software लिखना और design करना आता है, इसलिए मुझे एजेंट को बार-बार loop में चलाकर एक ही दिन में सब कुछ बनवाने की ज़रूरत नहीं
सिर्फ़ web chatbot और copy/paste से भी मैं प्रति घंटे हज़ारों lines of code generate कर सकता हूँ, जबकि code का मज़बूत mental model बनाए रखता हूँ और जहाँ ज़रूरत हो ख़ुद बदलाव भी करता हूँ
आज सुबह भी मैंने एक Python project में यही किया
क्योंकि जो चाहिए था वह मैंने ख़ुद design किया था, इसलिए हर generation एक single function के लिए request थी, और जब सुबह मुझे कुछ जोड़ना पड़ा, तो chatbot से पूछने के बजाय मैं सीधे सही जगह गया और ख़ुद ठीक कर दिया
अगर आप spec से पूरा system generate कराते हैं, तो ऐसा नहीं कर सकते
ख़ासकर तब, जब pricing असली लागत को छिपा रही हो
हर बार जब LLM पर कोई पोस्ट आती है, comments में बहुत लोग ज़ोर देकर कहते हैं कि नवीनतम DeepSeek/Qwen वगैरह से Opus जितने अच्छे नतीजे मिल रहे हैं, लेकिन मेरा अनुभव बिल्कुल ऐसा नहीं है
open source models को जैसे ही थोड़ा भी जटिल काम दिया जाए, वे Claude की तुलना में पूरी तरह बिखर जाते हैं
मुझे शक होता है कि कहीं यह 90s वाले Linux जैसा मामला तो नहीं
कुछ हद तक काम करता था, लेकिन home users के लिए बिल्कुल तैयार नहीं था, और फिर भी काफ़ी लोग मुख्यतः वैचारिक कारणों से सामने से कहते रहते थे कि सब ठीक है
लोग सच में “सबसे बेहतरीन software” बनाने की कोशिश कर रहे हैं
AI के Don Quixote-जैसे accelerationists, software बनाने वालों में बस शोर मचाने वाला छोटा-सा हिस्सा हैं, और online API को local system पर चुनना आम तौर पर developer की आलस नहीं, बल्कि user के पक्ष में लिया गया फ़ैसला है
अभी private AI के साथ local models की तुलना में ज़्यादा काम बेहतर ढंग से किया जा सकता है
इससे बचा नहीं जा सकता
local AI बेहतर हो जाने पर भी, LLM performance के frontier पर बने रहना अक्सर निवेश के लायक होता है
ज़्यादातर लोग किसी product को तब तक स्वीकार नहीं करते जब तक वह top-tier न हो और बेहद सुविधाजनक न हो
वह मानक ऊँचा है, और local AI अक्सर उस पर खरा नहीं उतरता
HN का यह ज़िद्दी रवैया कि हर user को open source, privacy-first, self-hosted Linux fanatic मान लिया जाए, देखने में तकलीफ़देह रूप से पुराना लगता है