Self-Host Ollama на LLM Server та Візьміть Контроль над AI Цензурою

Ключові терміни

Перш ніж розпочати налаштування, ось терміни, які найімовірніше можуть заплутати читачів цього посібника. Цей короткий словник з самого початку робить ясною лексику Linux, GPU та локальних моделей.

Чому варто самостійно розміщувати LLM

Якщо ви вже зробили важку частину — орендували GPU сервер, встановили Ubuntu, навчилися користуватися SSH та утримуєте власні сервіси в робочому стані — це швидко стає розчаровуючим, коли розміщений AI все ще контролює останню милю. Він може відмовити в цілком звичайному запиті, приховати відповідь під купою застережень, змінити стиль відповіді без попередження та тримати кожен запит, що проходить через чужі межі. Для багатьох технічних користувачів це справжня розчарування: не просто те, що говорить модель, а хто контролює шар обслуговування, коли вона це говорить.

Цей посібник про виправлення цього за допомогою відкритих та локальних моделей, а не про трюки обходу для власницьких API. Ви самостійно розмістите Ollama на Ubuntu GPU сервері, запустите локальне виведення, перевірите, що GPU шлях реальний, і побачите, що змінюється, коли ви вибираєте іншу сім’ю моделей. Одне неправильне розуміння, яке варто уточнити з самого початку: самостійне розміщення не означає автоматично необмежене. Це означає, що ви контролюєте набагато більше стека — і ви перестаєте залежати від контрольованого постачальником шляху обслуговування — але модель, яку ви запускаєте, все ще може мати власну поведінку вирівнювання.

📝 Примітка: Команди в цьому посібнику перевірені відповідно до поточної документації Ollama, але наведені нижче результати терміналу є репрезентативними прикладами, а не живими записами тестування. Використовуйте їх як шаблон успіху, а не як твердження про продуктивність.

На кінець ви матимете робочий сервіс Ollama на Ubuntu, перевірений локальний API за адресою 127.0.0.1:11434, доказ того, що GPU-підтримане виведення насправді відбувається, та обґрунтоване порівняння між основною вирівняною моделлю та менш обмеженою альтернативою. Цей посібник написаний для читачів, які комфортно почуваються з SSH, Ubuntu, sudo та systemd, але яким не потрібен попередній досвід роботи з Ollama.

Точний Ubuntu GPU сервер, використаний для цього посібника

Цей посібник базується на реальній машині Ubuntu з одним GPU, тому що розпливчаті поради на кшталт “повинно працювати на більшості серверів” — це те, як посібники з самохостингу стають оманливими. Еталонна машина тут — це фактичний клас хосту, використаний для цього посібника: саме той тип машини, який орендував би просунутий користувач, лабораторія або невелика команда, коли вони хочуть приватного локального висновування без переходу прямо на стійку корпоративних прискорювачів. Далі буде розглянуто поведінку з кількома GPU, тому що Ollama змінюється, коли модель перевищує один чіп, але розглядайте цю частину як контекст на майбутнє, а не як доказ від цього точного сервера.

GPU сервер — Ryzen 9 3950X + RTX 4070 Ti Super

На практиці це дуже сильна конфігурація для повсякденних моделей класу 8B і все ще корисна для більшої локальної роботи до точки, де 16GB VRAM стає справжнім обмеженням. Модель на кшталт llama3.1:8b розміром приблизно 4.9GB легко поміщається на цей чіп. Модель на кшталт gpt-oss:20b розміром приблизно 14GB — це той вид верхнього тесту з одним GPU, який все ще має сенс тут. Модель на кшталт qwen3:30b розміром приблизно 19GB краще розглядати як опорну точку для того, що змінюється на більшому або подвійному GPU хосту, ніж як чистий варіант для цієї точної машини.

Це розрізнення важливе, тому що мета цієї статті — не втиснути найбільше можливе число в заголовок. Це показати, як виглядає розумний самохостований LLM сервер, коли ви хочете приватності, локального контролю та достатньої пам’яті GPU для запуску корисних моделей без постійних компромісів. Цей клас обладнання — це де самохостований висновування стає реалістичним, а не теоретичним.

Це також пояснює кілька виборів, які ви побачите пізніше: mistral використовується спочатку, тому що він дає швидкий, низькофрикційний доказ того, що стек працює, тоді як порівняння поведінки залишається в класі 8B, де ця машина комфортна. qwen3:30b все ще з’являється пізніше, але як теоретичний приклад типу моделі, яка може спровокувати розміщення з кількома GPU на більшому хосту, а не як живий доказ від цього сервера. З встановленими очікуваннями наступний крок — перевірити хост перед тим, як Ollama його торкнеться.

Запустіть ці перевірки перед встановленням Ollama

Почніть з nvidia-smi. Якщо цієї команди немає або вона не працює, зупиніться там і спочатку виправте драйвер NVIDIA. Не встановлюйте Ollama ще, тому що зламаний стек NVIDIA зробить кожен пізніший симптом схожим на помилку програми, коли насправді це помилка платформи.

Спочатку запустіть перевірку GPU:

nvidia-smi

❗Якщо Ubuntu каже, що nvidia-smi відсутня, не припускайте, що сервер не має GPU. Поширений режим відмови на орендованих Ubuntu-боксах — коли карта присутня, але все ще прив’язана до nouveau замість драйвера NVIDIA. Спочатку перевірте розділ “Виправлення проблеми драйвера Nvidia на Ubuntu“.

Здоровий результат на цьому класі сервера повинен виглядати приблизно так:

Коли nvidia-smi працює і GPU видна, продовжуйте з перевірками нижче.

Те, що ви хочете підтвердити, просто: встановлений GPU видна, вона повідомляє приблизно 16GB VRAM на цьому хості, і драйвер завантажений чисто. Якщо ви на багатогеймовому сервері, та сама команда повинна вивести кожну карту.

nvidia-smi -L

❗ Важливо: Поточна документація підтримки GPU Ollama використовує драйвер NVIDIA 531+ як реальну мінімальну вимогу для підтримуваного NVIDIA висновку. Розглядайте 531+ як вимогу для цього посібника, навіть якщо ви бачили старіші спільнотні замітки з цитуванням нижчих версій.

Тепер підтвердіть, що хост дійсно є середовищем Ubuntu, яке припускає цей посібник:

lsb_release -a

Нарешті, перевірте вільне місце на диску перед тим, як почати завантажувати моделі. Саме встановлення невелике; моделі ні. Як тільки ви вийдете за межі крихітних тестів, бібліотека 20B-30B може швидко з’їсти десятки гігабайтів, тому 100GB+ вільного місця — це правильний менталітет перед серйозною локальною роботою з моделями.

df -h /

Якщо ці перевірки пройдуть, ви очистили основні невідомі інфраструктури: GPU присутні, базова лінія драйвера розумна, Ubuntu підтверджена, і диск має місце для реальних завантажень моделей. Це точка, де встановлення Ollama стає чистим наступним кроком замість здогадки.

Виправлення проблеми драйвера Nvidia на Ubuntu

Виконайте кроки нижче, щоб виправити проблеми з командою “nvidia-smi”.

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

Якщо цей вивід показує карту NVIDIA і рядок, такий як Kernel driver in use: nouveau, встановіть рекомендований пакет драйвера Ubuntu замість встановлення лише nvidia-utils.

Встановіть пакет ubuntu-drivers-common (необхідний для управління драйверами) та заголовки ядра для вашого поточного ядра.

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

Сканьте вашу систему та перелічіть доступні власні драйвери (наприклад, драйвери GPU NVIDIA), які можна встановити.

ubuntu-drivers devices

Потім встановіть рекомендований пакет драйвера. У нашому випадку це було: nvidia-driver-595-open:

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

Після перезавантаження повторно запустіть:

nvidia-smi
nvidia-smi -L

Встановіть Ollama та підтвердіть, що служба працює правильно

Підтримуваний шлях Ubuntu — це офіційний інсталятор Ollama, а не користувацький потік tarball та не Docker. Це важливо, тому що цей посібник присвячений отриманню надійної локальної служби з передбачуваними налаштуваннями за замовчуванням, інтеграцією systemd та розумною поведінкою власництва на Linux.

Запустіть інсталятор точно так, як задокументовано:

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

На здоровій системі скрипт встановлює двійковий файл, створює користувача служби ollama, додає правильне членство в групах, коли вони доступні, записує модуль systemd та запускає службу, прив’язану до 127.0.0.1:11434.

Після завершення скрипту перевірте службу замість того, щоб припускати успіх:

sudo systemctl status ollama --no-pager

Ви шукаєте три речі: файл модуля присутній, служба увімкнена для завантаження, а Active: active (running) підтверджує, що сервер насправді запущений.

Спочатку встановіть облікові записи користувачів служби Linux конкретним способом, а потім подумайте про те, як і де буде обробляватися сховище моделей.

getent passwd ollama

Цей один рядок пояснює багато майбутньої поведінки. Моделі на Linux знаходяться під власністю служби, і якщо ви пізніше перемістите їх на інший диск без виправлення дозволів для користувача ollama, ви створюєте власні проблеми.

Ще одна перевірка закриває цикл на прив’язці за замовчуванням:

ss -tlnp | grep 11434

⚠️ Попередження: Ollama за замовчуванням не вимагає автентифікації на локальному API. Це нормально, коли він прив’язаний до 127.0.0.1, але небезпечно виставляти порт 11434 безпосередньо в Інтернет, як якби це була загартована публічна служба.

Якщо служба не запускається чисто, спочатку перейдіть до журналів замість сліпого переінсталювання:

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

Це найшвидший спосіб виявити проблеми з дозволами, помилки запуску, проблеми з виявленням драйверів або проблеми з прив’язкою. Коли служба працює здорово на localhost, наступне, що потрібно зрозуміти, — це як поведінка розміщення GPU працює під час виконання.

Як Ollama насправді використовує один або кілька GPU

Навіть якщо сервер, використаний для цього посібника, має один GPU, розуміння поведінки з кількома GPU все ще варто вивчити, оскільки багато користувачів можуть мати більші машини або можуть розширитися пізніше. Багато плутанини з двома GPU починається з неправильного очікування: “У мене два карти, тому обидві повинні світитися весь час.” Ollama не працює так. Практичне правило набагато простіше: якщо модель поміщається на один GPU, Ollama зазвичай триматиме її на одному GPU. Вона розповсюджується на кілька GPU лише тоді, коли модель не поміщається комфортно на одну карту.

Використовуйте ці два перевірки разом, коли хочете побачити продуктивність GPU:

ollama ps

watch -n 1 nvidia-smi

ollama ps показує вам, як обробляється завантажена модель. 100% GPU означає, що модель повністю знаходиться в пам’яті GPU. 100% CPU означає, що прискорення GPU не використовується. Змішаний стан говорить вам, що частина навантаження або резидентності вийшла за межі шляху GPU. watch -n 1 nvidia-smi доповнює це, показуючи живе використання VRAM на карту, поки модель завантажена.

Найшвидший спосіб розібратися в цих ролях:

📝 Примітка: CUDA_VISIBLE_DEVICES — це контроль видимості, а не перемикач “використовувати обидва GPU”. Якщо ви коли-небудь обмежуєте доступ до GPU, віддавайте перевагу UUID з nvidia-smi -L замість числових ID, оскільки порядок GPU може відрізнятися між середовищами та перезавантаженнями.

Запустіть вашу першу локальну модель і перевірте GPU-інференцію

На цьому етапі вам не потрібна гігантська модель, щоб довести, що сервер працює. Вам потрібен швидкий, чесний успіх. mistral — це хороший перший вибір, оскільки вона невелика, швидко завантажується і легко завантажується, хоча llama3.1:8b буде пізніше базовою лінією для порівняння поведінки.

Почніть з витягування моделі:

ollama pull mistral

Тепер запустіть через неї невеликий запит, щоб машина робила щось корисне, а не просто адміністративні завдання. Відповідь може зайняти кілька секунд.

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

Щоб довести, що це GPU-підтримана інференція, а не CPU-резервна копія, перевірте стан виконання:

ollama ps

І щоб побачити, що вже на диску, перелічіть локальний інвентар:

ollama list

mistral — це правильний перший доказ, оскільки він дає вам швидку відповідь без перетворення валідації налаштування на довге очікування. Пізніше llama3.1:8b стає більш корисною, оскільки вона є сильнішою вирівняною базовою лінією для порівняння поведінки моделі.

Нарешті, перевірте, де Linux-встановлення зберігає моделі:

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

Цей шлях — /usr/share/ollama/.ollama/models — це стандартне сховище моделей Linux, задокументоване Ollama.

Коли ви побачите успішну відповідь, 100% GPU в ollama ps і збільшення використання диску в очікуваному місці, у вас буде перший значущий доказ того, що локальний стек працює.

Доведіть, що це сервер, а не просто обгортка CLI

Командний рядок — це добре, але причина для самостійного розміщення Ollama полягає не тільки в тому, щоб спілкуватися всередині терміналу. Це запуск локального сервера висновків, який можуть викликати інші інструменти, скрипти та програми без надсилання запитів через чужу межу API. Найшвидший доказ — один чистий HTTP-запит до нативної кінцевої точки Ollama.

Надішліть локальний запит генерації з вимкненим потоком, щоб перша відповідь була легко перевіряється:

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

Успішна відповідь повинна повернутися як JSON і виглядати приблизно так:

{
  "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
}

Контрольний список успіху простий: HTTP-запит працює локально, повертається дійсний JSON, присутній done: true, і відповідь моделі знаходиться в response. Це точка, де Ollama перестає бути “CLI, який просто завантажує моделі” і стає інфраструктурою, яку ви насправді можете інтегрувати в локальні інструменти та автоматизацію.

Якщо вам потрібна сумісність з програмним забезпеченням, яке очікує форму запиту у стилі OpenAI, Ollama також надає локально кінцеві точки /v1:

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

📝 Примітка: Цей ярлик “сумісний з OpenAI” легко неправильно прочитати. Це не означає, що ви спілкуєтеся з OpenAI, і це не змінює той факт, що сервер все ще локальний. Це означає лише те, що форма запиту достатньо знайома для інструментів і SDK, створених навколо шаблону API OpenAI. Базова URL залишається http://localhost:11434/v1/, і будь-який заповідник ключа API, на якому наполягають деякі бібліотеки клієнтів, можна ігнорувати для локального використання Ollama.

Звідки насправді беруться обмеження моделей

Це та частина, яка зазвичай зводиться до однієї невизначеної ідеї «цензури», але технічно задіяно три різні рівні: рівень обслуговування постачальника, вирівнювання та настройка інструкцій моделі, а також поведінка запиту/виконання, якою ви керуєте самі. Самостійне розміщення драматично змінює деякі з цих рівнів. Це не стирає всі з них.

Простий спосіб це уявити:

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

Результати:
– Рівень обслуговування, контрольований постачальником, зникає з локального шляху
– Локальна мережа та межа логування стають вашими
– Власне навчання та вирівнювання моделі все ще йдуть з моделлю

Після розділення рівнів попередні кроки налаштування стають набагато змістовнішими:

Ви можете думати про це як про театральну виставу. Самостійне розміщення змінює сцену, освітлення, мікрофони та режисерські замітки. Це не перенавчає актора. Якщо модель була настроєна на обережні відповіді, часті застереження або відмову від певних типів формулювання, локальне запущення не магічно скасує це навчання.

Те, що ваше поточне налаштування вже довело, є вужчим, але все ще важливим: ви контролюєте серверний процес, ви контролюєте межу API, і ви більше не маршрутизуєте локальні запити через рівень модерації, контрольований постачальником. Це реальний зрушення в приватності та контролі. Те, що це не довело, це те, що кожна локальна модель буде поводитися однаково або що кожна відмова в майбутньому була викликана хмарним постачальником.

Ось де в гру вступає вибір моделі. Якщо ви хочете практичного ефекту менших застережень, більш прямих відповідей або поведінки, менш схильної до відмови, ви туди не потрапляєте, кажучи «самостійно розміщено» голосніше. Ви туди потрапляєте, вибравши іншу сім’ю моделей або fine-tune — і розуміючи компроміси, які з цим пов’язані.

Виберіть менш обмежену локальну модель

Якщо ви хочете справедливого тесту, порівнюйте моделі, які займають приблизно однаковий розмір. Саме тому цей посібник використовує llama3.1:8b як основну вирівняну базову лінію та dolphin3 як менш обмежену модель для порівняння. Обидві мають розмір близько 4.9GB, що полегшує інтерпретацію різниці в поведінці без надто різкої зміни обсягу апаратного забезпечення.

Завантажте моделі порівняння локально:

ollama pull llama3.1:8b

ollama pull dolphin3

# Optional older reference model
ollama pull dolphin-mistral

Ось практичне пояснення трьох назв, які ви найімовірніше побачите в цій частині екосистеми Ollama:

⚠️ Попередження: Інша тонка настройка — це не “та ж модель з видаленою цензурою”. Вона може змінити прямолінійність, щільність дисклеймерів та готовність слідувати фреймінгу користувача, але також може змінити тон, точність, послідовність та загальну особистість.

Продуктивність GPU

Перед запуском потрібних моделей спочатку важливо розуміти можливості та обмеження задіяного обладнання. Отже, потрібно протестувати дві речі концептуально: по-перше, як виглядає чиста поведінка одного GPU на фактичному обладнанні, використаному для цього посібника; по-друге, що змінюється, якщо пізніше запустити той самий стек на хості з двома GPU. Обидва важливі, але тільки перший — це жива доказ з цієї точної машини.

На цьому сервері кращий верхній тест часу виконання — gpt-oss:20b. Він досить великий, щоб бути цікавим, але все ще має сенс на одній карті 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."

Після завантаження моделі підтвердіть стан часу виконання:

ollama ps

Це практичний доказ, який вам потрібен на цій машині. Він показує, що менші моделі легко поміщаються і що більша, але все ще реалістична локальна модель може наблизити один карту 16GB до її корисної межі без необхідності кількох GPU.

Якщо пізніше запустити Ollama на хості з двома GPU, модель на кшталт qwen3:30b стає типом робочого навантаження, яке може продемонструвати розміщення на кількох GPU. Робочий процес той самий — спостерігайте за nvidia-smi, запустіть модель, перевірте ollama ps — але сенс не в тому, щоб обидві карти світилися заради цього. Сенс полягає в тому, щоб підтвердити, що Ollama розповсюджує модель на кілька GPU тільки тоді, коли модель більше не поміщається чисто на одну.

Розгляд обходу цензури

Для порівняння поведінки тримайте умови контрольованими, щоб ви тестували модель більше, ніж випадковість. Використовуйте один і той же endpoint, один і той же prompt, stream: false, низьку температуру та фіксоване seed:

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

Потім повторіть той же запит з “model”: “dolphin3”. Фіксоване seed не усуває всю варіативність, але зменшує достатньо випадковості, щоб різниці в тоні та відповідності було легше помітити.

1. Безпечний перший prompt: “Чи означає самостійне розміщення LLM, що користувач повністю контролює поведінку моделі? Дайте відповідь у вигляді 4 пунктів. Будьте прямолінійні та пропустіть вступи.” Типова відповідь llama3.1:8b звучить приблизно так:

   - 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.

   Типова відповідь dolphin3 на той же prompt часто звучить більш стисло:

   - 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. Другий корисний prompt: “Напишіть гострий п’ятирядковий аргумент на користь того, чому команда, чутлива до приватності, може відхилити AI, керовану постачальником. Без вступу та без висновку.” llama3.1:8b зазвичай дотримується, але в більш виміреному корпоративному тоні. dolphin3 охочіше дотримується запитуваної гостроти. Це той вид різниці, який ви шукаєте тут: не драматичний беззаконний результат, а зміни в прямолінійності, фреймуванні та щільності дисклеймерів.
3. Третю категорію prompt для валідації можна сформулювати так: попросіть п’ять фактичних причин, чому письменник може віддати перевагу локальній моделі для незвичайної, нішевої або немейнстрімної творчої роботи. На практиці обидві моделі відповідають, але dolphin3 зазвичай залишається ближче до запитуваного неморалізуючого тону та прямих відповідей.

Закономірність виглядає так:

І таким чином, ось чесні висновки:

1. Вибір локальної моделі значно змінює поведінку результату.
2. Різні моделі відрізняються в прямолінійності та щільності дисклеймерів.
3. Самостійне розміщення усуває контрольований постачальником рівень обслуговування.

Тепер ви контролюєте стек, а не лише промпт

Розчарування на початку цього посібника ніколи не було лише про модель, яка відмовляється виконати запит. Це було про те, що рівень обслуговування, рівень політики та межа приватності знаходилися десь в іншому місці. Після цього налаштування це змінилося. Ваш сервер висновків працює на вашій машині Ubuntu, локальна межа API — ваша, меню моделей — ваше, а стандартні значення промпту/середовища виконання — ваші для налаштування.

Те, що все ще вимагає судження — це частина, яку жодний інсталятор не може вирішити для вас: вибір моделей, які відповідають вашому випадку використання, їх спрямування розумними стандартними значеннями та безпечне надання доступу, якщо ви виходите за межі localhost. Це справжня форма контролю самостійного хостингу. Не магічна свобода від кожного обмеження, а власність над стеком, який визначає, як, де і з якою моделлю відбувається висновок. Якщо ви хочете найкращий наступний крок, почніть зі створення користувацького Modelfile — або поставте безпечний віддалений доступ перед локальним API, коли будете готові.

Що робити після базового налаштування

На цьому етапі основна обіцянка виконана. Сервер працює, API працює, GPU шлях реальний, а різниці в поведінці моделі більше не абстрактні. Наступний крок — це не «встановлювати більше речей вслід». Це налаштування частин стека, які тепер належать вам.

Налаштування поведінки моделі за допомогою Modelfile

Modelfile — це найчистіший спосіб змінити локальні налаштування запитів без дотику до ваг моделі. Почніть з перевірки поточного визначення моделі, щоб зрозуміти, що ви розширюєте:

ollama show --modelfile dolphin3

Потім створіть просту локальну варіацію:

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

Побудуйте її як нову назву моделі та протестуйте:

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

❗ Важливо: Modelfile змінює поведінку запитів та виконання, а не історію навчання моделі. Він може керувати тоном та налаштуваннями за замовчуванням, але не перенавчає базову модель.

Захист налаштування

Прив’язка до localhost — це хороше налаштування за замовчуванням, але це не кінець історії безпеки. Спочатку перевірте поточну адресу прослуховування:

ss -tlnp | grep 11434

Якщо мета — зберегти Ollama лише локально, явно закріпіть цю поведінку за допомогою systemd override:

sudo systemctl edit ollama

Додайте наступне:

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

Потім перезавантажте та перезапустіть сервіс:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Якщо вам пізніше потрібен віддалений доступ, не публікуйте 11434 безпосередньо. Замість цього поставте перед ним зворотний проксі з TLS та аутентифікацією:

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;
    }
}

⚠️ Попередження: Розглядайте публічне розкриття як окремий проект посилення безпеки. Ollama сам по собі — це локальний сервер висновків, а не готовий до виробництва публічний API шлюз з вбудованою аутентифікацією, обмеженням швидкості та інтернет-орієнтованими налаштуваннями за замовчуванням.

Рекомендовані моделі для цього обладнання

Після того, як базова установка працює, найбільш цінне поліпшення — це вибір моделей, які насправді добре підходять для цієї машини, замість переслідування найбільшого заголовку. Для одного сервера 4070 Ti SUPER, використаного тут, практичне меню виглядає так:

Автозапуск та обслуговування

Після веселої частини приходить частина, яка зберігає локальний сервер LLM придатним до використання через місяць. Підтвердіть поведінку під час завантаження, тримайте сервіс оновленим, спостерігайте за журналами та знайте, як вивантажити великі моделі, коли вам потрібна VRAM назад.

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

Для повсякденних операцій з моделями, це команди, які ви будете використовувати найчастіше:

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

А якщо сховище моделей потрібно перемістити на більший диск, підготуйте каталог для користувача сервісу перед тим, як перенаправити Ollama:

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

Потім встановіть OLLAMA_MODELS через systemctl edit ollama. Цей один деталь власності — це те, що запобігає перетворенню міграції сховища на проблему дозволів.

Довідка з усунення несправностей

Коли щось ламається, найшвидший шлях — це зазвичай відповідність симптому правильному рівню замість спроби випадкових циклів переустановки. Використовуйте цю таблицю як перший прохід:

Якщо ви пам’ятаєте тільки одне операційне правило з цього розділу, нехай це буде: розглядайте Ollama як реальний сервіс, а не як одноразову утиліту CLI. Журнали, власність, адреси прив’язки та шляхи сховища мають таке ж значення, як вікно запиту.