Разворачивать LLM на своих мощностях часто приходится не из-за любви к self-hosted решениям, а ради контроля над данными и предсказуемого инференса. Часто этого требуют стандарты безопасности или архитектура внутренних инструментов компании.

В этой инструкции показано, как развернуть Qwen на облачном сервере через vLLM. В результате вы получите OpenAI-совместимый API с аутентификацией по токену и интерфейс Open WebUI для тестирования. Модель при этом не будет доступна из интернета.

Большие языковые модели всё чаще используют как сервис инференса — к ним обращаются по HTTP-API из внутренних приложений, как к базам данных или поисковым системам.

В бизнесе это позволяет быстро внедрять прикладные сценарии:

• Помощник для поддержки и operations — суммаризация обращений, черновики ответов, классификация запросов;
• Ассистент для инженеров — объяснение кода, генерация шаблонов, работа с регламентами и runbook’ами;
• Внутренний помощник по знаниям — поиск и анализ корпоративной документации.

Чтобы перейти от идеи к прототипу, нужен воспроизводимый стенд: доступный по HTTP, с понятным способом подключения и возможностью быстрой проверки. Модель должна работать как сервис.

Мы развернём Qwen с Hugging Face на GPU-сервере в Selectel, запустим через vLLM в режиме OpenAI-совместимого API и подключим Open WebUI для тестирования ответов. Это станет основой для более сложных систем.

Полноценный RAG (индексация, эмбеддинги, ретривер, пайплайн обновления) — тема отдельной статьи. Здесь мы подготовим только стабильный эндпоинт инференса.

Qwen: выбор модели

В инструкции используется Qwen3-30B-Instruct с Hugging Face.

Instruct-версия предпочтительнее базовой: она заточена под диалог, лучше реагирует на системные инструкции и предсказуемее в интеграциях.

Hugging Face выступает источником весов и конфигурации. vLLM загружает модель по model id и кэширует артефакты на диске. При повторных запусках повторная загрузка не требуется, если кэш сохранён.

Перед развёртыванием проверьте в карточке модели:

• Точный model id — он понадобится при запуске vLLM;
• Длину контекста — от неё зависит потребление VRAM;
• Лицензию и доступ — если требуется токен, подготовьте его заранее.

Выбор сервера

Ключевые параметры — конфигурация сервера и контур доступа. От них зависят скорость первого запуска и воспроизводимость тестов.

Для развертывания используем облачную платформу Selectel. В панели управления переходим в раздел «Облачные серверы», выбираем пул (например, Москва) и создаём сервер.

Задаём имя проекта и выбираем образ, например Ubuntu 24.04 LTS.

GPU и VRAM

Видеопамять расходуется на:

• веса модели;
• KV-кэш, растущий с длиной контекста и числом параллельных запросов.

Нужно учитывать запас VRAM. В разделе конфигурации выбираем GPU.

Для Qwen3-30B достаточно одной A100 80GB — это минимальная конфигурация, снижающая риск нехватки памяти на старте.

Диск и кэш модели

Первый запуск включает скачивание весов. Если кэш хранится на маленьком системном диске, возможны повторные загрузки и долгий старт.

Рекомендуется сразу выделить отдельный каталог (например, /data/models) под кэш Hugging Face. Это предотвратит нехватку места.

Доступ к стенду: API и UI

На этапе теста есть два подхода:

• открыть порты, но ограничить доступ по IP и использовать токен;
• использовать SSH-туннель — безопаснее, так как сервисы не публикуются в интернет.

В этой инструкции используется SSH-туннель. Сервисы vLLM и Open WebUI остаются доступными только через SSH. Не нужно настраивать правила доступа к портам извне.

SSH-туннель не заменяет аутентификацию. Токен на API включается в любом случае. Туннель снижает сетевую экспозицию.

Установка и запуск модели

Теперь перейдём к развертыванию Qwen. Цель — поднять модель как сервис инференса, настроить кэш, проверить работу API с токеном и доступность через туннель.

1. Подключение к серверу и базовые проверки

Подключитесь к серверу по SSH. В macOS и Linux используйте терминал, в Windows — PowerShell.

Проверьте наличие GPU:

Затем проверьте свободное место на диске:

2. Настройка кэша Hugging Face

Создайте каталог для кэша и задайте переменные окружения:

Если не задать HF_HOME или TRANSFORMERS_CACHE, кэш попадёт в домашний каталог. На облачных серверах он часто находится на маленьком системном диске, которого не хватит для Qwen.

3. Python-окружение и установка vLLM

Установите Python и создайте виртуальное окружение (venv) — это упростит управление зависимостями.

Установите vLLM:

Проверьте установку командой:

4. Запуск Qwen через vLLM

Задайте идентификатор модели и токен доступа. MODEL_ID должен совпадать с идентификатором на Hugging Face.

Токен лучше сохранить в переменной окружения — так он не попадёт в историю команд.

Запустите сервер vLLM. Ограничьте длину контекста, чтобы уложиться в доступную VRAM:

При первом запуске:

• займёт время — идёт загрузка весов;
• в nvidia-smi появится процесс vLLM и рост потребления VRAM;
• в логах будет сообщение о запуске сервера и прослушивании порта.

5. Проверка эндпоинта и генерации

Откройте вторую SSH-сессию. Экспортируйте VLLM_API_KEY, если он не прописан в ~/.bashrc. Процесс vllm serve должен продолжать работать в первой сессии.

Проверьте доступность эндпоинта и включённую авторизацию:

Проверьте генерацию:

Критерии успешного запуска:

• эндпоинт /v1/models возвращает список моделей;
• эндпоинт /v1/chat/completions отвечает осмысленным текстом;
• в логах vLLM видна обработка запроса.

6. SSH-туннель для доступа с macOS

Так как порты не открыты, используем SSH-туннель. Выполните в терминале локальной машины:

После этого API будет доступен по адресу http://localhost:8081/v1.

Если Open WebUI запускается в Docker-контейнере, localhost внутри контейнера указывает на сам контейнер. Чтобы он увидел API, укажите IP-адрес интерфейса docker0 (обычно 172.17.0.1) или используйте флаг --network=host.

7. Мониторинг и логи

На этом этапе бэкенд работает. Перед подключением UI проверяйте:

• nvidia-smi — следите за использованием VRAM. При увеличении --max-model-len память будет расти;
• Логи vLLM — они показывают входящие запросы и состояние KV-кэша. Это основной источник при задержках ответов.

Если эндпоинт стабильно отвечает на curl — база готова. Переходим к интерфейсу.

Open WebUI для тестирования

После запуска vLLM удобно перейти от curl к визуальному тестированию.

Open WebUI предоставляет простой интерфейс: можно быстро тестировать промты, сравнивать ответы и фиксировать наблюдения без написания кода.

Установите Docker на сервере и добавьте пользователя в группу docker, чтобы управлять контейнерами без sudo:

Запустите контейнер Open WebUI, передав адрес API и токен:

Проверьте, что контейнер работает:

Если туннель уже поднят, добавьте проброс порта WebUI:

После этого интерфейс будет доступен по http://localhost:3000.

Настройка подключения в Open WebUI

В интерфейсе Open WebUI перейдите в настройки и добавьте подключение к OpenAI-совместимому эндпоинту.

Поскольку WebUI работает в контейнере, он должен обращаться к серверу через IP-адрес docker0.

Выполните команду для получения IP:

Используйте результат для настройки:

• Base URL — http://<docker0_ip>:8081/v1 (обычно 172.17.0.1);
• API Key — тот же токен, что использован при запуске vLLM.

После подключения модель готова к работе. Можно настраивать системный промт и тестировать поведение.

Мы минимизировали сетевую экспозицию: порты API и UI не публикуются, доступ — только через SSH-туннель. Дополнительно включена аутентификация по токену.

Переход к продакшену

После тестов стенд нужно привести к виду продакшен-контура: сервис должен переживать перезагрузки, быть наблюдаемым и безопасным.

Запуск vllm serve вручную в SSH-сессии неудобен. Лучше перенести его в systemd или контейнер с политикой перезапуска. Это обеспечит автозапуск и отказоустойчивость.

Для защиты контура соблюдайте три правила:

• Сетевой периметр — API доступен только из доверенной сети (VPC/VPN) или через шлюз. Прямой доступ к портам vLLM и WebUI в интернет запрещён;
• Аутентификация — токен на API обязателен, ключи хранятся вне кода и подлежат ротации;
• Лимиты — добавьте rate limiting, таймауты и ограничения на размер запроса, чтобы защититься от перегрузок.

При росте нагрузки масштабирование идёт двумя путями:

• Вертикально — больше ресурсов на один инстанс;
• Горизонтально — несколько инстансов и балансировка.

Следующий шаг — прикладной сценарий: например, RAG или поиск по документации. Базовый элемент уже готов: стабильный эндпоинт инференса с контролируемым доступом.

Мы собрали стек, позволяющий запускать LLM на своих мощностях с интерфейсом, совместимым с OpenAI API. Главное преимущество vLLM — превращение «голой» модели в управляемый сервис с предсказуемым потреблением VRAM и встроенной очередью запросов.

Это надёжный фундамент для создания RAG-систем или внутренних ассистентов без рисков утечки данных и зависимости от внешних провайдеров.

Разворачивать LLM на своих мощностях часто приходится не из-за любви к self-hosted решениям, а ради контроля над данными и предсказуемого инференса. И обычно этого еще требуют стандарты безопасности или архитектура внутренних инструментов компании.

В статье покажем, как поднять Qwenна своем облачном серверечерез vLLM. На выходе получим стандартный OpenAI-совместимый API с авторизацией по токену и интерфейс Open WebUI для тестов. Детали внутри.

Большие языковые модели все чаще используют как сервис инференса: к ним обращаются по HTTP-API из внутренних инструментов и приложений так же, как к базам данных или поисковым движкам.

В бизнес-практике это дает быстрые прикладные сценарии:

• помощник для поддержки и operations — суммаризация обращений, черновики ответов, классификация;
• ассистент для инженерных команд —объяснение кода, генерация шаблонов, работа с регламентами и runbooks;
• внутренний помощник по знаниям — корпоративная документация.

Чтобы перейти от идеи к прототипу, нужен воспроизводимый стенд: доступный по HTTP, с понятным способом подключения клиентов и быстрыми проверками работоспособности. А модель должна быть поднята как сервис.

Развернем Qwen из Hugging Face наGPU-сервереSelectel, запустим ее через vLLM в режиме OpenAI-совместимого API, а затем подключим Open WebUI для первичной проверки ответов и поведения модели на типовых запросах.

Это станет базой для более сложных систем. Построение полноценного RAG (индексация, эмбеддинги, ретривер, пайплайн обновления) — следующий этап и тема для отдельной статьи. В рамках текущей инструкции мы подготовим только основу для него — стабильный эндпоинт инференса, который вы получите по итогам этой инструкции.

Qwen: подбор и описание модели

В этой инструкции используемQwen3-30B-Instructиз Hugging Face.

Для стенда инференса Instruct-модификация практичнее базовой: она предназначена для диалоговых и ассистентских сценариев, сразу ориентирована на режим «вопрос–ответ», лучше управляется через системные инструкции и предсказуемее ведет себя в типовых интеграциях.

Hugging Face используется как источник весов и конфигурации: vLLM загружает модель по model id и сохраняет артефакты в кэш на диске сервера. При повторных запусках загрузка не выполняется заново, если кэш сохранен.

Перед развертыванием достаточно сверить в карточке модели:

• точный model id — именно он будет использован при запуске vLLM;
• длину контекста — от нее зависят профиль тестов и рост потребления VRAM при увеличении входа/истории;
• условия доступа и лицензию — если требуется принять условия или использовать токен для скачивания, это лучше сделать заранее.

Выбор сервера

Для развертывания крупной LLM в облаке ключевое — правильно выбрать конфигурацию и сразу продумать контур доступа. Эти параметры определяют сколько времени займет первый старт и насколько повторяемыми будут итерации теста.

Для запуска локального Qwen воспользуемся облачной платформой Selectel. Для этого переходимв панель управления, в верхней части экрана видим словоПродуктыи нажимаем на него. Далее переходим вОблачные серверы, выбираем пул, например Москва и нажимаемСоздать сервер.

Даем имя проекту и выбираем образ, например: Ubuntu 24.04 LTS.

GPU и VRAM

При инференсе видеопамять расходуется на:

• веса модели;
• KV-кэш, который растет с длиной контекста и числом параллельных запросов.

Поэтому оценка памяти должна учитывать запас по VRAM под контекст и параллельность. Во вкладкеКонфигурацияпереходим в разделGPUи выбираем видеокарту.

Для текста нам будет достаточно одной A100 80GB — это базовая конфигурация для Qwen3-30B, которая снижает риск упереться в память на этапе первичного запуска.

Диск и кэш модели

Первый запуск включает скачивание весов с Hugging Face и запись в кэш. Если кэш хранится на маленьком системном разделе или диска недостаточно, возникают повторные загрузки и увеличивается время холодного старта и работы GPU.

На практике лучше сразу выделить каталог на диске (например, /data/models) под кэш Hugging Face и артефакты запуска. И запастись местом, чтобы модель не упиралась в диск в момент скачивания.

Доступ к стенду: API и UI

На этапе теста есть два рабочих подхода:

• открыть порты наружу (быстрее для демо), но ограничить доступ по IP/ACL и включить токен на API;
• использовать SSH-туннель (без публикации портов наружу), что обычно безопаснее для инженерного теста.

В этой инструкции используем второй вариант — SSH-туннель. Он безопаснее по умолчанию, потому что сервисы vLLM и Open WebUI остаются доступными только через SSH-подключение, а не через публичные порты. Кроме того не требуется настраивать правила доступа к портам API/UI на периметре для внешнего интернета.

Важно понимать, что SSH-туннель не заменяет аутентификацию. Мы в любом случае включим токен на API, но сам туннель снизит площадь атаки сервиса на уровне сети.

Новые GPU в облаке Selectel от 196,09 ₽/час

Видеокарты для ресурсоемких задач — NVIDIA® H100, H200, RTX™ 6000 Pro.

Подробнее →

Установка и запуск модели по шагам

Переходим к основной части — развертыванию и запуску Qwen. В этом разделе мы поднимем модель как сервис инференса, настроим кэш Hugging Face на диске и проверим, что эндпоинт работает: GPU доступен, модель загрузилась, API отвечает и защищен токеном.

1. Подключение к серверу и базовые проверки

Подключаемся к серверу по SSH. В macOS и Linux это делается через стандартный терминал, в Windows через PowerShell или командную строку:

Проверяем GPU:

А затем и свободное место на диске:

2. Настройка кэша Hugging Face на диске

Создаем каталог под кэш и фиксируем переменные окружения. Это важно: при

корректном кэшировании повторные запуски не начинают загрузку модели заново.

Нюанс: если не задать HF_HOME/TRANSFORMERS_CACHE, кэш уйдет в домашний каталог пользователя. На облачных инстансах  он часто размещен на небольшом системном диске, места на котором для весов Qwen точно не хватит.

3. Python-окружение и установка vLLM

Ставим Python и создаем изолированное окружение (venv) — это упрощает воспроизводимость и дальнейший перевод запуска в сервис.

Устанавливаем библиотеку vLLM:

Проверить корректность установки можно командой:

4. Запуск Qwen через vLLM

Фиксируем идентификатор модели и токен доступа. MODEL_ID должен совпадать с model id на Hugging Face.

Токен лучше предварительно прописать в переменную на сервере — так с ним удобнее работать и  он не «засветится» в истории команд.

Запускаем сервер vLLM. Ограничим длину контекста, чтобы KV-кэш точно поместился в доступную VRAM:

Что наблюдаем при первом запуске:

• первый старт займет время, из-за скачивания весов и прогрева;
• в nvidia-smi появится процесс vLLM и потребление VRAM;
• в логах будет видно, что сервер поднялся и слушает порт.

5. Проверка эндпоинта и генерации (локально на сервере)

Для текстов откройте вторую SSH-сессию или второе окно терминала. В новой сессии заново экспортируйте VLLM_API_KEY, если вы не прописывали его или в файле/~/.bashrc. При этом в первой сессии процесс vllm serve должен продолжать работать.

Проверяем, что эндпоинт доступен и авторизация включена:

Проверяем генерацию ответа:

Критерий успешного запуска:

• эндпоинт /v1/models отвечает и возвращает список моделей;
• эндпоинт /v1/chat/completions отдает осмысленный ответ;
• в логах vLLM в первом терминале видно обработку запроса.

6. SSH-туннель для доступа с macOS (API и UI)

Так как мы не открывали порты сервера наружу, для доступа к модели с локальной машины используем SSH. В терминале выполните команду:

После этого API будет доступен локально http://localhost:8081/v1.

Если вы планируете запускать Open WebUI в Docker-контейнере на том же сервере, учитывайте специфику изоляции. Внутри контейнера localhost указывает на сам контейнер, а не на хост. Чтобы Open WebUI увидел API vLLM, в качестве адреса эндпоинта нужно указывать IP-адрес интерфейса docker0 (обычно 172.17.0.1) или использовать флаг–network=host.

7. Контроль состояния и логи

На этом этапе у вас есть рабочий бэкенд. Перед тем как подключать UI, стоит приучить себя проверять два инструмента мониторинга:

• nvidia-smi: помогает следить за утилизацией VRAM. Если вы решите увеличить длину контекста через--max-model-len, именно здесь вы увидите, сколько памяти осталось под задачи генерации.
• Логи контейнера/процесса: vLLM подробно пишет о входящих запросах и состоянии KV-кэша. Это основной источник информации, если API начинает отвечать с задержкой.

Если эндпоинт стабильно отдает JSON в ответ на curl — база готова. Переходим к визуализации.

Open WebUI для теста

После того как vLLM эндпоинт поднят и отвечает, удобно перейти от проверки через curl к интерактивному тесту.

Open WebUI дает минимальный интерфейс для работы с моделью: можно быстро прогонять промты, сравнивать ответы и фиксировать наблюдения без написания клиентского кода.

На сервере устанавливаем Docker и добавляем текущего пользователя в группу, чтобы управлять контейнерами без sudo:

Теперь запускаем контейнер Open WebUI. Чтобы интерфейс «увидел» наш эндпоинт vLLM, нужно передать адрес API и токен через переменные окружения.

Проверяем, что контейнер работает:

Создаем защищенный туннель. Если туннель для API уже поднят, добавляем проброс порта WebUI:

После этого WebUI будет доступен локально по адресу http://localhost:3000.

Настройка подключения в Open WebUI

В интерфейсе Open WebUI перейдите в настройки и добавьте подключение к OpenAI-совместимому эндпоинту.

Поскольку WebUI запущен в контейнере, он должен обращаться к серверу через IP-адрес сетевого моста.

Далее вводим команду для получения IP хоста для Docker-контейнеров (docker0):

​​Используйте полученные данные для настройки в веб-интерфейсе:

• Base URL — http://:8081/v1(где — адрес, полученный командой выше- обычно 172.17.0.1);
• API Key — тот же токен, который задан при запуске vLLM (VLLM_API_KEY).

После подключения модель уже работает.

Дальше можно настраивать системный промт и работать с моделью.

В рамках тестового контура мы минимизируем сетевую экспозицию: не публикуем порты API и UI наружу, работаем с ними только через SSH-туннель. Дополнительно включаем токен на vLLM эндпоинт, чтобы доступ к API оставался контролируемым даже внутри туннеля.

Расширение и эксплуатация

После тестового запуска стоит привести стенд к виду «продакшен-контура»: чтобы сервис переживал перезапуски, был наблюдаемым и не выставлял API/UI наружу без контроля.

Запускать vllm serve вручную в  SSH-сессии неудобно. Для стабильной работы стоит перенести запуск в systemd или контейнер с restart policy. Это обеспечивает автозапуск после перезагрузки и автоматический перезапуск при падении.

Для защиты контура достаточно держаться трех правил:

• сетевой периметр — API доступен только из доверенной сети (VPC/VPN) или через периметр (proxy/gateway). Прямые порты vLLM и WebUI в интернет не публикуются;
• аутентификация — токен на API остается обязательным, ключи хранятся вне репозитория и подлежат ротации;
• лимиты — на входе появляются rate limiting/таймауты и ограничения на размер запроса, чтобы защититься от ошибок клиентов и неконтролируемой нагрузки.Когда стенд превращается в сервис, обычно первыми параметрами которые «упираются», становяться объем VRAM и:латентность на p95/p99.

Дальше масштабирование идет двумя путями:

• вертикально — больше ресурсов на одном инстансе;
• горизонтально — несколько инстансов и балансировка.

Следующим логичным шагом будет собрать поверх эндпоинта прикладной сценарий: например, RAG/поиск по документации. Это отдельная тема, но базовый элемент уже готов: стабильный эндпоинт инференса с контролируемым доступом и повторяемым запуском.

Мы собрали стек, который позволяет перевести задачи инференса на свои мощности, сохранив привычный интерфейс OpenAI API. Главная фишка vLLM здесь в том, что он превращает «голую» модель в управляемый сервис: с предсказуемым потреблением VRAM и готовой очередью запросов.

Это хороший фундамент для разработки. На такой базе можно собирать RAG-системы или внутренних ассистентов, не переживая за приватность данных и не завися от лимитов или доступности внешних провайдеров.

А вы как разворачиваете LLM у себя? Поделитесь своим набором флагов — соберем в комментариях краткий чек-лист для повторяемого деплоя.