Llama.cpp против vLLM для self-hosted инференса в 2026, что выбрать под нагрузку

[lonelygoblin]

Поднимаю self-hosted инференс LLM на проде в РФ (облако недоступно по понятным причинам, крутим на своём железе), и не могу решить между llama.cpp и vLLM. Нагрузка: чат-ассистент, пики до 50 одновременных запросов, модель 14-32B, железо 2x A100 80гб либо 4x 4090. Llama.cpp подкупает простотой и GGUF квантизацией, vLLM обещает throughput через PagedAttention и continuous batching. Кто гонял оба под реальной конкурентной нагрузкой, что в итоге выбрали и где грабли.

[rocknrolla]

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

[thumper416]

на 4090 кстати vLLM может капризничать с tensor parallel, sm_89 не всегда дружит с некоторыми кернелами. на A100 поедет без вопросов. учти при выборе железа

[smith_zhenya]

llama.cpp подкупает простотой и GGUF квантизацией

простота это иллюзия когда доходит до прода. в llama.cpp ты упрёшься в то что параллельные слоты надо руками выставлять (-np), и при переполнении он начинает тормозить всех, а не аккуратно очередить. vLLM это разруливает из коробки

[lena87]

sglang ещё посмотри, под чат с общими префиксами (системный промпт один на всех) он за счёт radix cache может обойти vLLM. для ассистента где у всех одинаковый длинный system prompt это прям заметно

[ch5237]

@smith_zhenya, разложу по полкам, гоняли оба в проде последний год под похожий профиль.

Короткий ответ: для твоей нагрузки vLLM. Дальше почему и где грабли.

Throughput. На 50 параллельных запросах continuous batching решает. llama.cpp с -np 8 на тех же запросах давал в 3-4 раза меньше токенов в секунду суммарно, потому что батчинг там примитивнее. vLLM держит загрузку гпу под 90 процентов, llama.cpp скакал.

Латентность под нагрузкой. У llama.cpp при заполнении слотов time to first token уезжает в небеса, новый запрос ждёт. vLLM за счёт PagedAttention и вытеснения держит TTFT предсказуемее.

Квантизация. Тут llama.cpp реально гибче, GGUF Q4_K_M качественный и жрёт мало. В vLLM бери AWQ или GPTQ 4bit, либо fp8 на A100. На 32B модели AWQ влезет в одну A100 80гб с запасом под kv cache. На 2x A100 ставь tensor parallel 2 и не парься.

4x 4090 против 2x A100. Если выбор ещё открыт, бери A100. На 4090 нет nvlink, межкарточный обмен по pcie душит tensor parallel, на 32B это чувствуется. Плюс 24гб на карту тесно под kv cache при длинном контексте. 4090 хороши когда модель влезает в одну карту и ты просто реплицируешь инстансы, а не шардишь.

Грабли vLLM: жрёт VRAM агрессивно (gpu_memory_utilization 0.9 по дефолту, оставь место), при OOM падает не всегда красиво. Версии меняются быстро, ломучие апдейты, пинуй версию жёстко. И квантизованные модели иногда требуют возни с форматом.

Итог: vLLM как основной движок, A100, tensor parallel, AWQ или fp8. llama.cpp оставь для локальной отладки и десктопных сценариев.

[Rhemix]

4090 хороши когда модель влезает в одну карту и ты просто реплицируешь инстансы

вот это золото. народ упорно пытается шардить 32B на 4090 через pcie и потом удивляется что throughput в пол. реплики одной 14B на каждую карту + балансер часто быстрее чем одна большая шардированная

[go21]

а в РФ как с поставкой A100 сейчас вообще, по серым каналам же конский ценник. может проще 4090 пачкой набрать чисто по бюджету. посчитай токены на рубль а не абсолютный throughput

[pharside]

vllm конечно король но он сложнее в эксплуатации, если у тебя команда из 2 человек и нагрузка не каждый день пиковая, llama.cpp проще держать живым. не всем нужен максимальный throughput, иногда нужен сон по ночам