В этом материале
Модель Workspace оборачивает существующую базовую модель vLLM; её идентификатор, инструкции и доступ не заменяют модель сервера.
При подключении Open WebUI к vLLM различайте идентификатор модели сервера и оболочку Workspace, показанную пользователям. Оболочка объединяет инструкции и ресурсы, но сама по себе не переименовывает работающие веса и не добавляет возможностей вычислительному серверу.
Конкретная граница приложения
Откройте Workspace → Models и создавайте запись только после проверки базовой модели через соединение провайдера. Выбор Base Model указывает генератор, а ID Workspace и отображаемое название обозначают повторно используемую конфигурацию. В редакторе задайте нужную системную инструкцию, оставив необязательные знания и инструменты пустыми для первой пробы. Документация различает скрытые базовые модели, обычную видимость списка и доступ к ресурсам. Администратор способен выбрать скрытую базовую модель, но это не подтверждает возможность прямого выбора каждой учётной записью. Поэтому проверяйте аудиторию оболочки и пользователя испытания, а не только наличие знакомого названия. Отдельная запись двух идентификаторов помогает понять, где менялась инструкция, а где фактически менялся генератор ответа. Выполнение оболочки проверяет доступ к ней и базовой модели. Скрытие доступной базы из списка отличается от запрета её использования целевыми пользователями (Open WebUI Models) (Open WebUI Workspace).
Практический маршрут
Начните с существующего совместимого endpoint и независимо проверьте идентификатор выдаваемой модели. Добавьте совместимое соединение в Open WebUI и изучите получение каталога. До создания записи Workspace выберите базовую модель напрямую. Затем создайте оболочку с понятным названием и узкой инструкцией, явно указав базовую модель и область видимости для пользователей (Open WebUI compatible provider guide).
Разобранный пример
Создайте помощника проверки кода, который получает функцию и перечисляет неопределённости до предложения изменений. Сначала испытайте базовую модель обычным вопросом. Затем передайте оболочке вымышленную вспомогательную функцию. Сравните выполнение инструкции при неизменном сервере и повторите проверку под целевой учётной записью без прав администратора. Так различаются поведение инструкции и реальная доступность настройки.
| Проверка | Запись |
|---|---|
| Идентификатор сервера | Название модели, выдаваемое существующим endpoint vLLM для обращения клиента. |
| Идентификатор оболочки | Запись Workspace, предназначенная для инструкций помощника проверки кода. |
| Результат доступа | Может ли предполагаемый пользователь выбрать оболочку и завершить пробную беседу. |
Как правильно прочитать сбой
Проверка совместимого соединения обычно запрашивает каталог моделей. Endpoint может поддерживать беседу, но не удовлетворять этому же пути получения каталога. Поэтому сохранение соединения, успешная проверка и успешный чат являются разными свидетельствами. Если запись видна только части пользователей, отдельно изучите разрешённый список моделей и доступ к самой оболочке.
Что завершает проверку
Итоговая запись должна связывать видимую оболочку с фактической базовой моделью и областью доступа. Сохраните возможность прямой проверки базовой модели: тогда последующее изменение инструкций можно разобрать без немедленной замены вычислительного сервера и потери исходного сравнения.
Связанные материалы: vLLM served-model-name: почему API не находит загруженную модель, llama.cpp server: локальный API из GGUF-модели.