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

[vikakychma]

делаю внутренний сервис с llm api на своих картах, нужно держать несколько одновременных запросов. что брать под нагрузку, vLLM или llama-server? llama.cpp понятнее и gguf удобнее, но я читал что vLLM сильно выигрывает на параллельных запросах за счёт continuous batching и paged attention. одиночный запрос меня не волнует, важна суммарная пропускная способность когда 10-20 юзеров долбят одновременно. у кого есть прод опыт, насколько реально разница в throughput?

[lfmatt]

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

[vemina]

минус vLLM что он жрёт видеопамять под весь кэш заранее и капризен к квантам, gguf не ест нормально, нужны awq/gptq или fp8. если у тебя видяхи под завязку и хочется gguf то llama.cpp проще.

[k8s_master]

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

тогда даже не думай, vLLM. весь смысл continuous batching ровно в твоём кейсе. под 10-20 параллельных он держит загрузку gpu под 90%+ и общий t/s раз в 5-8 выше llama.cpp на той же карте. llama.cpp хорош для одного юзера на десктопе, для многопользовательского api это vLLM или sglang.

[user_pasha]

sglang ещё гляньте, на некоторых сценариях с общими префиксами быстрее vLLM за счёт radix attention. если у вас одинаковый системный промпт у всех запросов то кэш префикса сильно помогает

[tommee]

@lfmatt, +1 за sglang, у нас на RAG где системный промпт здоровый и общий он vLLM обошёл заметно

[PostgresLord]

по теме развёрнуто, раз прод. ставили оба, остановились на vLLM. конфиг: 2x A100 80гб, модель 70B в fp8, tensor parallel 2. под пиком 20-25 одновременных запросов держим ~1400 t/s суммарно, латенси первого токена в районе 200-400мс. ключевое что надо понять: vLLM требует подбора --gpu-memory-utilization и --max-num-seqs под твою нагрузку, по дефолту он может либо жадничать память либо ограничивать конкуренцию. кванты только fp8/awq/gptq, gguf забудь. деплой в докере, версия фиксированная потому что они ломают совместимость между релизами регулярно. если бюджет на A100 нет и сидите на 3090/4090, fp8 не везде заводится по compute capability, тогда awq. llama.cpp оставили только для дев машин разрабов где gguf удобно и юзер один. для api под людей vLLM, не пожалели.

[heckman]

@root про ломают совместимость между релизами это в точку, обновились с одной минорной версии и упал весь деплой из за смены формата конфига. пинуем версию намертво теперь

[sandtiger]

а sglang в проде у кого нибудь стабильно крутится или это пока энтузиастское? боюсь брать под боевую нагрузку