- 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 दे रहे हैं
अभी कोई टिप्पणी नहीं है.