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. Саме квантизація робить інференс на CPU взагалі можливим.

Її runner побудований на llama.cpp — бібліотеці інференсу на C++, яка зробила квантизацію GGUF практичною на звичайному обладнанні. Згодом Ollama додала власний engine для деяких новіших сімейств моделей, але llama.cpp і далі залишається основою більшості моделей, які вона обслуговує. Тому, коли люди порівнюють Ollama з llama.cpp, здебільшого вони порівнюють рівень зручності з компонентом, який він обгортає.

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

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

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

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

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

Безперервне батчування визначає всю різницю

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

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

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

Можна встановити OLLAMA_NUM_PARALLEL=4 і отримати частину цієї переваги. Ціна — використання пам’яті. Кожен паралельний слот потребує власного KV cache, а Ollama розподіляє контекстне вікно між слотами. Тому чотири паралельні запити до моделі, налаштованої на 8192 токенів, залишають для кожного запиту контекст обсягом 2048 токенів. Саме значення 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

vLLM потребує Linux і Python версії від 3.10 до 3.13. Встановіть його в окреме virtual environment, оскільки пакет встановлює конкретну збірку PyTorch:

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

Потім запустіть model server. Назва — це ідентифікатор репозиторію Hugging Face, а не короткий тег:

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

Перший запуск повільний, оскільки vLLM завантажує ваги, а потім профілює 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 dependency:

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 обов’язковий, а не декоративний: PyTorch передає tensors між процесами через shared memory, а стандартний обсяг shared memory у Docker замалий для tensor-parallel inference.

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

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

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

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

Це саме значення можна передати через змінну середовища VLLM_API_KEY. Запит без цього token отримує відповідь HTTP 401. Однак це не означає, що порт 8000 можна відкривати на публічному інтерфейсі: у vLLM немає обмеження частоти запитів, а token у незашифрованому HTTP-з’єднанні можна прочитати під час передавання. Водночас сервер має поняття про клієнта, який виконує запит.

В Ollama такої функції немає. Немає ключа, входу чи списку дозволених клієнтів. Будь-який процес, який має доступ до 11434, може запускати, завантажувати або видаляти моделі. Залиште Ollama доступною лише через loopback і підключайтеся до неї через власну WireGuard VPN, або використовуйте reverse proxy з автентифікацією, який завершує TLS (захист транспортного рівня).

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

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 для кешу залишається достатньо місця. На карті 16 GB цього недостатньо, тому потрібно або вибрати меншу модель, або передати --quantization разом із квантизованим checkpoint. 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: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

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

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

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

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

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

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

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

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

llama.cpp — це inference library, а GGUF — її формат quantized weights. Runner Ollama побудований на ній і додає те, що llama.cpp залишає користувачеві: model registry, автоматичне завантаження, resident server, systemd unit і OpenAI-compatible endpoint. Ollama додала власний engine для деяких нових model families, тому внутрішня реалізація цих систем більше не є ідентичною.

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

За 16-bit precision самі weights займають приблизно 16 GB, тобто близько 2 GB на кожен мільярд параметрів, а KV cache потребує додаткового місця. Карта на 24 GB забезпечує достатній запас. Для карти на 16 GB потрібен quantized checkpoint або менша модель. vLLM використовує частку доступної memory, задану параметром --gpu-memory-utilization, який станом на July 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, якщо його задано. Назви моделей мають різний формат: llama3.1:8b для Ollama і повний repository id, наприклад Qwen/Qwen2.5-1.5B-Instruct, для vLLM.