Когда вы поднимаете нейросеть локально, первый развилочный вопрос — на каком движке. Два самых ходовых варианта: vLLM и llama.cpp. Оба поднимают OpenAI-совместимый сервер, к которому одинаково подключается и чат, и агент, и интеграция с 1С, — но ведут себя под нагрузкой совершенно по-разному. Я прогнал оба движка на одном и том же железе (от RTX 5060 Ti до Tesla V100) на модели Qwen3-4B и замерил скорость. Вывод короткий: для одного пользователя разница почти не важна, а под параллельной нагрузкой vLLM обгоняет llama.cpp в 1.5–2.7 раза. Ниже — цифры и понятное правило, что брать под вашу задачу.
Чем эти движки различаются по сути
Прежде чем смотреть на ток/сек, стоит понять, откуда берётся разница — она не случайна, а заложена в архитектуре.
llama.cpp вырос из идеи «запустить LLM где угодно, хоть на ноутбуке без видеокарты». Он работает с квантованными моделями в формате GGUF, умеет раскладывать модель между GPU и CPU, ставится буквально одной сборкой и не тянет тяжёлого окружения. Это движок «включил и работает»: минимум зависимостей, скромные требования к памяти, отличная поддержка потребительского железа.
vLLM проектировался под другой сценарий — сервер, который держит поток запросов. Его ключевые механизмы, PagedAttention и continuous batching, позволяют эффективно обслуживать много одновременных генераций, переиспользуя память и не простаивая между запросами. За это приходится платить: vLLM требует более серьёзного окружения (CUDA, Python-стек), любит полновесные или AWQ-модели и разворачивается сложнее.
Отсюда и вся разница в замерах: llama.cpp оптимизирован под «один запрос за другим», vLLM — под «много запросов сразу».
Скорость на одиночном запросе: llama.cpp не отстаёт
Начнём с последовательной генерации — один запрос за другим, как в личном чате. Токенов в секунду на Qwen3-4B:
| GPU | vLLM | llama.cpp |
|---|---|---|
| RTX 5070 Ti ×1 | 90 | 90 |
| RTX 3090 ×1 | 84 | 91 |
| Tesla V100 ×1 | 67 | 82 |
| RTX 5060 Ti ×1 | 48 | 48 |
Неожиданно, да? На одиночной генерации llama.cpp не только не отстаёт, но местами обгоняет — на RTX 3090 и особенно на Tesla V100 он заметно быстрее vLLM. Причина в том, что vLLM платит накладными расходами за свою серверную машинерию, которая на одном запросе просто не нужна, а llama.cpp работает налегке. Для сценария «локальный ассистент для меня одного» это важный вывод: тяжёлый vLLM вам, скорее всего, не нужен, а на старых картах он даже проиграет.
Скорость под нагрузкой: здесь vLLM отрывается
Теперь дадим серверу 10 одновременных запросов и посмотрим на суммарную пропускную способность (throughput) — это то, что важно, когда модель обслуживает не вас одного, а сервис, агента или несколько пользователей:
| GPU | vLLM | llama.cpp | vLLM быстрее в |
|---|---|---|---|
| RTX 5060 Ti ×1 | 263 | 98 | 2.7× |
| RTX 5070 Ti ×2 | 672 | 262 | 2.6× |
| RTX 5060 Ti ×2 | 414 | 156 | 2.6× |
| RTX 5070 Ti ×1 | 481 | 292 | 1.6× |
| RTX 3090 ×1 | 419 | 263 | 1.6× |
| Tesla V100 ×1 | 284 | 190 | 1.5× |
Картина переворачивается полностью. Под параллельной нагрузкой vLLM выигрывает везде — от полутора до почти трёх раз. Тот же самый RTX 3090, который на одиночном запросе был быстрее с llama.cpp (91 против 84), под нагрузкой отдаёт с vLLM 419 ток/с против 263 — в полтора раза больше. А на RTX 5060 Ti разрыв достигает 2.7 раза. Это и есть цена continuous batching: llama.cpp обрабатывает параллельные запросы куда менее эффективно и захлёбывается там, где vLLM продолжает наращивать выработку.
Память и квантизация: где llama.cpp экономнее
Скорость — не единственная ось. По памяти движки тоже разные:
- llama.cpp работает с GGUF-квантами (Q4, Q6, Q8), которые занимают в 2–4 раза меньше видеопамяти, чем полновесная модель. На карте с 16 ГБ это значит, что через llama.cpp вы запустите более крупную модель, чем через vLLM в полной точности. Плюс он умеет выгружать часть слоёв на CPU — медленно, но работает даже когда модель в VRAM не влезает.
- vLLM традиционно ориентирован на полновесные веса или AWQ-квантизацию. Он тоже умеет в квантованные модели, но настроек и подводных камней здесь больше, а экономия памяти обычно скромнее, чем у GGUF.
Простое правило: если упираетесь в видеопамять и готовы пожертвовать точностью ради того, чтобы модель вообще влезла, — llama.cpp с GGUF гибче. Если памяти хватает и нужна максимальная пропускная способность — vLLM.
Порог входа и эксплуатация
Ещё одно различие, которое не видно в таблицах, но сильно влияет на выбор на практике:
- llama.cpp ставится просто: скачал сборку (или собрал под свою CUDA), скормил GGUF-файл, запустил
llama-server. Минимум зависимостей, легко на Windows, легко на слабом железе, легко объяснить новичку. - vLLM требует аккуратного Python-окружения, подходящей версии CUDA и совместимых драйверов; на нестандартном железе (например, старой Tesla V100) его порой приходится собирать из специализированных форков. Зато на выходе — production-grade сервер с метриками и эффективным батчингом.
То есть выбор — это ещё и вопрос «сколько времени вы готовы потратить на инфраструктуру». Для быстрого эксперимента на своей машине llama.cpp обгонит vLLM по времени «до первого ответа модели», даже если проиграет в ток/сек под нагрузкой.
Итог: простое правило выбора
- Берите llama.cpp, если: запускаете модель для себя или небольшой команды, важна простота установки, работаете на потребительском или старом железе, упираетесь в видеопамять (GGUF-кванты экономнее). Для одиночного запроса он не медленнее, а иногда и быстрее.
- Берите vLLM, если: поднимаете сервер под поток запросов, строите агента или сервис с параллельной нагрузкой, используете структурированный вывод, и у вас есть время на настройку окружения. Под нагрузкой он даёт в 1.5–2.7 раза больше пропускной способности.
- Ollama (частый третий вариант в запросах) — это, по сути, удобная обёртка над тем же llama.cpp: она проще в управлении моделями, но по потолку производительности наследует ограничения llama.cpp, а не догоняет vLLM.
И помните, что движок — только половина уравнения; вторая половина — железо. Как те же движки ведут себя на разных картах и какую видеокарту брать под задачу, я разобрал в статье RTX 5070 Ti vs RTX 3090 для LLM.
Локальный сервер с LLM — это фундамент, но ценность появляется, когда модель встроена в рабочий процесс: читает документы, отвечает клиентам, заполняет данные в 1С. Как довести дело до работающей интеграции — в курсе «Применение искусственного интеллекта ChatGPT для 1С»: от локального движка до агента внутри вашей учётной системы.