Jinsi ya kuendesha Ollama kwenye VPS kwa usalama

Unachojenga

Mfumo mmoja wa lugha (language model) wenye uzito huru unaoendeshwa kwenye seva unayomiliki, unaojibu kupitia HTTP API na, ukipenda, ukurasa wa gumzo kwenye kivinjari chako. Ollama ndicho kifaa kinachopakua model, kukiweka kwenye kumbukumbu (RAM), na kuhudumia maombi kwenye http://127.0.0.1:11434. Usakinishaji wake ni amri moja tu. Changamoto zote za kiufundi zipo kwingine: kuchagua model ambayo VPS yako inaweza kuhimili kwenye RAM, na kutochapisha kimakosa seva ya inference isiyo na uthibitisho (authentication) kwenye Internet nzima.

Maonyo mawili ya kweli kwanza. VPS inayotumia CPU pekee huendesha model ndogo polepole, na hakuna uthibitisho wa ndani kwenye API hata kidogo. Yote haya yamefafanuliwa kwa kina hapa chini, kwa sababu hapo ndipo watu wanapopata matatizo.

Ukweli wa vipimo kwa namba rahisi

Kiasi cha kumbukumbu kinachotumiwa na model ni takriban ukubwa wa faili yake, pamoja na takriban gigabyte moja ya ziada kwa ajili ya uendeshaji, na kiasi kingine kwa ajili ya context window. Model za kawaida za Ollama zimefanyiwa 4-bit quantization (zinazoitwa Q4), ambazo hutumia takriban nusu gigabyte ya RAM kwa kila bilioni moja ya parameters. Kwa hivyo, hesabu ni rahisi, na ndiyo inayopanga kila kitu.

Model ya 3B kama llama3.2:3b inahitaji takriban 2 GB ya download na inahitaji takriban 4 GB ya RAM iliyo wazi ili kufanya kazi. Model ya 7B au 8B kama mistral:7b au llama3.1:8b ina ukubwa wa takriban 5 GB kwenye diski na inahitaji takriban 8 GB ya RAM, huku 16 GB ikiwa ni bora zaidi. Model ya 13B au 14B inahitaji takriban 16 GB. Chochote kilicho katika kiwango cha 30B hadi 70B kinahitaji seva yenye RAM kubwa au, kwa uhalisia, GPU; kwenye CPU VPS, model hiyo haitatoshea au itajibu polepole sana kiasi cha kutokuwa na manufaa.

Sasa kuhusu kasi, kwa sababu hii ndiyo sehemu ambayo watu huipuuza. Inference ya CPU inategemea bandwidth ya kumbukumbu, si kasi ya processor (clock speed), na VPS yenye vCPU inayoshirikiwa ina bandwidth ndogo. Tarajia kasi ya tokens chache kwa sekunde: model ya 7-8B Q4 inaweza kufikia tokens 4 hadi 10 kwa sekunde, na model ya 3B inaweza kufikia 10 hadi 25. GPU ina kasi kubwa zaidi kwa takriban mara kumi. Hizi ni namba za makadirio kwa makusudi; hatua ya kweli ni kupima seva yako mwenyewe, jambo ambalo hatua ya run hapa chini inaonyesha jinsi ya kulifanya. Iamini eval rate yako, si namba iliyo kwenye makala yoyote, ikiwemo hii.

Hitimisho la kiutendaji: model ndogo zilizofanyiwa quantization kwenye CPU zina manufaa ya kweli kwa ajili ya kuandaa rasimu, kufupisha maandishi, na kuainisha data ikiwa unaweza kuvumilia kasi hiyo. Kwa chochote kikubwa au cha haraka zaidi, tengeneza bajeti ya instance yenye GPU.

Ili kulinganisha model mahususi na seva mahususi, kadiria kiasi cha kumbukumbu kitakachotumiwa hapa:

Kusakinisha Ollama

Kuna njia mbili safi. Hati rasmi ndiyo rahisi zaidi kwenye VPS tupu:

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

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

Hii hutengeneza mtumiaji wa mfumo anayeitwa ollama, husakinisha binary kwenye /usr/local/bin/ollama, na kusajili huduma ya systemd inayoitwa ollama.service ambayo huanza wakati wa boot na kufungua 127.0.0.1:11434. Thibitisha kuwa inafanya kazi:

systemctl status ollama
ollama --version

systemctl status ollama

Ikiwa tayari unatumia Docker, tumia container badala yake:

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

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

Zingatia kiambishi 127.0.0.1: kwenye ramani ya port. Hii hufunga port kwenye localhost pekee. Kuandika -p 11434:11434 badala yake huchapisha huduma hiyo kwenye kila interface, jambo ambalo ni kosa ambalo sehemu ya usalama huonya dhidi yake. Chagua njia moja ya kusakinisha; usitumie hati hiyo na container kwa wakati mmoja, au michakato miwili itagombania port hiyo.

Pakua na uendeshe modeli yako ya kwanza

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

pull hupakua matabaka ya modeli kwenye diski (takriban 2 GB kwa modeli hii). run hupakia matabaka hayo kwenye kumbukumbu na kukuweka kwenye prompt ya >>>. Andika swali. Token ya kwanza inaweza kuchukua sekunde kadhaa wakati weights zinapopakuliwa kutoka kwenye diski kwenda kwenye RAM, kisha jibu litaanza kutiririka. Andika /bye ili kuondoka kwenye chat; Ollama itaendelea kufanya kazi kwa nyuma.

Angalia kile kilichopakiwa na jinsi kinavyotoshea:

ollama ps

Safu ya PROCESSOR inakuonyesha ukweli. 100% CPU inamaanisha hakuna GPU inayotumika, na hapo ndipo kasi ndogo inapotokea. Pima kasi halisi kwa kutumia flag ya verbose:

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

Mstari wa eval rate unaochapishwa mwishoni ndio idadi ya tokens kwa sekunde kwenye maunzi haya. Hiyo ndiyo namba ya kuzingatia wakati wa kupanga mipango yako.

Mahali ambapo mifano huhifadhiwa, na kiasi cha diski cha kununua

Mifano iliyosakinishwa na script na kuendeshwa kama huduma, hukaa kwenye saraka ya nyumbani ya mtumiaji ollama:

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

Unapoiendesha kwa njia ya mwingiliano (interactive) kama mtumiaji wako mwenyewe, mifano hiyo hukaa kwenye ~/.ollama/models. Ndani ya container, mifano hiyo hukaa kwenye volume yenye jina ollama. Hili ni muhimu kwa sababu uzito wa quantized huongezeka haraka: mfano wa 3B ni takriban 2 GB, wa 7-8B ni takriban 5 GB, na wa 14B ni takriban 9 GB. Ukipakua mifano minne ili kuilinganisha, utakuwa umetumia 20 GB bila kutambua. Kadiria ukubwa wa diski kulingana na mifano unayokusudia kuhifadhi, na ufute mingine kwa kutumia ollama rm <model>. Ikiwa VPS hiyo hiyo tayari inaendesha kitu kingine kinachotumia nafasi nyingi, kama vile PhotoPrism au Immich inayohifadhi maktaba ya picha, ondoa kiasi hicho kutoka kwenye nafasi iliyo wazi kwanza, na chukulia kilichobaki kama bajeti yako halisi ya mifano.

Iendeshe kama huduma unayoimiliki

Hati ya usakinishaji tayari imesajili ollama.service, kwa hivyo inajianzisha upya wakati wa boot bila kazi ya ziada. Mpangilio unaofaa kubadilishwa ni muda ambao model inakaa kwenye kumbukumbu, na kwenye usanidi fulani, anwani ya bind; yote haya huwekwa kwenye systemd drop-in ili uboreshaji wa Ollama usiyafute:

sudo systemctl edit ollama.service

Ongeza haya chini ya kichwa cha habari [Service] kinachoonyeshwa na kihariri:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE ni muda ambao model inakaa kwenye kumbukumbu baada ya ombi la mwisho (chaguo-msingi ni dakika 5). Iongeze kwenye seva unayotumia siku nzima ili kuepuka kupakia upya weights kila wakati; iweke kuwa 0 kwenye seva yenye rasilimali chache ili kuachia RAM mara tu ombi linapokamilika. systemctl edit hupakia upya faili za unit kwa ajili yako, kwa hivyo anzisha upya huduma ili kutumia mabadiliko hayo:

sudo systemctl restart ollama

Hoja ya usalama inayozingatiwa zaidi

Kwa chaguo-msingi, Ollama hufunga 127.0.0.1:11434, kwa hivyo ni michakato iliyo kwenye VPS yenyewe pekee inayoweza kuifikia. Chaguo hilo ni sahihi. Liache hivyo.

API hii haina uthibitishaji (authentication). Haina chochote. Hakuna API key, hakuna login, hakuna rate limit, wala allow-list. Mtu yeyote anayeweza kufikia port 11434 anaweza kuendesha model yoyote uliyopakua, kupakua mpya, kuzifuta, na kutumia CPU au GPU yako kwa uwezo wake wote bila kikomo. Vichanganuzi kama Shodan huorodhesha maelfu ya mifano ya Ollama iliyo wazi, na mfumo ulio wazi hupatikana na kutumiwa vibaya ndani ya saa chache.

Kwa hiyo, hili ndilo kosa moja ambalo hupaswi kamwe kufanya: usiweke OLLAMA_HOST=0.0.0.0 na kufungua 11434 kwenye firewall yako. Hilo huweka inference server isiyokuwa na authentication wazi kwa Internet yote. Hakuna kiwango cha usanidi kinachoweza kufanya 11434-ghafi kwenye-0.0.0.0 iwe salama, kwa sababu hakuna kitu cha kusanidi kwenye Ollama; authentication haipo kabisa. Hii ni kanuni inayohusu service hii mahususi, si marufuku ya kufungua port yoyote: relay ya RustDesk inayojihost kwa desktop ya mbali lazima ipokee traffic ya umma ili ifanye kazi, na inaruhusiwa kufanya hivyo kwa kuwa ina key-based authentication yake pamoja na orodha fupi na iliyoandikwa ya ports, vitu ambavyo Ollama haina kabisa.

Kuna njia tatu salama za kufikia model kutoka nje ya seva hiyo:

• Iweke ndani ya seva (local). Ikiwa mpigaji simu pekee ni programu nyingine kwenye VPS hiyo hiyo, cron script, bot, au MCP server inayounganisha zana zako na model, acha bind ikiwa 127.0.0.1 na uifanye programu hiyo iite http://127.0.0.1:11434. Hakuna kinachowekwa wazi na hakuna kingine kinachohitajika.
• Ifikie kupitia tunnel ya kibinafsi. Weka VPS kwenye WireGuard VPN unayojiendeshea mwenyewe, weka OLLAMA_HOST kwenye anwani ya tunnel (kwa mfano 10.8.0.1, si 0.0.0.0), na VPN peers pekee ndio wataweza kuunganisha. Internet ya umma haitaona chochote kwenye 11434.
• Weka reverse proxy yenye uthibitishaji mbele yake. Malizia TLS na uhitaji password au token kwenye nginx, Traefik, au Caddy, kisha fanya proxy kwenda 127.0.0.1:11434. Ollama huendelea na bind yake ya localhost; proxy ndiyo kitu pekee kinachosikiliza kwenye port ya umma. Hii ni sawa na kuweka cheti cha Let's Encrypt kwenye nginx mbele ya huduma yoyote ya ndani.

Chaguo la reverse-proxy ndilo hasa ambalo chat UI inakupa baadaye, ikiwa na login halisi iliyoambatishwa.

Ongeza kiolesura cha gumzo kwa kutumia Open WebUI, nyuma ya TLS

Open WebUI ni kiolesura cha gumzo kinachojiendesha chenyewe. Kiendeshe ndani ya Docker na uelekeze kwenye Ollama ya ndani:

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

Flag ya --network=host ni maelezo muhimu kwenye Linux VPS. Inaweka container kwenye network namespace ya host, kwa hivyo 127.0.0.1 ndani ya container inakuwa ni loopback ya host yenyewe na container inafikia Ollama kupitia 127.0.0.1:11434 bila Ollama kusikiliza kwenye interface nyingine yoyote. Mbinu ya bridge-network utakayoiona kwingine, --add-host=host.docker.internal:host-gateway na OLLAMA_BASE_URL=http://host.docker.internal:11434, haifanyi kazi hapa: jina hilo linatafsiriwa kama gateway ya Docker bridge, na huduma iliyofungwa kwenye 127.0.0.1 kwenye host haipatikani kupitia bridge, kwa hivyo Open WebUI inabaki ikiripoti kuwa haiwezi kuunganisha na Ollama.

Hasara ya kutumia host networking ni kwamba Open WebUI sasa inasikiliza kwenye port ya host ya 8080 kwenye kila interface; mapping yoyote ya -p inapuzwa, na Docker inatoa onyo kuhusu hilo. Kwa hivyo funga 8080 kwenye firewall ya host na ya mtoa huduma na uache TLS reverse proxy iwe ndiyo mlango pekee wa umma. Katika ziara ya kwanza kabisa, Open WebUI inakuomba uunde akaunti ya admin, akaunti hiyo ndiyo safu yako ya uthibitishaji, kwa hivyo chagua nenosiri imara.

Ili kufungua gumzo kutoka kwenye laptop yako kupitia HTTPS, weka TLS reverse proxy mbele ya 127.0.0.1:8080. Ikiwa tayari unaelekeza programu kadhaa za Docker kwenye seva hiyo, Traefik yenye TLS ya kiotomatiki kwa programu nyingi ndiyo chaguo safi zaidi: block moja ya label inatoa cheti na kuelekeza chat.example.com kwenye Open WebUI. Kanuni kutoka sehemu ya usalama bado inatumika, proxy inamiliki port ya umma na login, wakati Ollama inabaki kwenye localhost na 8080 ya Open WebUI inabaki ikiwa imefungwa na firewall.

Tumia endpoint inayooana na OpenAI kutoka kwenye code yako

Ollama hutumia sehemu ya OpenAI chat API katika /v1, kwa hivyo maktaba nyingi za wateja wa OpenAI hufanya kazi baada ya kubadilisha vitu viwili: base URL na ufunguo wa muda (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 inahitajika na maktaba ya mteja lakini hupuuzwa na Ollama, kwa hivyo string yoyote inafaa. model lazima iwe jina ambalo umeshalivuta (pull); jina lisilojulikana hurejesha model "x" not found, try pulling it first. Wito wa kawaida wa curl una wazo lilelile:

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"}]}'

Hivi ndivyo unavyounganisha model kwenye zana za wakala (agent) na mhariri (editor). Ikiwa tayari unafanya maendeleo kwenye seva hiyo, model ya ndani inaweza kusaidia scripts na plugins sambamba na Claude Code inayoendeshwa kwenye VPS ndani ya tmux, jambo linalosaidia kuweka kazi za uandishi za bei nafuu na za faragha nje ya API inayolipishwa, huku hoja nzito zikibaki na model inayohudumiwa (hosted model).

Njia za kufeli, pamoja na maandishi kamili utakayoyaona

Mchakato ume “Killed” katikati ya utengenezaji. Unaanzisha model kubwa, kisha terminal inaonyesha Killed, au log ya server inaonyesha llama runner process has terminated: signal: killed. Linux OOM killer uliusimamisha kwa sababu model ilihitaji RAM zaidi ya iliyo kwenye box. Thibitisha sababu kwa sudo dmesg | grep -i oom, ambapo utaona mstari kama Out of memory: Killed process ... (ollama). Suluhisho ni kutumia model ndogo au iliyofanyiwa quantization kwa kiwango kikubwa zaidi, llama3.2:3b badala ya 13B, au kuongeza swap ili mzigo unaozidi RAM ya kimwili kwa kiasi kidogo uendelee polepole badala ya kufa. Swap hubadilisha crash ya papo hapo kuwa jibu la polepole; haifanyi model ya 70B iwe ya kutumika kwenye 4 GB. Kill hii hutokea bila ujumbe isipokuwa uwe unaangalia terminal, kwa hiyo kwenye box unayo-query kutoka sehemu nyingine, kuambatisha unit ya OnFailure= kwenye ollama.service inayotuma ujumbe kwa server ya ntfy unayo-host kwa alerts za push kunakujulisha mara tu inapokufa badala ya kukuacha ugundue wakati wa request inayofuata.

"Error: model requires more system memory". Ollama inakataa kuanzisha model na kuchapisha Error: model requires more system memory (X GiB) than is available (Y GiB). Hii ni toleo la kistaarabu la crash iliyotajwa hapo juu: Ollama imefanya hesabu na kusimama badala ya kuruhusu OOM killer aifanye. Hata inakupa namba hizo mbili. Chagua model ambayo mahitaji yake yako chini ya RAM yako iliyo wazi (angalia na free -h), punguza urefu wa context, au hamia kwenye VPS kubwa zaidi. Hakuna flag inayoweza kuifanya model ifit, kumbukumbu ni ya kweli.

Tokeni ya kwanza huchukua muda mrefu sana, kisha kila kitu huwa kawaida. Modeli ambayo haikuwa imepakiwa haionyeshi chochote kwa sekunde tano hadi thelathini, kisha huanza kutuma majibu kwa mtiririko wa kawaida. Kusubiri huko hutokana na uzito wa modeli kupakiwa kutoka kwenye diski hadi RAM kwa mara ya kwanza, na storage ya polepole hufanya hali hiyo iwe mbaya zaidi. Baada ya kupakiwa, modeli hubaki kwenye RAM kwa muda wa OLLAMA_KEEP_ALIVE, kwa hiyo prompt ya pili hujibiwa papo hapo. Ikiwa upakiaji huo wa kwanza unazidi timeout mahali fulani kwenye njia ya ombi, utapata error badala ya jibu la polepole, na kubaini ni layer gani iliyoripoti context deadline exceeded kunakuonyesha ikiwa client, proxy au upakiaji wenyewe uliishiwa muda wa kusubiri. Ongeza thamani hiyo ikiwa mapengo hayo yanakusumbua, na utumie ollama ps kuona ikiwa modeli imepakiwa kwa sasa.

Kila kitu ni polepole tu. Token kumi kwa sekunde au chini ya hapo, bila error yoyote. Hiyo ni inference ya CPU inayofanya kile ambacho inference ya CPU hufanya. ollama ps inaonyesha 100% CPU, ikimaanisha hakuna GPU. Hii si bug na hakuna mpangilio unaoweza kuirekebisha, kwa sababu kikomo ni bandwidth ya kumbukumbu, si usanidi mbaya. Tumia model ndogo, kubali kasi hiyo, au hamia kwenye instance ya GPU, na pima kiwango chako halisi na --verbose kabla ya kuamua kuwa kitu kimeharibika.

Connection refused kutoka kwa mashine nyingine. Kutoka kwenye laptop yako unapata curl: (7) Failed to connect to <ip> port 11434: Connection refused. Hii inafanya kazi kama ilivyokusudiwa: Ollama inajifunga kwenye localhost pekee. Usi "rekebishe" kwa kuifunga kwenye 0.0.0.0, ambayo ndiyo kosa hasa la kufichua huduma kama ilivyotajwa hapo juu. Fikia model kupitia VPN au kupitia proxy inayothibitisha utambulisho badala yake.

Ulifichua 11434 kwenye mtandao. Ikiwa uliweka OLLAMA_HOST=0.0.0.0, ukafungua firewall, na sasa unaona model zinapakuliwa ambazo hukuanzisha au CPU imefika 100% kwa sababu ya wateja usiofahamika, umegunduliwa na kutumiwa. Hili ni kosa kuu, si jambo la kawaida. Jifunge tena kwenye 127.0.0.1 au anwani ya VPN, funga 11434 kwenye firewall, na uweke uthibitisho wa utambulisho mbele. Chukulia kuwa chochote kinachoweza kufikiwa kwenye anwani hiyo wakati ilikuwa wazi kimeulizwa na watu wasiofahamika.

Hifadhi nakala na maboresho

Kuna data chache za kupoteza. Modeli zinaweza kupakuliwa tena, kwa hivyo vitu pekee vya kuhifadhi nakala ni volume ya data ya Open WebUI, akaunti, historia ya mazungumzo, mipangilio, na faili yoyote ya systemd drop-in uliyoiandika. Hifadhi nakala ya volume hiyo kwa kutumia container ya muda:

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

Boresha Ollama kwa kuendesha tena script ya usakinishaji; boresha Open WebUI kwa kutumia docker pull ghcr.io/open-webui/open-webui:main ikifuatiwa na kuunda upya container. Usiweke toleo lolote kwa muda mrefu: ubora wa modeli na runtime hubadilika haraka, kwa hivyo soma maelezo ya toleo (release notes) na ufanye majaribio ya utendaji (benchmark) kwenye seva yako badala ya kuamini takwimu za robo mwaka iliyopita.

FAQ

Je, ninaweza kweli kuendesha LLM kwenye VPS inayotumia CPU pekee?

Ndiyo, kwa kiasi fulani. Miundo midogo iliyopunguzwa ukubwa (quantized) katika kiwango cha 3B hadi 8B inaweza kuendeshwa kwenye CPU na ni muhimu kwa kuandaa rasimu, kufupisha, na kuainisha maudhui, ingawa kwa kasi ndogo ya tokeni chache kwa sekunde kwenye vCPU inayoshirikiwa. Miundo yoyote kuanzia 13B na kuendelea itakuwa polepole sana au haitatoshea kabisa kwenye RAM. Kwa kasi halisi au miundo mikubwa zaidi, unahitaji instance yenye GPU.

Kila muundo unahitaji RAM kiasi gani?

Kanuni ya jumla kwa miundo chaguo-msingi ya 4-bit quantized ni: takriban 0.5 GB ya RAM kwa kila bilioni moja ya vigezo (parameters) kwa ajili ya uzito wa muundo, pamoja na takriban 1 GB ya ziada kwa ajili ya uendeshaji na nafasi kidogo zaidi kwa ajili ya muktadha (context). Kwa hivyo, muundo wa 3B unahitaji takriban 4 GB ya nafasi huru, muundo wa 7-8B unahitaji takriban 8 GB, na muundo wa 14B unahitaji takriban 16 GB. Angalia nafasi yako iliyobaki kwa kutumia free -h na uache nafasi ya kutosha kwa mfumo wa uendeshaji na programu nyingine zozote kwenye seva.

Je, Ollama API ina uthibitishaji (authentication)?

Hapana. Ollama haina uthibitishaji wa ndani, API key, au kikomo cha kasi (rate limit); mtu yeyote anayeweza kufikia port 11434 anayo mamlaka kamili juu yake. Hii ndiyo sababu inajifunga kwenye 127.0.0.1 kwa chaguo-msingi na ndiyo sababu hupaswi kamwe kuweka 11434 kwenye 0.0.0.0 hadharani kwenye Internet. Ifikie kupitia mtandao wa ndani, VPN ya faragha, au kupitia reverse proxy inayoongeza utaratibu wa kuingia (login).

Ninawezaje kuongeza kiolesura cha gumzo cha wavuti?

Endesha Open WebUI kwenye Docker kwa kutumia --network=host ili ishiriki loopback ya seva na ifikie Ollama asilia kwenye http://127.0.0.1:11434, kisha weka TLS reverse proxy mbele ya port yake 8080 ili uweze kuifikia kutoka kwenye kompyuta yako. Weka 8080 ikiwa imefungwa kwenye firewall ili proxy iwe ndiyo mlango pekee wa umma. Akaunti ya msimamizi ya Open WebUI inatoa utaratibu wa kuingia, na unaweka nenosiri lake wakati wa uzinduzi wa kwanza.

Ninawezaje kuiita kutoka kwenye programu yangu mwenyewe?

Tumia endpoint inayooana na OpenAI kwenye http://127.0.0.1:11434/v1. Elekeza SDK yoyote ya OpenAI kwenye URL hiyo ya msingi, tumia kamba yoyote ya herufi kama API key kwa sababu haitazingatiwa, na uweke model kwenye jina la muundo ulioupakua. Nambari ya programu (code) ya OpenAI iliyopo kwa kawaida hufanya kazi bila mabadiliko yoyote isipokuwa URL ya msingi na ufunguo.