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

[savva_spb]

Деплоим 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 вместо краша?

[ruslan_ml61]

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

[kolya_flux]

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

[sasha_py52]

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

[semyon_core]

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

[denis_omega53]

Итоговый конфиг который мы используем для похожей конфигурации (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 и очередь, но сервис живой.