Содержание

  1. Зачем вообще нужен движок инференса
  2. Ollama: простота любой ценой
  3. vLLM: продакшен-стандарт
  4. Бенчмарки: цифры, которые решают
  5. Кому что подходит — конкретные сценарии
  6. Практика: установка и первый запуск
  7. Итог

В 2026 году запустить LLM на своём сервере — уже не экзотика, а рутина. Собственники бизнеса задают этот вопрос не айтишникам, а друг другу: «мы хотим свою нейросеть, не зависеть от OpenAI и не платить за каждый токен».

Но здесь возникает развилка. LLM — это не бинарник, который можно просто скачать и запустить. Нужен движок инференса — программа, которая загружает модель в память, обрабатывает запросы и выдаёт ответы. Два главных претендента сегодня — Ollama и vLLM. Первый — для тех, кто хочет «взял и запустил». Второй — для тех, кому нужно выдерживать сотни параллельных запросов в продакшене.

Разберём, чем они отличаются на самом деле, когда каждый оправдан, и почему выбор не сводится к «какой лучше». В этой статье — без рекламных обещаний, только бенчмарки, архитектурные детали и реальные кейсы.

14-24x выше throughput у vLLM
1 команда для старта Ollama
300+ моделей в Ollama Hub
9x разрыв при 8+ пользователях
Схема выбора движка инференса LLM

Дорожная карта выбора движка: от сценария к решению

Зачем вообще нужен движок инференса

HHапрямую загрузить LLM через PyTorch — просто. model.generate() — и модель работает. Проблема в том, что для реальной нагрузки такой подход не годится. PyTorch аллоцирует под каждый запрос полный контекст, не умеет группировать запросы в батч и тратит гигабайты на хранение KV-кэша для каждого пользователя отдельно. В результате — низкая пропускная способность, дикий расход VRAM и никакого API для интеграции.

Движок инференса решает три задачи. Оптимизация памяти — через PagedAttention (vLLM), радикс-внимание (SGLang), квантизацию (llama.cpp). Ускорение генерации — через continuous batching, FlashAttention, асинхронную обработку. API-прослойку — OpenAI-совместимый эндпоинт, вызов функций, интеграция с Open WebUI, n8n, LangChain. Туториалы по сборке стека есть, например, в нашем гайде по локальным AI-агентам.

Ключевая идея: разница между Ollama и vLLM — не в «крутизне», а в цене одного запроса при росте нагрузки. Ollama проигрывает тем сильнее, чем больше пользователей стучатся одновременно.

Ollama: простота любой ценой

Ollama — это C++-клиент на базе llama.cpp, обёрнутый в удобный CLI и HTTP API. Его главное достижение — установка в одну команду. curl -fsSL https://ollama.com/install.sh | sh — и у вас на сервере работает LLM. Второй командой ollama pull llama3.3:70b скачивается модель. Третьей — начинается чат. Всё.

За этой простотой скрывается несколько архитектурных ограничений. Ollama не использует continuous batching в понимании vLLM — она объединяет запросы, но без динамического управления очередью. На Хабре собрали бенчмарки: на одной H100 с Llama 3.1 8B Ollama выдерживает около 12 параллельных запросов до деградации latency. После 20 — время ответа растёт линейно, потому что движок начинает ставить запросы в очередь и обрабатывать последовательно.

Ещё один нюанс — формат моделей. Ollama работает исключительно с GGUF (квантизованные модели от llama.cpp). Это даёт огромную экономию памяти — модель 70B в Q4 занимает ~40 ГБ вместо 140 ГБ в FP16. Но GGUF не поддерживает все архитектурные фичи: например, вызов функций (tool calling) в Ollama работает с ограничениями, а multi-GPU балансировка — через костыли.

Ollama не предназначена для продакшена с высокой нагрузкой. Это инструмент для разработки, прототипирования и личного использования. Если к вашему API стучится 10 пользователей — Ollama справится. Если 50 — начнутся таймауты. Если 200 — нужен vLLM.

vLLM: продакшен-стандарт

vLLM — это Python-фреймворк от UC Berkeley, построенный вокруг алгоритма PagedAttention. Вместо того чтобы хранить KV-кэш для каждого запроса в непрерывном блоке памяти (как делает PyTorch), vLLM разбивает его на страницы по 16-32 токена и управляет ими как виртуальная память в ОС. Эффект — от 14 до 24 раз выше пропускная способность по сравнению с обычным инференсом, при том же объёме VRAM.

Но главное преимущество vLLM — continuous batching. В классическом батчинге модель ждёт, пока наберётся полный батч запросов, потом обрабатывает их все разом, потом ждёт следующий батч. В continuous batching движок добавляет новые запросы прямо в текущий батч по мере их поступления — как конвейер на заводе. Red Hat в своих тестах 2026 года показала разрыв в 9x при 8 параллельных пользователях между vLLM и Ollama на одной и той же модели Llama 3 70B на H100.

Кроме того, vLLM поддерживает:

  • Multi-GPU и multi-node (Tensor Parallelism, Pipeline Parallelism)
  • Все основные форматы: Safetensors, GPTQ, AWQ, FP8
  • OpenAI-совместимый API с полноценным вызовом функций (tool calling)
  • Prefix caching (кэширование общих префиксов запросов — экономия до 60% времени для системных промптов)
  • Speculative decoding (маленькая «модель-черновик» ускоряет большую на 2-3x)
  • LoRA-адаптеры на лету, без перезагрузки

Плата за это — сложность. Установка vLLM требует Python-окружения, CUDA-тулкита, понимания параметров GPU. Ошибка в --tensor-parallel-size или неверно выбранный тип квантизации — и модель не влезает в VRAM, или latency взлетает в 2 раза.

Золотое правило: если вы пишете AI-агента для себя — Ollama. Если ваш агент обслуживает клиентов, дёргает CRM, обрабатывает 1000+ запросов в час — vLLM. Если сомневаетесь — считайте стоимость одного запроса при пиковой нагрузке, и выбор станет очевиден.
# Сравнение throughput при росте нагрузки
# Модель: Llama 3.1 8B, GPU: 1x H100 (80 ГБ)
 
# Параллельные запросы → токенов/с
 
1 пользователь: Ollama 185 tok/s ≈ vLLM 220 tok/s
8 пользователей: Ollama 320 tok/s → vLLM 1 890 tok/s (5.9x)
32 пользователя: Ollama 410 tok/s → vLLM 4 200 tok/s (10.2x)
128 пользователей: Ollama 480 tok/s → vLLM 7 100 tok/s (14.8x)
 
# При 1 пользователе разница незначительна.
# При 128 — vLLM быстрее в 15 раз.

Данные: синтетические бенчмарки на основе публичных тестов Red Hat, serverflow.ru и Habr. Реальные цифры зависят от модели, квантизации и конфигурации GPU.

Бенчмарки: цифры, которые решают

Сравнивать движки «в лоб» некорректно — они оптимизированы под разные сценарии. Но есть три метрики, которые объективно показывают разницу.

Throughput (токенов/с). При одном пользователе vLLM быстрее Ollama на 15-20% за счёт оптимизированных CUDA-ядер. AI Bot Direct приводит данные: при 8 параллельных пользователях разрыв — 9x. При 128 — 15x. Причина — continuous batching: vLLM никогда не простаивает, пока хотя бы один запрос в очереди. Ollama обрабатывает запросы почти последовательно.

Latency (время первого токена, TTFT). Здесь vLLM проигрывает при малой нагрузке — из-за накладных расходов на планировщик continuous batching. Ollama даёт первый токен быстрее при 1-2 пользователях. При 10+ — vLLM отыгрывает и держит latency стабильной, тогда как у Ollama она растёт линейно.

Использование VRAM. Ollama с GGUF Q4_K_M потребляет на 30-40% меньше памяти, чем vLLM с той же моделью в FP16 или AWQ. Это преимущество для серверов с ограниченной видеопамятью (RTX 3090/4090 с 24 ГБ). Но vLLM эффективнее использует доступную память через PagedAttention — больше запросов в одном батче без переполнения.

Метрика Ollama vLLM
Throughput (1 user) 185 tok/s 220 tok/s
Throughput (128 users) 480 tok/s 7 100 tok/s
TTFT (1 user) ~150 мс ~220 мс
TTFT (32 users) ~1 200 мс ~280 мс
Расход VRAM (8B Q4) ~6 ГБ ~10 ГБ (FP16)
Multi-GPU Ограниченно TP + PP из коробки

Кому что подходит — конкретные сценарии

Вместо абстрактного «выбирайте по задачам» — четыре реальных сценария, с которыми к нам приходят клиенты.

Сценарий 1: Разработчик, который пишет AI-агента для себя. Нужен быстрый старт, модель на коленке, тестирование промптов. Выбор — Ollama. Ставится за 2 минуты, моделей в реестре 300+, API OpenAI-совместимый. Для одного-двух параллельных запросов производительности достаточно. Если потом понадобится продакшен — Ollama можно заменить на vLLM без изменения кода: оба поддерживают одинаковый эндпоинт /v1/chat/completions.

Сценарий 2: Команда из 10-50 человек в корпоративном чате. Open WebUI на Ollama — классическая комбинация. Open WebUI проксирует запросы к Ollama, добавляет RAG, управление пользователями. Работает стабильно до 10-15 одновременных пользователей. Дальше — latency растёт. Тут есть два пути: либо поставить vLLM за Open WebUI (через смену эндпоинта), либо оставить Ollama, но ограничить число одновременных сессий.

Сценарий 3: Продакшен-сервис, который обрабатывает тысячи запросов в час. Клиентский AI-агент поддержки, квалификатор лидов, автоматизация документов. Единственный адекватный выбор — vLLM. Continuous batching даёт стабильную latency при любой нагрузке, tool calling работает нативно, multi-GPU позволяет горизонтально масштабироваться. Подробно про архитектуру таких агентов мы писали в кейсе ИИ-оператора поддержки.

Сценарий 4: Бюджетный сервер без GPU. Только CPU, 32-64 ГБ RAM. Выбор — Ollama с llama.cpp backend (GGUF, Q4 или Q3). vLLM не поддерживает CPU-инференс (только с недавних пор экспериментальный V1 бэкенд, но без гарантий). Альтернатива — llama.cpp без обёртки Ollama, но тогда не будет HTTP API.

Практика: установка и первый запуск

Коротко — как поднять каждый движок на свежей Ubuntu 22.04/24.04 с NVIDIA GPU.

Ollama:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama serve
# API: curl http://localhost:11434/v1/chat/completions

Всё. Open WebUI ставится через Docker: docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway ghcr.io/open-webui/open-webui:main. Подробная установка — в отдельном гайде по Open WebUI.

vLLM:

pip install vllm
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-7B-Instruct \
    --tensor-parallel-size 1 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 8192 \
    --port 8000
# API: curl http://localhost:8000/v1/chat/completions

Основные параметры: --tensor-parallel-size — число GPU для тензорного параллелизма. --gpu-memory-utilization — доля VRAM под модель (0.80-0.95). --max-model-len — максимальная длина контекста. --enforce-eager — отключить CUDA graphs (помогает при малых объёмах VRAM).

Для Docker:

docker run --runtime nvidia --gpus all \
    -p 8000:8000 \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen2.5-7B-Instruct

Если модель не влезает в VRAM — используйте квантизацию: pip install vllm[awq] и флаг --quantization awq.

Совет: начинайте с Ollama. Как только упрётесь в производительность — переезжайте на vLLM. API-интерфейс одинаковый, код менять не придётся. В гайде по локальным агентам описан полный переход со сценариями.

Итог

Выбор между Ollama и vLLM — это не технологический вопрос, а вопрос бюджета и нагрузки. Если вы разрабатываете AI-агента для себя или тестируете гипотезу — Ollama даст результат за 5 минут. Если агент идёт в продакшен и обрабатывает запросы реальных пользователей — vLLM окупит время на настройку за первую же неделю работы.

При этом не обязательно выбирать раз и навсегда. Современный стек позволяет начинать с Ollama, а потом прозрачно переключаться на vLLM через Open WebUI, продолжать через n8n или LangChain — API остаётся совместимым. Это не блокирующее решение.

На практике мы в N202 используем оба движка: Ollama на этапе разработки и тестирования агентов, vLLM — когда отдаём клиенту готовый продукт с SLA. Альтернативы тоже есть — SGLang быстрее vLLM на батчах за счёт радикс-внимания, llama.cpp оптимальнее Ollama для CPU, Triton от NVIDIA — для enterprise-инсталляций. Но стартовать с Ollama → vLLM — самый надёжный путь без vendor lock.