Урок 1: Ollama vs vLLM — когда пилот становится production

Чему вы научитесь

• Отличать локальный runtime для пилота от production-сервера для нагрузки на десятки и сотни пользователей
• Понимать, когда Ollama остаётся нормальным выбором, а когда его уже надо убирать из общего контура
• Использовать vLLM там, где важны concurrent users, OpenAI-совместимый API, batching и экономия GPU-памяти
• Не попадать в типичную ловушку «пилот на ноутбуке поехал — значит, можно сразу выкатывать на 100 пользователей»
• Выбирать альтернативы: TGI, LocalAI, llama.cpp, MLC LLM — и понимать, где они сильны, а где нет

В open-source мире нет одной «лучшей» системы инференса. Есть инструменты под разные слои. Для локального пилота, инженерной станции, R&D и edge-проверки почти всегда удобнее Ollama. Для shared-сервиса, общего API, RAG-шлюза и корпоративного чата почти всегда нужен vLLM или другой серверный движок того же класса. Ошибка начинается в тот момент, когда предприятие пытается не заметить эту границу.

На 20 апреля 2026 года у репозитория ollama/ollama больше 169 тыс. stars, а у vllm-project/vllm — больше 77 тыс. stars (ollama/ollama, vllm-project/vllm). Но популярность тут не главный критерий. Главный критерий — архитектура нагрузки.

Почему Ollama хорош — и где он заканчивается

Ollama хорош по трём причинам.

Во-первых, он убирает почти весь «порог входа». Локальная установка, понятная команда ollama run, REST API на localhost:11434, готовые model manifests и минимальные требования к окружению — именно поэтому он так быстро стал стандартом для демо и пилотов (ollama/ollama).

Во-вторых, он удобен для edge. Если задача живёт на инженерной станции, в лаборатории, на ноутбуке технолога или на отдельной on-prem машине без общего трафика, Ollama часто закрывает её лучше, чем тяжёлый inference-server.

В-третьих, Ollama — это хороший способ быстро проверить связку «модель + промпт + документы + UX», не поднимая сразу платформенный стек.

Но есть обратная сторона: Ollama не проектировался как shared multi-tenant inference layer для серьёзной concurrent-нагрузки. В его официальном README нет обещания про high-concurrency serving, нет механики continuous batching уровня vLLM и нет позиционирования как общего inference-gateway для десятков и сотен одновременных пользователей (ollama/ollama). Поэтому формулировка ниже — это не обвинение, а правильная эксплуатационная граница.

Практический тест простой. Если у вас появилось хотя бы два из четырёх признаков, пора смотреть на vLLM:

• одновременно работают не 1–3, а 10+ пользователей — точный порог зависит от модели и железа, нужна проверка;
• нужен общий OpenAI-совместимый endpoint для нескольких приложений;
• важен предсказуемый throughput на одном или нескольких GPU;
• появляется задача маршрутизации и балансировки между моделями, как в уроке p.2/05 про гибридные архитектуры.

Почему vLLM — это уже сервер, а не просто локальный runtime

У vLLM другая задача. Его официальный README прямо описывает проект как high-throughput и memory-efficient inference engine, а в списке ключевых механизмов указывает PagedAttention — механизм виртуализации KV-cache, continuous batching, prefix caching, параллельность и OpenAI-совместимый API (vllm-project/vllm).

Для production это означает не «чуть быстрее», а другой класс работы с памятью и очередью.

• PagedAttention виртуализирует KV-cache и уменьшает неэффективный расход памяти на длинных и разнотипных запросах (vLLM paper / repo).
• Continuous batching не заставляет ждать, пока один батч закончится полностью; сервер добавляет новые запросы по мере исполнения, что особенно важно для чата и RAG (vllm-project/vllm).
• OpenAI-compatible server даёт возможность переиспользовать клиентский код и ставить vLLM под существующие приложения без полной переделки (vllm-project/vllm).
• Hardware support у проекта уже шире, чем просто NVIDIA: в официальном репозитории и документации перечислены NVIDIA, AMD, CPU и плагины под другие ускорители; в документации отдельно есть таблица поддерживаемого железа и квантованных режимов (repo, docs).

Есть ещё один важный момент. В research-паке фигурирует тезис про 16x throughput у vLLM против Ollama на Blackwell. На 20 апреля 2026 года официальная первичка vLLM публично показывает другой, более аккуратный тезис: до 4x прироста throughput на Blackwell против предыдущего поколения Hopper в совместных benchmark’ах с SemiAnalysis (vLLM blog, 2025-10-09). Сравнение именно vLLM vs Ollama на Blackwell как воспроизводимый официальный benchmark — нужна проверка. При этом независимые тесты 2026 подтверждают значительное превосходство vLLM над Ollama при высокой параллельности: на 10+ concurrent users throughput у vLLM обычно в разы выше.

Decision tree: что брать под конкретную задачу

flowchart TD
    A[Нужно запустить open LLM локально] --> B{Один пользователь или общий сервис?}
    B -->|Один пользователь, ноутбук, edge| C[Ollama или llama.cpp]
    B -->|Общий API, 10+ пользователей| D{Нужен production server?}
    D -->|Да| E[vLLM]
    D -->|HF-центричный старый стек| F[TGI]
    C --> G{Нужен mobile/WebGPU?}
    G -->|Да| H[MLC LLM]
    G -->|Нет| I{Нужен OpenAI-compatible API?}
    I -->|Да| J[LocalAI]
    I -->|Нет| K[Ollama или llama.cpp]

Когда мигрировать с Ollama на vLLM

1. Замерьте не «качество ответа», а профиль нагрузки. Сколько у вас одновременных пользователей, какой средний размер контекста, сколько токенов на ответ, сколько приложений сидит на одной модели.

2. Посчитайте TCO, а не только скорость. Иногда Ollama «дешевле» ровно до момента, пока один GPU не начинают делить пять команд. Дальше стоимость ожидания и деградации UX быстро съедает мнимую экономию — см. урок p.4/01 про ROI.

3. Выделите общий API-слой. Если приложений больше одного, LLM не должна жить вшитой в каждое из них. Нужен единый endpoint, логирование, лимиты, policy, router.

4. Переезжайте сначала на один боевой сценарий. Не нужно сразу тащить весь пилот. Выберите один сервис — например, корпоративный RAG — и вынесите его на vLLM.

5. Оставьте Ollama там, где он силён. На dev-машинах, в лаборатории, на edge-узлах, в автономных сценариях без shared-нагрузки.

Что с альтернативами

TGI

text-generation-inference долго был одной из стандартных open-source систем серверного инференса. Но на 21 марта 2026 года официальный репозиторий Hugging Face помечен как archived, а README прямо говорит, что проект находится в maintenance mode и рекомендует смотреть в сторону vLLM, SGLang, llama.cpp и MLX (huggingface/text-generation-inference). Для новых проектов это не запрет, а сигнал: не стройте ставку на стек, который сам автор уже не двигает как фронтир.

LocalAI

LocalAI полезен там, где вам нужен OpenAI-совместимый API, но нет желания писать свой gateway вокруг llama.cpp или Ollama. Он умеет много бэкендов, поддерживает не только текст, но и голос, vision и image pipelines, и хорошо подходит для компактного self-hosted стека (mudler/LocalAI). Но для тяжёлого shared-throughput он всё равно не заменяет vLLM.

llama.cpp

llama.cpp — фундамент экосистемы GGUF, CPU-инференса и Apple Silicon. Это не «игрушка для энтузиастов», а production-grade библиотека, на которой держатся многие desktop и embedded сценарии. Но это именно low-level runtime, а не корпоративный inference gateway (ggerganov/llama.cpp).

MLC LLM

MLC LLM интересен не цеховому дата-центру, а устройствам: mobile, edge, WebGPU, компиляция модели под целевой runtime. Если у вас сценарий «модель должна жить не на сервере, а на устройстве», MLC стоит знать в лицо (mlc-ai/mlc-llm).

Практическое правило для промышленного проекта

• Ollama — для локального пилота, edge, автономной инженерной машины.
• vLLM — для общего боевого сервиса, RAG, агентных систем и многопользовательского inference.
• TGI — только если вы уже внутри старого стека и понимаете, почему не хотите мигрировать.
• llama.cpp — когда нужен CPU, GGUF, автономность и минимальная зависимость от Python-обвязки.
• LocalAI — когда нужен OpenAI-совместимый API-шлюз без большого platform team.
• MLC LLM — когда endpoint живёт на устройстве, а не в серверной.