VLLM против Llama.cpp против Ollama: битва движков для Open WebUI на RTX 3090

RTX 3090, 92 ГБ RAM и три движка: какой выживет в реальном бою?

Ты купил RTX 3090 за 24 ГБ VRAM. Поставил Open WebUI. Радостно начинаешь грузить Qwen 32B. И тут понимаешь: выбор движка — это не техническая деталь, а философский вопрос, от которого зависит, будешь ты пить кофе или перезагружать сервер каждые полчаса.

AMD Ryzen 9, RTX 3090, 92 ГБ RAM — звучит мощно. До тех пор, пока не пытаешься запустить две модели одновременно с hot-swap. Тут начинается настоящее веселье.

Почему твой RTX 3090 плачет: анатомия проблемы

24 ГБ VRAM — много? Для 2026 года — уже нет. Особенно когда пытаешься запихнуть туда Qwen2.5 32B в 4-битной квантованности (нужно около 20 ГБ), оставив место для контекста и параллельных запросов.

Добавь сюда желание переключаться между моделями без перезагрузки сервера. И возможность работать нескольким пользователям одновременно. И чтобы всё это не падало при первом же запросе на сложную логику.

Три кандидата выходят на ринг: vLLM, Llama.cpp и Ollama. Каждый обещает быть лучшим. Каждый лжёт. По-своему.

VLLM: гоночный болид, который не умеет поворачивать

vLLM — это как Ferrari в мире LLM-движков. Быстро? Безумно. Эффективно использует память? Да. Подходит для продакшена? Идеально.

Но есть нюанс. Вернее, несколько.

Что vLLM делает гениально

• PagedAttention — технология, которая экономит память как скупердяй. Вместо выделения памяти под весь контекст сразу, vLLM выделяет её постранично. Результат: можно загружать модели большего размера.
• Continuous batching — обрабатывает запросы не пачками, а непрерывно. Новый запрос пришёл — добавили в батч. Старый завершился — освободили ресурсы. Для многопользовательского сценария это золото.
• OpenAI-совместимый API — подключаешь Open WebUI за пять минут, никаких танцев с бубном.

Где vLLM спотыкается на RTX 3090

Запускаешь vLLM с Qwen2.5 32B Q4_K_M:

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-32B-Instruct-GPTQ-Int4 \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192

Всё работает. До тех пор, пока не пытаешься загрузить вторую модель. vLLM не поддерживает hot-swap из коробки. Нужны костыли в виде отдельных инстансов на разных портах. Или ждать, пока разработчики добавят эту фичу (на 05.02.2026 всё ещё в планах).

Ещё один подводный камень: vLLM жрёт память под свои внутренние структуры. Те самые 0.9 от gpu-memory-utilization — это не только модель. Это ещё и кэш, и буферы, и служебные данные. На практике для Qwen 32B остаётся около 2-3 ГБ свободной VRAM под контекст. Мало.

Llama.cpp: швейцарский нож, который точит сам себя

Если vLLM — Ferrari, то Llama.cpp — это Land Rover Defender. Медленнее на прямой? Да. Зато проедет там, где другие сломаются.

Особенность Llama.cpp в его архитектуре. Это не сервер в классическом понимании. Это библиотека для инференса, вокруг которой нужно строить свою инфраструктуру.

Почему Llama.cpp обожают энтузиасты

• Поддержка всего и вся — CPU, GPU, смешанный режим. Даже если у тебя только 8 ГБ VRAM, можешь догрузить модель в оперативку.
• Квантование до 2 бит — там, где vLLM говорит "нет", Llama.cpp спрашивает "сколько бит тебе отрезать?".
• Hot-swap из коробки — выгрузил модель, загрузил другую. Без перезапуска сервера.

Конфигурация для Open WebUI через llama-cpp-python:

# Пример запуска с поддержкой hot-swap
from llama_cpp import Llama

llm = Llama(
    model_path="./models/qwen2.5-32b-q4_k_m.gguf",
    n_gpu_layers=-1,  # Все слои на GPU
    n_ctx=8192,
    n_batch=512,
    n_threads=8,
    verbose=False
)

Проблема в том, что Llama.cpp не даёт тебе готовый сервер. Нужно писать обёртку. Или использовать сторонние решения вроде llama-cpp-python с его OpenAI-совместимым API.

Тёмная сторона Llama.cpp

Continuous batching? В базовой версии — нет. Нужно использовать специальные сборки или патчи. Многопользовательский доступ? Только если сам реализуешь очередь запросов.

Скорость. На RTX 3090 с Qwen 32B Q4_K_M Llama.cpp показывает около 15-20 токенов в секунду. vLLM в тех же условиях — 25-35. Разница ощутима.

Ollama: магия, которая работает пока не сломается

Ollama — это Docker для LLM. Установил, запустил команду, получил работающую модель. Никаких конфигураций, компиляций, танцев с CUDA.

Команда для запуска Qwen 32B:

ollama run qwen2.5:32b

Всё. Сервер запущен, API доступен. Open WebUI подключается за секунды. Hot-swap? Есть. Просто запускаешь другую модель — предыдущая выгружается.

Вот только за эту простоту приходится платить.

Что Ollama скрывает под капотом

Ollama использует собственную реализацию инференса на основе llama.cpp. Но с ограничениями:

• Нет тонкой настройки параметров GPU
• Ограниченный контроль над распределением памяти
• Свои, иногда странные, настройки квантования по умолчанию

На RTX 3090 Ollama с Qwen 32B ведёт себя предсказуемо: загружает модель, работает. Но если попытаться поднять вторую модель параллельно (через отдельный инстанс), начинаются проблемы с памятью.

Ollama не умеет эффективно делить VRAM между несколькими моделями. Каждая модель думает, что она одна в системе. Результат — CUDA out of memory.

Реальные цифры: тест на выживание

Цифры говорят сами за себя. Но они не рассказывают всей истории.

Сценарии использования: когда что выбирать

Сценарий 1: Домашний сервер для экспериментов

Хочешь поиграться с разными моделями, быстро переключаться между ними, не париться с настройками.

Выбор: Ollama

Причина: простота установки, встроенный hot-swap, автоматическое управление моделями. Запустил и забыл.

Конфигурация для Open WebUI:

# docker-compose.yml для Open WebUI + Ollama
version: '3.8'

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    depends_on:
      - ollama

  ollama:
    image: ollama/ollama:latest
    ports:
      - "11434:11434"
    volumes:
      - ./ollama:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

Сценарий 2: Продакшен с несколькими пользователями

Нужно обслуживать 5-10 пользователей одновременно, важен отклик, стабильность важнее возможности быстрого переключения моделей.

Выбор: vLLM

Причина: continuous batching, эффективное использование памяти, готовый продакшен-грэйд API.

Но как быть с hot-swap? Придётся использовать хак:

# Запуск нескольких инстансов vLLM на разных портах
# Первая модель
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-32B-Instruct-GPTQ-Int4 \
  --port 8001 \
  --gpu-memory-utilization 0.45 &

# Вторая модель
python -m vllm.entrypoints.openai.api_server \
  --model mistralai/Mistral-7B-Instruct-v0.3 \
  --port 8002 \
  --gpu-memory-utilization 0.45 &

Да, это костыль. Да, это тратит больше памяти на служебные структуры. Но это работает.

Сценарий 3: Максимальная гибкость и контроль

Готов писать код, настраивать каждый параметр, собирать свой велосипед, но получить полный контроль над системой.

Выбор: Llama.cpp + собственная обёртка

Причина: полный контроль над памятью, возможность тонкой настройки под конкретное железо, поддержка экзотических квантований.

Пример минимальной обёртки для hot-swap:

import threading
from llama_cpp import Llama

class ModelManager:
    def __init__(self):
        self.current_model = None
        self.lock = threading.Lock()
    
    def load_model(self, model_path):
        with self.lock:
            if self.current_model:
                del self.current_model
            
            self.current_model = Llama(
                model_path=model_path,
                n_gpu_layers=-1,
                n_ctx=8192,
                n_batch=512,
                n_threads=8,
                verbose=False
            )
    
    def generate(self, prompt):
        with self.lock:
            if not self.current_model:
                raise ValueError("No model loaded")
            return self.current_model(prompt)

Гибридный подход: когда одного движка мало

А что если использовать лучшее от каждого мира? На RTX 3090 с его 24 ГБ VRAM можно реализовать интересную схему:

1. Основная модель (Qwen 32B) работает на vLLM для быстрого многопользовательского доступа
2. Вторая, меньшая модель (например, Qwen2.5 7B) живёт в Ollama для быстрого hot-swap
3. Тяжёлые экспериментальные модели запускаются через Llama.cpp по требованию

Это требует ручного управления памятью, но даёт максимальную гибкость. Главное — следить, чтобы суммарное потребление VRAM не превышало 24 ГБ.

Ошибки, которые сломают твой сервер

Ошибка 1: Доверять автоматическому распределению памяти

И vLLM, и Ollama пытаются сами решать, сколько памяти выделить. На RTX 3090 они часто ошибаются в худшую сторону — выделяют слишком много, не оставляя места для контекста.

Решение: всегда явно указывай лимиты. Для vLLM — --gpu-memory-utilization 0.85. Для Ollama — через переменные окружения OLLAMA_NUM_GPU и OLLAMA_GPU_LAYERS.

Ошибка 2: Использовать стандартные квантования

Q4_K_M — это не всегда оптимально. Для Qwen 32B на RTX 3090 иногда лучше работает Q5_K_M — чуть больше памяти, но значительно лучше качество.

Экспериментируй. Загрузи одну и ту же модель в разных квантованиях, проверь скорость и качество ответов.

Ошибка 3: Забывать про системную память

92 ГБ RAM — это хорошо. Но если ты запускаешь модель, которая не помещается в VRAM, llama.cpp начнёт использовать оперативку. И если одновременно работает ещё что-то (база данных, веб-сервер), система начнёт свопиться.

Решение: используй ulimit и cgroups для ограничения потребления памяти процессами.

Что будет через год?

На 05.02.2026 ситуация стабильна, но меняется. vLLM обещает нативную поддержку нескольких моделей. Ollama работает над улучшением управления памятью. Llama.cpp оптимизируется под новые архитектуры GPU.

Мой прогноз: к концу 2026 мы увидим движки, которые объединят скорость vLLM, гибкость llama.cpp и простоту Ollama. А пока — выбирай исходя из своих конкретных задач.

Если нужна скорость и стабильность для команды — vLLM с костылями для hot-swap. Если экспериментируешь в одиночку — Ollama. Если готов копаться в коде ради максимального контроля — llama.cpp.

И помни: не существует идеального движка. Есть движок, который меньше всего мешает тебе работать.