# vLLM или llama.cpp: какой сервер выбрать под модель и нагрузку

Источник: https://modelium.tech/zhurnal/vllm-ili-llama-cpp/

Выбирайте не абстрактно «самый быстрый» сервер, а маршрут для своего формата модели, устройства и нагрузки. llama.cpp предлагает нативный GGUF, CPU и частичное размещение на GPU; vLLM предлагает серверную раздачу модели и отдельные GPU-пути, а GGUF у него требует экспериментального плагина. Оба предоставляют Chat Completions API, но скорость и память на вашей системе нужно проверять сопоставимыми запросами.

**Срез 5 октября 2026 года:** официальные репозитории vLLM `f98d1fc` и llama.cpp `a7fb71f`. Это сопоставление документированных возможностей, **не** собственный тест скорости Modelium [s1](#src-s1)[s6](#src-s6). Частотность «vllm vs llama cpp» не измерена.

## vLLM или llama.cpp: короткое решение

Если у вас уже есть GGUF и нужен запуск на CPU, Mac или с частичным переносом слоёв на GPU, начните с llama.cpp: у проекта есть эти пути и локальный HTTP-сервер [s5](#src-s5)[s6](#src-s6). Если вы обслуживаете совместимый checkpoint в Linux на подходящем GPU и хотите проверять серверную нагрузку через OpenAI-совместимый API, начните с vLLM; конкретный GPU и формат проверьте по его платформенной инструкции [s1](#src-s1)[s2](#src-s2). **Ни один из этих критериев не доказывает, что один runtime быстрее другого на вашей машине.**

Оба сервера предлагают `/v1/chat/completions` и параллельную обработку, поэтому формула «llama.cpp — только для одного пользователя, vLLM — для нескольких» неверна: README llama-server описывает серверные слоты и continuous batching [s1](#src-s1)[s6](#src-s6). Отличаются маршрут модели, бэкенды и поведение на реальной нагрузке; решение принимайте после успешного ответа и сопоставимого замера, а не по чужому throughput.

## Как выбрать по формату модели?

**GGUF:** llama.cpp прямо документирует загрузку локального файла через `-m, --model` и квантованные модели; это обычный маршрут этого проекта [s5](#src-s5)[s6](#src-s6). vLLM тоже может использовать GGUF, но на зафиксированном срезе его документация требует внешний `vllm-gguf-plugin` и прямо предупреждает об экспериментальном статусе и возможной несовместимости с другими функциями. Для GGUF она рекомендует tokenizer исходной модели; это не тот же простой путь, что основной запуск из vLLM quickstart [s3](#src-s3)[s1](#src-s1). Если выбран GGUF, изучите [отдельный разбор плагина](/zhurnal/vllm-gguf-plugin/) до установки.

**Исходный checkpoint:** quickstart vLLM показывает `vllm serve Qwen/Qwen2.5-1.5B-Instruct`; это демонстрация интерфейса, а не гарантия для любой модели, лицензии или видеокарты [s1](#src-s1). У llama-server можно указать конкретный GGUF-файл, а вариант `--hf-repo` выбирает квантование; репозиторий и файл нужно фиксировать, а не полагаться на меняющийся default [s6](#src-s6). Для честного сравнения берите одну архитектуру и ревизию исходных весов, фиксируйте процедуру GGUF-конвертации и квантования, tokenizer и chat template. Даже тогда квантование меняет численное представление: **сравнение разных файлов — это сравнение целого стека**, а не чистый тест двух движков.

Размер GGUF или safetensors-файла **не равен** требуемой RAM или VRAM: дополнительно расходуются KV-кеш, буферы и память на одновременные запросы. `--n-gpu-layers` у llama-server задаёт перенос слоёв на GPU, а `--ctx-size` и `--parallel` меняют профиль; фактическое размещение проверяйте в логах своей версии [s6](#src-s6). При планировании бюджета откройте [методику оценки памяти](/zhurnal/videokarta-dlya-llm/), не превращая чужой тестовый компьютер в минимальное требование.

## На каком железе и ОС начать?

Для vLLM quickstart основным маршрутом указывает Linux и Python 3.10–3.13; его GPU-инструкция разделяет NVIDIA CUDA, AMD ROCm, Intel XPU и Apple Silicon, причём последний идёт через отдельный vLLM-Metal. Нативный Windows в этой инструкции не поддерживается, предложен путь через WSL при совместимом окружении [s1](#src-s1)[s2](#src-s2). Это не означает, что любой перечисленный GPU запустит любую модель или квантование. Не переносите требования одного backend на другой.

У llama.cpp документированы сборка на CPU, Metal, CUDA, HIP и Vulkan, а также гибридное размещение CPU+GPU. Build guide отдельно описывает Windows и соответствующие сборки; CPU-доступность не обещает приемлемую скорость для вашей модели и длины контекста [s5](#src-s5)[s7](#src-s7). Поэтому при CPU-only или Apple Silicon сначала проверьте совместимость llama.cpp, а при Linux/NVIDIA дополнительно проверьте vLLM и сравните в одинаковых условиях. Если выбор GPU сомнителен, сначала получите рабочий ответ на **одном** runtime, а не подбирайте число параллельных запросов наугад.

## Как проверить первый ответ, не перепутав серверы?

Откройте [инструкцию vLLM](/zhurnal/vllm/) и [инструкцию llama.cpp](/zhurnal/llama-cpp/), зафиксируйте версии и адреса **только на localhost**. Quickstart vLLM показывает `vllm serve <идентификатор модели>` и запрос `/v1/models` на `localhost:8000`; README llama-server описывает `-m <путь-к-GGUF>`, `--host 127.0.0.1`, порт `8080` и Chat Completions [s1](#src-s1)[s6](#src-s6). Это ориентиры для настройки у читателя, не выполненные Modelium команды. Перед приватными данными проверьте сетевую доступность и политику логирования отдельно: OpenAI-совместимый endpoint сам по себе не является сетевой изоляцией.

Посылайте в оба сервера один короткий обезличенный вопрос через Chat API, предварительно сверив имя модели в ответе и наличие корректного chat template. Если один сервер не загрузил выбранный формат или не выдал валидный ответ, это **сбой совместимости**, не результат сравнения задержки [s1](#src-s1)[s6](#src-s6). Ошибку и ревизию сохраните, а не заменяйте модель между попытками молча. При отсутствии соответствующего GGUF не объявляйте «сопоставимый benchmark» по двум разным семействам.

## Как измерить серверную нагрузку без ложного победителя?

После первых исправных ответов составьте несколько собственных обезличенных входов: короткий вопрос, длинный документ и повторяющийся префикс, если он характерен вашему приложению. Подайте тот же набор последовательно при одном и нескольких одновременных клиентах; у llama-server зафиксируйте `--parallel` и состояние continuous batching, у vLLM — версию, параметры сервера и загруженный checkpoint [s6](#src-s6)[s1](#src-s1). Не утверждайте, что второй сервер обязан быть быстрее: их форматы весов, квантование, backend и настройка контекста способны исказить прямое сопоставление.

Запишите долю успешных ответов, задержку до первого токена (TTFT), полную задержку, output throughput, расход RAM/VRAM и поведение на выбранном уровне параллелизма. vLLM определяет ITL как промежуток между streaming-выдачами, а TPOT — как `(полная задержка − TTFT) / (число выходных токенов − 1)`; не сравнивайте метрики одинакового названия от разных клиентов без сверки формул [s4](#src-s4). Его руководство также предупреждает, что повторный `vllm bench serve` может прогреть prefix cache и завысить throughput: отделите холодные и тёплые серии, отмечайте перезапуск/очистку и используйте одинаковую последовательность запросов [s4](#src-s4). Для собственного vLLM-теста есть [пошаговая методика bench serve](/zhurnal/vllm-bench-serve/); показатели из документации — демонстрация, не замеры Modelium.

## Когда выбор нужно отложить?

Если модель поддерживается только в одном runtime, сравнение серверов на «одинаковой модели» пока не состоялось. Если бюджет памяти или устройство не подтверждены, сначала проверьте размещение, а не выводите минимум из размера весов [s2](#src-s2)[s6](#src-s6). Если требуется коммерческое использование, отдельно прочитайте условия **конкретных** весов: лицензия движка не равна лицензии модели. И если важна приватность, проверьте сетевую границу и журналы, а не приписывайте защиту самому факту локального запуска.

**Следующий шаг:** [проверить запуск и ответ выбранной модели через vLLM](/zhurnal/vllm/), затем получить ответ того же исходного checkpoint в подходящем GGUF через [llama.cpp](/zhurnal/llama-cpp/) и сравнить свою нагрузку с записанными параметрами. Modelium пока не запускал эту пару и не сообщает победителя по скорости или качеству.

## Источники

1. [vLLM — Quickstart (Git f98d1fc)](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/getting_started/quickstart.md) — получено 2026-10-05
2. [vLLM — GPU installation (Git f98d1fc)](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/getting_started/installation/gpu.md) — получено 2026-10-05
3. [vLLM — GGUF plugin and limitations (Git f98d1fc)](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/features/quantization/gguf.md) — получено 2026-10-05
4. [vLLM — Benchmark CLI and latency definitions (Git f98d1fc)](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/benchmarking/cli.md) — получено 2026-10-05
5. [llama.cpp — README (Git a7fb71f)](https://github.com/ggml-org/llama.cpp/blob/a7fb71fab83b474a0892b9a05aaa3a8ddca2729b/README.md) — получено 2026-10-05
6. [llama.cpp — llama-server README (Git a7fb71f)](https://github.com/ggml-org/llama.cpp/blob/a7fb71fab83b474a0892b9a05aaa3a8ddca2729b/tools/server/README.md) — получено 2026-10-05
7. [llama.cpp — Build guide (Git a7fb71f)](https://github.com/ggml-org/llama.cpp/blob/a7fb71fab83b474a0892b9a05aaa3a8ddca2729b/docs/build.md) — получено 2026-10-05