vLLM в Docker запускается официальным образом vllm/vllm-openai: контейнеру нужны доступ к GPU и к весам модели, а готовность подтверждает запрос к OpenAI-совместимому endpoint. Контейнер помогает воспроизвести запуск; тестовый запрос подтверждает ответ сервера, а готовность к нагрузке проверяется отдельным замером очереди, памяти и задержки. Схема работает для компаний, которые держат открытые веса на своём или арендованном железе и хотят управлять доступом к модели самостоятельно: от выбора версии до журнала каждого вызова.
Что вы получите
Официальный образ vllm/vllm-openai запускает OpenAI-совместимый сервер. Перед рабочим трафиком проверьте GPU, доступ к весам, ответ /health и запрос к выбранной модели.
На выходе — локальный адрес, который принимает запросы в привычном формате и отдаёт ответы генерации. Поверх такого адреса строятся чат для сотрудников, агент с инструментами и пакетная обработка документов: всё, что умеет говорить с сервером модели. При собственной инфраструктуре команда управляет размещением запросов и доступом к модели. Для арендованного сервера отдельно проверяйте местоположение данных, сеть, настройки журналирования и условия провайдера. Сравнивайте с готовым сервисом по требованиям к данным, доступности, нагрузке и работе инженеров. Замена модели требует проверки памяти, лицензии и совместимости с вашим приложением. Ответственность тоже ваша: сервер падает — чинить вам, а поддержке писать некуда. Общая картина запуска моделей на собственном сервере разобрана в статье про vLLM для компаний, здесь же — узкий вопрос контейнерной сборки: образ, параметры, проверка.
Образ и параметры
Официальный образ vllm/vllm-openai содержит сервер и зависимости. Зафиксируйте тег образа и точную ревизию модели, чтобы повторный запуск использовал проверенную комбинацию. Модель можно загрузить по идентификатору из реестра или передать локальные веса через смонтированный том. Для запуска на GPU Docker должен видеть драйвер NVIDIA; в официальном примере указаны --gpus all, том кэша модели и --ipc=host. Порт сначала привяжите к локальному интерфейсу или защищённой сети, затем откройте доступ через шлюз с аутентификацией. Параметры запуска храните в конфигурации: идентификатор модели, путь к весам или кэшу, порт и настройки памяти. Секрет доступа к закрытой модели передавайте через менеджер секретов, вне репозитория. Термины разобраны в глоссарии на сайте — от vLLM до инференса. Том с весами держите на отдельном диске или разделе — файлы модели занимают заметное место, и переполнение системного раздела может остановить сервер в разгар рабочего дня.
| Параметр | За что отвечает | Где смотреть |
|---|---|---|
| Имя модели | Какие веса грузит сервер | В команде запуска и в конфиге |
| Путь к весам | Том с файлами модели | В настройках монтирования |
| Порт | Адрес приёма запросов | В пробросе портов контейнера |
| Лимит контекста | Длина одного запроса | В документации выбранной модели |
| Параллельные запросы | Сколько запросов сервер ведёт одновременно | В замерах на типовой нагрузке |
Проверка endpoint
- Поднимите контейнер и дождитесь строки о готовности сервера.
- Отправьте тестовый запрос с коротким текстом на локальный адрес.
- Проверьте ответ: текст, служебные поля, отсутствие ошибок в логе.
- Повторите запрос с фрагментом реальной инструкции на полную длину.
- Замерьте время ответа и использование GPU на типовом промпте из вашей задачи.
- Сохраните безопасный диагностический вывод без промптов, токенов и персональных данных.
Проверку разделите на три уровня. GET /health показывает, что процесс сервера отвечает; GET /v1/models показывает загруженную модель; POST /v1/chat/completions проверяет диалоговый запрос. Последний маршрут требует модель с подходящим chat template. Для модели без такого шаблона используйте совместимый маршрут completions либо настройте шаблон согласно документации vLLM. Успешный ответ одного запроса подтверждает работоспособность endpoint, а скорость при одновременных пользователях покажет отдельный нагрузочный тест.
Тестовый запрос лучше брать из реальной задачи: первый абзац инструкции для агента или типовой вопрос сотрудника. Синтетическое «привет» показывает лишь, что сервер жив, а работу с длинным контекстом и скорость ответа придётся мерить отдельно. Замер времени делайте на нескольких повторах: первый ответ после загрузки модели может быть медленнее следующих, и судить по нему рано. Проверьте поля ответа и usage, если модель их возвращает. Длинный запрос тестируйте отдельно: усечение контекста и поведение модели зависят от конфигурации сервера. Лог сервера читайте целиком при первом запуске: предупреждения о параметрах и загрузке модели появляются именно там. Архитектура доступов к такому контуру — тема материала про архитектуру корпоративной нейросети: сетевые зоны, учётные записи и разграничение прав.
Модели и доступ
vLLM обслуживает совместимые модели, включая отдельные выпуски Qwen, DeepSeek и Llama. Лицензия и доступ к весам различаются у конкретных версий; проверяйте их перед рабочим запуском. Собственный или арендованный сервер даёт иной контур управления, чем внешний API: команда отвечает за сеть, обновления, доступ к весам и журналирование. При выборе площадки проверяйте требования компании к размещению данных. Отдельная проверка на старте — соответствие мощности сервера требованиям модели с запасом на пиковые часы: требования из карточки модели относятся к базовой конфигурации, а ваша нагрузка почти всегда шире. Перед боевым запуском пройдите короткий список проверок.
- Лицензия конкретной модели разрешает коммерческое использование.
- Веса получены из доверенного источника; контрольную сумму сверяйте, если издатель её предоставляет.
- Мощность сервера покрывает требования модели с запасом.
- Журналирование настроено без секретов и лишних персональных данных.
- Политика перезапуска и проверка здоровья сервиса испытаны на тестовом сервере.
Пройденный список отвечает на главный вопрос выбора: какая именно модель поместится на ваше железо и подойдёт по лицензии.
Какая модель нужна вашему контуру в первую очередь?
Эксплуатация контура
Живой сервис требует рутины: обновления образа по расписанию, контроль заполнения диска, резервные копии конфигурации. Нагрузку отслеживайте по времени ответа и длине очереди — эти метрики замечают проблему раньше жалоб пользователей. При росте нагрузки сначала выясните ограничение: память GPU, скорость генерации, сеть или очередь. Дополнительные реплики и балансировщик полезны лишь после проверки модели на каждой машине и общей схемы доступа. Обновление образа планируйте на часы минимальной нагрузки и держите под рукой предыдущую версию для отката. Состав работ и порядок сопровождения описаны на странице про ИИ-консалтинг: объём зависит от числа моделей и требований к доступности, детали фиксируем на созвоне.
Поднимите контейнер на тестовом сервере с одной моделью и одним пользователем — собой. Тестовые запросы покажут время ответа и потребление памяти на выбранной модели. Вторым шагом пригласите коллегу: вдвоём уже видна очередь и конкуренция за ресурсы, которую в одиночку заметить трудно. Нагрузочный прогон на ожидаемом числе одновременных пользователей идёт третьим шагом.