С Ollama на vLLM: когда пришло время менять сервер для локальных LLM

Ollama — один из самых простых способов запустить языковую модель на своём компьютере, но есть момент, когда удобство превращается в ограничение. Разбираемся, когда пора переходить на vLLM и как это сделать без потери данных.

Ollama великолепна для одного пользователя и одного GPU — но как только несколько клиентов начинают конкурировать за модель, её простота перестаёт быть достоинством и становится бутылочным горлышком.

Два инструмента — две философии

Ollama и vLLM решают внешне похожие задачи: оба запускают языковые модели локально, оба умеют отдавать API, стримить токены и работать с квантизованными моделями. Но под капотом у них совершенно разная архитектура.

Ollama заточена под удобство: простой CLI, модельная библиотека, минимум настроек. Она идеальна, когда один разработчик отправляет запросы к модели на своём рабочем столе. vLLM — это инференс-движок для обслуживания: здесь реализовано непрерывное батчирование, управление кэшем ключей-значений (KV cache), параллелизм на нескольких GPU, эндпоинты для мониторинга.

Важно понимать: никто не «лучше» другого в абсолютном смысле. Вопрос в том, совпадает ли ваша нагрузка с моделью работы того или иного сервера.

Пять сигналов, что Ollama уже не хватает

Несколько пользователей = нестабильная задержка

Самый частый симптом. Пока вы один — всё летит. Но стоит подключиться трём-четырём клиентам одновременно, и запросы начинают вставать в очередь: время до первого токена скачет, длинный промпт одного пользователя тормозит всех остальных.

Ollama умеет обрабатывать параллельные запросы (параметр OLLAMA_NUM_PARALLEL), но это не бесплатно — память под кэш растёт пропорционально числу параллельных сессий и длине контекста. Конфигурация, спокойно работающая для одного разговора на 8K токенов, может упасть, когда четыре клиента одновременно попросят больший контекст.

vLLM изначально спроектирован для консолидации работы из активных запросов через непрерывное батчирование — новые последовательности подхватываются на лету, завершённые освобождают место.

GPU простаивает, пока запросы ждут в очереди

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

Результат — не обязательно более низкая задержка для каждого отдельного запроса. Но при нагрузке даёт значительно лучшую суммарную пропускную способность и более предсказуемое использование ресурсов.

Длинные промпты тормозят время до первого токена

Ассистенты по коду с длинным контекстом, RAG-пайплайны, агентные сессии — они все постоянно отправляют большие системные промпты или повторяющиеся префиксы документов. Обработка этих входных токенов — этап «префилла» — может доминировать в общем времени ответа.

vLLM поддерживает чанковый префилл и автоматическое кэширование префиксов. Если несколько запросов начинаются одинаково (один и тот же системный промпт, одни и те же определения инструментов, общий префикс документа), результаты префилла переиспользуются, а не пересчитываются заново.

Это особенно ценно, когда запросы содержат:

• Одинаковый длинный системный промпт
• Определения инструментов (tool definitions)
• Стабильное описание репозитория
• Повторяющиеся few-shot примеры
• Общий префикс RAG-документа
• Общую историю разговора

Кэширование префиксов не ускоряет генерацию — оно экономит повторные вычисления. И работает только когда промпты действительно совпадают в начале.

Нужно больше одного GPU

Если модель не помещается в память одной видеокарты — это веский аргумент для vLLM. Он поддерживает тензорный параллелизм между GPU и пайплайновый параллелизм между несколькими узлами.

Это не делает многокартовый инференс тривиальным — пропускная способность шины, топология PCIe, архитектура модели, накладные расходы на коммуникацию всё ещё влияют на производительность. Но vLLM предоставляет осознанный путь к распределённому инференсу, а Ollama обычно лучше подходит для одного десктопа или рабочей станции.

Нужен production-grade мониторинг

Ollama в ответах API отдаёт полезные поля таймингов — время загрузки модели, время обработки промпта, количество сгенерированных токенов. Этого хватает для локального бенчмаркинга.

vLLM предоставляет Prometheus-совместимый эндпоинт /metrics. Это позволяет отслеживать объём запросов, время в очереди, задержку до первого токена, межтокеновую задержку, использование кэша, прерывания, пропускную способность и статусы запросов во времени.

Когда пользователи зависят от вашего сервиса, мониторинг перестаёт быть опцией. Без метрик очереди, кэша и задержек невозможно отличить «GPU слишком мал» от «контекст слишком велик», «планировщик работает плохо» или «просто слишком много одновременных запросов».

Где vLLM выигрывает по-настоящему

Главное преимущество vLLM — не в том, что он генерирует один ответ быстрее Ollama на каждом компьютере. Смысл в том, что он даёт оператору больше механизмов для эффективного использования дорогой памяти и вычислений GPU при множестве запросов.

Непрерывное батчирование — вместо статических батчей, где все запросы должны стартовать и завершаться вместе, vLLM динамически добавляет и убирает последовательности из батча по мере их выполнения. Это критично при неравномерном трафике, когда один пользователь просит короткую классификацию, а другой отправил промпт на 20K токенов.

Страничное управление KV-кэшем (PagedAttention) — кэш ключей-значений хранится блоками, а не в виде непрерывного выделения для каждой последовательности. Это снижает фрагментацию памяти и позволяет более гибко использовать доступный объём. Результат — больше одновременных запросов в том же бюджете памяти.

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

Распараллеливание и распределённый инференс — тензорный, пайплайновый, дата-, экспертный и контекстный параллелизм. Не каждому деплою это нужно, но наличие этих возможностей становится важным, когда сервис перерастает одну видеокарту.

Широкие настройки для продакшена — управление использованием памяти GPU, максимальной длиной модели, количеством активных последовательностей, квантизацией, типами данных кэша, спекулятивным декодированием, вызовом инструментов, структурированным выводом, алиасами моделей, ключами аутентификации. Гибкость даёт возможность точно подстроиться под рабочую нагрузку, но и создаёт больше возможностей для неоптимальной конфигурации.

Где Ollama по-прежнему лучше

Переходный гайд не должен превращать Ollama во «второсортичный инструмент». Для многих локальных сценариев она остаётся лучшим выбором.

Персональные рабочие станции. Один разработчик, чат-интерфейс, код-ассистент, эпизодические локальные API — операционные преимущества vLLM могут никогда не окупить затраты на настройку.

Коллекции GGUF-моделей. У Ollama естественный рабочий процесс с GGUF и Modelfiles. Если вы накопили кастомные квантизации, адаптеры, шаблоны, системные промпты — миграция на vLLM без оценки более нативного формата чекпоинтов может сохранить неудобства перехода, но потерять часть преимуществ в производительности.

Смешанный CPU/GPU оффлоадинг. Если модель не помещается целиком в VRAM и вы частично грузите её в системную память, Ollama или llama.cpp могут быть более подходящим выбором — vLLM наиболее эффективен, когда модель и необходимый кэш помещаются в память акселератора.

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

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

Не мигрируйте только из-за скорости в токенах в секунду

Скорость генерации токенов при одиночном запросе — неполный бенчмарк. Два сервера могут показывать схожую decode-пропускную способность для одного запроса, но вести себя совершенно по-разному с восемью одновременными клиентами.

Корректная оценка должна включать:

• Время до первого токена (TTFT)
• Межтокеновую задержку (ITL)
• Сквозную задержку запроса
• Пропускную способность обработки промптов
• Пропускную способность генерации
• Количество завершённых запросов в минуту
• Время ожидания в очереди
• Потребление VRAM
• Утилизацию GPU
• Частоту ошибок и тайм-аутов

Запускайте одну и ту же модель, точность, длину контекста, набор промптов, ограничение на вывод и уровень конкурентности на обоих серверах. Иначе вы скорее сравниваете упаковку модели и конфигурацию, чем инференс-движки.

Планируйте миграцию модели заранее

Имена моделей в Ollama не маппятся автоматически на идентификаторы vLLM. Ollama-пакет может содержать конкретную GGUF-квантизацию, шаблон промпта, стоп-токены и параметры по умолчанию.

Перед сменой сервера определите:

• Семейство и версию исходной модели
• Базовая она или instruction-tuned
• Текущую квантизацию и эффективную точность
• Шаблон промпта или чата
• Настроенную длину контекста
• Стоп-токены и дефолты генерации
• Требования к tool-calling или структурированному выводу
• Наличие LoRA-адаптеров или кастомных системных промптов

Не предполагайте, что чекпоинт AWQ или FP8 будет вести себя идентично