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

Источник: https://modelium.tech/zhurnal/vllm-sleep-mode/

Sleep Mode временно освобождает часть памяти GPU без остановки сервера vLLM. Для возврата той же модели начните с уровня 1: веса сохраняются в RAM, KV-кеш сбрасывается; после wake_up проверьте ответ модели. HTTP-управление требует dev-режима с опасными неаутентифицированными эндпоинтами, поэтому пробуйте его только на изолированном тестовом сервере, недоступном посторонним.

**Проверено по документации 5 октября 2026 года:** vLLM Git `f98d1fc` и карточка Qwen3-0.6B HF `c1899de`. Это инструкция для вашего тестового стенда, а не отчёт о собственном прогоне Modelium [s1](#src-s1)[s7](#src-s7).

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

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

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

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

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

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

- **Уровень 1**: веса модели сохраняются в CPU RAM, KV-кеш выбрасывается. Выбирайте его, когда хотите вернуть ту же модель и у хоста достаточно доступной RAM для копии весов **и прочей работающей нагрузки**. Размер файла весов сам по себе не является расчётом требуемой RAM: её нужно оценить и измерить на своём процессе [s1](#src-s1).

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

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

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

Сначала разверните vLLM согласно [гайду сервера](/zhurnal/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-маршруты в интернет или корпоративную сеть [s1](#src-s1)[s2](#src-s2).

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

После 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 [s1](#src-s1)[s3](#src-s3)[s8](#src-s8).

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

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

- `**/sleep**`** не найден или отклонён.** Сверьте оба флага на *том же* серверном процессе: `VLLM_SERVER_DEV_MODE=1` и `--enable-sleep-mode`. Не включайте dev-режим на доступном клиентам инстансе ради исправления 404; перенесите эксперимент на закрытый стенд [s1](#src-s1)[s2](#src-s2).

- **После уровня 1 сильно выросла RAM или GPU освободился не полностью.** Веса резервируются на CPU, а CUDA graph memory по умолчанию остаётся на GPU. Не выводите норму RAM из веса скачанного файла и не обещайте фиксированный процент освобождения; проверьте локальные показатели и конкурирующую нагрузку [s1](#src-s1).

- **После **`**wake_up**`** нет рабочего ответа.** Проверьте `/is_sleeping`, журнал сервера и ответ `/v1/chat/completions` именно для прежней модели. Если случайно применён уровень 2, последовательность восстановления отличается и включает загрузку весов; на тестовом стенде безопаснее вернуться к baseline-экземпляру, чем слепо вызывать `/collective_rpc` без изоляции и понимания состояния [s1](#src-s1)[s2](#src-s2)[s4](#src-s4).

- **Нужен только сброс KV, не выгрузка весов.** В документации есть отдельный `release_kv_cache_memory()` после завершённой паузы и с требованиями к allocator/backend. Это другой сценарий, не равнозначный уровню 1; сначала проверьте совместимость своей конфигурации и не считайте HTTP-код подтверждением исправления нагрузки [s1](#src-s1).

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

Главный следующий шаг — [подготовить обычный локальный сервер vLLM](/zhurnal/vllm/) с конкретной моделью и baseline-ответом, затем провести описанное сравнение на закрытом тестовом стенде. При изменении версии vLLM перепроверьте параметры и интерфейс sleep: здесь закреплено состояние исходников `f98d1fc` от 4 октября 2026 года. Для AMD проверьте [путь ROCm](/zhurnal/vllm-na-amd-rocm/), а если интересуют серверные счётчики нагрузки, смотрите [гайд по метрикам](/zhurnal/vllm-metrics-prometheus/). Ни установка, ни измерение памяти или латентности от имени Modelium не проводились [s1](#src-s1)[s5](#src-s5)[s8](#src-s8).

## Источники

1. [vLLM Sleep Mode: уровни, Python и HTTP, закреплённая документация](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/features/sleep_mode.md) — получено 2026-10-05
2. [vLLM Security: границы API key и опасность development endpoints](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/usage/security.md) — получено 2026-10-05
3. [vLLM Online Serving: health, models и sleep endpoints](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/serving/online_serving/README.md) — получено 2026-10-05
4. [vLLM OpenAI-Compatible Server: Chat API и ограничения ключа](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/serving/online_serving/openai_compatible_server.md) — получено 2026-10-05
5. [vLLM CUDA installation: архитектура GPU и отдельное окружение](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/getting_started/installation/gpu.cuda.inc.md) — получено 2026-10-05
6. [vLLM upstream test_sleep_mode.py: метод сравнения вывода до и после](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/tests/basic_correctness/memory/sleep_mode/test_sleep_mode.py) — получено 2026-10-05
7. [Qwen/Qwen3-0.6B: закреплённая карточка модели](https://huggingface.co/Qwen/Qwen3-0.6B/blob/c1899de289a04d12100db370d81485cdf75e47ca/README.md) — получено 2026-10-05
8. [vLLM Production Metrics: серверный endpoint /metrics](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/usage/metrics.md) — получено 2026-10-05