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

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

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

Безперервне пакетування — це ключова відмінність

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

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

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

Можна налаштувати OLLAMA_NUM_PARALLEL=4 і отримати частину цієї переваги. Ціна цього рішення — пам’ять. Кожен паралельний слот потребує власного KV-кешу, а Ollama розподіляє вікно контексту між слотами. Тому чотири паралельні запити до моделі, налаштованої на 8192 токенів, залишають кожному запиту контекст обсягом 2048 токенів. Пейджований кеш vLLM усуває цей компроміс, оскільки блоки виділяються запиту в міру фактичного збільшення його розміру.

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

Щоб підвищити рівень паралелізму, використовуйте 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.

Інсталяція та запуск сервера за допомогою vLLM

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

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

Потім запустіть модель. Назва має бути ідентифікатором репозиторію Hugging Face, а не короткою міткою:

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

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

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 передає тензори між процесами через спільну пам’ять, а стандартний обсяг спільної пам’яті Docker замалий для виведення з використанням tensor parallelism.

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

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

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

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

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

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

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

Ollama працює на CPU. Для квантизованої 4-бітної моделі потрібно приблизно пів гігабайта RAM на кожен мільярд параметрів, а також близько гігабайта накладних витрат середовища виконання і додатковий обсяг для контексту. Тому для моделі 3B потрібно приблизно 4 GB вільної пам’яті, а для моделі 8B — приблизно 8 GB. Швидкість на спільному vCPU становить від однозначної до низької двозначної кількості токенів за секунду. Це обмеження пропускної здатності пам’яті, а не помилка конфігурації. Жоден прапорець його не усуне.

vLLM розрахований на GPU. Стандартний режим обслуговує неквантизовані ваги з точністю 16 біт. Це приблизно 2 GB на кожен мільярд параметрів. Для моделі 8B потрібно близько 16 GB відеопам’яті лише для ваг, без KV-кешу, заради паралельної обробки запитів якого ви встановлюєте vLLM. На карті з 24 GB залишається достатньо кешу для практичної роботи. На карті з 16 GB цього недостатньо. Тому потрібно вибрати меншу модель або передати --quantization разом із квантизованою контрольною точкою. Бекенд для CPU існує, але стандартні wheels для нього не зібрані. Крім того, він усуває саму причину використання vLLM.

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

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

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

Причини збоїв і повідомлення, які ви побачите

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

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, якщо картку більше ніщо не використовує. Збільшення використання пам’яті понад приблизно 0.95 зазвичай замінює цю помилку запуску на аварійне завершення через нестачу пам’яті CUDA під навантаженням. Це гірший варіант.

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

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

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

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

Запуск обох є цілком обґрунтованим рішенням

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

FAQ

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

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

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

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

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

llama.cpp — це бібліотека інференсу, а GGUF — її формат квантизованих ваг. Runner Ollama побудований на ній і додає компоненти, які llama.cpp залишає на ваш розсуд: реєстр моделей, автоматичне завантаження, постійно запущений сервер, модуль systemd і сумісну з OpenAI кінцеву точку. Ollama додала власний рушій для деяких новіших сімейств моделей, тому тепер ці продукти не є повністю ідентичними на внутрішньому рівні.

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

За точності 16 біт самі ваги займають приблизно 16 GB, тобто близько 2 GB на мільярд параметрів, а для KV cache потрібен додатковий обсяг. Відеокарта на 24 GB працює без проблем. Для відеокарти на 16 GB потрібен квантизований checkpoint або менша модель. vLLM використовує частку обсягу відеопам’яті, задану параметром --gpu-memory-utilization, який станом на July 2026 за замовчуванням має значення 0.92.

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

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