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

У 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. Для кожного токена зберігаються і key, і value по 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 для кешу та додатково пам’ять для самого середовища виконання. Така конфігурація не вміщується в 4 GiB RAM. У 8 GiB вона працює із запасом пам’яті. Якщо збільшити контекст до 32k на тому самому комп’ютері з 8 GiB, кеш сам використає весь запас. Спостерігайте за цим у реальному часі за допомогою free -h під час завантаження моделі та не покладайтеся на оцінку, яку не перевірили вимірюванням.

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

Вісь 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. Обидва варіанти мають реальну вартість. Виберіть той, який створює менше проблем.

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. Після цього процес утримує модель протягом усього часу роботи. Під час простою модель не вивантажується. Це усуває несподіване повторне завантаження, але звільнити пам’ять можна лише після зупинки сервісу. Якщо ви вперше пишете units, це той самий підхід, що й запуск власних сервісів через 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 для 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 — швидкість генерації токенів. Обидва значення наведено в токенах за секунду. На плані зі спільним vCPU модель 8B у форматі Q4_K_M зазвичай забезпечує лише кілька одиниць у tg. Найбільше впливає оброблення prompt: увесь prompt обробляється до появи першого вихідного токена, тому довгий system prompt додає затримку до кожного запиту.

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

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

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

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