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

[navspy]

Делюсь сравнением vLLM и llama.cpp под реальной многопользовательской нагрузкой, потому что в большинстве гайдов меряют single-stream и это вводит в заблуждение. Поднимал self-hosted инференс для внутреннего сервиса, ~30 одновременных пользователей, модель Qwen2.5-32B-Instruct на двух A6000 48гб. На одиночном запросе llama.cpp даёт сопоставимые токены и проще ставится. Но как только идёт параллельная нагрузка vLLM улетает вперёд в разы за счёт continuous batching и paged attention. На 30 параллельных запросах vLLM держал суммарно ~1100 t/s по всем стримам, llama.cpp с его батчингом еле выжимал 300-350 и латенси скакало. Вопрос к тем кто на проде: есть ли смысл вообще смотреть в сторону llama.cpp если нагрузка многопользовательская, или это однозначно vLLM и не выпендривайся.

[catbert1]

vLLM для конкаренси, точка. llama.cpp это про локалку на одного и про гибрид cpu+gpu когда vram не хватает. под прод с батчами даже не рассматривается всерьёз

[Manuelriere]

а почему не sglang. на тех же кейсах часто обгоняет vllm на структурированной генерации и radix cache там умнее. если у тебя много общих префиксов в промптах sglang может дать ещё процентов 30 сверху

[middlewarlock]

TGI ещё есть от huggingface, но честно vLLM сейчас стандарт де-факто, вокруг него больше всего тулинга

[delphin]

на одиночном запросе llama.cpp даёт сопоставимые токены и проще ставится

вот это важная оговорка которую все проскакивают. если у тебя не 30 юзеров а 2-3 и модель влезает в vram, разница в throughput тебе не нужна, а возни с vLLM (питон, версии cuda, флаги) больше. для маленького внутреннего тула llama-server на llama.cpp ставится за 5 минут и работает. инструмент под задачу, а не серебряная пуля. ты выбрал vLLM правильно для своих 30 юзеров, но не делай из этого вывод что llama.cpp устарел

[hause]

@middlewarlock, по личному опыту разверну где vLLM кусается на проде, чтобы ОП не наступил на грабли после переезда.
Первое: vLLM преаллоцирует vram под kv cache агрессивно, по дефолту gpu_memory_utilization 0.9. Если на той же карте крутится что-то ещё, поймаешь OOM на старте. Крути параметр под свой запас.
Второе: continuous batching шикарен по throughput, но хвостовая латенси под пиком плавает. Если у тебя SLA на p99 первого токена, тестируй именно под нагрузкой а не на холодную, может неприятно удивить.
Третье: квантизация в vLLM отдельная история. AWQ и GPTQ работают, но не все модели в этих форматах есть, а gguf vLLM нативно не ест толком. У тебя 32B на 48гб в fp16 впритык, считай память под kv заранее иначе короткий контекст получишь.
Четвёртое чисто эксплуатация: обновления vLLM ломучие, фиксируй версию в проде намертво и не обновляй на проде в пятницу. Ловил регрессии по скорости между минорными релизами.
Итого vLLM под 30 юзеров верный выбор, но это не поставил и забыл, тюнить придётся. По цене A6000 сейчас около 350-400к за штуку, две карты это серьёзный капекс, на старте может дешевле арендовать gpu по часам и переехать на своё когда нагрузка устаканится.

[rsal56]

обновления vLLM ломучие, фиксируй версию в проде намертво и не обновляй на проде в пятницу

подтверждаю кровью. словили падение throughput процентов на 20 после апдейта минорной версии, полдня искали причину пока не откатились. requirements с точными версиями и docker образ зафризенный, иначе ад

[pandas4]

@Manuelriere, 30 юзеров и две A6000, жирно живёте. у нас на одной 4090 крутится 7B и норм всем хватает лол

[nixos_andy]

@middlewarlock, @ОП ещё момент, если запросы разной длины context сильно гуляет, у vLLM с этим ок благодаря paged attention, а вот llama.cpp с фиксированным n_ctx на всех ты либо память переплачиваешь либо упираешься в потолок. так что для разнородной нагрузки vLLM ещё и память экономнее по факту, не только быстрее