Як безпечно розгорнути Ollama на VPS

Що ви створюєте

Одна open-weight мовна модель працює на сервері, який ви контролюєте, приймає запити через HTTP API і, за бажання, доступна через сторінку чату у браузері. Ollama завантажує модель, розміщує її в пам’яті та обробляє запити на http://127.0.0.1:11434. Встановлення виконується однією командою. Усе складне відбувається в інших частинах: потрібно вибрати модель, яка справді поміститься в оперативній пам’яті вашого VPS, і не опублікувати випадково сервер інференсу без автентифікації для всього інтернету.

Спочатку два важливі попередження. VPS лише з CPU повільно запускає невеликі моделі, а API взагалі не має вбудованої автентифікації. Нижче докладно розглянуто обидві проблеми, оскільки саме через них найчастіше виникають серйозні наслідки.

Перевірка вимог у цифрах

Обсяг пам’яті моделі приблизно дорівнює її розміру файлу плюс близько 1 GB накладних витрат під час роботи та додатковий обсяг для контекстного вікна. Стандартні теги більшості популярних моделей Ollama, зокрема llama3.2:3b, llama3.1:8b і mistral:7b, використовують 4-бітне квантування (позначається як Q4_K_M). Для кожного мільярда параметрів це потребує близько 0.5 GB RAM. Не всі стандартні варіанти є Q4: невеликі моделі, такі як smollm2:135m, постачаються у 16-бітному форматі. Тому перед розрахунками перевірте рядок із параметрами квантування на сторінці моделі в бібліотеці. Отже, арифметика проста, і саме вона визначає все. Останній складник задаєте ви: збільшення num_ctx понад невелике стандартне значення Ollama дає змогу працювати з довшими запитами, але збільшує обсяг KV cache у RAM. Тому визначте довжину контексту до того, як оцінювати, чи поміститься модель.

Модель 3B, така як llama3.2:3b, завантажується приблизно як файл на 2 GB і потребує близько 4 GB вільної RAM для роботи. Модель 7B або 8B, така як mistral:7b чи llama3.1:8b, займає на диску приблизно 5 GB і потребує близько 8 GB RAM, а для комфортної роботи — 16 GB. Моделі 13B або 14B потребують приблизно 16 GB. Для моделей діапазону від 30B до 70B потрібен сервер із великим обсягом RAM або, реалістичніше, GPU. На CPU VPS така модель або не поміститься, або відповідатиме настільки повільно, що буде непридатною.

Тепер про швидкість, оскільки її часто недооцінюють. Інференс на CPU обмежений пропускною здатністю пам’яті, а не тактовою частотою. Спільний vCPU VPS має невисоку пропускну здатність. Очікуйте від однозначної до невисокої двозначної кількості токенів за секунду: модель 7-8B Q4 може генерувати від 4 до 10 токенів за секунду, а модель 3B — від 10 до 25. GPU приблизно на порядок швидший. Це навмисно приблизні значення. Найкраще виміряти продуктивність на власному сервері; нижче показано, як це зробити під час запуску. Довіряйте власним eval rate, а не числу з будь-якої статті, зокрема з цієї.

Практичний висновок: невеликі квантизовані моделі на CPU справді придатні для підготовки чернеток, узагальнення та класифікації, якщо вас влаштовує така швидкість. Для більших або швидших моделей закладайте бюджет на GPU instance. Якщо ви хочете побачити цей розрахунок від початку до кінця для конкретної моделі, запуск Nemotron 3.5 Lightning на VPS пояснює, який тег завантажити, скільки RAM їй фактично потрібно та чи достатньо продуктивності в режимі лише CPU.

Щоб порівняти конкретну модель із конкретним сервером, оцініть її обсяг пам’яті тут:

Встановлення Ollama

Є два коректні способи. На чистому VPS найпростіше скористатися офіційним скриптом:

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

Скрипт створює системного користувача з іменем ollama, встановлює бінарний файл у /usr/local/bin/ollama і реєструє службу systemd з назвою ollama.service, яка запускається під час завантаження системи та прослуховує 127.0.0.1:11434. Переконайтеся, що служба працює:

systemctl status ollama
ollama --version

Якщо ви вже використовуєте Docker, скористайтеся контейнером:

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

Зверніть увагу на префікс 127.0.0.1: у зіставленні портів. Він прив’язує порт лише до localhost. Якщо вказати -p 11434:11434, порт буде опубліковано на всіх інтерфейсах. Саме цієї помилки застерігає уникати розділ про безпеку. Виберіть один спосіб встановлення. Не запускайте скрипт і контейнер одночасно, інакше два процеси конкуруватимуть за порт.

Завантажте та запустіть свою першу модель

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

pull завантажує шари моделі на диск (для цієї моделі — близько 2 GB). run завантажує їх у пам’ять і відкриває запрошення >>>. Введіть запитання. Перший токен може з’явитися через кілька секунд, поки ваги завантажуються з диска в RAM. Після цього відповідь виводиться потоком. Введіть /bye, щоб завершити чат. Ollama продовжує працювати у фоновому режимі.

Перевірте, що завантажено та як це використовується:

ollama ps

Стовпець PROCESSOR показує фактичну ситуацію. Значення 100% CPU означає, що GPU не використовується. Саме тому робота повільна. Виміряйте реальну швидкість за допомогою прапорця verbose:

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

Рядок eval rate, виведений наприкінці, показує кількість токенів за секунду на цьому обладнанні. Орієнтуйтеся на це значення під час планування.

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

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

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

Якщо запускати їх інтерактивно від власного користувача, вони зберігаються в ~/.ollama/models. У контейнері вони розміщуються в іменованому томі ollama. Це важливо, оскільки квантовані ваги швидко займають багато місця: модель 3B потребує приблизно 2 GB, модель 7-8B — приблизно 5 GB, а модель 14B — приблизно 9 GB. Якщо завантажити чотири моделі для порівняння, непомітно можна витратити 20 GB. Розрахуйте обсяг диска для моделей, які плануєте залишити, а решту видаліть за допомогою ollama rm <model>. Якщо на тому самому VPS уже працює сервіс із великим власним споживанням дискового простору, наприклад PhotoPrism або Immich зі збереженою фототекою, спочатку відніміть його обсяг від вільного місця. Залишок вважайте реальним бюджетом дискового простору для моделей.

Запустіть його як керований вами сервіс

Скрипт інсталяції вже зареєстрував ollama.service, тому сервіс запускається після перезавантаження без додаткових дій. Варто змінити тривалість перебування моделі в пам’яті та, у деяких конфігураціях, адресу прив’язки. Обидва параметри задаються в drop-in-конфігурації systemd, щоб оновлення Ollama їх не перезаписало:

sudo systemctl edit ollama.service

Додайте це під заголовком [Service], який показує редактор:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE визначає, як довго модель залишається в пам’яті після останнього запиту (за замовчуванням 5 хвилин). Збільште це значення на сервері, до якого ви звертаєтеся протягом усього дня, щоб не завантажувати ваги під час кожного запиту. На сервері з обмеженим обсягом пам’яті встановіть 0, щоб звільняти RAM одразу після завершення запиту. Якщо потрібно, щоб модель залишалася в пам’яті необмежено довго, а не протягом фіксованого періоду, у матеріалі як назавжди залишити модель Ollama завантаженою описано поле keep_alive для окремого запиту та спосіб повторного прогрівання ваг після перезавантаження, а не під час першого повільного запиту. systemctl edit перезавантажує для вас unit-файли, тому для застосування зміни перезапустіть сервіс:

sudo systemctl restart ollama

Найважливіший аспект безпеки

За замовчуванням Ollama прив’язується до 127.0.0.1:11434, тому доступ до нього мають лише процеси безпосередньо на VPS. Це правильне значення за замовчуванням. Залиште його.

API не має автентифікації. Узагалі. Немає API key, входу чи обмеження частоти запитів. Єдиний список дозволів, який він має, — OLLAMA_ORIGINS — лише визначає, яким browser origin дозволено надсилати запити (CORS). Він не заважає виконувати запити через curl або скрипт на іншій машині. Будь-хто, хто має доступ до порту 11434, може запускати будь-яку завантажену модель, завантажувати нові, видаляти їх і безстроково завантажувати CPU або GPU на 100%. Сканери на кшталт Shodan індексують тисячі відкритих екземплярів Ollama, а доступний з інтернету екземпляр знаходять і використовують у зловмисних цілях протягом кількох годин.

Тому єдина помилка, якої не можна припускатися: не встановлюйте OLLAMA_HOST=0.0.0.0 і не відкривайте 11434 у firewall. Це відкриває неавтентифікований inference server для всього інтернету. Жодні налаштування не роблять raw 11434-on-0.0.0.0 безпечним, оскільки жоден документований параметр Ollama не додає автентифікацію до локального API, а список дозволених origin не є входом. Це правило стосується саме цього сервісу, а не забороняє відкривати порти взагалі: self-hosted relay RustDesk для віддаленого робочого столу має приймати публічний трафік, щоб виконувати свою функцію, і забезпечує це власною автентифікацією на основі ключів та коротким документованим списком портів. В Ollama немає ні першого, ні другого.

Є три безпечні способи отримати доступ до моделі не з самого сервера:

• Залиште доступ локальним. Якщо єдиним клієнтом є інша програма на тому самому VPS, cron script, bot або MCP server, який з’єднує ваші інструменти з моделлю, залиште прив’язку до 127.0.0.1 і налаштуйте цю програму на виклик http://127.0.0.1:11434. Нічого не відкривається, і більше нічого не потрібно.
• Отримуйте доступ через приватний тунель. Підключіть VPS до WireGuard VPN, який ви адмініструєте самостійно, встановіть OLLAMA_HOST як адресу тунелю (наприклад, 10.8.0.1, а не 0.0.0.0), і підключатися зможуть лише VPN peers. Для публічного інтернету порт 11434 залишатиметься недоступним.
• Розмістіть перед ним reverse proxy з автентифікацією. Завершуйте TLS і вимагайте password або token у nginx, Traefik чи Caddy, а потім проксіюйте запити до 127.0.0.1:11434. Ollama зберігає прив’язку до localhost, а єдиним компонентом, що прослуховує публічний порт, буде proxy. Це така сама схема, як розміщення сертифіката Let's Encrypt у nginx перед будь-яким локальним сервісом.

Саме цей варіант із reverse proxy ви налаштуєте далі в chat UI, де буде додано повноцінний вхід.

Додайте chat UI з Open WebUI за TLS

Open WebUI — це self-hosted chat interface. Запустіть його в Docker і підключіть до локального Ollama:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Прапорець --network=host є важливою деталлю на Linux VPS. Він розміщує контейнер у мережевому просторі імен хоста, тому 127.0.0.1 усередині контейнера є власним loopback хоста, а контейнер підключається до Ollama через 127.0.0.1:11434, не змушуючи Ollama слухати будь-який інший інтерфейс. Рецепт із bridge network, який ви побачите в іншому розділі, — --add-host=host.docker.internal:host-gateway із OLLAMA_BASE_URL=http://host.docker.internal:11434 — тут не працює: це ім’я вказує на gateway Docker bridge, а сервіс, прив’язаний до 127.0.0.1 на хості, недоступний через bridge. У результаті Open WebUI лише повідомляє, що не може підключитися до Ollama.

Недолік host networking полягає в тому, що Open WebUI тепер слухає порт 8080 хоста на всіх інтерфейсах. Будь-яке зіставлення -p ігнорується, і Docker виводить відповідне попередження. Тому закрийте 8080 і на хості, і у firewall провайдера. Нехай TLS reverse proxy буде єдиною точкою публічного доступу. Під час першого відвідування Open WebUI запропонує створити обліковий запис адміністратора. Цей обліковий запис є вашим рівнем автентифікації, тому виберіть надійний пароль.

Щоб відкрити chat із ноутбука через HTTPS, розмістіть TLS reverse proxy перед 127.0.0.1:8080. Якщо на цьому сервері ви вже маршрутизуєте кілька Docker-застосунків, Traefik з автоматичним TLS для багатьох застосунків буде найзручнішим варіантом: один блок label випустить сертифікат і направить chat.example.com до Open WebUI. Такий самий підхід із маршрутизацією через label для кожного застосунку використовуватимуть усі інші browser front-end на сервері — від status dashboard до чогось більш розважального, наприклад Halcyon, який подає бібліотеку Jellyfin як відеопрокат 90-х, кожен зі своїм hostname і власним входом. Правило з розділу про безпеку залишається чинним: proxy керує публічним портом і входом, а Ollama залишається на localhost, тоді як власний 8080 Open WebUI залишається закритим firewall.

Використовуйте OpenAI-сумісну кінцеву точку у своєму коді

Ollama підтримує підмножину OpenAI Chat API за адресою /v1, тому більшість клієнтських бібліотек OpenAI працює після зміни двох параметрів: базової URL-адреси та одноразового ключа.

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 потрібен клієнтській бібліотеці, але Ollama його ігнорує, тому можна використовувати будь-який рядок. model має бути назвою моделі, яку ви вже завантажили; невідома назва повертає відповідь 404 з model 'x' not found. Звичайний виклик curl працює за тим самим принципом:

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

Так само модель підключають до інструментів для агентів і редакторів. Якщо ви вже розробляєте на цьому сервері, локальна модель може обслуговувати скрипти та плагіни разом із Claude Code, запущеним на VPS у tmux, щоб недорогі приватні чернетки не використовували платний API, а складне міркування виконувала hosted-модель.

Режими відмови з точними рядками, які ви побачите

Процес було «Killed» під час генерації. Ви запускаєте велику модель, і термінал виводить Killed або журнал сервера (journalctl -u ollama) містить рядок, що починається з llama-server process has terminated. Це формулювання в Ollama 0.40.7, перевірене 21 October 2026; у старіших версіях було llama runner process has terminated: signal: killed. Linux OOM killer зупинив процес, оскільки моделі потрібно більше RAM, ніж доступно на сервері. Підтвердьте причину за допомогою sudo dmesg | grep -i oom. Там ви побачите рядок на кшталт Out of memory: Killed process .... Використайте меншу або сильніше квантизовану модель, llama3.2:3b замість 13B, або додайте swap. Тоді навантаження, яке лише трохи перевищує обсяг фізичної RAM, повільно завершиться замість аварійного завершення. Swap перетворює миттєвий збій на повільну відповідь. Він не робить модель 70B практичною на 4 GB. Завершення процесу відбувається без повідомлення, якщо ви випадково не стежите за терміналом. На сервері, до якого ви звертаєтеся віддалено, підключення unit OnFailure= до ollama.service, який надсилає повідомлення на сервер ntfy для push-сповіщень, дає змогу дізнатися про збій одразу, а не під час наступного запиту.

Ollama відмовляється завантажувати модель. Запит одразу завершується помилкою, а не аварійним завершенням процесу, і журнал сервера містить model is too large for system memory (Ollama 0.40.7, перевірене 21 October 2026). Старіші версії безпосередньо виводили Error: model requires more system memory (X GiB) than is available (Y GiB) у командному рядку. Це контрольований варіант описаного вище збою: Ollama розрахувала потребу в пам’яті й зупинилася, не передавши процес OOM killer. Виберіть модель, вимоги якої менші за обсяг вільної RAM (перевірте за допомогою free -h), зменште довжину контексту або перейдіть на більший VPS. Жоден flag не дасть змоги завантажити модель, якщо для неї фізично недостатньо пам’яті.

Перший токен з’являється дуже довго, а потім усе працює нормально. Холодна модель протягом п’яти–тридцяти секунд нічого не виводить, а потім нормально передає відповідь потоком. Це означає, що ваги вперше завантажуються з диска в RAM. Повільне сховище збільшує цю затримку. Після завантаження модель залишається в пам’яті протягом усього часу OLLAMA_KEEP_ALIVE, тому на другий запит відповідає одразу. Якщо початкове завантаження перевищує timeout на будь-якому етапі обробки запиту, ви отримаєте помилку, а не повільну відповідь. Визначення рівня, який повідомив про context deadline exceeded, покаже, де саме завершився timeout: на клієнті, проксі чи під час завантаження моделі. Збільште це значення, якщо затримка заважає роботі, і використайте ollama ps, щоб перевірити, чи завантажена модель.

Усе просто працює повільно. Швидкість становить десять токенів на секунду або менше, але помилок немає. Це інференс на CPU, який працює саме так. ollama ps показує 100% CPU, тобто GPU немає. Це не помилка. Жодне налаштування не перетворить CPU на GPU, оскільки основним обмеженням є пропускна здатність пам’яті. Однак на VM варто перевірити один параметр: Ollama визначає кількість потоків за кількістю фізичних ядер, а hypervisor може повідомляти її неправильно. У сеансі ollama run --verbose спробуйте /set parameter num_thread 4 (або кількість ваших vCPU), повторіть той самий запит і залиште значення, яке дає найкращий eval rate. Далі використайте меншу модель, прийміть таку швидкість або перейдіть на GPU instance. Перед висновком про несправність виміряйте фактичну швидкість за допомогою --verbose. Якщо очікування спричинене не швидкістю, а довжиною відповіді, обмеження відповіді за допомогою num_predict не дасть моделі витрачати хвилини на токени, які ви все одно не читатимете.

Інша машина отримує Connection refused. З ноутбука актуальний curl (8.23.0, перевірений 21 October 2026) виводить curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server, а curl 8.5.0, який постачається з Ubuntu 24.04, виводить curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server. Слова «Connection refused» з’являються лише після додавання -v у рядку connect to <ip> port 11434 from ... failed: Connection refused. Це очікувана поведінка: Ollama прослуховує лише localhost. Не «виправляйте» це прив’язуванням до 0.0.0.0. Саме так виникає описана вище помилка з відкритим доступом. Підключайтеся до моделі через VPN або через proxy з автентифікацією.

Ви відкрили 11434 для інтернету. Якщо ви встановили OLLAMA_HOST=0.0.0.0, відкрили порт у firewall і тепер бачите завантаження моделей, яких не запускали, або невідомі клієнти завантажують CPU на 100%, сервер було виявлено та використано сторонніми особами. Це основна помилка, а не рідкісний виняток. Прив’яжіть сервіс до 127.0.0.1 або адреси VPN, закрийте 11434 у firewall і додайте автентифікацію перед сервісом. Вважайте, що все, що було доступне за цією адресою, поки порт залишався відкритим, запитували сторонні користувачі.

Резервне копіювання та оновлення

Даних зі станом небагато, тому втрачати майже нічого. Моделі можна повторно завантажити, тому резервне копіювання потрібне лише для тому даних Open WebUI, облікових записів, історії чатів, налаштувань і будь-якого drop-in-файлу systemd, який ви створили. Створіть резервну копію тому за допомогою тимчасового контейнера:

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

Оновіть Ollama, повторно запустивши інсталяційний скрипт. Open WebUI оновлюйте за допомогою docker pull ghcr.io/open-webui/open-webui:main, а потім пересоздайте контейнер. Зауваження щодо дискового простору для гілки 0.40: Ollama 0.40.2 почала у фоновому режимі оновлювати моделі, завантажені в попередніх версіях, і зберігати оригінальні копії як резервні. Тому вони займають додатковий дисковий простір, доки їх не буде видалено. У версії 0.40.3 (11 October 2026) це фонове оновлення призупинили. Після оновлення перевірте df -h і перегляньте примітки до випуску, щоб знайти команду для видалення цих резервних копій. Не фіксуйте версії надовго: якість моделей і runtime швидко змінюються, тому читайте примітки до випуску та повторно тестуйте продуктивність на власному сервері, а не покладайтеся на показники минулого кварталу.

FAQ

Чи справді можна запустити LLM на VPS лише з CPU?

Так, але з обмеженнями. Невеликі квантизовані моделі діапазону від 3B до 8B працюють на CPU і придатні для створення чернеток, узагальнення та класифікації. Однак вони працюють повільно — приблизно від кількох до 10 з лишком токенів за секунду на shared vCPU. Моделі від 13B і більше працюють дуже повільно або взагалі не поміщаються в RAM. Для реальної швидкодії чи більших моделей потрібен GPU instance.

Скільки RAM потрібно кожній моделі?

Орієнтовне правило для 4-бітних (Q4) тегів, які більшість популярних моделей використовує за замовчуванням: приблизно 0.5 GB RAM на кожен мільярд параметрів для ваг, а також близько 1 GB накладних витрат і трохи більше для контексту. Тому моделі 3B потрібно приблизно 4 GB вільної пам’яті, моделі 7-8B — близько 8 GB, а моделі 14B — близько 16 GB. Перевірте доступний запас пам’яті за допомогою free -h і залиште місце для операційної системи та інших процесів на сервері.

Чи має Ollama автентифікацію API?

Ні. Ollama не має вбудованої автентифікації, API key або rate limit. Будь-хто, хто може підключитися до порту 11434, отримує повний контроль над ним. Параметр OLLAMA_ORIGINS лише обмежує browser origins, яким дозволено надсилати запити, але не визначає, хто може підключитися. Саме тому за замовчуванням Ollama прив’язується до 127.0.0.1, а порт 11434 не можна відкривати для інтернету на 0.0.0.0. Підключайтеся локально, через приватну VPN або через reverse proxy, який додає форму входу.

Як додати web-інтерфейс для чату?

Запустіть Open WebUI у Docker з параметром --network=host. Це дасть змогу використовувати loopback хоста й підключатися до native Ollama через http://127.0.0.1:11434. Потім розмістіть TLS reverse proxy перед його портом 8080, щоб отримувати доступ із ноутбука. Залиште 8080 закритим у firewall, щоб proxy був єдиною публічно доступною точкою входу. Власний admin account Open WebUI забезпечує вхід, а пароль для нього потрібно встановити під час першого запуску.

Як викликати його з власного застосунку?

Використовуйте OpenAI-compatible endpoint за адресою http://127.0.0.1:11434/v1. Вкажіть цю base URL у будь-якому OpenAI SDK, передайте будь-який рядок як API key, оскільки він ігнорується, і встановіть model у назву моделі, яку ви завантажили. Наявний код OpenAI зазвичай працює без змін, окрім base URL і key.