Ollama чи llama.cpp для VPS без GPU

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

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

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

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

llama.cpp — це реалізація інференсу transformer мовами 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. Ці файли зберігаються на root-диску й можуть займати кілька гігабайт кожен, тому на VPS із root-томом обсягом 25 GB варто заздалегідь знати що залишає після себе pull і як перенести каталог моделей в інше місце, перш ніж третє завантаження заповнить диск.

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

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

Квантизація зменшує розмір кожної ваги з 16 або 32 бітів до 4, 5 або 8 бітів. Завдяки цьому модель із 8 мільярдами параметрів вміщується в RAM звичайного 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 цей вибір визначає, чи завантажиться модель взагалі. Розмір — лише половина рішення, оскільки доступний за ресурсами рядок не обов’язково є найкращим для використання. Саме порівняння вартості Q4, Q8 і fp16 для якості відповідей показує, чи дають додаткові гігабайти помітний результат.

У 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 показує, що фактично збережено на диску. Якщо registry не містить потрібної збірки, імпортуйте 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. Якщо більший контекст потрібен лише для одного завдання, num_ctx можна встановити для окремого запиту, а не для всього сервера, щоб додатковий cache не використовувався для інших завдань daemon. У llama.cpp також не варто покладатися на значення за замовчуванням. Явно встановіть -c і перевірте, яке саме значення задано.

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

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

Розглянемо Llama 3.1 8B. Модель має 32 шари, 8 голів ключів і значень та розмірність голови 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 вона працюватиме із запасом. Якщо збільшити контекст до 32k на тому самому сервері з 8 GiB, кеш сам використає весь запас пам’яті. Під час завантаження моделі спостерігайте за використанням пам’яті в реальному часі за допомогою free -h і не покладайтеся на оцінку, яку не перевірили вимірюванням. Якщо ви плануєте модель, значно більшу за 8B, та сама арифметика для моделі 27B на VPS лише з CPU показує, який обсяг даних фактично вміщує кожен рівень від 8 до 64 GB.

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

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

Скрипт встановлення Ollama записує unit systemd, створює системного користувача ollama і вмикає сервіс. Ви отримуєте керування життєвим циклом без ручного написання конфігурації. Налаштування виконується через 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. Обидва варіанти мають реальну ціну. Оберіть той, наслідки якого для вас менш критичні. Якщо ви вирішите, що модель має просто залишатися в пам’яті, налаштування keep_alive, щоб модель переживала періоди бездіяльності та перезавантаження, займає кілька рядків і позбавляє потреби вручну прогрівати модель щоразу після перезапуску сервера.

llama.cpp не надає daemon, тому 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 Chat, тому більшість клієнтських бібліотек працює з будь-яким із них після зміни лише базової 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 і вбудований web UI. Він також надає службові маршрути, яких немає в Ollama: /health для readiness probe, /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 наведено швидкість обробки prompt, а у стовпці tg — швидкість генерації токенів. Обидва показники вимірюються в токенах за секунду. На плані зі shared vCPU модель 8B у форматі Q4_K_M зазвичай показує низькі однозначні значення для tg. Найбільше впливає обробка prompt: весь prompt обробляється до появи першого вихідного токена, тому довгий system prompt додає затримку до кожного запиту. Довжина відповіді — це частина витрат, якою можна керувати. За швидкості три токени на секунду модель, яка генерує 600 токенів, займає VPS протягом трьох хвилин. Тому обмеження виходу через num_predict — найдешевший спосіб не допустити, щоб одна надто довга відповідь спричинила timeout.

Придатне для CPU: модель від 1B до 4B для класифікації, вилучення даних, коротких резюме або маршрутизації. Відповіді надходять за кілька секунд, а обсяг пам’яті відповідає типовому плану. Практичний приклад для такого розміру замість діапазону наведено в матеріалі Nemotron 3.5 Lightning, завантажена та виміряна на VPS. Там вказано точний tag, фактичний обсяг RAM і швидкість роботи без GPU. Непридатне для CPU: інтерактивний чат зі швидкістю читання, coding assistants, робота з довгими документами або будь-які сценарії з agent loop, який послідовно виконує багато викликів. Цикл із дванадцяти викликів по чотири секунди займає хвилину, перш ніж з’явиться результат. Якщо планувалося використовувати coding assistant, матеріал про підключення агента до моделі, яку ви розміщуєте самостійно пояснює, які завдання невелика локальна модель справді виконує краще, а які потрібно залишити для hosted API.

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

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

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

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

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

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 через pipe:

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 використовує memory mapping для GGUF, тому файл, більший за обсяг RAM, усе одно починає завантажуватися. Потім kernel підвантажує ваги з диска та вивантажує їх назад для кожного токена, а генерація сповільнюється до кількох секунд на токен, тоді як диск працює на 100 відсотків. Передайте --no-mmap, щоб примусово виділити пам’ять. Тоді процес одразу завершиться з помилкою, а не перейде в повільний режим. Якщо kernel втручається, dmesg показує причину:

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

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

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

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

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

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

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

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

Запускайте 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, набір стандартних параметрів sampling, daemon із вивантаженням моделей у разі простою та HTTP API. Коли ви порівнюєте кількість токенів за секунду за однакових налаштувань, ви порівнюєте той самий рушій із самим собою. Насправді ви обираєте між різними management layer.

Що швидше на VPS лише з CPU?

Вони використовують один рушій, тому за однакового файлу моделі, quantisation, розміру контексту та кількості потоків результати будуть близькими. Відмінності, про які повідомляють користувачі, зазвичай спричинені різними стандартними параметрами, найчастіше довжиною контексту та кількістю потоків, а не рушієм. Виміряйте це за допомогою 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 покаже цю модель поруч з усіма моделями, завантаженими з реєстру. Так можна використовувати quantisation, якої немає в реєстрі.

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

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