Ollama чи llama.cpp на VPS: що обрати

Ollama проти llama.cpp: який рівень ви хочете запускати?

Ollama і llama.cpp не є конкурентами в тому сенсі, який передбачає це запитання. llama.cpp — це рушій інференсу: він завантажує файл моделі та перетворює prompt на токени. Ollama — це менеджер моделей, фоновий daemon і HTTP API, що працює поверх цього рушія. У README Ollama досі вказано llama.cpp як бекенд інференсу (перевірено 2 August 2026). Отже, насправді питання полягає в тому, з яким рівнем ви хочете працювати на своєму VPS, а не в тому, який варіант швидший.

Запускайте Ollama, якщо вам потрібен сервіс, який завантажує моделі за іменем і продовжує працювати без постійного контролю. Запускайте llama.cpp безпосередньо, якщо сервер має обмежені ресурси й вам потрібно вибрати точний файл моделі, точний розмір контексту та точну кількість потоків, оскільки на невеликому VPS кожен із цих параметрів споживає пам’ять, якої у вас немає.

Що насправді являє собою кожен проєкт

llama.cpp — це реалізація інференсу трансформерів мовами C і C++ на основі бібліотеки ggml. Вона читає файли GGUF. GGUF (GGML universal file format) — це контейнер в одному файлі, який містить ваги, токенізатор і метадані, потрібні рушію для запуску моделі. Проєкт постачає окремі бінарні файли для різних завдань. llama-server — це HTTP-сервер, llama-cli — інтерактивний prompt, а llama-bench вимірює пропускну здатність. Релізи позначаються номером збірки, а не семантичною версією. Поточний тег — b10224, опублікований 2 August 2026, і новий тег з’являється майже кожного робочого дня.

Ollama — це програма мовою Go. Фоновий daemon, запущений за допомогою ollama serve, завантажує моделі та обробляє HTTP-запити, а клієнт командного рядка взаємодіє з цим daemon. В основі обох компонентів лежить registry на ollama.com, де зберігаються попередньо запаковані моделі. Ollama використовує семантичні версії, а v0.32.5 було випущено 27 July 2026. ollama pull завантажує GGUF разом із шаблоном prompt і набором параметрів за замовчуванням, а потім зберігає його в /usr/share/ollama/.ollama/models у Linux.

Саме пакування визначає всю різницю. Ollama самостійно визначає квантизацію, шаблон і довжину контексту та дає вам одне ім’я, яке потрібно запам’ятати. llama.cpp нічого не визначає за вас і натомість надає flags.

Вісь 1: керування моделлю та квантуванням

Квантування зменшує розмір кожної ваги з 16 або 32 бітів до 4, 5 або 8 бітів. Завдяки цьому модель із 8 мільярдами параметрів вміщується в оперативній пам’яті звичайного VPS. Схема назв GGUF стає зрозумілою, якщо знати шаблон: Q4_K_M означає 4-бітове K-квантування середнього розміру. Більше число зберігає вищу точність і потребує більше пам’яті.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Це опубліковані розміри файлів у репозиторії bartowski/Meta-Llama-3.1-8B-Instruct-GGUF на Hugging Face, отримані 2 August 2026 і перетворені з байтів у GiB. 6 збірок однієї моделі, причому найменша має розмір 2.96 GiB, а найбільша — 7.95 GiB. Поширений варіант за замовчуванням, Q4_K_M, має розмір 4.58 GiB. На VPS із 4 GiB цей єдиний вибір визначає, чи завантажиться модель взагалі.

У llama.cpp потрібно вказати ім’я файлу, тому цей рядок ви обираєте самостійно.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c — це розмір контексту в токенах, -t — кількість потоків, а -ngl визначає, скільки шарів буде перенесено на GPU (0 на сервері лише з CPU). Нічого не визначається автоматично.

В Ollama квантування входить до тега, який ви завантажуєте, а ollama ls показує, що фактично збережено на диску. Якщо в реєстрі немає потрібної збірки, імпортуйте GGUF самостійно. Створіть Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Потім створіть його та перевірте результат:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Налаштування довжини контексту часто спричиняє проблеми. Ollama вибирає значення за замовчуванням на основі доступної VRAM, а сервер без GPU потрапляє до найменшої категорії: 4096 токенів. Якщо передати документ на 20,000 токенів, зайві токени буде відкинуто ще до того, як модель їх побачить. Тому відповідь може впевнено містити помилки щодо файлу, який модель прочитала лише частково. Збільште це значення за допомогою OLLAMA_CONTEXT_LENGTH для daemon або PARAMETER num_ctx у Modelfile. У llama.cpp також не варто покладатися на значення за замовчуванням. Явно встановіть -c і перевірте, яке значення ви вказали.

Арифметика використання пам’яті, про яку зазвичай не розповідають

Файл моделі — не єдина складова витрат. KV cache (кеш ключів і значень) зберігає один запис для кожного шару та кожного токена контексту. Його розмір збільшується разом із довжиною розмови.

Розглянемо Llama 3.1 8B. Модель має 32 шари, 8 голів key/value і розмірність голови 128. Для кожного токена зберігаються і ключ, і значення по 2 байти кожне у f16, тому 2 x 8 x 128 x 2 = 4096 байт на шар. Для 32 шарів це 128 KiB на токен. Контекст на 4096 токенів потребує 512 MiB, а контекст на 32,768 токенів — 4 GiB.

Отже, модель Q4_K_M 8B із контекстом 4k потребує приблизно 4.58 GiB для ваг, ще близько 0.5 GiB для кешу та додаткову пам’ять для самого runtime. Вона не поміститься в 4 GiB RAM. У 8 GiB RAM вона працюватиме із запасом. Якщо збільшити контекст до 32k на тому самому сервері з 8 GiB RAM, кеш сам використає весь запас пам’яті. Спостерігайте за використанням пам’яті в реальному часі за допомогою free -h, коли модель завантажена, і не покладайтеся на оцінку, яку не перевірили вимірюванням. Якщо ви плануєте модель, значно більшу за 8B, ті самі розрахунки для моделі 27B на VPS лише з CPU показують, що фактично вміщує кожен рівень від 8 до 64 GB.

Ollama збільшує ці вимоги. OLLAMA_NUM_PARALLEL за замовчуванням має значення 1, а потрібний моделі обсяг пам’яті масштабується відповідно до цього числа, помноженого на довжину контексту. Якщо одночасно збільшити обидва значення, daemon непомітно запросить у кілька разів більше RAM, ніж ви очікували. Ці самі розрахунки визначають максимальну кількість одночасних користувачів, оскільки кожен паралельний запит потребує власної частини KV cache. Саме тому сервер, який без проблем працює для одного користувача, зупиняється під навантаженням від п’яти користувачів.

Вісь 2: демон, яким потрібно керувати

Скрипт встановлення Ollama записує unit systemd, створює системного користувача ollama і вмикає сервіс. Керування життєвим циклом працює без написання власних unit-файлів. Конфігурація виконується через systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE має більше значення на CPU VPS, ніж будь-де інде. За замовчуванням моделі зберігаються в пам’яті 5 хвилин, після чого вивантажуються. Наступний запит має знову прочитати весь файл із диска, перш ніж сформувати відповідь, тому повторне завантаження файлу розміром 4.58 GiB може збільшити час відповіді з двох до тридцяти секунд на повільному сховищі. Велике значення keep-alive усуває цю затримку, але постійно займає RAM. Обидва варіанти мають реальну ціну. Виберіть той, який створює менше проблем.

llama.cpp не надає демона, тому unit потрібно створити самостійно як /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Увімкніть його за допомогою sudo systemctl enable --now llama-server. Після цього процес утримує модель протягом усього часу роботи. Під час простою модель не вивантажується, тому не буде несподіваного повторного завантаження, але звільнити пам’ять можна лише після зупинки сервісу. Якщо ви раніше не створювали unit-файли, це той самий підхід, що й у випадку запуску власних сервісів через systemd на VPS.

Вісь 3: API, з яким взаємодіятиме ваш застосунок

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

Ollama прослуховує 127.0.0.1:11434. Його сумісний з OpenAI маршрут — http://localhost:11434/v1/chat/completions, а паралельно доступний власний API за адресою /api/chat. Також документовано маршрут, сумісний з Anthropic.

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

llama-server прослуховує 127.0.0.1:8080 і надає /v1/chat/completions, /v1/completions та /v1/embeddings, а також власну кінцеву точку /completion і вбудований вебінтерфейс. Він також надає службові маршрути, яких немає в Ollama: /health для перевірки готовності, /props для перегляду параметрів завантаженої моделі, /slots для перегляду стану обробки кожним слотом запитів і /metrics у форматі Prometheus. Якщо ви плануєте моніторити цей сервіс, саме ця відмінність, імовірно, буде вирішальною.

Жоден із серверів не вмикає автентифікацію автоматично. За замовчуванням обидва прослуховують loopback, і це обґрунтовано. Підключайтеся до них через SSH-тунель або використовуйте reverse proxy. Ніколи не відкривайте 11434 чи 8080 для доступу з інтернету.

Що насправді може VPS лише з CPU

VPS лише з CPU повільно запускає невеликі моделі. Це чесний підсумок. Важливо знати, де проходить межа. Спочатку виконайте вимірювання, а вже потім будуйте навколо них архітектуру:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

Стовпець pp показує швидкість обробки промпту, а стовпець tg — швидкість генерації токенів. Обидва значення наведено в токенах за секунду. На тарифі зі спільним vCPU модель 8B у форматі Q4_K_M зазвичай показує низькі однозначні значення для tg. Найбільше впливає обробка промпту: весь промпт обробляється до появи першого вихідного токена, тому довгий системний промпт додає затримку до кожного запиту.

На CPU придатна модель від 1B до 4B для класифікації, вилучення даних, коротких підсумків або маршрутизації. Відповіді надходять за кілька секунд, а обсяг пам’яті відповідає звичайному тарифу. На CPU непридатні інтерактивний чат зі швидкістю читання, асистенти для програмування, робота з довгими документами та будь-які сценарії з агентним циклом, який послідовно виконує багато викликів. Цикл із дванадцяти викликів по чотири секунди займає хвилину, перш ніж з’явиться результат. Якщо ви все одно планували використовувати асистента для програмування, як спрямувати агента на модель, яку ви розгорнули самостійно пояснює, які завдання невелика локальна модель справді виконує краще, а які мають залишитися за hosted API.

Якщо показники не відповідають вимогам, є два варіанти. Якщо проблема в паралельності, тобто багато користувачів одночасно звертаються до однієї моделі, змінюється вибір рушія; порівняння Ollama та vLLM для паралельного обслуговування розглядає цей сценарій. Якщо проблема у швидкості, потрібен VPS із підключеним GPU, де -ngl починає мати практичне значення. Перед цим визначте базові показники самого обладнання, оскільки пропускна здатність диска й пам’яті впливає на час завантаження не менше, ніж CPU. Відтворюваний бенчмарк VPS вартий витраченої години.

Встановіть llama.cpp із фіксованою збіркою

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

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Щоб зафіксувати конкретну збірку, натомість завантажте готовий tarball зі сторінки релізів. Build b10224 є поточним тегом станом на 2 August 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

Або зберіть цей самий тег із вихідного коду:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev є задокументованою залежністю для функцій HTTPS. Компіляція триває кілька хвилин і потребує більше RAM, ніж доступно в найменших планах, тому виконайте збірку на потужнішому сервері та скопіюйте бінарні файли, якщо на малому сервері не вистачає ресурсів.

Встановлення Ollama із зафіксованою версією

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Скрипт читає OLLAMA_VERSION, тому можна зафіксувати перевірений реліз замість автоматичного встановлення версії, випущеної сьогодні вранці. v0.32.5 опубліковано 27 July 2026. Також доступний ручний спосіб, якщо ви не хочете передавати скрипт безпосередньо в shell:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

Ручний спосіб не створює unit systemd або користувача сервісу, тому їх потрібно додати самостійно. Повний посібник із запуску Ollama на VPS покроково описує налаштування цього сервісу.

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

Ollama відмовляється завантажувати модель. ollama run повертає рядок такого вигляду:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

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

llama.cpp не завершується з помилкою, а працює надзвичайно повільно. За замовчуванням llama.cpp відображає файл GGUF у пам’ять, тому файл, більший за обсяг RAM, усе одно починає завантажуватися. Потім ядро зчитує ваги з диска та вивантажує їх назад для кожного токена, і генерація сповільнюється до кількох секунд на токен, а диск працює на 100 відсотків. Передайте --no-mmap, щоб примусово виділити пам’ять і отримати негайну помилку замість погіршення продуктивності. Коли ядро втручається, dmesg показує причину:

Out of memory: Killed process 1234 (llama-server)

Файл моделі взагалі не завантажується. GGUF, створений для новішої сім’ї моделей, ніж підтримує ваш рушій, повертає помилку з назвою невідомої архітектури:

error loading model architecture: unknown model architecture: 'qwen3next'

Потрібно оновити рушій, а не вибирати інший файл. Це наслідок фіксації версій, тому номер збірки слід записувати. Потрібно знати, з якої версії ви оновлюєтеся.

API відповідає локально, але не з вашого застосунку. Ollama прив’язується до 127.0.0.1:11434, тому інший хост отримує відмову в підключенні. Встановлюйте OLLAMA_HOST=0.0.0.0:11434 через systemctl edit ollama лише тоді, коли порт захищений firewall або розташований у приватній мережі, оскільки перед API немає автентифікації.

Перша відповідь після паузи дуже повільна. Модель було вивантажено після 5 хвилин бездіяльності, і тепер її знову зчитують із диска. ollama ps, виконана безпосередньо перед запитом, не показує завантажених моделей, що підтверджує це. Збільште OLLAMA_KEEP_ALIVE.

То який варіант слід використовувати?

Запускайте Ollama, якщо хочете, щоб моделі керувалися автоматично, а OpenAI-сумісна кінцева точка працювала без додаткових налаштувань. Це оптимальний варіант за замовчуванням для першого розгортання та для сценаріїв, у яких вибір моделі часто змінюватиметься.

Запускайте llama.cpp безпосередньо, якщо пам’яті настільки мало, що потрібно самостійно вибирати рядок квантизації, якщо для моніторингу потрібні /health, /slots і /metrics або якщо потрібен параметр, якого немає в Ollama. Це правильний вибір для VPS, де модель ледве поміщається в пам’яті, оскільки саме налаштування, завдяки яким вона поміщається, Ollama вибирає замість вас.

Використовувати обидва варіанти — нормально. Ollama підходить для експериментів, а llama.cpp — для єдиної моделі, яку ви розгорнули в production і не хочете змінювати.

FAQ

Чи є Ollama лише оболонкою навколо llama.cpp?

Майже, але оболонка виконує додаткову роботу. У README Ollama llama.cpp указано як бекенд інференсу (перевірено 2 August 2026). Поверх нього Ollama додає реєстр моделей, prompt template, який перетворює повідомлення чату на prompt, набір стандартних параметрів семплювання, daemon із вивантаженням неактивних моделей і HTTP API. Якщо порівнювати кількість токенів за секунду за однакових параметрів, ви порівнюєте один і той самий рушій із самим собою. Фактично ви обираєте між рівнями керування.

Що працює швидше на VPS лише з CPU?

Вони використовують один рушій, тому для того самого файлу моделі, квантизації, розміру контексту й кількості потоків результати будуть близькими. Відмінності, про які повідомляють користувачі, зазвичай спричинені різними стандартними параметрами, найчастіше довжиною контексту та кількістю потоків, а не самим рушієм. Виміряйте це за допомогою llama-bench -m <file> -p 512 -n 128 і порівняйте стовпець tg на власному сервері, перш ніж довіряти опублікованим показникам.

Чи можна використовувати власний файл GGUF з Ollama?

Так. Розмістіть файл на сервері, створіть Modelfile, першим рядком якого буде FROM ./your-model.gguf, додайте потрібні рядки PARAMETER, наприклад num_ctx, а потім виконайте ollama create your-name -f ./Modelfile. ollama ls покаже його поруч з усіма моделями, отриманими з реєстру. Так можна використовувати квантизацію, якої немає в реєстрі.

Скільки RAM потрібно для моделі 8B?

Врахуйте розмір файлу, KV cache і runtime. Збірка Llama 3.1 8B із Q4_K_M займає на диску приблизно 4.58 GiB, а контекст на 4096 токенів додає приблизно 512 MiB кешу, тому 8 GiB RAM буде достатньо, а 4 GiB — ні. Обсяг кешу масштабується разом із контекстом: для тієї самої моделі з контекстом на 32,768 токенів потрібно приблизно 4 GiB лише кешу. В Ollama також врахуйте, що ця вимога масштабується разом із OLLAMA_NUM_PARALLEL.