Когда какой движок выбирать под разные задачи

opensourceithardware
← Back to Blog

Введение: проблема выбора в мире LLM движков

Локальный запуск больших языковых моделей перестал быть уделом энтузиастов и превратился в рутинную задачу для разработчиков, исследователей и инженеров. Однако экосистема породила множество движков: Ollama, llama.cpp, vLLM, TensorRT-LLM, ExLlamaV2, LM Studio, MLC LLM. Каждый из них заточён под разные аппаратные конфигурации, сценарии использования и требования к производительности.

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

Классификация движков по целевой аудитории

Прежде чем погружаться в детали, необходимо понять, что все движки делятся на три большие семьи.

Семья A: Максимальная совместимость с железом (CPU-first)

  • Представители: llama.cpp, MLC LLM
  • Характеристика: работают везде, где есть C++ компилятор. Поддерживают CPU без GPU, AVX инструкции, ARM (включая Apple Silicon), а также GPU как ускорение.
  • Жертва: скорость на чистом GPU ниже оптимизированных решений.

Семья B: Production на NVIDIA GPU (Throughput-first)

  • Представители: vLLM, TensorRT-LLM, TGI
  • Характеристика: Требуют CUDA, используют продвинутые техники (PagedAttention, непрерывное бэтчирование, FP8).
  • Жертва: портативность. Не работают на AMD, Intel GPU (кроме экспериментально).

Семья C: Десктопные однопользовательские сценарии на мощном GPU (Latency-first)

  • Представители: ExLlamaV2, AutoGPTQ, Text Generation WebUI
  • Характеристика: Ориентированы на один запрос, но максимально быстро. Используют все трюки с 4-битной квантизацией.
  • Жертва: масштабируемость. При 10 параллельных запросах деградируют.

Семья D: Удобство и "бесплатный" локальный ChatGPT

  • Представители: Ollama, LM Studio, GPT4All
  • Характеристика: Графический интерфейс или простой CLI. Скачивание моделей из хаба.
  • Жертва: глубокая настройка и экстремальная производительность.

Чек-лист принятия решений

Пройдите последовательно эти проверки.

Шаг 1. Определите ваше железо

Железо Явный выбор Почему
Apple M1/M2/M3 (8-128 ГБ unified) llama.cpp (Metal) Лучшая оптимизация под Metal, 80-90% теоретической пропускной способности памяти
Старый ноутбук на Intel/AMD без дискретного GPU llama.cpp (CPU) Поддержка AVX2/AVX512, нет альтернатив
NVIDIA RTX 3060/4060 (8-12 ГБ) ExLlamaV2 или Ollama Оба хорошо работают с 4-битными моделями 7B-13B
NVIDIA RTX 4090 / A6000 (24+ ГБ) vLLM Можно выжать 200-300 токен/с на модели 7B
2-8 GPU NVIDIA в сервере vLLM (tensor parallel) или TensorRT-LLM Только они умеют эффективно разбивать модель
AMD Radeon (ROCm совместимая) llama.cpp (ROCm) или MLC LLM vLLM не работает стабильно
Intel Arc GPU llama.cpp (SYCL) или IPEX-LLM Слабая поддержка, только экспериментальные бинарды

Шаг 2. Определите сценарий использования

Сценарий Выбор первого эшелона Запасной вариант
API для мобильного приложения (500 RPS) vLLM + TensorRT-LLM TGI от Hugging Face
Локальный чат для одного пользователя Ollama или LM Studio ExLlamaV2 в WebUI
Пакетная обработка тысячи документов (офлайн) vLLM (batch режим) llama.cpp (server режим)
Встраиваемое устройство (Raspberry Pi 5) llama.cpp (однопоточный) MLC LLM (через TVM)
Обучение и тонкая настройка с последующим экспортом Выбрать движок после обучения Стандарт: Hugging Face + PEFT
RAG система с большими промптами (32K токенов) vLLM (prefix caching) llama.cpp с rope scaling

Шаг 3. Учитывайте дополнительные ограничения

  • Требуется авторизация и API ключи? Ollama и vLLM (OpenAI-совместимый слой) дают готовый middleware.
  • Нужна строгая приватность (данные не покидают офис)? Любой локальный движок, но проще всего Ollama или llama.cpp.
  • Модель в формате GGUF? Работает только в llama.cpp и Ollama (который использует ту же библиотеку).
  • Модель в формате Hugging Face? Работает везде, но лучше конвертировать в GGUF для CPU или использовать vLLM для GPU.
  • Вы пишете на Go или Rust? llama.cpp имеет C API с биндингами, у Ollama есть HTTP API.
  • Вы пишете на Python? Все движки предоставляют Python интерфейс, но vLLM самый нативный.

Глубокое сравнение по характеристикам

Производительность (токенов в секунду) для модели Llama 3 8B на RTX 4090

Движок Квантизация Batch Size = 1 Batch Size = 32
vLLM FP16 140 1200 (суммарно)
vLLM INT8 (AWQ) 180 1500
TensorRT-LLM FP16 200 1800
ExLlamaV2 4-bit (GPTQ) 190 450 (деградация)
llama.cpp (CUDA) Q4_K_M 130 300
Ollama (CUDA) Q4_K_M 120 250

Вывод: Для одного запроса разница между TensorRT-LLM и Ollama в 1.5 раза. Для 32 параллельных запросов TensorRT-LLM быстрее Ollama в 7 раз.

Потребление памяти

Модель Движок Квантизация VRAM (ГБ) RAM (ГБ)
Llama 3 70B vLLM FP8 70 5
Llama 3 70B llama.cpp Q4_K_M 0 (CPU) 45
Llama 3 70B llama.cpp Q4_K_M (GPU offload 20 слоев) 18 30
Mistral 7B ExLlamaV2 4-bit 4.2 2
Mistral 7B vLLM FP16 14 3

Вывод: llama.cpp позволяет запустить 70B модель на десктопе с 64 ГБ RAM без GPU. vLLM требует дорогого GPU с 80 ГБ VRAM.

Когда использовать неочевидные движки

ExLlamaV2 вместо vLLM

  • Ситуация: Вы на десктопе с RTX 4090, у вас одна задача — генерировать длинные тексты (тысячи токенов) максимально быстро, без параллельных запросов.
  • Почему: ExLlamaV2 имеет лучшую реализацию 4-битных матричных умножений, а vLLM оптимизирован для бэтча, а не для одного большого контекста.
  • Результат: ExLlamaV2 даст 190 токен/с против 140 у vLLM.

TensorRT-LLM вместо vLLM

  • Ситуация: Вы разворачиваете продакшн на выделенных серверах с NVIDIA и готовы потратить день на оптимизацию.
  • Почему: TensorRT-LLM от NVIDIA даёт максимальную скорость за счёт сведения графа вычислений и использования специфических инструкций на уровне ядер.
  • Результат: На 30-50% выше throughput, чем vLLM, но сложность интеграции выше.

MLC LLM вместо llama.cpp

  • Ситуация: Вам нужно запустить модель на телефоне (Android/iOS) или в браузере через WebGPU.
  • Почему: MLC LLM использует Apache TVM для компиляции модели в бинарный код под конкретную платформу, включая мобильные GPU и WebGPU.
  • Результат: На iPhone 15 Pro можно получить 20-30 токен/с на модели 3B, что невозможно с llama.cpp (нет Metal на iOS).

Text Generation Inference (TGI) от Hugging Face

  • Ситуация: Вы уже используете экосистему Hugging Face (transformers, PEFT, accelerate) и не хотите изучать новые форматы.
  • Почему: TGI понимает любую модель из хаба, поддерживает Flash Attention v2, непрерывное бэтчирование и токенизацию на Rust.
  • Результат: Производительность между vLLM и TGI сопоставима, но TGI проще вписать в существующий пайплайн.

Антипаттерны — что никогда не стоит делать

1. Запускать vLLM на MacBook с M-серией Проблема: vLLM требует CUDA; код падает на этапе импорта torch. На CPU режиме производительность падает в 200 раз. Альтернатива: llama.cpp с Metal.

2. Использовать Ollama для production API с 50+ пользователями Проблема: Ollama не имеет нормального бэтчирования, каждый запрос обрабатывается последовательно. При параллельных запросах время ответа растёт линейно. Альтернатива: vLLM или TGI.

3. Запускать модель в Hugging Face transformers (без оптимизаций) на сервере с GPU Проблема: Стандартный model.generate() использует naive кэширование, фрагментирует память и имеет throughput в 10 раз ниже vLLM. Альтернатива: Заменить transformers на vLLM без изменения модели.

4. Собирать llama.cpp с CPU инструкциями по умолчанию Проблема: Если не указать флаги -DLLAMA_AVX2=ON -DLLAMA_FMA=ON, производительность на современном CPU упадёт в 3-5 раз. Альтернатива: Всегда проверять логи компиляции на наличие AVX2 found.

5. Квантовать модель в 2 бита (Q2_K или IQ1) для серьезных задач Проблема: Потеря качества (perplexity) настолько велика, что модель начинает галлюцинировать на простых вопросах. Альтернатива: Q4_K_M (минимальный порог для production) или Q5_K_M/Q6_K.

Итоговые рекомендации по проектам

Проект 1: Чат-бот для поддержки внутри компании (100-200 сотрудников)

  • железо: Один NVIDIA L4 (24 ГБ) или RTX 4090
  • движок: vLLM с моделью Mistral-7B-Instruct в INT8
  • конфигурация: --max-num-seqs 128 --enable-prefix-caching

Проект 2: RAG система для анализа юридических документов (длинные контексты до 32К)

  • железо: NVIDIA A100 (40 ГБ) или 2x RTX 4090
  • движок: vLLM с tensor parallel
  • конфигурация: --tensor-parallel-size 2 --max-model-len 32768

Проект 3: Персональный ассистент на ноутбуке Data Scientist (Windows с RTX 4060 8 ГБ)

  • железо: RTX 4060 + 32 ГБ RAM
  • движок: ExLlamaV2 через Text Generation WebUI
  • модель: CodeLlama-7B-Python или Mistral-7B в 4-bit GPTQ

Проект 4: Образовательный курс по LLM (нужно запустить на любых ноутбуках студентов)

  • железо: Любой ноутбук за последние 5 лет (даже без GPU)
  • движок: llama.cpp (предварительно скомпилированный бинарник для Windows/Mac/Linux)
  • модель: TinyLlama-1.1B в Q4_K_M (умещается в 2 ГБ RAM)

Проект 5: Офлайн переводчик на корабле без интернета (встроенный Linux, ARM)

  • железо: Raspberry Pi 5 или Orange Pi 5 (8 ГБ RAM)
  • движок: MLC LLM (компиляция в статический бинарник)
  • модель: NLLB-200 600M или Madlad-400

Заключение

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

Для практического решения используйте следующее правило: начните с llama.cpp для прототипа (работает везде), затем замените на vLLM для production нагрузки на GPU, или оставайтесь на llama.cpp для CPU/Apple Silicon. Ollama подходит для разработки и тестирования, но не для продакшн-масштабирования.

Держите в запасе ExLlamaV2 для однопользовательских сценариев на мощном GPU и MLC LLM для мобильных вещей. Главное — не привязывайтесь жёстко к одному движку на этапе архитектуры: все современные инструменты умеют читать одну и ту же модель в разных форматах.