vLLM vs Ollama vs llama.cpp: какой движок инференса ставить в продакшен

Движок инференса (inference engine) — это программный слой, который принимает HTTP-запросы, загружает языковую модель в VRAM и раздаёт ответы нескольким пользователям одновременно. В 2026 году четыре практических варианта для корпоративного self-hosted AI: vLLM, Ollama, llama.cpp и SGLang — TGI ушёл в maintenance. Выбор движка определяет, выдержит ли система рабочую нагрузку компании.

Сценарий, который мы видим раз в месяц: компания развернула пилот на Ollama — «всё работает, ребята из продаж довольны, давайте катить на всю фирму». Через две недели после раскатки служба поддержки ругается, что ассистент отвечает по 30 секунд, юристы пишут что ничего не открывается в 11 утра, а админ замечает на графиках что GPU нагружен на 18%. Никто не сломал железо. Сломан выбор движка инференса.

Между «модель скачать и запустить» и «обслуживать 200 человек одновременно» лежит выбор inference engine — программы, которая принимает HTTP-запросы, грузит модель в VRAM, batch’ит запросы, считает forward pass и возвращает токены. От этого выбора зависит, выдержит ли self-hosted AI рабочий день компании или будет ложиться на каждой летучке. Этот текст — про четыре практических варианта в 2026: vLLM, Ollama, llama.cpp и SGLang — плюс что делать с TGI после ухода в maintenance.

Зачем вообще отдельный движок

Запустить LLM руками через transformers в Python можно. Но в продакшене нужны вещи, которых там нет:

Continuous batching — склеивать запросы разных пользователей в один forward pass на GPU. Без этого 10 параллельных юзеров = 10 последовательных проходов = очередь длиной в минуты.
PagedAttention / KV-cache management — управление памятью для ключей и значений attention. Наивный подход съедает VRAM до OOM при первом длинном контексте.
Quantization-aware кernels — оптимизированные ядра для GGUF / AWQ / GPTQ / FP8.
OpenAI-compatible API — чтобы Dify, Open WebUI, LangChain и любой внутренний код подключались без переделки.
Метрики — Prometheus-эндпоинт с latency, throughput, queue length.
Streaming — токен-за-токеном, чтобы UI не ждал минуту до первого слова.

Каждый из четырёх движков ниже закрывает эти задачи по-разному. И главное — для разных сценариев.

vLLM — рабочая лошадка для серверного инференса

Что: open-source движок от UC Berkeley, центр гравитации экосистемы в 2026 году. Apache 2.0.

Что умеет:

PagedAttention — оригинальная разработка vLLM, превращающая KV-cache в подобие виртуальной памяти; именно она позволяет batch’ить десятки и сотни параллельных запросов.
Continuous batching — на 10 параллельных юзерах vLLM выдаёт ~485 t/s суммарно для Llama 3.1 8B FP16, тогда как Ollama упирается в ~148 t/s в той же конфигурации (SitePoint benchmark).
OpenAI-compatible REST + gRPC — переключение с OpenAI на свой контур = поменять base_url.
Квантизация — AWQ, GPTQ, FP8, BitsAndBytes; GGUF загружается, но без оптимальных кернелов — рекомендуют конвертировать в AWQ/FP8.
Tensor parallelism / pipeline parallelism — для моделей 70B+ на нескольких GPU.
Speculative decoding — ускорение через draft-модель.
Prefix caching — кэш для общих префиксов промпта (системный промпт, базовая инструкция).
Метрики Prometheus — встроенно, ровно тот эндпоинт, что просит DevOps.

Слабые стороны:

Сложнее в развёртывании, чем Ollama. Запуск через Docker / pip + правильно сконфигурированные --gpu-memory-utilization, --max-model-len, --tensor-parallel-size.
На macOS работает плохо — vLLM написан под NVIDIA / AMD ROCm, для Apple Silicon есть форк vllm-mlx, но он догоняет.
Не любит «маленьких» сетапов: ниже одного A10 / 4090 эффект от continuous batching пропадает, можно ставить llama.cpp и не страдать.

Когда брать:

5+ одновременных пользователей.
Серверный сетап на NVIDIA (A10, L4, A100, H100, RTX 4090/5090, RTX PRO 6000 Blackwell).
Нужна Prometheus-наблюдаемость и SLA.
Прод. Везде, где лежит и ассистент, и поддержка, и менеджеры одновременно.

Ollama — отличный пилот, плохой продакшен

Что: обёртка над llama.cpp с великолепным DX. Apache 2.0. ollama run llama3.3 — и всё работает.

Что умеет:

Установка одной командой на любой OS, в том числе Windows.
OpenAI-compatible эндпоинт — Dify, Open WebUI цепляются за минуту.
Автозагрузка моделей — ollama pull qwen3:32b-q4_K_M и оно скачается с реестра.
Hot model swap — переключение между моделями без рестарта сервиса.
Modelfile — простой формат с системным промптом и параметрами.
GGUF-квантизация — оптимизирована под этот формат.

Где ломается в продакшене. По умолчанию OLLAMA_NUM_PARALLEL=1 — то есть одна модель обслуживает один запрос за раз, остальные становятся в очередь длиной до 512 (OLLAMA_MAX_QUEUE). Поднять до 4 можно, до 8 уже подирает GPU и уменьшает контекст. Согласно официальной FAQ Ollama, параллелизм определяется тремя переменными:

OLLAMA_NUM_PARALLEL — параллельных запросов на модель.
OLLAMA_MAX_LOADED_MODELS — сколько моделей одновременно в памяти.
OLLAMA_MAX_QUEUE — длина очереди.

В замерах при 128 одновременных пользователях vLLM держит P99 latency меньше 100 мс, Ollama — 673 мс (Markaicode). Это не баг Ollama, это её архитектурный выбор: она FIFO-планировщик поверх llama.cpp, без continuous batching. Дополнительный 10–15% overhead vs голый llama.cpp — плата за управляющий слой (Ollama vs vLLM benchmark).

Когда брать:

Пилот / proof-of-concept на 1–5 пользователей.
Локальный ассистент инженера или юриста.
Тестовый сервер для подбора модели и квантизации.
Edge-сценарии, где скорость развёртывания важнее производительности (отдел из 3 человек, ноут разработчика, тестовый Mac mini).

Когда не брать:

Любой кейс с 10+ юзерами одновременно.
Customer-facing сервис со SLA.
Когда нужен Prometheus-эндпоинт и алерты на latency.

llama.cpp — крепкий низкоуровневый движок

Что: оригинальный C++ движок, на котором построена половина экосистемы (Ollama, LM Studio, Jan, многие десктопные обёртки). MIT-подобная лицензия.

Что умеет:

GGUF — родной формат. Кванты от Q2 до Q8 + специальные K_M / K_S варианты, IQ-кванты для экстремальной экономии.
Кросс-платформенность — CUDA, ROCm, Metal, Vulkan, OpenCL, чистый CPU. Работает там, где vLLM сразу скажет «ставь NVIDIA».
Apple Silicon — на M-чипах llama.cpp с Metal-бэкендом конкурентоспособен с MLX и значительно опережает Ollama в чистом throughput на одиночных запросах.
Минимальные зависимости — один бинарник. Грузится на серверы без Python.
Speculative decoding, grammar-constrained output, prompt caching — присутствуют.
server-режим — встроенный HTTP-сервер с OpenAI-compatible эндпоинтом.

Слабые стороны:

Continuous batching формально появился в 2024 году, но его эффективность не догоняет vLLM/SGLang на NVIDIA.
На пиковой нагрузке vLLM выдаёт >35× больше RPS и >44× больше output tokens/sec (Red Hat Developer).
Конфиги — минимализм; не очень понятно «как готовить» для production без чтения исходников.

Когда брать:

Apple Silicon (Mac Studio M3 Ultra) — это родной для llama.cpp ландшафт, vLLM здесь догоняет.
Edge / on-device — киоск, ноутбук менеджера, сервер на ARM, машина без NVIDIA.
Сетапы на не-NVIDIA железе (Radeon, Intel Arc, серверы с Vulkan).
Когда вам нужен один бинарник без зоопарка зависимостей.

SGLang — для RAG, multi-turn и structured output

Что: относительно новый движок, выросший из академического проекта в LMSYS. Apache 2.0. Стал mainstream в 2025–2026 после стабилизации API.

Что умеет:

RadixAttention — кэш префиксов в виде radix-дерева. Если у вас RAG с повторяющимся системным промптом + длинной инструкцией + уникальным запросом — SGLang переиспользует общий префикс между вызовами.
Throughput — на H100 пик ~16,200 t/s vs ~12,500 t/s у vLLM (29% преимущество), на prefix-heavy workloads — до 6.4× (Yotta Labs).
Native structured output — JSON-schema, regex constraints, function calling — встроены и быстрее, чем outlines/instructor поверх vLLM.
OpenAI-compatible API + собственный SGLang Frontend Language для агентских пайплайнов.
Speculative decoding, tensor parallelism, FP8/AWQ — на уровне vLLM.

Слабые стороны:

Меньше hardware-поддержки. NVIDIA — да, AMD — догоняет, TPU/Trainium/Gaudi — нет.
Сообщество и контрибьюторы меньше, чем у vLLM (примерно в 3 раза по количеству).
Меньше моделей сразу из коробки — encoder-decoder, мультимодальные приходят с лагом.

Когда брать:

RAG-системы с длинным системным промптом и общими инструкциями (выгода от RadixAttention реальная).
Multi-turn чаты — продолжающийся контекст диалога переиспользуется.
AI-агенты с structured output (function calling, JSON schema), где нужно сокращать latency на каждом вызове.
В пределах NVIDIA и стандартных архитектур моделей.

Когда не брать:

Гетерогенный парк железа (TPU, Apple Silicon, AMD без боли).
Редкие модели и архитектуры — vLLM поддержит раньше.

TGI — теперь RIP, и это важно знать

Text Generation Inference (TGI) от HuggingFace был долгое время одним из стандартов. С 11 декабря 2025 года TGI переведён в maintenance mode: принимаются только мелкие багфиксы, документация и лёгкие правки. HuggingFace официально рекомендует мигрировать на:

vLLM — для серверного инференса.
SGLang — для prefix-heavy и agent-сценариев.
llama.cpp / MLX — для локального запуска.

Если вы запускали пилот на TGI — пора планировать миграцию. Через год-два уязвимости перестанут чиниться вовремя, новые модели Llama / Qwen / DeepSeek могут не поддерживаться или поддерживаться с задержкой.

Какой движок выбрать для продакшена?

Сценарий	Дефолт	Альтернатива
1–5 юзеров, пилот	Ollama	llama.cpp server
5–50 юзеров, отдел	vLLM	Ollama с `OLLAMA_NUM_PARALLEL=4` (на грани)
50–500 юзеров, компания	vLLM	SGLang при RAG-нагрузке
500+ юзеров, customer-facing	vLLM с tensor parallelism	SGLang
Apple Silicon (Mac Studio M3 Ultra)	llama.cpp / MLX	Ollama
Edge / киоск / ноут	llama.cpp	Ollama
RAG с длинным system prompt	SGLang	vLLM с prefix caching
AI-агент с function calling	SGLang	vLLM + outlines
Не-NVIDIA (AMD/Intel/CPU)	llama.cpp	vLLM на ROCm (с осторожностью)
Существующий TGI	мигрировать на vLLM	SGLang при подходящем профиле

Привязка к нашему ICP

Онлайн-школа на 500–1500 учеников, AI-ассистент по контенту курса. Пик нагрузки — после прайм-тайма уроков, 50–100 одновременных запросов. Дефолт: vLLM на одной A10 / L4 для модели 8B-класса. Если ассистент использует общую базу знаний с длинной инструкцией — переход на SGLang окупится.

Отдел продаж на 10 человек, расшифровка и саммари звонков. Пиковая нагрузка — 5–8 одновременных задач, в основном асинхронные. Дефолт: vLLM на 4090 / RTX PRO 6000 для 32B модели. Ollama тоже потянет, но при росте до отдела на 30 человек упрётся.

Юр-департамент на 5–8 человек, разбор договоров. Запросы редкие, но контекст длинный (50–100K токенов). Дефолт: vLLM для возможности больших контекстов и квантизации FP8. Ollama здесь страдает на длинных контекстах из-за отсутствия PagedAttention.

Бутик-интегратор / разработчик, локальный ассистент. Один пользователь, MacBook Pro / Mac Studio. Дефолт: Ollama (или llama.cpp напрямую если хочется тонкой настройки). vLLM на маке — оверкилл и боль.

Грабли при миграции с Ollama на vLLM

1. Формат модели меняется. Ollama хранит в GGUF (~/.ollama/models). vLLM грузит из HuggingFace Hub в Safetensors / AWQ / GPTQ / FP8. Конвертация GGUF → vLLM-friendly формат требует пересчёта или скачивания исходных весов.

2. Системный промпт — разные шаблоны. Modelfile в Ollama vs --chat-template в vLLM. Тот же chat template должен быть один в один, иначе модель «переключается» по тону.

3. Параметры запуска. --gpu-memory-utilization (по умолчанию 0.90) часто слишком агрессивный — нужно оставить запас VRAM под KV-cache и эмбеддер. Если в памяти живёт reranker — 0.75 безопаснее.

4. Контекст-окно. В Ollama по дефолту num_ctx=2048. В vLLM --max-model-len — то, что заявлено моделью (32K, 128K). Не забудьте, потому что vLLM не предупреждает.

5. Concurrency settings. --max-num-seqs (количество одновременных последовательностей) и --max-num-batched-tokens определяют, сколько continuous batching реально может прокачать. Дефолты — на сервер, не на встройку в RTX 4090.

6. Health check. Ollama отвечает на GET / пустой страницей. vLLM — GET /health. Если у вас балансировщик с health-проверкой — поправьте.

Что мы ставим в AGmind по умолчанию

Дефолт для проектов AGmind: vLLM.

Причины:

Continuous batching выдерживает реальную нагрузку отдела или компании.
Prometheus-метрики из коробки — встаёт в нашу мониторинговую связку без танцев.
Поддержка квантизации FP8/AWQ позволяет уплотнить большие модели в одну видеокарту.
Tensor parallelism — путь к большим моделям без переписывания.

Когда меняем на SGLang: клиентские RAG-системы с длинным фиксированным system prompt, agent-пайплайны со structured output, сильно multi-turn чаты.

Когда оставляем Ollama: этап аудита и пилота — пока мы не подтвердили требования по нагрузке, Ollama даёт возможность быстро гонять разные модели и квантизации без затрат на DevOps.

Когда выбираем llama.cpp: Apple Silicon (Mac Studio M3 Ultra), edge-сценарии, нестандартное железо.

Итог

Ошибка №1 — пытаться вытянуть Ollama в продакшн «потому что на пилоте работало». Ollama проектировалась как удобный личный/командный инструмент, не как сервер на 100 пользователей. И это нормально.

Ollama — пилот, разработчик, edge.
llama.cpp — Apple Silicon, не-NVIDIA железо, минимальные зависимости.
vLLM — сервер, нагрузка, метрики, дефолт на NVIDIA.
SGLang — RAG с длинным префиксом, агенты, structured output.
TGI — мигрировать на vLLM или SGLang в течение года.

Связанные тексты: сколько стоит сервер для AI, как развернуть ChatGPT в компании за 6 недель, DGX Spark как приватный AI-сервер, Mac Studio M3 Ultra для AI, архитектура AI-помощника, векторные базы данных для RAG.