vLLM Sleep Mode: как освободить GPU и безопасно вернуть модель

Когда Sleep Mode нужен, а когда нет?

Если один GPU попеременно обслуживает вывод и другую доверенную задачу, Sleep Mode позволяет временно освободить часть занятой памяти без остановки процесса vLLM. Документация описывает перенос весов на CPU и сброс KV-кеша на первом уровне; на втором веса тоже отбрасываются. По умолчанию память CUDA graphs остаётся на GPU, поэтому обещание «освободить всю VRAM» было бы неверным s1. Если задача — повторно использовать вычисленный префикс между запросами, а не освободить память устройства, это другой механизм: prefix caching. Если нужно выбрать и запустить сервер, начните с общего гайда vLLM s1s3.

Это не способ незаметно перевести рабочий публичный сервис в паузу. Документация включает HTTP-эндпоинты sleep/wake только в development mode и предупреждает, что они не должны быть доступны пользователям. Более того, --api-key защищает не все маршруты; среди открытых в dev-режиме есть /collective_rpc, позволяющий выполнять опасные операции в движке. Экспериментируйте лишь на выделенном стенде с закрытым сетевым доступом; выставленный наружу порт нельзя считать защищённым одним API-ключом s1s2.

Как выбрать модель, железо и уровень сна?

Практический маршрут: задача временно освободить GPU → конкретная модель → память CPU и совместимость ускорителя → сервер vLLM в изоляции → наблюдение сна и проверка нового ответа. В качестве примера из документации vLLM используется репозиторий Qwen/Qwen3-0.6B; карточка автора подтверждает существование модели, но ни одна из этих страниц не доказывает успешную работу именно на вашем устройстве. Здесь не утверждается, что Modelium запускал её s1s7.

Для CUDA-пути закреплённая инструкция установки vLLM указывает compute capability от 7.5 для своего prebuilt стека и рекомендует свежее окружение из-за сочетания PyTorch/CUDA; это не универсальные требования к RAM, не правило для всех backend и не свидетельство успешного запуска на произвольной карте. Sleep Mode в своей документации указан для CUDA и ROCm; подходящие версии драйверов и устройства проверяйте для своей сборки отдельно s1s5.

• Уровень 1: веса модели сохраняются в CPU RAM, KV-кеш выбрасывается. Выбирайте его, когда хотите вернуть ту же модель и у хоста достаточно доступной RAM для копии весов и прочей работающей нагрузки. Размер файла весов сам по себе не является расчётом требуемой RAM: её нужно оценить и измерить на своём процессе s1.
• Уровень 2: веса и KV-кеш отбрасываются. Документация применяет его к сценарию замены/обновления весов или нехватки RAM для их сохранения; возврат к выводу требует корректной загрузки весов после частичного wake_up(tags=["weights"]) и последующего восстановления KV-кеша. Это не эквивалент простого wake_up уровня 1, не используйте его как сокращённую «более сильную паузу» без плана перезагрузки s1s6.

Фраза «Sleep Mode ускоряет следующий ответ» без замера также не следует из источников: восстановление имеет собственную стоимость, а KV-кеш после уровня 1 утрачен. Для сравнения фиксируйте одну версию сервера, модель, длину вопроса, соседнюю GPU-нагрузку, свободную RAM и условия до/после; вывод о выигрыше делайте лишь по своим измерениям s1s8.

Как запустить закрытый тест и проверить управление?

Сначала разверните vLLM согласно гайду сервера в отдельном окружении, проверьте выбранный GPU/backend и что Qwen3-0.6B доступна из выбранного источника. Затем используйте только изолированный локальный стенд: VLLM_SERVER_DEV_MODE=1 vllm serve Qwen/Qwen3-0.6B --enable-sleep-mode --host 127.0.0.1 --port 8000. Сам vLLM документирует переменную и флаг; привязка к loopback — дополнительная мера для теста на одной машине, а не доказательство безопасности от других локальных процессов. Не публикуйте этот порт и не проксируйте dev-маршруты в интернет или корпоративную сеть s1s2.

Перед сном подтвердите, что сервер отвечает на GET http://127.0.0.1:8000/health, выдаёт список моделей по /v1/models и возвращает содержательный ответ на ваш одинаковый тестовый вопрос через /v1/chat/completions. Зелёный /health проверяет HTTP/движок, но сам по себе не показывает, восстановились ли веса и отвечает ли выбранная модель после сна; именно поэтому сохраните полный baseline-ответ, модель и время замера. Чат требует пригодный chat template, а URI API и model надо сверять с фактической моделью, которую вы обслуживаете s3s4.

После baseline отправьте POST http://127.0.0.1:8000/sleep?level=1, затем запросите GET http://127.0.0.1:8000/is_sleeping. Сверьте наблюдаемую память GPU и RAM на своей машине: документация описывает сброс KV и перенос весов на CPU, но остаточные аллокации допустимы. Запишите оба показателя до и после; не подменяйте измерение фразой из документации о возможной экономии. Затем отправьте POST http://127.0.0.1:8000/wake_up, повторно проверьте /is_sleeping и тот же чат-запрос к конкретной модели, сопоставив успешность и ответ с baseline s1s3s8.

Синтаксис HTTP-переходов дан в официальной документации, но команды в этом тексте Modelium не исполнял. Upstream тест vLLM сравнивает генерацию до и после sleep(level=1) при фиксированных параметрах; это тест авторов проекта, не независимое измерение Modelium и не гарантия тождественных ответов при любом sampling. Чтобы оценить свой сценарий, повторите вопросы и сохраните не только успешный HTTP-код, но и текст ответов, условия sampling и замеры памяти/задержки s1s6.

Что делать при ошибке или неожиданном расходе памяти?

• /sleep не найден или отклонён. Сверьте оба флага на том же серверном процессе: VLLM_SERVER_DEV_MODE=1 и --enable-sleep-mode. Не включайте dev-режим на доступном клиентам инстансе ради исправления 404; перенесите эксперимент на закрытый стенд s1s2.
• После уровня 1 сильно выросла RAM или GPU освободился не полностью. Веса резервируются на CPU, а CUDA graph memory по умолчанию остаётся на GPU. Не выводите норму RAM из веса скачанного файла и не обещайте фиксированный процент освобождения; проверьте локальные показатели и конкурирующую нагрузку s1.
• После wake_up нет рабочего ответа. Проверьте /is_sleeping, журнал сервера и ответ /v1/chat/completions именно для прежней модели. Если случайно применён уровень 2, последовательность восстановления отличается и включает загрузку весов; на тестовом стенде безопаснее вернуться к baseline-экземпляру, чем слепо вызывать /collective_rpc без изоляции и понимания состояния s1s2s4.
• Нужен только сброс KV, не выгрузка весов. В документации есть отдельный release_kv_cache_memory() после завершённой паузы и с требованиями к allocator/backend. Это другой сценарий, не равнозначный уровню 1; сначала проверьте совместимость своей конфигурации и не считайте HTTP-код подтверждением исправления нагрузки s1.

Как завершить эксперимент и куда двигаться дальше?

Главный следующий шаг — подготовить обычный локальный сервер vLLM с конкретной моделью и baseline-ответом, затем провести описанное сравнение на закрытом тестовом стенде. При изменении версии vLLM перепроверьте параметры и интерфейс sleep: здесь закреплено состояние исходников f98d1fc от 4 октября 2026 года. Для AMD проверьте путь ROCm, а если интересуют серверные счётчики нагрузки, смотрите гайд по метрикам. Ни установка, ни измерение памяти или латентности от имени Modelium не проводились s1s5s8.