В этом материале
Localhost относится к среде клиента; внутри контейнера это не обязательно хост с запущенным vLLM.
Если vLLM не открывается по localhost, сначала определите, где находится клиент и где работает сервер. Адрес 127.0.0.1 указывает на текущую сетевую среду: для браузера, контейнера и удалённой машины это могут быть разные места. Проверяйте готовность процесса, привязку интерфейса и публикацию порта отдельно от модели и GPU.
Нарисуйте короткую схему соединения
Запишите цепочку словами: браузер на ноутбуке → локальный порт хоста → порт контейнера → процесс vLLM. Если клиент тоже в контейнере, добавьте его отдельным узлом. Такая схема часто сразу показывает, почему обращение к собственному localhost не достигает соседнего процесса.
Не начинайте с изменения всех сетевых правил. Сначала сохраните адрес запроса, место его выполнения и ожидаемый сервер. В инструкции Docker vLLM показана публикация порта, а параметры интерфейса и порта перечислены в справочнике serve.
Убедитесь, что движок готов
Проверьте журнал запуска. Контейнер может существовать, пока модель скачивается или компилируется. Если процесс завершился с OOM, настройка порта не вернёт его к работе. Если он ещё готовится, преждевременный перезапуск начинает подготовку заново.
После готовности обратитесь к HTTP-интерфейсу из ближайшей доступной среды. Затем получите /v1/models и выполните короткий запрос. Разница между живым процессом и работающей генерацией разобрана в проверке готовности. Сохраняйте точный тип ошибки: отказ соединения отличается от HTTP-ответа с ошибкой модели.
Проверьте две стороны опубликованного порта
В записи -p 127.0.0.1:8000:8000 первое значение порта относится к хосту, второе — к контейнеру. Если сервер внутри слушает другой порт, публикация должна соответствовать этому выбору. Номер снаружи не обязан совпадать с внутренним, но различие нужно явно записать.
Сервер внутри контейнера также должен слушать доступный контейнеру интерфейс. Привязка только к его внутреннему loopback способна помешать маршруту через опубликованный порт. Прежде чем менять привязку, проверьте реальную команду и журнал, а не предполагаемый конфигурационный файл.
Разделите локальный доступ и внешнее подключение
Публикация на 127.0.0.1 удобна для проверки с хоста. Она не обещает доступ с другого компьютера. Для удалённого клиента требуется отдельный согласованный маршрут и правила доступа. Не расширяйте интерфейс без необходимости просто ради устранения локальной ошибки.
Практический тест состоит из трёх строк отчёта: запрос рядом с процессом, запрос с хоста, запрос из целевого приложения. Укажите статус и время каждого. Если первые два успешны, а третий нет, исследуйте настройки приложения, базовый URL и путь endpoint, сохраняя серверную конфигурацию неизменной.
Если меняете карту или движок, сохраните прежнюю сетевую схему как контроль. Связь сетевой доступности с производительностью разобрана в пилотном чек-листе: каждую ступень полезно подтверждать своим результатом.
Практические выводы
Владелец GPU может подготовить полезный результат даже до нагрузки: точный адрес, версия движка и успешный контрольный запрос. Добавьте информацию о контейнерной сети и доступном временном окне. Это сокращает повторную диагностику при подключении оператора к пилоту.
Для финансового партнёра важно отделить сетевую подготовку от нехватки оборудования. Открытый порт не подтверждает производительность, а закрытый не доказывает слабость GPU.