स्थानीय LLM ecosystem को Ollama की ज़रूरत नहीं है

 (sleepingrobots.com)
26 पॉइंट द्वारा GN⁺ 15 일 전 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Ollama स्थानीय LLM चलाने को सरल बनाने वाला शुरुआती टूल था, लेकिन बाद में स्रोत छिपाने और cloud-केंद्रित बदलाव के कारण उसने भरोसा खो दिया
  • मुख्य इंजन llama.cpp के योगदान को कम करके दिखाया गया, और अपने ggml backend पर जाने से performance में गिरावट और पुराने bugs की वापसी हुई
  • model naming में भ्रम, closed-source GUI app distribution, अप्रभावी Modelfile structure जैसी वजहों से community की आलोचना जारी रही
  • model registry bottleneck, security vulnerabilities, और vendor lock-in structure स्थानीय-प्राथमिकता वाली सोच से टकराते हैं
  • llama.cpp, LM Studio, Jan जैसे open source विकल्प पहले से ही बेहतर performance और transparency दे रहे हैं और स्थानीय LLM ecosystem के केंद्र में आ चुके हैं

Ollama की समस्याएँ और स्थानीय LLM ecosystem के विकल्प

  • Ollama की शुरुआत और शुरुआती भूमिका

    • Ollama स्थानीय LLM execution को आसान बनाने वाले पहले llama.cpp wrapper के रूप में चर्चित हुआ
      • उपयोगकर्ता बिना सीधे C++ build किए या server setup किए model चला सकते थे
    • बाद में इसने स्रोत छिपाया, उपयोगकर्ताओं को भ्रमित किया, और local-first philosophy से हटकर venture capital आधारित cloud-केंद्रित ढाँचे की ओर बढ़ गया
    • संस्थापक Jeffrey Morgan और Michael Chiang हैं, जिन्होंने पहले Docker GUI Kitematic बनाया था, जिसे Docker Inc. ने अधिग्रहित किया था
    • Y Combinator(W21) से निकला यह प्रोजेक्ट 2023 में सार्वजनिक रूप से लॉन्च हुआ और खुद को “Docker for LLMs” कहता था

  • llama.cpp को उचित credit न देना

    • Ollama की inference क्षमता पूरी तरह Georgi Gerganov के llama.cpp पर निर्भर थी
    • एक साल से अधिक समय तक README, website और marketing material में कहीं भी llama.cpp का ज़िक्र नहीं था, यहाँ तक कि MIT license notice भी गायब था
    • license compliance की community request issue(#3185) पर 400 दिनों से अधिक समय तक कोई जवाब नहीं मिला
    • बाद में co-founder ने README के नीचे सिर्फ एक पंक्ति जोड़ी: “llama.cpp project founded by Georgi Gerganov”
    • Ollama की ओर से कहा गया कि “हम बहुत सारे patches कर रहे हैं और धीरे-धीरे अपने engine पर जा रहे हैं”, यानी जानबूझकर credit कम किया गया

अपने backend पर जाना और performance गिरना

  • ggml-आधारित custom backend अपनाना

    • 2025 के मध्य में, Ollama ने llama.cpp की जगह ggml-आधारित अपनी implementation अपनाई
    • वजह स्थिरता बताई गई, लेकिन नतीजा यह हुआ कि पहले से ठीक किए गए bugs फिर वापस आ गए
    • structured output errors, vision model failures, और GGML assertion crashes जैसी कई समस्याएँ सामने आईं
    • GPT-OSS 20B जैसे नए models काम नहीं कर पाए या tensor type support की समस्या आई
    • Gerganov ने सीधे कहा कि Ollama ने ggml को गलत तरीके से fork किया

  • performance comparison के नतीजे

    • community benchmarks में llama.cpp, Ollama से 1.8 गुना तेज़ रहा (161 vs 89 tokens/s)
    • CPU पर भी 30~50% का performance gap देखा गया
    • Qwen-3 Coder 32B test में llama.cpp का throughput 70% अधिक था
    • कारण बताए गए: Ollama का daemon architecture, अप्रभावी GPU offloading, और पुराना backend

model naming में भ्रम

  • DeepSeek-R1 मामला

    • Ollama ने DeepSeek-R1-Distill-Qwen-32B जैसे distilled models को सिर्फ “DeepSeek-R1” के नाम से दिखाया
    • जबकि वह असली 671B parameter model नहीं था, फिर भी वही नाम इस्तेमाल किया गया
    • उपयोगकर्ताओं को लगा कि उन्होंने “DeepSeek-R1 को local में चलाया”, जिससे DeepSeek की reputation को नुकसान पहुँचा
    • संबंधित GitHub issues(#8557, #8698) को duplicate कहकर बंद किया गया, लेकिन समस्या अनसुलझी रही
    • अभी भी ollama run deepseek-r1 distilled model ही चलाता है

closed app release

  • GUI app का private distribution

    • 2025 के जुलाई में macOS और Windows के लिए Ollama GUI app जारी किया गया
    • इसे private repository में develop किया गया, बिना license के distribute किया गया, और source code सार्वजनिक नहीं था
    • open source image बनाए रखने वाले प्रोजेक्ट के लिए यह तेज़ी से closed दिशा में बदलाव था
    • community ने AGPL-3.0 dependency की संभावना और license violation की चिंता उठाई
    • website पर GitHub link के पास download button रखकर इसे open source जैसा दिखाया गया
    • कई महीनों की चुप्पी के बाद यह 2025 के नवंबर में main repository में merge किया गया
    • XDA ने आलोचना की कि “जो प्रोजेक्ट खुद को open source कहते हैं, उन्हें स्पष्ट बताना चाहिए कि क्या public है और क्या नहीं”

Modelfile की अप्रभाविता

  • GGUF format के साथ duplication

    • GGUF format में model चलाने के लिए ज़रूरी सारी जानकारी एक ही file में होती है
    • Ollama इसके ऊपर Modelfile नाम की अलग configuration file जोड़ता है, जो Dockerfile जैसी संरचना रखती है
    • इससे GGUF में पहले से मौजूद जानकारी दोबारा लिखी जाती है और अनावश्यक complexity पैदा होती है
    • Ollama सिर्फ hardcoded templates की सूची को auto-detect करता है, नए templates को नज़रअंदाज़ कर देता है
    • नतीजतन model का instruction format टूट जाता है, और उपयोगकर्ताओं को manual conversion करना पड़ता है

  • parameter बदलने की अप्रभावी प्रक्रिया

    • parameter बदलने के लिए ollama show --modelfile से extract, फिर edit, फिर ollama create से दोबारा बनाना पड़ता है
    • इस प्रक्रिया में 30~60GB model की पूरी copy बनती है
    • community ने इसे “अप्रभावी और अनावश्यक duplication” कहा
    • llama.cpp में केवल command-line arguments से parameter समायोजित किए जा सकते हैं

  • template compatibility की समस्या

    • Ollama Go template syntax का उपयोग करता है, जो model creators के Jinja templates से मेल नहीं खाता
    • LM Studio और llama.cpp सीधे Jinja support करते हैं, लेकिन Ollama में conversion करना पड़ता है
    • conversion errors के कारण conversation format टूटने की कई reports आईं

model registry में bottleneck

  • model registration में देरी

    • नया model Hugging Face पर आने के बाद भी Ollama में उसे उपयोग करने से पहले अलग से package करके register करना पड़ता है
    • supported quantization formats भी Q4_K_M, Q8_0 जैसे सीमित हैं
    • इसका नतीजा यह है कि model release होने और Ollama पर उपलब्ध होने के बीच देरी होती है
    • community में “नए models test करने हों तो llama.cpp या vLLM इस्तेमाल करें” जैसे PSA posts फैल गए

  • quantization limitations

    • Ollama Q5, Q6, IQ series को support नहीं करता
    • उपयोगकर्ताओं के पूछने पर जवाब मिलता है: “दूसरा tool इस्तेमाल करें”
    • ollama run hf.co/{repo}:{quant} command से Hugging Face को सीधे call करना संभव हुआ, लेकिन फिर भी file internal hash storage में copy होती है और share नहीं की जा सकती, और template समस्याएँ बनी रहती हैं

cloud की ओर बदलाव और security समस्याएँ

  • cloud models जोड़ना

    • 2025 के अंत में Ollama ने cloud-hosted models जोड़े
    • local-केंद्रित tool होने के बावजूद कुछ models prompts को बाहरी servers पर भेजते हैं
    • MiniMax जैसे third-party models इस्तेमाल करने पर data बाहर जा सकता है
    • Ollama ने लिखा कि वह “logs store नहीं करता”, लेकिन third-party policies स्पष्ट नहीं हैं
    • Alibaba Cloud आधारित models के मामले में data retention की कोई गारंटी नहीं है

  • security vulnerabilities

    • CVE-2025-51471: एक vulnerability जिसमें malicious registry server authentication token चुरा सकता है
    • fix PR मौजूद था, लेकिन कई महीनों तक apply नहीं किया गया
    • local privacy को मुख्य मूल्य बताने वाले tool के लिए यह गंभीर संरचनात्मक समस्या है

venture capital-केंद्रित संरचना

  • बार-बार दिखने वाला पैटर्न

    • open source project को wrap करके user base बनाना → funding जुटाना → monetization की ओर जाना
    • Ollama की चरणबद्ध दिशा
      • open source से शुरुआत, llama.cpp पर निर्माण
      • स्रोत को छोटा दिखाना, खुद को स्वतंत्र product की तरह पेश करना
      • model registry और format के ज़रिए lock-in बनाना
      • closed GUI release करना
      • cloud service जोड़कर monetization करना

  • vendor lock-in structure

    • Ollama models को hashed filenames में store करता है, जिससे दूसरे tools के साथ compatibility मुश्किल हो जाती है
    • GGUF import किया जा सकता है, लेकिन export जानबूझकर असुविधाजनक रखा गया है
    • इस तरह उपयोगकर्ता Ollama ecosystem में बंध जाते हैं

वैकल्पिक tools

  • llama.cpp

    • OpenAI-compatible API server(llama-server), web UI, granular parameter control, और high throughput देता है
    • 2026 के फरवरी में ggml.ai, Hugging Face में शामिल हुआ, जिससे sustainability मजबूत हुई
    • MIT license पर आधारित, 450 से अधिक contributors की भागीदारी

  • अन्य विकल्प

    • llama-swap: multiple model loading और hot-swap support
    • LiteLLM: कई backends के बीच OpenAI-compatible proxy
    • LM Studio: GUI-आधारित, llama.cpp का उपयोग, GGUF के साथ पूर्ण compatibility
    • Jan, Msty: local-first design वाले open source desktop apps
    • koboldcpp, Red Hat ramalama: container-आधारित model execution, स्पष्ट source attribution

निष्कर्ष: स्थानीय LLM ecosystem की दिशा

  • Georgi Gerganov का llama.cpp स्थानीय AI innovation की बुनियाद है
    • community collaboration के जरिए consumer hardware पर भी शक्तिशाली models चलाना संभव हुआ
  • Ollama इसी आधार पर बढ़ा, लेकिन स्रोत छिपाने, quality गिराने, बंद स्वरूप अपनाने, और cloud की ओर मुड़ने से उसने भरोसा खो दिया
  • स्थानीय LLM ecosystem को Ollama नहीं, बल्कि llama.cpp की ज़रूरत है
    • असली openness और performance पहले से ही community-केंद्रित tools दे रहे हैं

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

3 टिप्पणियां

 
shblue21 15 일 전

मैं इससे कुछ हद तक सहमत हूँ, और लोकल में इसे ठीक से इस्तेमाल करना हो तो मुझे लगता है कि lm studio बेहतर है।
 
kirinonakar 14 일 전

मैंने भी शुरुआत में ollama से शुरू किया था, लेकिन इन दिनों मुझे lm studio पर स्विच किए हुए काफ़ी समय हो गया है।
 
GN⁺ 15 일 전
Hacker News की राय

  • ज़्यादातर लोकल LLM उपयोगकर्ताओं को लगता है कि Ollama ने UX की समस्या हल कर दी
    एक लाइन के कमांड से मॉडल चलाया जा सकता है, और ROCm ड्राइवर भी अपने-आप संभल जाते हैं
    इसके उलट llama.cpp का नाम ही C++ लाइब्रेरी जैसा लगता है, इसलिए आम उपयोगकर्ताओं के लिए उसके पास जाना आसान नहीं है
    मैं बस प्रोग्राम को खुद build नहीं करना चाहता, सिर्फ़ मज़े से इस्तेमाल करना चाहता हूँ

    • अब llama.cpp में डिफ़ॉल्ट रूप से GUI शामिल है। पहले नहीं था, लेकिन अब समय बदल गया है
    • “LM Studio, Jan, Msty, koboldcpp…” जैसे कई विकल्प हैं, लेकिन वास्तव में Ollama की जगह लेने वाला अगला दावेदार क्या है, यह जानने की जिज्ञासा है
      मैं Mac Mini इस्तेमाल करता हूँ, लेकिन CLI टूल भी ठीक है। Ollama की ताकत आसान इंस्टॉलेशन और मॉडल डाउनलोड थी, इसलिए विकल्प से भी उसी स्तर की सुविधा की उम्मीद है
    • kobold.cpp या LM Studio का सुझाव दिया गया। LM Studio open source नहीं है, लेकिन llama.cpp को उचित क्रेडिट देता है
      मेरा मानना है कि quality control महत्वपूर्ण है ताकि टूटा हुआ मॉडल सपोर्ट merge न हो जाए या गलत GGUF अपलोड न किए जाएँ
    • सहमत। यह स्थिति Docker जैसी है
      बेशक runc सीधे इस्तेमाल किया जा सकता है, लेकिन ज़्यादातर लोग docker run चुनते हैं
      UX तकनीक अपनाने का मुख्य तत्व है, और अगर कोई प्रोजेक्ट अच्छा interface नहीं बना पाया, तो उसके ऊपर wrapper बनाना गलत नहीं है
    • Ollama ने UX समस्या हल की, इसका मतलब यह नहीं कि license violation माफ़ हो जाती है

  • वही बात बार-बार दोहराते-दोहराते थक गया था, इसलिए मुझे जितनी timeline और sources पता थीं, उन्हें एक बार में व्यवस्थित कर दिया

    • यह लेख लिखने के लिए धन्यवाद कहा गया। मैंने भी llama.cpp में थोड़ा योगदान दिया है, और Ollama संस्थापकों का व्यवहार सच में निराशाजनक लगा
      विकल्प के तौर पर llama-file की सिफ़ारिश की गई। Mozilla AI का llamafile एक single executable file है जो OS से बेपरवाह काम करता है, और पूरी तरह open source है
      यह Justine Tunney द्वारा बनाए गए CosmopolitanC पर आधारित है, और आधिकारिक रूप से llama.cpp का उपयोग करता है
    • FOSS भावना को महत्व देने वाले व्यक्ति के तौर पर, यह बहुत शिक्षाप्रद लेख लगा
    • कहा गया कि इसमें बहुत-सी ऐसी बातें थीं जो पहले पता नहीं थीं
    • सारांश और timeline को शानदार बताया गया

  • मुझे लगता है Ollama उपयोग में आसानी के मामले में 1000 गुना बेहतर है
    llama.cpp शानदार है, लेकिन आम उपयोगकर्ताओं के लिए अनुकूल नहीं है
    मैंने शुरुआत Ollama से की थी, लेकिन नए fixes के लिए llama.cpp पर चला गया
    फिर भी मॉडल मैनेजमेंट के लिए अब भी Ollama इस्तेमाल करता हूँ। यह इतना सुविधाजनक है कि मैं खुद script बनाकर cache directory संभालता हूँ

    • ब्लॉग पोस्ट में कहा गया कि विकल्प सहज हैं, लेकिन असल में ऐसा नहीं है
      साधारण chat app हो तो अलग बात है, लेकिन OpenAI-compatible API और model management चाहिए हो तो पहुँच अचानक बहुत कठिन हो जाती है
    • Ollama का डिफ़ॉल्ट context size बहुत छोटा था, इसलिए शिकायतें थीं कि मॉडल बेवकूफ़ लगता है
      इसे लगातार बदलना हो तो नई model file बनानी पड़ती थी, और वह और भी जटिल था
      Docker-शैली का तरीका आम उपयोगकर्ताओं के लिए उल्टा असुविधाजनक है, और advanced users के लिए llama.cpp बेहतर है
    • जानकारी के लिए, अब llama.cpp में router mode भी जुड़ गया है, जिससे मॉडल real time में बदले जा सकते हैं
    • हाल की versions कहीं ज़्यादा शक्तिशाली हो गई हैं। llama.cpp tools/serv में देखा जा सकता है
    • मैं 3 साल से LM Studio इस्तेमाल कर रहा हूँ, और तब भी यह Ollama से कहीं बेहतर था

  • MIT license पर दो नज़रियों का सार दिया गया

    1. “एक लाइन का क्रेडिट दे दो, फिर कुछ भी कर सकते हो”
    2. “कानूनी रूप से आज़ादी है, लेकिन समुदाय के प्रति नैतिक ज़िम्मेदारी भी है”
      llama.cpp के संस्थापक Georgi Gerganov ने सिर्फ़ क्रेडिट न दिए जाने पर असंतोष जताया। यानी वे व्यवहार में पहली व्याख्या के ज़्यादा क़रीब थे
    • मुझे दूसरी व्याख्या तर्कसंगत नहीं लगती। अगर GPL obligations चाहिएँ, तो GPL इस्तेमाल करना चाहिए
      MIT एक कानूनी दस्तावेज़ है, नैतिक दिशा-निर्देश नहीं
      व्यक्तिगत रूप से, मुझे लगता है कि user-facing software के लिए GPL का उपयोग बेहतर है
      MIT चुनने के बाद कंपनियों के कोड ले जाने पर शिकायत करना विरोधाभासी है
      मेरा मानना है कि कंपनियों की नैतिकता नहीं होती, नैतिकता सिर्फ़ लोगों की होती है
    • अगर Georgi चाहते, तो कभी भी GPL में बदल सकते थे। लेकिन उन्होंने ऐसा नहीं किया
      आख़िरकार दोनों प्रोजेक्ट आगे बढ़ते रहे, और उपयोगकर्ताओं को ज़्यादा विकल्प मिले

  • पहले default model folder बदला नहीं जा सकता था, इसलिए असुविधा होती थी
    मॉडल register करने के लिए Dockerfile जैसी प्रक्रिया से गुज़रना पड़ता था, और मॉडल hash storage में copy हो जाता था, इसलिए उसकी जगह बदली नहीं जा सकती थी
    इसलिए मैं LM Studio पर चला गया। वह पूरी तरह open source नहीं है, लेकिन model folder दिखाता था और Hugging Face के साथ integrated था

    • अब यह संभव है। server config file के environment variable OLLAMA_MODELS से path तय किया जा सकता है
    • मैंने भी इस समस्या से जूझा था। SSD upgrade से पहले और बाद में LM Studio से तुलना करना चाहता था, लेकिन मॉडल की location ढूँढना और व्यवस्थित करना बहुत जटिल और बेवजह पीड़ादायक था

  • Ollama की वह संरचना, जिसमें model files को hash blob storage में copy किया जाता है, दूसरे टूल्स के साथ sharing असंभव बना देती है
    शायद यह deduplication के लिए डिज़ाइन किया गया होगा, लेकिन नतीजा यह है कि दूसरे tools आज़माना मुश्किल हो जाता है
    model files बहुत बड़े होते हैं, इसलिए storage space और download दोनों बड़ा बोझ बनते हैं

  • Arch Linux में pacman -Ss ollama 16 results देता है, लेकिन llama.cpp या lmstudio के लिए 0 results आते हैं
    उम्मीद है कि कभी यह बदलेगा

    • llama.cpp बहुत तेज़ी से update होता है, इसलिए stable package के रूप में रखना कठिन है, लेकिन AUR से install किया जा सकता है
      Vulkan, ROCm, CUDA versions सब समर्थित हैं
    • दूसरी ओर openSUSE में zypper से llamacpp मिल सकता है
      distribution के हिसाब से version और support अलग हैं, और शायद इतनी सारी Linux distributions के मौजूद होने का कारण भी यही है
    • मैंने CachyOS में yay -S llama.cpp से install किया, और यह Ollama से कहीं तेज़ और बेहतर था

  • “llama.cpp” नाम अब अपना-सा नहीं लगता
    पहले यह Meta के Llama model को दर्शाता था, लेकिन अब उससे भी ज़्यादा शक्तिशाली open source models बहुत हैं

    • लेकिन “Ollama” में भी वही समस्या है
      अब “Local LLaMA” नाम लोकल मॉडल चलाने के सामान्य नाम की तरह इस्तेमाल होने लगा है
    • Wikipedia की generalized trademarks सूची देखें तो यह घटना आम है

  • Ollama में शुरू से ही पूरे workflow को नियंत्रित करने की मंशा की गंध आती थी, इसलिए मैंने इसे शुरुआत से टाल दिया
    नतीजे में मुझे लगता है कि यह सही फ़ैसला था

  • Ollama की hash blob storage संरचना सबसे बड़ा जाल है
    अगर कई महीनों तक मॉडल डाउनलोड किए हों, तो किसी दूसरे tool पर जाते समय सब कुछ फिर से डाउनलोड करना पड़ता है
    ज़्यादातर उपयोगकर्ताओं को यह बात तब पता चलती है जब वे पहले ही काफ़ी गहराई तक निवेश कर चुके होते हैं, और तब switching cost बहुत भारी लगती है