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.

Его движок построен на базе llama.cpp — библиотеки инференса на C++, которая сделала квантование GGUF практичным для обычного оборудования. С тех пор Ollama добавила собственный движок для некоторых новых семейств моделей, но llama.cpp по-прежнему остается основой для большинства обслуживаемых моделей. Поэтому, когда люди сравнивают Ollama с llama.cpp, они в основном сравнивают уровень эргономики с тем инструментом, который он оборачивает.

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

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

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

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

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

Continuous batching — это ключевое различие

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

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

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

Вы можете настроить OLLAMA_NUM_PARALLEL=4 и получить часть этих преимуществ. Цена — использование памяти. Каждый параллельный слот требует собственного KV-кэша, а Ollama делит контекстное окно между слотами. Таким образом, четыре параллельных запроса к модели, настроенной на 8192 токена, оставляют каждому запросу по 2048 токенов контекста. Значение 8192 — это выбор, а не данность, поэтому увеличение num_ctx и расчет необходимого объема RAM — это шаг, который определяет, будут ли четыре слота вообще пригодны для использования. Paged-кэш в vLLM позволяет избежать этого компромисса, так как блоки выделяются запросу по мере его фактического роста. В любом случае, предел количества пользователей, которых может обслуживать один сервер одновременно, определяется размером KV-кэша, стоимостью префилла (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. Устанавливайте vLLM в отдельное виртуальное окружение, так как он требует специфическую сборку 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 недостаточно для параллельного вывода тензоров.

Наиболее важные флаги для промышленной эксплуатации: --max-model-len (размер контекстного окна, который вы готовы выделить), --gpu-memory-utilization (доля памяти видеокарты, которую может занять vLLM; по умолчанию 0.92 на июль 2026 года), --tensor-parallel-size для распределения одной модели между несколькими GPU и --api-key.

Аутентификация: один флаг в vLLM и её отсутствие в Ollama

vLLM принудительно требует bearer token, если вы его зададите:

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

То же самое значение можно передать через переменную окружения VLLM_API_KEY. Запрос без этого токена получит ошибку HTTP 401. Это всё ещё не повод открывать порт 8000 во внешнюю сеть, так как в vLLM нет ограничения частоты запросов (rate limiting), а обычный HTTP-токен передаётся в открытом виде, но это означает, что сервер различает вызывающую сторону.

В Ollama такой функции нет. Здесь нет ключей, логинов или списков разрешённых IP-адресов. Любой процесс, имеющий доступ к порту 11434, может запускать, загружать или удалять модели. Держите сервис на loopback-интерфейсе и обращайтесь к нему через собственный WireGuard VPN или через аутентифицирующий reverse proxy, который выполняет TLS termination (завершение шифрования на транспортном уровне).

Аппаратное обеспечение: требования для каждого решения

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

vLLM предполагает наличие GPU. По умолчанию система использует неквантованные веса с точностью 16 бит, что составляет примерно 2 GB на миллиард параметров: модели 8B требуется около 16 GB видеопамяти только для весов, без учета KV-кэша, который обеспечивает параллелизм, ради которого вы и устанавливали vLLM. На карте с 24 GB памяти остается достаточно места для рабочего кэша. На карте с 16 GB памяти места не хватит, поэтому придется либо выбрать модель поменьше, либо передать --quantization с квантованной контрольной точкой. Существует бэкенд для 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: 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 out-of-memory во время работы под нагрузкой, что является более серьезной проблемой.

Ollama выводит Killed в процессе генерации. Linux-механизм out-of-memory killer завершил процесс, так как модели потребовалось больше оперативной памяти, чем доступно на сервере. Проверьте это с помощью sudo dmesg | grep -i oom. Решением является использование модели меньшего размера или с более сильной квантованием, а не изменение настроек.

Ollama работает корректно при одиночных запросах, но зависает под нагрузкой. Ошибки в логах отсутствуют. Время выполнения запросов растет пропорционально количеству клиентов, так как OLLAMA_NUM_PARALLEL=1 обрабатывает их последовательно. Длинные ответы усугубляют очередь, поскольку один клиент занимает единственный слот до завершения генерации, блокируя всех остальных. Использование ограничения ответа через num_predict позволяет установить лимит времени, в течение которого один запрос может удерживать сервер. Увеличьте параметр параллелизма, приняв меньший контекст на запрос, либо перенесите нагрузку на vLLM.

vLLM возвращает 401 на каждый запрос. Вы запустили его с флагом --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 значительно опережает Ollama, поскольку механизм continuous batching декодирует все активные последовательности за один проход, тогда как Ollama по умолчанию обрабатывает их последовательно. На системах только с CPU этот вопрос неактуален: Ollama там работает, а vLLM — практически нет.

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

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

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

llama.cpp — это библиотека для инференса, а GGUF — формат квантованных весов для нее. Исполняемый модуль Ollama построен на базе llama.cpp и добавляет компоненты, которые в llama.cpp нужно настраивать самостоятельно: реестр моделей, автоматическую загрузку, резидентный сервер, systemd-юнит и API-совместимый с OpenAI эндпоинт. Ollama добавила собственный движок для некоторых новых семейств моделей, поэтому теперь они не идентичны на уровне реализации.

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

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

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

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