Управление развертыванием модели

Вы можете управлять развертыванием модели в GPUStack, перейдя на страницу Models - Deployments. Развертывание модели в GPUStack содержит одну или несколько реплик экземпляров модели. При развертывании GPUStack автоматически вычисляет требования к ресурсам для экземпляров модели на основе метаданных модели и соответствующим образом распределяет их по доступным рабочим процессам.

Развертывание модели

В настоящее время поддерживаются модели из Hugging Face, ModelScope и локальные пути.

Развертывание модели Hugging Face

1. Нажмите кнопку Deploy Model, затем выберите Hugging Face в раскрывающемся списке.

2. Найдите модель по названию от Hugging Face, используя строку поиска в левом верхнем углу. Например, Qwen/Qwen3-0.6B.

3. Отрегулируйте Name, Cluster, Backend, Backend Version и Replicas по мере необходимости.

4. При необходимости разверните раздел Performance для конфигурации производительности. Дополнительную информацию см. в разделе Конфигурация, связанная с производительностью.

5. При необходимости разверните раздел Scheduling для планирования конфигураций. Дополнительную информацию см. в разделе Конфигурация планирования.

6. При необходимости разверните раздел Advanced для расширенных настроек. Дополнительную информацию см. в разделе Расширенная конфигурация.

7. Нажмите кнопку Save.

Развертывание модели ModelScope

1. Нажмите кнопку Deploy Model, затем выберите ModelScope в раскрывающемся списке.

2. Найдите модель по названию от ModelScope, используя строку поиска в левом верхнем углу. Например, Qwen/Qwen3-0.6B.

3. Отрегулируйте Name, Cluster, Backend, Backend Version и Replicas по мере необходимости.

4. При необходимости разверните раздел Performance для конфигурации производительности. Дополнительную информацию см. в разделе Конфигурация, связанная с производительностью.

5. При необходимости разверните раздел Scheduling для планирования конфигураций. Дополнительную информацию см. в разделе Конфигурация планирования.

6. При необходимости разверните раздел Advanced для расширенных настроек. Дополнительную информацию см. в разделе Расширенная конфигурация.

7. Нажмите кнопку Save.

Развертывание модели локального пути

Вы можете развернуть модель по локальному пути. Путь к модели может представлять собой каталог (например, загруженный каталог модели Hugging Face) или файл (например, файл модели GGUF), расположенный в рабочих процессах. Это полезно при работе в среде с воздушным зазором.

Чтобы развернуть модель локального пути:

1. Нажмите кнопку Deploy Model, затем выберите Local Path в раскрывающемся списке.

2. Заполните Name развертывания.

3. Заполните Model Path.

4. Отрегулируйте Cluster, Backend, Backend Version и Replicas по мере необходимости.

5. При необходимости разверните раздел Performance для конфигурации производительности. Дополнительную информацию см. в разделе Конфигурация, связанная с производительностью.

6. При необходимости разверните раздел Scheduling для планирования конфигураций. Дополнительную информацию см. в разделе Конфигурация планирования.

7. При необходимости разверните раздел Advanced для расширенных настроек. Дополнительную информацию см. в разделе Расширенная конфигурация.

8. Нажмите кнопку Save.

Бэкэнд

В настоящее время GPUStack поддерживает некоторые встроенные серверные части: vLLM, SGLang, MindIE и VoxBox.

Более подробную информацию можно найти в разделе Средства вывода.

Серверная версия

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

Для встроенной серверной части vLLM или SGLang установите image_name в конфигурации развертывания, чтобы использовать образ контейнера, которого нет в каталоге исполнителей. Оставьте backend_version неустановленным: пользовательское изображение и серверную версию нельзя выбрать вместе. Если при развертывании vLLM используется пользовательский образ, распределенное выполнение по умолчанию равно mp. Если изображение включает Рэя и вы хотите его использовать, установите --distributed-executor-backend=ray в backend_parameters.

Для встроенного бэкенда vLLM или SGLang run_command предоставляет начальные аргументы запуска без исполняемого файла; GPUStack по-прежнему добавляет свои управляемые аргументы, включая обслуживающий хост и порт. Для пользовательского бэкенда run_command указывает полную команду, включая исполняемый файл. Пример см. в разделе Использование пользовательских движков инференса.

Редактирование развертывания модели

1. Найдите развертывание модели, которое вы хотите изменить, на странице списка развертываний.
2. Нажмите кнопку Edit в столбце Operations.
3. При необходимости обновите атрибуты. Например, измените Replicas, чтобы увеличить или уменьшить масштаб.
4. Нажмите кнопку Save.

Остановить развертывание модели

Остановка развертывания модели устанавливает для цели реплики нулевое значение, удаляет ее экземпляры и освобождает ресурсы. Для развертываний с включенным масштабированием по расписанию также устанавливается scaling_schedule.paused для приостановки выполнения расписания. Включенные настройки, базовые показатели и правила сохраняются. Изменения и откаты, при которых расписание включено, сохраняют его состояние паузы; в обычных развертываниях используется масштабирование реплик без состояния паузы.

1. Найдите развертывание модели, которое вы хотите остановить, на странице списка развертываний.
2. Нажмите кнопку с многоточием в столбце Operations, затем выберите Stop.
3. Подтвердите операцию.

Начало развертывания модели

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

Без включенного расписания при запуске для цели реплики устанавливается единица. Отключение масштабирования по расписанию — это отдельный выбор конфигурации. Редактирование количества реплик непосредственно в списке переключает масштабирование на ручное после подтверждения.

1. Найдите развертывание модели, которое вы хотите начать, на странице списка развертываний.
2. Нажмите кнопку с многоточием в столбце Operations, затем выберите Start.

Удалить развертывание модели

1. Найдите развертывание модели, которое вы хотите удалить, на странице списка развертываний.
2. Нажмите кнопку с многоточием в столбце Operations, затем выберите Delete.
3. Подтвердите удаление.

Экспортное и импортное развертывание

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

Экспортное развертывание

1. Найдите развертывание модели, которое вы хотите экспортировать, на странице списка развертываний.
2. Нажмите кнопку с многоточием в столбце Operations, затем выберите Export YAML.
3. Чтобы экспортировать несколько развертываний одновременно, сначала выберите их, затем выберите Export YAML в раскрывающемся списке пакетных действий над списком.

Браузер загружает файл YAML с именем <deployment-name>.yaml для одного развертывания или gpustack-deployments-<timestamp>.yaml для нескольких.

Файл содержит одно развертывание для каждого документа YAML, разделенное знаком ---. Каждый из них представляет собой тело запроса, создавшего развертывание, плюс кластер, к которому оно принадлежит, минус поля, генерируемые сервером:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# Exported from GPUStack v2.3.0 at 2026-09-07T10:00:00Z
name: qwen3-8b
cluster_name: production
source: huggingface
huggingface_repo_id: Qwen/Qwen3-8B
replicas: 2
placement_strategy: binpack
worker_selector:
  zone: a
gpu_selector:
  gpu_ids:
  - worker-1:cuda:0
  gpus_per_replica: 1
backend: vLLM
backend_version: 0.11.0
backend_parameters:
- --max-model-len=32768
env:
  HF_TOKEN: hf_xxx
enable_model_route: true
---
name: bge-m3
cluster_name: staging
source: huggingface
huggingface_repo_id: BAAI/bge-m3
replicas: 1

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

Справочник по полю

Каждое поле в файле — это то, что вы устанавливаете в форме развертывания. Ниже указано, как каждый из них называется в любом месте, в том порядке, в котором они записаны в экспортированном файле. Что означает поле, описано там, где находится этот параметр, ссылка в правом столбце.

Последняя группа полей — gpu_selector, gpu_type_selector, extended_kv_cache, speculative_config, scaling_schedule и lora_list — содержит блок, а не одно значение, и форма этого блока здесь не записана. Настройте параметры развертывания, экспортируйте их и скопируйте блок из файла: это быстрее, чем его расшифровка, и единственный способ быть в этом уверенным.

description и distributable переносятся по файлу, но не имеют никакого контроля над формой.

Что не учитывается в файле: идентификаторы, временные метки, состояние времени выполнения, такое как готовые реплики и состояние паузы, метаданные, полученные планировщиком, организация-владелец, политика доступа и пути выполнения LoRA. Если включено масштабирование по расписанию, количество экспортированных реплик является настроенным базовым уровнем, а не целевым показателем текущего окна. Сервер восстанавливает состояние времени выполнения при импорте; перезапись существующего развертывания с включенным расписанием приостановки сохраняет его состояние приостановки.

Выбор развертываний сразу из нескольких кластеров — это нормально: каждая запись записывает свой cluster_name, поэтому один файл описывает их все и импортирует обратно целиком. Кластер записывается по имени, а не по идентификатору, поэтому файл по-прежнему корректно восстанавливается в GPUStack, который нумерует свои кластеры по-другому — как это происходит при переустановке.

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

Место, где выполнялось развертывание, никогда не экспортируется. Развертывание, запланированное автоматически, вообще не имеет gpu_selector в файле, поэтому при его импорте оно планируется заново в соответствии с тем, что доступно в целевом кластере. Графические процессоры, которые вы выбрали сами, являются вашим намерением, а не результатом планирования, поэтому они экспортируются в том виде, в котором они написаны — см. примечание об импорте в другой кластер ниже.

Импорт развертываний

1. Нажмите кнопку Deploy Model, затем выберите YAML File в раскрывающемся списке.
2. Выберите файл .yaml. Файл является отправной точкой — сначала из кластера ничего не считывается — и развертывания, которые он называет, просматриваются, чтобы заполнить часть различий, доступную только для чтения. Выбор второго файла полностью заменяет первый, редактирует и все такое.
3. Решите, где будет осуществляться развертывание. Follow the file, так запускается ящик, присваивает каждой записи в кластере собственные имена cluster_name — именно это восстанавливает резервную копию, охватывающую несколько кластеров за один импорт. Запись, в которой не указан ни один кластер, возвращается к тому, в котором уже находится его развертывание. Вместо этого выберите конкретный кластер, и каждая запись попадет туда, что бы ни было написано в файле.
4. Просмотрите разницу. Левая часть — это развертывание в том виде, в котором оно хранится в GPUStack, а правая — то, что будет импортировано. Список рядом с ними начинается со всего документа, а затем индексирует каждое развертывание в нем, отмеченное Create, Update или Unchanged, с указанием количества полей, которые Update могли бы изменить; выберите запись, чтобы изменить это развертывание отдельно, или первую строку, чтобы изменить все сразу.
5. Исправьте все, что в списке отмечено красным. Причина отображается над различием, и документ снова проверяется по мере его редактирования — вскоре после того, как вы перестанете печатать, или сразу после выхода из редактора.
6. Нажмите Import. Если план заменяет какое-либо существующее развертывание, подтвердите его один раз — в диалоговом окне будет указано имя каждого заменяемого развертывания. Все пишется сразу; если какая-либо запись не удалась, ничего из файла не записывается.

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

Сам файл никогда не загружается: вместе с запросом на импорт передается только текст в редакторе.

При импорте применяются следующие правила:

• Перезапись является преднамеренной и ограниченной. Запись, имя которой соответствует существующему развертыванию, заменяет ее только в том случае, если вы подтвердите замену при импорте, и только если это развертывание остановлено. Остановлено означает масштабирование до нуля реплик и отсутствие запущенных экземпляров — уменьшение масштаба возвращается немедленно, но экземплярам требуется некоторое время для завершения работы, поэтому при импорте сразу после этого вам может потребоваться подождать. Имена развертываний уникальны во всей организации, поэтому имя в записи всегда идентифицирует только одно развертывание, независимо от того, в каком кластере оно выполняется.
• Кластер — это обычное поле записи. Измените cluster_name в редакторе или выберите другой кластер для импорта, и перезапись переместит туда развертывание. Поскольку перезапись достигает только остановленного развертывания, нет экземпляров для миграции: следующие экземпляры помещаются в тот кластер, который он к тому времени назовет. Не забудьте обновить gpu_selector и worker_selector, чтобы они соответствовали новому кластеру, или удалите их.
• Перезапись заменяет развертывание, а не объединяется с ним. Файл имеет желаемое состояние, поэтому поле, которое вы удаляете из него, возвращается к значению по умолчанию. Удаление блока gpu_selector позволяет вернуть развертывание в режим автоматического планирования. Записи под знаком плана Unchanged вообще не пишутся.
• Маршруты модели следуют за enable_model_route. Установка значения false при перезаписи удаляет маршрут, созданный развертыванием, вместе с его дочерними маршрутами LoRA. Удаление адаптера LoRA из файла удаляет маршрут этого адаптера сам по себе, а остальные остаются в покое. В любом случае, если удаляемый маршрут также обслуживает другое развертывание, вместо этого запись отклоняется — сначала отключите другие цели.
• Реплики берутся из файла. Отредактируйте replicas в редакторе, если размер целевой среды отличается от размера файла. При выборе графических процессоров убедитесь, что в gpu_selector их по-прежнему достаточно для нового подсчета, точно так же, как вы это делаете при редактировании развертывания. При включенном масштабировании по расписанию число устанавливается scaling_schedule.baseline_replicas, поскольку расписание владеет количеством реплик.
• Поле, которое GPUStack не распознает, скорее отклоняется, чем автоматически удаляется. Обычно это означает, что файл взят из более новой версии GPUStack; удалите поле, указанное в ошибке, и повторите попытку.
• Кластер, которого нет в этом GPUStack, назван, а не угадан. Импорт файла из другой установки, где кластеры называются как-то по-другому, помечает каждую запись, cluster_name которой неизвестна. Либо переименуйте его в кластер, который существует здесь, либо выберите конкретный кластер, чтобы поместить все в него. Запись, в которой вообще не упоминается кластер, для развертывания, которое еще не существует, помечается таким же образом — ее некуда поместить.
• В файле указано, в какой организации он находится. При просмотре All администратором платформы не выбрана ни одна организация, поэтому Follow the file считывает одно из кластеров имен файлов. Кластеры именования файлов из двух организаций или ни одного из них в этом GPUStack отклоняются, а не используются по умолчанию где-либо — выберите конкретный кластер для импорта или сначала переключитесь на организацию.
• Когда запись попадает в кластер, отличный от того, из которого она была экспортирована, gpu_ids под gpu_selector и worker_selector по-прежнему относятся к графическим процессорам и рабочим процессам исходного кластера. Измените их на значения из нового кластера или удалите их, чтобы планировщик мог выполнить развертывание; в противном случае импорт не удастся, поскольку графические процессоры не могут быть найдены.

История изменений развертывания

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

1. Найдите развертывание в списке развертывания модели.
2. Откройте меню Operations и выберите Revision history.
3. Выберите версию, чтобы сравнить ее с ее непосредственным предшественником в файле различий YAML, доступном только для чтения. Например, если выбрать v2, слева отобразится v1, а справа — v2. Последняя редакция остается доступной для проверки. Первоначальная версия или версия, предшественница которой была удалена или сокращена, вместо этого показывает свою полную конфигурацию.
4. Нажмите действие Roll back to this revision в строке более старой версии. Тот же ящик переключается на предварительный просмотр под названием Roll back <name> to vN, сравнивая текущую конфигурацию развертывания с этой версией. Список редакций скрыт при просмотре отката. Нажмите Back to history, чтобы вернуться к предыдущему выбору и странице. Чтобы применить конфигурацию, нажмите Roll back прямо в предварительном просмотре; дополнительное диалоговое окно подтверждения не отображается. Последняя версия не имеет действия отката. Откат отключается, если конфигурации совпадают. Сервер проверяет конфигурацию, используя те же правила, что и при обычном редактировании. Успешный откат, при котором изменяется конфигурация, создает новую ревизию.

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

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

В представлениях редакций используется то же форматирование конфигурации, что и при импорте и экспорте YAML: неустановленные поля модели опускаются, а поля следуют порядку схемы. Явные значения, такие как false, 0 и пустые переопределения, остаются видимыми. Очистка настройки выглядит как удаление ее строки из файла diff. Такое форматирование влияет только на отображаемую конфигурацию; при откате используется полный сохраненный снимок.

В предварительном просмотре имеется флажок Restart on rollback, установленный по умолчанию, слева от нижнего колонтитула рядом с кнопками действий. После сохранения восстановленной конфигурации пользовательский интерфейс запрашивает перезапуск развертывания, чтобы воссоздать ее экземпляры. Снимите флажок, чтобы сохранить без перезапуска; желтое уведомление появляется, когда изменения конфигурации требуют повторного создания экземпляров. После успешного отката и любого запрошенного перезапуска ящик закрывается, а список развертывания обновляется. Если конфигурация сохранена, но перезапуск не удался, ящик остается открытым, сообщает об обоих результатах и выдает Retry restart, что не повторяет откат. Успешная повторная попытка также закроет ящик и обновит список. Непосредственный вызов API отката восстанавливает только конфигурацию.

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

Сохранение редакций

В развертываниях по умолчанию сохраняются 10 старые версии в дополнение к последней. Форма развертывания не предоставляет этот параметр. Опытные пользователи могут настроить revision_history_limit через API. Установите значение 0, чтобы сохранить только последнюю версию. Понижение предела немедленно удаляет лишнюю историю, начиная с самых старых записей, без создания версии конфигурации.

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

История имеет те же ограничения по организации и доступу, что и редактирование развертывания, и недоступна для рабочих и участников кластерной СИСТЕМЫ. Переменные среды сохраняются с их исходными значениями, поэтому более старая версия может сохранять учетные данные до тех пор, пока эта версия не будет удалена или автоматически сокращена.

Просмотр экземпляра модели

1. Найдите развертывание модели, которую хотите проверить, на странице списка развертываний.
2. Щелкните символ >, чтобы просмотреть список экземпляров развертывания.

Удалить экземпляр модели.

1. Найдите развертывание модели, которую хотите проверить, на странице списка развертываний.
2. Щелкните символ >, чтобы просмотреть список экземпляров развертывания.
3. Найдите экземпляр модели, который хотите удалить.
4. Нажмите кнопку с многоточием для экземпляра модели в столбце Operations, затем выберите Delete.
5. Подтвердите удаление.

Просмотр журналов экземпляров модели

1. Найдите развертывание модели, которую хотите проверить, на странице списка развертываний.
2. Щелкните символ >, чтобы просмотреть список экземпляров развертывания.
3. Найдите экземпляр модели, который хотите проверить.
4. Нажмите кнопку View Logs для экземпляра модели в столбце Operations.

Конфигурация, связанная с производительностью

GPUStack предоставляет следующие параметры конфигурации для оптимизации производительности вывода модели.

Расширенный KV-кэш

Вы можете включить расширенный кэш KV, чтобы разгрузить кэш KV в память ЦП или удаленное хранилище. Эта функция особенно полезна для установок с ограниченной памятью графического процессора, требующих большой длины контекста. Внутри GPUStack настраивает разгрузку кэша KV, которую поддерживает выбранный бэкенд и платформа, например LMCache или HiCache.

Доступные варианты:

• Отношение ОЗУ к видеопамяти: соотношение системной оперативной памяти к видеопамяти графического процессора, используемой для кэша KV. Например, 2.0 означает, что кэш в оперативной памяти может быть в два раза больше, чем видеопамять графического процессора.
• Максимальный размер ОЗУ: максимальный размер KV-кэша, хранящегося в системной памяти (ГиБ). Если установлено, это значение переопределяет RAM-to-VRAM Ratio.
• Размер блоков кэша: количество токенов на фрагмент кэша KV. Не применимо к vLLM в CANN, где разъем выгружает целые блоки KV и повторно использует их с размером блока двигателя.

Эта функция работает только для определенных бэкендов и платформ.

Матрица совместимости

При использовании vLLM на CANN для расширенного кэша KV требуется vLLM Ascend v0.21.0 или новее, и он недоступен на Atlas 300I Duo (310P).

Конфигурация планирования

Режим расписания

Авто

GPUStack автоматически распределяет экземпляры модели по соответствующим графическим процессорам/воркерам на основе текущей доступности ресурсов.

• Стратегия размещения

Распределение: сделайте ресурсы всего кластера относительно равномерно распределенными между всеми воркерами. Это может привести к большей фрагментации ресурсов одного воркера.

Binpack: установите приоритет общего использования ресурсов кластера, уменьшая фрагментацию ресурсов на рабочих процессах/графических процессорах.

• Выбор рабочего

При настройке планировщик развернет экземпляр модели на воркере, содержащий указанные метки.

1. Перейдите на страницу Workers и отредактируйте нужного воркера. Назначьте воркеру собственные метки, добавив их в раздел меток.

2. Перейдите на страницу Deployments и нажмите кнопку Deploy Model. Разверните раздел Scheduling и введите ранее назначенные метки воркеров в конфигурацию Worker Selector. Во время развертывания экземпляр модели будет назначен соответствующему воркеру на основе этих меток.

Руководство

Этот тип расписания позволяет пользователям указывать, на каком графическом процессоре развертывать экземпляр модели.

• Выбор графического процессора

Выберите один или несколько графических процессоров из списка. Экземпляр модели попытается развернуться на выбранном графическом процессоре, если позволяют ресурсы.

• ГП на реплику

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

Вручную: выберите из раскрывающегося списка количество графических процессоров, которые должна использовать каждая реплика.

Расширенная конфигурация

GPUStack поддерживает индивидуальные конфигурации для развертывания модели.

Категория модели

Категория модели помогает упорядочивать и фильтровать модели. По умолчанию GPUStack автоматически определяет категорию модели на основе метаданных модели. Вы также можете настроить категорию, выбрав ее из раскрывающегося списка.

Параметры серверной части

Введите параметры серверной части, которую вы хотите настроить при запуске модели. Поддерживаемые форматы параметров:

Полный список поддерживаемых параметров см. в разделе Средства вывода.

Переменные среды

Переменные среды, используемые при запуске модели. Эти переменные передаются серверному процессу при запуске.

Адаптеры LoRA

LoRA (адаптация низкого ранга) — это эффективный по параметрам метод точной настройки, который адаптирует базовую модель к конкретной области путем загрузки небольших файлов адаптеров вместо повторного обучения полных весов. GPUStack позволяет монтировать несколько адаптеров LoRA на одном развернутом базовом LLM и автоматически создает один модельный маршрут для каждого адаптера.

Разверните раздел Advanced в форме развертывания, найдите LoRA Adapters и добавьте адаптеры один за другим:

• Выберите адаптер из раскрывающегося списка. Список поддерживает поиск. Если ваш адаптер не отображается, сначала подтвердите с помощью Hugging Face или ModelScope, что модель действительно его предоставляет, а затем вставьте идентификатор репозитория в поле поиска, чтобы выбрать его.
• LoRA name: введите чистое имя адаптера, например alpaca.

После развертывания GPUStack автоматически создает модельный маршрут для каждого адаптера LoRA с именем <base-model-name>:<adapter-name>. Чтобы переключить адаптеры, установите в поле model OpenAI-совместимого API соответствующее имя маршрута. Все адаптеры используют один и тот же экземпляр графического процессора. GPUStack автоматически вводит аргументы запуска серверной части, такие как --enable-lora, поэтому вам обычно не нужно повторять их под Backend Parameters.

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

Разрешить разгрузку процессора

Если разгрузка ЦП включена, GPUStack выделит память ЦП, если ресурсов ГП недостаточно. Необходимо правильно настроить бэкенд инференса для использования гибридного вывода ЦП+ГП или полного вывода ЦП.

Разрешить распределённый инференс между воркерами

Включить распределённый инференс для нескольких воркеров. Основной экземпляр модели будет взаимодействовать с экземплярами серверной части одного или нескольких других воркеров, передавая им вычислительные задачи.

Автоматический перезапуск при ошибке

Включите автоматический перезапуск экземпляра модели в случае возникновения ошибки. Эта функция обеспечивает высокую доступность и надежность экземпляра модели. В случае возникновения ошибки GPUStack автоматически попытается перезапустить экземпляр модели, используя стратегию экспоненциальной задержки. Задержка между попытками перезапуска увеличивается в геометрической прогрессии, вплоть до максимального интервала в 5 минут. Такой подход предотвращает перегрузку системы из-за частых перезапусков в случае постоянных ошибок.

Включить универсальный прокси.

Хотя интеграция с API-интерфейсами, совместимыми с OpenAI, является обычной практикой, у пользователей могут быть разные требования для их сценариев использования. GPUStack поддерживает любые API инференса, кроме OpenAI-совместимых, и делает его более гибким для разработки приложений ИИ.

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

Форма на основе пути (рекомендуется)

Добавьте идентификатор маршрута числовой модели к префиксу прокси — /model/proxy/<model_route_id>/<upstream-path> — и GPUStack отправит запрос к целям этого маршрута. Никакого дополнительного заголовка не требуется.

1
2
3
4
5
6

# Assume the model route id is 42.
curl http://<server-url>/model/proxy/42/embed \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <GPUSTACK_API_KEY>" \
  -d '{"inputs":["What is Deep Learning?", "Deep Learning is not..."]}'

Шлюз удаляет /model/proxy/<id> перед пересылкой, поэтому вышестоящий бэкенд инференса видит:

1
2
3
4

curl http://<inference-server-url>/embed \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"inputs":["What is Deep Learning?", "Deep Learning is not..."]}'

Идентификатор маршрута модели стабилен при переименовании, его можно найти на странице сведений о модели или получить из GET /v2/model-routes.

Форма на основе заголовка (устарела)

1
2
3
4
5
6

curl http://<server-url>/model/proxy/embed \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <GPUSTACK_API_KEY>" \
  -H "X-GPUStack-Model: bge-m3" \
  -d '{"inputs":["What is Deep Learning?", "Deep Learning is not..."]}'

Префикс пути /model/proxy удаляется перед пересылкой. Вы должны предоставить либо заголовок X-GPUStack-Model, либо атрибут model в теле JSON, чтобы шлюз мог разрешить целевую модель. На вышестоящем сервере вывода запрос выглядит так:

1
2
3
4
5

curl http://<inference-server-url>/embed \
  -X POST \
  -H "Content-Type: application/json" \
  -H "X-GPUStack-Model: bge-m3" \
  -d '{"inputs":["What is Deep Learning?", "Deep Learning is not..."]}'