Self-Host Ollama pe un LLM Server și Preiei Controlul asupra Cenzurii AI

Cuvinte cheie

Înainte de a trece la configurare, iată termenii care vor confunda cel mai probabil cititorii acestui ghid. Acest glosar rapid păstrează vocabularul Linux, GPU și modelelor locale clar de la început.

De ce merită să auto-găzduiești un LLM

Dacă ai deja făcut partea grea — ai închiriat serverul GPU, ai instalat Ubuntu, ai învățat să te miști prin SSH și ai ținut propriile servicii în funcțiune — devine frustrant rapid când un AI găzduit încă controlează ultima milă. Poate refuza o cerere perfect obișnuită, poate ascunde răspunsul sub disclaimer-uri, poate schimba stilul răspunsului fără avertisment și poate ține fiecare prompt care curge prin granițele altcuiva. Pentru mulți utilizatori tehnici, aceasta este frustrarea reală: nu doar ceea ce spune modelul, ci cine controlează stratul de servire când o spune.

Acest ghid este despre remedierea acestui lucru cu modele deschise și locale, nu despre trucuri de ocolire pentru API-uri proprietare. Vei auto-găzdui Ollama pe un server GPU Ubuntu, vei rula inferența local, vei verifica că calea GPU este reală și vei vedea ce se schimbă când alegi o familie de modele diferită. O concepție greșită de clarificat devreme: auto-găzduit nu înseamnă automat nerestricționat. Înseamnă că controlezi mult mai mult din stivă — și încetezi să depinzi de o cale de servire controlată de furnizor — dar modelul pe care îl rulezi poate încă să aibă propriul comportament de aliniere.

📝 Notă: Comenzile din acest ghid sunt validate în raport cu documentația Ollama curentă, dar rezultatele terminalului prezentate mai jos sunt exemple reprezentative mai degrabă decât capturi de benchmark live. Folosește-le ca model de succes, nu ca o afirmație de performanță.

La final, vei avea un serviciu Ollama funcțional pe Ubuntu, un API local verificat la 127.0.0.1:11434, dovadă că inferența susținută de GPU se întâmplă de fapt și o comparație întemeiată între un model aliniat mainstream și o alternativă mai puțin restricționată. Acest tutorial este scris pentru cititori care sunt confortabili cu SSH, Ubuntu, sudo și systemd, dar care nu au nevoie de experiență anterioară cu Ollama.

Serverul GPU Ubuntu exact folosit pentru acest ghid

Acest tutorial se bazează pe o mașină Ubuntu reală cu o singură GPU, deoarece sfaturile vagi de tipul “ar trebui să funcționeze pe majoritatea serverelor” sunt modul în care ghidurile de auto-găzduire devin înșelătoare. Caseta de referință de aici este clasa reală de gazdă folosită pentru acest ghid: tipul de mașină pe care o ar închiria de fapt o persoană avansată, un laborator sau o mică echipă atunci când doresc inferență locală privată fără a sări direct la un rack de acceleratoare enterprise. Va discuta în continuare comportamentul multi-GPU, deoarece Ollama se schimbă odată ce un model depășește o singură placă, dar tratați acea parte ca context orientat spre viitor mai degrabă decât ca dovadă din acest server exact.

Server GPU — Ryzen 9 3950X + RTX 4070 Ti Super

În practică, aceasta este o configurație foarte puternică pentru modelele zilnice din clasa 8B și încă una utilă pentru lucrări locale mai mari până în punctul în care 16GB de VRAM devine constrângerea reală. Un model precum llama3.1:8b la aproximativ 4.9GB se încadrează ușor pe această placă. Un model precum gpt-oss:20b la aproximativ 14GB este tipul de test single-GPU de nivel superior care are încă sens aici. Un model precum qwen3:30b la aproximativ 19GB este mai bine tratat ca punct de referință pentru ceea ce se schimbă pe o gazdă mai mare sau dual-GPU decât ca o potrivire curată pentru această mașină exact.

Această distincție contează deoarece scopul acestui articol nu este să storc cel mai mare număr posibil într-un titlu. Este să arăt cum arată un server LLM auto-găzduit sensibil atunci când dorești confidențialitate, control local și suficientă memorie GPU pentru a rula modele utile fără compromis constant. Această clasă de hardware este locul în care inferența auto-găzduită devine realistă, nu teoretică.

Explică, de asemenea, câteva alegeri pe care le vei vedea mai târziu: mistral este folosit mai întâi deoarece oferă o dovadă rapidă și fără fricțiuni că stiva funcționează, în timp ce comparația comportamentului rămâne în clasa 8B unde această mașină este confortabilă. qwen3:30b apare încă mai târziu, dar ca exemplu teoretic al tipului de model care poate declanșa plasarea multi-GPU pe o gazdă mai mare mai degrabă decât ca dovadă în direct din acest server. Cu așteptări stabilite, următorul pas este validarea gazdei înainte ca Ollama să o atingă.

Rulează Aceste Verificări Pre-Instalare Înainte de a Atinge Ollama

Începe cu nvidia-smi. Dacă această comandă lipsește sau eșuează, oprește-te acolo și repară mai întâi driverul NVIDIA. Nu instala Ollama încă, deoarece o stivă NVIDIA defectă va face ca fiecare simptom ulterior să arate ca o defecțiune a aplicației când este de fapt o defecțiune a platformei.

Rulează mai întâi verificarea GPU:

nvidia-smi

❗Dacă Ubuntu spune că nvidia-smi lipsește, nu presupune că serverul nu are GPU. Un mod de defecțiune obișnuit pe cutiile Ubuntu închiriate este că placa este prezentă dar încă legată la nouveau în loc de driverul NVIDIA. Verifică mai întâi secțiunea “Repară Problema Driverului Nvidia pe Ubuntu“.

Un rezultat sănătos pe această clasă de server ar trebui să arate aproximativ așa:

Odată ce nvidia-smi funcționează și GPU-ul este vizibil, continuă cu verificările de mai jos.

Ceea ce vrei să confirmi este simplu: GPU-ul instalat este vizibil, raportează aproximativ 16GB de VRAM pe acest host, și driverul este încărcat curat. Dacă ești pe un server multi-GPU, aceeași comandă ar trebui să listeze fiecare card.

nvidia-smi -L

❗ Important: Documentația curentă de suport GPU Ollama folosește driverul NVIDIA 531+ ca limita reală pentru inferența NVIDIA suportată. Tratează 531+ ca cerință pentru acest ghid, chiar dacă ai văzut note mai vechi din comunitate citând versiuni mai mici.

Acum confirmă că hostul este într-adevăr mediul Ubuntu pe care îl presupune acest ghid:

lsb_release -a

În sfârșit, verifică spațiul liber pe disc înainte de a începe descărcarea modelelor. Instalarea în sine este mică; modelele nu sunt. Odată ce depășești testele minuscule, o bibliotecă de 20B-30B poate consuma zeci de gigaocteți rapid, deci 100GB+ liber este mentalitatea corectă înainte de munca serioasă cu modele locale.

df -h /

Dacă aceste verificări trec, ai clarificat principalele necunoscute de infrastructură: GPU-urile sunt prezente, linia de bază a driverului este sănătoasă, Ubuntu este confirmat, și discul are loc pentru extrageri reale de modele. Acesta este punctul în care instalarea Ollama devine un pas curat următor în loc de o ghicire.

Repară Problema Driverului Nvidia pe Ubuntu

Urmează pașii de mai jos, pentru a fixa problemele cu comanda “nvidia-smi”.

lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'

Dacă acea ieșire arată o placă NVIDIA și o linie cum ar fi Kernel driver in use: nouveau, instalează pachetul driverului Ubuntu recomandat în loc de a instala doar nvidia-utils.

Instalează pachetul ubuntu-drivers-common (necesar pentru gestionarea driverelor) și anteturile kernel pentru kernelul tău în execuție.

apt update
apt install -y ubuntu-drivers-common linux-headers-$(uname -r)

Scanează sistemul tău și listează driverele proprietare disponibile (de ex., drivere GPU NVIDIA) care pot fi instalate.

ubuntu-drivers devices

Apoi instalează pachetul driverului recomandat. În cazul nostru a fost: nvidia-driver-595-open:

apt install -y nvidia-driver-595-open
reboot

După repornire, rulează din nou:

nvidia-smi
nvidia-smi -L

Instalați Ollama și Confirmați că Serviciul Este Sănătos

Calea Ubuntu acceptată este instalatorul oficial Ollama, nu un flux tarball personalizat și nu o detură Docker. Asta contează pentru că acest ghid este despre obținerea unui serviciu local fiabil cu setări implicite previzibile, integrare systemd și comportament corect al proprietății pe Linux.

Rulați instalatorul exact așa cum este documentat:

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

Pe un sistem sănătos, scriptul instalează binarele, creează utilizatorul serviciului ollama, adaugă apartenența la grupuri corespunzătoare atunci când sunt disponibile, scrie unitatea systemd și pornește serviciul legat la 127.0.0.1:11434.

După ce scriptul se termină, validați serviciul în loc să presupuneți succesul:

sudo systemctl status ollama --no-pager

Căutați trei lucruri aici: fișierul unității este prezent, serviciul este activat la pornire și Active: active (running) confirmă că serverul este de fapt activ.

Mai întâi, stabiliți contul utilizatorului serviciului Linux într-un mod concret și abia apoi gândiți-vă la cum și unde va fi gestionat stocarea modelului.

getent passwd ollama

Acea singură linie explică o mulțime de comportament viitor. Modelele pe Linux trăiesc sub proprietatea serviciului și dacă le mutați mai târziu pe alt disc fără a fixa permisiunile pentru utilizatorul ollama, vă creați propria defecțiune.

Încă o verificare închide bucla pe legarea implicită:

ss -tlnp | grep 11434

⚠️ Avertisment: Ollama nu necesită autentificare pe API-ul local implicit. Asta este bine când este legat la 127.0.0.1, dar nu este sigur să expuneți portul 11434 direct la internet ca și cum ar fi un serviciu public întărit.

Dacă serviciul nu pornește curat, mergeți mai întâi la jurnale în loc să reinstalați orbește:

journalctl -u ollama -n 100 --no-pager

Asta este cel mai rapid mod de a detecta probleme de permisiuni, erori de pornire, probleme de detectare a driverelor sau probleme de legare. Odată ce serviciul este sănătos pe localhost, următorul lucru de înțeles este cum se comportă plasarea GPU la runtime.

Cum folosește Ollama de fapt unu sau mai multe GPU-uri

Chiar dacă serverul folosit pentru acest ghid are un GPU, comportamentul multi-GPU merită totuși înțeles deoarece mulți utilizatori pot avea cutii mai mari sau pot se extinde mai târziu. O mare parte din confuzia cu două GPU-uri începe cu așteptarea greșită: “Am două carduri, deci ambele ar trebui să se aprindă tot timpul.” Așa nu funcționează Ollama. Regula practică este mult mai simplă: dacă un model se încadrează pe un GPU, Ollama de obicei îl va ține pe un GPU. Se răspândește doar pe mai multe GPU-uri atunci când modelul nu se încadrează confortabil pe o singură placă.

Folosiți aceste două verificări împreună ori de câte ori doriți să vedeți performanța GPU:

ollama ps

watch -n 1 nvidia-smi

ollama ps vă spune cum este procesat modelul încărcat. 100% GPU înseamnă că modelul este complet rezident în memoria GPU. 100% CPU înseamnă că accelerația GPU nu este utilizată. O stare mixtă vă spune că o parte din sarcina de lucru sau rezidență s-a scurs în afara căii GPU. watch -n 1 nvidia-smi completează aceasta prin afișarea utilizării VRAM în timp real pe card în timp ce modelul este încărcat.

Cel mai rapid mod de a ține aceste roluri drepte este acesta:

📝 Notă: CUDA_VISIBLE_DEVICES este un control de vizibilitate, nu un comutator “folosiți ambele GPU-uri”. Dacă vreodată restricționați accesul GPU, preferați UUID-urile din nvidia-smi -L în locul ID-urilor numerice deoarece ordinea GPU poate varia între medii și reporniri.

Rulați Primul Model Local și Verificați Inferența GPU

La acest punct, nu aveți nevoie de un model gigantic pentru a dovedi că serverul funcționează. Aveți nevoie de un succes rapid și onest. mistral este o bună primă descărcare deoarece este mic, rapid de descărcat și ușor de încărcat, chiar dacă llama3.1:8b va fi mai târziu linia de bază pentru compararea comportamentului.

Începeți prin a descărca modelul:

ollama pull mistral

Acum rulați un mic prompt prin el, astfel încât mașina să facă ceva util, nu doar administrativ. Răspunsul ar putea dura câteva secunde.

ollama run mistral "In one sentence, explain why people self-host LLMs."

Pentru a dovedi că aceasta este inferență cu suport GPU și nu o rezervă CPU, verificați starea runtime:

ollama ps

Și pentru a vedea ce este deja pe disc, listați inventarul local:

ollama list

mistral este alegerea corectă pentru prima dovadă deoarece vă oferă un răspuns rapid fără a transforma validarea configurării într-o așteptare lungă. Mai târziu, llama3.1:8b devine mai util deoarece este o linie de bază aliniată mai puternică pentru compararea comportamentului modelului.

În sfârșit, verificați unde instalarea Linux stochează modelele:

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

Acea cale — /usr/share/ollama/.ollama/models — este depozitul standard de modele Linux documentat de Ollama.

Odată ce vedeți un răspuns reușit, 100% GPU în ollama ps și utilizarea discului crescând în locația așteptată, aveți prima dovadă semnificativă că stiva locală funcționează.

Demonstrați că este un server, nu doar un wrapper CLI

O linie de comandă este frumoasă, dar motivul pentru a auto-găzdui Ollama nu este doar pentru a conversa într-un terminal. Este pentru a rula un server de inferență local pe care alte instrumente, scripturi și aplicații îl pot apela fără a trimite solicitări prin granița API-ului altcuiva. Cea mai rapidă dovadă este o cerere HTTP curată către punctul final nativ Ollama.

Trimiteți o cerere de generare locală cu streaming dezactivat, astfel încât primul răspuns să fie ușor de inspectat:

curl http://localhost:11434/api/generate -d '{
"model": "mistral",
"prompt": "Say hello from a self-hosted Ollama server in one sentence.",
"stream": false
}'

Un răspuns reușit ar trebui să revină ca JSON și să arate aproximativ așa:

{
  "model": "mistral",
  "created_at": "2026-05-13T12:45:12.000000Z",
  "response": "Hello from a self-hosted Ollama server running locally on Ubuntu.",
  "done": true,
  "done_reason": "stop",
  "total_duration": 812345678,
  "load_duration": 12345678,
  "prompt_eval_count": 14,
  "eval_count": 12
}

Lista de verificare a succesului este simplă: cererea HTTP funcționează local, JSON valid revine, done: true este prezent, iar răspunsul modelului se află în response. Acesta este punctul în care Ollama încetează să fie „un CLI care se întâmplă să descarce modele” și devine infrastructură pe care o puteți integra efectiv în instrumente locale și automatizări.

Dacă doriți compatibilitate cu software-ul care se așteaptă la o formă de cerere în stil OpenAI, Ollama expune, de asemenea, punctele finale /v1 local:

curl -X POST http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "mistral",
"messages": [
{"role": "user", "content": "Say this is a test."}
]
}'

📝 Notă: Eticheta „compatibilă cu OpenAI” este ușor de citit greșit. Nu înseamnă că vorbești cu OpenAI, și nu schimbă faptul că serverul este încă local. Înseamnă doar că forma cererii este suficient de familiară pentru instrumente și SDK-uri construite în jurul modelului API OpenAI. URL-ul de bază rămâne http://localhost:11434/v1/, iar orice cheie API placeholder pe care unele biblioteci client insistă să o aibă poate fi ignorată pentru utilizarea locală Ollama.

De unde provin cu adevărat restricțiile modelelor

Aceasta este partea care de obicei se aplatizează într-o singură idee vagă de “cenzură”, dar din punct de vedere tehnic sunt implicate trei straturi diferite: stratul de servire controlat de furnizor, alinierea modelului și ajustarea instrucțiunilor, și comportamentul prompt/runtime pe care îl controlezi tu. Auto-găzduirea schimbă dramatic unele dintre acele straturi. Nu le șterge pe toate.

O modalitate simplă de a-ți imagina este aceasta:

Cloud API request:
You -> Vendor API gateway -> Vendor moderation / policy layer -> Model -> Response

Self-hosted Ollama request:
You -> Local Ollama server on 127.0.0.1 -> Model -> Response

Rezultate:
– Stratul de servire controlat de furnizor dispare din calea locală
– Limita rețelei locale și a jurnalizării devine a ta
– Alinierea și antrenamentul propriu al modelului vin în continuare cu modelul

Odată ce separi straturile, pașii de configurare anteriori devin mult mai semnificativi:

Poți să te gândești la asta ca la o producție de teatru. Auto-găzduirea schimbă scena, iluminatul, microfonele și notele regizorului. Nu reentrează actorul. Dacă un model a fost ajustat pentru a răspunde cu prudență, pentru a se gândi des sau pentru a refuza anumite tipuri de cadru, rularea lui local nu va anula magic acel antrenament.

Ceea ce configurația ta actuală a dovedit deja este mai restrâns, dar totuși important: controlezi procesul serverului, controlezi limita API și nu mai rutezi prompturile locale printr-un strat de moderare deținut de furnizor. Aceasta este o schimbare reală în confidențialitate și control. Ceea ce nu a dovedit este că fiecare model local se va comporta la fel sau că fiecare refuz din viitor a fost cauzat de un furnizor de cloud.

Aceasta este locul unde alegerea modelului intră în joc. Dacă vrei efectul practic al mai puținer disclaimer-uri, răspunsuri mai directe sau comportament mai puțin plin de refuzuri, nu ajungi acolo spunând “auto-găzduit” mai tare. Ajungi acolo alegând o familie de modele diferită sau o ajustare fină — și prin înțelegerea compromisurilor care vin cu ea.

Alege Model Local Mai Puțin Restricționat

Dacă vrei un test corect, compară modele care ocupă aproximativ aceeași clasă de dimensiune. De aceea acest ghid folosește llama3.1:8b ca linie de bază aliniată mainstream și dolphin3 ca model de comparație mai puțin restricționat. Ambele sunt în jur de 4.9GB, ceea ce face diferența de comportament mai ușor de interpretat fără a schimba și prea drastic amprenta hardware.

Descarcă modelele de comparație local:

ollama pull llama3.1:8b

ollama pull dolphin3

# Optional older reference model
ollama pull dolphin-mistral

Iată cadrul practic pentru cele trei nume pe care le vei vedea cel mai probabil în această parte a ecosistemului Ollama:

⚠️ Avertisment: Un fine-tune diferit nu este “același model cu cenzura eliminată.” Poate schimba directitatea, densitatea declinării de răspundere și disponibilitatea de a urma cadrul utilizatorului, dar poate schimba și tonul, acuratețea, consistența și personalitatea generală.

Performanța GPU

Înainte de a rula modelele dorite, este esențial să înțelegeți posibilitățile și limitările hardware-ului implicat. Deci, sunt două lucruri de testat conceptual: în primul rând, cum arată comportamentul curat cu un singur GPU pe hardware-ul real utilizat pentru acest ghid; în al doilea rând, ce se schimbă dacă mai târziu rulați același stack pe un host cu dual-GPU. Ambele sunt importante, dar doar primul este o dovadă în direct din această mașină exactă.

Pe acest server, testul de runtime mai bun din gama superioară este gpt-oss:20b. Este suficient de mare pentru a fi interesant, în timp ce are sens pe o singură placă 16GB.

ollama pull gpt-oss:20b

ollama stop mistral

ollama run gpt-oss:20b "Explain in one paragraph why a 14GB model is a realistic upper-end single-GPU test on a 16GB card."

După ce modelul se încarcă, confirmați starea runtime:

ollama ps

Aceasta este dovada practică pe care o doriți pe această mașină. Arată că modelele mai mici se potrivesc ușor și că un model local mai mare, dar totuși realist, poate împinge o placă 16GB aproape de limita sa utilizabilă fără a necesita mai multe GPU-uri.

Dacă mai târziu rulați Ollama pe un host cu două GPU-uri, un model cum ar fi qwen3:30b devine genul de sarcină de lucru care poate demonstra plasarea multi-GPU. Fluxul de lucru este același — urmăriți nvidia-smi, rulați modelul, inspectați ollama ps — dar scopul nu este să iluminați ambele plăci pentru propriul bine. Scopul este să confirmați că Ollama răspândește un model pe mai multe GPU-uri doar atunci când modelul nu se mai potrivește curat pe unul.

Considerații privind ocolirea cenzurii

Pentru compararea comportamentului, păstrați condițiile controlate pentru a testa modelul mai mult decât aleatorietatea. Utilizați același endpoint, același prompt, stream: false, o temperatură scăzută și o seed fixă:

curl http://localhost:11434/api/generate -d '{
"model": "llama3.1:8b",
"prompt": "<comparison prompt>",
"stream": false,
"options": {
"temperature": 0.2,
"seed": 42
}
}'

Apoi repetați aceeași cerere cu “model”: “dolphin3”. Seed-ul fix nu elimină toată variația, dar o reduce suficient pentru a face diferențele de ton și conformitate mai ușor de observat.

1. Un prim prompt sigur este: “Does self-hosting an LLM mean the user fully controls the model’s behavior? Answer in 4 bullet points. Be direct and skip preambles.” Un răspuns reprezentativ llama3.1:8b tinde să sune așa:

   - Self-hosting gives you more control over deployment, privacy, and availability.
   - It does not automatically remove the model's built-in alignment behavior.
   - The model may still refuse or soften some responses depending on its training.
   - Full control comes from combining self-hosting with careful model selection and configuration.

   Un răspuns reprezentativ dolphin3 la același prompt sună adesea mai redus:

   - You control the machine, the network boundary, and the serving layer.
   - You do not erase the model's training history just by running it locally.
   - Vendor-side policy can disappear, but model-side alignment can still remain.
   - Real control comes from choosing a model whose behavior matches your use case.

2. Un al doilea prompt util este: “Write a sharp five-sentence case for why a privacy-sensitive team might reject vendor-managed AI. No intro and no conclusion.” llama3.1:8b de obicei se conformează, dar într-un ton corporativ mai măsurat. dolphin3 urmează mai ușor ascuțimea cerută. Acesta este genul de diferență pe care o căutați aici: nu output-uri dramatice fără legi, ci schimbări în directitate, cadru și densitate de disclaimer.
3. A treia categorie de prompt pentru validare poate fi următoarea: cereți cinci motive factuale pentru care un scriitor ar putea prefera un model local pentru lucrări creative neobișnuite, de nișă sau non-mainstream. În practică, ambele modele răspund, dar dolphin3 tinde să rămână mai aproape de tonul cerut non-moralizator și răspunsuri directe.

Modelul arată așa:

Și astfel, iată concluziile oneste:

1. Alegerea modelului local schimbă semnificativ comportamentul output-ului.
2. Modelele diferite variază în directitate și densitate de disclaimer.
3. Self-hosting-ul elimină un strat de servire controlat de furnizor.

Acum Controlezi Stiva, Nu Doar Promptul

Frustrarea de la începutul acestui ghid nu a fost niciodată doar despre un model care refuză o cerere. A fost despre faptul că stratul de servire, stratul de politică și granița de confidențialitate trăiau undeva altundeva. După această configurare, acea parte s-a schimbat. Serverul tău de inferență rulează pe mașina ta Ubuntu, granița API locală este a ta, meniul de modele este al tău, și prompt-urile/valorile implicite ale runtime-ului sunt ale tale pentru a le ajusta.

Ceea ce necesită în continuare judecată este partea pe care niciun instalator nu o poate rezolva pentru tine: alegerea modelelor care se potrivesc cazului tău de utilizare, direcționarea lor cu valori implicite sensate și expunerea accesului în siguranță dacă mergi dincolo de localhost. Aceasta este forma reală a controlului auto-găzduirii. Nu libertate magică de la fiecare restricție, ci proprietatea asupra stivei care decide cum, unde și cu care model se întâmplă inferența. Dacă vrei următorul pas cel mai bun, începe prin crearea unui Modelfile personalizat — sau prin plasarea unui acces la distanță securizat în fața API-ului local când ești gata.

Ce să faci după configurația de bază

La acest punct, promisiunea de bază este îndeplinită. Serverul funcționează, API-ul funcționează, calea GPU este reală, iar diferențele de comportament ale modelului nu mai sunt abstracte. Următoarea mișcare nu este “instalează mai multe lucruri orbește.” Este să ajustezi părțile stack-ului care acum îți aparțin.

Personalizarea comportamentului modelului cu un Modelfile

Un Modelfile este cel mai curat mod de a schimba implicite locale de prompting fără a atinge ponderile modelului în sine. Începe prin inspectarea definiției curente a modelului pentru a înțelege ce extinzi:

ollama show --modelfile dolphin3

Apoi creează o variație locală simplă:

FROM dolphin3

SYSTEM You are a direct, factual assistant for a self-hosted Ubuntu LLM server. 
Prefer short, practical answers and avoid padded disclaimers.

PARAMETER temperature 0.2
PARAMETER num_ctx 8192

Construiește-o ca un nou nume de model și testează-o:

ollama create dolphin3-local -f ./Modelfile
ollama run dolphin3-local "Summarize what changed in this custom model in 3 bullets."

❗ Important: Un Modelfile schimbă comportamentul de prompting și runtime, nu istoricul de antrenament al modelului. Poate orienta tonul și implicite, dar nu reentreneaza modelul subiacent.

Securizarea configurației

Legarea la localhost este o implicită bună, dar nu este sfârșitul poveștii de securitate. Verifică mai întâi adresa de ascultare curentă:

ss -tlnp | grep 11434

Dacă scopul este să păstrezi Ollama doar local, fixează acel comportament explicit cu o suprasciere systemd:

sudo systemctl edit ollama

Adaugă următoarele:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"

Apoi reîncarcă și repornește serviciul:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Dacă ai nevoie de acces la distanță mai târziu, nu publica 11434 direct. Pune un proxy invers cu TLS și autentificare în fața lui:

server {
    listen 443 ssl http2;
    server_name llm.example.com;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
    }
}

⚠️ Avertisment: Tratează expunerea publică ca un proiect de consolidare separat. Ollama în sine este un server de inferență local, nu o pasarelă API gata pentru producție cu autentificare încorporată, limitare de rată și implicite orientate către internet.

Modele recomandate pentru acest hardware

Odată ce instalarea de bază funcționează, cea mai mare îmbunătățire de valoare este alegerea modelelor care se potrivesc bine acestei mașini în loc să urmărești cel mai mare titlu. Pentru serverul cu un singur 4070 Ti SUPER folosit aici, meniul practic arată așa:

Pornire automată și întreținere

După partea distractivă vine partea care ține un server LLM local utilizabil peste o lună. Confirmă comportamentul la pornire, ține serviciul actualizat, urmărește jurnalele și știi cum să descărci modele mari când ai nevoie de VRAM înapoi.

sudo systemctl is-enabled ollama

sudo systemctl enable --now ollama

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

journalctl -u ollama -n 100 --no-pager

Pentru operațiuni zilnice cu modele, acestea sunt comenzile pe care le vei folosi cel mai des:

ollama list
ollama ps
ollama stop gpt-oss:20b
sudo du -sh /usr/share/ollama/.ollama/models

Și dacă stocarea modelului trebuie să se mute pe un disc mai mare, pregătește directorul pentru utilizatorul serviciului înainte de a reorienta Ollama:

sudo mkdir -p /mnt/ai/ollama-models
sudo chown -R ollama:ollama /mnt/ai/ollama-models

Apoi setează OLLAMA_MODELS prin systemctl edit ollama. Acel detaliu de proprietate este ceea ce previne o migrare de stocare de la a se transforma într-o problemă de permisiuni.

Referință de depanare

Când ceva se rupe, cea mai rapidă cale este de obicei potrivirea simptomului cu stratul corect în loc să încerci bucle de reinstalare aleatorii. Folosește acest tabel ca prima trecere:

Dacă ții minte doar o regulă operațională din această secțiune, fă-o pe aceasta: tratează Ollama ca un serviciu real, nu ca o utilitate CLI disponibilă. Jurnalele, proprietatea, adresele de legare și căile de stocare sunt la fel de importante ca fereastra de prompt.