В первой части: «Подготовка моделей ИИ к развертыванию» мы рассмотрели, как наша модель покидает конвейер обучения в виде подписанного, оптимизированного артефакта Open Container Initiative (OCI), готового к отправке на периферию. Теперь возникает следующий вопрос: каковы будут последствия запуска этих рабочих нагрузок ИИ на периферии?
Запуск логического вывода (инференса) ИИ в центре обработки данных означает использование стандартизированного оборудования и большого объема памяти. На периферии один парк устройств может охватывать несколько аппаратных платформ.
Прежде чем думать о стратегиях обновления или управлении решением, возникает более фундаментальный вопрос: что требуется для правильной работы модели ИИ на устройстве с ограниченным оборудованием и общими ресурсами?
В этой статье мы рассмотрим этот вопрос через призму выбора платформы, управления зависимостями аппаратных ускорителей, проблем с общей памятью и задержками, а также шаблонов обмена сообщениями, которые связывают датчики с инференсом, а инференс — с последующими системами.
Аппаратная реальность: почему развертывание ИИ на периферии отличается от облачного ИИ
При запуске ИИ в «ядре» (облаке или локальных центрах обработки данных) вы работаете на стандартизированном оборудовании. Вы выбираете тип экземпляра GPU, версия Compute Unified Device Architecture (CUDA) известна, а память измеряется десятками гигабайт. Парки периферийного ИИ — это полная противоположность: они по своей природе гетерогенны, ограничены в ресурсах, а в некоторых случаях обслуживают операционные нагрузки, которые конкурируют с инференсом ИИ за одни и те же аппаратные ресурсы.
Парк устройств одной организации может включать NVIDIA Jetson Orin на архитектуре aarch64, промышленные шлюзы на базе Intel Atom на x86_64 с GPU или без него, серверы AMD near-edge с дискретными GPU Peripheral Component Interconnect Express (PCIe) и одноплатные компьютеры со встроенными нейронными процессорами (NPU). Каждому из них может потребоваться свой формат среды выполнения, свой вариант модели и свои стратегии управления ресурсами.
В первой части «Подготовка моделей ИИ к развертыванию» был решен вопрос о формате среды выполнения: было показано, как рекомендуемый конвейер создает Open Neural Network Exchange (ONNX) в качестве промежуточного представления и, при необходимости, компилирует его в форматы, специфичные для оборудования (TensorRT для GPU SKU, OpenVINO для Intel и ONNX Runtime для гетерогенных устройств). В этой статье мы сосредоточимся на другом аспекте, который необходимо учитывать при использовании периферийного оборудования: конкуренция за ресурсы.
Процесс инференса ИИ на периферии может совместно использовать память и CPU со стеком коммуникаций приложений, агентом телеметрии и службой контроля (watchdog). А с периферийным оборудованием это еще сложнее, поскольку это верно независимо от того, выполняется ли инференс на CPU, где все процессы используют один и тот же пул памяти, или на встроенном GPU, который является наиболее распространенным форм-фактором GPU в периферийных устройствах.
Такие платформы, как NVIDIA Jetson, объединяют CPU и GPU в единый пул общей памяти, что означает, что процессы операционной системы (ОС) и рабочая нагрузка инференса буквально конкурируют за одни и те же байты. Борьба за ресурсы на периферии не приводит к медленным ответам, как в облачной среде; она может привести к сбою службы инференса прямо во время выполнения. В некоторых случаях это делает изоляцию ресурсов первостепенной задачей проектирования, а не просто оптимизацией.
Кроме того, при такой гетерогенности поддерживать матрицу совместимости оборудования непросто. Могут возникнуть несовместимости, которые редко проявляются в начале. Они всплывают в процессе эксплуатации, на сотнях устройств, в самый неподходящий момент. Red Hat решает эту проблему с помощью программы сертификации оборудования для Red Hat Device Edge и Red Hat OpenShift. Для каждого класса устройств в парке документируется и тестируется проверенная комбинация базовой ОС, ядра, среды выполнения и поддерживаемых ускорителей, что превращает управление оборудованием из реактивного в проактивное и снижает риск интеграции, к которому особенно чувствительны рабочие нагрузки инференса ИИ.
Теперь, когда аппаратный ландшафт понятен, следующий вопрос, учитывая эту аппаратную гетерогенность, заключается в том, на какой программной платформе следует запускать каждый класс устройств.
Запуск службы инференса: выбор правильного уровня платформы
Программная платформа, на которой размещается служба инференса, определяет, какие операционные возможности доступны, сколько накладных расходов на ресурсы потребляет сама платформа и какие инструменты интегрируются с инфраструктурой управления. Существует спектр вариантов, и выбор правильного уровня для каждого класса устройств важен как для эффективности, так и для эксплуатационной пригодности. Red Hat знает об этом, и именно поэтому предлагает широкий спектр вариантов, чтобы помочь подобрать платформу и требования к вариантам использования.
Для наиболее ограниченных устройств, где конкурирующие рабочие нагрузки и сама ОС оставляют примерно 1 ядро и 1,5 ГБ памяти (рекомендуется 3 ГБ / 4 ГБ, если развертывание выполняется по сети) для операционной системы платформы, Red Hat Device Edge с Podman, упрощенный за счет использования Quadlets, предоставляет возможности среды выполнения контейнеров без накладных расходов Kubernetes. Quadlet преобразует декларативные файлы определений контейнеров в файлы модулей systemd, поэтому служба инференса управляется непосредственно systemd: предсказуемый порядок запуска, автоматический перезапуск при сбое, ограничение ресурсов с помощью элементов управления срезами systemd (MemoryMax и AllowedCPUs) и полная интеграция с journald для ведения журналов. Серверы инференса, такие как минимальный сервер ONNX Runtime или пользовательский легковесный контейнер инференса, работают как первоклассные службы systemd. Это правильный уровень для устройств far-edge, где каждый мегабайт на счету. При этом, если вы хотите придерживаться использования файлов compose для контейнеров для развертывания ваших приложений, это также возможно при использовании данной платформы.
Для устройств, имеющих не менее 2 ядер и 2 ГБ доступной памяти (рекомендуется 3 ГБ / 4 ГБ, если развертывание выполняется по сети) и где требуется API, вы можете использовать Red Hat Device Edge с MicroShift, который добавляет легковесный Kubernetes. MicroShift поддерживает манифесты рабочих нагрузок, специфичные для Kubernetes, проверки работоспособности и ограничения ресурсов. Он также помогает с развертыванием моделей ИИ на периферии благодаря KServe (технический предварительный просмотр) запуску в режиме необработанного развертывания (без бессерверных компонентов), предоставляя стандартизированные конечные точки инференса REST и gRPC при значительно меньших накладных расходах, чем полноценная бессерверная инфраструктура. Этот уровень подходит для промышленных ПК и устройств инференса, которым требуется структурированное управление рабочими нагрузками на основе Kubernetes без затрат ресурсов полноценного кластера Kubernetes.
Для серверов near-edge с большими ресурсами есть возможность запуска OpenShift. Существует ряд возможных архитектур, доступных для периферийных сценариев использования с OpenShift. Развертывание OpenShift на одном узле (SNO) требует примерно 4 ядер и 16 ГБ памяти. В качестве примечания: эти ресурсы являются базовой инфраструктурой для SNO; если у вас есть сценарий использования, в котором вы хотите запустить Red Hat OpenShift AI на SNO, а не только инференс, вам потребуется не менее 32 CPU и 128 ГБ памяти для инфраструктуры, а затем вам нужно будет добавить ресурсы для самих приложений.
Компактный кластер из 3 узлов также требует 4 ядер и 16 ГБ оперативной памяти на узел, но обеспечивает полную высокую доступность.
Для площадок, которым требуется высокая доступность, но которые не могут позволить себе 3 полноценных узла, в OpenShift 4.20 были представлены 2 компактные топологии: «Два узла с арбитром» (Two-Node with Arbiter), которая добавляет легковесный третий узел, единственной задачей которого является поддержание кворума etcd, и «Два узла с ограждением» (Two-Node with Fencing), которая достигает того же результата всего с 2 узлами, используя ограждение на основе контроллера управления основной платой (BMC) через Pacemaker для изоляции сбойного узла и предотвращения ситуации «разделенного мозга» (split-brain). В этих случаях управляющим узлам требуется не менее 2 ядер и 16 ГБ памяти, в то время как арбитру (если он есть) требуется только 1 ядро и 8 ГБ.
Ниже приведена сводка минимальных ресурсов, необходимых для каждой архитектуры OpenShift, как это указано в официальной документации. Обратите внимание, что каждое ядро CPU равно 2 виртуальным центральным процессорам (vCPU), когда включена Hyper-threading (гиперпоточность), что является обычным значением по умолчанию, если выполнение детерминированных рабочих нагрузок не входит в требования к варианту использования.
Минимальные требования для каждой архитектуры OpenShift edge
Наконец, для развертываний, где даже эти базовые показатели слишком высоки, компонуемая архитектура OpenShift позволяет администраторам кластера отключать дополнительные компоненты во время установки, такие как консоль, оператор baremetal или оператор хранилища, что еще больше снижает потребление ресурсов в соответствии с возможностями устройства.
Хотя мы сопоставили некоторые варианты платформы с уровнями аппаратных ресурсов, выбор между Red Hat Device Edge и OpenShift включает в себя больше переменных, чем просто запас памяти и CPU. Вам необходимо учитывать операционную модель, стратегию обновления, предположения о связности и требуемую степень совместимости с Kubernetes — все это играет роль. Если вам интересно разобраться в принятии этого решения, специализированная система принятия решений, подробно охватывающая эти аспекты, доступна в предыдущей серии статей.
Выбор правильной платформы для каждого класса устройств необходим, но недостаточен. Как только решение о платформе принято, следующая задача — убедиться, что аппаратное ускорение, предоставляемое этими устройствами, работает под ней надежно.
Аппаратное ускорение: управление цепочкой зависимостей
Большинство развертываний ИИ на периферии полагаются на аппаратное ускорение. Устройства NVIDIA используют CUDA и TensorRT. Процессоры Intel используют OpenVINO и инструментарий oneAPI. Системы AMD используют Radeon Open Compute (ROCm). Другие специализированные ускорители ИИ для периферии привносят свои собственные комплекты разработки программного обеспечения (SDK). Каждый из этих стеков хорошо работает в изоляции, но проблема, специфичная для рабочих нагрузок ИИ, заключается в том, что цепочка зависимостей между оборудованием, драйвером ядра, инструментарием пользовательского пространства и средой вывода хрупка таким образом, что это может привести к скрытым сбоям.
Эта хрупкость проявляется на нескольких уровнях. Например, на уровне приложений движки TensorRT могут потребовать пересборки при изменении конфигураций TensorRT, CUDA, драйверов или GPU. На системном уровне обновления ОС или ядра могут сделать модули драйверов GPU недействительными, что сделает ускоритель полностью недоступным для рабочих нагрузок вывода. Это означает, например, что обновление ОС, предназначенное для исправления уязвимостей (CVE), может незаметно нарушить вывод при следующей попытке загрузки модели. Другой пример: на платформах NVIDIA Jetson контейнеризированный доступ к интегрированному GPU Tegra зависит от специфичного для платформы обнаружения устройств и конфигурации среды выполнения контейнеров. CDI (Container Device Interface) specifications may need to be generated or refreshed для отражения изменений в конфигурации ускорителя и драйверах хоста, и сбои в этом рабочем процессе предоставления доступа к устройству могут помешать контейнерам вывода получить доступ к GPU, даже если сам драйвер остается функциональным.
Решение этих проблем требует контроля на 2 уровнях. На уровне устройства необходимо зафиксировать весь программный стек, включая версию ядра и модули драйверов. А на уровне парка устройств вам нужен конвейер развертывания, который проверяет доступность ускорителя и запускает легковесный дымовой тест вывода после каждого обновления, чтобы обнаружить ошибку до того, как она распространится по всему парку.
Red Hat решает обе задачи. Для уровня устройства Red Hat Device Edge и Red Hat Enterprise Linux (RHEL) могут использовать bootc для управления ОС как неизменяемым, версионированным образом, который фиксирует ядро, модули драйверов и инструментарий пользовательского пространства вместе. В этих системах обновления являются атомарными, и доступен откат, если обновление нарушает зависимость ускорителя, поэтому программный стек, от которого зависит рабочая нагрузка вывода, никогда не «дрейфует» незаметно между развертываниями.
В развертываниях на базе OpenShift эквивалентный контроль обеспечивается декларативной конфигурацией узлов. Оператор Node Feature Discovery обнаруживает доступные ускорители и соответствующим образом помечает узлы, в то время как GPU Operator управляет полным жизненным циклом драйверов и инструментария как версионированным ресурсом. Оба оператора настраиваются с помощью пользовательских ресурсов, зафиксированных в Git, поэтому стек ускорителей становится частью определения кластера, а изменения проходят через тот же процесс проверки и отката GitOps, что и любая другая конфигурация.
Для уровня парка устройств OpenShift (Tekton) и конвейеры OpenShift AI (Kubeflow) предоставляют конвейер развертывания, где можно проверить доступность ускорителя и выполнить легковесный дымовой тест вывода после каждого обновления. Для парков автономных устройств RHEL, которые не являются частью кластера Kubernetes, Red Hat Edge Manager берет на себя эту роль, развертывая обновления образов bootc по всему парку контролируемым, поэтапным образом и обеспечивая видимость того, какие устройства работают с какой версией образа, поэтому одни и те же принципы применимы независимо от того, являются ли устройства парка узлами Kubernetes или «голыми» устройствами RHEL в полевых условиях. В совокупности эти 2 элемента контроля устраняют разрыв между работающим прототипом (POC) и развертыванием, которое продолжает работать после обновлений ОС, драйверов и изменений моделей.
Необходимо учесть еще одну вещь: цепочка зависимостей также создает проблему жизненного цикла версионирования, которая выходит за рамки обновлений отдельных устройств. Когда в парк добавляются новые классы устройств, конвейер непрерывной интеграции, непрерывной доставки и непрерывного развертывания (CI/CD) моделей может потребоваться для создания новых скомпилированных вариантов, специфичных для оборудования, которого не существовало, когда текущая модель обучалась и проверялась. Это не разовая активность; она должна происходить для каждой версии модели, находящейся в настоящее время в реестрах производства и тестирования, которую необходимо запустить на новом классе оборудования. Проектирование конвейера CI/CD для создания всех необходимых аппаратных вариантов в виде матричного вывода, помеченного как версией модели, так и целевым оборудованием, позволяет избежать превращения этого процесса в кошмар при закупке новых типов устройств.
Однако цепочка зависимостей от ускорителя — не единственная проблема выполнения, характерная для ИИ-нагрузок на периферии. Как только стек становится стабильным, а ускоритель — надежно доступным, в игру вступают еще 2 ограничения, с которыми облачные развертывания сталкиваются иначе. На многих периферийных устройствах CPU и GPU используют единый пул физической памяти, поэтому любой скачок нагрузки процесса напрямую влияет на механизм вывода (inference engine). Если вы планируете использовать такие устройства с унифицированной памятью, прочитайте следующий раздел, чтобы узнать, как это может повлиять на ваш сценарий использования ИИ на периферии.
Конкуренция за ресурсы и гарантии времени выполнения: проблемы выполнения ИИ на периферии
При использовании устройств с унифицированной памятью возникают типичные проблемы выполнения в развертываниях ИИ на периферии. Первая и самая распространенная — это совместное использование ресурсов ИИ-процессами и обычными процессами, но, в зависимости от сценария, могут быть и другие, например, чувствительность рабочей нагрузки к задержкам. Давайте рассмотрим обе.
Периферийные устройства и общие ресурсы
На периферийных платформах со встроенным ИИ-оборудованием CPU и GPU используют единый пул физической памяти. Это означает, что скачок потребления памяти любым из процессов, запущенных на устройстве, напрямую сокращает объем, доступный для механизма вывода, что потенциально может привести к ошибке нехватки памяти (OOM) в процессе вывода, или наоборот — ИИ-вывод может забрать память, необходимую для работы ОС и приложений.
Решением является явное бюджетирование памяти для всех рабочих нагрузок на устройстве, при котором общий пул рассматривается как ограниченный ресурс, который должен быть разделен на этапе проектирования, а не распределяться оппортунистически во время выполнения. Это означает установку жестких лимитов памяти для каждой группы нагрузок на уровне ОС, чтобы ни один процесс не мог расшириться в область памяти, зарезервированную для вывода. В Red Hat Device Edge с Podman это можно сделать с помощью элементов управления на основе срезов systemd, а в MicroShift или OpenShift — с помощью запросов и лимитов памяти Kubernetes, которые обеспечивают аналогичную изоляцию на уровне оркестрации.
Кроме того, лимиты памяти контейнеров сами по себе могут не обеспечить полную защиту от исчерпания памяти на периферийных платформах с унифицированной памятью. Существуют некоторые inference frameworks and accelerator drivers manage additional memory pools компоненты, потребление которых не всегда видно через стандартные метрики уровня контейнера. По этой причине, помимо лимитов контейнеров, часто требуются специфический мониторинг памяти и настройка памяти на уровне фреймворка.
Проблема задержки
Проблема задержки типична для сценариев использования ИИ на периферии, и она имеет 2 различных измерения, которые часто требуют разных решений.
Первое — это чувствительность к задержкам. Многие периферийные ИИ-приложения не могут оптимизироваться под среднее время отклика так, как это делают облачные приложения. Система инспекции на конвейере, где поздние обнаружения означают пропущенные дефекты, или система предиктивного обслуживания, собирающая данные о вибрации с высокой частотой, требуют стабильно низкой задержки, даже если случайные скачки допустимы.
Второе — это детерминизм. Некоторым приложениям требуется гарантированное время отклика в худшем случае, а не просто низкое среднее значение. Предохранительная блокировка, которая должна сработать в рамках ограниченного окна, или робототехнический контроллер, где джиттер планировщика нарушает последовательность движений, не могут допустить, чтобы шаг вывода обычно выполнялся за 2 мс, но иногда занимал 50 мс из-за того, что планировщик GPU понизил его приоритет или диспетчеру памяти потребовалась реорганизация. В таком случае это может привести к физическим последствиям.
Вывод с учетом задержек
Начиная с проблемы чувствительности к задержкам, для приложений с более мягкими требованиями к задержкам, использующих пакетный вывод, первым решением по конфигурации является настройка размера пакета сервера. Пакетная обработка увеличивает использование GPU и пропускную способность, но размер пакета более 1 добавляет задержку очереди, которая может нарушить требования к времени отклика. Поэтому для большинства сценариев ИИ на периферии, чувствительных к задержкам, размер пакета следует явно установить равным 1, а не оставлять значение по умолчанию для фреймворка обслуживания.
Кроме того, фокусируясь на архитектуре ИИ-сервиса и на том, как она может помочь снизить задержку, можно выделить 2 паттерна вывода, которые снижают эффективное потребление ресурсов и время вывода без ущерба для точности. Первый называется «иерархическим» или «каскадным» выводом, когда вы запускаете небольшую быструю модель на ограниченном конечном устройстве для типичных простых случаев, переходя к более крупной модели на более мощном шлюзе или в облаке только тогда, когда показатель уверенности низок или в случаях, когда нет жестких ограничений по задержке.
Второй паттерн — это «адаптивный» вывод, при котором полный конвейер вывода запускается только тогда, когда входные данные датчиков существенно изменились, используя сначала легкую проверку обнаружения изменений. Это освобождает систему от предыдущих очередей вывода, когда вам нужно использовать модель, и, как дополнительное преимущество, значительно снижает среднее энергопотребление в стабильных ситуациях.
Эти паттерны предполагают использование специализированных моделей с быстрым временем вывода, таких как обнаружение объектов, классификация дефектов, оценка предиктивного обслуживания или оценка позы. Другая проблема возникает, когда периферийная рабочая нагрузка включает большую языковую модель (LLM) — например, полевой помощник, работающий на шлюзе ближнего края, которому нужно отвечать на запросы техника или локально суммировать журналы датчиков. Задержка вывода LLM определяется генерацией токенов, а не одним прямым проходом, поэтому стандартные методы оптимизации, которые мы обсуждали, здесь напрямую не применимы.
Для этого случая стоит знать два метода. Первый — это спекулятивная декодировка (speculative decoding), которую можно рассматривать как особый случай каскадного вывода, использующий небольшую черновую модель для генерации последовательностей токенов-кандидатов, которые более крупная модель-верификатор принимает или отклоняет параллельно. Это сокращает количество необходимых полных прямых проходов и значительно сокращает время до первого токена на ограниченном оборудовании.
Второй метод — это квантование кэша ключей-значений (KV cache quantization), которое снижает задержку и объем памяти кэша внимания, что является дополнительным преимуществом для периферийных сценариев, поскольку, как мы видели, на периферийных платформах с унифицированной памятью вывод напрямую конкурирует с тем же пулом памяти, который используют все остальные процессы на устройстве. Важно, чтобы используемый вами сервер вывода поддерживал эти методы, и в этом смысле они поддерживаются в сервере вывода vLLM, который доступен через Red Hat OpenShift AI как часть стека обслуживания моделей.
Детерминизм и ИИ-вывод
Для приложений, требующих детерминизма, этой настройки недостаточно, поскольку планировщик, подсистема памяти и уровень прерываний способны вызывать задержки независимо от того, насколько хорошо настроен механизм вывода. Решение этой задачи требует дополнительных функций и конфигурации на уровне операционной системы.
Первая — это конфигурация ядра реального времени PREEMPT_RT, которая заменяет стандартный планировщик на тот, который обеспечивает ограниченную задержку в худшем случае. Помимо ядра реального времени (RT), конфигурация привязки к CPU (CPU affinity) и изоляции ядер с помощью параметра ядра isolcpus являются необходимым условием для этих RT-гарантий. Без них другие потоки ядра все равно могут быть запланированы на ядрах вывода и нарушить временной контракт.
IRQ affinity (привязка запросов прерываний) распространяет тот же принцип на аппаратные прерывания. Сетевые интерфейсы, хранилища и шины датчиков должны быть вынесены за пределы изолированных ядер, поскольку входящее прерывание вытеснит даже поток реального времени (RT thread). На уровне памяти использование hugepages (страницы по 2 МБ или 1 ГБ через hugetlbfs) сокращает количество промахов TLB при работе с большими весами моделей и буферами активации на периферийном оборудовании. При соблюдении всех этих условий полный цикл управления имеет предсказуемое время выполнения в худшем случае.
Стоит отметить, что эти функции доступны не только в RHEL и Red Hat Device Edge; также возможно настроить привязку/изоляцию CPU и IRQ, использование hugepages памяти и другие возможности оптимизации в OpenShift.
Также важно упомянуть, что описанные нами средства обеспечения детерминизма (ядро реального времени, изоляция CPU, IRQ affinity и т. д.) предназначены для одиночных быстрых вызовов логического вывода и не применимы к логическому выводу LLM, где задержка определяется итеративной генерацией токенов и измеряется сотнями миллисекунд независимо от конфигурации планировщика.
В этом разделе также не рассматривается настройка, специфичная для неоднородного доступа к памяти (NUMA-узлы), поскольку многопроцессорное оборудование редко используется на периферии. В редких случаях установки на периферии, где используется многопроцессорное оборудование, эти механизмы также доступны в RHEL, Red Hat Device Edge и OpenShift, поэтому их можно использовать в дополнение к описанным здесь средствам управления.
Подключение логического вывода к данным: шаблоны обмена сообщениями в Edge AI
Мы описали, как эффективно выполнять логический вывод на устройстве, но как данные попадают в службу логического вывода и как результаты логического вывода достигают систем, которые их потребляют? На периферии это архитектурный выбор, имеющий прямые последствия для задержки, надежности и процессов машинного обучения (MLOps).
Большинство датчиков и источников данных не поддерживают REST или gRPC «из коробки». Они предоставляют данные через драйверы ядра, Video4Linux2 (V4L2), последовательные интерфейсы или проприетарные SDK, поэтому процесс захвата почти всегда находится между необработанным источником и службой логического вывода. Таким образом, шаблон обмена сообщениями — это выбор того, как процесс захвата и последующие потребители результатов логического вывода будут координироваться друг с другом.
При проектировании архитектуры перемещения данных вам нужно будет определить, как данные физически перемещаются между процессами (сериализованные копии через сокеты или разделяемая память с нулевым копированием), и будет ли обмен данными синхронным, асинхронным или потоковым. Упрощая комбинацию этих вариантов, можно выделить 3 шаблона, которые охватывают большинство развертываний Edge AI.
Шаблоны приема данных во время логического вывода
Синхронный запрос-ответ
Процесс захвата вызывает службу логического вывода через REST или gRPC, ожидает результата и действует на его основе. Это легко отследить, но создает жесткую связь между вызывающим объектом и службой логического вывода, поскольку, если обновление модели меняет время выполнения логического вывода или формат вывода, вызывающий объект перестает работать. Это означает наличие последствий для MLOps, поскольку при изменении модели вам нужно будет убедиться, что это не нарушит конвейер обработки данных.
Событийно-ориентированная модель pub/sub
Но существует множество решений pub/sub; какое из них следует использовать? Наиболее распространенными, основанными на архитектуре брокера, являются Message Queuing Telemetry Transport (MQTT) и Kafka, в то время как существуют ZeroMQ и Data Distribution Service (DDS), которые полностью исключают брокера и соединяют издателей и подписчиков напрямую.
/)
/)
