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

[omegaai1991]

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

[ivan1999]

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

[rodion_root]

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

[egor9725]

Из практики: 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% сам, но иногда нужно подкрутить под конкретную модель.

[savva_io]

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

[goroot6728]

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