vLLM в проде падает с OOM при всплесках трафика — как правильно настроить KV-cache и batching?

[ama123]

Деплоим vLLM 0.6.x с Qwen2.5-14B на двух A10G (24GB каждая, tensor_parallel_size=2). В обычное время всё хорошо, latency p50 ~1.2с. Но при всплесках — раз 5-6 в день на 3-5 минут нагрузка вырастает в 3-4 раза — начинаются OOM и сервис падает. Перезапуск занимает минуты, бизнес недоволен. gpu_memory_utilization стоит 0.90. Что можно сделать с батчингом и кэшем чтобы деградировать gracefully вместо краша?

[tiger71]

Классическая проблема. Первое что надо сделать — снизить gpu_memory_utilization до 0.85 или даже 0.80. Да, ты потеряешь немного throughput в обычное время, зато при пиках будет буфер. Второе — обязательно выстави --max-num-seqs (максимальное количество одновременных запросов в батче), у тебя он скорее всего дефолтный 256 что много для 14B на A10G. Попробуй 64-96. Третье — --max-model-len ограничь реальным максимумом твоих промптов, не держи 32k если у тебя промпты 2k.

[lentyaj]

Ещё добавлю: поставь перед vLLM нормальную очередь запросов. Мы используем простой Redis + воркеры, при превышении порога очереди возвращаем 429 с retry-after вместо того чтобы грузить vLLM до упора. Это разделяет проблему 'сервис упал' от 'сервис перегружен'. Клиент получает явный сигнал и может ретраить, а не висеть.

[Tracyw]

@lentyaj, У нас была похожая история. Решили через --enable-chunked-prefill и --max-num-batched-tokens 4096. Chunked prefill разбивает длинные prefill-фазы на чанки и перемежает их с decode-фазой, это сильно снижает latency spikes при длинных промптах и уменьшает пиковое потребление памяти под KV-кэш. После включения p99 latency упала с 18с до 6с при той же нагрузке.

[ivan21]

@ama123, Смотрите ещё на --kv-cache-dtype fp8 если ваша карта поддерживает (A10G поддерживает через torch). KV-кэш в fp8 занимает вдвое меньше памяти чем в fp16, можно держать вдвое больше одновременных сессий. У нас это дало возможность поднять max-num-seqs с 64 до 128 без увеличения OOM-риска. Небольшое падение качества есть но на уровне шума для большинства задач.

[callie]

Итоговый конфиг который мы используем для похожей конфигурации (13-14B, 2xA10G): gpu_memory_utilization=0.82, max_num_seqs=80, max_model_len=8192, enable_chunked_prefill=true, max_num_batched_tokens=8192, kv_cache_dtype=fp8. Перед этим — nginx с rate limiting + небольшая очередь на Redis. OOM пропали полностью, при пиках просто растёт latency и очередь, но сервис живой.

[b1llyn0m]

Если у вас именно краши с OOM, а не просто рост latency — это почти всегда не KV-кэш. vLLM при заполнении кэша должен делать preemption (recompute или swap), а не падать. Реальный убийца — пик активаций во время prefill длинных промптов: он масштабируется от max_num_batched_tokens и НЕ резервируется через gpu_memory_utilization. Поэтому жёсткий cap на max_num_batched_tokens чинит краши надёжнее, чем кручение utilization. И добавьте --swap-space 4-8, чтобы при пике он вытеснял сессии на CPU, а не умирал.

[natebeckham]

@lentyaj, вот это и есть настоящий graceful degradation, а не возня с utilization. Только привяжи порог очереди к max_num_seqs движка, а не к абстрактному числу: если в vLLM влезает 80 одновременных — отдавай 429 примерно на этом потолке плюс небольшой запас, иначе либо рано режешь трафик, либо снова заваливаешь движок. И retry-after обязательно с джиттером, иначе клиенты синхронно вернутся и устроят второй пик.

[jwil1440]

@callie, конфиг крепкий, но я бы дописал --swap-space (хотя бы 4) — тогда при всплеске vLLM вытесняет блоки на CPU вместо OOM. И мониторь num_preempted_requests из /metrics: если она лезет вверх при пиках — это твой ранний сигнал, что пора резать max_num_seqs дальше, а не ждать падения. По fp8 KV на A10G аккуратнее с моделями, чувствительными к длинному контексту: пару раз ловил деградацию на промптах за 6к именно из-за fp8 кэша.