SGLang в Docker: первый локальный запуск и проверка модели

ГЛАВНОЕ ЗА МИНУТУ

Контейнер SGLang нужно проверять по всей цепочке: доступ GPU, загрузка модели, готовность сервера и генерация.

Для первого запуска SGLang в Docker нужны совместимая аппаратная среда, доступ ускорителя контейнеру и поддерживаемая модель. Начинайте с небольшого контрольного checkpoint и локального порта. Цель первого опыта — проверить цепочку исполнения, а не сразу получить максимальную нагрузку или доказать пригодность всех моделей на вашей карте.

Сверьте образ с окружением

Официальная установка SGLang описывает актуальные маршруты и контейнеры. Выбирайте образ для своей платформы и драйвера. Наличие Docker само по себе не подтверждает доступ GPU: эту ступень нужно проверить до загрузки весов.

Запишите GPU, драйвер, ОС и выбранный тег. В учебных примерах часто используется latest, но для воспроизводимого пилота после проверки сохраняют конкретный выпуск или digest. Иначе повторный запуск через несколько недель может получить другую среду, а изменение поведения будет трудно объяснить.

Выполните минимальный пример

Для совместимой NVIDIA-среды текущий quickstart показывает маршрут через sglang serve. Локальный учебный вариант:

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:30000:30000 \
  -v sglang-hf-cache:/root/.cache/huggingface \
  lmsysorg/sglang:latest \
  sglang serve Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 30000

Команда иллюстрирует синтаксис для подходящей среды, а не устанавливает драйвер. Привязка хостового порта ограничена локальным компьютером. Использование общего IPC и каталогов следует согласовать с условиями своей машины. Основная последовательность приведена в официальном quickstart.

Дождитесь завершения подготовки

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

После готовности получите предусмотренный сервером список моделей и выполните короткий запрос по инструкции API своей версии. Проверьте фактическое имя, формат сообщений и ограничение выхода. Небольшая успешная генерация подтверждает базовый маршрут, но не устойчивую параллельную обработку.

Проверьте сохранение файлов и повторный старт

Том в примере предназначен для повторного использования скачанных весов. Проверьте это остановкой и повторным запуском контейнера. Другие артефакты, включая компиляционные кеши, могут требовать отдельного размещения; не считайте один том универсальным сохранением всего состояния движка.

Измерьте холодный старт отдельно от старта с готовыми файлами. Эти данные влияют на восстановление после остановки оборудования и доступность по расписанию. Для сравнения с другим движком используйте руководство SGLang и vLLM, сохраняя одну модель и формат.

Если первый ответ успешен, повторите его после новой сессии запуска и сохраните итоговый тег образа. Контроль должен показывать ту же модель и ожидаемый маршрут API. Только затем переходите к более тяжёлому входу, сохраняя базовый пример отдельно от экспериментальной конфигурации нагрузки.

Подготовьте карточку пилота

Владельцу GPU полезно сохранить образ, модель, команду, журнал готовности и контрольный ответ. Следующий опыт должен проверять рабочий контекст и параллельность. Если появляется OOM, разберите фазу и бюджет по материалу memory fraction, а не меняйте сразу всю программную среду.

Финансовому партнёру карточка показывает уже выполненную подготовку и оставшееся ограничение. Так обсуждение дополнительных ресурсов можно привязать к конкретной нагрузке и понятной процедуре приёмки оборудования.