VPS पर Ollama कैसे होस्ट करें: सुरक्षित सेटअप गाइड

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

एक सिंगल open-weight language model जिसे आप अपने सर्वर पर चलाते हैं, जो एक HTTP API के माध्यम से उत्तर देता है और यदि आप चाहें, तो आपके ब्राउज़र में एक chat page भी उपलब्ध कराता है। Ollama वह टूल है जो model को डाउनलोड करता है, उसे memory में लोड करता है और http://127.0.0.1:11434 पर requests को सर्व करता है। इसका इंस्टॉलेशन केवल एक command का काम है। इस प्रक्रिया की जटिलता अन्य पहलुओं में है: ऐसा model चुनना जिसे आपका VPS वास्तव में RAM में रख सके, और गलती से एक unauthenticated inference server को पूरी इंटरनेट पर public न कर देना।

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

साइजिंग का वास्तविक आकलन, स्पष्ट आंकड़ों में

किसी मॉडल का मेमोरी फुटप्रिंट मोटे तौर पर उसकी फाइल साइज, लगभग एक गीगाबाइट रनटाइम ओवरहेड, और कॉन्टेक्स्ट विंडो के लिए कुछ अतिरिक्त मेमोरी का योग होता है। अधिकांश लोकप्रिय Ollama मॉडल्स के डिफॉल्ट टैग्स, जिनमें llama3.2:3b, llama3.1:8b और mistral:7b शामिल हैं, 4-बिट क्वांटाइज्ड (Q4_K_M लेबल वाले) होते हैं। यह प्रति बिलियन पैरामीटर लगभग आधा गीगाबाइट RAM की खपत करते हैं। हर डिफॉल्ट Q4 नहीं होता: smollm2:135m जैसे छोटे मॉडल्स 16-बिट पर आते हैं, इसलिए गणना करने से पहले मॉडल के लाइब्रेरी पेज पर क्वांटाइजेशन लाइन की जांच करें। गणित सरल है और यही सब कुछ तय करता है। अंतिम पैरामीटर वह है जिसे आप स्वयं सेट करते हैं: Ollama के छोटे डिफॉल्ट से num_ctx बढ़ाना लंबे प्रॉम्प्ट्स के लिए जगह तो बनाता है, लेकिन यह RAM में KV कैश को बढ़ा देता है। इसलिए, यह तय करने से पहले कि मॉडल फिट होगा या नहीं, एक कॉन्टेक्स्ट लेंथ निर्धारित कर लें।

llama3.2:3b जैसा 3B मॉडल लगभग 2 GB की डाउनलोड फाइल है और इसे चलाने के लिए लगभग 4 GB फ्री RAM चाहिए। mistral:7b या llama3.1:8b जैसा 7B या 8B मॉडल डिस्क पर लगभग 5 GB का होता है और इसे चलाने के लिए लगभग 8 GB RAM की आवश्यकता होती है, जबकि 16 GB RAM होने पर यह बेहतर काम करता है। 13B या 14B मॉडल के लिए लगभग 16 GB RAM चाहिए। 30B से 70B रेंज का कोई भी मॉडल चलाने के लिए अधिक RAM वाले सर्वर या व्यावहारिक रूप से एक GPU की आवश्यकता होती है। CPU VPS पर यह या तो फिट नहीं होगा या इतना धीमा चलेगा कि इसका कोई उपयोग नहीं रह जाएगा।

अब गति की बात करते हैं, क्योंकि लोग इसे कम आंकते हैं। CPU इन्फरेंस मेमोरी बैंडविड्थ से सीमित होता है, क्लॉक स्पीड से नहीं, और एक शेयर्ड vCPU VPS की बैंडविड्थ सीमित होती है। प्रति सेकंड सिंगल-डिजिट से लेकर लो-डबल-डिजिट टोकन्स की उम्मीद रखें: एक 7-8B Q4 मॉडल शायद 4 से 10 टोकन्स प्रति सेकंड दे सके, और 3B मॉडल 10 से 25 टोकन्स। GPU की गति लगभग दस गुना अधिक होती है। ये आंकड़े जानबूझकर अनुमानित दिए गए हैं, सबसे सही तरीका यह है कि आप अपने सर्वर पर स्वयं मापें, जिसे नीचे दिए गए रन स्टेप में बताया गया है। किसी भी लेख में दिए गए नंबर के बजाय, जिसमें यह लेख भी शामिल है, अपने eval rate पर भरोसा करें।

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

किसी विशिष्ट मॉडल की तुलना अपने सर्वर से करने के लिए, यहाँ उसका मेमोरी फुटप्रिंट अनुमानित करें:

Ollama इंस्टॉल करें

इसे इंस्टॉल करने के दो साफ-सुथरे तरीके हैं। एक bare VPS पर आधिकारिक स्क्रिप्ट सबसे सरल है:

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

यह ollama नाम का एक system user बनाता है, binary को /usr/local/bin/ollama में इंस्टॉल करता है, और ollama.service नामक एक systemd service को रजिस्टर करता है जो बूट होने पर start हो जाती है और 127.0.0.1:11434 पर bind होती है। पुष्टि करें कि यह चल रही है:

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 हो जाएगा, जो कि वह गलती है जिसके बारे में सुरक्षा अनुभाग चेतावनी देता है। इंस्टॉल करने का कोई एक तरीका चुनें; स्क्रिप्ट और container को एक ही समय पर न चलाएं, अन्यथा दो processes एक ही port के लिए संघर्ष करेंगी।

अपना पहला मॉडल पुल और रन करें

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

pull मॉडल लेयर्स को डिस्क पर डाउनलोड करता है (इस मॉडल के लिए लगभग 2 GB)। run उन्हें मेमोरी में लोड करता है और आपको >>> प्रॉम्प्ट पर ले आता है। एक प्रश्न टाइप करें। डिस्क से RAM में वेट्स (weights) लोड होने के कारण पहले टोकन में कुछ सेकंड लग सकते हैं, उसके बाद उत्तर स्ट्रीम होने लगेगा। चैट से बाहर निकलने के लिए /bye टाइप करें; Ollama बैकग्राउंड में चलता रहता है।

देखें कि क्या लोड है और यह कैसे फिट होता है:

ollama ps

PROCESSOR कॉलम सही जानकारी देता है। 100% CPU का अर्थ है कि कोई GPU उपयोग में नहीं है, और यही धीमेपन का कारण है। verbose फ्लैग के साथ वास्तविक गति मापें:

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

अंत में प्रिंट की गई eval rate लाइन इस हार्डवेयर पर आपकी टोकन्स प्रति सेकंड की गति है। इसी संख्या के आधार पर योजना बनाएं।

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

Script द्वारा install किए जाने और service के रूप में चलने पर, models ollama user की home directory में रहते हैं:

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

अपने user के रूप में interactively चलाने पर, वे ~/.ollama/models में रहते हैं। Container के भीतर वे ollama नामक volume में रहते हैं। यह महत्वपूर्ण है क्योंकि quantized weights का आकार जल्दी बढ़ जाता है: एक 3B model लगभग 2 GB का होता है, 7-8B लगभग 5 GB का, और 14B लगभग 9 GB का। तुलना करने के लिए चार models download करें और आप बिना ध्यान दिए 20 GB खर्च कर चुके होंगे। डिस्क का आकार उन models के अनुसार तय करें जिन्हें आप रखना चाहते हैं, और बाकी को ollama rm <model> से delete कर दें। यदि उसी VPS पर पहले से ही कोई ऐसी सेवा चल रही है जो बहुत अधिक storage लेती है, जैसे कि PhotoPrism या Immich जो photo library रखते हैं, तो पहले उसे खाली जगह में से घटा दें और जो बचे उसे ही अपना वास्तविक model budget मानें।

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

इंस्टॉल स्क्रिप्ट ने पहले ही ollama.service को रजिस्टर कर दिया है, इसलिए यह बिना किसी अतिरिक्त कार्य के बूट होने पर रीस्टार्ट हो जाता है। जिस सेटिंग को बदलना उचित है, वह यह है कि कोई मॉडल कितनी देर तक मेमोरी में रहता है, और कुछ सेटअप पर, bind address। ये दोनों एक systemd drop-in में जाते हैं ताकि Ollama अपग्रेड इन्हें ओवरराइट न करे:

sudo systemctl edit ollama.service

इसे उस [Service] हेडर के नीचे जोड़ें जिसे एडिटर आपको दिखाता है:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE यह निर्धारित करता है कि अंतिम अनुरोध के बाद मॉडल कितनी देर तक मेमोरी में रहता है (डिफ़ॉल्ट 5 मिनट है)। यदि आप दिन भर क्वेरी करते हैं, तो हर बार वेट्स (weights) को रीलोड करने से बचने के लिए इसे बढ़ा दें; यदि आपके पास RAM कम है, तो अनुरोध समाप्त होते ही मेमोरी खाली करने के लिए इसे 0 पर सेट करें। यदि आप चाहते हैं कि कोई मॉडल एक निश्चित समय के बजाय हमेशा मेमोरी में रहे, तो Ollama मॉडल को हमेशा लोड रखना विषय में प्रति-अनुरोध keep_alive फ़ील्ड और रीबूट के बाद पहली धीमी रिक्वेस्ट के बजाय वेट्स को पहले से तैयार रखने की जानकारी दी गई है। systemctl edit आपके लिए यूनिट फ़ाइलों को रीलोड करता है, इसलिए बदलाव लागू करने के लिए रीस्टार्ट करें:

sudo systemctl restart ollama

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

डिफ़ॉल्ट रूप से Ollama 127.0.0.1:11434 पर बाइंड होता है, इसलिए केवल VPS पर चल रही प्रक्रियाएं ही इसे एक्सेस कर सकती हैं। यह डिफ़ॉल्ट सेटिंग सही है। इसे ऐसे ही रहने दें।

इस API में कोई प्रमाणीकरण (authentication) नहीं है। बिल्कुल भी नहीं। इसमें न तो कोई API key है, न लॉगिन, और न ही कोई rate limit। इसमें केवल एक allow-list है, OLLAMA_ORIGINS, जो केवल यह नियंत्रित करती है कि कौन से ब्राउज़र ओरिजिन इसे कॉल कर सकते हैं (CORS); यह curl या किसी अन्य मशीन पर चल रही स्क्रिप्ट को रोकने के लिए कुछ नहीं करती। जो कोई भी port 11434 तक पहुँच सकता है, वह आपके द्वारा डाउनलोड की गई किसी भी model को चला सकता है, नई model डाउनलोड कर सकता है, उन्हें हटा सकता है, और आपके CPU या GPU को अनिश्चित काल के लिए पूर्ण लोड पर डाल सकता है। Shodan जैसे स्कैनर हजारों खुले Ollama इंस्टेंस को इंडेक्स करते हैं, और एक exposed इंस्टेंस कुछ ही घंटों में खोज लिया जाता है और उसका दुरुपयोग किया जाता है।

इसलिए, यह वह एक गलती है जिसे कभी न करें: OLLAMA_HOST=0.0.0.0 को सेट न करें और अपने firewall में 11434 को न खोलें। ऐसा करने से एक बिना प्रमाणीकरण वाला inference server पूरी इंटरनेट दुनिया के लिए खुल जाता है। 0.0.0.0 पर raw 11434 को सुरक्षित बनाने का कोई तरीका नहीं है, क्योंकि Ollama की किसी भी documented सेटिंग में local API के लिए प्रमाणीकरण नहीं जोड़ा गया है, और एक ओरिजिन allow-list लॉगिन नहीं है। यह नियम विशेष रूप से इस सेवा के लिए है, न कि किसी पोर्ट को खोलने पर पूर्ण प्रतिबंध: remote desktop के लिए एक self-hosted RustDesk relay को अपना काम करने के लिए public traffic स्वीकार करना पड़ता है, और वह ऐसा इसलिए कर पाता है क्योंकि उसमें अपना key-based प्रमाणीकरण और पोर्ट्स की एक संक्षिप्त, documented सूची होती है, जो Ollama में बिल्कुल नहीं है।

VPS के बाहर से model तक पहुँचने के तीन सुरक्षित तरीके हैं:

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

Reverse-proxy विकल्प ठीक वही है जो chat UI आपको आगे प्रदान करता है, जिसमें एक वास्तविक लॉगिन जुड़ा होता है।

Open WebUI के साथ एक चैट UI जोड़ें, TLS के पीछे

Open WebUI एक self-hosted चैट इंटरफेस है। इसे Docker में चलाएं और 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 फ्लैग एक महत्वपूर्ण विवरण है। यह कंटेनर को होस्ट के नेटवर्क नेमस्पेस में डाल देता है, जिससे कंटेनर के अंदर का 127.0.0.1 होस्ट का अपना लूपबैक बन जाता है और कंटेनर Ollama तक 127.0.0.1:11434 पर पहुँच जाता है, बिना Ollama को किसी अन्य इंटरफेस पर लिसन कराए। ब्रिज-नेटवर्क रेसिपी जो आप कहीं और देखेंगे, --add-host=host.docker.internal:host-gateway और OLLAMA_BASE_URL=http://host.docker.internal:11434 के साथ, यहाँ काम नहीं करती है: वह नाम Docker ब्रिज गेटवे पर रिजॉल्व होता है, और होस्ट पर 127.0.0.1 से बाइंड की गई सर्विस ब्रिज के पार पहुँच योग्य नहीं होती, इसलिए Open WebUI बस यही रिपोर्ट करता रहता है कि वह Ollama से कनेक्ट नहीं हो पा रहा है।

होस्ट नेटवर्किंग का नुकसान यह है कि Open WebUI अब हर इंटरफेस पर होस्ट के पोर्ट 8080 पर लिसन करता है; कोई भी -p मैपिंग हटा दी जाती है, और Docker ऐसा होने पर एक चेतावनी देता है। इसलिए होस्ट और प्रोवाइडर दोनों के फायरवॉल पर 8080 को बंद कर दें और TLS रिवर्स प्रॉक्सी को ही एकमात्र पब्लिक द्वार रहने दें। पहली बार विजिट करने पर Open WebUI आपसे एक एडमिन अकाउंट बनाने के लिए कहेगा, वह अकाउंट आपकी ऑथेंटिकेशन लेयर है, इसलिए एक मजबूत पासवर्ड चुनें।

अपने लैपटॉप से HTTPS के माध्यम से चैट खोलने के लिए, 127.0.0.1:8080 के सामने एक TLS रिवर्स प्रॉक्सी रखें। यदि आप पहले से ही बॉक्स पर कई Docker ऐप्स को रूट करते हैं, तो कई ऐप्स पर ऑटोमैटिक TLS के साथ Traefik सबसे उपयुक्त है: एक लेबल ब्लॉक सर्टिफिकेट जारी करता है और chat.example.com को Open WebUI तक रूट करता है। वही लेबल-प्रति-ऐप रूटिंग वह तरीका है जिसका उपयोग बॉक्स पर मौजूद हर दूसरा ब्राउज़र फ्रंट-एंड करेगा, चाहे वह स्टेटस डैशबोर्ड हो या Halcyon, जो Jellyfin लाइब्रेरी को 90 के दशक के रेंटल स्टोर के रूप में प्रस्तुत करता है, प्रत्येक अपने स्वयं के होस्टनेम पर और अपने स्वयं के लॉगिन के पीछे। सुरक्षा अनुभाग का नियम अभी भी लागू होता है, प्रॉक्सी के पास पब्लिक पोर्ट और लॉगिन का स्वामित्व होता है, जबकि Ollama localhost पर रहता है और Open WebUI का अपना 8080 फायरवॉल के पीछे रहता है।

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

Ollama, /v1 पर OpenAI chat API के एक subset का समर्थन करता है, इसलिए base URL और एक throwaway 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)

api_key की आवश्यकता client library द्वारा होती है लेकिन Ollama इसे अनदेखा कर देता है, इसलिए कोई भी string काम करेगी। model वह नाम होना चाहिए जिसे आपने पहले ही pull कर लिया है; एक अज्ञात नाम model 'x' not found के साथ 404 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"}]}'

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

विफलता के प्रकार, सटीक strings के साथ जो आपको दिखाई देंगी

प्रक्रिया generation के बीच में ही "Killed" हो जाती है। आप एक बड़ा model start करते हैं और terminal Killed प्रिंट करता है, या server log (journalctl -u ollama) में llama-server process has terminated से शुरू होने वाली एक line दिखती है। Ollama 0.40.7 (21 अक्टूबर 2026 को जाँचा गया) में यही wording है; पुराने releases में llama runner process has terminated: signal: killed लिखा आता था। Linux OOM killer ने इसे रोक दिया क्योंकि model को box की उपलब्ध RAM से अधिक की आवश्यकता थी। sudo dmesg | grep -i oom के साथ कारण की पुष्टि करें, जहाँ आपको Out of memory: Killed process ... जैसी एक line दिखेगी। इसका समाधान एक छोटा या अधिक heavily quantized model है, जैसे 13B के बजाय llama3.2:3b, या swap जोड़ना ताकि जो load physical RAM से थोड़ा ही ऊपर है, वह crash होने के बजाय धीरे-धीरे चले। Swap एक instant crash को धीमी response में बदल देता है; यह 4 GB पर 70B model को व्यावहारिक नहीं बनाता। यह kill silent होती है जब तक कि आप terminal न देख रहे हों, इसलिए ऐसे box पर जिसे आप कहीं और से query करते हैं, ollama.service पर एक OnFailure= unit attach करें जो आपके द्वारा host किए गए ntfy server पर push alerts भेजे। इससे आपको इसके मरते ही पता चल जाएगा, बजाय इसके कि आप अगली request पर इसे discover करें।

Ollama model load करने से मना कर देता है। Request crash होने के बजाय तुरंत एक error के साथ fail हो जाती है, और server log में model is too large for system memory दर्ज होता है (Ollama 0.40.7, 21 अक्टूबर 2026 को जाँचा गया)। पुराने releases prompt पर ही Error: model requires more system memory (X GiB) than is available (Y GiB) प्रिंट करते थे। यह ऊपर बताए गए crash का विनम्र रूप है: Ollama ने गणना की और OOM killer को काम सौंपने के बजाय खुद रुक गया। ऐसा model चुनें जिसकी आवश्यकता आपकी free RAM से कम हो (free -h के साथ जाँचें), context length को छोटा करें, या बड़े VPS पर move करें। कोई भी flag model को fit नहीं करा सकता, memory वास्तविक है।

पहला token आने में बहुत समय लगता है, फिर सब ठीक हो जाता है। एक cold model पहली बार में पाँच से तीस सेकंड तक कुछ प्रिंट नहीं करता, फिर सामान्य रूप से stream करता है। वह pause weights के disk से RAM में पहली बार load होने का है, और slow storage इसे और खराब कर देता है। एक बार load होने के बाद, model OLLAMA_KEEP_ALIVE की अवधि तक resident रहता है, इसलिए दूसरा prompt तुरंत answer देता है। यदि वह पहला load call path में कहीं किसी timeout से अधिक समय लेता है, तो आपको धीमी response के बजाय error मिलता है, और यह पता लगाना कि किस layer ने context deadline exceeded रिपोर्ट किया आपको बताता है कि client, proxy, या load में से किसका धैर्य समाप्त हुआ। यदि ये अंतराल आपको परेशान करते हैं तो उस value को बढ़ाएं, और यह देखने के लिए कि क्या model वर्तमान में loaded है, ollama ps का उपयोग करें।

सब कुछ बस धीमा है। दस tokens प्रति सेकंड या उससे कम, बिना किसी error के। यह CPU inference है जो वही कर रहा है जो CPU inference करता है। ollama ps में 100% CPU दिखता है, जिसका अर्थ है कि कोई GPU नहीं है। यह कोई bug नहीं है, और कोई setting CPU को GPU में नहीं बदलती, क्योंकि मुख्य सीमा memory bandwidth है। VM पर एक setting test करने योग्य है: Ollama उन physical cores से अपना thread count चुनता है जिन्हें वह detect करता है, और hypervisor उन्हें गलत रिपोर्ट कर सकता है। एक ollama run --verbose session में, /set parameter num_thread 4 (या अपने vCPU count) को try करें, वही prompt फिर से चलाएं, और जो value सबसे अच्छा eval rate दे उसे रखें। इसके अलावा, छोटा model उपयोग करें, गति स्वीकार करें, या GPU instance पर move करें, और कुछ भी broken मानने से पहले --verbose के साथ अपनी वास्तविक दर मापें। जब प्रतीक्षा दर के बजाय उत्तर की लंबाई के कारण हो, तो num_predict के साथ reply को cap करना ऐसे model को, जो लंबी बातें करना पसंद करता है, उन tokens पर मिनटों खर्च करने से रोकता है जिन्हें आप कभी पढ़ने वाले नहीं थे।

दूसरी machine से Connection refused। आपके laptop से, एक current curl (8.23.0, 21 अक्टूबर 2026 को जाँचा गया) curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server प्रिंट करता है, और Ubuntu 24.04 में मौजूद curl 8.5.0 curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server प्रिंट करता है। "Connection refused" शब्द केवल तभी दिखाई देते हैं यदि आप -v जोड़ें, जो connect to <ip> port 11434 from ... failed: Connection refused वाली line में दिखता है। यह design के अनुसार काम कर रहा है: Ollama केवल localhost पर bind होता है। इसे 0.0.0.0 पर bind करके "ठीक" न करें, जो कि ऊपर बताया गया सटीक exposure mistake है। model तक VPN के माध्यम से या authenticating proxy के जरिए पहुँचें।

आपने 11434 को internet पर expose कर दिया। यदि आपने OLLAMA_HOST=0.0.0.0 set किया, firewall खोला, और अब ऐसे model pulls देख रहे हैं जो आपने शुरू नहीं किए थे या unknown clients द्वारा CPU को 100% पर pinned देख रहे हैं, तो आपको ढूँढ लिया गया है और आपका उपयोग किया गया है। यह मुख्य गलती है, न कि कोई edge case। 127.0.0.1 या VPN address पर rebind करें, firewall पर 11434 बंद करें, और सामने authentication लगाएँ। यह मान लें कि उस address पर जो कुछ भी reachable था, उसे अजनबियों द्वारा query किया गया है।

बैकअप और अपग्रेड

इसमें खोने के लिए बहुत कम स्टेट (state) होती है। मॉडल्स को दोबारा डाउनलोड किया जा सकता है, इसलिए केवल Open WebUI का डेटा वॉल्यूम, अकाउंट्स, चैट हिस्ट्री, सेटिंग्स और आपके द्वारा लिखे गए किसी भी systemd ड्रॉप-इन का बैकअप लेना ही सार्थक है। एक अस्थायी कंटेनर (throwaway container) का उपयोग करके वॉल्यूम का बैकअप लें:

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

Ollama को अपग्रेड करने के लिए इंस्टाल स्क्रिप्ट को दोबारा चलाएं; Open WebUI को अपग्रेड करने के लिए docker pull ghcr.io/open-webui/open-webui:main चलाएं और उसके बाद कंटेनर को फिर से बनाएं। 0.40 लाइन के लिए डिस्क संबंधी एक नोट: Ollama 0.40.2 ने पुराने वर्जन्स के साथ पुल किए गए मॉडल्स को बैकग्राउंड में अपग्रेड करना शुरू कर दिया था और मूल प्रतियों को बैकअप के रूप में रखा, इसलिए जब तक उन्हें हटाया नहीं जाता, वे अतिरिक्त डिस्क स्पेस लेती हैं, और 0.40.3 (11 अक्टूबर 2026) ने उस बैकग्राउंड अपग्रेड को रोक दिया था। अपग्रेड के बाद df -h की जाँच करें, और उन बैकअप्स को हटाने वाली कमांड के लिए रिलीज नोट्स पढ़ें। किसी भी चीज़ को लंबे समय के लिए पिन न करें: मॉडल की गुणवत्ता और रनटाइम दोनों तेजी से बदलते हैं, इसलिए रिलीज नोट्स पढ़ें और पिछली तिमाही के आंकड़ों पर भरोसा करने के बजाय अपने सिस्टम पर दोबारा बेंचमार्क करें।

FAQ

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

हाँ, सीमाओं के भीतर। 3B से 8B रेंज के छोटे quantized models CPU पर चल सकते हैं और ड्राफ्टिंग, सारांश बनाने और वर्गीकरण के लिए उपयोगी होते हैं। हालांकि, ये धीमे होते हैं और shared vCPU पर इनकी गति सिंगल-डिजिट या लो-डबल-डिजिट tokens प्रति सेकंड तक ही रहती है। 13B या उससे बड़े models या तो बहुत धीमे चलते हैं या RAM में फिट ही नहीं होते। वास्तविक गति या बड़े models के लिए आपको GPU instance की आवश्यकता होगी।

प्रत्येक model को कितनी RAM की आवश्यकता होती है?

4-bit (Q4) tags वाले सबसे लोकप्रिय models के लिए एक सामान्य नियम यह है: weights के लिए प्रति बिलियन पैरामीटर लगभग 0.5 GB RAM, साथ ही लगभग 1 GB ओवरहेड और context के लिए थोड़ा अतिरिक्त स्थान। इसलिए, एक 3B model के लिए लगभग 4 GB खाली RAM, 7-8B model के लिए लगभग 8 GB, और 14B model के लिए लगभग 16 GB की आवश्यकता होती है। free -h के साथ अपनी उपलब्ध RAM की जाँच करें और ऑपरेटिंग सिस्टम तथा अन्य कार्यों के लिए पर्याप्त जगह छोड़ें।

क्या Ollama API प्रमाणित (authenticated) है?

नहीं। Ollama में कोई इन-बिल्ट प्रमाणीकरण, API key या rate limit नहीं है। जो कोई भी port 11434 तक पहुँच सकता है, उसका इस पर पूर्ण नियंत्रण होता है। इसकी OLLAMA_ORIGINS सेटिंग केवल यह सीमित करती है कि कौन से ब्राउज़र ओरिजिन इसे कॉल कर सकते हैं, न कि कौन इससे कनेक्ट कर सकता है। यही कारण है कि यह डिफ़ॉल्ट रूप से 127.0.0.1 पर बाइंड होता है और आपको कभी भी 11434 को 0.0.0.0 पर इंटरनेट के लिए एक्सपोज़ नहीं करना चाहिए। इसे स्थानीय रूप से, प्राइवेट VPN के माध्यम से, या ऐसे reverse proxy के जरिए एक्सेस करें जो लॉगिन की सुविधा देता हो।

मैं वेब चैट इंटरफेस कैसे जोड़ूँ?

Open WebUI को Docker में --network=host के साथ चलाएं ताकि यह होस्ट के लूपबैक को शेयर कर सके और http://127.0.0.1:11434 पर नेटिव Ollama तक पहुँच सके। इसके बाद, अपने लैपटॉप से एक्सेस के लिए इसके port 8080 के सामने एक TLS reverse proxy लगाएं। फायरवॉल पर 8080 को बंद रखें ताकि केवल प्रॉक्सी ही एकमात्र सार्वजनिक द्वार रहे। Open WebUI का अपना एडमिन अकाउंट लॉगिन प्रदान करता है, और आप पहली बार लॉन्च करने पर इसका पासवर्ड सेट करते हैं।

मैं इसे अपने एप्लिकेशन से कैसे कॉल करूँ?

http://127.0.0.1:11434/v1 पर उपलब्ध OpenAI-compatible endpoint का उपयोग करें। किसी भी OpenAI SDK को उस बेस URL पर पॉइंट करें, API key के रूप में कोई भी स्ट्रिंग पास करें क्योंकि इसे अनदेखा कर दिया जाता है, और model को उस मॉडल के नाम पर सेट करें जिसे आपने पुल किया है। मौजूदा OpenAI कोड आमतौर पर बेस URL और की (key) को छोड़कर बिना किसी बदलाव के काम करता है।