6 पॉइंट द्वारा GN⁺ 2025-07-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल की MIT Technology Review की एक रिपोर्ट में लोकल LLM की तुलना ऑफलाइन बैकअप Wikipedia से करने का विचार पेश किया गया
  • Ollama लाइब्रेरी के मुख्य LLM मॉडल फ़ाइल साइज़ और Kiwix द्वारा दिए गए ऑफलाइन Wikipedia बंडल के आकार की सीधे तुलना की गई
  • LLM फ़ाइलें और Wikipedia डेटा का उद्देश्य, ताकत और सीमाएँ अलग हैं, इसलिए सीधी तुलना आसान नहीं है, लेकिन स्टोरेज क्षमता के आधार पर दिलचस्प अंतर दिखते हैं
  • कुछ LLM (1~4GB मॉडल) साधारण English Wikipedia (लगभग 1GB) से बड़े हैं, जबकि पूरी Wikipedia (57GB) बड़े LLM (20~32GB) से भी बड़ी है
  • फ़ाइल साइज़ के अलावा मेमोरी और CPU आवश्यकताओं जैसी व्यावहारिक बातों पर भी ध्यान देना ज़रूरी है, और वास्तविक उपयोग के आधार पर चुनाव बदल सकता है

लोकल LLM और ऑफलाइन Wikipedia की तुलना

परिचय और तुलना का संदर्भ

  • MIT Technology Review में हाल ही में "How to run an LLM on your laptop" शीर्षक से एक लेख प्रकाशित हुआ
  • लेख में इस बात पर ज़ोर दिया गया कि लोकल में LLM चलाकर ऑफलाइन माहौल में भी ज्ञान का उपयोग संभव है
  • Simon Willison की यह तुलना प्रभावशाली है कि ऑफलाइन LLM Wikipedia के संक्षिप्त, अधूरे संस्करण जैसा है, और प्रलय जैसी स्थिति में सिर्फ USB के सहारे समाज को फिर से शुरू करने में मदद कर सकता है

मॉडल और डेटा साइज़ की तुलना

  • Ollama लाइब्रेरी के कई LLM मॉडल और Kiwix द्वारा उपलब्ध ऑफलाइन Wikipedia बंडल फ़ाइल साइज़ की तुलना की गई
  • तुलना के लिए ऐसे मॉडल चुने गए जिन्हें सामान्य उपभोक्ता हार्डवेयर पर चलाया जा सके, और Wikipedia डेटा को बिना इमेज वाले संस्करण तक सीमित रखा गया
  • मुख्य तुलना परिणाम इस प्रकार हैं:
    • सबसे छोटे सार-संक्षेप संस्करण
      • Best of Wikipedia (शीर्ष 50,000, सार-संक्षेप): 356.9MB
      • Simple English Wikipedia (सार-संक्षेप): 417.5MB
    • प्रमुख LLM मॉडल (छोटे)
      • Qwen 3 0.6B: 523MB
      • Deepseek-R1 1.5B: 1.1GB
      • Llama 3.2 1B: 1.3GB
    • प्रमुख LLM मॉडल (मध्यम से बड़े)
      • Deepseek-R1 8B / Qwen 3 8B: 5.2GB
      • Gemma3n e4B: 7.5GB
      • Deepseek-R1 14B: 9GB
      • Qwen 3 14B: 9.3GB
    • पूरी Wikipedia
      • Wikipedia (पूर्ण): 57.18GB
  • Wikipedia के शीर्ष 50,000 लेख 356.9MB के साथ बहुत छोटे हैं
  • सबसे छोटा LLM (0.6B, Qwen) 523MB का है, जो साधारण Wikipedia सार-संक्षेप से बड़ा है
  • पूरी Wikipedia (57.18GB), सबसे बड़े LLM (20GB) से भी काफी बड़ी है

तुलना की सीमाएँ और विचारणीय बातें

  • सीधी तुलना कठिन है: विश्वकोश (डेटा) और LLM (जनरेटिव मॉडल) का उद्देश्य और संरचना मूल रूप से अलग हैं
  • सिर्फ फ़ाइल साइज़ ही महत्वपूर्ण नहीं है: LLM को फ़ाइल साइज़ के अलावा चलते समय अधिक मेमोरी और CPU संसाधन चाहिए होते हैं। ऑफलाइन Wikipedia को कम-क्षमता वाले डिवाइस पर चलाना अपेक्षाकृत आसान है
  • वास्तविक उपयोग के हिसाब से उपयोगिता: उदाहरण के लिए, सिर्फ chemistry क्षेत्र डाउनलोड किया जा सकता है, या किसी खास हार्डवेयर के लिए ऑप्टिमाइज़ किया गया LLM चुना जा सकता है
  • चयन मानदंड की व्यक्तिपरकता: तुलना में इस्तेमाल की गई वस्तुओं का चयन कुछ हद तक व्यक्तिपरक है

निष्कर्ष और संकेत

  • Wikipedia के शीर्ष 50,000 लेख और Llama 3.2 3B मॉडल फ़ाइल साइज़ के लिहाज़ से लगभग समान स्तर पर हैं
  • सबसे छोटा Wikipedia बंडल सबसे छोटे LLM से भी छोटा है, जबकि पूरी Wikipedia फ़ाइल सबसे बड़े LLM से बड़ी है
  • पर्याप्त स्टोरेज वाले माहौल में LLM और Wikipedia डेटा दोनों को डाउनलोड करके साथ में उपयोग करना भी विचार करने योग्य है

1 टिप्पणियां

 
GN⁺ 2025-07-21
Hacker News राय
  • LLM की ताकत सिर्फ ज्ञान को स्टोर करने या खोजने में नहीं, बल्कि समझ में है; यह Wikipedia जैसे साधारण डेटा की तरह नहीं, बल्कि अस्पष्ट या गलत सवालों को भी समझकर उपयोगकर्ता के स्तर के हिसाब से समझाता है और अलग-अलग क्षेत्रों को जोड़ता है; अगर समाज को फिर से शुरू करने जैसी स्थिति हो, तो इस तरह की इंटरैक्टिव समझ ज़्यादा मूल्यवान हो सकती है; यह सिर्फ ज्ञान का स्नैपशॉट नहीं, बल्कि ऐसा टूल बन सकता है जिससे लोग उसे उपयोग कर सकें और सीख सकें
    • जानकारी-पूर्व समाज में किसी अविश्वसनीय कंप्यूटर को देवता की तरह पूजना, Star Trek के एक एपिसोड की याद दिलाता है
    • LLM “ज़्यादा” मूल्यवान है या नहीं, पता नहीं, लेकिन यह निश्चित रूप से उपयोगी है; AI का मौजूदा इस्तेमाल मुझे खास पसंद नहीं; मूल रूप से यह एक उन्नत autocomplete जैसा लगता है; फिर भी search engine के रूप में यह बेहतरीन काम करता है; Copilot से छोटा सवाल पूछो तो अक्सर ठीक-ठाक जवाब मिल जाता है; लेकिन बहुत गहरे technical सवाल पूछो तो यह बहुत बकवास भी करता है; हमेशा सतर्क रहना पड़ता है; मैंने एक बार CentOS repository file बनाने को कहा था, उसने लगभग सब सही किया, लेकिन gpgkey को http पर सेट कर दिया, जिससे security टूट गई
    • आदर्श रूप से, किसी और के summary पर निर्भर होने के बजाय मूल स्रोतों को खुद आलोचनात्मक तरीके से पढ़ना चाहिए; स्कूल में हम सब यह सीखते हैं और सहमत भी होते हैं, लेकिन व्यवहार में बहुत कम लोग ऐसा करते हैं; graduation के बाद लोग अक्सर सिर्फ tertiary sources पर भरोसा करने लगते हैं; मैंने LLM की मदद से किसी विषय में हाल की historiography trends और उपयोगी references खोजे हैं; दूसरी ओर, Wikipedia editors के ऐसे कई मामले देखे हैं जहाँ वे Wikipedia की अशुद्धियों की ओर इशारा करने पर रक्षात्मक या शत्रुतापूर्ण हो जाते हैं, और वास्तव में references चेक किए बिना भटकाने वाली सामग्री मिलने का अनुभव भी बहुत हुआ है
    • यह इस धारणा पर आधारित है कि कंप्यूटर या smartphone बचे रहेंगे; Wikipedia या कुछ किताबें print करके रखना एक सुरक्षित backup हो सकता है; लेकिन अगर सच में समाज reboot होता है, तो पूरी तरह अलग तरह से फिर से शुरू करने का भी कुछ अर्थ हो सकता है
    • मुझे लगता है कि offline Wikipedia, दूसरे सूचना स्रोत, और local LLM का संयोजन सबसे अच्छा है; अगर LLM संक्षेप में जवाब दे और संबंधित links भी दे, तो और अच्छा; search feature वाले LLM अक्सर बहुत लंबा समझाते हैं, जबकि ज़्यादा links देकर मनचाही जानकारी तक पहुँचने देना बेहतर है
  • “एक USB stick से समाज को reboot करना” इंटरव्यू के दौरान यूँ ही कही गई बात थी, मुझे नहीं लगा था कि यह लेख में आ जाएगी लेख लिंक; कई लोगों ने कहा कि USB में Wikipedia रखना ज़्यादा तर्कसंगत है, और मैं सहमत हूँ; Wikipedia dump MySQL में है, इसलिए उसे SQLite में बदलकर FTS इस्तेमाल करना ज़्यादा सुविधाजनक लग सकता है; 1TB से बड़े USB भी आसानी से मिल जाते हैं, इसलिए storage की चिंता लगभग नहीं है
    • कोई न कोई ऐसी कंपनी शुरू कर सकता है जो इस तरह पहले से लोड की गई USB sticks बेचे; अगर उसमें electromagnetic shock protection वाला box भी हो तो असली disaster की स्थिति में बहुत मदद मिल सकती है; मुझे लगता है कि सबसे अधिक संरक्षण-मूल्य वाली चीज़ बड़े पैमाने की disaster risk से जुड़ी जानकारी है; copyright की वजह से ‘Global Catastrophic Risks’ जैसी किताबें नहीं रखी जा सकतीं, लेकिन संबंधित वेबपेज जैसी चीज़ें शायद crawl की जा सकती हैं
    • मैं 10 साल से भी ज़्यादा समय से mobile phone या PDA में local Wikipedia dump लेकर चल रहा हूँ (पिछले 5 साल से तस्वीरों सहित); यह सिर्फ disaster preparedness के लिए नहीं, offline उपयोग में भी अक्सर मददगार रहा है; हाल में LLM जैसे models सचमुच उपयोगी हो गए हैं, इसलिए RAG फ़ॉर्मैट में local model और Wikipedia को जोड़ने पर synergy मिलने की उम्मीद है
    • एक पुरानी टिप्पणी फिर से उद्धृत कर रहा हूँ: सभी digitized books लगभग 30TB हैं, और compress करने पर लगभग 5.5TB; यह 2TB microSD card के 3 कार्डों में आ जाएगा; लगभग 750 डॉलर में सब कुछ portable बनाया जा सकता है
    • SQL की ज़रूरत नहीं, बस Kiwix इस्तेमाल कर लो
    • लेख का शुरुआत से ही इतना भव्य होना थोड़ा खटकता है; लगता है पत्रकार हमेशा tools को ज़रूरत से ज़्यादा महान बनाकर पेश करते हैं; अजीब सा एहसास होता है
  • मैं अभी wikipedia_en_all_maxi_2024-01.zim डाउनलोड कर रहा हूँ; libzim से pages निकालकर उसे LLM से जोड़ने की योजना है; zim file में pages HTML के रूप में stored हैं और इसका आकार लगभग 100GB है; वजह यह है कि HDD में बहुत बड़ी संख्या में stored games की सूची है (सिर्फ titles, अलग category नहीं), और मैं उन्हें Wikipedia articles से match करके genre या अन्य जानकारी के हिसाब से व्यवस्थित करना चाहता हूँ; प्रयोग में देखा कि LLM (Mistral Small 3.2 quantized) हैरानी की बात है कि इस chaos को काफ़ी अच्छी तरह व्यवस्थित कर देता है; llama.cpp से custom script में इसे तेज़ी से चलाया जा सकता है
    • सच कहूँ तो इस तरह का game-Wiki linking काम Wikidata query से कहीं आसान है; इसमें वे games भी शामिल हो सकते हैं जो अभी English Wiki में नहीं हैं
    • ऐसे तकनीकी अनुभव ही असल वजह हैं कि मैं HN पढ़ता हूँ; कोई व्यक्ति अपनी सोच-समझ से बनाया हुआ कुछ पर्याप्त detail के साथ साझा करे, तो वह ताज़गी भरा लगता है; मैं भी खुद LLM बनाने की कोशिश कर रहा हूँ, और इतना उपयोगी use case पहली बार देखा है, इसलिए लगता है और सीखना चाहिए; अच्छी जानकारी के लिए आभारी हूँ
  • Wikipedia, arXiv dumps, और open source code में executable code और अपेक्षाकृत विश्वसनीय जानकारी का बड़ा हिस्सा होता है, और ये सस्ते व खोजने में आसान हैं; FOSS apps सीधे इस्तेमाल किए जा सकते हैं, और Wiki विषय का परिचय या सार दे देती है; दूसरी तरफ LLM, खासकर छोटे models, चीज़ें गढ़ लेते हैं, लेकिन वे असाफ-सुथरे सवालों का जवाब देने की कोशिश करते हैं और (कभी-कभी) विशाल मूल सामग्री में से खुद पढ़कर सार भी निकाल सकते हैं; offline कामकाजी स्थिति में मुझे लगता है कि मौजूद libraries का अधिकतम उपयोग करना बेहतर है, और coding assistant के रूप में LLM के कुछ वास्तविक उपयोग के उदाहरण भी सूझते हैं; हालांकि local model इस्तेमाल करने का मेरा निजी अनुभव नहीं है, benchmark में Qwen3 32B को coding help के लिए ठीक बताया गया है, इसलिए कभी न कभी यह उपयोगी हो सकता है
  • LLM की कम चर्चा की गई ताकतों में से एक है भाषा-स्वतंत्र ज्ञान उपयोग; English Wiki में ज़्यादातर सामग्री अच्छी होती है, लेकिन दूसरी भाषाओं में नहीं; कभी ऐसी जानकारी भी दूसरी भाषा की Wiki में मिल जाती है जो English Wiki में नहीं होती; LLM इन सबको एक साथ जोड़कर कई भाषाओं में पहुँच योग्य बना सकता है
  • AI कंपनियों ने पूरे web को LLM में distill करके एक smart computer बना दिया, तो फिर इंसान copyright वाली चीज़ों तक को शामिल करके एक नई सर्वोत्तम Wikipedia क्यों नहीं बना सकते? समझ नहीं आता कि बच्चे AI कंपनियों से कम सक्षम क्यों हैं कि ऐसा नहीं कर पाते
    • हम वास्तव में यही काम करते आए हैं; बस आजकल encyclopedia अच्छी नहीं बिकती
    • वही तो library है
  • मैं Wikipedia Monthly का ज़िक्र करना चाहता हूँ, जो Wikipedia का monthly dump है; 341 भाषाओं का कुल 205GB, और सिर्फ English 24GB है; इसे MediaWiki markup से clean text में बदला गया है, इसलिए local search indexing या कई तरह के उपयोग के लिए अच्छा है; मुझे लगता है कि Simple English Wikipedia की सामग्री उथली और बहुत सटीक नहीं है; Wikipedia Monthly ब्लॉग लिंक
  • LLM की उपयोगिता पर चर्चा में हमेशा स्थिति-विशेष के ठोस उपयोग छूट जाते हैं, यह थोड़ा खलता है; LLM आने से पहले information retrieval और machine learning में सख्त मानदंड और evaluation sets होते थे, लेकिन अब जबकि LLM ज़्यादा general-purpose होकर कई तरह के tasks हल कर सकते हैं, फिर भी वास्तविक LLM बनाम दूसरे तरीकों के benchmark ज़्यादा न दिखना अजीब लगता है; हो सकता है कि research community की दिशा मुझे ठीक से न पता हो, इसलिए मैं कुछ मिस कर रहा हूँ
  • LLM के गलत जानकारी देने पर बहुत बहस होती है, लेकिन आदर्श ‘doomsday information query database’ के लिए मुझे LLM + file archive का संयोजन सबसे अच्छा लगता है; चरण 1: LLM इंसानी अस्पष्ट सवाल को समझकर मुख्य concepts और संबंधित Wiki documents आदि की link list दे; चरण 2: उपयोगकर्ता दिए गए documents से खुद भरोसेमंद जानकारी की पुष्टि करे
    • मेरे जैसे बेहद निराशावादी व्यक्ति को भी लगता है कि LLM इंसानी लिखावट को search query में बदलने वाले टूल के रूप में अच्छे से इस्तेमाल हो सकते हैं; इन्हें मध्यस्थ से ज़्यादा advisor या tutor की तरह इस्तेमाल करना आदर्श है; अंततः उपयोगकर्ता का उनकी सीमाओं से आगे जाना ज़रूरी है
  • "$1-distill-$2" जैसे नाम वाले models (कभी-कभी "-distill" नहीं भी होता) वास्तव में $2 model होते हैं जिन्हें $1 के outputs पर train करके बनाया गया “knowledge distillation” परिणाम माना जाना चाहिए, इसलिए नाम के विपरीत वे $1 स्वयं नहीं हैं; लेख में आया “Deepseek-R1 1.5B” जैसा model वास्तव में मौजूद नहीं है, बात कुछ ऐसी ही है