Ollama или vLLM: что выбрать для запуска LLM

Ollama против vLLM: краткий обзор

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

Оба решения поддерживают HTTP API, совместимый с OpenAI, поэтому переключение между ними требует лишь изменения базового URL в коде клиента. Разница заключается не в API, а в механизме обработки ситуации, когда второй запрос поступает в момент генерации токенов первым запросом.

Что на самом деле представляет собой Ollama

Ollama — это уровень удобства. Он предоставляет реестр моделей (ollama pull llama3.1:8b), локальное хранилище весов, интерфейс чата, systemd-сервис и HTTP API — всё в рамках одной команды установки. Большинство моделей, которые он обслуживает, — это файлы GGUF, обычно с 4-битной квантованием. Именно поэтому модель 7B или 8B занимает на диске около 5 ГБ вместо 16 ГБ. Квантование снижает объем памяти, необходимый для инференса на CPU. На компьютерах Apple Silicon он также может запускать модели на базе safetensors через движок MLX, а начиная с версии v0.40.0 (сентябрь 2026 года) поддерживаемые архитектуры запускаются на MLX автоматически.

Его GGUF-раннер построен на базе llama.cpp — библиотеки инференса на C++, которая сделала квантование GGUF практичным на обычном оборудовании. По состоянию на октябрь 2026 года Ollama поддерживает два движка: llama.cpp и MLX, а сборки для Linux также поддерживают инференс MLX с использованием CUDA. Руководство разработчика включает этот бэкенд с помощью cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 при наличии CUDA 13+ и cuDNN 9+. Таким образом, когда люди сравнивают Ollama с llama.cpp, они в основном сравнивают уровень эргономики с тем, что он оборачивает.

Проект рассчитан на одного пользователя. По состоянию на октябрь 2026 года значение по умолчанию для OLLAMA_NUM_PARALLEL равно 1. Это означает, что одна модель обрабатывает один запрос за раз, а все остальные ожидают в очереди, которая по умолчанию вмещает 512 записей (OLLAMA_MAX_QUEUE). Вы можете увеличить параметр параллелизма, а в разделе ниже объясняется, во что это вам обойдется. Если вы ранее не запускали Ollama, начните с размещения Ollama на VPS с закрытым портом 11434, так как локальный API не требует аутентификации.

Что такое vLLM на самом деле

vLLM — это сервер для инференса, и больше ничего. Он не управляет библиотекой моделей, предоставляет vllm chat клиент для работающего сервера и не загружает модель по запросу. При запуске вы указываете репозиторий Hugging Face, он загружает эту конкретную модель и обслуживает её до тех пор, пока вы не остановите процесс.

За эту узкую специализацию вы получаете высокую пропускную способность. Эту работу выполняют два механизма. PagedAttention хранит KV-кэш (key-value cache, состояние внимания для каждого токена, которое модель сохраняет для каждого активного запроса) в блоках фиксированного размера, подобно тому, как операционная система использует страницы памяти. Запросу больше не требуется один большой непрерывный участок памяти, зарезервированный под худший сценарий, поэтому память, которая раньше оставалась зарезервированной и неиспользуемой, становится доступной для большего числа одновременных запросов. Continuous batching позволяет новому запросу присоединиться к выполняемому пакету на следующем шаге декодирования, вместо того чтобы ждать завершения текущего пакета. Завершённая последовательность немедленно покидает пакет, и её слот освобождается для нового запроса.

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

Непрерывная пакетная обработка — это главное отличие

Представьте пять запросов, поступающих на сервер одновременно при идентичном аппаратном обеспечении.

Ollama с настройками по умолчанию выполняет первый запрос до завершения, затем второй и так далее. Пятый клиент ожидает завершения четырех полных генераций. Общая пропускная способность примерно равна скорости одной генерации, так как процессор всегда работает только с одной последовательностью.

vLLM декодирует все пять запросов за один прямой проход. Генерация одного токена для пяти последовательностей стоит почти столько же, сколько генерация одного токена для одной последовательности, поскольку самая ресурсоемкая часть — это чтение весов модели из памяти, и это чтение является общим для всего пакета. Это тот же самый факт пропускной способности памяти, который делает инференс на CPU медленным: вы платите за перемещение весов, а не за арифметические операции.

Вы можете установить OLLAMA_NUM_PARALLEL=4 и получить часть этих преимуществ. Цена — это память. Каждый параллельный слот требует собственного KV-кэша, и Ollama умножает выделение контекста, а не делит его: в её FAQ сказано, что требуемый объем RAM масштабируется как OLLAMA_NUM_PARALLEL умножить на OLLAMA_CONTEXT_LENGTH. Таким образом, четыре параллельных запроса к модели, настроенной на 8192 токена, удерживают по 8192 токена каждый, но сервер должен хранить кэш для 32768 токенов в сумме. Само значение 8192 — это выбор, а не данность, поэтому увеличение num_ctx и расчет необходимой RAM — это шаг, который определяет, поместятся ли четыре слота в принципе. Страничный кэш vLLM позволяет избежать резервирования полного окна для каждого слота заранее, так как блоки выделяются запросу по мере его фактического роста. В любом случае, предел того, сколько пользователей может обслуживать один сервер одновременно, сводится к размеру KV-кэша, стоимости префилла и глубине очереди, что и является причиной, почему сервер, который отлично работал для одного пользователя, начинает тормозить при пяти.

Установка и запуск 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). Текущий релиз vLLM (0.32.0, октябрь 2026) поддерживает Python версий от 3.11 до 3.14, что соответствует руководству по установке. Поддержка Python 3.10 была прекращена в 0.32.0, поэтому Python 3.12, используемый ниже, является безопасным выбором. Устанавливайте его в отдельное виртуальное окружение, так как он требует специфическую сборку PyTorch:

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

Последняя строка взята из руководства по установке vLLM для NVIDIA по состоянию на октябрь 2026 года. Она устанавливает предварительно скомпилированные ядра FlashInfer. Без них vLLM загружает и компилирует ядра при запуске, что, согласно руководству, может добавить несколько минут ожидания на GPU архитектуры Hopper и новее. Выполняйте эту команду после каждого обновления vLLM, так как FlashInfer не импортируется при несовпадении версий ядер.

Затем запустите модель. Имя модели — это идентификатор репозитория на 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 предоставляет контейнеру доступ к разделяемой памяти хоста; увеличение --shm-size — альтернативный вариант. PyTorch передает тензоры между процессами через разделяемую память, что особенно важно для тензорно-параллельного вывода.

Наиболее важные для продакшена флаги: --max-model-len (размер контекстного окна, за который вы готовы платить), --gpu-memory-utilization (доля памяти карты, которую vLLM может занять, по умолчанию 0.92 на октябрь 2026 года), --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 без него получит ответ HTTP 401. Однако ключ не защищает весь сервер целиком. Руководство по безопасности vLLM и код аутентификации в исходниках версии 0.32.0 применяют его только к эндпоинтам с префиксами путей /v1, /v2, /inference и /cohere. Текст справки --api-key на странице vllm serve перечисляет только первые три, но код проверяет все четыре. И руководство, и текст справки указывают, что другие эндпоинты, в частности /invocations, который предоставляет тот же инференс, что и /v1, не аутентифицируются. Это достаточная причина, чтобы не открывать порт 8000 во внешней сети. Руководство по безопасности vLLM также оставляет ограничение частоты запросов (rate limiting) на усмотрение обратного прокси-сервера, стоящего перед ним, а токен, передаваемый по обычному HTTP, можно прочитать при перехвате трафика, но этот флаг всё же означает, что сервер различает вызывающую сторону.

Локальный API Ollama не требует аутентификации. Облачные модели, публикация моделей и загрузка приватных моделей требуют входа в систему; прямой доступ к API ollama.com требует API-ключа. Любой процесс, который может обратиться к порту 11434, может запускать, скачивать или удалять модели. Оставьте его на loopback и обращайтесь к нему через собственный VPN на базе WireGuard или через аутентифицирующий обратный прокси-сервер с TLS termination (безопасность транспортного уровня).

Аппаратное обеспечение: требования

Ollama работает на CPU. 4-битная квантованная модель требует примерно полгигабайта оперативной памяти на каждый миллиард параметров плюс около гигабайта на накладные расходы среды выполнения и дополнительный объем для контекста. Таким образом, для модели 3B нужно около 4 GB свободной памяти, а для 8B — около 8 GB. Скорость на общем vCPU составляет от единиц до десятков токенов в секунду. Это ограничение пропускной способности памяти, а не ошибка конфигурации, и никакие флаги это не исправят. Чтобы увидеть эти расчеты в действии на конкретном релизе, а не опираться на эмпирические правила, запуск Nemotron 3.5 Lightning на VPS позволяет точно определить нужный тег, объем занимаемой RAM после загрузки и понять, достаточно ли быстро работает CPU-режим для ваших задач.

vLLM предполагает использование GPU. По умолчанию система работает с неквантованными весами в 16-битном представлении, что требует примерно 2 GB на каждый миллиард параметров: модели 8B нужно около 16 GB видеопамяти только для весов, не считая KV-кэша, который обеспечивает параллелизм, ради которого вы и устанавливали vLLM. На карте с 24 GB памяти остается достаточно места для кэша. На карте с 16 GB места не хватит, поэтому придется либо выбрать модель поменьше, либо передать --quantization (с квантованным чекпоинтом или для квантования полноразрядных весов при загрузке), либо выгрузить часть весов в системную RAM с помощью --cpu-offload-gb. Это сохранит точность, но замедлит работу, так как веса будут передаваться на GPU при каждом проходе. Существует CPU-бэкенд с собственными отдельными сборками, но он лишает смысла использование vLLM в принципе.

Таким образом, вопрос выбора аппаратного обеспечения чаще всего определяет выбор программного обеспечения. Нет GPU — используйте Ollama. Арендованный GPU, простаивающий на 5 процентах загрузки из-за последовательной обработки запросов — повод использовать vLLM.

Что выбрать для вашей нагрузки

• Один пользователь, VPS с одним CPU, написание черновиков и суммаризация: Ollama. Скорость приемлема, а проще решения не найти.
• Ассистент для программирования или MCP-сервер, связывающий ваши инструменты с локальной моделью, к которому обращаетесь только вы: Ollama. Параллелизм в один поток — это и есть ваша реальная нагрузка.
• Сравнение пяти моделей на этой неделе: Ollama. Загрузка и удаление моделей по тегам — это именно то, что он делает хорошо, в то время как vLLM требует перезапуска процесса для каждой модели.
• Внутреннее приложение, чат-сервис или конвейер поиска с реальными пользователями: vLLM. Здесь пакетная обработка (batching) оправдывает затраты на GPU.
• Пакетная задача по оценке ста тысяч документов за ночь: vLLM с высоким значением --max-num-seqs. Пропускная способность — единственный важный показатель, а задержка на один документ значения не имеет.
• Платформа для агентов, где несколько самостоятельно размещенных ИИ-агентов обращаются к модели одновременно: 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, если видеокарта больше ничем не занята.

Ollama выводит Killed в процессе генерации. Механизм Linux out-of-memory killer завершил процесс, так как модели потребовалось больше оперативной памяти, чем есть в системе. Проверьте это с помощью 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 и используется для тестирования новых релизов моделей. Оба API совместимы с OpenAI, поэтому одна клиентская библиотека с переключением base-URL подходит для обоих случаев. Контроль затрат здесь важнее выбора конкретного движка, так как простой GPU оплачивается так же, как и активная работа, а обеспечение предсказуемости расходов на агентов и инференс — это отдельная задача, не связанная с выбором сервера.

FAQ

Быстрее ли vLLM, чем Ollama?

При выполнении одного запроса на том же GPU разница невелика, так как оба инструмента выполняют одни и те же вычисления. При большом количестве одновременных запросов vLLM значительно опережает конкурента, поскольку механизм continuous batching декодирует все активные последовательности за один проход, тогда как Ollama по умолчанию выполняет их по очереди. На машинах только с CPU оба инструмента поддерживают пути вывода, при этом vLLM использует отдельные сборки (wheels) для CPU.

Может ли vLLM работать без GPU?

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

В чем разница между Ollama и llama.cpp?

llama.cpp — это библиотека для вывода, а GGUF — её формат квантованных весов. Ollama использует её для вывода GGUF и добавляет реестр моделей, загрузку по тегам, управление моделями и systemd-юнит. Ollama также поставляет движок MLX, который запускает модели в формате safetensors на Apple Silicon, и поддерживает сборки с CUDA на Linux, поэтому внутреннее устройство этих инструментов не всегда идентично.

Сколько видеопамяти нужно vLLM для модели 8B?

При точности 16 бит только веса занимают около 16 ГБ, примерно 2 ГБ на миллиард параметров, плюс к этому требуется место для KV-кэша. Карты на 24 ГБ будет достаточно. Для карты на 16 ГБ потребуется квантованная модель, модель меньшего размера или использование --cpu-offload-gb для перемещения части весов в системную оперативную память, что снизит скорость. vLLM резервирует часть памяти карты, определяемую параметром --gpu-memory-utilization, который по состоянию на октябрь 2026 года по умолчанию равен 0.92.

Нужно ли менять код приложения при переключении между ними?

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