Описание программы¶

Полное наименование: Компонент обработки мультимодальных данных

Обозначение: LPI-VAP-MLLM

Краткое наименование (для работы с документом): «Обработка мультимодальных данных»

Программный продукт: «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0»)

Стандарт: ГОСТ 19.402-78

Аннотация¶

Настоящий документ содержит описание компонента обработки мультимодальных данных (LPI-VAP-MLLM), являющегося расширением программного продукта «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0»; далее — Платформа 4.0). Компонент предназначен для организации прикладной обработки изображений с применением мультимодальных больших языковых моделей и получения результатов, пригодных для автоматического использования средствами Платформы 4.0.

Компонент обеспечивает настройку подключений к MLLM и экземпляров выполнения, создание и версионирование промптов, ведение эталонных изображений, назначение камер и условий запуска. Обработка может запускаться пользователем на отдельном изображении, автоматически по расписанию либо при поступлении события заданной категории. Задания выполняются асинхронно с учётом доступного параллелизма. Ответ MLLM проверяется по JSON Schema, сохраняется в журнале и в зависимости от типа промпта используется для классификации, локализации, создания или верификации события и консолидации результатов нескольких камер.

Исполняемые составные части поставляются контейнерными образами и размещаются в кластере Kubernetes Платформы 4.0 на серверных ЭВМ архитектуры x86 под управлением «Московской серверной операционной системы». Управляющие сервисы размещаются на мастер-ноде кластера, используют процессорные ресурсы, PostgreSQL, Kafka, Redis и S3-совместимое объектное хранилище; сервер MLLM размещается на выделенной LLM-ноде и выполняет инференс на одном или нескольких графических ускорителях класса NVIDIA H100 или A30 согласно выбранному типу конфигурации. Пользователь обращается к компоненту через общий веб-интерфейс Платформы 4.0 с персонального компьютера или тонкого клиента; установка серверных частей и весов MLLM на рабочее место не требуется.

Серверная прикладная логика реализована преимущественно на Python, пользовательский интерфейс — на TypeScript и JavaScript. Для представления, хранения, конфигурации и обмена данными также используются HTML, CSS, SQL, JSON, JSON Schema, YAML и Protocol Buffers. Объём программы определяется составом контейнерных образов, клиентского приложения и служебных ресурсов конкретной версии поставки и должен фиксироваться по ведомости образов и результатам сборки. Размер весов выбранной MLLM и её кэша фиксируется отдельно при расчёте общего объёма размещения. Пользовательские и эталонные изображения, промпты и результаты выполнения относятся к данным компонента и в объём программы не включаются.

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

1. Общие сведения¶

1.1. Обозначение и наименование программы¶

Компонент предназначен для организации обработки изображений с применением мультимодальных больших языковых моделей (далее — MLLM). В компоненте выполняются настройка подключений к MLLM, создание и версионирование промптов, назначение источников данных и расписаний, ручная проверка промптов на отдельных кадрах, параллельное выполнение заданий, сохранение результатов и их представление в структурированном формате JSON. Компонент может формировать результат по одному источнику либо консолидировать результаты нескольких камер. Классы решаемых задач и границы функциональной ответственности компонента приведены в разделе 2.

Компонент состоит из функциональных блоков, приведённых в таблице 1.1.1. Перечень составных частей каждого блока, их функции, входы и выходы приведены в подразделе 3.3 и в настоящем подразделе не повторяются. Имена сервисов являются техническими обозначениями в схеме развёртывания Платформы 4.0 и не являются самостоятельными программными продуктами.

Таблица 1.1.1 — Функциональные блоки компонента.

Схема 1.1 — Место LPI-VAP-MLLM в Платформе 4.0.

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

1.2. Программное обеспечение, необходимое для функционирования программы¶

Компонент исполняется на серверных вычислительных средствах в составе Платформы 4.0 и поставляется набором контейнерных образов. Состав программного обеспечения приведён для целевого контура заказчика. Конкретные версии контейнерных образов, MLLM, драйверов и библиотек должны быть зафиксированы в формуляре целевой поставки и согласованы между собой.

Уровни программного обеспечения, необходимого для функционирования компонента, приведены на схеме 1.2; состав каждого уровня раскрыт в п. 1.2.1–1.2.5.

Схема 1.2 — Уровни программного обеспечения, необходимого для функционирования компонента.

1.2.1. Системное программное обеспечение¶

Сервисы управления подключениями и промптами, шлюз формирования запроса и консолидация результатов исполняются на процессорах мастер-ноды и сами по себе не требуют графического ускорителя. Графические ускорители необходимы серверу MLLM, размещаемому на LLM-ноде. Их количество, модель, видеопамять и схема распределения вычислений выбираются по одному из типов конфигурации, приведённых в разделе 4.

1.2.2. Общесистемные (инфраструктурные) сервисы Платформы 4.0¶

Приведённые версии подтверждены по совместимому составу программных средств. При формировании целевой поставки они подлежат сверке с ведомостью контейнерных образов. PostgreSQL и MinIO содержат постоянные данные и включаются в резервное копирование. Изображения во временном хранилище Redis имеют ограниченный срок жизни и не должны рассматриваться как долговременная копия пользовательских данных.

1.2.3. Среды исполнения и системные библиотеки¶

Основные библиотеки и фреймворки приведены в таблице.

Диапазон версии означает, что разные составные части используют совместимые, но не обязательно одинаковые версии библиотеки. Для эксплуатации применяются готовые контейнерные образы; установка Python-, Node.js- или ML-библиотек непосредственно в целевую операционную систему не требуется. Точный состав каждого образа фиксируется в формуляре поставки.

1.2.4. Смежные компоненты Платформы 4.0 и внешние программные средства¶

Самостоятельное взаимодействие LPI-VAP-MLLM с СУДИР и регистрация компонента как отдельного OIDC-клиента не предусматриваются. Аутентификацию пользователя выполняет LPI-VAP-CORE; компонент получает пользовательский контекст через защищённый контур Платформы 4.0 и авторизует каждую операцию.

Получение и декодирование видеопотока, базовая видеоаналитика, управление камерами и долговременное хранение событий не входят в границу ответственности LPI-VAP-MLLM. Компонент использует подготовленные кадры и сведения о событиях, а результат передаёт соответствующим средствам Платформы 4.0.

1.2.5. Клиентское программное обеспечение¶

Рабочее место пользователя должно иметь сетевой доступ к веб-интерфейсу Платформы 4.0 и веб-браузер с поддержкой HTML5, JavaScript, WebSocket и загрузки файлов. Могут использоваться Google Chrome версии не ниже 80, Яндекс.Браузер или Mozilla Firefox сопоставимой поддерживаемой версии. Браузер должен разрешать отображение изображений и работу редактора структурированных данных. Установка исполняемых частей компонента, MLLM или средств GPU на рабочее место пользователя не требуется.

1.3. Языки программирования¶

MLLM исполняется средствами готового контейнерного образа vLLM, PyTorch и CUDA. Низкоуровневые языки реализации этих сторонних средств не являются языками прикладной логики LPI-VAP-MLLM и отдельно в таблице не перечисляются.

Точные версии программного обеспечения и библиотек целевой поставки указываются в формуляре.

2. Функциональное назначение¶

Компонент обработки мультимодальных данных LPI-VAP-MLLM предназначен для настройки и выполнения задач анализа изображений с применением мультимодальных больших языковых моделей. Компонент объединяет в одном контуре управление подключениями к MLLM, подготовку и версионирование промптов, назначение источников и условий запуска, передачу заданий модели, проверку структуры ответа, хранение результатов и их представление пользователю.

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

LPI-VAP-MLLM не получает и не декодирует видеопоток непосредственно, не управляет камерами, не выполняет базовую видеоаналитику и не является средством обучения или дообучения MLLM. Получение кадров, регистрация и долговременное хранение событий, а также предоставление общих справочников и прав доступа выполняются смежными компонентами Платформы 4.0. Сервер MLLM загружает модель и производит вычисления, а LPI-VAP-MLLM управляет прикладным циклом её использования.

2.1. Классы решаемых задач¶

Основной функциональный цикл показан на схеме 2.1.

Схема 2.1 — Функциональный цикл выполнения мультимодального промпта.

2.2. Сведения о функциональных ограничениях на применение¶

2.3. Показатели назначения¶

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

Таблица 2.3.1 — Показатели назначения и соответствующие конфигурации сервера MLLM.

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

Показатели обеспечиваются при следующих условиях:

1. состав оборудования соответствует выбранному типу конфигурации, а версии драйвера графической подсистемы, образа сервера MLLM и варианта модели зафиксированы формуляром поставки;
2. длина контекста запроса, число и разрешение изображений не превышают предельных значений выбранного типа конфигурации;
3. модель загружена и прогрета, посторонняя нагрузка на графические ускорители отсутствует;
4. скорость обработки относится к устойчивому режиму и учитывает запросы, завершившиеся структурно корректным ответом; ошибки и превышения времени ожидания учитываются отдельно;
5. параметры параллелизма, длины очереди и генерации соответствуют настройкам целевой поставки.

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

3. Описание логической структуры¶

LPI-VAP-MLLM имеет сервисно-ориентированную логическую структуру. Центральная составная часть хранит прикладную конфигурацию, принимает задания, распределяет их между доступными экземплярами MLLM и обрабатывает ответы. Отдельные составные части формируют запрос к модели, выполняют GPU-инференс и, при необходимости, консолидируют результаты нескольких камер. Пользовательский интерфейс, камеры, получение кадров и хранилище событий относятся к смежным компонентам Платформы 4.0.

3.1. Алгоритм программы¶

Работа компонента состоит из двух связанных циклов:

1. конфигурационного — создание подключения, промпта, примеров, источников и условий запуска;
2. исполнительного — получение изображения, постановка задания в очередь, вызов MLLM, проверка и применение результата.

Общий алгоритм выполнения показан на схеме 3.1.

Схема 3.1 — Общий алгоритм выполнения мультимодального задания.

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

3.1.1. Создание и проверка подключения к MLLM¶

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

1. Пользователь с соответствующим разрешением задаёт наименование, поддерживаемый тип программного интерфейса, наименование и версию модели.
2. Для подключения задаётся один или несколько экземпляров выполнения. Для каждого экземпляра указываются адрес API, допустимое число параллельных соединений и, если требуются, реквизиты аутентификации и прокси-сервер.
3. Пользовательский интерфейс проверяет заполнение обязательных полей и передаёт данные через API-шлюз в inf-llm-integration.
4. Сервис сохраняет подключение и экземпляры выполнения в PostgreSQL. Каждому объекту присваивается внутренний идентификатор.
5. Техническая доступность проверяется обращением к служебной точке получения моделей либо контрольным мультимодальным запросом — в зависимости от интерфейса целевой MLLM. Проверяются разрешение имени и маршрутизация, установление защищённого соединения, аутентификация, наличие выбранной модели и получение ответа.
6. При положительном результате пользователь оставляет или переводит подключение в активное состояние. При отрицательном результате подключение следует сохранить неактивным до устранения причины. Отключение запрещает назначение ему новых заданий, не удаляя конфигурацию и ранее полученные результаты.

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

3.1.2. Создание и версионирование промпта¶

При создании промпта пользователь задаёт наименование, описание, текст задания, тип обработки и подключение к MLLM. Для автоматического использования результата задаётся JSON Schema или эквивалентное описание обязательных полей. В схеме указываются признаки события и нарушения, описание и допустимые категории, а для локализации — координаты областей и их метки. Для проверки события задаётся структура решения о подтверждении или отклонении.

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

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

3.1.3. Назначение источников и условий запуска¶

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

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

3.1.4. Формирование мультимодального запроса¶

При запуске по расписанию или категории исполняющий контур помещает кадр во временное хранилище и передаёт в задание его идентификатор. При ручном запуске аналогичным образом регистрируется загруженный файл. inf-llm-integration получает двоичные данные по идентификатору и сохраняет рабочую копию в объектном хранилище. При проверке события используется изображение, связанное с уже зарегистрированным событием; при необходимости на него наносится область исходной детекции.

Мультимодальный контекст формируется в следующем порядке:

1. выбирается текущая версия промпта и связанное активное подключение;
2. добавляются системные инструкции и текст пользовательского задания;
3. первым целевым изображением помещается текущий кадр либо кадр события;
4. следом добавляются дополнительные изображения события и выбранные эталонные примеры, если они предусмотрены промптом;
5. добавляются идентификатор камеры, категория и временная метка события, если они требуются шаблону;
6. задаются параметры генерации и схема ожидаемого структурированного ответа;
7. запрос кодируется в формат поддерживаемого MLLM API; изображение передаётся как двоичные данные, строка Base64 или защищённая ссылка в зависимости от настроенного адаптера.

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

3.1.5. Выполнение запроса и разбор ответа¶

После подготовки входных данных inf-llm-integration создаёт постоянную запись задания со ссылками на промпт, MLLM, камеру, изображение и время кадра. Диспетчер выбирает задания в состоянии ожидания и распределяет их по экземплярам выполнения. Число одновременно переданных заданий одному экземпляру не превышает настроенное значение его пропускной способности; остальные задания остаются в очереди.

Для назначенного задания создаётся запись выполнения с уникальным идентификатором, временем начала и исходным состоянием. Адаптер выбирается по типу подключения. При использовании поставляемого сервера запрос проходит через llm-agent, который формирует OpenAI-совместимые сообщения, подставляет изображения и схему ответа, после чего вызывает llm-vllm. Сервер модели возвращает ответ адаптеру, а затем — в inf-llm-integration.

Состояния исполнительного цикла приведены в таблице 3.1.1.

Таблица 3.1.1 — Состояния выполнения мультимодального задания.

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

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

3.1.6. Консолидация и применение результатов¶

Проверенный ответ вместе с параметрами запуска сохраняется в журнале выполнений и доступен для просмотра независимо от дальнейшего применения. Затем выбирается одна из следующих ветвей:

• если ответ является итоговым событием или нарушением и связан с камерой, inf-llm-integration формирует типизированное сообщение события с категориями, описанием, изображением, временем исходного кадра, идентификатором промпта и исходным JSON;
• если ответ является частным нарушением и содержит правило консолидации, он передаётся в inf-llm-event-consolidation вместе с камерой, изображением, категорией и сроком актуальности;
• если выполнялся проверочный промпт, результат передаётся хранилищу событий как решение о подтверждении или отклонении, комментарий и сведения о применённом промпте; при предусмотренном схемой решении событие может быть помечено на удаление;
• если признаки события и нарушения отрицательны, результат остаётся в журнале выполнений и новое событие не создаётся.

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

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

3.2. Используемые методы¶

3.3. Структура программы с описанием функций составных частей¶

Структурная схема компонента и его окружения показана на схеме 3.2. Сплошной границей выделены составные части LPI-VAP-MLLM; внешние блоки относятся к Платформе 4.0 и предоставляют компоненту необходимые данные или принимают его результаты.

Схема 3.2 — Логическая структура LPI-VAP-MLLM и связи с окружением.

Таблица 3.3.1 — Функции составных частей LPI-VAP-MLLM.

Расписания и связи промптов с камерами хранятся средствами управления камерами Платформы 4.0, поскольку исполняются в контуре получения кадров. LPI-VAP-MLLM хранит сам промпт и результаты его выполнения, а в задании получает идентификаторы промпта, камеры и изображения. Точные версии и состав контейнерных образов должны соответствовать формуляру целевой поставки.

Все служебные соединения выполняются во внутренних сетях развёртывания. Пользователю и внешним клиентам предоставляются только маршруты API-шлюза Платформы 4.0. Прямой внешний доступ к PostgreSQL, MinIO, Kafka, Redis, серверу MLLM и шлюзу формирования запроса не требуется.

3.4. Связи программы с другими программами¶

Таблица 3.4.1 — Связи LPI-VAP-MLLM с другими программами и инфраструктурными сервисами.

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

4. Используемые технические средства¶

Компонент эксплуатируется на серверных технических средствах заказчика в составе Платформы 4.0. Составные части поставляются контейнерными образами и размещаются в кластере Kubernetes Платформы 4.0: управляющие сервисы — на мастер-ноде, на которой работает Центральный модуль управления данными и распределёнными вычислениями (LPI-VAP-CORE), сервер мультимодальной модели — на выделенной LLM-ноде. Установка исполняемых частей компонента на рабочее место пользователя не требуется: работа выполняется через веб-браузер.

Составные части распределяются по типам узлов кластера:

• мастер-нода — сервис управления подключениями, промптами и заданиями, шлюз формирования мультимодального запроса и сервис консолидации результатов, а также используемые ими общесистемные хранилища, брокер сообщений и временное хранилище изображений; графический ускоритель этим составным частям не требуется;
• LLM-нода — сервер мультимодальной модели: загрузка весов MLLM и выполнение мультимодальных запросов на графических ускорителях. LLM-нода выделяется отдельно; совмещение её назначения с другими не применяется, поскольку ускорители сервера модели заняты постоянно.

Управляющим сервисам выделяется доля ресурсов мастер-ноды, соответствующая позиции поставки LPI-VAP-MLLM (подраздел 4.3). LLM-нода предоставляется заказчиком в одном из трёх нормативных типов конфигурации (п. 4.3.2); выбор типа определяет показатели назначения подраздела 2.3. Качественные требования, минимально допустимые версии программной среды и удельные величины для расчёта ёмкости приведены в подразделе 4.4 в форме «не ниже». Приведённые характеристики являются требованиями к целевому контуру, а не описанием оборудования разработки.

4.1. Серверные технические средства¶

4.1.1. Размещение составных частей на узлах кластера¶

Таблица 4.1.1 — Размещение составных частей компонента на узлах кластера.

Мастер-нода входит в состав инфраструктуры Платформы 4.0 и не выделяется под компонент отдельно. Веб-интерфейс, шлюз прикладных интерфейсов, средства аутентификации и разграничения доступа, PostgreSQL, объектное хранилище, брокер сообщений и временное хранилище предоставляются Платформой 4.0; компонент использует в них собственные базы данных, бакеты и топики. LLM-нода в позицию поставки LPI-VAP-CORE не входит и предоставляется для LPI-VAP-MLLM. Способ установки графических ускорителей должен обеспечивать их прямую доступность серверу MLLM, требуемую полосу PCI Express и согласованную работу драйвера, CUDA, NCCL и среды исполнения контейнеров. При виртуальном размещении должен быть предусмотрен поддерживаемый способ передачи ускорителя виртуальной машине или контейнеру без уменьшения доступной видеопамяти ниже значения выбранного типа конфигурации.

4.1.2. Схема развёртывания¶

Схема 4.1 — Размещение составных частей LPI-VAP-MLLM на узлах кластера Платформы 4.0.

4.1.3. Требования к техническим средствам узлов¶

Таблица 4.1.2 — Требования к техническим средствам узлов, на которых размещается компонент.

Количественные значения по группам таблицы 4.1.2 установлены подразделом 4.3 (ресурсы, выделяемые компоненту, и типы конфигурации LLM-ноды) и таблицей 4.4.1 (требования «не ниже») и в настоящем подразделе не повторяются.

4.1.4. Размещение данных¶

Таблица 4.1.3 — Размещение и защита данных компонента.

4.2. Технические средства рабочего места пользователя¶

Таблица 4.2.1 — Технические средства рабочего места пользователя.

4.3. Ресурсы, выделяемые компоненту¶

Управляющие составные части компонента не требуют отдельных серверов: приведённые в п. 4.3.1 ресурсы выделяются им на мастер-ноде кластера Платформы 4.0. Сервер MLLM размещается на LLM-ноде, конфигурация которой выбирается заказчиком из нормативных типов п. 4.3.2.

4.3.1. Состав и назначение выделяемых ресурсов¶

Таблица 4.3.1 — Ресурсы, выделяемые управляющим составным частям компонента, и их назначение.

Приведённые значения не включают ресурсы общесистемных средств Платформы 4.0 (веб-интерфейс и шлюз, средства аутентификации, серверы PostgreSQL, объектного и временного хранилищ, брокера сообщений), которые предоставляются Платформой 4.0 и используются компонентом совместно с другими её компонентами, а также ресурсы LLM-ноды, нормируемые п. 4.3.2.

4.3.2. Типы конфигурации LLM-ноды¶

Нормативные типы конфигурации LLM-ноды и связанные с ними показатели назначения приведены в таблице 4.3.2.

Таблица 4.3.2 — Типы конфигурации LLM-ноды LPI-VAP-MLLM.

Ускорители заданы классом устройства и перечнем минимальных характеристик (таблица 4.3.3); допускается применение эквивалента, не уступающего указанным значениям.

Таблица 4.3.3 — Минимальные характеристики графических ускорителей по типам конфигурации.

Для типа 3 указанные CPU, GPU, RAM и SSD требуются на каждом из двух серверов; суммарно тип содержит 96 процессорных ядер, восемь ускорителей класса NVIDIA A30, 1024 ГБ оперативной памяти и 2000 ГБ SSD. Проект размещения должен предусматривать распределение запросов между серверами и сетевую связность, необходимую выбранному способу параллельного исполнения.

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

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

4.3.3. Соотношение с конфигурацией узлов Платформы 4.0¶

Мастер-нода, на которой размещаются управляющие сервисы, входит в конфигурацию Платформы 4.0, установленную для позиции поставки LPI-VAP-CORE. LLM-нода является отдельным узлом кластера и в позицию поставки LPI-VAP-CORE не входит. Соотношение ресурсов приведено в таблице 4.3.4.

Таблица 4.3.4 — Ресурсы компонента в соотношении с конфигурацией узлов Платформы 4.0.

Из таблицы 4.3.4 следует:

1. отдельные серверы под управляющие сервисы не требуются: их доля составляет около 8 % процессорных ядер и около 6 % оперативной памяти мастер-ноды минимальной конфигурации и предусматривается сверх минимальной конфигурации узла либо покрывается запасом ресурсов, заложенным проектом целевой поставки;
2. LLM-нода предоставляется отдельно и целиком занята сервером модели; её ресурсы не участвуют в обеспечении показателей назначения Центрального модуля и не суммируются с вычислительными нодами видеоаналитики;
3. для Центрального модуля LLM-нода является внешним ресурсом: при её отсутствии или недоступности события регистрируются без дополнительной мультимодальной проверки.

4.3.4. Масштабирование¶

Показатели назначения задаются выбранным типом конфигурации LLM-ноды. В пределах типа фактический параллелизм определяется числом экземпляров выполнения MLLM и настроенной ёмкостью подключений (п. 2.2). Увеличение пропускной способности сверх выбранного типа выполняется дополнительными LLM-нодами или сменой типа по отдельному согласованию; ресурсы управляющих сервисов на мастер-ноде рассчитываются по профилю запросов. Порядок выбора и масштабирования приведён на схеме 4.2.

Схема 4.2 — Выбор типа конфигурации LLM-ноды и масштабирование обработки.

Промежуточные и расширенные конфигурации рассчитываются по удельным величинам п. 4.4.2 и параметрам проекта поставки п. 4.4.3; ёмкость хранилищ рассчитывается отдельно и не зависит от типа LLM-ноды.

4.4. Требования к узлам целевой конфигурации и параметры проектирования¶

Подраздел устанавливает требования, которые не нормированы подразделом 4.3: качественные требования к узлам, на которых размещается компонент, минимально допустимые версии программной среды, удельные величины для расчёта ёмкости и перечень параметров, которые определяются проектом поставки. Требования приведены раздельно по типам узлов кластера и сформулированы в форме «не ниже». Управляющие составные части обследованы в составе Платформы 4.0 на узле без графических ускорителей (два процессора Intel Xeon Gold 6454S — 64 физических ядра, 512 ГБ оперативной памяти, массив RAID 5 из корпоративных SSD); указанные ниже значения подтверждены этой проверкой и являются минимально допустимыми для целевой поставки.

4.4.1. Требования к узлам по типам¶

Таблица 4.4.1 — Требования к узлам, не нормированные подразделом 4.3.

Число LLM-нод и экземпляров выполнения MLLM определяется требуемыми показателями назначения и профилем запросов (п. 4.3.4).

4.4.2. Удельные величины для расчёта конфигурации¶

Таблица 4.4.2 — Удельные величины для расчёта конфигурации.

Ёмкость объектного хранилища рассчитывается раздельно по эталонным изображениям и файлам выполнений как произведение ожидаемого числа объектов, их среднего размера и установленного срока хранения, с запасом не менее 20 %. Свободное место на LLM-ноде должно покрывать одновременно текущую и устанавливаемую версии образа сервера MLLM, веса и кэш модели.

4.4.3. Параметры, определяемые проектом поставки¶

Таблица 4.4.3 — Параметры, определяемые проектом поставки.

Окончательная конфигурация определяется в следующем порядке:

1. фиксируются модель MLLM, формат входа и контрольная нагрузка;
2. выбирается ближайший по требуемому показателю нормативный тип LLM-ноды из таблицы 4.3.2;
3. рассчитываются процессорные, оперативные, дисковые и сетевые резервы мастер-ноды для управляющих сервисов, данных, обновления и резервного копирования по удельным величинам таблицы 4.4.2;
4. проектируются отказоустойчивость, защита информации и инженерное обеспечение;
5. конфигурация фиксируется в официальном согласовании с поставщиком.

До предоставления перечисленных сведений таблица 4.3.2 задаёт обязательный исходный профиль LLM-ноды, но не является полной спецификацией серверов, сети, хранилищ, резервного копирования и автоматизированных рабочих мест.

5. Вызов и загрузка¶

Компонент вызывается двумя способами:

• пользователем — из веб-интерфейса Платформы 4.0;
• интеграционным клиентом и смежными компонентами — через программные интерфейсы и асинхронные каналы Платформы 4.0.

Загрузка серверных составных частей выполняется администратором при запуске Платформы 4.0. Пользователь не запускает исполняемые файлы компонента, не устанавливает их на своё рабочее место и не загружает веса модели из браузера. LPI-VAP-CORE выполняет аутентификацию пользователя через СУДИР и формирует пользовательский контекст. После этого браузер загружает клиентское приложение, а оно обращается к сервису управления подключениями, промптами и результатами через единый API-шлюз. Конкретные сетевые адреса и имена доменов развёртывания задаются паспортом целевой поставки; в примерах ниже применяется обозначение <адрес-Платформы-4.0>.

5.1. Способ вызова программы¶

5.1.1. Вызов пользователем¶

Пользователь вызывает функции LPI-VAP-MLLM в следующем порядке:

1. запускает поддерживаемый веб-браузер и открывает адрес https://<адрес-Платформы-4.0>/;
2. проходит единый вход: LPI-VAP-CORE при отсутствии действующей сессии перенаправляет браузер на страницу СУДИР, где пользователь вводит учётные данные;
3. после возврата LPI-VAP-CORE формирует пользовательский контекст, затем пользователь открывает раздел LLM и выбирает страницу «Список LLM» либо «Список промптов»;
4. выполняет разрешённое действие: просматривает, создаёт или изменяет подключение к MLLM, создаёт или изменяет промпт, назначает промпт камерам, запускает проверку на изображении либо открывает «Историю ответов»;
5. после завершения работы выходит из Платформы 4.0 и закрывает браузер, если это предусмотрено локальным регламентом информационной безопасности.

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

LPI-VAP-MLLM не взаимодействует с СУДИР непосредственно и не обрабатывает учётные данные пользователя. Компонент получает от LPI-VAP-CORE проверенный контекст и авторизует запрошенную операцию.

Признаками успешного вызова являются:

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

Отображение пустого списка само по себе не является отказом, если запрос завершён успешно и в системе ещё не созданы соответствующие записи.

5.1.2. Запуск серверных составных частей¶

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

• узлы кластера подготовлены в соответствии с разделом 4; установлены серверная операционная система, среда исполнения контейнеров, средства оркестрации Kubernetes, а на LLM-ноде — драйвер графических ускорителей и средства предоставления ускорителей контейнерам; узлам присвоены признаки назначения (мастер-нода, LLM-нода); все ускорители выбранного типа конфигурации обнаруживаются операционной системой;
• контейнерные образы версии поставки загружены на узлы либо доступны в разрешённом реестре образов; образ сервера MLLM содержит утверждённую модель либо имеет доступ к её локальному репозиторию, загрузка весов из сети общего пользования при штатном старте не требуется;
• подготовлены конфигурация развёртывания, секреты, внутренние сети, постоянные тома PostgreSQL, объектного хранилища и брокера сообщений, а также области весов, кэша и временных данных; системное время узлов синхронизировано;
• настроены разрешение имён, сертификаты, сервисные учётные данные и доступ к зависимым сервисам Платформы 4.0;
• выполнено согласованное резервное копирование постоянных данных перед запуском новой версии поставки или изменением схем баз данных.

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

Рекомендуемый порядок загрузки приведён в таблице 5.1.1. Параллельный запуск сервисов одного этапа допустим, если оркестратор контролирует готовность их зависимостей.

Таблица 5.1.1 — Порядок загрузки серверных составных частей.

Порядок запуска и остановки приведён на схеме 5.1.

Схема 5.1 — Порядок запуска серверных составных частей (остановка выполняется в обратном порядке).

Для пользователя различаются два уровня готовности:

• готовность каталога — доступны аутентификация, веб-интерфейс, API-шлюз, сервис управления и его PostgreSQL; пользователь может просматривать подключения, промпты и историю выполнений в пределах назначенных прав;
• полная функциональная готовность — дополнительно доступны сервер MLLM, шлюз формирования запроса, сервис консолидации, Kafka, Redis, объектное хранилище и смежные сервисы камер, кадров и событий; разрешены ручная проверка, автоматическое выполнение промптов и формирование событий.

Контейнер со статусом running не является достаточным признаком работоспособности всего компонента. После запуска администратор выполняет проверки из таблицы 5.1.2.

Таблица 5.1.2 — Проверка готовности после загрузки.

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

При плановой остановке сначала прекращают приём новых заданий (отключают автоматические запуски и ручные проверки), затем дожидаются завершения либо регламентированно останавливают задания в очереди. После этого останавливают управляющие сервисы и сервер MLLM, а PostgreSQL, объектное хранилище, Kafka и Redis — последними. Закрытие вкладки браузера или выход пользователя из системы не останавливает серверные составные части.

5.2. Входные точки в программу¶

5.2.1. Веб- и программные входные точки¶

Входные точки LPI-VAP-MLLM приведены в таблице 5.2.1. Пользовательские и прикладные точки публикуются единым шлюзом Платформы 4.0; внутренние точки не предназначены для непосредственного вызова с рабочего места пользователя.

Таблица 5.2.1 — Входные точки LPI-VAP-MLLM.

Через GraphQL выполняются следующие группы операций:

• получение перечня подключений, создание, изменение, активация, деактивация и архивирование подключения;
• получение перечня промптов, создание и изменение текста, типа, JSON Schema, настроек изображения и назначений на камеры;
• получение истории версий промпта и истории его ответов;
• создание асинхронного выполнения по одному или нескольким изображениям, получение результата по идентификатору и отмена незавершённого задания.

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

Таблица 5.2.2 — Асинхронные входные каналы LPI-VAP-MLLM.

Публикация внутренних HTTP-, RPC- и Kafka-интерфейсов за пределы серверного контура не требуется. Их вызов выполняется только по доверенным сетевым маршрутам с аутентификацией, если она предусмотрена выбранным протоколом.

5.2.2. Порядок загрузки пользовательской сессии¶

При открытии веб-интерфейса выполняется следующая последовательность (схема 5.2):

1. браузер получает статические ресурсы клиентского приложения;
2. клиент загружает файлы конфигурации интерфейса целевой поставки, включая доступные маршруты, режим работы и локализацию;
3. LPI-VAP-CORE проверяет пользовательскую сессию; при её отсутствии либо недействительности выполняет единый вход через СУДИР;
4. после возврата от СУДИР LPI-VAP-CORE передаёт клиенту пользовательский контекст и ролевую модель, на основании которых формируются только разрешённые маршруты, пункты меню и действия;
5. при открытии /llm либо /prompts клиент выполняет защищённые GraphQL-запросы к inf-llm-integration через шлюз API;
6. для страницы промптов устанавливается защищённое WebSocket-соединение, используемое для отображения хода асинхронных проверок;
7. параметры фильтрации и сортировки, присутствующие в строке запроса, восстанавливаются, после чего загружается соответствующая страница списка.

Схема 5.2 — Загрузка пользовательской сессии компонента.

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

Сбой обрабатывается с учётом недоступного звена:

• при невозможности загрузить конфигурацию интерфейса пользователь получает сообщение об ошибке конфигурации, защищённые страницы не формируются;
• при недействительном токене сессия завершается и выполняется переход на страницу входа;
• при недоступности шлюза API список или карточка не считаются загруженными, пользователю выводится ошибка запроса;
• при недоступности сервера MLLM ранее сохранённые подключения и промпты могут оставаться доступными для просмотра, но новое выполнение не считается успешным; задание переводится в состояние ошибки либо остаётся в очереди в соответствии с настройками повторов и времени ожидания;
• при разрыве WebSocket не следует считать отсутствие обновления признаком завершения задания; после восстановления соединения состояние проверяется по идентификатору выполнения или истории ответов;
• при недоступности хранилища кадров, объекта хранения или Kafka операция, требующая соответствующих данных, завершается диагностируемой ошибкой, а положительное событие не формируется.

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

5.2.3. Объём программы и использование памяти¶

Объём загружаемых контейнерных образов и фактическое потребление памяти зависят от утверждённой модели, типа конфигурации LLM-ноды, состава контейнерных образов и срока хранения результатов. Для управляющих составных частей подтверждены значения не менее 1 ГБ контейнерных образов, около 0,1 ГБ фонового потребления оперативной памяти и не менее 10 ГБ начального наполнения хранилищ; они являются минимально допустимыми («не менее») для целевой поставки, а удельные величины для расчёта ёмкости приведены в п. 4.4.2. Состав учитываемого объёма приведён в таблице 5.2.3.

Таблица 5.2.3 — Состав объёма LPI-VAP-MLLM.

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

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

Для каждого выбранного профиля подраздела 4.3 фиксируются:

• объём каждого образа, модели, клиентского комплекта и постоянного тома;
• оперативная память до запуска, после загрузки модели и при максимальной нормируемой параллельной нагрузке;
• видеопамять каждого GPU после загрузки модели и на пике контрольной нагрузки;
• максимальный размер кэша, временных изображений, очередей и журналов;
• время загрузки модели до успешного ответа GET /v1/models;
• резерв, необходимый для обновления и отката.

Измерения выполняются по закреплённым версиям целевой сборки сначала после «холодного» запуска, затем при контрольной нагрузке с максимальными предусмотренными контекстом, числом изображений и параллелизмом. Потребление GPU контролируется штатными средствами NVIDIA, оперативной памяти — средствами операционной и контейнерной среды, диска — по фактическим размерам образов, томов и каталогов.

Для управляющих составных частей значения подтверждены обследованием: контейнерные образы — 0,7 ГБ, фоновое потребление оперативной памяти — около 0,1 ГБ, клиентские статические ресурсы — не более 39 МБ в несжатом виде, метаданные в реляционном хранилище — 15 МБ, изображения и файлы в объектном хранилище — 243 МБ. Эти значения приняты как минимально допустимые («не хуже») для целевой поставки. Для выбранной MLLM дополнительно должны быть определены идентификатор и версия модели, размер весов и образа сервера MLLM, фактическое и пиковое потребление оперативной памяти и видеопамяти, параметры параллелизма и кэша контекста, измеренное время загрузки модели и размер резерва для обновления. Эти значения определяются утверждённой моделью и типом конфигурации LLM-ноды по подразделу 4.3.

6. Входные данные¶

6.1. Характер и организация входных данных¶

Входные данные LPI-VAP-MLLM образуют две группы: долговременная конфигурация и оперативные данные отдельного запуска. Конфигурация вводится пользователем или программным клиентом через защищённый API Платформы 4.0 и хранится до изменения или логического удаления. Оперативные данные поступают при ручном запуске, по расписанию либо при регистрации события и используются для формирования одного мультимодального запроса.

Таблица 6.1.1 — Группы входных данных LPI-VAP-MLLM.

Логическая организация входов показана на схеме 6.1.

Схема 6.1 — Формирование входного задания компонента.

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

6.2. Предварительная подготовка входных данных¶

До включения автоматической обработки выполняются следующие действия:

1. пользователю или сервисной учётной записи назначаются права на просмотр и изменение подключений, промптов, расписаний и запусков;
2. создаётся подключение к MLLM, указываются доступный сетевой адрес, модель, способ аутентификации и экземпляры выполнения; доступность подтверждается получением списка моделей либо контрольным запросом;
3. создаётся непустой промпт, выбираются тип анализа и активное подключение; схема ответа разбирается как корректный объект JSON Schema, а перечисления категорий сверяются со справочником Платформы 4.0;
4. проверяются существование и рабочее состояние камер, возможность получить кадр и передать его во временное хранилище;
5. для автоматического режима задаётся ровно определимое условие запуска: интервал, фиксированное время, день недели или категория события; одна и та же камера не должна повторяться в разных строках расписания одного промпта;
6. для ручного запуска выбирается основной файл изображения, а для событийного — доступное изображение события и его метаданные;
7. оценивается суммарный объём текста, изображений и ожидаемого ответа. Он не должен превышать контекст выбранной модели; число одновременных запросов не должно превышать доступную ёмкость экземпляров выполнения;
8. синхронизируется системное время составных частей, чтобы время кадра, события и выполнения можно было однозначно сопоставить.

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

Изображение должно декодироваться без ошибки, соответствовать разрешённому MIME-типу и не превышать лимиты целевой конфигурации. Ручная форма принимает файлы JPEG и PNG. Основное изображение обязательно; для промпта локализации при ручной проверке допускается не более трёх дополнительных изображений. Изображения с персональными или иными защищаемыми сведениями допускаются к обработке только по правилам информационной безопасности заказчика.

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

6.3. Формат входных данных¶

Таблица 6.3.1 — Форматы входных данных LPI-VAP-MLLM.

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

6.4. Описание входных данных¶

6.4.1. Параметры подключения к MLLM¶

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

Таблица 6.4.1 — Входные параметры подключения к MLLM.

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

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

6.4.2. Текст, версия и схема ответа промпта¶

Таблица 6.4.2 — Входные параметры промпта.

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

{
  "type": "object",
  "properties": {
    "is_event": { "type": "boolean" },
    "is_violation": { "type": "boolean" },
    "description": { "type": "string" },
    "primary_category": {
      "type": "string",
      "enum": ["<код основной категории>"]
    },
    "secondary_category": {
      "type": "string",
      "enum": ["<код вторичной категории>"]
    }
  },
  "required": [
    "is_event",
    "is_violation",
    "description",
    "primary_category",
    "secondary_category"
  ],
  "additionalProperties": false
}

Для локализации схема дополнительно описывает массивы областей [x1, y1, x2, y2] и соответствующих меток. Для верификации она описывает комментарий, состояние подтверждения и, если предусмотрено процессом, решение об удалении события. Фактические имена категорий и допустимые состояния берутся из утверждённых справочников целевой поставки.

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

6.4.3. Расписание, источники и условия запуска¶

Расписание передаётся группой, связанной с одним prompt_id. Группа содержит одну или несколько строк расписания и назначенные каждой строке камеры.

Таблица 6.4.3 — Входные параметры расписания и источников.

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

При запуске по категории совпадение выполняется по коду справочника, а не по локализованной подписи. Команды включения и отключения изменяют активность промпта или подключения, но не удаляют расписание. Ручная проверка не требует расписания: в неё передаются prompt_id, основное изображение и, при необходимости, дополнительные изображения, камера и время кадра.

6.4.4. Изображения и контекст обработки¶

Таблица 6.4.4 — Изображения и метаданные запуска.

При ручном запуске файл сначала передаётся как multipart/form-data во временное хранилище, после чего его UUID включается в команду выполнения. При автоматическом запуске аналогичный UUID создаёт контур получения кадров. Перед отправкой в MLLM компонент получает двоичные данные и преобразует их в формат адаптера. Для OpenAI-совместимого запроса изображение может быть представлено как Data URI с Base64.

Контекст событийного запуска дополнительно содержит:

• идентификаторы события и сообщения;
• идентификатор камеры и фактическое время события;
• код типа события, первичную и вторичную категории;
• UUID или защищённую ссылку изображения;
• область исходной локализации [x1, y1, x2, y2], если она имеется;
• текущее состояние подтверждения — для промпта верификации.

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

6.4.5. Управляющие и справочные данные¶

Контекст пользователя содержит сведения о сессии или сервисной учётной записи, идентификатор субъекта и назначенные роли. Для пользовательского вызова его формирует LPI-VAP-CORE после единого входа через СУДИР; контекст передаётся по защищённому контуру и не вводится в поля промпта. LPI-VAP-MLLM проверяет право на каждую управляющую операцию и область доступных камер.

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

• создание, изменение, включение, отключение и логическое удаление подключения;
• создание и изменение промпта, сохранение новой редакции, изменение активности и логическое удаление;
• создание, изменение и удаление эталонного примера;
• сохранение назначений и расписаний;
• создание ручного выполнения, получение его состояния и отмена по UUID;
• повтор после ошибки как новое выполнение после проверки причины отказа.

Для списков подключений и промптов передаются номер страницы, размер страницы, строка поиска, признаки активности, идентификаторы MLLM и камер, тип промпта и порядок сортировки по активности или времени изменения. Значения размера страницы ограничиваются API, а пустой фильтр не должен интерпретироваться как идентификатор сущности.

Справочник моделей предоставляет идентификаторы моделей, доступных выбранному адаптеру. Справочники первичных и вторичных категорий задают допустимые коды для триггеров и JSON Schema. До выполнения проверяется, что значения всё ещё актуальны. Удалённая или недоступная модель и неизвестная категория являются ошибкой входных данных.

Параметр max_connections каждого экземпляра ограничивает число одновременно обрабатываемых запросов. Суммарная доступная ёмкость используется диспетчером; при её исчерпании корректное задание остаётся в очереди. Команда отмены передаёт UUID выполнения и допустима только для поддерживаемого текущего состояния. Автоматические повторы, их число и задержки не являются входом по умолчанию и должны быть отдельно установлены в целевой конфигурации.

6.5. Способ кодирования входных данных¶

Текстовые значения, JSON и JSON Schema кодируются в UTF-8. В HTTP API используется application/json, а для загрузки файлов — multipart/form-data. Во внутреннем обмене применяются типизированные RPC-сообщения и утверждённые схемы сообщений очереди; их двоичное представление не предназначено для ручного формирования.

Числовые идентификаторы передаются десятичными целыми значениями. UUID передаются канонической строкой с дефисами. Время кадра и события передаётся целым числом секунд Unix и относится к UTC; календарное время расписания — строкой HH:mm, дни недели — числами от 1 до 7. Значения перечислений должны соответствовать регистру и кодам программного контракта.

Изображения JPEG и PNG передаются двоичным содержимым при первичной загрузке. После регистрации между составными частями передаются UUID или защищённые ссылки. Если адаптер требует включить изображение в JSON, двоичные данные кодируются Base64 и предваряются корректным MIME-типом в Data URI. Base64 не считается способом шифрования и не может использоваться вместо защищённого транспортного соединения.

Координаты задаются числовыми массивами в порядке x1, y1, x2, y2. При включённой нормализации они переводятся в систему, установленную контрактом целевой модели; при выключенной — относятся к пикселям исходного изображения. Смешение систем координат в одном ответе или запросе не допускается.

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

7. Выходные данные¶

7.1. Характер и организация выходных данных¶

Выходные данные LPI-VAP-MLLM включают сохранённую конфигурацию, сведения о ходе и результате каждого запуска, события для смежных компонентов и диагностические сообщения. Пользователь получает данные через защищённый API и веб-интерфейс Платформы 4.0. Внутренние получатели получают типизированные сообщения очереди и вызовы программных интерфейсов.

Таблица 7.1.1 — Группы выходных данных LPI-VAP-MLLM.

Результат одного запуска организуется вокруг execution_uuid. Исходный ответ сохраняется отдельно от нормализованных полей. Это позволяет показать ответ для диагностики, но не делает непроверенный JSON допустимым прикладным результатом. Связь с созданным событием устанавливается по event_message_uuid.

Схема 7.1 — Формирование выходных данных запуска.

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

7.2. Формат выходных данных¶

Таблица 7.2.1 — Форматы выходных данных LPI-VAP-MLLM.

Внутренние сообщения очереди и RPC не являются публичным API. Их структура может изменяться только согласованно во всех отправляющих и принимающих составных частях. Клиенту веб-интерфейса не требуется декодировать внутренний двоичный формат события.

7.3. Описание выходных данных¶

7.3.1. Сведения о подключениях и промптах¶

Результат создания подключения содержит его числовой llm_id. При последующем чтении возвращается запись, описанная в таблице 7.3.1.

Таблица 7.3.1 — Выходная запись подключения к MLLM.

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

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

Результат создания промпта содержит prompt_id. Полная запись промпта включает:

Таблица 7.3.2 — Выходная запись промпта.

История промпта возвращается упорядоченным набором редакций. Редакция содержит history_id, version_id, строковое обозначение версии, prompt_id, текст, время изменения, признак активности, JSON Schema, параметры координат и области верификации, а также метаданные. История расписаний в эту запись не входит.

Запись эталонного примера содержит example_id, наименование, поясняющий текст, UUID изображения, признаки активности и логического удаления, время создания и изменения. Ответ списка дополнительно содержит total. Ссылка на файл формируется только для пользователя, имеющего право его просмотра.

7.3.2. Состояние и результат выполнения промпта¶

После принятия ручного или автоматического запуска создаётся запись выполнения. Ручной асинхронный вызов немедленно возвращает execution_uuid, по которому клиент получает прогресс и конечный результат.

Таблица 7.3.3 — Выходная запись выполнения промпта.

Публичные состояния приведены в таблице 7.3.4.

Таблица 7.3.4 — Состояния выполнения промпта.

Внутренние состояния очереди «ожидает», «выполняется», «завершено» и «ошибка» не должны подменять перечисление внешнего API. Веб-интерфейс может показывать дополнительные локальные этапы и процент выполнения, но конечным источником состояния остаётся запись выполнения.

История запусков возвращается постранично как execution_list и total. В интерфейсе для записи показываются дата, продолжительность, путь объекта, камера и её разрешение, категория, состояние, пояснение и основное изображение. Продолжительность вычисляется как разность finish_at и start_at и не сохраняется как независимое исходное значение.

7.3.3. Результаты классификации, локализации и верификации¶

После проверки по схеме ответ классификации или локализации содержит пять обязательных полей:

• is_event — является ли результат событием;
• is_violation — является ли результат нарушением;
• description — краткое объяснение решения;
• primary_category — код основной категории;
• secondary_category — код уточняющей категории.

Результат локализации дополнительно содержит объект detections с массивом областей bboxes и массивом меток labels. Элементы с одинаковым индексом относятся к одному объекту; число областей должно совпадать с числом меток. Пример результата имеет следующий вид:

{
  "is_event": true,
  "is_violation": true,
  "description": "Обнаружен признак контролируемой ситуации",
  "primary_category": "<код основной категории>",
  "secondary_category": "<код вторичной категории>",
  "detections": {
    "bboxes": [[10, 20, 110, 220]],
    "labels": ["<метка объекта>"]
  }
}

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

Промпт верификации возвращает:

Таблица 7.3.5 — Выходные поля верификации события.

При обычном решении компонент передаёт статус и комментарий в хранилище событий с признаком автоматического проверяющего и сведениями о применённом промпте. При delete_event = true выполняется отдельная операция удаления по правилам хранилища событий. Отсутствие этого поля не должно трактоваться как команда удаления.

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

7.3.4. Консолидированные результаты и интеграционный обмен¶

Для активной камеры результат с is_event = true или is_violation = true преобразуется в сообщение события, если схема не предписывает консолидацию. Ручное выполнение без камеры сохраняется в истории, но не создаёт событие видеонаблюдения.

Таблица 7.3.6 — Состав события, сформированного по результату MLLM.

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

При консолидации частный выход содержит:

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

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

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

7.3.5. Сообщения о результате и ошибках¶

Успешная синхронная операция возвращает идентификатор объекта либо логический status = true. Для операции, не создающей сущность, может дополнительно возвращаться краткое поле msg. Ответ списка содержит записи и total. Принятие асинхронного запуска подтверждается UUID; окончательный успех подтверждается только состоянием generated.

Сообщение прогресса содержит тот же execution_uuid, состояние, время начала, время окончания и обезличенную ошибку. Клиент после терминального состояния запрашивает сохранённую запись выполнения. Если уведомление не было доставлено, результат остаётся доступен через API.

Таблица 7.3.7 — Выходные сообщения об ошибках.

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

Если интерфейс статистики включён в поставку, для выбранной MLLM и периода возвращаются общее число запросов, числа успешных и ошибочных запросов, распределение по временным интервалам и промптам, а также доля успешных запросов. Статистические суммы не заменяют журнал отдельных выполнений.

Для целевой поставки необходимо утвердить сроки хранения конфигурации, версий, результатов, изображений и журналов, правила доступа к исходному JSON и изображениям, каталог пользовательских кодов и текстов ошибок, политику повторов и дедупликации, пороги и сроки хранения статистики, требуемые форматы выгрузки и отчётности и правила аудита административных изменений (приложение Г). Эти значения определяются требованиями заказчика, а не конфигурацией контура разработки.

7.4. Способ кодирования выходных данных¶

Текст и ответы JSON кодируются в UTF-8. Внешний API передаёт JSON с MIME-типом application/json по защищённому HTTP-соединению. Отсутствующее необязательное значение передаётся как null либо не включается в запрошенный набор полей; пустая строка не должна использоваться как замена неизвестному идентификатору.

Числовые идентификаторы возвращаются десятичными целыми значениями. UUID передаются канонической строкой с дефисами. start_at, finish_at, snapshot_timestamp и временные метки статистики представлены целым числом секунд Unix в UTC. Веб-интерфейс может отображать их в выбранном пользователем формате и часовом поясе, не изменяя сохранённого значения.

Состояния выполнения кодируются строками нижнего регистра: started, generated, failed, canceled. Логические значения кодируются JSON-значениями true и false. Процент успешных запросов представляется числом от 0 до 100; правила округления задаются клиентом отображения.

Категории в API и интеграционных сообщениях передаются стабильными кодами справочника. Локализованные наименования формируются веб-интерфейсом и не заменяют код. Координаты передаются массивами чисел в порядке [x1, y1, x2, y2]; единицы определяются признаком нормализации. Метка в labels относится к области с тем же индексом в bboxes.

raw_json_response является строкой, внутри которой находится JSON в UTF-8. Клиент должен сначала разобрать строку как JSON и не использовать её как HTML. Типизированные поля записи выполнения имеют приоритет над повторным разбором исходного текста для прикладных решений.

Изображение предоставляется UUID либо защищённой ссылкой. Двоичное содержимое возвращается отдельным запросом с фактическим MIME-типом JPEG или PNG. Ссылка не должна раскрывать путь файловой системы или реквизиты доступа и действует в пределах установленных прав и срока хранения. Внутреннее сообщение консолидации может содержать Base64 без префикса Data URI; это не является форматом выдачи изображения пользователю.

События внутренней очереди кодируются утверждённым типизированным двоичным форматом, а сообщения, для которых контрактом установлен JSON, — UTF-8 JSON. Журналы не являются источником прикладного результата и не должны содержать секреты или полный защищаемый вход и выход MLLM.

Приложения¶

Приложение А (рекомендуемое). Шаблоны схем структурированных ответов¶

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

А.1. Схема результата классификации¶

{
  "type": "object",
  "properties": {
    "is_event": {
      "type": "boolean"
    },
    "is_violation": {
      "type": "boolean"
    },
    "description": {
      "type": "string"
    },
    "primary_category": {
      "type": "string",
      "enum": ["<код основной категории>"]
    },
    "secondary_category": {
      "type": "string",
      "enum": ["<код вторичной категории>"]
    }
  },
  "required": [
    "is_event",
    "is_violation",
    "description",
    "primary_category",
    "secondary_category"
  ],
  "additionalProperties": false
}

А.2. Схема результата локализации¶

{
  "type": "object",
  "properties": {
    "is_event": {
      "type": "boolean"
    },
    "is_violation": {
      "type": "boolean"
    },
    "description": {
      "type": "string"
    },
    "primary_category": {
      "type": "string",
      "enum": ["<код основной категории>"]
    },
    "secondary_category": {
      "type": "string",
      "enum": ["<код вторичной категории>"]
    },
    "detections": {
      "type": "object",
      "properties": {
        "bboxes": {
          "type": "array",
          "items": {
            "type": "array",
            "items": {
              "type": "number"
            },
            "minItems": 4,
            "maxItems": 4
          }
        },
        "labels": {
          "type": "array",
          "items": {
            "type": "string"
          }
        }
      },
      "required": ["bboxes", "labels"],
      "additionalProperties": false
    }
  },
  "required": [
    "is_event",
    "is_violation",
    "description",
    "primary_category",
    "secondary_category",
    "detections"
  ],
  "additionalProperties": false
}

Массивы bboxes и labels должны иметь одинаковую длину. Каждая область задаётся как [x1, y1, x2, y2]. Диапазон координат определяется признаком normalize_coords и утверждённым контрактом целевой модели.

А.3. Схема результата верификации события¶

{
  "type": "object",
  "properties": {
    "comment": {
      "type": "string",
      "minLength": 1
    },
    "event_confirmation_status": {
      "type": "integer",
      "enum": [1, 2, 3]
    },
    "delete_event": {
      "type": "boolean"
    }
  },
  "required": [
    "comment",
    "event_confirmation_status"
  ],
  "additionalProperties": false
}

Значение 1 означает отсутствие определённого решения, 2 — подтверждение, 3 — отклонение события. Поле delete_event включается в схему только тогда, когда команда удаления поддерживается обработчиком и разрешена регламентом заказчика. Отсутствие поля не означает удаление.

Для всех схем должны выполняться следующие правила:

• схема хранится как корректный JSON в UTF-8;
• обязательные поля соответствуют типу промпта;
• значения enum содержат стабильные коды, а не локализованные подписи;
• типы полей согласованы с серверным валидатором;
• изменение схемы создаёт новую редакцию промпта и проверяется контрольным запуском до активации автоматической обработки.

Приложение Б (справочное). Жизненный цикл конфигурации и выполнения¶

Б.1. Подключение и промпт¶

Схема Б.1 — Жизненный цикл подключения и промпта.

Сохранение подключения не подтверждает его доступность. Активация выполняется после проверки целевого API и модели. Изменение текста, JSON Schema, нормализации координат или параметров области верификации сохраняется как новая редакция промпта. Расписание является текущим назначением и не восстанавливается автоматически из истории текста.

Б.2. Выполнение промпта¶

Схема Б.2 — Жизненный цикл выполнения промпта.

Состояния generated, failed и canceled являются терминальными. Повторный запуск после ошибки создаёт новое выполнение с новым UUID. Наличие event_message_uuid позволяет сопоставить выполнение с сообщением события, но не заменяет проверку сохранения события у получателя.

Приложение В (справочное). Типы запусков, состояния и сообщения¶

В.1. Типы условий запуска¶

Таблица В.1 — Типы условий запуска промпта.

Значение 0 зарезервировано для неопределённого типа и не является рабочим условием. Пользовательский ручной запуск реализуется отдельной командой и может соответствовать типу UPON_REQUEST только в том интеграционном профиле, где это явно предусмотрено. Поддержка FRAME_COMPARISON также подтверждается для целевой поставки отдельно.

В.2. Сводные состояния¶

Таблица В.2 — Состояния объектов LPI-VAP-MLLM.

В.3. Сообщение прогресса выполнения¶

{
  "execution_uuid": "00000000-0000-0000-0000-000000000001",
  "status": "generated",
  "error": "",
  "start_at": 1787904000,
  "finish_at": 1787904015
}

Поле finish_at отсутствует или равно null, пока выполнение не перешло в терминальное состояние. При failed поле error содержит обезличенное краткое описание причины. Сохранённая запись выполнения запрашивается отдельно по execution_uuid.

В.4. Пример записи успешного выполнения¶

{
  "execution_uuid": "00000000-0000-0000-0000-000000000001",
  "status": "generated",
  "start_at": 1787904000,
  "finish_at": 1787904015,
  "snapshot_timestamp": 1787903990,
  "camera_id": 101,
  "is_event": true,
  "is_violation": true,
  "primary_category": "<код основной категории>",
  "secondary_category": "<код вторичной категории>",
  "description": "Обнаружен признак контролируемой ситуации",
  "image_uuid": "00000000-0000-0000-0000-000000000002",
  "event_message_uuid": "00000000-0000-0000-0000-000000000003",
  "error_text": null
}

Значения идентификаторов, времени и категорий приведены только для пояснения структуры. Они не являются параметрами контура заказчика. Исходный ответ MLLM дополнительно возвращается в raw_json_response как строка с JSON.

В.5. Связь успешного результата с прикладным выходом¶

Таблица В.3 — Связь результата выполнения с прикладным выходом.

Приложение Г (обязательное при подготовке целевой поставки). Уточняемые сведения¶

До выпуска утверждаемой редакции документа должны быть определены значения таблицы Г.1.

Таблица Г.1 — Сведения, уточняемые для целевой поставки.

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

Приложение Д (справочное). Исходные тексты схем Mermaid¶

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

Исходные тексты¶

MLLM-MER-001. Схема 1.1 — Место LPI-VAP-MLLM в Платформе 4.0¶

Расположение схемы: 1.1. Обозначение и наименование программы.

flowchart TB
    UI["Веб-интерфейс<br/>Платформы 4.0"]
    subgraph MLLM["LPI-VAP-MLLM"]
        direction TB
        CONN["Подключения к MLLM<br/>и промпты"]
        QUEUE["Очередь заданий<br/>и диспетчеризация"]
        REQ["Формирование<br/>мультимодального запроса"]
        SRV["Сервер MLLM<br/>на графических ускорителях"]
        RES["Проверка и применение<br/>результата"]
        CONS["Консолидация результатов<br/>нескольких камер"]
        CONN --> QUEUE
        QUEUE --> REQ
        REQ --> SRV
        SRV --> REQ
        REQ --> RES
        RES --> CONS
    end
    UI --> CONN
    UI --> RES
    CORE["LPI-VAP-CORE<br/>доступ, камеры, кадры,<br/>события"] --> QUEUE
    RES --> CORE
    CONS --> CORE

MLLM-MER-002. Схема 1.2 — Уровни программного обеспечения, необходимого для функционирования компонента¶

Расположение схемы: 1.2. Программное обеспечение, необходимое для функционирования программы.

flowchart TB
    L1["Уровень 1. Технические средства узлов кластера<br/>серверы x86-64, графические ускорители, накопители, сеть<br/>(раздел 4)"]
    L2["Уровень 2. Системное программное обеспечение<br/>«Московская серверная операционная система», среда исполнения контейнеров,<br/>Kubernetes, драйвер NVIDIA и средства предоставления ускорителей, CUDA<br/>(п. 1.2.1)"]
    L3["Уровень 3. Общесистемные сервисы Платформы 4.0<br/>PostgreSQL, Apache Kafka, Redis, MinIO, nginx и веб-шлюз<br/>(п. 1.2.2)"]
    L4["Уровень 4. Среды исполнения и библиотеки<br/>Python, vLLM, PyTorch, FastAPI, LangChain, OpenAI SDK и другие<br/>(п. 1.2.3)"]
    L5["Уровень 5. Составные части LPI-VAP-MLLM<br/>управление подключениями и промптами, шлюз запроса,<br/>сервер MLLM, консолидация результатов<br/>(п. 1.1, подраздел 3.3)"]
    L6["Уровень 6. Клиентское программное обеспечение<br/>веб-браузер рабочего места пользователя<br/>(п. 1.2.5)"]
    EXTC["Смежные компоненты и внешние средства<br/>LPI-VAP-CORE (единая точка входа через СУДИР),<br/>подсистема камер и кадров, хранилище событий<br/>(п. 1.2.4)"]

    L1 --> L2 --> L3 --> L4 --> L5 --> L6
    L5 <--> EXTC

MLLM-MER-003. Схема 2.1 — Функциональный цикл выполнения мультимодального промпта¶

Расположение схемы: 2.1. Классы решаемых задач.

flowchart LR
    CFG["Подключение, модель<br/>и промпт"] --> START{"Условие запуска"}
    CAM["Камеры, расписания<br/>и категории событий"] --> START
    START -->|ручной запуск| FILE["Загруженный кадр"]
    START -->|по расписанию| SNAP["Текущий кадр камеры"]
    START -->|по событию| EVENT["Кадр и контекст события"]
    REF["Эталонные изображения"] --> REQUEST["Мультимодальное задание"]
    FILE --> REQUEST
    SNAP --> REQUEST
    EVENT --> REQUEST
    REQUEST --> QUEUE["Очередь и распределение<br/>по экземплярам MLLM"]
    QUEUE --> MLLM["Выполнение запроса MLLM"]
    MLLM --> VALIDATE{"Ответ соответствует<br/>заданной структуре?"}
    VALIDATE -->|нет| ERROR["Состояние ошибки<br/>и диагностика"]
    VALIDATE -->|да| RESULT["Сохранённый результат JSON"]
    RESULT --> VIEW["Просмотр результата"]
    RESULT --> DIRECT["Создание или проверка события"]
    RESULT --> CONS["Консолидация результатов"]

MLLM-MER-004. Схема 3.1 — Общий алгоритм выполнения мультимодального задания¶

Расположение схемы: 3.1. Алгоритм программы.

flowchart TD
    START(["Условие запуска"]) --> MODE{"Режим запуска"}
    MODE -->|ручной| UPLOAD["Загрузка отдельного кадра"]
    MODE -->|расписание| SNAPSHOT["Получение текущего кадра камеры"]
    MODE -->|категория события| TRIGGER["Текущий и дополнительные кадры,<br/>контекст события"]
    MODE -->|проверка события| VERIFY["Кадр зарегистрированного события"]

    UPLOAD --> INPUT
    SNAPSHOT --> INPUT
    TRIGGER --> INPUT
    VERIFY --> INPUT["Проверка промпта, подключения,<br/>назначения камеры и изображения"]

    INPUT -->|ошибка| INPUT_ERROR["Фиксация отказа входных данных"]
    INPUT -->|успешно| TASK["Создание задания<br/>со статусом «ожидает»"]
    TASK --> DISPATCH{"Есть свободный<br/>экземпляр MLLM?"}
    DISPATCH -->|нет| TASK
    DISPATCH -->|да| CONTEXT["Формирование текста, изображений,<br/>параметров и схемы ответа"]
    CONTEXT --> CALL["Вызов выбранного экземпляра MLLM"]

    CALL -->|сетевая ошибка<br/>или превышение времени| FAILED["Статус «ошибка»,<br/>диагностическое сообщение"]
    CALL -->|ответ получен| JSON{"Ответ является JSON<br/>требуемой структуры?"}
    JSON -->|нет| FAILED
    JSON -->|да| SAVE["Сохранение результата<br/>со статусом «выполнено»"]

    SAVE --> ROUTE{"Способ применения"}
    ROUTE -->|просмотр| UI["Журнал выполнений"]
    ROUTE -->|итоговый результат| EVENT["Создание события"]
    ROUTE -->|частный результат| CONS["Ожидание результатов<br/>других камер"]
    ROUTE -->|проверка события| CONFIRM["Подтверждение или отклонение<br/>исходного события"]
    CONS -->|набор неполон<br/>или устарел| WAIT["Ожидание либо удаление<br/>устаревших данных"]
    CONS -->|набор полон| EVENT

MLLM-MER-005. Схема 3.2 — Логическая структура LPI-VAP-MLLM и связи с окружением¶

Расположение схемы: 3.3. Структура программы с описанием функций составных частей.

flowchart LR
    subgraph PLATFORM["Смежные компоненты Платформы 4.0"]
        UI["Веб-интерфейс<br/>и API-шлюз"]
        CORE["LPI-VAP-CORE<br/>единая точка входа,<br/>роли и полномочия"]
        CAM["Управление камерами<br/>и связями объектов"]
        FRAME["Получение кадров<br/>и базовая видеоаналитика"]
        DTS["Временное хранилище<br/>изображений"]
        DICT["Справочник моделей<br/>и категорий"]
        EVENTS["Хранилище событий"]
    end

    subgraph COMPONENT["LPI-VAP-MLLM"]
        INT["inf-llm-integration<br/>управление и диспетчеризация"]
        DB1[("PostgreSQL<br/>конфигурация и выполнения")]
        AGENT["llm-agent<br/>формирование запроса"]
        VLLM["llm-vllm<br/>GPU-инференс"]
        CONS["inf-llm-event-consolidation<br/>объединение результатов"]
        DB2[("PostgreSQL<br/>частные результаты")]
    end

    CORE --> UI
    UI <-->|"GraphQL / внутренний RPC"| INT
    CAM -->|"назначения и расписания"| FRAME
    FRAME -->|"задание, UUID кадров"| INT
    DTS <-->|"получение и размещение изображений"| INT
    DICT -->|"модели и категории"| INT
    INT <-->|"прикладные данные"| DB1
    INT -->|"HTTP JSON"| AGENT
    AGENT -->|"OpenAI-совместимый API"| VLLM
    VLLM -->|"структурированный ответ"| AGENT
    AGENT -->|"JSON"| INT
    INT -->|"итоговое событие"| EVENTS
    INT -->|"частный результат"| CONS
    CONS <-->|"состояние консолидации"| DB2
    CAM -->|"состав камер объекта"| CONS
    CONS -->|"доказательные изображения"| DTS
    CONS -->|"консолидированное событие"| EVENTS
    EVENTS -->|"событие для проверки"| INT

MLLM-MER-006. Схема 4.1 — Размещение составных частей LPI-VAP-MLLM на узлах кластера Платформы 4.0¶

Расположение схемы: 4.1.2. Схема развёртывания.

flowchart LR
    ARM["Рабочее место<br/>веб-браузер"]
    INGRESS["Ingress и веб-шлюз<br/>HTTPS, WebSocket"]
    subgraph MASTER["Мастер-нода Kubernetes"]
        INT["inf-llm-integration<br/>управление и очередь"]
        AGENT["llm-agent<br/>формирование запроса"]
        CONS["inf-llm-event-consolidation<br/>консолидация"]
        STORE["PostgreSQL, MinIO, Kafka"]
        TEMP["Redis<br/>временные изображения"]
        INT --> AGENT
        INT --> CONS
        INT --> STORE
        CONS --> STORE
        INT --> TEMP
    end
    subgraph LLM["LLM-нода Kubernetes (GPU)"]
        VLLM["llm-vllm<br/>сервер MLLM"]
        WEIGHTS["Веса и кэш модели"]
        VLLM --> WEIGHTS
    end
    CORE["LPI-VAP-CORE<br/>камеры, кадры, события"]
    BACKUP["Средства резервного копирования<br/>в отдельном домене отказа"]

    ARM --> INGRESS --> INT
    AGENT --> VLLM
    INT <--> CORE
    CONS --> CORE
    STORE --> BACKUP

MLLM-MER-007. Схема 4.2 — Выбор типа конфигурации LLM-ноды и масштабирование обработки¶

Расположение схемы: 4.3.4. Масштабирование.

flowchart TB
    SEL{"Требуемые показатели:<br/>длина контекста и скорость обработки"}
    T1["Тип 1: 1 сервер, 1 × H100<br/>контекст до 32 784 токенов<br/>не менее 0,15 запроса в минуту"]
    T2["Тип 2: 1 сервер, 8 × A30<br/>контекст до 8 192 токенов<br/>не менее 1 запроса в минуту"]
    T3["Тип 3: 2 сервера, 4 × A30 каждый<br/>контекст до 4 096 токенов<br/>не менее 6 запросов в минуту"]
    INST["Экземпляры выполнения MLLM<br/>и ёмкость подключений:<br/>параллелизм заданий"]
    NX["Дальнейшее масштабирование<br/>дополнительными LLM-нодами<br/>по отдельному согласованию"]
    MASTER["Ресурсы управляющих сервисов мастер-ноды:<br/>рассчитываются по числу промптов, камер,<br/>запросов в минуту и срокам хранения результатов"]

    SEL --> T1
    SEL --> T2
    SEL --> T3
    T1 --> INST
    T2 --> INST
    T3 --> INST
    INST --> NX
    MASTER -.-> INST

MLLM-MER-008. Схема 5.1 — Порядок запуска серверных составных частей (остановка выполняется в обратном порядке)¶

Расположение схемы: 5.1.2. Запуск серверных составных частей.

flowchart TB
    G1["1. Базовая инфраструктура узлов<br/>среда исполнения контейнеров и Kubernetes,<br/>сети, тома, графические ускорители LLM-ноды"]
    G2["2. Хранение и обмен<br/>PostgreSQL, объектное хранилище,<br/>брокер сообщений, временное хранилище"]
    G3["3. Сервер MLLM<br/>загрузка весов модели в видеопамять,<br/>подготовка кэша выполнения"]
    G4["4. Смежные сервисы<br/>камеры, кадры, справочник категорий,<br/>хранилище событий"]
    G5["5. Управляющие сервисы<br/>шлюз запроса, управление и очередь,<br/>консолидация"]
    G6["6. Внешний доступ<br/>веб-интерфейс и шлюз прикладных интерфейсов"]
    CHK{"Проверка готовности<br/>группы пройдена?"}
    RST["Перезапуск сервиса средствами оркестратора;<br/>запуск следующих групп приостановлен"]
    OK["Компонент готов к работе"]

    G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> CHK
    CHK -->|нет| RST
    RST --> CHK
    CHK -->|да| OK

MLLM-MER-009. Схема 5.2 — Загрузка пользовательской сессии компонента¶

Расположение схемы: 5.2.2. Порядок загрузки пользовательской сессии.

sequenceDiagram
    actor U as Пользователь
    participant UI as Веб-интерфейс
    participant CORE as LPI-VAP-CORE<br/>единая точка входа
    participant GW as API-шлюз
    participant INT as Сервис управления<br/>inf-llm-integration

    U->>UI: Открыть раздел «LLM» или «Промпты»
    UI->>CORE: Проверить сессию и разрешения
    alt Сессия отсутствует или истекла
        CORE-->>UI: Требуется вход через СУДИР
        UI-->>U: Страница входа
    else Сессия действительна
        UI->>GW: GraphQL-запрос списка и справочников
        GW->>INT: Получить подключения, промпты, состояния
        INT-->>GW: Данные раздела
        GW-->>UI: Данные раздела
        UI->>GW: Установить соединение WebSocket
        GW-->>UI: Канал уведомлений о ходе выполнений
        UI-->>U: Список и доступные команды
    end

MLLM-MER-010. Схема 6.1 — Формирование входного задания компонента¶

Расположение схемы: 6.1. Характер и организация входных данных.

flowchart LR
    CFG["Подключение, промпт,<br/>камера и условие запуска"] --> CHECK["Проверка и<br/>нормализация"]
    IMG["Целевое и дополнительные<br/>изображения"] --> CHECK
    EVENT["Контекст события<br/>или команда пользователя"] --> CHECK
    DICT["Модели, категории,<br/>права и лимиты"] --> CHECK
    CHECK --> TASK["Входное задание<br/>LPI-VAP-MLLM"]
    TASK --> REQUEST["Мультимодальный запрос:<br/>текст + изображения + схема"]

MLLM-MER-011. Схема 7.1 — Формирование выходных данных запуска¶

Расположение схемы: 7.1. Характер и организация выходных данных.

flowchart LR
    MLLM["Исходный ответ MLLM"] --> PARSE{"Разбор и проверка<br/>по схеме"}
    PARSE -->|ошибка| FAILED["Состояние failed,<br/>диагностика"]
    PARSE -->|успешно| JOURNAL["Состояние generated,<br/>запись в журнале"]
    JOURNAL --> DECISION{"Тип и содержание<br/>результата"}
    DECISION -->|нет события| HISTORY["Только история<br/>выполнения"]
    DECISION -->|событие| EVENT["Событие<br/>Платформы 4.0"]
    DECISION -->|консолидация| CONS["Частный результат<br/>и итоговое событие"]
    DECISION -->|верификация| VERIFY["Статус и комментарий<br/>исходного события"]

MLLM-MER-012. Схема Б.1 — Жизненный цикл подключения и промпта¶

Расположение схемы: Б.1. Подключение и промпт.

flowchart LR
    CREATE_LLM["Создание подключения"] --> SAVED_LLM["Сохранено<br/>is_active = true/false"]
    SAVED_LLM --> CHECK["Проверка адреса,<br/>модели и доступа"]
    CHECK -->|успешно| ACTIVE_LLM["Активное подключение"]
    CHECK -->|ошибка| SAVED_LLM
    ACTIVE_LLM --> DISABLE_LLM["Отключение"]
    DISABLE_LLM --> SAVED_LLM
    SAVED_LLM --> DELETE_LLM["Логическое удаление"]
    ACTIVE_LLM --> CREATE_PROMPT["Создание промпта"]
    CREATE_PROMPT --> PROMPT["Текущая редакция<br/>и история"]
    PROMPT --> TEST["Контрольный запуск"]
    TEST -->|успешно| ACTIVE_PROMPT["Активный промпт"]
    TEST -->|ошибка| EDIT["Изменение текста,<br/>схемы или параметров"]
    EDIT --> PROMPT
    ACTIVE_PROMPT --> EDIT
    ACTIVE_PROMPT --> DISABLE_PROMPT["Отключение промпта"]
    DISABLE_PROMPT --> PROMPT
    PROMPT --> DELETE_PROMPT["Логическое удаление"]

MLLM-MER-013. Схема Б.2 — Жизненный цикл выполнения промпта¶

Расположение схемы: Б.2. Выполнение промпта.

flowchart LR
    REQUEST["Команда или<br/>условие запуска"] --> STARTED["started<br/>принято или выполняется"]
    STARTED -->|ответ проверен| GENERATED["generated"]
    STARTED -->|ошибка| FAILED["failed"]
    STARTED -->|команда отмены| CANCELED["canceled"]
    GENERATED --> NO_EVENT["Запись в истории<br/>без события"]
    GENERATED --> EVENT["Прямое событие"]
    GENERATED --> CONS["Частный результат<br/>консолидации"]
    GENERATED --> VERIFY["Изменение статуса<br/>исходного события"]

Лист регистрации изменений¶

Таблица — Лист регистрации изменений.

Рабочая редакция 0.2 уточняет границу интеграции с СУДИР: единый вход выполняет LPI-VAP-CORE, а LPI-VAP-MLLM получает пользовательский контекст и проверяет полномочия на операции. Рабочая редакция 0.3 отражает выравнивание содержания и оформления с описаниями Центрального модуля, компонентов управления моделями и среды разработки сценариев: компонент определён как расширение программного продукта, целевое развёртывание приведено к кластеру Kubernetes Платформы 4.0 с размещением сервера модели на LLM-ноде, добавлены схемы уровней программного обеспечения, масштабирования и загрузки сессии, приведены к единому виду функциональные блоки, разделы о технических средствах, порядок загрузки и лист регистрации; служебные примечания об основаниях разделов исключены. Она не является зарегистрированным изменением утверждённого оригинала. При выпуске утверждаемой редакции необходимо:

1. присвоить обозначение документа и формальный номер изменения;
2. сформировать DOCX или PDF и указать фактическое число и номера листов;
3. указать номер сопроводительного документа, если он оформляется;
4. получить подписи ответственного исполнителя, проверяющего и нормоконтролёра в порядке, принятом для проекта;
5. в последующих строках регистрировать только изменения утверждённого оригинала, а не отдельные технические коммиты Git.

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