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 के रूप में सूचीबद्ध करती है (2 August 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 और वे मेटाडेटा होते हैं जिनकी इंजन को मॉडल चलाने के लिए आवश्यकता होती है। यह प्रोजेक्ट अलग-अलग कार्यों के लिए अलग-अलग बाइनरी फाइलें प्रदान करता है। llama-server एक HTTP सर्वर है, llama-cli एक इंटरैक्टिव प्रॉम्प्ट है, और llama-bench थ्रूपुट को मापता है। इसके रिलीज को सिमेंटिक वर्जन के बजाय बिल्ड नंबर द्वारा टैग किया जाता है। वर्तमान टैग b10224 है, जिसे 2 अगस्त 2026 को प्रकाशित किया गया था, और लगभग हर कार्य दिवस पर एक नया टैग आता है।

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

यही पैकेजिंग ही मुख्य अंतर है। Ollama आपके लिए क्वांटाइजेशन, टेम्पलेट और कॉन्टेक्स्ट लेंथ तय करता है, और आपको याद रखने के लिए एक नाम देता है। llama.cpp कुछ भी तय नहीं करता और आपको फ्लैग्स देता है।

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

क्वांटाइजेशन प्रत्येक वेट (weight) को 16 या 32 बिट्स से घटाकर 4, 5 या 8 बिट्स में बदल देता है। यही वह प्रक्रिया है जिससे 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 होता है)। आपके लिए कुछ भी अनुमानित नहीं होता।

Ollama के साथ क्वांटाइजेशन उस टैग के साथ आता है जिसे आप पुल (pull) करते हैं, और 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 टोकन का डॉक्यूमेंट भेजते हैं, तो मॉडल के देखने से पहले ही अतिरिक्त टोकन हटा दिए जाते हैं, जिससे मॉडल उस फाइल के बारे में गलत उत्तर देता है जिसे उसने आधा ही पढ़ा है। इसे डेमन (daemon) पर 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 को disk से वापस पढ़ना पड़ता है, इसलिए धीमी storage पर 4.58 GiB का reload दो सेकंड के उत्तर को तीस सेकंड में बदल देता है। एक लंबा keep-alive latency को ठीक करता है और स्थायी रूप से RAM का उपयोग करता है। दोनों ही वास्तविक लागतें हैं। वह चुनें जो कम नुकसानदेह हो। यदि आप निर्णय लेते हैं कि model को resident रहना चाहिए, तो keep_alive को सेट करना ताकि यह idle अवधि और reboot के दौरान बना रहे में केवल कुछ लाइनें लगती हैं और हर बार box के restart होने पर आपको मैन्युअल रूप से model को warm करने की आवश्यकता नहीं पड़ती।

llama.cpp आपको कोई daemon नहीं देता है, इसलिए आप 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 अपने पूरे जीवनकाल के लिए model को hold करके रखती है। idle रहने पर कुछ भी unload नहीं होता है, जिसका अर्थ है कि कोई reload surprise नहीं होता और service को stop करने के अलावा memory को reclaim करने का कोई तरीका नहीं है। यदि unit लिखना आपके लिए नया है, तो यह VPS पर systemd के अंतर्गत अपनी स्वयं की services चलाने के समान ही पैटर्न है।

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

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

Ollama 127.0.0.1:11434 पर listen करता है। इसका OpenAI-compatible route http://localhost:11434/v1/chat/completions है, और यह इसके साथ-साथ /api/chat पर एक native API भी बनाए रखता है। एक Anthropic-compatible route भी document किया गया है।

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"}]}'

llama-server, 127.0.0.1:8080 पर listen करता है और /v1/chat/completions, /v1/completions तथा /v1/embeddings सर्व करता है, साथ ही इसका अपना /completion endpoint और एक built-in web UI भी है। यह ऐसे operational routes भी expose करता है जो Ollama में नहीं हैं: readiness probe के लिए /health, loaded model की settings के लिए /props, प्रत्येक request slot क्या कर रहा है इसके लिए /slots, और Prometheus format में /metrics। यदि आप इस service को monitor करने की योजना बना रहे हैं, तो शायद यही अंतर निर्णय लेने का आधार होगा।

कोई भी सर्वर आपके लिए authentication चालू नहीं करता है। सुरक्षा कारणों से दोनों default रूप से loopback पर रहते हैं। इन्हें SSH tunnel के माध्यम से या reverse proxy के पीछे से access करें, और कभी भी 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 टोकन तक बोलने वाला मॉडल बॉक्स को तीन मिनट के लिए व्यस्त रखता है, इसलिए 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 को पिन करना

दोनों projects में साप्ताहिक बदलाव होते हैं, इसलिए जो version आपने deploy किया है उसका record रखें। Upstream one-liner वर्तमान build को इंस्टॉल करता है:

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

किसी विशिष्ट build को पिन करने के लिए, इसके बजाय releases page से prebuilt tarball लें। 2 August 2026 तक build b10224 वर्तमान tag है:

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'

या source से उसी tag को build करें:

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 features के लिए documented dependency है। Compile होने में कई मिनट लगते हैं और इसके लिए सबसे छोटे plans की तुलना में अधिक RAM की आवश्यकता होती है। यदि छोटा server memory कम पड़ने के कारण fail हो जाए, तो किसी बड़े box पर build करें और binaries को copy कर लें।

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 run इस तरह की एक पंक्ति दिखाता है:

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

Ollama लोड करने से पहले आकार की जाँच करता है, इसलिए यह तुरंत विफल हो जाता है और कारण बताता है। एक क्वांटाइजेशन स्तर नीचे जाएँ, कॉन्टेक्स्ट लेंथ कम करें, या कोई छोटा मॉडल चुनें।

llama.cpp विफल नहीं होता, बल्कि बहुत धीमा हो जाता है। llama.cpp डिफ़ॉल्ट रूप से GGUF को मेमोरी-मैप करता है, इसलिए RAM से बड़ी फ़ाइल भी शुरू हो जाती है। इसके बाद कर्नल हर टोकन पर डिस्क से वेट्स (weights) को पेज-इन और पेज-आउट करता है, और जनरेशन की गति प्रति टोकन कई सेकंड तक गिर जाती है जबकि डिस्क 100 प्रतिशत उपयोग पर पिन हो जाती है। वास्तविक एलोकेशन को बाध्य करने के लिए --no-mmap पास करें ताकि यह खराब प्रदर्शन करने के बजाय तुरंत विफल हो जाए। जब कर्नल हस्तक्षेप करता है, तो dmesg कारण दिखाता है:

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

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

error loading model architecture: unknown model architecture: 'qwen3next'

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

API स्थानीय रूप से उत्तर देता है लेकिन आपके ऐप से नहीं। Ollama 127.0.0.1:11434 पर बाइंड होता है, इसलिए दूसरे होस्ट को 'connection refused' मिलता है। OLLAMA_HOST=0.0.0.0:11434 को केवल तभी systemctl edit ollama पर सेट करें जब पोर्ट किसी फ़ायरवॉल या प्राइवेट नेटवर्क के पीछे हो, क्योंकि API के सामने कोई प्रमाणीकरण (authentication) नहीं होता है।

विराम के बाद पहला उत्तर बहुत धीमा है। 5 मिनट का आइडल अनलोड हो गया है और मॉडल को फिर से डिस्क से पढ़ा जा रहा है। अनुरोध से ठीक पहले चलाया गया 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 के रूप में सूचीबद्ध किया गया है (2 अगस्त 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 वाले VPS पर कौन सा अधिक तेज़ है?

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

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

हाँ। फाइल को सर्वर पर रखें, एक 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 के साथ scale होता है: 32,768 token context पर वही model अकेले लगभग 4 GiB cache लेता है। Ollama के साथ, याद रखें कि आवश्यकता OLLAMA_NUM_PARALLEL के साथ भी scale होती है।