Ollama против vLLM: что выгоднее и когда

MAATRIX

Оба инструмента запускают одну и ту же открытую модель и отдают ответ по OpenAI-совместимому API — и ведут себя противоположно, как только запросов становится больше одного. Ollama выигрывает у одиночного пользователя и умеет работать без видеокарты; vLLM разносит его в разы на потоке, но требует GPU, в который модель влезает целиком. Ниже — замеры на одном железе, расчёт KV-кэша, точные тексты ошибок и правило выбора.

Короткий ответ: считайте не токены, а одновременные запросы

Вопрос «ollama или vllm» почти всегда сводится к одному числу — сколько запросов приходит в модель одновременно в пике. Не в сутки, не в час, а именно параллельно.

• 1–3 одновременных запроса — берите Ollama. На таком профиле vLLM не даёт выигрыша, а часто даже медленнее, и вы платите за сложность впустую.
• 4–8 запросов — зона паритета. Решает то, сколько разных моделей вам нужно держать и есть ли вообще GPU.
• От 10 и выше, постоянно — vLLM. Разрыв начинается с двукратного и на 32–64 параллельных доходит до порядка.

Второй вопрос, отсекающий половину случаев: есть ли видеокарта. Ollama честно работает на CPU — медленно, но работает. CPU-бэкенд vLLM существует для разработки: единицы токенов в секунду и сборка из исходников. На VPS без GPU выбора нет — есть Ollama.

Третий вопрос: одна модель или несколько. Один процесс vLLM обслуживает ровно одну модель и держит её в VRAM постоянно, Ollama выгружает и подгружает по требованию. Чат на 8B, эмбеддинги и мелкая модель для классификации на одной карте — это сценарий Ollama даже при высокой нагрузке.

Что под капотом: GGUF и llama.cpp против PagedAttention

Ollama — обвязка вокруг llama.cpp с реестром моделей и HTTP-сервером. Модели хранятся в GGUF, по умолчанию в квантовании Q4_K_M, и главное свойство формата — модель может лежать в VRAM частично, а остальные слои считает CPU. Отсюда и универсальность, и её цена.

vLLM устроен иначе. Это PyTorch-движок с двумя ключевыми механизмами. PagedAttention хранит KV-кэш не одним непрерывным куском на запрос, а страницами по 16 токенов — как виртуальная память в ОС. Кэш не фрагментируется, память не резервируется под максимальную длину заранее, и в ту же карту помещается кратно больше одновременных диалогов. Continuous batching подсаживает новый запрос в текущий батч на любом шаге генерации: пришедшему не надо ждать, пока договорят те, кто начал раньше.

Параллелизм в Ollama устроен через статические слоты. OLLAMA_NUM_PARALLEL задаёт их число, и вот подвох: KV-кэш выделяется на каждый слот отдельно и резервируется целиком. При num_ctx 8192 и OLLAMA_NUM_PARALLEL=4 рантайм запрашивает кэш на 32 768 токенов — независимо от того, пользуется ли кто-то слотами прямо сейчас. Поставили 8 «на всякий случай» — получили нехватку памяти на ровном месте.

Ещё одно следствие архитектуры: у vLLM префиксный кэш общий, и одинаковый системный промпт на 1500 токенов считается один раз на всех. В Ollama кэш промпта живёт внутри слота и теряется, когда слот занимает другой диалог. Для бота с длинным системным промптом это разница в разы на времени до первого токена.

Замеры: что происходит с ростом параллелизма

Стенд: одна RTX 4090 24 ГБ, Ubuntu 24.04, Llama 3.1 8B Instruct. Ollama — Q4_K_M (веса 4,7 ГБ), vLLM — FP16 (16 ГБ). Промпт 512 токенов, генерация 256, по 200 запросов на точку. Нагрузку удобно давать штатным бенчмарком vLLM — он бьёт по любому OpenAI-совместимому эндпоинту:

vllm bench serve \
  --backend openai-chat --endpoint /v1/chat/completions \
  --base-url http://127.0.0.1:8000 \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --dataset-name random --random-input-len 512 --random-output-len 256 \
  --max-concurrency 32 --num-prompts 200

Для Ollama меняется только --base-url на http://127.0.0.1:11434 — OpenAI-совместимый эндпоинт у него по тому же пути.

Ваши числа будут другими — они зависят от карты, длины промпта и квантования. Важна форма кривой: у Ollama пропускная растёт до числа слотов и упирается в полку, а лишние запросы копятся в очереди, раздувая время до первого токена. У vLLM она растёт почти линейно, пока не кончится KV-кэш.

Обратите внимание на первую строку. При одном запросе Ollama быстрее, и это не ошибка замера: генерация токена упирается в пропускную способность памяти, то есть в объём весов, который читается на каждом шаге. 4,7 ГБ против 16 ГБ — вот и вся разница. Если у вас один пользователь, переход на vLLM в FP16 сделает хуже. Что ещё влияет на скорость, разобрано в статье Ollama медленно генерирует токены.

Память: почему vLLM просит больше и как посчитать KV-кэш

Самая частая причина, по которой vLLM не стартует, — не хватило памяти под KV-кэш. Считается он точно:

байт на токен = 2 (K и V) × число слоёв × число KV-голов × размер головы × байт на элемент

Для Llama 3.1 8B: 2 × 32 × 8 × 128 × 2 = 131 072 байта, то есть 128 КиБ на каждый токен контекста. Бюджет карты на 24 ГБ: при --gpu-memory-utilization 0.90 движку доступно ~21,6 ГБ, минус 16 ГБ весов и ~1,5 ГБ на активации и графы — на кэш остаётся около 4 ГБ, это ~32 000 токенов, или 40 диалогов по 800 токенов. А модель по паспорту умеет 131 072 токена. Отсюда ошибка первого запуска:

ValueError: The model's max seq len (131072) is larger than the maximum number of
tokens that can be stored in KV cache (32496). Try increasing `gpu_memory_utilization`
or decreasing `max_model_len` when initializing the engine.

Лечится не увеличением --gpu-memory-utilization (там уже почти всё), а честным --max-model-len 8192: 128 тысяч токенов на каждый диалог вам не нужны. Второй рычаг — --kv-cache-dtype fp8, он вдвое режет вес кэша. Третий и самый действенный — 4-битный AWQ вместо FP16: веса ужимаются до ~5,7 ГБ, под кэш освобождается около 14 ГБ, то есть больше 110 000 токенов.

На старых картах ждёт отдельный сюрприз:

ValueError: Bfloat16 is only supported on GPUs with compute capability of at least 8.0.
Your Tesla T4 GPU has compute capability 7.5. You can use float16 instead by explicitly
setting the `dtype` flag in CLI, for example: --dtype=half.

То есть на T4 и V100 vLLM стартует только с --dtype half, а FP8-кэш там недоступен в принципе.

У Ollama диагностика памяти живёт в одной команде — ollama ps:

NAME           ID              SIZE      PROCESSOR         UNTIL
llama3.1:8b    42182419e950    6.7 GB    100% GPU          4 minutes from now

Пока в колонке PROCESSOR стоит 100% GPU, всё хорошо. Как только там появляется 47%/53% CPU/GPU, скорость падает в несколько раз: часть слоёв считается процессором. Таблица соответствия моделей и памяти собрана в отдельном разборе — сколько RAM нужно для Ollama.

Запуск: команды, порты и эксплуатация

Ollama ставится одной строкой и сразу регистрируется как systemd-юнит:

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl edit ollama

В drop-in задаются переменные — сам юнит менять не нужно, обновление его перезапишет:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=2"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_FLASH_ATTENTION=1"

Дальше sudo systemctl restart ollama и ollama pull llama3.1:8b. Про безопасность: у Ollama нет никакой авторизации. Порт 11434, открытый наружу, — это чужая модель на вашем GPU за ваш счёт. Держите его на loopback и закройте фаерволом:

sudo ufw allow 22/tcp
sudo ufw deny 11434/tcp
sudo ufw enable

Наружу пускайте только через nginx с basic-auth или WireGuard.

vLLM ставится в отдельное окружение, версию имеет смысл фиксировать — между минорными релизами регулярно меняются флаги:

python3 -m venv /opt/vllm
/opt/vllm/bin/pip install "vllm==0.11.0"
/opt/vllm/bin/vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --host 127.0.0.1 --port 8000 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --kv-cache-dtype fp8 \
  --api-key sk-local-changeme

В отличие от Ollama, у vLLM есть ключ API из коробки и телеметрия в формате Prometheus. Две метрики, по которым видно, пора ли добавлять железо:

curl -s http://127.0.0.1:8000/metrics | grep -E 'num_requests_(running|waiting)'

Если vllm:num_requests_waiting стабильно больше нуля — очередь не рассасывается, и тюнинг это не исправит: нужна вторая карта или более короткий --max-model-len.

Где каждый ломается: честный список

Ollama. Нет авторизации и нет метрик — мониторинг придётся строить снаружи, по логам и времени ответа. Параллелизм статический, каждый слот стоит полного KV-кэша. При смешанной нагрузке и OLLAMA_MAX_LOADED_MODELS=1 начинается перезагрузка моделей туда-сюда: пользователь ждёт 10–30 секунд на подгрузку весов. Тензорного параллелизма нет — на две карты модель раскладывается по слоям, это даёт влезть по памяти, но не ускоряет. И Q4 — всё-таки потеря качества, заметная на задачах со строгим форматом вывода.

vLLM. Требует GPU, точка. Один процесс — одна модель; две модели означают два процесса и поделенную VRAM. Холодный старт 40–90 секунд: загрузка весов плюс захват CUDA-графов, --enforce-eager сокращает его, но отнимает 10–15% пропускной. pip install vllm тянет PyTorch с CUDA — 8–10 ГБ на диске ещё до первой модели. GGUF поддерживается экспериментально и медленно, так что коллекцию из Ollama не перенести. И флаги меняются между версиями: незакреплённая версия однажды не поднимется после обновления.

Общий минус: локальная модель уровня 8B — не облачный фронтир. Если нужно качество топовых API, вопрос стоит не «Ollama или vLLM», а локальная модель против облачного API.

Какой сервер брать под это в MAATRIX

Конфигурация зависит от того, какой из двух путей вы выбрали, и разница здесь принципиальная.

Ollama на CPU, минимум: 4 vCPU, 16 ГБ RAM, 60 ГБ NVMe. Модель 7–8B в Q4_K_M поедет со скоростью 6–9 токенов в секунду. Этого хватает боту, суммаризатору, разбору документов по расписанию — всему, где ответ не читают в реальном времени. Для живого чата медленно, и признавать это надо до заказа.

Ollama на CPU, комфортный вариант: 8 vCPU, 32 ГБ RAM, 120 ГБ NVMe. Те же 8B дают 10–14 токенов в секунду, помещается вторая модель и остаётся запас на Open WebUI рядом. Диск берите с запасом: каждая модель — от 4 до 25 ГБ, и коллекция в /usr/share/ollama/.ollama/models растёт незаметно.

vLLM, минимум: GPU с 24 ГБ VRAM, 8 vCPU, 32 ГБ RAM, 100 ГБ NVMe. Оперативная память нужна не для инференса — через неё грузятся веса; на 16 ГБ RAM загрузка 16-гигабайтной модели упрётся в своп. Диск: 8–10 ГБ зависимостей плюс кэш HuggingFace.

vLLM, комфортный вариант: 48 ГБ VRAM одной картой либо две по 24 с --tensor-parallel-size 2, 64 ГБ RAM, 200 ГБ NVMe. Здесь 8B живёт в FP16 с длинным контекстом, а 32B — в 4-битном AWQ.

По локации для инференса мы советуем UK, Лондон. Причина практическая: реестр Ollama и HuggingFace оттуда открываются напрямую, без прокси, — а pip install vllm и ollama pull из России регулярно обрываются на середине. Плюс низкий пинг до ЕС и европейская юрисдикция, если модель обрабатывает данные клиентов из Евросоюза. Берите RU, если персональные данные обязаны оставаться в России по 152-ФЗ, и US, если рядом с локальной моделью держите прокси к зарубежным API. Развёрнутое сравнение — в материале VPS в Великобритании для доступа к нейросетям и AI.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта не нужна даже для лондонской площадки. Совет напоследок: если сомневаетесь, начинайте с Ollama на VPS, снимите реальные p95 и длину очереди на своём трафике и переезжайте на GPU с vLLM, только когда упрётесь в полку. Обратный порядок обходится дороже.

Частые вопросы