vLLM vs llama.cpp что выбрать для продакшн инференса

[redislover]

Стоит задача: деплоить Qwen2.5-72B для внутреннего использования в компании, примерно 50-100 одновременных запросов. Есть сервер с 4x A100 80GB. Смотрю в сторону vLLM и llama.cpp с сервером. Кто реально деплоил что-то подобное — что посоветуете? Важны: throughput, latency на первый токен, стабильность под нагрузкой.

[svelteandy]

На таком железе однозначно vLLM. llama.cpp хорош для локалки или когда надо на одной карточке выжать максимум через GGUF-квантизацию, но для 4xA100 с нагрузкой в 100 concurrent users — это не его история. vLLM с PagedAttention и continuous batching даст на порядок лучший throughput.

[Pmannn]

Согласен с предыдущим, но добавлю нюанс: llama.cpp в последних версиях тоже умеет tensor parallelism и неплохо работает с несколькими GPU. Но его OpenAI-compatible сервер всё равно уступает vLLM по batching-логике. Для 72B модели на 4xA100 я бы смотрел ещё на SGLang — в бенчмарках он часто обгоняет vLLM на longer context.

[nashnet]

Из практики: vLLM на Qwen2.5-72B с --tensor-parallel-size 4 и bfloat16 на 4xA100 даёт около 1200-1500 токенов/сек суммарного throughput при batching. TTFT (time to first token) при нагрузке держится в районе 300-500мс. Для запуска: python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-72B-Instruct --tensor-parallel-size 4 --max-model-len 32768. Главный момент — выставь --gpu-memory-utilization 0.90, иначе vLLM по умолчанию резервирует 90% сам, но иногда нужно подкрутить под конкретную модель.

[sleepyraccoon]

Один важный практический момент который все упускают: vLLM иногда падает с OOM если не ограничить max_num_seqs и max_num_batched_tokens под свою нагрузку. Обязательно нагрузи сервер перед продом — locust или простой bash-скрипт с параллельными curl, смотри на утилизацию VRAM в nvidia-smi -l 1. Также логи vLLM в prod лучше гнать в что-то вроде Prometheus + Grafana, там есть встроенные метрики через /metrics эндпоинт.

[cmout098]

Используем vLLM в проде уже 8 месяцев, всё норм. Единственная боль — обновления иногда ломают совместимость конфигов, держите версию зафиксированной в docker-compose и не обновляйтесь без тестирования.

[solidity2024]

llama.cpp на четырех A100 это как пиццу на КамАЗе возить. Он про маки и одну видяху с GGUF, когда железа мало. На таком сетапе даже обсуждать нечего, vLLM и закрыли тему.

[kernelpilot]

@Pmannn, гонял SGLang рядом с vLLM пару месяцев. На shared-prefix нагрузке (RAG с общим системным промптом) он реально быстрее, процентов 20-25 за счёт RadixAttention. Но на разнородных запросах разница в пределах погрешности, а доки и комьюнити у vLLM сильно жирнее. Ради красивых бенчей я бы его в прод не тащил, случись что, дебажить будете втроём с автором.

[docker13]

@nashnet, у тебя пост оборвался на самом интересном, иначе что? Дополню из своего опыта: 0.90 норм, а вот на 0.95 ловил OOM когда прилетала пачка длинных запросов под 32k одновременно. И включи -enable-prefix-caching, если у юзеров общий системный промпт, TTFT падает ощутимо.

[juniorredteam]

@redislover, ещё вариант на подумать: вместо одной 72B в bf16 на 4 картах взять Qwen2.5-72B-Instruct-AWQ (int4) и поднять две реплики по 2 карты за балансером. Суммарный throughput выше, плюс отказоустойчивость бонусом, одна реплика легла, вторая живёт. Качество на AWQ просаживается несильно, мы на внутренних тестах разницу почти не увидели. Но если важна максимальная точность ответов, тогда да, bf16 на 4 картах как тебе выше расписали.