Холивар, llama.cpp против vLLM для своего сервера в 2026, кто кого

[ou812]

llama.cpp или vLLM под продакшн на своём железе, давайте честно разберём, а то каждый тянет одеяло. Ситуация: один сервер с 4x A6000, надо отдавать модель 70B классу пользователей внутри компании, человек 30 параллельно. Мне важна не пиковая скорость для одного запроса, а суммарный throughput когда летит пачка запросов одновременно. llama.cpp я люблю за простоту и кванты, но есть ощущение что под нагрузкой он сольёт vLLM с его continuous batching. Переубедите или подтвердите.

[clickhousepro]

@ou812, тут даже спорить не о чем. под 30 параллельных юзеров vllm порвёт llama.cpp в разы по суммарному throughput. continuous batching и paged attention для того и сделаны. llama.cpp хорош когда один-два юзера и тебе нужны экзотические кванты. на твоём кейсе бери vllm и не выдумывай

[Sdgator]

+1 vllm для concurrency, без вариантов

[nixos_andy]

llama.cpp хорош когда один-два юзера

не совсем. в llama.cpp давно есть continuous batching через --parallel и --cont-batching, оно не стоит на месте. да, до vllm по эффективности батча не дотягивает, но разница уже не в разы как было пару лет назад, а скорее в 1.5-2 на типовой нагрузке. так что если кванты критичны (а на A6000 ты можешь захотеть Q5 чтобы 70B влезла комфортно с большим контекстом), llama.cpp это всё ещё рабочий вариант, не списывай его

[fpga87]

вы оба забыли про sglang. для multi-turn чата с общими префиксами он по radix cache часто обгоняет vllm. если у ребят внутренний ассистент с системным промптом на полстраницы, общий префикс кешируется и throughput взлетает. я бы хоть глянул в его сторону прежде чем фиксироваться

[gdgdgd]

А лицензии кто-нибудь смотрел? для внутреннего корпората vllm apache 2.0, llama.cpp MIT, оба ок. это я так, на всякий, а то потом юристы прибегут

[grpc1337]

холивар ни о чём, ответ зависит от модели и кванта. на fp16/awq 70B vllm безусловный выбор. но автор сам написал что любит кванты. если ему нужен GGUF Q4 потому что иначе 70B с большим контекстом на 4x A6000 впритык, то vllm с gguf работает но костыльно и медленнее чем с родными форматами. короче сначала определись fp16 ты гонишь или квант, а потом уже выбирай движок, а не наоборот

[tastee]

важна не пиковая скорость для одного запроса, а суммарный throughput

раз так, замерь сам на своей нагрузке, не верь форуму. подними оба, прогони vllm benchmark serving с пуассоновским потоком 30 rps и сравни p50/p99 латентность и tokens/s. цифры с чужого железа тебе соврут. у меня на 2x A6000 vllm давал в 2.3 раза больше токенов в секунду на батче 24, но у тебя другая модель и контекст

[icu2]

по итогу взял vllm, throughput решает. но за наводку на sglang спасибо, для следующего проекта с чатом гляну