vLLM против llama.cpp на одной видяхе, кто реально быстрее в 2026

[jwil1440]

Спор вечный, но цифры меняются. vLLM или llama.cpp на ОДНОЙ потребительской видяхе типа 4090. Везде пишут что vLLM быстрее, но это про батчинг и многопользовательскую нагрузку. А если я один сижу и долблю по одному запросу, есть ли смысл городить vLLM с его прожорливостью по памяти, или llama.cpp с GGUF проще и не хуже.

[maja33]

для одиночных запросов llama.cpp часто даже шустрее на старте, потому что vLLM резервирует память под KV-кеш агрессивно и прогревается дольше. но если у тебя хоть иногда параллельные запросы то vLLM рвет в клочья за счет continuous batching

[ivan21]

vLLM не умеет в GGUF нормально, ему подавай safetensors в fp16 или AWQ/GPTQ кванты. на 4090 24гб ты fp16 модель больше 7B не запихнешь. так что для одной видяхи и больших моделей llama.cpp безальтернативен из-за гибких квантов

[SparkMain]

Разберу предметно потому что вопрос мутный без контекста сценария. Тестил обе на 4090 24гб, модель Qwen2.5 32B. llama.cpp с Q4_K_M GGUF дает на одиночном запросе 38-42 т/с генерации, влезает целиком в vram с 16к контекста. vLLM с этой моделью требует AWQ или GPTQ 4-бит квант, на одиночном запросе выдает 45-50 т/с, чуть быстрее за счет более эффективных CUDA-ядер и paged attention. НО. как только идут параллельные запросы картина меняется кардинально. 8 одновременных запросов на vLLM это совокупно 280-320 т/с, llama.cpp с его слабым батчингом проседает до 90-110 совокупно. Вывод. Один пользователь, один запрос за раз, нужны разные кванты и удобство, бери llama.cpp или ollama поверх него. Делаешь сервис на несколько юзеров или гоняешь батчевую обработку датасета, ставь vLLM не раздумывая, разница в throughput кратная. Еще нюанс, vLLM капризен к версиям CUDA и torch, разворачивать дольше, в докере удобнее. llama.cpp скомпилил и забыл.

[middlewarlock]

vLLM с этой моделью требует AWQ или GPTQ 4-бит квант

уже не совсем так, в свежих vLLM завезли экспериментальную поддержку GGUF, правда она медленнее нативных квантов и не для всех архитектур. так что технически GGUF в vLLM можно, но смысла мало, потеряешь скорость ради совместимости

[proxmoxaddict]

@maja33, короче llama.cpp для дома, vLLM для прода. как обычно

[juniorredteam]

@speedrun не как обычно, а зависит от задачи, но в целом да. еще sglang забыли, он местами быстрее vLLM на сложных промптах с префиксным кешированием, кто на агентах сидит с повторяющимися системными промптами тому стоит глянуть