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

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

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

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

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

GGUF: llama.cpp прямо документирует загрузку локального файла через -m, --model и квантованные модели; это обычный маршрут этого проекта s5s6. vLLM тоже может использовать GGUF, но на зафиксированном срезе его документация требует внешний vllm-gguf-plugin и прямо предупреждает об экспериментальном статусе и возможной несовместимости с другими функциями. Для GGUF она рекомендует tokenizer исходной модели; это не тот же простой путь, что основной запуск из vLLM quickstart s3s1. Если выбран GGUF, изучите отдельный разбор плагина до установки.

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

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

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

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

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

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

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

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

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

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

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

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

Если модель поддерживается только в одном runtime, сравнение серверов на «одинаковой модели» пока не состоялось. Если бюджет памяти или устройство не подтверждены, сначала проверьте размещение, а не выводите минимум из размера весов s2s6. Если требуется коммерческое использование, отдельно прочитайте условия конкретных весов: лицензия движка не равна лицензии модели. И если важна приватность, проверьте сетевую границу и журналы, а не приписывайте защиту самому факту локального запуска.

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