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 के डिफॉल्ट मॉडल 4-बिट क्वांटाइज्ड (Q4 लेबल वाले) होते हैं, जो प्रति बिलियन पैरामीटर लगभग आधा गीगाबाइट RAM लेते हैं। इसलिए गणित सरल है और यही सब कुछ तय करता है। अंतिम शब्द वह है जिसे आप स्वयं सेट करते हैं: 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, लॉगिन, रेट लिमिट या अलाउ-लिस्ट नहीं है। जो कोई भी port 11434 तक पहुँच सकता है, वह आपके द्वारा डाउनलोड किए गए किसी भी मॉडल को चला सकता है, नए मॉडल डाउनलोड कर सकता है, उन्हें हटा सकता है, और आपके CPU या GPU को अनिश्चित काल के लिए पूर्ण लोड पर डाल सकता है। Shodan जैसे स्कैनर हजारों खुले Ollama इंस्टेंस को इंडेक्स करते हैं, और एक खुला हुआ इंस्टेंस कुछ ही घंटों में खोज लिया जाता है और उसका दुरुपयोग किया जाता है।

इसलिए एक गलती कभी न करें: OLLAMA_HOST=0.0.0.0 को set करके अपने firewall में 11434 को open न करें। इससे बिना authentication वाला inference server पूरे internet पर public हो जाता है। Raw 11434-on-0.0.0.0 को कोई भी configuration सुरक्षित नहीं बना सकती, क्योंकि Ollama में configuration के लिए ऐसा कुछ है ही नहीं; authentication मौजूद ही नहीं है। यह नियम केवल इस particular service पर लागू होता है। इसका अर्थ यह नहीं है कि कोई port कभी open नहीं करना चाहिए: remote desktop के लिए self-hosted RustDesk relay को अपना काम करने के लिए public traffic स्वीकार करना ही होगा। यह अपनी key-based authentication और documented ports की छोटी सूची उपलब्ध कराकर ऐसा करता है। Ollama में इनमें से कुछ भी नहीं है।

सर्वर के अलावा किसी अन्य स्थान से मॉडल तक पहुँचने के तीन सुरक्षित तरीके हैं:

• इसे लोकल रखें। यदि एकमात्र कॉलर उसी VPS पर कोई अन्य प्रोग्राम, क्रॉन स्क्रिप्ट, बॉट, या आपके टूल्स को मॉडल से जोड़ने वाला MCP सर्वर है, तो बाइंड को 127.0.0.1 पर रहने दें और उस प्रोग्राम को http://127.0.0.1:11434 पर कॉल करने दें। कुछ भी एक्सपोज़ नहीं होता है और किसी अन्य चीज़ की आवश्यकता नहीं होती है।
• इसे प्राइवेट टनल के माध्यम से एक्सेस करें। VPS को अपने द्वारा होस्ट किए गए WireGuard VPN पर रखें, OLLAMA_HOST को टनल एड्रेस (उदाहरण के लिए 10.8.0.1, न कि 0.0.0.0) पर सेट करें, और केवल VPN पीयर्स ही कनेक्ट कर पाएंगे। सार्वजनिक इंटरनेट को 11434 पर कुछ भी दिखाई नहीं देगा।
• इसके सामने एक प्रमाणीकरण करने वाला रिवर्स प्रॉक्सी रखें। TLS को टर्मिनेट करें और nginx, Traefik, या Caddy पर पासवर्ड या टोकन की आवश्यकता रखें, फिर 127.0.0.1:11434 पर प्रॉक्सी करें। Ollama अपना localhost बाइंड बनाए रखता है; प्रॉक्सी ही एकमात्र ऐसी चीज़ है जो सार्वजनिक पोर्ट पर लिसन कर रही है। यह किसी भी लोकल सर्विस के सामने nginx पर Let’s Encrypt सर्टिफिकेट लगाने जैसा ही है।

रिवर्स-प्रॉक्सी विकल्प बिल्कुल वही है जो चैट 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 का उपयोग करता है, इसलिए अधिकांश OpenAI client libraries दो बदलाव करने के बाद काम करती हैं: base URL और एक throwaway key।

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, try pulling it first प्राप्त होगा। एक साधारण 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 पर develop कर रहे हैं, तो एक local model scripts और plugins को support कर सकता है, जैसे कि tmux के अंदर VPS पर चल रहा Claude Code, जिससे सस्ता और निजी drafting work paid API से बाहर रहता है, जबकि भारी reasoning के लिए hosted model का उपयोग किया जा सकता है।

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

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

"Error: model requires more system memory"। Ollama मॉडल को शुरू करने से मना कर देता है और Error: model requires more system memory (X GiB) than is available (Y GiB) प्रिंट करता है। यह ऊपर दिए गए क्रैश का विनम्र संस्करण है: Ollama ने गणना की और OOM killer के आने से पहले ही रुक गया। यह आपको वे दो संख्याएँ भी देता है। ऐसा मॉडल चुनें जिसकी आवश्यकता आपकी खाली RAM (free -h से जाँचें) से कम हो, context length को कम करें, या बड़े VPS पर जाएँ। कोई भी flag मॉडल को फिट नहीं कर सकता, मेमोरी की सीमा वास्तविक है।

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

सब कुछ बस धीमा है। बिना किसी त्रुटि के प्रति सेकंड दस या उससे कम टोकन। यह CPU inference है जो वही कर रहा है जो CPU inference करता है। ollama ps में 100% CPU दिखाई देता है, जिसका अर्थ है कि कोई GPU नहीं है। यह कोई बग नहीं है और कोई सेटिंग इसे ठीक नहीं कर सकती, क्योंकि सीमा मेमोरी बैंडविड्थ है, न कि गलत कॉन्फ़िगरेशन। एक छोटा मॉडल उपयोग करें, गति स्वीकार करें, या GPU इंस्टेंस पर जाएँ, और कुछ भी खराब होने का निर्णय लेने से पहले --verbose के साथ अपनी वास्तविक दर मापें। जब प्रतीक्षा दर के बजाय उत्तर की लंबाई के कारण हो, तो num_predict के साथ उत्तर को सीमित करना उन मॉडलों को, जो बहुत अधिक बोलने के आदी हैं, उन टोकनों पर मिनटों बर्बाद करने से रोकता है जिन्हें आप कभी पढ़ने वाले नहीं थे।

दूसरी मशीन से Connection refused। अपने लैपटॉप से आपको curl: (7) Failed to connect to <ip> port 11434: Connection refused मिलता है। यह डिज़ाइन के अनुसार काम कर रहा है: Ollama केवल localhost पर bind होता है। इसे 0.0.0.0 पर bind करके "ठीक" न करें, जो कि ऊपर बताई गई exposure की गलती है। मॉडल तक VPN के माध्यम से या authenticating proxy के जरिए पहुँचें।

आपने 11434 को इंटरनेट पर expose कर दिया है। यदि आपने OLLAMA_HOST=0.0.0.0 सेट किया है, फायरवॉल खोला है, और अब ऐसे मॉडल pulls देख रहे हैं जिन्हें आपने शुरू नहीं किया था या अज्ञात क्लाइंट्स द्वारा CPU 100% पर पिन किया हुआ है, तो आपको खोज लिया गया है और आपका उपयोग किया गया है। यह मुख्य गलती है, न कि कोई मामूली मामला। वापस 127.0.0.1 या VPN एड्रेस पर bind करें, फायरवॉल पर 11434 को बंद करें, और सामने authentication लगाएँ। यह मान लें कि उस एड्रेस पर जो कुछ भी पहुँच योग्य था, जब वह खुला था, तो उसे अजनबियों द्वारा क्वेरी किया गया है।

Backups and upgrades

खोने के लिए बहुत कम state होती है। 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 .

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

FAQ

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

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

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

डिफ़ॉल्ट 4-bit quantized models के लिए एक सामान्य नियम यह है: weights के लिए प्रति बिलियन parameters लगभग 0.5 GB RAM, साथ ही लगभग 1 GB overhead और 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 तक पहुँच सकता है, उसका इस पर पूर्ण नियंत्रण होता है। यही कारण है कि यह डिफ़ॉल्ट रूप से 127.0.0.1 पर bind होता है और आपको कभी भी 11434 को 0.0.0.0 पर इंटरनेट के लिए expose नहीं करना चाहिए। इसे स्थानीय रूप से, private VPN के माध्यम से, या ऐसे reverse proxy के जरिए एक्सेस करें जो लॉगिन की सुविधा देता हो।

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

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

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

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