Сравнение инференс-движков

Движок — это программа, превращающая веса в токены: она загружает файл, прогоняет прямой проход трансформера и обычно сверху говорит по HTTP. Хорошая новость: почти каждый движок гоняет одну и ту же модель примерно с одной скоростью на одном железе — выбор движка про воркфлоу, поддержку форматов и параллелизм, а не про сырой tok/s. Плохая новость та же: шопинг по бенчмаркам между ними — в основном потраченное усилие.

Поле

Заметка о родословной: Ollama и LM Studio оба гоняют llama.cpp под капотом. Сравнение их с llama.cpp — сравнение упаковки, а не инференса.

Также полезно знать: llama.cpp поставляет больше, чем сервер — инструменты квантизации и конверсии, бенчмарк-каркас и биндинги для дюжины языков.

Глубокие разрезы

vLLM родился из озарения paged attention (см. параллелизм): обращайтесь с памятью GPU так, как ОС обращается с RAM — и влезает куда больше запросов. Это ответ по умолчанию на «у меня GPU-сервер и реальный трафик».

SGLang кэширует префиксы между запросами (RadixAttention): если 40 агентов делят один и тот же двухстраничный системный промпт, он обрабатывается один раз, а не 40. Также известен быстрым ограниченным декодированием — см. структурированный вывод.

exllamav2 — острый край ровно для одной ниши: один пользователь на одной NVIDIA GPU, желающий максимум tok/s на бит квантизации. Серверная история и широта железа тонкие; ниша реальна.

MLX — ML-фреймворк Apple, построенный под единую память. На момент написания mlx-lm часто обгоняет Metal-путь llama.cpp на крупных моделях — достаточно близко, чтобы на Mac стоило попробовать оба (подробнее в Apple Silicon).

transformers — медленный, верный референс: когда квантованный движок делает что-то странное, прогон той же модели через него отвечает на вопрос «это движок или модель?». Это также труба под инструментами дообучения (см. дообучение).

Выбирайте по потребности

Две заметки к таблице:

• «Начните с» — не «остановитесь на»: каждый десктопный движок читает тот же GGUF, поэтому попробовать второй стоит пять минут, а не миграцию.
• Когда всё же сравниваете, держите всё постоянным: одна модель, один квант, один промпт, модель уже прогрета.

Разделение форматов отражает разделение десктоп/сервер

GGUF против safetensors (см. форматы моделей) — не просто предпочтение контейнера: оно определяет ваш движок. GGUF — однофайловый, предквантованный, везде-работающий формат, и вся десктопная экосистема (llama.cpp, Ollama, LM Studio) построена на нём. safetensors — формат шардированных тензоров экосистемы Hugging Face; высокопроизводительные серверные движки (vLLM, SGLang, transformers) потребляют его, обычно квантуя на лету (варианты AWQ/GPTQ), а не предупакованным.

Так что настоящее дерево решений короткое: десктоп и один пользователь → GGUF-движки; сервер и параллелизм → safetensors-движки. Всё остальное — детали.

Когда что-то «не запускается», первым делом проверьте формат — половина случаев «движок X не может запустить модель Y» это несовпадение GGUF/safetensors, а не пробел в возможностях.

Накладные расходы — не история

На одинаковом железе с одинаковым квантом движки попадают примерно в 10–20% друг от друга для однопоточного декодирования — часто потому, что делят бэкенд. Что реально двигает вашу ощущаемую скорость в разы, а не на проценты:

• Загружена ли уже модель — холодная загрузка стоит от секунд до минуты.
• Пересылается ли весь разговор каждую реплику — стоимость контекста, см. токены.
• Выстраиваются ли запросы друг за другом — см. параллелизм.
• Сидят ли слои на GPU — см. параметры движка.

Та же GPU, та же 8B Q4_K_M, один поток (иллюстративно, не спеки):
llama.cpp / Ollama / LM Studio    ~130–145 tok/s   (один движок под капотом)
exllamav2 EXL2 ~4bpw              ~160–180 tok/s   (загрузчик, заточенный под декодирование)

Та же GPU, 8 одновременных чат-потоков:
llama-server serial queue         каждый поток ждёт; суммарная пропускная способность плоская
vLLM                              все потоки почти на однопоточной скорости

Выберите движок под ваш воркфлоу, затем тратьте энергию на паттерны ввода-вывода, а не на бенчмарки движков.

Один файл, много движков

GGUF, скачанный для Ollama, запускается и в llama.cpp напрямую, и в LM Studio — движки не конвертируют и не перекачивают; вы указываете им на тот же файл (Ollama умеет импортировать локальный путь однострочным Modelfile). То же серверно для safetensors между vLLM и SGLang. Практическое следствие: файловой привязки к вендору нет, а ошибка в выборе движка стоит вам минуты.

Вот почему эта страница всё время толкает воркфлоу вместо бенчмарков: когда ваши потребности меняются, уже скачанные модели переезжают с вами.

Когда перерасти Ollama

Дефолты Ollama превосходны, пока не перестают. Переходите к движку обслуживания, когда:

• Вам нужен устойчивый параллелизм сверх нескольких потоков (см. параллелизм).
• Вы хотите кэширование префиксов для многих агентов с общим системным промптом (SGLang).
• Вам нужно обслуживать AWQ/GPTQ safetensors-кванты напрямую из экосистемы HF.
• Вы тестируете нагрузку на фичу продукта перед релизом.
• Вам нужен тензорный параллелизм на мульти-GPU, чтобы уложить одну большую модель на карты.

Пока одно из этого не верно, удобство стоит больше пропускной способности.

Связанные разделы: форматы моделей · параметры движка · развёртывание эндпоинта · выбор модели