Ollama чи vLLM: що обрати для LLM-сервера

Ollama і vLLM в одному абзаці

Ollama — це менеджер моделей із вбудованим сервером: він завантажує квантизовані ваги, завантажує їх у пам’ять і відповідає на 127.0.0.1:11434, використовуючи CPU, якщо на сервері немає іншого ресурсу. vLLM — це рушій для високої пропускної здатності: він підтримує GPU завантаженим, одночасно обробляючи багато запитів, і не підходить для машини без GPU. На цьому вибір завершено. Спілкування однієї людини з локальним асистентом — завдання для Ollama. Застосунок, який обслуговує команду, — завдання для vLLM.

Обидва підтримують HTTP API, сумісний з OpenAI, тому клієнтський код можна перенести з одного на інший, змінивши базову URL-адресу. API не є відмінністю. Відмінність полягає в тому, що відбувається, коли надходить другий запит, а перший ще генерує токени.

Що насправді таке Ollama

Ollama — це рівень спрощення роботи. В одній команді встановлення він надає реєстр моделей (ollama pull llama3.1:8b), локальне сховище ваг, чат із prompt, службу systemd і HTTP API. Більшість моделей, які він обслуговує, є файлами GGUF, зазвичай квантизованими до 4 бітів. Тому модель 7B або 8B займає на диску близько 5 GB, а не 16 GB. Квантизація зменшує обсяг пам’яті, потрібний для inference на CPU. На Mac з Apple Silicon Ollama також може запускати моделі на основі safetensors через рушій MLX. Починаючи з v0.40.0 (September 2026), підтримувані архітектури автоматично запускаються через MLX.

Його GGUF runner побудований на llama.cpp — бібліотеці inference мовою C++, яка зробила квантизацію GGUF практичною на звичайному обладнанні. Станом на October 2026 Ollama підтримує два рушії: llama.cpp і MLX. Linux builds також підтримують MLX inference з CUDA. У development guide цей backend вмикається через cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13. Потрібні CUDA 13+ і cuDNN 9+. Тому порівняння Ollama з llama.cpp здебільшого є порівнянням рівня зручності з компонентом, який цей рівень обгортає.

Цільова схема розрахована на одного користувача. Станом на October 2026 значення за замовчуванням для OLLAMA_NUM_PARALLEL дорівнює 1. Це означає, що одна модель обробляє один запит за раз, а всі інші запити очікують у черзі, яка за замовчуванням містить 512 елементів (OLLAMA_MAX_QUEUE). Ви можете збільшити параметр parallel. У наступному розділі пояснено, яких ресурсів це потребує. Якщо ви ще не запускали Ollama, почніть зі статті розгортання Ollama на VPS і блокування порту 11434, оскільки локальний API не потребує автентифікації.

Що насправді являє собою vLLM

vLLM — це лише inference server. Він не керує бібліотекою моделей, не надає vllm chat client для запущеного сервера і не завантажує модель під час отримання запиту. Під час запуску ви вказуєте repository на Hugging Face, після чого vLLM завантажує цю модель і обслуговує запити, доки ви не зупините процес.

Перевага такого вузького призначення — висока пропускна здатність. Її забезпечують два механізми. PagedAttention зберігає KV cache (key-value cache — стан attention для кожного токена, який модель зберігає для кожного активного запиту) у блоках фіксованого розміру, подібно до того, як операційна система розподіляє пам’ять сторінками. Запиту більше не потрібне одне велике безперервне резервування пам’яті, розраховане на найгірший випадок. Тому пам’ять, яка раніше залишалася зарезервованою та невикористаною, стає доступною для більшої кількості одночасних запитів. Continuous batching дає змогу новому запиту приєднатися до поточного batch на наступному кроці декодування, не очікуючи завершення поточного batch. Після завершення sequence одразу залишає batch, а його слот заповнюється знову.

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

Безперервна пакетна обробка визначає все

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

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

vLLM декодує всі п’ять послідовностей за один forward pass. Генерація одного токена для п’яти послідовностей коштує лише трохи дорожче, ніж для однієї, оскільки основні витрати пов’язані з читанням ваг моделі з пам’яті, а це читання спільне для всього batch. Цей самий факт, пов’язаний із пропускною здатністю пам’яті, пояснює повільну inference на CPU: ви платите за переміщення ваг, а не за арифметичні операції.

Це частково можна налаштувати через OLLAMA_NUM_PARALLEL=4. Ціна — споживання пам’яті. Кожен паралельний слот потребує власного KV cache, а Ollama множить виділений обсяг контексту, а не ділить його: у FAQ зазначено, що потрібний обсяг RAM зростає у OLLAMA_NUM_PARALLEL разів на OLLAMA_CONTEXT_LENGTH. Тому чотири паралельні запити до моделі, налаштованої на 8192 токенів, зберігають по 8192 токенів кожен, але сервер має утримувати cache загальним обсягом 32768 токенів. Саме значення 8192 також є налаштуванням, а не фіксованою вимогою, тому збільшення num_ctx і розрахунок потрібного для цього обсягу RAM визначають, чи помістяться взагалі чотири слоти. Paged cache у vLLM не дає змоги заздалегідь резервувати повне вікно для кожного слоту: блоки виділяються запиту в міру його фактичного зростання. У будь-якому разі гранична кількість користувачів, яких один сервер може обслуговувати одночасно, залежить від розміру KV cache, вартості prefill і глибини черги. Саме це пояснює, чому сервер, якого вистачало для одного користувача, різко сповільнюється за п’ятьох.

Встановлення та запуск Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Скрипт встановлення створює системного користувача ollama, встановлює бінарний файл і реєструє ollama.service, прив’язаний до 127.0.0.1:11434. Рядок eval rate, виведений командою --verbose, показує фактичну кількість токенів за секунду на цьому сервері. Орієнтуйтеся на це значення, а не на опубліковані показники. Одне вимірювання для одного запиту є лише початковою оцінкою, а не показником пропускної здатності. Тому вимірювання кількості токенів за секунду за різної кількості паралельних запитів покаже, чи витримує сервер очікуване навантаження і чи вигідніше орендувати GPU, ніж платити за кожен токен.

Щоб збільшити кількість паралельних запитів, використайте drop-in для systemd. Під час оновлення ця зміна не буде перезаписана:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps показує завантажену конфігурацію, а значення в стовпці PROCESSOR відображає фактичний стан. 100% CPU означає, що GPU не використовується. Це чесне пояснення більшості випадків, коли Ollama працює повільно. Рядок OLLAMA_KEEP_ALIVE=30m у цьому drop-in так само важливий на сервері без активних запитів. За замовчуванням модель вивантажується після п’яти хвилин без запитів. Збереження моделі в пам’яті між запитами запобігає повторному повному завантаженню моделі для першого запиту після паузи тривалістю до пів години. Якщо паузи тривають довше, задайте більше значення.

Встановлення та запуск моделі через vLLM

GPU-збірки vLLM потребують Linux. macOS на Apple Silicon підтримує лише CPU з попередньо зібраним wheel у релізі 0.32.0. GPU-прискорення на таких Mac забезпечує vLLM-Metal — окремий плагін, який підтримує спільнота та який створено на основі MLX. Поточний реліз Python (0.32.0, October 2026) підтримує версії від 3.11 до 3.14. У посібнику зі встановлення наведено той самий діапазон. Підтримку Python 3.10 вилучили у версії 0.32.0, тому Python 3.12, який використовується нижче, є безпечним вибором. Встановіть vLLM в окреме virtual environment, оскільки пакет встановлює конкретну збірку PyTorch:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels

Останній рядок наведено в посібнику зі встановлення vLLM для NVIDIA станом на October 2026. Він встановлює попередньо скомпільовані kernels FlashInfer. Без них vLLM завантажує та компілює kernels під час запуску. За даними посібника, на GPU Hopper і новіших поколінь це може додати кілька хвилин. Виконуйте цю команду повторно після кожного оновлення vLLM. FlashInfer відмовляється імпортуватися, якщо kernels не відповідають поточній версії.

Далі запустіть модель. Її ім’я — це repository id у Hugging Face, а не короткий tag:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Перший запуск відбувається повільно. Спочатку vLLM завантажує weights, а потім профілює GPU, щоб визначити, скільки блоків KV cache поміститься. Сервіс прослуховує порт 8000. Перевірте його до написання клієнтського коду:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Якщо на сервері вже встановлено Docker, офіційний image усуває потребу вручну налаштовувати CUDA dependencies:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host надає контейнеру доступ до shared memory хоста. Інший варіант — збільшити --shm-size. PyTorch передає tensors між процесами через shared memory, особливо під час tensor-parallel inference.

У production найважливішими є такі flags: --max-model-len — context window, за який ви готові платити; --gpu-memory-utilization — частка GPU memory, яку vLLM може зайняти (станом на October 2026 значення за замовчуванням — 0.92); --tensor-parallel-size — для розподілу однієї моделі між кількома GPU; і --api-key.

vLLM використовує один прапорець для автентифікації, а локальний API Ollama її не підтримує

vLLM перевіряє bearer token, якщо його вказати:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

Те саме значення можна передати через змінну середовища VLLM_API_KEY. Запит до /v1 без цього token отримує HTTP 401. Однак цей ключ не захищає весь сервер. Посібник з безпеки vLLM і код автентифікації у вихідному коді версії 0.32.0 застосовують його лише до endpoint під префіксами шляхів /v1, /v2, /inference і /cohere. Текст довідки --api-key на сторінці vllm serve містить лише перші три префікси, але код перевіряє всі чотири. І посібник, і текст довідки зазначають, що інші endpoint, зокрема /invocations, який надає той самий inference, що й /v1, не захищені автентифікацією. Цього достатньо, щоб не публікувати порт 8000 у публічному інтерфейсі. У посібнику з безпеки vLLM також зазначено, що rate limiting потрібно реалізувати на reverse proxy перед ним. Крім того, token, переданий через звичайний HTTP, можна перехопити під час передавання. Водночас цей прапорець означає, що сервер розпізнає поняття клієнта.

Локальний API Ollama не потребує автентифікації. Для cloud models, публікації моделей і приватного завантаження моделей потрібен sign-in; прямий доступ до API ollama.com потребує API key. Будь-який процес, який має доступ до 11434, може запускати, завантажувати або видаляти моделі. Залиште API доступним лише через loopback і підключайтеся до нього через WireGuard VPN, розгорнуту власноруч, або через reverse proxy з автентифікацією, який завершує TLS (transport layer security).

Обладнання: що потрібно кожному варіанту

Ollama працює на CPU. Квантизована до 4 бітів модель потребує приблизно пів гігабайта RAM на кожен мільярд параметрів, а також близько 1 гігабайта для службових витрат під час роботи й додаткову пам’ять для контексту. Тому для моделі 3B потрібно близько 4 GB вільної пам’яті, а для моделі 8B — близько 8 GB. Швидкість на спільному vCPU становить від однозначного до низького двозначного числа токенів за секунду. Це обмеження пропускної здатності пам’яті, а не помилка конфігурації, тому жоден flag її не усуне. Щоб побачити ці розрахунки для конкретного релізу, а не покладатися на приблизне правило, у матеріалі про запуск Nemotron 3.5 Lightning на VPS зафіксовано точний tag для завантаження, обсяг RAM після завантаження моделі та те, чи достатньо швидка робота лише на CPU для практичного використання.

vLLM розрахований на GPU. Типовий режим використовує неквантизовані ваги з точністю 16 бітів. Це приблизно 2 GB на кожен мільярд параметрів: моделі 8B потрібно близько 16 GB відеопам’яті лише для ваг, ще до врахування KV cache, який забезпечує паралельність запитів, заради якої ви встановлювали vLLM. На карті з 24 GB залишається достатньо місця для cache. На карті з 16 GB — ні. Тому потрібно або вибрати меншу модель, або передати --quantization (із квантизованим checkpoint чи для квантизації ваг повної точності під час завантаження), або перемістити частину ваг у системну RAM за допомогою --cpu-offload-gb. Точність ваг при цьому зберігається, але робота сповільнюється, оскільки під час кожного forward pass ці ваги передаються на GPU. Існує також backend для CPU з окремими wheels, але тоді втрачається сенс використання vLLM.

Отже, питання про обладнання здебільшого визначає вибір програмного забезпечення. Якщо GPU немає, використовуйте Ollama. Якщо орендований GPU завантажений лише на 5 відсотків, оскільки запити обробляються послідовно, використовуйте vLLM.

Що вибрати для вашого робочого навантаження

• Одна людина, CPU VPS, підготовка чернеток і стислих викладів: Ollama. Швидкість прийнятна, а простішого варіанта немає.
• Асистент для написання коду або MCP-сервер, який з’єднує ваші інструменти з локальною моделлю, до якого звертаєтеся лише ви: Ollama. Фактичне робоче навантаження — один одночасний запит.
• Порівняння п’яти моделей цього тижня: Ollama. Завантаження та видалення моделей із тегами — саме те, для чого він підходить, тоді як vLLM потребує перезапуску процесу для кожної моделі.
• Внутрішній застосунок, чат-продукт або retrieval pipeline із реальними користувачами: vLLM. Саме тут пакетна обробка виправдовує витрати на GPU.
• Пакетне завдання, яке за ніч оцінює сто тисяч документів: vLLM із високим --max-num-seqs. Важливий лише показник пропускної здатності, а затримка обробки окремого документа не має значення.
• Платформа агентів, на якій кілька self-hosted AI-агентів одночасно звертаються до моделі: vLLM, оскільки трафік від агентів має нерівномірний характер і за своєю природою є паралельним.

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

vLLM відмовляється запускатися через помилку KV cache. У повідомленні вказано обидва числа:

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

Модель оголошує вікно контексту, яке перевищує обсяг пам’яті, що залишився після завантаження ваг. Зменште його за допомогою --max-model-len 8192 або збільште --gpu-memory-utilization, якщо інші процеси не використовують GPU.

Ollama виводить Killed під час генерації. Linux OOM killer зупинив процес, оскільки моделі потрібно більше RAM, ніж доступно на сервері. Підтвердьте це за допомогою sudo dmesg | grep -i oom. Потрібно використати меншу модель або модель із сильнішим квантуванням, а не змінювати параметри.

Ollama добре відповідає без навантаження, але зависає під навантаженням. Помилки ніде не з’являються. Запити просто обробляються довше зі збільшенням кількості клієнтів, оскільки OLLAMA_NUM_PARALLEL=1 серіалізує їх. Довгі відповіді погіршують ситуацію: один клієнт утримує єдиний слот, доки модель не вирішить зупинитися, і блокує всі наступні запити. Тому обмеження відповіді за допомогою num_predict встановлює максимальний час, протягом якого один запит може утримувати сервер. Збільшіть параметр паралельності та врахуйте додатковий обсяг RAM для контексту кожного слоту або перенесіть навантаження на vLLM.

vLLM повертає 401 для кожного виклику /v1. Ви запустили його з --api-key, але клієнт не надсилає заголовок Authorization. Більшість клієнтських бібліотек OpenAI надсилають значення, яке ви передаєте як ключ, тому вкажіть ключ у клієнті, а не вилучайте цей прапорець.

vLLM повідомляє, що модель не знайдена. Ollama завантажує моделі за потреби, а vLLM — ні. Поле model у тілі запиту має збігатися з ідентифікатором репозиторію, з яким ви запустили модель, або зі значенням --served-model-name, якщо ви його вказали. Перевірте точний рядок за допомогою curl http://localhost:8000/v1/models.

Запустити обидва — цілком обґрунтований варіант

Вони не взаємовиключні. Поширена схема передбачає vLLM на GPU-інстансі для обслуговування застосунку, а Ollama — на звичайному VPS поруч для локальних скриптів, завдань cron і тестування нових релізів моделей. Обидві кінцеві точки сумісні з OpenAI API, тому достатньо однієї клієнтської бібліотеки та зміни базової URL-адреси. Тут контроль витрат важливіший за вибір рушія: простійний GPU тарифікується так само, як і завантажений, а контрольоване планування витрат на агентів та інференс — це окрема дисципліна, не пов’язана з вибором сервера.

FAQ

Чи швидший vLLM за Ollama?

Для одного запиту на тому самому GPU різниця невелика, оскільки обидва виконують однакові обчислення. Для великої кількості одночасних запитів vLLM значно швидший, оскільки continuous batching декодує кожну активну послідовність за один forward pass, тоді як Ollama за замовчуванням обробляє їх одну за одною. На машині лише з CPU обидва мають підтримувані шляхи інференсу, а vLLM використовує окремі CPU wheels.

Чи може vLLM працювати без GPU?

Так, через свій CPU backend. Стандартні wheels призначені для NVIDIA або AMD GPU, а причина існування vLLM — утримувати accelerator завантаженим пакетними запитами — на CPU зникає. CPU backend доступний з окремими wheels для x86 і Arm. Для реального CPU inference використовуйте Ollama або llama.cpp безпосередньо.

У чому різниця між Ollama і llama.cpp?

llama.cpp — це inference library, а GGUF — її quantized weight format. Ollama використовує її для GGUF inference і додає model registry, tagged downloads, model management та systemd unit. Ollama також постачається з MLX engine, який запускає моделі на основі safetensors на Apple Silicon, і підтримує CUDA builds у Linux, тому внутрішня реалізація цих рішень не завжди однакова.

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

За 16-bit precision самі weights займають приблизно 16 GB, тобто близько 2 GB на кожен мільярд параметрів, а додатково потрібен простір для KV cache. Карта на 24 GB має достатній запас. Для карти на 16 GB потрібна quantized model, менша модель або --cpu-offload-gb, щоб перемістити частину weights у system RAM ціною зниження швидкості. vLLM використовує частку пам’яті карти, задану --gpu-memory-utilization; станом на October 2026 значення за замовчуванням становить 0.92.

Чи потрібно змінювати код застосунку, щоб перейти між ними?

Зазвичай потрібно змінити лише base URL, API key і назву моделі. Ollama надає свій OpenAI-compatible surface за адресою http://127.0.0.1:11434/v1 і ігнорує key, тоді як vLLM надає http://localhost:8000/v1 і перевіряє key у своїх маршрутах /v1, якщо його задано. Назви моделей мають різний формат: llama3.1:8b для Ollama і повний repository id, наприклад Qwen/Qwen2.5-1.5B-Instruct, для vLLM.