VPS पर Ollama बनाम llama.cpp: क्या चुनें?

Ollama बनाम llama.cpp: आप किस लेयर को चलाना चाहते हैं?

Ollama और llama.cpp उस तरह से प्रतिस्पर्धी नहीं हैं जैसा कि प्रश्न में संकेत दिया गया है। llama.cpp एक inference engine है: यह एक model file को लोड करता है और prompt को tokens में बदल देता है। Ollama एक model manager, एक background daemon और उस engine के ऊपर स्थित एक HTTP API है। Ollama का README अभी भी llama.cpp को अपने inference backend के रूप में सूचीबद्ध करता है (27 October 2026 को जाँचा गया)। इसलिए असली सवाल यह है कि आप अपने VPS पर किस लेयर को संचालित करना चाहते हैं, न कि यह कि कौन सा तेज़ है।

Ollama तब चलाएँ जब आप एक ऐसी service चाहते हैं जो नाम से models को fetch करे और बिना किसी ध्यान के काम करती रहे। llama.cpp को सीधे तब चलाएँ जब VPS छोटा हो और आपको सटीक model file, सटीक context size और सटीक thread count चुनने की आवश्यकता हो, क्योंकि एक छोटे VPS पर इनमें से प्रत्येक setting के लिए उतनी memory खर्च होती है जो आपके पास उपलब्ध नहीं है।

प्रत्येक प्रोजेक्ट वास्तव में क्या है

llama.cpp, ggml लाइब्रेरी पर निर्मित transformer inference का एक C और C++ कार्यान्वयन है। यह GGUF फाइलों को पढ़ता है। GGUF (GGML universal file format) एक सिंगल-फाइल कंटेनर है जिसमें वे weights, tokeniser और metadata होते हैं जिनकी मॉडल को चलाने के लिए इंजन को आवश्यकता होती है। यह प्रोजेक्ट अलग-अलग कार्यों के लिए अलग-अलग binaries ships करता है। llama-server एक HTTP सर्वर है, llama-cli एक इंटरैक्टिव प्रॉम्प्ट है, और llama-bench थ्रूपुट मापता है। यह प्रोजेक्ट अब semantic-versioned releases (MAJOR.MINOR.PATCH) जारी करता है, और 15 October 2026 को प्रकाशित v0.7.0, 27 October 2026 तक का नवीनतम संस्करण था। बिल्ड-नंबर वाले nightly tags अभी भी इनके साथ आते हैं, जो दिन में कई बार जारी होते हैं, और 27 October 2026 को सबसे नया b11913 था।

Ollama एक Go प्रोग्राम है। ollama serve के साथ शुरू होने वाला एक बैकग्राउंड डेमन, मॉडल लोड करता है और HTTP अनुरोधों का उत्तर देता है, और एक कमांड लाइन क्लाइंट उस डेमन से बात करता है। इन दोनों के पीछे ollama.com पर एक रजिस्ट्री है जो पहले से पैक किए गए मॉडल रखती है। Ollama semantic versions का उपयोग करता है। v0.32.5 को 27 July 2026 को ship किया गया था, और v0.40.12 को 27 October 2026 को 00:07 UTC पर release किया गया था। ollama pull एक GGUF को प्रॉम्प्ट टेम्पलेट और डिफ़ॉल्ट पैरामीटर्स के सेट के साथ फेच करता है, और फिर इसे Linux पर /usr/share/ollama/.ollama/models के अंतर्गत स्टोर करता है। ये फाइलें रूट डिस्क पर रहती हैं और प्रत्येक कई गीगाबाइट की होती हैं, इसलिए 25 GB रूट वॉल्यूम वाले VPS पर तीसरी डाउनलोड से डिस्क भरने से पहले यह जानना उपयोगी है कि pull क्या पीछे छोड़ता है और मॉडल डायरेक्टरी को कहीं और कैसे ले जाएं।

यह पैकेजिंग ही मुख्य अंतर है। Ollama आपके लिए quantisation, टेम्पलेट और कॉन्टेक्स्ट लेंथ तय करता है, और आपको याद रखने के लिए एक नाम देता है। llama.cpp उन विकल्पों को flags के रूप में expose करता है, और जिन सेटिंग्स को आप unset छोड़ देते हैं उनके लिए स्वचालित डिफ़ॉल्ट्स का उपयोग करता है।

Axis 1: मॉडल और क्वांटाइजेशन नियंत्रण

क्वांटाइजेशन मॉडल के मूल 16 या 32 बिट्स की तुलना में कम बिट्स में वेट्स (weights) को स्टोर करता है। सामान्य GGUF बिल्ड्स औसतन प्रति वेट लगभग 4, 5 या 8 बिट्स का उपयोग करते हैं। फाइल में प्रिसिजन (precision) एक समान नहीं होती है। llama.cpp के क्वांटाइजर सोर्स (27 अक्टूबर 2026 को पढ़ा गया) के अनुसार, एक Q4_K_M बिल्ड अधिकांश टेंसर्स को 4-बिट पर रखता है, लेकिन आउटपुट लेयर, अटेंशन वैल्यू और फीड-फॉरवर्ड डाउन टेंसर्स को लगभग आधी लेयर्स में 6-बिट Q6_K देता है, जबकि नॉर्म्स जैसे छोटे टेंसर्स को बिल्कुल भी क्वांटाइज नहीं किया जाता है। यही कारण है कि 8 बिलियन पैरामीटर वाला मॉडल एक साधारण VPS की RAM में फिट हो जाता है। एक बार पैटर्न समझ लेने पर GGUF का नामकरण पढ़ना आसान हो जाता है: Q4_K_M का अर्थ है 4-बिट K-क्वांट, मध्यम आकार। एक उच्च संख्या अधिक प्रिसिजन बनाए रखती है और अधिक मेमोरी लेती है।

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

ये Hugging Face पर bartowski/Meta-Llama-3.1-8B-Instruct-GGUF रिपॉजिटरी में प्रकाशित फाइल साइज हैं, जिन्हें 2 अगस्त 2026 को पढ़ा गया और बाइट्स से GiB में परिवर्तित किया गया। एक मॉडल के 6 बिल्ड्स हैं, और सबसे छोटा 2.96 GiB है, जबकि सबसे बड़ा 7.95 GiB है। सामान्य डिफॉल्ट, Q4_K_M, 4.58 GiB है। 4 GiB के VPS पर यह अकेला विकल्प तय करता है कि मॉडल लोड होगा या नहीं। साइज इस निर्णय का केवल आधा हिस्सा है, क्योंकि जिस रो (row) को आप वहन कर सकते हैं, वह जरूरी नहीं कि उपयोग करने लायक भी हो, और Q4, Q8 और fp16 वास्तव में उत्तर की गुणवत्ता में क्या अंतर लाते हैं यह बताता है कि क्या अतिरिक्त गीगाबाइट्स से आपको कोई ध्यान देने योग्य लाभ मिलता है।

llama.cpp के साथ आप फाइल का नाम खुद तय करते हैं, इसलिए आप वह रो खुद चुनते हैं।

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c टोकन में कॉन्टेक्स्ट साइज है, -t थ्रेड काउंट है, और -ngl यह सेट करता है कि कितनी लेयर्स GPU पर मूव होंगी (CPU-ओनली बॉक्स पर 0)। अनसेट सेटिंग्स के डिफॉल्ट्स होते हैं, और --fit डिफॉल्ट रूप से ऑन रहता है ताकि अनसेट आर्गुमेंट्स को डिवाइस मेमोरी के अनुसार एडजस्ट किया जा सके।

Ollama के साथ क्वांटाइजेशन उस टैग के साथ आता है जिसे आप पुल करते हैं, और ollama ls दिखाता है कि डिस्क पर वास्तव में क्या है। जब रजिस्ट्री में वह बिल्ड न हो जो आप चाहते हैं, तो खुद एक GGUF इम्पोर्ट करें। एक Modelfile लिखें:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

फिर इसे बिल्ड करें और परिणाम की जाँच करें:

ollama create llama31-q4 -f ./Modelfile
ollama ls

कॉन्टेक्स्ट लेंथ वह सेटिंग है जो लोगों को उलझाती है। Ollama उपलब्ध VRAM से अपना डिफॉल्ट चुनता है, और बिना GPU वाले बॉक्स सबसे छोटे बकेट में गिर जाते हैं: 4096 टोकन। इसे 20,000 टोकन का डॉक्यूमेंट भेजें तो अतिरिक्त टोकन मॉडल के देखने से पहले ही ड्रॉप कर दिए जाते हैं, इसलिए मॉडल उस फाइल के बारे में आत्मविश्वास के साथ गलत उत्तर देता है जिसे उसने आधा ही पढ़ा है। इसे डेमन पर OLLAMA_CONTEXT_LENGTH के साथ, या Modelfile में PARAMETER num_ctx के साथ बढ़ाएं। यदि केवल एक जॉब को बड़े विंडो की आवश्यकता है, तो num_ctx को सर्वर-वाइड के बजाय प्रति रिक्वेस्ट सेट किया जा सकता है, जिससे डेमन द्वारा किए जाने वाले अन्य कार्यों पर अतिरिक्त कैश का बोझ नहीं पड़ता। llama.cpp का भी कोई ऐसा डिफॉल्ट नहीं है जिस पर भरोसा किया जा सके। -c को स्पष्ट रूप से सेट करें और जानें कि आपने क्या सेट किया है।

मेमोरी की वह गणना जो कोई नहीं बताता

मॉडल फाइल ही एकमात्र लागत नहीं है। KV cache (key/value cache) कॉन्टेक्स्ट के प्रति टोकन, प्रति लेयर एक एंट्री रखता है, और जैसे-जैसे बातचीत बढ़ती है, यह भी बढ़ता जाता है।

Llama 3.1 8B के लिए इसकी गणना करें। मॉडल में 32 लेयर्स, 8 key/value हेड्स और 128 का हेड डाइमेंशन है। प्रत्येक टोकन f16 में 2 बाइट्स पर एक की (key) और एक वैल्यू (value) दोनों को स्टोर करता है, इसलिए प्रति लेयर 2 x 8 x 128 x 2 = 4096 बाइट्स होते हैं। 32 लेयर्स में यह प्रति टोकन 128 KiB होता है। इसलिए 4096 टोकन कॉन्टेक्स्ट की लागत 512 MiB है, और 32,768 टोकन कॉन्टेक्स्ट की लागत 4 GiB है।

अतः 4k कॉन्टेक्स्ट पर एक Q4_K_M 8B मॉडल को वेट्स (weights) के लिए लगभग 4.58 GiB, प्लस लगभग 0.5 GiB कैश, और रनटाइम की आवश्यकता होती है। यह 4 GiB RAM में फिट नहीं होता है। यह काम करने के लिए पर्याप्त जगह के साथ 8 GiB में फिट हो जाता है। उसी 8 GiB बॉक्स पर कॉन्टेक्स्ट को 32k तक बढ़ाएं और केवल कैश ही पूरी अतिरिक्त क्षमता को खत्म कर देगा। मॉडल लोड होते समय इसे free -h के साथ लाइव देखें, और उस अनुमान पर भरोसा न करें जिसे आपने मापा नहीं है। यदि आप 8B से काफी बड़े मॉडल के लिए साइजिंग कर रहे हैं, तो CPU-only VPS पर 27B मॉडल के लिए की गई यही गणना दिखाती है कि 8 से 64 GB तक का प्रत्येक टियर वास्तव में क्या संभाल सकता है।

Ollama इसे कई गुना बढ़ा देता है। OLLAMA_NUM_PARALLEL डिफ़ॉल्ट रूप से 1 पर सेट होता है, और मॉडल को जितनी मेमोरी चाहिए वह उस संख्या और कॉन्टेक्स्ट लेंथ के गुणनफल के साथ बढ़ती है। दोनों को एक साथ बढ़ाने पर डेमन चुपचाप आपसे उतनी RAM मांगता है जितनी आपने सोची भी नहीं थी। यही गणना एक साथ उपयोग करने वाले उपयोगकर्ताओं की सीमा तय करती है, क्योंकि प्रत्येक समवर्ती अनुरोध (concurrent request) को अपना KV cache का हिस्सा चाहिए होता है, जो कि कारण है कि एक व्यक्ति के लिए ठीक चलने वाला सर्वर पांच लोगों पर धीमा हो जाता है।

Axis 2: वह daemon जिसे आपको संचालित करना है

Ollama install script एक systemd unit लिखती है, एक ollama system user बनाती है और service को enable करती है। आपको इसे खुद लिखे बिना lifecycle management की सुविधा मिल जाती है। Configuration systemd के माध्यम से की जाती है:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE का महत्व CPU VPS पर कहीं और की तुलना में अधिक है। Models डिफ़ॉल्ट रूप से 5 मिनट तक memory में रखे जाते हैं और फिर unload कर दिए जाते हैं। अगली request को जवाब देने से पहले पूरी file को फिर से load करना पड़ता है। यदि kernel अभी भी file को अपने page cache में रखता है तो यह तेज़ होता है, लेकिन केवल खाली RAM ही इसे वहां रख पाती है, और एक बार जब अन्य काम इसे बाहर धकेल देते हैं तो file disk से वापस आती है, इसलिए धीमी storage पर एक 4.58 GiB का reload दो सेकंड के जवाब को तीस सेकंड में बदल देता है। एक लंबा keep-alive latency को ठीक करता है और स्थायी रूप से RAM का उपयोग करता है। दोनों ही वास्तविक लागतें हैं। वह चुनें जो कम नुकसान पहुँचाए। यदि आप तय करते हैं कि model को resident रहना चाहिए, तो keep_alive को सेट करना ताकि यह idle periods और reboots के दौरान बना रहे में कुछ ही lines लगती हैं और हर बार box restart होने पर आपको मैन्युअल रूप से model को warm करने की आवश्यकता नहीं पड़ती।

llama.cpp आपको कोई daemon और कोई service user नहीं देता है, इसलिए आप दोनों को स्वयं set करते हैं। उस llama.cpp directory से जहाँ आपने build किया था, binary और उसकी libraries को /usr/local में install करें, एक llama user बनाएँ, और उसे model की एक copy दें:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

यदि आपने build करने के बजाय release archive का उपयोग किया है, तो ExecStart को उसके अंदर मौजूद llama-server पर point करें, क्योंकि archive अपनी libraries को binary के बगल में रखता है। फिर unit को /etc/systemd/system/llama-server.service के रूप में लिखें:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

इसे sudo systemctl enable --now llama-server के साथ enable करें। इसके बाद process अपने पूरे lifetime के दौरान model को hold करके रखती है। डिफ़ॉल्ट रूप से idle होने पर कुछ भी unload नहीं होता है, लेकिन --sleep-idle-seconds जोड़ने से service को रोके बिना automatic unloading और reloading सक्षम हो जाती है। यदि unit लिखना आपके लिए नया है, तो यह VPS पर systemd के तहत अपनी services चलाने के समान ही pattern है।

Axis 3: वह API जिससे आपका app बात करेगा

यह axis काफी सीमित हो गया है। दोनों projects अब OpenAI chat format का उपयोग करते हैं, इसलिए अधिकांश client libraries केवल base URL बदलने के बाद किसी के भी साथ काम करती हैं।

Ollama 127.0.0.1:11434 पर listening करता है। इसका OpenAI-compatible route http://localhost:11434/v1/chat/completions है और इसके साथ native API /api/chat पर उपलब्ध रहती है। Anthropic-compatible route भी documented है। इनमें से कोई भी route model को अपने-आप जानकारी खोजने की सुविधा नहीं देता। इसलिए यदि आपके app को model के training data से नई जानकारी वाले answers चाहिए, तो Ollama's API, Open WebUI या एक छोटे tool loop के माध्यम से web search जोड़ने की योजना बनाएँ।

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

ऊपर दिए गए flags के साथ start होने पर, llama-server 127.0.0.1:8080 पर listen करता है। यदि इसे ऐसे ही छोड़ दिया जाए, तो यह अब default रूप से port 9931 (27 October 2026 को जाँचा गया) का उपयोग करता है, इसलिए यदि आपका app 8080 की अपेक्षा करता है तो command line पर --port को बनाए रखें। यह /v1/chat/completions, /v1/completions और /v1/embeddings के साथ-साथ अपना स्वयं का /completion endpoint और एक built-in web UI serve करता है। यह ऐसे operational routes भी expose करता है जो Ollama में नहीं हैं: readiness probe के लिए /health, loaded model की settings के लिए /props, प्रत्येक request slot क्या कर रहा है इसके लिए /slots, और यदि आप --metrics जोड़ते हैं तो Prometheus format में /metrics, क्योंकि वह endpoint default रूप से off रहता है। यदि आप इस service को monitor करने की योजना बना रहे हैं, तो शायद यही अंतर निर्णय लेने का आधार होगा।

कोई भी server आपके लिए authentication चालू नहीं करता है। दोनों उचित कारणों से default रूप से loopback पर रहते हैं। उन तक SSH tunnel के माध्यम से या reverse proxy के पीछे से पहुँचें, और कभी भी 11434 या 8080 को internet के लिए open न करें।

CPU-only VPS वास्तव में क्या कर सकता है

CPU-only VPS पर छोटे मॉडल्स धीरे चलते हैं। यह एक ईमानदार सारांश है, और उपयोगी बात यह जानना है कि सीमा कहाँ है। किसी भी डिज़ाइन को बनाने से पहले मापें:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

pp कॉलम प्रॉम्प्ट प्रोसेसिंग की गति है और tg कॉलम टोकन जनरेशन की गति है, दोनों टोकन प्रति सेकंड में हैं। एक shared vCPU प्लान पर Q4_K_M में 8B मॉडल आमतौर पर tg के लिए कम सिंगल डिजिट में रहता है। प्रॉम्प्ट प्रोसेसिंग वह हिस्सा है जो सबसे अधिक प्रभावित करता है: पहला आउटपुट टोकन आने से पहले पूरा प्रॉम्प्ट प्रोसेस होता है, इसलिए एक लंबा सिस्टम प्रॉम्प्ट हर अनुरोध में देरी जोड़ देता है। उत्तर की लंबाई वह हिस्सा है जिसे आप नियंत्रित कर सकते हैं, क्योंकि तीन टोकन प्रति सेकंड की गति पर, 600 टोकन तक बोलने वाला मॉडल 200 सेकंड तक बॉक्स को व्यस्त रखता है, जो केवल जनरेशन में तीन मिनट से अधिक है, इसलिए num_predict के साथ आउटपुट को सीमित करना एक लंबी प्रतिक्रिया को टाइमआउट बनने से रोकने का सबसे सस्ता तरीका है।

CPU पर उपयोग योग्य: 1B से 4B मॉडल जो क्लासिफिकेशन, एक्सट्रैक्शन, छोटे सारांश या रूटिंग का काम करते हैं। उत्तर सेकंडों में आते हैं और मेमोरी एक सामान्य प्लान में फिट हो जाती है। उस आकार के लिए एक उदाहरण के रूप में, VPS पर Nemotron 3.5 Lightning को पुल और मापना सटीक टैग, आवश्यक RAM और बिना GPU के इसकी गति बताता है। CPU पर उपयोग योग्य नहीं: पढ़ने की गति पर इंटरैक्टिव चैट, कोडिंग असिस्टेंट, लंबे दस्तावेज़ों पर काम, या कोई भी ऐसा एजेंट लूप जो क्रम में कई कॉल करता है। एक लूप जो चार सेकंड की बारह कॉल करता है, कुछ भी उत्पन्न करने से पहले एक मिनट लेता है। यदि कोडिंग असिस्टेंट ही योजना थी, तो एजेंट को अपने द्वारा होस्ट किए गए मॉडल की ओर निर्देशित करना यह स्पष्ट करता है कि कौन से कार्य एक छोटे स्थानीय मॉडल के लिए सही हैं और कौन से होस्ट किए गए API पर होने चाहिए।

जब आंकड़े काम न करें तो दो रास्ते हैं। यदि समस्या कॉनकरेंसी (concurrency) की है, यानी कई उपयोगकर्ता एक साथ एक मॉडल का उपयोग कर रहे हैं, तो इंजन का चुनाव बदल जाता है, और कॉनकरेंट सर्विंग के लिए Ollama बनाम vLLM की तुलना इस विषय को कवर करती है। यदि समस्या कच्ची गति की है, तो उत्तर GPU वाला VPS है, जहाँ -ngl का महत्व बढ़ जाता है। इससे पहले, हार्डवेयर के लिए एक बेसलाइन प्राप्त करें, क्योंकि डिस्क और मेमोरी बैंडविड्थ लोड समय को CPU जितना ही प्रभावित करते हैं। एक दोहराने योग्य VPS बेंचमार्क पर एक घंटा बिताना सार्थक है।

llama.cpp को इंस्टॉल करना और एक विशिष्ट build को पिन करना

दोनों प्रोजेक्ट्स में साप्ताहिक बदलाव होते हैं, इसलिए आप जो वर्ज़न डिप्लॉय करें उसका रिकॉर्ड रखें। अपस्ट्रीम वन-लाइनर कमांड वर्तमान build को इंस्टॉल करता है:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

किसी विशिष्ट build को पिन करने के लिए, releases पेज से प्री-बिल्ट tarball का उपयोग करें। यह प्रोजेक्ट अब semantic-versioning वाले releases भी जारी करता है: 27 October 2026 को v0.7.0 नवीनतम था, और इसका release पेज बाइनरीज़ के लिए nightly b11669 की ओर इशारा करता है। इसके बाद 28 October 2026 को v0.8.0 आया, जिसका release पेज बाइनरीज़ के लिए nightly b11960 की ओर इशारा करता है। नीचे दी गई कमांड्स 2 August 2026 के वर्तमान टैग, b10224 का उपयोग करती हैं; आप जिस टैग का परीक्षण कर चुके हैं, उसे यहाँ बदलें:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

या उसी टैग को सोर्स से बिल्ड करें:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev HTTPS फीचर्स के लिए प्रलेखित निर्भरता (dependency) है। कंपाइल होने में कई मिनट लगते हैं और इसके लिए सबसे छोटे प्लान्स की तुलना में अधिक RAM की आवश्यकता होती है, इसलिए यदि छोटा सर्वर कम पड़ जाए तो किसी बड़े बॉक्स पर बिल्ड करें और बाइनरीज़ को कॉपी कर लें।

Ollama को इंस्टॉल करें, एक विशिष्ट version पर पिन करें

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

यह script OLLAMA_VERSION को पढ़ती है, इसलिए आप आज जारी हुए किसी भी version के बजाय एक ज्ञात-सही (known-good) release को सुरक्षित रख सकते हैं। v0.32.5 को 27 July 2026 को प्रकाशित किया गया था। यदि आप किसी script को सीधे shell में pipe नहीं करना चाहते हैं, तो एक manual तरीका भी उपलब्ध है:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

Manual तरीका systemd unit या service user नहीं बनाता है, इसलिए आपको उन्हें स्वयं जोड़ना होगा। VPS पर पूर्ण Ollama सेटअप गाइड उस service सेटअप को चरण-दर-चरण कवर करती है।

विफलता के प्रकार और दिखाई देने वाले स्ट्रिंग्स

Ollama मॉडल लोड करने से इनकार करता है। Ollama के पुराने releases लोड करने से पहले आकार की जाँच करते थे, और ollama run इस प्रकार की एक पंक्ति दिखाता था:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama के वर्तमान source में अब वह संदेश नहीं है (27 October 2026 को जाँच की गई)। Ollama अब लोडिंग का कार्य llama-server को सौंप देता है, इसलिए जो मॉडल फिट नहीं होता, वह एक runner failure के रूप में दिखाई देता है, जिसकी त्रुटियाँ इस प्रकार शुरू होती हैं:

llama-server reported out-of-memory during startup
llama-server process has terminated

दोनों ही स्थितियों में समाधान एक ही है। एक quantisation row नीचे जाएँ, context length कम करें, या कोई छोटा मॉडल चुनें।

llama.cpp विफल नहीं होता, बल्कि बहुत धीमा चलता है। llama.cpp डिफ़ॉल्ट रूप से GGUF को memory-map करता है, इसलिए RAM से बड़ी फ़ाइल भी शुरू हो जाती है। इसके बाद kernel हर token पर disk से weights को page-in और page-out करता है, और generation की गति प्रति token कई सेकंड तक गिर जाती है, जबकि disk 100 प्रतिशत उपयोग पर पिन हो जाती है। memory mapping को अक्षम करने के लिए --load-mode none पास करें। वह विकल्प --no-mmap की जगह आया है, जिसे pinned b10224 build में deprecated के रूप में प्रलेखित किया गया है और अब वर्तमान builds में दिखाई नहीं देता है (29 October 2026 को जाँच की गई)। जब kernel हस्तक्षेप करता है, तो dmesg कारण दिखाता है:

Out of memory: Killed process 1234 (llama-server)

मॉडल फ़ाइल बिल्कुल भी लोड नहीं होती है। आपके engine से नए मॉडल परिवार के लिए बनाया गया GGUF एक त्रुटि देता है जो उस architecture का नाम बताती है जिसे वह नहीं पहचानता, जहाँ <arch> फ़ाइल के metadata में संग्रहीत नाम है:

llama_model_load: error loading model: unknown model architecture: '<arch>'

इसका समाधान engine को अपग्रेड करना है, न कि कोई दूसरी फ़ाइल चुनना। यह pinning की कीमत है, और यही कारण है कि आप build number को नोट करके रखते हैं। आपको यह जानने की आवश्यकता है कि आप किस version से अपग्रेड कर रहे हैं।

API स्थानीय रूप से उत्तर देता है लेकिन आपके app से नहीं। Ollama 127.0.0.1:11434 पर bind होता है, इसलिए दूसरे host को connection refused मिलता है। OLLAMA_HOST=0.0.0.0:11434 को केवल तभी systemctl edit ollama के माध्यम से सेट करें जब port किसी firewall या private network के पीछे हो, क्योंकि API के सामने कोई authentication नहीं होता है।

विराम के बाद पहला उत्तर बहुत धीमा है। 5 मिनट का idle unload हो गया था और मॉडल फिर से लोड हो रहा है, यदि page cache ने इसे नहीं रखा है तो यह disk से लोड हो रहा है। अनुरोध से ठीक पहले चलाया गया ollama ps दिखाता है कि कुछ भी लोड नहीं है, जो इसकी पुष्टि करता है। OLLAMA_KEEP_ALIVE को बढ़ाएं।

तो आपको कौन सा चलाना चाहिए?

जब आप चाहते हैं कि models आपके लिए manage की जाएं और बिना किसी अतिरिक्त मेहनत के OpenAI-जैसा endpoint मिल जाए, तो Ollama चलाएं। यह पहले deployment के लिए और ऐसी किसी भी स्थिति के लिए सही default विकल्प है जहां model का चुनाव बार-बार बदलता रहेगा।

जब memory इतनी कम हो कि आपको quantization row खुद चुननी पड़े, जब आपको monitoring के लिए /health, /slots और /metrics की आवश्यकता हो, या जब आपको किसी ऐसे flag की जरूरत हो जिसे Ollama expose नहीं करता, तब सीधे llama.cpp चलाएं। VPS पर यह सबसे सटीक विकल्प है जहां model बमुश्किल fit होता है, क्योंकि जिन settings से यह fit होता है, वे वही हैं जिन्हें Ollama आपकी ओर से चुनता है।

दोनों को एक साथ चलाना सामान्य है। प्रयोगों के लिए Ollama का उपयोग करें, और उस एक model के लिए llama.cpp का उपयोग करें जिसे आप production में डाल चुके हैं और जिसमें कोई बदलाव नहीं चाहते।

FAQ

क्या Ollama केवल llama.cpp का एक wrapper है?

काफी हद तक, लेकिन यह wrapper वास्तविक कार्य करता है। Ollama की README फाइल में llama.cpp को इसके inference backend के रूप में सूचीबद्ध किया गया है (27 October 2026 को जाँचा गया)। इसके ऊपर Ollama एक model registry, prompt template जो chat messages को prompt में बदलता है, default sampling parameters का एक सेट, idle unloading के साथ एक daemon, और एक HTTP API जोड़ता है। जब आप समान settings पर tokens per second की तुलना करते हैं, तो आप वास्तव में एक ही engine की तुलना उसी से कर रहे होते हैं। आप वास्तव में management layer के बीच चुनाव करते हैं।

CPU-only VPS पर कौन सा अधिक तेज़ है?

वे एक ही engine का उपयोग करते हैं, इसलिए समान model file, quantisation, context size और thread count पर उनका प्रदर्शन लगभग समान रहता है। लोग जो अंतर बताते हैं, वह आमतौर पर अलग-अलग defaults के कारण होता है, अक्सर context length और thread count, न कि engine के कारण। किसी भी प्रकाशित आंकड़े पर विश्वास करने से पहले इसे llama-bench -m <file> -p 512 -n 128 के साथ मापें और अपने स्वयं के सर्वर पर tg column की तुलना करें।

क्या मैं Ollama के साथ अपनी खुद की GGUF file का उपयोग कर सकता हूँ?

हाँ। फाइल को सर्वर पर रखें, एक Modelfile लिखें जिसकी पहली पंक्ति FROM ./your-model.gguf हो, अपनी आवश्यकतानुसार कोई भी PARAMETER पंक्तियाँ जोड़ें जैसे कि num_ctx, और फिर ollama create your-name -f ./Modelfile चलाएँ। ollama ls इसे registry से pull की गई किसी भी अन्य चीज़ के साथ सूचीबद्ध करेगा। इस तरह आप उस quantisation का उपयोग कर सकते हैं जो registry में उपलब्ध नहीं है।

8B model के लिए मुझे कितनी RAM की आवश्यकता है?

फाइल के आकार, KV cache और runtime के लिए बजट निर्धारित करें। Llama 3.1 8B का Q4_K_M build डिस्क पर लगभग 4.58 GiB का होता है, और 4096 token का context लगभग 512 MiB cache जोड़ता है, इसलिए 8 GiB RAM पर्याप्त है और 4 GiB पर्याप्त नहीं है। Cache का आकार context के साथ बढ़ता है: वही model 32,768 token context पर अकेले लगभग 4 GiB cache की मांग करता है। Ollama के साथ, याद रखें कि आवश्यकता OLLAMA_NUM_PARALLEL के साथ भी बढ़ती है।