VPS पर Ollama कैसे host करें और सुरक्षित रखें

आप क्या बना रहे हैं

एक single open-weight language model जो आपके अपने server पर चलेगा। आप इसे HTTP API के माध्यम से या अपने browser में chat page के जरिए एक्सेस कर सकते हैं। Ollama वह component है जो model को download करता है, उसे memory में load करता है, और http://127.0.0.1:11434 पर requests serve करता है। इसका installation केवल एक command है। इस प्रक्रिया के कठिन हिस्से अन्य जगह हैं: आपके VPS की RAM के अनुकूल model का चुनाव करना, और गलती से एक unauthenticated inference server को पूरी internet पर public कर देना।

सबसे पहले दो महत्वपूर्ण चेतावनियाँ। CPU-only VPS पर छोटे models भी slow चलते हैं, और API में कोई built-in authentication नहीं है। इन दोनों विषयों पर नीचे विस्तार से चर्चा की गई है, क्योंकि इन्हीं वजहों से अक्सर गलतियाँ होती हैं।

Sizing का वास्तविक आकलन, सरल अंकों में

किसी model का memory footprint लगभग उसका file size होता है, plus runtime overhead लगभग 1 GB, plus context window के लिए कुछ अतिरिक्त मेमोरी। Ollama के default models 4-bit quantized (Q4 label) होते हैं, जिसमें प्रति billion parameters लगभग आधा GB RAM खर्च होता है। इसलिए calculation सरल है, और यही सब कुछ तय करता है।

llama3.2:3b जैसा 3B model ~2 GB का download है और इसे run करने के लिए लगभग 4 GB free RAM चाहिए। mistral:7b या llama3.1:8b जैसा 7B या 8B model disk पर ~5 GB का है और इसे लगभग 8 GB RAM चाहिए, बेहतर performance के लिए 16 GB। 13B या 14B model को लगभग 16 GB चाहिए। 30B-to-70B range वाले किसी भी model के लिए large-RAM वाले system या, वास्तव में, GPU की आवश्यकता होती है — CPU VPS पर यह या तो fit नहीं होगा या इतना धीमा जवाब देगा कि वह useless होगा।

अब speed की बात करते हैं, क्योंकि लोग इसे अक्सर कम आंकते हैं। CPU inference memory bandwidth पर निर्भर करता है, clock speed पर नहीं, और shared vCPU VPS की bandwidth सीमित होती है। प्रति second single-digit से low-double-digit tokens की अपेक्षा करें: एक 7-8B Q4 model 4 से 10 tokens per second दे सकता है, और 3B model 10 से 25। GPU लगभग 10 गुना (an order of magnitude) तेज़ होता है। ये आंकड़े जानबूझकर अनुमानित रखे गए हैं — सही तरीका अपने स्वयं के system को measure करना है, जिसे नीचे दिए गए run step में दिखाया गया है। अपने eval rate पर भरोसा करें, किसी भी article के नंबर पर नहीं, यहाँ तक कि इस पर भी नहीं।

Practical निष्कर्ष: यदि आप गति (pace) को स्वीकार कर सकते हैं, तो CPU पर छोटे quantized models drafting, summarizing, और classification के लिए वास्तव में उपयोगी हैं। इससे बड़े या तेज़ काम के लिए, GPU instance का बजट रखें।

किसी विशिष्ट model की तुलना किसी विशिष्ट system से करने के लिए, यहाँ उसका memory footprint estimate करें:

Ollama Install करें

इसके दो सरल तरीके हैं। Bare VPS के लिए official script सबसे आसान है:

curl -fsSL https://ollama.com/install.sh | sh

यह ollama नाम का एक system user बनाता है, binary को /usr/local/bin/ollama में install करता है, और ollama.service नाम की एक systemd service register करता है। यह service boot पर start होती है और 127.0.0.1:11434 को bind करती है। Check करें कि यह चल रहा है या नहीं:

systemctl status ollama
ollama --version

यदि आप पहले से Docker का उपयोग कर रहे हैं, तो container का उपयोग करें:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Port mapping पर 127.0.0.1: prefix का ध्यान रखें। यह port को केवल localhost से bind करता है। -p 11434:11434 लिखने से यह हर interface पर publish हो जाता है, जो security section में बताई गई गलती है। कोई एक install method चुनें; script और container को एक साथ न चलाएं, अन्यथा दो processes port के लिए आपस में टकराएंगे।

अपना पहला model pull करें और run करें

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull model layers को disk पर download करता है (इस model के लिए लगभग 2 GB)। run उन्हें memory में load करता है और आपको >>> prompt पर ले जाता है। एक प्रश्न type करें। Weights के disk से RAM में load होने के कारण पहला token आने में कुछ सेकंड लग सकते हैं, उसके बाद उत्तर stream होने लगेगा। Chat से बाहर निकलने के लिए /bye type करें; Ollama background में चलता रहेगा।

देखें कि क्या load हुआ है और वह कैसे fit होता है:

ollama ps

PROCESSOR column सही जानकारी देता है। 100% CPU का मतलब है कि कोई GPU उपयोग नहीं हो रहा है, और इसी कारण गति धीमी है। Verbose flag के साथ वास्तविक speed मापें:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

अंत में printed eval rate line आपके इस hardware पर tokens per second दर्शाती है। योजना बनाने के लिए इसी number का उपयोग करें।

Models कहाँ रहते हैं, और कितनी disk खरीदनी चाहिए

Script द्वारा install होने और service के रूप में run होने पर, models ollama user के home directory में रहते हैं:

sudo du -sh /usr/share/ollama/.ollama/models

यदि आप अपने स्वयं के user के रूप में interactively run करते हैं, तो वे ~/.ollama/models में रहते हैं। Container के अंदर, वे ollama named volume में रहते हैं। यह महत्वपूर्ण है क्योंकि quantized weights बहुत तेज़ी से बढ़ते हैं: एक 3B model ~2 GB का है, 7-8B model ~5 GB का है, और 14B model ~9 GB का है। तुलना करने के लिए यदि आप चार models pull करते हैं, तो आपने बिना पता चले 20 GB खर्च कर दिए होंगे। केवल उन्हीं models के लिए disk size तय करें जिन्हें आप रखना चाहते हैं, और बाकी को ollama rm <model> से delete कर दें।

इसे एक नियंत्रित service के रूप में चलाएं

install script पहले से ही ollama.service को register कर चुका है, इसलिए यह बिना किसी अतिरिक्त कार्य के boot पर restart हो जाता है। बदलने योग्य setting यह है कि model कितनी देर तक resident रहता है, और कुछ setups में, bind address — इन दोनों को systemd drop-in में रखा जाता है ताकि Ollama upgrade इन्हें overwrite न कर दे:

sudo systemctl edit ollama.service

editor में दिखाए गए [Service] header के नीचे इसे जोड़ें:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE यह निर्धारित करता है कि last request के बाद model कितनी देर तक memory में रहता है (default 5 minutes)। यदि आप किसी server को दिन भर query करते हैं, तो हर बार weights को reload होने से बचाने के लिए इसे बढ़ा दें; RAM खाली करने के लिए कम resources वाले box पर इसे 0 पर set करें। systemctl edit आपके लिए unit files को reload करता है, इसलिए change लागू करने के लिए restart करें:

sudo systemctl restart ollama

सबसे महत्वपूर्ण सुरक्षा बिंदु

Default रूप से Ollama 127.0.0.1:11434 पर bind होता है, इसलिए केवल VPS पर चल रहे processes ही इसे एक्सेस कर सकते हैं। यह default सेटिंग सही है। इसे ऐसे ही रहने दें।

API में कोई authentication नहीं है। बिल्कुल नहीं। इसमें कोई API key, login, rate limit, या allow-list नहीं है। जो कोई भी port 11434 तक पहुँच सकता है, वह आपके द्वारा pull किए गए किसी भी model को चला सकता है, नए models pull कर सकता है, उन्हें delete कर सकता है, और आपके CPU या GPU को अनिश्चित काल के लिए full load पर रख सकता है। Shodan जैसे scanners हज़ारों open Ollama instances को index करते हैं, और एक exposed instance को घंटों के भीतर ढूँढकर उसका दुरुपयोग किया जा सकता है।

इसलिए, यह एक ऐसी गलती है जो कभी नहीं करनी चाहिए: OLLAMA_HOST=0.0.0.0 को set न करें और अपने firewall में 11434 को open न करें। ऐसा करने से एक unauthenticated inference server पूरे internet के लिए खुला हो जाता है। 0.0.0.0 पर raw 11434 को कोई भी configuration सुरक्षित नहीं बना सकता, क्योंकि Ollama में configure करने के लिए कुछ भी नहीं है — authentication का विकल्प ही मौजूद नहीं है।

Box के बाहर से model तक पहुँचने के तीन सुरक्षित तरीके यहाँ दिए गए हैं:

• इसे local रखें। यदि एकमात्र caller उसी VPS पर कोई दूसरा program है — जैसे कोई cron script, bot, या MCP server जो आपके tools को model से जोड़ता है — तो bind को 127.0.0.1 पर ही रहने दें और उस program को http://127.0.0.1:11434 call करने दें। कुछ भी expose नहीं होगा और किसी अन्य चीज़ की आवश्यकता नहीं होगी।
• एक private tunnel के माध्यम से एक्सेस करें। VPS को स्वयं होस्ट किए गए WireGuard VPN पर रखें, OLLAMA_HOST को tunnel address (उदाहरण के लिए 10.8.0.1, न कि 0.0.0.0) पर set करें, और केवल VPN peers ही connect कर पाएंगे। Public internet को 11434 पर कुछ भी दिखाई नहीं देगा।
• आगे एक authenticating reverse proxy लगाएँ। nginx, Traefik, या Caddy पर TLS terminate करें और password या token की आवश्यकता रखें, फिर 127.0.0.1:11434 पर proxy करें। Ollama अपने localhost bind को बनाए रखता है; proxy ही public port पर listen करने वाली एकमात्र चीज़ होती है। यह बिल्कुल वैसा ही है जैसे किसी local service के आगे nginx पर Let's Encrypt certificate लगाना।

Reverse-proxy विकल्प वही है जो अगला chat UI आपको एक वास्तविक login के साथ प्रदान करता है।

TLS के पीछे Open WebUI के साथ chat UI जोड़ें

Open WebUI एक self-hosted chat interface है। इसे Docker में चलाएं और इसे local Ollama से जोड़ें:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Linux VPS के लिए --network=host flag सबसे महत्वपूर्ण है। यह container को host के network namespace में डाल देता है, जिससे container के अंदर 127.0.0.1 host का अपना loopback बन जाता है। इससे container बिना किसी अन्य interface पर listen किए, 127.0.0.1:11434 पर Ollama तक पहुँच जाता है। अन्य जगहों पर दिखने वाला bridge-network तरीका — --add-host=host.docker.internal:host-gateway के साथ OLLAMA_BASE_URL=http://host.docker.internal:11434 — यहाँ काम नहीं करेगा: वह name Docker bridge gateway को resolve करता है, और host पर 127.0.0.1 पर bound service को bridge के माध्यम से एक्सेस नहीं किया जा सकता। इस कारण Open WebUI Ollama से connect न हो पाने का error दिखाता है।

Host networking का नुकसान यह है कि Open WebUI अब हर interface पर host के port 8080 पर listen करता है; कोई भी -p mapping काम नहीं करेगी, और Docker इसके बारे में एक warning देगा। इसलिए host और provider firewall दोनों पर 8080 को बंद कर दें और TLS reverse proxy को ही एकमात्र public access रखें। पहली बार visit करने पर Open WebUI आपसे admin account बनाने को कहेगा — वह account आपका authentication layer है, इसलिए एक strong password चुनें।

अपने laptop से HTTPS के माध्यम से chat खोलने के लिए, 127.0.0.1:8080 के आगे एक TLS reverse proxy लगाएं। यदि आप पहले से ही machine पर कई Docker apps route कर रहे हैं, तो कई apps के लिए automatic TLS के साथ Traefik सबसे अच्छा विकल्प है: एक label block certificate जारी करता है और chat.example.com को Open WebUI तक route करता है। Security section का नियम यहाँ भी लागू होता है — proxy के पास public port और login होता है, जबकि Ollama localhost पर रहता है और Open WebUI का अपना 8080 firewalled रहता है।

अपने code से OpenAI-compatible endpoint का उपयोग करें

Ollama, /v1 पर OpenAI chat API का एक subset उपयोग करता है। इसलिए, base URL और एक dummy key बदलकर अधिकांश OpenAI client libraries का उपयोग किया जा सकता है।

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

Client library के लिए api_key आवश्यक है, लेकिन Ollama इसे ignore कर देता है, इसलिए कोई भी string काम करेगी। model वही name होना चाहिए जिसे आपने पहले से pull किया हो; अज्ञात name होने पर model "x" not found, try pulling it first error मिलता है। एक साधारण curl call भी इसी तरह काम करता है:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

Agent और editor tooling में model को जोड़ने का तरीका भी यही है। यदि आप पहले से ही उस machine पर development कर रहे हैं, तो local model का उपयोग scripts और plugins को चलाने के लिए किया जा सकता है। यह tmux के अंदर VPS पर running Claude Code के साथ मिलकर काम कर सकता है। इससे भारी reasoning के लिए hosted model का उपयोग होता है, जबकि सस्ता और private drafting work local model पर रहता है।

Failure modes, with the exact strings you will see

The process is "Killed" mid-generation. आप एक बड़ा model शुरू करते हैं और terminal Killed प्रिंट करता है, या server log में llama runner process has terminated: signal: killed दिखता है। Linux OOM killer ने इसे रोक दिया क्योंकि model को box की available RAM से अधिक memory की आवश्यकता थी। sudo dmesg | grep -i oom से कारण की पुष्टि करें, जहाँ आपको Out of memory: Killed process ... (ollama) जैसी line दिखेगी। समाधान एक छोटा या अधिक heavily quantized model है — 13B के बजाय llama3.2:3b — या swap जोड़ना, ताकि physical RAM से थोड़ा अधिक load होने पर भी process धीरे-धीरे चलता रहे और crash न हो। Swap एक instant crash को slow answer में बदल देता है; यह 4 GB पर 70B model को practical नहीं बनाता।

"Error: model requires more system memory". Ollama model को start करने से मना कर देता है और Error: model requires more system memory (X GiB) than is available (Y GiB) प्रिंट करता है। यह ऊपर बताए गए crash का एक विनम्र version है: Ollama ने calculation की और OOM killer को काम करने देने के बजाय खुद process रोक दिया। यह आपको दो numbers भी देता है। ऐसा model चुनें जिसकी requirement आपकी free RAM से कम हो (free -h से check करें), context length कम करें, या बड़े VPS पर जाएँ। कोई भी flag model को fit नहीं बना सकता — memory की कमी वास्तविक है।

The first token takes forever, then it is fine. एक cold model पांच से तीस सेकंड तक कुछ भी print नहीं करता, फिर सामान्य रूप से stream करता है। वह pause weights के disk से RAM में पहली बार load होने के कारण होता है, और slow storage इसे और खराब कर देता है। एक बार load होने के बाद, model OLLAMA_KEEP_ALIVE तक resident रहता है, इसलिए दूसरा prompt तुरंत answer देता है। यदि gaps आपको परेशान करते हैं, तो उस value को बढ़ाएँ, और यह देखने के लिए कि क्या model currently loaded है, ollama ps का उपयोग करें।

Everything is simply slow. Ten tokens per second या उससे कम, बिना किसी error के। यह CPU inference का सामान्य व्यवहार है। ollama ps में 100% CPU दिखता है, जिसका अर्थ है कि कोई GPU नहीं है। यह कोई bug नहीं है और कोई setting इसे ठीक नहीं कर सकती, क्योंकि सीमा memory bandwidth की है, misconfiguration की नहीं। छोटे model का उपयोग करें, speed को स्वीकार करें, या GPU instance पर जाएँ — और कुछ भी खराब मानने से पहले अपनी real rate को --verbose से मापें।

Connection refused from another machine. अपने laptop से आपको curl: (7) Failed to connect to <ip> port 11434: Connection refused मिलता है। यह design के अनुसार ही काम कर रहा है: Ollama केवल localhost पर bind होता है। इसे 0.0.0.0 पर bind करके "fix" न करें, क्योंकि यह ऊपर बताई गई exposure mistake है। इसके बजाय VPN या authenticating proxy के माध्यम से model तक पहुँचें।

You exposed 11434 to the internet. यदि आपने OLLAMA_HOST=0.0.0.0 set किया है, firewall खोला है, और अब आपको वे model pulls दिख रहे हैं जो आपने शुरू नहीं किए थे या unknown clients द्वारा CPU 100% पर है, तो आपकी security breach हो चुकी है। यह एक मुख्य गलती है, कोई edge case नहीं। 127.0.0.1 या VPN address पर rebind करें, firewall पर 11434 को बंद करें, और आगे authentication लगाएँ। मान लें कि जब वह address खुला था, तब उस पर पहुँचने वाले किसी भी request को strangers ने query किया था।

Backups and upgrades

Data loss का जोखिम बहुत कम है। Models को दोबारा download किया जा सकता है, इसलिए केवल Open WebUI के data volume — accounts, chat history, settings — और आपके द्वारा लिखे गए किसी भी systemd drop-in को backup करना ही आवश्यक है। एक throwaway container का उपयोग करके volume को backup करें:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Install script को दोबारा चलाकर Ollama को upgrade करें; Open WebUI को docker pull ghcr.io/open-webui/open-webui:main के साथ upgrade करें और फिर container को recreate करें। किसी भी चीज़ को long-term के लिए pin न करें: model quality और runtime दोनों तेज़ी से बदलते हैं, इसलिए पिछले quarter के numbers पर भरोसा करने के बजाय release notes पढ़ें और अपने स्वयं के box पर re-benchmark करें।

FAQ

क्या मैं वास्तव में CPU-only VPS पर LLM चला सकता हूँ?

हाँ, कुछ सीमाओं के भीतर। 3B से 8B रेंज के छोटे quantized models CPU पर चलते हैं। ये drafting, summarizing, और classification के लिए उपयोगी हैं — लेकिन shared vCPU पर इनकी गति धीमी होगी (single-digit से low-double-digit tokens per second)। 13B या उससे बड़े models बहुत धीमे चलते हैं या RAM में फिट नहीं होते। बेहतर speed या बड़े models के लिए आपको GPU instance की आवश्यकता होगी।

प्रत्येक model को कितनी RAM चाहिए?

Default 4-bit quantized models के लिए एक सामान्य नियम: weights के लिए प्रति billion parameters लगभग 0.5 GB RAM, plus लगभग 1 GB overhead और context के लिए कुछ अतिरिक्त RAM। इसलिए, 3B model के लिए लगभग 4 GB free RAM, 7-8B model के लिए लगभग 8 GB, और 14B model के लिए लगभग 16 GB चाहिए। free -h के साथ अपना headroom चेक करें और operating system व अन्य processes के लिए पर्याप्त space छोड़ें।

क्या Ollama API authenticated है?

नहीं। Ollama में कोई built-in authentication, API key, या rate limit नहीं है — जो भी port 11434 तक पहुँच सकता है, उसका उस पर पूरा नियंत्रण होगा। इसी कारण यह default रूप से 127.0.0.1 पर bind होता है और आपको 11434 को 0.0.0.0 पर internet के लिए कभी भी expose नहीं करना चाहिए। इसे locally, private VPN के माध्यम से, या किसी reverse proxy के जरिए एक्सेस करें जो login की सुविधा देता हो।

मैं web chat interface कैसे जोड़ूँ?

Open WebUI को Docker में --network=host के साथ चलाएँ ताकि यह host का loopback share कर सके और http://127.0.0.1:11434 पर native Ollama तक पहुँच सके। फिर अपने laptop से access करने के लिए इसके port 8080 के आगे एक TLS reverse proxy लगाएँ। Firewall में 8080 को बंद रखें ताकि proxy ही एकमात्र public door रहे। Open WebUI का अपना admin account login प्रदान करता है, और आप पहली बार launch करते समय इसका password सेट करते हैं।

मैं इसे अपने स्वयं के application से कैसे call करूँ?

http://127.0.0.1:11434/v1 पर मौजूद OpenAI-compatible endpoint का उपयोग करें। किसी भी OpenAI SDK को उस base URL पर point करें, API key के रूप में कोई भी string पास करें (क्योंकि इसे ignore किया जाता है), और model को उस name पर सेट करें जिसे आपने pull किया है। मौजूदा OpenAI code आमतौर पर base URL और key के अलावा बिना किसी बदलाव के चलता है।