VPS वर Ollama सुरक्षितपणे कसे होस्ट करावे

तुम्ही काय तयार करणार आहात

तुमच्या मालकीच्या सर्व्हरवर चालणारे एक open-weight language model, ज्याला HTTP API द्वारे वापरता येईल. हवे असल्यास ब्राउझरमध्ये chat page देखील देता येईल. Ollama हे model download करते, ते memory मध्ये load करते आणि http://127.0.0.1:11434 वर requests स्वीकारते. Installation साठी एकच command पुरेसा आहे. या प्रक्रियेतील कठीण भाग इतरत्र आहेत: तुमच्या VPS च्या RAM मध्ये प्रत्यक्ष मावेल असे model निवडणे आणि authentication नसलेला inference server चुकून संपूर्ण internet वर प्रकाशित न करणे.

सुरुवातीला दोन महत्त्वाच्या सूचना. CPU-only VPS वर small models धीम्या गतीने चालतात. तसेच API मध्ये built-in authentication अजिबात नाही. या दोन्ही बाबींचे खाली सविस्तर वर्णन केले आहे, कारण याच ठिकाणी गंभीर समस्या निर्माण होऊ शकतात.

आकाराचा वास्तव तपास, साध्या आकड्यांत

मॉडेलचा memory footprint साधारणपणे त्याच्या file size एवढा असतो. त्यात runtime overhead साठी सुमारे 1 gigabyte आणि context window साठी आणखी काही memory लागते. Ollama चे default models 4-bit quantized असतात. त्यांना Q4 असे label केलेले असते. प्रत्येक 1 billion parameters साठी साधारण 0.5 gigabyte RAM लागते. त्यामुळे गणित सोपे आहे आणि सर्व निर्णय त्यावर अवलंबून असतात.

llama3.2:3b सारखे 3B model सुमारे 2 GB download असते आणि ते चालवण्यासाठी सुमारे 4 GB free RAM लागते. mistral:7b किंवा llama3.1:8b सारखे 7B किंवा 8B model disk वर सुमारे 5 GB जागा घेतात. त्यांना सुमारे 8 GB RAM लागते; 16 GB असल्यास ते सुरळीत चालतात. 13B किंवा 14B model साठी साधारण 16 GB RAM लागते. 30B ते 70B range मधील कोणत्याही model साठी मोठ्या RAM चा box किंवा प्रत्यक्षात GPU आवश्यक असतो. CPU VPS वर ते बसणार नाहीत किंवा इतक्या धीम्या गतीने उत्तर देतील की त्यांचा उपयोग होणार नाही.

आता speed बद्दल पाहू. हा भाग लोक बहुतेक वेळा कमी लेखतात. CPU inference हे clock speed पेक्षा memory bandwidth वर अधिक अवलंबून असते. Shared vCPU VPS मध्ये ही bandwidth मर्यादित असते. Single-digit ते low-double-digit tokens per second अशी गती अपेक्षित ठेवा. 7-8B Q4 model साधारण 4 ते 10 tokens per second देऊ शकते. 3B model 10 ते 25 tokens per second देऊ शकते. GPU साधारणपणे यापेक्षा एका order of magnitude ने जलद असतो. हे आकडे मुद्दाम अंदाजे दिले आहेत. स्वतःच्या box ची मोजणी करणे हाच योग्य मार्ग आहे. खालील run step मध्ये ते कसे करायचे ते दाखवले आहे. कोणत्याही article मधील आकड्यावर, यासह, विश्वास ठेवू नका. आपल्या eval rate वर विश्वास ठेवा.

व्यावहारिक निष्कर्ष असा आहे: वेग मर्यादित असला तरी तो स्वीकारता येत असल्यास CPU वर चालणारी लहान quantized models drafting, summarizing आणि classification साठी खरोखर उपयुक्त ठरतात. त्यापेक्षा मोठे किंवा जलद model हवे असल्यास GPU instance साठी budget ठेवा.

विशिष्ट model ची विशिष्ट box शी तुलना करण्यासाठी त्याचा memory footprint येथे अंदाजित करा:

Ollama स्थापित करा

यासाठी दोन योग्य पद्धती आहेत. स्वतंत्र VPS वर अधिकृत script वापरणे ही सर्वात सोपी पद्धत आहे:

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

यामुळे ollama नावाचा system user तयार होतो, binary /usr/local/bin/ollama येथे स्थापित होते आणि ollama.service नावाची systemd service नोंदवली जाते. ही service boot वेळी सुरू होते आणि 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 होतो. सुरक्षा विभागात ज्या चुकीबद्दल इशारा दिला आहे, ती हीच आहे. एकच installation पद्धत निवडा. script आणि container एकाच वेळी चालवू नका; अन्यथा दोन्ही process port साठी संघर्ष करतात.

तुमचे पहिले model डाउनलोड करून चालवा

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

pull model चे layers disk वर डाउनलोड करते. या model साठी ते सुमारे 2 GB आहे. run हे layers memory मध्ये load करते आणि तुम्हाला >>> prompt दाखवते. प्रश्न टाइप करा. Weights disk मधून RAM मध्ये load होत असताना पहिला token येण्यासाठी काही सेकंद लागू शकतात. त्यानंतर उत्तर stream होते. Chat मधून बाहेर पडण्यासाठी /bye टाइप करा. Ollama background मध्ये सुरू राहते.

काय load झाले आहे आणि ते कसे कार्य करते ते पहा:

ollama ps

PROCESSOR column वस्तुस्थिती दाखवतो. 100% CPU म्हणजे GPU वापरला जात नाही. त्यामुळेच वेग कमी आहे. verbose flag वापरून प्रत्यक्ष वेग मोजा:

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

शेवटी छापली जाणारी eval rate line या hardware वरील तुमचा tokens per second वेग दाखवते. नियोजन करताना हाच आकडा आधार म्हणून वापरा.

मॉडेल कुठे साठवले जातात आणि किती डिस्क घ्यावी

स्क्रिप्टद्वारे स्थापित करून सेवा म्हणून चालवलेले मॉडेल ollama वापरकर्त्याच्या home मध्ये साठवले जातात:

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

तुमच्या स्वतःच्या वापरकर्त्याच्या खात्याने परस्परसंवादी पद्धतीने चालवल्यास ते ~/.ollama/models मध्ये साठवले जातात. कंटेनरमध्ये ते ollama named volume मध्ये साठवले जातात. हे महत्त्वाचे आहे, कारण quantized weights ची एकूण डिस्क-वापराची मात्रा वेगाने वाढते: 3B मॉडेल सुमारे 2 GB, 7-8B मॉडेल सुमारे 5 GB आणि 14B मॉडेल सुमारे 9 GB असते. तुलना करण्यासाठी चार मॉडेल डाउनलोड केल्यास लक्षात न येता 20 GB जागा वापरली जाते. ठेवायच्या मॉडेलसाठी पुरेशी डिस्क जागा नियोजित करा आणि उरलेली मॉडेल्स ollama rm <model> ने हटवा. त्याच VPS वर एखादी मोठी डिस्क-जागा वापरणारी सेवा आधीपासून चालत असल्यास, उदाहरणार्थ PhotoPrism किंवा फोटो लायब्ररी साठवणारे Immich, आधी ती जागा मोकळ्या डिस्कमधून वजा करा आणि उरलेली जागा तुमचे वास्तविक मॉडेल बजेट माना.

तुमच्या नियंत्रणाखाली सेवा म्हणून चालवा

इन्स्टॉल स्क्रिप्टने ollama.service आधीच नोंदणीकृत केले आहे. त्यामुळे पुढील कोणतेही काम न करता ते boot वेळी पुन्हा सुरू होते. बदलण्यासारखी सेटिंग म्हणजे model किती वेळ memory मध्ये ठेवायचा आणि काही setup मध्ये 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 म्हणजे शेवटच्या request नंतर model किती वेळ memory मध्ये राहतो (default 5 minutes). दिवसभर ज्या box ला query केले जाते, तिथे weights प्रत्येक वेळी पुन्हा load होऊ नयेत म्हणून हे मूल्य वाढवा. RAM मर्यादित असलेल्या box वर request पूर्ण होताच RAM मोकळी करण्यासाठी ते 0 वर सेट करा. systemctl edit unit files तुमच्यासाठी पुन्हा load करते. त्यामुळे बदल लागू करण्यासाठी सेवा restart करा:

sudo systemctl restart ollama

सर्वाधिक महत्त्वाचा सुरक्षा मुद्दा

मूलभूतरित्या Ollama 127.0.0.1:11434 वर bind होते. त्यामुळे फक्त VPS वरील process तिच्यापर्यंत पोहोचू शकतात. ही default setting योग्य आहे. ती तशीच ठेवा.

API मध्ये authentication नाही. अजिबात नाही. API key नाही, login नाही, rate limit नाही आणि allow-list नाही. पोर्ट 11434 पर्यंत पोहोचू शकणारा कोणीही तुम्ही pull केलेले कोणतेही model चालवू शकतो, नवीन model pull करू शकतो, model delete करू शकतो आणि तुमचा CPU किंवा GPU अनिश्चित काळासाठी पूर्ण क्षमतेने वापरू शकतो. Shodan सारखे scanner उघड्या Ollama instance ची हजारोंच्या संख्येने नोंद करतात. उघडा instance काही तासांत शोधला जाऊन त्याचा गैरवापर होतो.

म्हणून एकच गंभीर चूक कधीही करू नका: `OLLAMA_HOST=0.0.0.0 सेट करून firewall मध्ये 11434 उघडू नका. असे केल्यास authentication नसलेला inference server संपूर्ण इंटरनेटसाठी सार्वजनिक होतो. raw 11434-on-0.0.0.0` सुरक्षित करण्यासाठी कितीही configuration केले, तरी उपयोग नाही, कारण Ollama मध्ये configure करण्यासारखी कोणतीही authentication व्यवस्था नाही; authentication अस्तित्वातच नाही. हा नियम या विशिष्ट सेवेसाठी आहे. याचा अर्थ पोर्ट कधीही उघडू नये असा नाही: remote desktop साठी self-hosted RustDesk relay आपले कार्य करण्यासाठी सार्वजनिक network traffic स्वीकारणे आवश्यक आहे. त्यासाठी त्यात स्वतःची key-based authentication आणि ports ची छोटी, दस्तऐवजीकृत यादी आहे. Ollama मध्ये यापैकी काहीही नाही.

Box व्यतिरिक्त इतर ठिकाणाहून model पर्यंत पोहोचण्याचे तीन सुरक्षित मार्ग आहेत:

• स्थानिक प्रवेश ठेवा. दुसरा program त्याच VPS वर चालत असेल, जसे cron script, bot किंवा तुमची tools model शी जोडणारा MCP server, तर bind 127.0.0.1 वरच ठेवा आणि त्या program कडून http://127.0.0.1:11434 ला call करा. काहीही सार्वजनिकपणे उघड होत नाही आणि इतर कशाचीही आवश्यकता नसते.
• Private tunnel द्वारे पोहोचा. VPS ला तुम्ही स्वतः host केलेल्या WireGuard VPN मध्ये जोडा, OLLAMA_HOST ला tunnel address द्या, उदाहरणार्थ 10.8.0.1, 0.0.0.0 नाही. त्यानंतर फक्त VPN peer कनेक्ट होऊ शकतात. Public internet वरून 11434 वरील काहीही दिसत नाही.
• Authentication असलेला reverse proxy समोर ठेवा. nginx, Traefik किंवा Caddy वर TLS termination करा आणि password किंवा token आवश्यक ठेवा. त्यानंतर 127.0.0.1:11434 कडे proxy करा. Ollama चे localhost bind तसेच राहते. Public port वर listening करणारी एकमेव सेवा proxy असते. कोणत्याही local service समोर nginx वर Let's Encrypt certificate ठेवण्यासारखी हीच रचना आहे.

Reverse-proxy पर्याय पुढे chat UI मध्ये उपलब्ध आहे आणि त्यासोबत प्रत्यक्ष login जोडलेले आहे.

TLS मागे Open WebUI सह chat UI जोडा

Open WebUI हा self-hosted chat interface आहे. तो 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 flag हा महत्त्वाचा तपशील आहे. यामुळे container host च्या network namespace मध्ये चालतो. त्यामुळे container मधील 127.0.0.1 हे host च्या स्वतःच्या loopback कडे निर्देश करते आणि container Ollama पर्यंत 127.0.0.1:11434 द्वारे पोहोचतो. यासाठी Ollama ला इतर कोणत्याही interface वर listening ठेवण्याची गरज नसते. इतरत्र दिलेली bridge-network पद्धत, म्हणजे --add-host=host.docker.internal:host-gateway सह OLLAMA_BASE_URL=http://host.docker.internal:11434, येथे कार्य करत नाही. त्या पद्धतीत ते नाव Docker bridge gateway कडे resolve होते. Host वर 127.0.0.1 वर bind केलेली सेवा bridge द्वारे पोहोचण्यायोग्य नसते. त्यामुळे Open WebUI Ollama शी connect होत नसल्याचे दाखवत राहते.

Host networking चा तोटा असा आहे की Open WebUI आता host च्या 8080 port वर प्रत्येक interface वर listening करते. कोणतेही -p mapping दुर्लक्षित केले जाते आणि Docker तसे सांगणारी warning दाखवते. त्यामुळे host firewall आणि provider firewall या दोन्ही ठिकाणी 8080 बंद करा. TLS reverse proxy हाच एकमेव सार्वजनिक प्रवेशबिंदू ठेवा. पहिल्यांदा Open WebUI उघडल्यावर ते admin account तयार करण्यास सांगते. हे account तुमचा authentication layer असते. त्यामुळे मजबूत password निवडा.

HTTPS द्वारे laptop वरून chat उघडण्यासाठी 127.0.0.1:8080 च्या पुढे TLS reverse proxy ठेवा. या server वर आधीच अनेक Docker apps route करत असल्यास, अनेक apps साठी automatic TLS असलेले Traefik हा सर्वात योग्य पर्याय आहे. एका label block मधून certificate जारी करता येतो आणि chat.example.com Open WebUI कडे route करता येतो. Security section मधील नियम येथेही लागू राहतो. Public port आणि login यांचे नियंत्रण proxy कडे असते, तर Ollama localhost वरच राहते आणि Open WebUI चा स्वतःचा 8080 firewall ने संरक्षित राहतो.

तुमच्या code मधून OpenAI-compatible endpoint वापरा

Ollama /v1 येथे OpenAI chat API चा काही भाग उपलब्ध करून देते. त्यामुळे base URL आणि तात्पुरती 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 ते दुर्लक्षित करते. त्यामुळे कोणतीही string चालते. model हे तुम्ही आधीच pull केलेल्या model चे नाव असणे आवश्यक आहे. अपरिचित नाव दिल्यास 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"}]}'

Agent आणि editor tooling मध्ये model जोडण्यासाठीही हीच पद्धत वापरता येते. तुम्ही या box वर आधीच development करत असल्यास, स्थानिक model scripts आणि plugins साठी VPS वर tmux मध्ये चालणाऱ्या Claude Code सोबत वापरता येतो. त्यामुळे स्वस्त आणि private drafting काम paid API शिवाय करता येते, तर जड reasoning hosted model कडे ठेवता येते.

तुम्हाला दिसणाऱ्या अचूक strings सह अपयशाच्या स्थिती

जनरेशनच्या मध्यावर प्रक्रिया "Killed" होते. तुम्ही मोठे मॉडेल सुरू करता आणि टर्मिनलमध्ये Killed दिसते किंवा सर्व्हर log मध्ये llama runner process has terminated: signal: killed दिसतो. मॉडेलला सर्व्हरवर उपलब्ध RAM पेक्षा जास्त RAM आवश्यक असल्यामुळे Linux OOM killer ने ती प्रक्रिया थांबवली. sudo dmesg | grep -i oom वापरून कारणाची पुष्टी करा. त्यात Out of memory: Killed process ... (ollama) सारखी ओळ दिसेल. यावर उपाय म्हणजे लहान किंवा अधिक quantized मॉडेल वापरणे. 13B ऐवजी llama3.2:3b वापरा. तसेच swap वाढवल्यास physical RAM पेक्षा थोडीच जास्त memory लागणारा load हळूवारपणे पूर्ण होऊ शकतो, प्रक्रिया बंद पडत नाही. Swap मुळे तात्काळ crash ऐवजी उत्तर मिळण्यास जास्त वेळ लागतो. मात्र 4 GB वर 70B मॉडेल व्यावहारिक बनत नाही. तुम्ही टर्मिनल पाहत असाल तरच ही प्रक्रिया बंद झाल्याचे लक्षात येते; अन्यथा kill कोणतीही सूचना न देता होते. त्यामुळे दुसऱ्या ठिकाणाहून query पाठवत असलेल्या सर्व्हरवर, OnFailure= unit ला ollama.service जोडून push alerts साठी तुम्ही host केलेल्या ntfy server वर सूचना पाठवा. त्यामुळे प्रक्रिया बंद होताच तुम्हाला कळते आणि पुढील request वेळीच हे लक्षात येण्याची गरज राहत नाही.

"Error: model requires more system memory". Ollama model सुरू करण्यास नकार देते आणि Error: model requires more system memory (X GiB) than is available (Y GiB) छापते. ही वरील crash ची सौम्य आवृत्ती आहे: OOM killer ला प्रक्रिया थांबवू देण्याऐवजी Ollama ने आवश्यक memory ची गणना करून सुरुवातीलाच थांबवले. त्यात आवश्यक memory आणि उपलब्ध memory हे दोन आकडेही दिलेले असतात. तुमच्या free RAM पेक्षा कमी आवश्यकता असलेले model निवडा. free -h वापरून free RAM तपासा. Context length कमी करा किंवा मोठ्या VPS वर जा. कोणताही flag model ला उपलब्ध memory मध्ये बसवू शकत नाही. आवश्यक memory प्रत्यक्षात लागते.

पहिला token येण्यास खूप वेळ लागतो, त्यानंतर सर्व काही सुरळीत चालते. Cold model पहिल्यांदा सुरू होताना पाच ते तीस सेकंद काहीही output देत नाही. त्यानंतर तो नेहमीप्रमाणे stream करतो. या विलंबाचे कारण weights प्रथमच disk वरून RAM मध्ये load होणे हे आहे. Slow storage असल्यास हा विलंब वाढतो. एकदा load झाल्यानंतर model OLLAMA_KEEP_ALIVE च्या कालावधीपर्यंत memory मध्ये उपलब्ध राहतो. त्यामुळे दुसऱ्या prompt ला त्वरित उत्तर मिळते. हा पहिला load call path मधील एखाद्या timeout पेक्षा जास्त वेळ घेत असल्यास slow answer मिळण्याऐवजी error मिळतो. context deadline exceeded कोणत्या layer ने reported केले हे शोधणे यामुळे client, proxy किंवा model load यांपैकी कोणाची प्रतीक्षा-सीमा संपली ते समजते. या विलंबामुळे त्रास होत असल्यास ती value वाढवा. सध्या model load आहे का हे पाहण्यासाठी ollama ps वापरा.

सगळेच फक्त धीमे चालते. कोणतीही error न दाखवता प्रति सेकंद दहा किंवा त्यापेक्षा कमी tokens मिळतात. हे CPU inference कडून अपेक्षितच आहे. ollama ps मध्ये 100% CPU दिसते. याचा अर्थ GPU उपलब्ध नाही. ही bug नाही आणि कोणतीही setting ती दूर करू शकत नाही, कारण मर्यादा memory bandwidth ची आहे, misconfiguration ची नाही. लहान model वापरा, हा वेग स्वीकारा किंवा GPU instance वर जा. काहीही बिघडले आहे असे ठरवण्यापूर्वी --verbose वापरून प्रत्यक्ष rate मोजा.

दुसऱ्या machine वरून connection refused मिळते. Laptop वरून तुम्हाला curl: (7) Failed to connect to <ip> port 11434: Connection refused मिळते. हे अपेक्षेप्रमाणेच आहे: Ollama फक्त localhost वर bind होते. 0.0.0.0 वर bind करून हे "दुरुस्त" करू नका. वर वर्णन केलेली exposure ची हीच चूक आहे. VPN किंवा authentication करणाऱ्या proxy द्वारे model पर्यंत पोहोचा.

तुम्ही 11434 इंटरनेटवर उघडे ठेवले. तुम्ही OLLAMA_HOST=0.0.0.0 सेट केले, firewall उघडला आणि आता स्वतः सुरू न केलेले model pulls किंवा अज्ञात clients मुळे CPU 100% वापरात असल्याचे दिसत असेल, तर तुमचा server शोधून त्याचा वापर करण्यात आला आहे. ही मुख्य चूक आहे; हा एखादा दुर्मिळ edge case नाही. 127.0.0.1 किंवा VPN address वर पुन्हा bind करा, firewall मध्ये 11434 बंद करा आणि पुढे authentication लावा. हा address उघडा असताना त्यावर पोहोचणारी कोणतीही गोष्ट अनोळखी लोकांनी query केली असे गृहीत धरा.

बॅकअप आणि अपग्रेड

गमावण्यासारखी state फार कमी आहे. Models पुन्हा download करता येतात. त्यामुळे बॅकअप घेण्यासारख्या गोष्टी म्हणजे Open WebUI चा data volume, accounts, chat history, settings आणि तुम्ही तयार केलेला systemd drop-in. तात्पुरत्या container च्या मदतीने volume चा बॅकअप घ्या:

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

Install script पुन्हा चालवून Ollama चे upgrade करा. docker pull ghcr.io/open-webui/open-webui:main चालवल्यानंतर container पुन्हा तयार करून Open WebUI चे upgrade करा. दीर्घकाळासाठी कोणतीही आवृत्ती pin करू नका. Models ची quality आणि runtime दोन्ही वेगाने बदलतात. त्यामुळे release notes वाचा आणि तुमच्या स्वतःच्या box वर पुन्हा benchmark करा. मागील quarter मधील आकड्यांवर अवलंबून राहू नका.

FAQ

मी CPU-only VPS वर LLM खरोखर चालवू शकतो का?

होय, काही मर्यादांसह. 3B ते 8B श्रेणीतील लहान quantized models CPU वर चालतात आणि मसुदा तयार करणे, सारांश तयार करणे आणि वर्गीकरण यांसाठी प्रत्यक्षात उपयुक्त ठरतात. मात्र shared vCPU वर त्यांचा वेग कमी असतो आणि साधारणपणे प्रति सेकंद single-digit ते low-double-digit tokens मिळतात. 13B किंवा त्यापेक्षा मोठे model अत्यंत धीमे असतात किंवा RAM मध्ये मावतातच असे नाही. प्रत्यक्षात चांगला वेग किंवा मोठे models हवे असल्यास GPU instance आवश्यक आहे.

प्रत्येक model साठी किती RAM आवश्यक असते?

default 4-bit quantized models साठी साधारण नियम असा आहे: weights साठी प्रति billion parameters सुमारे 0.5 GB RAM, त्यासोबत अंदाजे 1 GB overhead आणि context साठी थोडी अधिक RAM. त्यामुळे 3B model साठी सुमारे 4 GB मोकळी RAM, 7-8B model साठी सुमारे 8 GB आणि 14B model साठी सुमारे 16 GB आवश्यक असते. free -h वापरून उपलब्ध headroom तपासा आणि operating system तसेच server वरील इतर घटकांसाठी जागा ठेवा.

Ollama API authenticated आहे का?

नाही. Ollama मध्ये built-in authentication, API key किंवा rate limit नाही. port 11434 पर्यंत पोहोचू शकणाऱ्या कोणत्याही व्यक्तीकडे त्याचे पूर्ण नियंत्रण असते. म्हणूनच ते default म्हणून 127.0.0.1 वर bind होते आणि 0.0.0.0 वर 11434 इंटरनेटसाठी कधीही उघडा ठेवू नये. त्याच्यापर्यंत स्थानिक पातळीवर, private VPN द्वारे किंवा login जोडणाऱ्या reverse proxy मार्फत पोहोचा.

web chat interface कसे जोडायचे?

--network=host वापरून Open WebUI Docker मध्ये चालवा. त्यामुळे ते host चे loopback share करते आणि native Ollama वरील http://127.0.0.1:11434 पर्यंत पोहोचते. त्यानंतर laptop वरून access मिळवण्यासाठी त्याच्या 8080 port समोर TLS reverse proxy ठेवा. Firewall मध्ये 8080 बंद ठेवा, जेणेकरून proxy हाच एकमेव सार्वजनिक प्रवेशबिंदू राहील. Open WebUI चे स्वतःचे admin account login पुरवते. पहिल्यांदा सुरू करताना त्याचा password सेट करा.

माझ्या application मधून त्याला call कसे करायचे?

http://127.0.0.1:11434/v1 वरील OpenAI-compatible endpoint वापरा. कोणत्याही OpenAI SDK चा base URL त्या पत्त्यावर सेट करा. API key म्हणून कोणतीही string द्या, कारण ती दुर्लक्षित केली जाते. model हे तुम्ही pull केलेल्या model च्या नावावर सेट करा. base URL आणि key वगळता विद्यमान OpenAI code सहसा कोणताही बदल न करता चालतो.