VPS वर Ollama कसे होस्ट करायचे

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

तुमच्या स्वतःच्या सर्व्हरवर चालणारे एक single open-weight language model, जे HTTP API द्वारे आणि तुमच्या आवडीनुसार ब्राउझरमधील chat page द्वारे प्रतिसाद देते. Ollama हे असे साधन आहे जे model डाउनलोड करते, ते memory मध्ये लोड करते आणि http://127.0.0.1:11434 वर requests सर्व्ह करते. याची installation फक्त एका command ने होते. या प्रक्रियेतील कठीण गोष्टी इतर ठिकाणी आहेत: तुमच्या VPS च्या RAM मध्ये बसणारे model निवडणे आणि चुकून संपूर्ण इंटरनेटसाठी unauthenticated inference server उघडा ठेवणे.

सुरुवातीला दोन महत्त्वाच्या सूचना. फक्त CPU असलेला VPS लहान models अत्यंत संथ गतीने चालवतो, आणि API मध्ये कोणतेही built-in authentication उपलब्ध नाही. या दोन्ही गोष्टी खाली सविस्तरपणे दिल्या आहेत, कारण या दोन गोष्टींमुळेच वापरकर्त्यांना अडचणी येतात.

आकारमानाची वास्तववादी पडताळणी, साध्या आकड्यांमध्ये

मॉडेलचा मेमरी footprint हा साधारणपणे त्याच्या file size इतका असतो, त्यात runtime overhead म्हणून सुमारे एक GB आणि context window साठी काही अतिरिक्त मेमरी लागते. Ollama चे default मॉडेल्स 4-bit quantized (Q4 लेबल असलेले) असतात, ज्यासाठी प्रत्येक billion parameters साठी सुमारे अर्धा GB RAM लागतो. त्यामुळे हे गणित सोपे आहे आणि तेच सर्व काही ठरवते.

llama3.2:3b सारखे 3B मॉडेल डाउनलोड करण्यासाठी ~2 GB लागतात आणि चालवण्यासाठी सुमारे 4 GB free RAM आवश्यक असते. mistral:7b किंवा llama3.1:8b सारखे 7B किंवा 8B मॉडेल डिस्कवर ~5 GB घेतात आणि त्यांना सुमारे 8 GB RAM लागते, परंतु सुलभतेसाठी 16 GB आवश्यक आहेत. 13B किंवा 14B मॉडेलला साधारणपणे 16 GB लागतात. 30B ते 70B रेंजमधील कोणत्याही मॉडेलसाठी मोठ्या RAM असलेल्या सिस्टमची किंवा वास्तववादीपणे GPU ची गरज असते — CPU VPS वर ते एकतर बसणार नाही किंवा इतक्या संथ गतीने उत्तर देईल की ते निरुपयोगी ठरेल.

आता वेगाबद्दल, कारण लोक या गोष्टीचा अंदाज कमी लावतात. CPU inference हे clock speed पेक्षा memory bandwidth वर अवलंबून असते, आणि shared vCPU VPS ची bandwidth मर्यादित असते. प्रति सेकंद single-digit ते low-double-digit tokens ची अपेक्षा ठेवा: 7-8B Q4 मॉडेल कदाचित 4 ते 10 tokens प्रति सेकंद देऊ शकेल, तर 3B मॉडेल 10 ते 25 tokens देऊ शकेल. GPU साधारणपणे 10 पटीने वेगाने काम करते. हे आकडे जाणीवपूर्वक अंदाजे दिले आहेत — सर्वात अचूक पद्धत म्हणजे तुमच्या स्वतःच्या सिस्टमची मोजमाप करणे, जे खालील run स्टेपमध्ये कसे करायचे ते दाखवले आहे. कोणत्याही लेखातील आकड्यांवर, अगदी यावरील आकड्यांवरही, विश्वास ठेवण्याऐवजी तुमच्या eval rate वर विश्वास ठेवा.

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

एखाद्या विशिष्ट मॉडेलची तुमच्या विशिष्ट सिस्टमशी तुलना करण्यासाठी, त्याचा memory footprint येथे तपासा:

Ollama इंस्टॉल करा

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

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

यामुळे ollama नावाचा system user तयार होतो, /usr/local/bin/ollama मध्ये binary इंस्टॉल होते आणि 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 वापरले, तर तो सर्व interfaces वर publish होतो; security section मध्ये याबद्दल चेतावणी दिली आहे. एकच installation पद्धत निवडा; script आणि container एकाच वेळी चालवू नका, अन्यथा दोन processes मध्ये port साठी संघर्ष होईल.

तुमचे पहिले model pull आणि run करा

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

pull model layers डिस्कवर download करते (यासाठी सुमारे 2 GB लागतील). run त्यांना memory मध्ये load करते आणि तुम्हाला >>> prompt वर घेऊन जाते. एक प्रश्न टाईप करा. weights डिस्कमधून RAM मध्ये load होत असताना पहिला token मिळायला काही सेकंद लागू शकतात, त्यानंतर उत्तर stream होईल. चॅटमधून बाहेर पडण्यासाठी /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 आहेत. नियोजनासाठी याच आकड्याचा वापर करा.

मॉडेल्स कोठे साठवले जातात आणि किती डिस्क खरेदी करावी

स्क्रिप्टद्वारे इन्स्टॉल केलेले आणि service म्हणून चालणारे मॉडेल्स ollama युजरच्या home मध्ये असतात:

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

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

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

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

sudo systemctl restart ollama

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

By default Ollama 127.0.0.1:11434 ला bind होते, त्यामुळे फक्त त्याच VPS वरील processes त्याला reach करू शकतात. हे default सेटिंग योग्य आहे. ते तसेच ठेवा.

API मध्ये कोणतेही authentication नाही. अजिबात नाही. यामध्ये कोणतीही API key, login, rate limit किंवा allow-list नाही. जो कोणी port 11434 ला reach करू शकतो, तो तुम्ही pull केलेले कोणतेही model चालवू शकतो, नवीन models pull करू शकतो, ते delete करू शकतो आणि तुमच्या CPU किंवा GPU वर अमर्याद वेळेसाठी full load आणू शकतो. Shodan सारखे scanners हजारो open Ollama instances index करतात; एखादा exposed instance काही तासांतच शोधला जातो आणि त्याचा गैरवापर केला जातो.

त्यामुळे ही एक चूक कधीही करू नका: OLLAMA_HOST=0.0.0.0 सेट करू नका आणि तुमच्या firewall मध्ये 11434 open करू नका. यामुळे एक unauthenticated inference server संपूर्ण internet वर प्रकाशित होतो. 0.0.0.0 वर raw 11434 सुरक्षित करण्यासाठी कोणतीही configuration पुरेशी नाही, कारण Ollama मध्ये configure करण्यासाठी काहीच नाही — कारण तिथे authentication अस्तित्वातच नाही.

मशीनच्या बाहेरून model ला reach करण्याचे तीन सुरक्षित मार्ग आहेत:

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

पुढच्या टप्प्यात chat UI तुम्हाला reverse-proxy पर्यायच देते, ज्यामध्ये प्रत्यक्ष login जोडलेला असतो.

Open WebUI सह TLS मागे 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 ठरतो. यामुळे Ollama इतर कोणत्याही interface वर listen न करताही container द्वारे 127.0.0.1:11434 वर पोहोचू शकतो. इतरत्र दिसणारी bridge-network पद्धत — --add-host=host.docker.internal:host-gateway सह OLLAMA_BASE_URL=http://host.docker.internal:11434 — येथे काम करत नाही: ते नाव Docker bridge gateway कडे निर्देश करते, आणि host वरील 127.0.0.1 वर bound असलेली service bridge द्वारे पोहोचण्यायोग्य नसते. परिणामी Open WebUI Ollama ला connect होऊ शकत नाही असा error दाखवते.

Host networking चा तोटा असा आहे की Open WebUI आता प्रत्येक interface वर host च्या 8080 port वर listen करते; सर्व -p mapping रद्द केली जातात आणि Docker तसा warning संदेश देते. म्हणून host आणि provider firewall दोन्हीवर 8080 बंद करा आणि TLS reverse proxy ला एकमेव public door म्हणून वापरा. पहिल्या भेटीत Open WebUI तुम्हाला admin account तयार करण्यास सांगते — ते account तुमचे authentication layer असेल, म्हणून एक strong password निवडा.

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

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

Ollama /v1 वर OpenAI chat API चा एक उपसंच (subset) वापरते. त्यामुळे, 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 "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 जोडण्यासाठी हीच पद्धत वापरली जाते. जर तुम्ही आधीच त्या मशीनवर development करत असाल, तर tmux मध्ये VPS वर चालणाऱ्या Claude Code सोबत स्थानिक model वापरता येते. यामुळे महागड्या API शिवाय खाजगी ड्राफ्टिंगचे काम पूर्ण होते, तर जड reasoning साठी hosted model वापरता येते.

Failure modes, with the exact strings you will see

प्रक्रिया जनरेशन दरम्यान "Killed" होते. तुम्ही मोठे model सुरू करता आणि terminal मध्ये Killed प्रिंट होते, किंवा server log मध्ये llama runner process has terminated: signal: killed दिसते. Linux OOM killer ने ही प्रक्रिया थांबवली आहे कारण model ला उपलब्ध RAM पेक्षा जास्त मेमरीची गरज होती. sudo dmesg | grep -i oom वापरून कारणांची खात्री करा, तिथे तुम्हाला Out of memory: Killed process ... (ollama) सारखी ओळ दिसेल. उपाय म्हणून लहान किंवा अधिक heavily quantized model वापरा — 13B ऐवजी llama3.2:3b वापरा — किंवा swap वाढवा, जेणेकरून physical RAM च्या मर्यादेपेक्षा थोडी जास्त लोड असलेली प्रक्रिया मरण्याऐवजी हळूवारपणे पूर्ण होईल. Swap मुळे instant crash ऐवजी slow answer मिळतो; परंतु यामुळे 4 GB RAM वर 70B model वापरणे सोपे होत नाही.

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

पहिला token मिळण्यास खूप वेळ लागतो, त्यानंतर सर्व ठीक चालते. Cold model पाच ते तीस सेकंद काहीही प्रिंट करत नाही आणि त्यानंतर सामान्यपणे stream होते. ही प्रतीक्षा म्हणजे weights पहिल्यांदा disk मधून RAM मध्ये लोड होत असतात, आणि slow storage मुळे ही समस्या वाढते. एकदा लोड झाल्यावर, model OLLAMA_KEEP_ALIVE पर्यंत resident राहते, त्यामुळे दुसरा prompt लगेच उत्तर देतो. जर तुम्हाला ही वाट पाहण्याची वेळ त्रासदायक वाटत असेल, तर ती value वाढवा, आणि model सध्या लोड आहे की नाही हे पाहण्यासाठी ollama ps वापरा.

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

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

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

Backups and upgrades

येथे गमावण्यासाठी कमी डेटा आहे. मॉडेल्स पुन्हा डाउनलोड करता येतात, त्यामुळे फक्त Open WebUI चा data volume — म्हणजेच accounts, chat history, settings — आणि तुम्ही लिहिलेले कोणतेही systemd drop-in बॅकअप घेणे आवश्यक आहे. खालीलप्रमाणे throwaway container वापरून volume चा बॅकअप घ्या:

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

Ollama अपग्रेड करण्यासाठी install script पुन्हा रन करा; Open WebUI अपग्रेड करण्यासाठी docker pull ghcr.io/open-webui/open-webui:main वापरा आणि त्यानंतर container पुन्हा तयार करा. कोणत्याही गोष्टीला दीर्घकालीन पिन (pin) करू नका: model quality आणि runtime दोन्ही वेगाने बदलतात, त्यामुळे मागील तिमाहीच्या आकडेवारीवर अवलंबून राहण्याऐवजी release notes वाचा आणि तुमच्या स्वतःच्या मशीनवर पुन्हा benchmark करा.

FAQ

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

हो, काही मर्यादांसह. 3B ते 8B रेंजमधील लहान quantized मॉडेल्स CPU वर चालतात आणि drafting, summarizing आणि classification साठी उपयुक्त ठरतात — फक्त त्यांचा वेग कमी असतो. shared vCPU वर त्यांचा वेग single-digit किंवा low-double-digit tokens per second इतका असतो. 13B किंवा त्यापेक्षा मोठे मॉडेल्स अत्यंत संथ चालतात किंवा RAM मध्ये बसत नाहीत. अधिक वेगासाठी किंवा मोठ्या मॉडेल्ससाठी तुम्हाला GPU instance आवश्यक आहे.

प्रत्येक मॉडेलला किती RAM लागते?

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

Ollama API सुरक्षित (authenticated) आहे का?

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

मी web chat interface कसे जोडू?

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

मी माझ्या स्वतःच्या application मधून याला कसे कॉल करू?

http://127.0.0.1:11434/v1 वरील OpenAI-compatible endpoint वापरा. कोणत्याही OpenAI SDK ला तो base URL द्या, API key म्हणून कोणताही string द्या (कारण तो ignore केला जातो), आणि model ला तुम्ही pull केलेले मॉडेलचे नाव द्या. अस्तित्वात असलेला OpenAI कोड base URL आणि key सोडून इतर कोणत्याही बदलाशिवाय चालतो.