vLLM – один из самых популярных инструментов для запуска больших языковых моделей. Он быстрый, удобный и активно используется в промышленной эксплуатации (продакшене). Однако существует проблема, с которой сталкиваются почти все при масштабировании нагрузки: ошибка OOM (Out Of Memory) – нехватка оперативной памяти.
Инженеры из AI21 Labs столкнулись с этим при работе со своей моделью Jamba. Они запускали vLLM на серверах с графическими процессорами (GPU), увеличивали количество запросов – и в какой-то момент система аварийно завершала работу. Причём предсказать момент сбоя было сложно: система могла работать стабильно, а затем внезапно вылетала.
Почему vLLM так интенсивно потребляет память 🧠
Проблема заключается в том, как vLLM управляет ресурсами. Когда модель обрабатывает запрос, ей необходимо хранить промежуточные данные – так называемые KV-кэши. Это своего рода «заметки на полях», которые помогают модели удерживать контекст разговора и генерировать текст быстрее.
vLLM заранее резервирует под эти кэши значительный объем видеопамяти. Идея состоит в том, чтобы не тратить время на динамическое выделение памяти в процессе вычислений. Но если запросов много или они содержат длинный контекст, этот резерв быстро исчерпывается – и система выдает ошибку.
Проще говоря: vLLM стремится к максимальной скорости, поэтому забирает память с запасом, но иногда этот объем оказывается избыточным или, наоборот, недостаточным в зависимости от специфики нагрузки.
Что предпринимали в AI21 Labs
Команда протестировала несколько подходов. Сначала они попытались просто ограничить количество одновременных запросов, чтобы снизить нагрузку. Это помогло лишь частично: в определенных сценариях память всё равно переполнялась.
Затем начались эксперименты с настройками самого vLLM. В частности, с параметром gpu_memory_utilization – он определяет долю видеопамяти, которую vLLM может занять под KV-кэши. По умолчанию это 90%, но в AI21 обнаружили, что для их задач такая настройка слишком агрессивна.
Они снизили значение до 80%, а затем до 70% – система стала работать стабильнее. Однако это привело к тому, что часть ресурсов GPU простаивала, а общая пропускная способность снизилась. Это решение нельзя было назвать идеальным.
Решение было найдено в плоскости формирования батчей – групп запросов, которые обрабатываются одновременно. Вместо жесткого ограничения памяти команда сосредоточилась на управлении очередями.
vLLM старается упаковать в один батч (пакет) как можно больше запросов для эффективной загрузки GPU. Но если в пакете оказывается несколько длинных запросов с объемным контекстом, лимит памяти может быть превышен прямо в процессе выполнения операции.
AI21 Labs внедрили систему, которая в реальном времени отслеживает объем памяти, фактически требуемый для текущих запросов, и динамически корректирует размер батча. Если система видит, что свободная память на исходе, она приостанавливает добавление новых запросов в пакет и ждет освобождения ресурсов.
В этом нет сложной магии – скорее аккуратная балансировка. Но эффект оказался значительным: количество ошибок OOM сократилось в разы, а пропускная способность сохранилась на высоком уровне.
Что это значит для индустрии
Опыт AI21 Labs подтверждает важный тезис: стандартные настройки vLLM хороши для быстрого старта, но не универсальны. При запуске модели в промышленную эксплуатацию с реальной нагрузкой необходимо детально анализировать, как именно система потребляет ресурсы.
Особенно это актуально в случаях, когда:
- запросы сильно различаются по длине;
- нагрузка неравномерна (резкие всплески после периодов затишья);
- используются тяжелые модели на ограниченных аппаратных мощностях.
В таких сценариях подход «установил и забыл» не сработает. Необходимо внедрять мониторинг памяти, экспериментировать с параметрами батчинга и, возможно, наслаивать собственную логику управления нагрузкой.
AI21 Labs не раскрыли всех технических деталей реализации, так как это внутреннее решение для их инфраструктуры. Однако общая концепция ясна: vLLM предоставляет отличный фундамент, но для стабильной работы под высокой нагрузкой инструмент требует тонкой доработки.
Остается открытым вопрос: будет ли сам проект vLLM развиваться в сторону более интеллектуального управления памятью? Проект активно поддерживается сообществом, поэтому вполне вероятно, что подобные механизмы со временем появятся в базовой версии (из коробки).
Пока же тем, кто масштабирует vLLM, стоит воспринимать настройку не как разовую задачу, а как непрерывный процесс. Ошибки нехватки памяти – это не приговор, а сигнал к тому, что пришло время оптимизировать параметры системы.
