Развертывание ИИ на «границе сети» (edge) — это одновременно и перспективная, и сложная задача. В предыдущих статьях вы узнали, как оптимизировать и упаковывать свои граничные ИИ-модели, а также как выполнять их для удовлетворения типичных требований вариантов использования на периферии, но это еще не все.
В этой статье мы переключим наше внимание с архитектуры моделей и сервисов на вопросы управления, которые влияют на наш сценарий использования граничного ИИ после того, как модель начинает работать на тысячах устройств. Мы ответим на такие вопросы: Как узнать, какая версия где работает? Как обновить ее, не вызывая инцидентов во всем парке устройств? И как управлять устройствами, к которым нет доступа обычными средствами?
Эти вопросы определяют управление ИИ-моделями на периферии, и они сложнее, чем кажутся. В облачном ИИ управление моделями — это централизованная проблема. На периферии вы управляете тысячами или даже сотнями тысяч географически распределенных устройств, каждое из которых имеет собственный профиль оборудования, особенности подключения, региональный бизнес-контекст и, возможно, собственные нормативные требования. Обновление модели, которое просто выполнить в облаке, может оказаться гораздо сложнее для всего парка граничных устройств, а неудачное обновление, отправленное на каждое устройство одновременно, — это совсем другой тип инцидента по сравнению с облаком.
Управление парком устройств граничного ИИ: понимание и контроль того, что и где работает
Ответ на вопрос об управлении ИИ-моделями начинается с подхода, который вы используете для управления устройством и операционной системой (ОС), на которой работает эта ИИ-модель.
Декларативное управление против императивного
Существует 2 фундаментальных подхода к управлению состоянием устройства: декларативный и императивный. Императивная модель говорит каждому устройству, что делать в конкретный момент времени. Декларативная модель определяет желаемое состояние и позволяет каждому устройству непрерывно приводить свое фактическое состояние в соответствие с этим определением. Для управления парком устройств граничного ИИ более подходит декларативный подход. Устройства на периферии уходят в оффлайн, неожиданно перезагружаются и работают в условиях, которые центральная система не может полностью предсказать. Помимо лучшей масштабируемости, декларативная система справляется с этим естественным образом, поскольку устройство несет ответственность за сближение с желаемым состоянием, когда это возможно. GitOps развивает эту концепцию дальше, используя репозиторий с контролем версий в качестве единственного источника достоверных данных. Вы фиксируете изменения в репозитории Git, и агент на каждом устройстве применяет их. Это дает вам полный след аудита, возможность отката к любому предыдущему состоянию и четкий процесс утверждения изменений с помощью стандартных рабочих процессов pull-запросов.
Управление по принципу pull (вытягивание) против push (проталкивание)
Следующий вопрос заключается в том, как устройства, содержащие ИИ-модели, сообщают о своем фактическом состоянии плоскости управления и как система доставляет обновления конфигураций. Здесь есть 2 паттерна: управление по принципу pull и push. В модели на основе push центральная система отправляет обновления и записывает то, что она отправила, в то время как в модели на основе pull граничное устройство инициирует запрос, а центральная система должна только ответить. Связь на основе pull имеет практическое преимущество в сети, которое имеет огромное значение на периферии. Устройства, находящиеся за трансляцией сетевых адресов (NAT), за корпоративными брандмауэрами или использующие сотовую связь, по умолчанию недоступны извне. Управление на основе push требует входящего подключения к каждому устройству, что означает открытие правил брандмауэра или управление туннелями виртуальной частной сети (VPN). Связь на основе pull требует только исходящего подключения от устройства, которое доступно практически всегда, даже в условиях ограничений сети. Для развертывания граничного ИИ это часто является решающим фактором.
Еще одна проблема метода управления push заключается в том, что записанное состояние и фактическое состояние устройства могут расходиться всякий раз, когда сбой push-уведомления не удается, устройство находится в оффлайне или обновление завершается частично. Напротив, в модели на основе pull каждое устройство периодически сообщает о своем фактическом работающем состоянии. Плоскость управления сохраняет то, что она получила, а не то, что она отправила, что является еще одной причиной, почему управление pull лучше всего подходит для сценариев использования на периферии.
Сегментация парка устройств
Следующее требование — это возможность нацеливать конфигурацию, ИИ-модель и системные обновления не просто по принципу «все устройства сразу». Реальные периферийные развертывания имеют сегментацию, например:
- По классу оборудования, поскольку на разном оборудовании работают разные варианты моделей
- По географическому признаку, поскольку нормативные требования могут различаться в зависимости от страны
- По бизнес-подразделениям, поскольку общие платформы, обслуживающие несколько команд, требуют изоляции арендаторов
- По операционной группе, поскольку рабочие и тестовые устройства требуют применения разных политик
По этой причине вы должны прикреплять метаданные к каждому устройству при регистрации и поддерживать их на протяжении всего жизненного цикла устройства. Затем вы можете использовать эти метки, такие как класс оборудования, географический регион, бизнес-подразделение и операционный уровень, для выражения политик развертывания вроде «развернуть версию модели v2.1 на всех устройствах с меткой hardware-class=jetson-orin-agx в регионе europe на операционном уровне production». Это является основой для целевых развертываний, отчетов о соответствии и реагирования на инциденты для сценариев граничных вычислений.
Интеграция через API управления
Еще один фактор, который необходимо учитывать, — это интеграция платформы управления с другими подсистемами для извлечения большей ценности и поддержки более сложных сценариев использования. Наличие интерфейса программирования приложений (API) — лучший способ упростить эту интеграцию, поскольку API управления делают инфраструктуру компонуемой. Когда те же возможности, которые доступны в консоли управления или интерфейсе командной строки (CLI), также доступны через API, вы можете легко интегрировать управление парком устройств, например, в существующие конвейеры непрерывной интеграции и непрерывной доставки (CI/CD), инициировать развертывание моделей в рамках более широкого процесса релиза, запрашивать состояние устройств с платформ наблюдаемости и автоматизировать реагирование на операционные события.
Это тот же подход, который Red Hat применила в своих продуктах. Например, Red Hat Advanced Cluster Management предоставляет этот API для развертываний Red Hat OpenShift и MicroShift с таргетингом кластеров на основе меток, распространением политик, поддержкой GitOps и управлением, интегрированным с внешними инструментами автоматизации. Red Hat Edge Manager предоставляет аналогичные возможности для узлов Red Hat Enterprise Linux (RHEL) / Red Hat Device Edge с определениями групп устройств, которые отражают любую комбинацию аппаратных, географических или бизнес-атрибутов, а также связью на основе pull, которая работает через NAT и границы брандмауэров без необходимости входящего доступа к полевым устройствам.
С помощью этих инструментов вы обеспечите согласованность развертывания: нужная модель на нужном устройстве. Это необходимое условие, но именно качество модели определяет, приносит ли система пользу. И это еще не все. В разделе «Часть 1: Подготовка моделей ИИ к развертыванию» мы описали проблему распространения моделей, но хранение и перемещение модели на устройство — это лишь часть проблемы. Вам также необходимо место для отслеживания версий моделей. Обычно для этого используется реестр моделей. Реестр моделей — это центральное место для регистрации, весионирования и управления моделями перед их развертыванием. Он хранит метаданные о каждой модели, такие как проект, настройки обучения, показатели производительности и события развертывания, что делает его ключевым компонентом управления моделями.
Red Hat OpenShift AI включает в себя реестр моделей. В предстоящем выпуске Edge Manager новый сборщик каталогов будет собирать выбранные метаданные моделей и ссылки на артефакты из этого реестра и публиковать их в программном каталоге Edge Manager. Это помогает оптимизировать управление жизненным циклом моделей на периферии: когда вы регистрируете новую версию модели, она появляется в каталоге, и операторы могут развертывать ее на своих парках устройств, используя те же политики развертывания, которые они применяют уже сейчас.
Ранее мы упоминали, что наличие правильной модели на правильном устройстве имеет важное значение, но чтобы убедиться в этом, вам потребуется отслеживать специфичные для ИИ метрики наряду с инфраструктурными метриками по всему парку устройств, чему и посвящен следующий раздел.
Наблюдаемость периферийного ИИ: мониторинг специфичных для ИИ метрик качества
Видимость парка устройств обычно охватывает состояние инфраструктуры, такое как версия ОС, образ контейнера и тег модели, работающие на каждом устройстве. Но для рабочих нагрузок ИИ состояния инфраструктуры недостаточно. Устройство может сообщать, что на нем запущенна версия модели v2.1, и быть полностью работоспособным с точки зрения инфраструктуры, в то время как эта модель на самом деле выдает ухудшенные результаты вывода из-за сдвига распределения в локальной среде.
Мониторинг качества ИИ в масштабе всего парка устройств требует иной стратегии телеметрии по сравнению со стандартным мониторингом инфраструктуры. Вы не можете передавать потоком исходные входные и выходные данные вывода с тысяч устройств на центральную платформу; стоимость пропускной способности непомерно высока, а требования к хранению на принимающей стороне огромны. Правильная архитектура собирает статистические сводки на уровне устройства и пересылает только эти сводки, а не исходные данные (за редким исключением).
Как это работает и какие данные не входят в обычный мониторинг инфраструктуры?
На устройстве служба вывода вычисляет и предоставляет специфичные для ИИ метрики, такие как распределение собственных оценок уверенности модели (насколько модель уверена в своих прогнозах), показатели обнаружения по классам с течением времени (как часто прогнозируется каждый выходной класс) и перцентили задержки вывода. Эти метрики важны. Например, распределение оценок уверенности, которое смещается вниз в течение 6 недель, в то время как все инфраструктурные метрики остаются в норме, говорит о том, что модель сталкивается с какими-то трудностями в своей текущей среде. Показатель обнаружения по классу, который внезапно падает до нуля для класса, исторически появлявшегося регулярно, указывает на то, что что-то в среде изменилось.
Эти данные представляют собой не исходные результаты обнаружения, а сводку с соответствующей информацией о них. На этом этапе вы можете отправить эти сводки на локальный или региональный уровень агрегации, который агрегирует данные с устройств на своем сайте или в регионе и потенциально применяет фильтры перед пересылкой на центральную платформу (в основной центр обработки данных или облако).
Если используется эта многоуровневая архитектура, она поддерживает стоимость пропускной способности на каждом уровне пропорционально количеству устройств, с которых он выполняет агрегацию, а не линейно зависящей от количества исходных событий вывода. На центральной платформе агрегированные метрики питают общепарковые панели мониторинга и оповещения, такие как тепловые карты ухудшения точности по объектам, графики трендов дрейфа для каждой версии модели и гистограммы распределения уверенности, сегментированные по классу устройств. Эти представления позволяют операторам выявлять проблемы, которые были бы незаметны на уровне устройства, сравнивать производительность моделей по регионам и расставлять приоритеты при устранении неполадок там, где это важнее всего.
OpenTelemetry является стандартным протоколом для этого конвейера телеметрии. Коллектор OpenTelemetry на каждом периферийном устройстве пересылает метрики в региональную точку агрегации, которая затем пересылает их в централизованное развертывание Prometheus и Графаны (Grafana). Как только информация централизована, вы можете извлекать из нее полезные аналитические данные. Например, вы можете использовать Red Hat TrustyAI, входящий в состав Red Hat OpenShift AI, чтобы добавить анализ на базе ИИ на центральной платформе с помощью тестов статистического дрейфа, обнаружения предвзятости и объяснимости моделей. Эта комбинация дает операционной группе видимость, позволяющую обнаруживать деградацию модели на уровне парка устройств до того, как она проявится в бизнес-метриках нижнего уровня.
Наблюдаемость сообщает вам, когда модель нуждается в изменении. Доставка этого обновления модели ИИ на устройство — совершенно другая проблема. Давайте углубимся в то, как это работает.
Обновления периферийных моделей ИИ: использование каналов с ограниченной пропускной способностью
Доставка моделей на тысячи распределенных устройств создает новый набор проблем, особенно когда пропускная способность, задержка и надежность различаются на разных сайтах.
Одним из эффективных способов распространения обновлений моделей по географически распределенной инфраструктуре является многоуровневая архитектура реестров. Центральный реестр в ядре, региональные зеркальные реестры, расположенные ближе к кластерам периферийных сайтов, и локальные реестры на местах для изолированных сред образуют иерархию. Когда вы публикуете новую версию модели в ядре, она распространяется наружу на зеркала. Периферийные устройства выполняют запросы из ближайшего доступного уровня, что повышает надежность скачивания для сайтов с маргинальным подключением.
Пример многоуровневой топологии распространения моделей ИИ на базе OpenShift и MicroShift
Топология распространения решает проблему того, откуда берутся артефакты модели. Следующая задача заключается в уменьшении объема данных, которые устройства должны передавать в первую очередь, поскольку периферийные сети — это не сети центров обработки данных. Многие устройства подключаются через сотовые сети 4G или 5G, где передача данных имеет свою стоимость. Другие подключаются через общие каналы глобальной сети (WAN), изначально рассчитанные на трафик бизнес-приложений. Это означает, что многогигабайтный образ модели, распространяемый на тысячи устройств одновременно, превращается в проблему планирования сети.
Здесь нет универсального ответа. Это зависит от модели упаковки, выбранной для модели ИИ. Как описано в разделе «Часть 1: Подготовка моделей ИИ к развертыванию», существует несколько подходов к распространению, но упаковка на основе контейнеров в большинстве случаев лучше всего подходит для развертываний периферийного ИИ. Она обеспечивает дедупликацию слоев Open Container Initiative (OCI), версионирование на основе реестра и единую инфраструктуру распространения, общую с контейнерами вашего приложения. По этой причине в данной статье мы будем предполагать, что модель упакована и распространяется как образ контейнера OCI, либо внедренная со своей средой выполнения, либо в виде выделенного ModelCar sidecar.
Помимо выбора метода распространения, существует еще один фактор, который следует учитывать: пропускная способность в периферийных архитектурах обычно ограничена. Хорошая новость заключается в том, что при использовании образов OCI в качестве метода распространения моделей ИИ у вас есть множество вариантов различной степени сложности для снижения потребления трафика во время обновлений.
Дельта-обновления
Базовым подходом является стандартная дедупликация слоев OCI. Когда вы отправляете обновленный образ контейнера, устройства сканируют и загружают только измененные слои. Если вы упаковали модель ИИ вместе со средой выполнения в образ контейнера, как показано в Части 1: Подготовка моделей ИИ к развертыванию, и обновляете модель ИИ, слой среды выполнения выводов остается прежним, а устройства загружают только слой весов модели. Это не требует специальной конфигурации и является неотъемлемой частью формата OCI.
Обратите внимание, что это преимущество относится в основном к подходу с единым образом, когда модель и среда выполнения используют один и тот же образ контейнера. В паттерне ModelCar образ модели содержит только файл весов. Когда модель меняется, фактически меняется весь этот образ целиком, поэтому здесь нет слоев для повторного использования, и дедупликация не дает никаких практических преимуществ. В этом случае вам потребуется нечто дополнительное, например zstd:chunked compression.
Помимо стандартной дедупликации слоев, сжатие zstd:chunked идет еще дальше. Клиенты могут выборочно загружать отдельные фрагменты (по умолчанию 4 МБ) внутри слоя на основе того, какие именно фрагменты различаются, используя запросы диапазонов HTTP. Среда выполнения повторно использует файлы или фрагменты, которые уже существуют локально, не загружая их заново. Для образов моделей, где некоторые файлы весов остаются неизменными между версиями, это может сократить размер передачи даже в пределах одного слоя. Это означает, что образы ModelCar, содержащие единственный файл весов и не получающие преимуществ от дедупликации слоев, все равно могут демонстрировать реальное сокращение передаваемых данных при инкрементальных обновлениях за счет использования zstd:chunked, так как устройство загружает только изменившиеся диапазоны байтов, повторно используя остальное из локального хранилища.
Если вы не хотите использовать zstd:chunked, у вас все равно есть другой подход к снижению использования пропускной способности. Вы можете использовать методы бинарных дельт, которые вычисляют двоичную разницу между двумя версиями слоя и передают только дельту, аналогично тому, как это делает OSTree при своих обновлениях. Как это работает? Библиотека tar-diff с использованием bsdiff и zstd побайтово восстанавливает обновленные слои из предварительно сгенерированных файлов патчей, которые на порядки меньше полного слоя контейнера.
Каждый подход связан с различными компромиссами. Стандартная дедупликация слоев не требует настройки и работает с любым реестром и средой выполнения, совместимыми с OCI, но она помогает только тогда часть образа остается неизменной. Метод zstd:chunked идет дальше и работает даже в пределах одного слоя, но он требует поддержки как со стороны реестра, так и со стороны среды выполнения контейнеров на периферийном устройстве, а экономия зависит от того, какая часть бинарного файла изменилась между версиями.
Кроме того, экономия от zstd:chunked требует наличия реестра образов контейнеров; эти преимущества не распространяются на отключенный транспорт, когда вам нужно использовать файл обновления, например, на USB-накопителе. Наконец, бинарная дельта с tar-diff может обеспечить наименьший объем передаваемых данных из всех трех вариантов, поскольку она вычисляет точную разницу между двумя версиями независимо от структуры слоев. Однако на сегодняшний день не существует стандарта OCI для дельта-распространения, поэтому механизм доставки требует дополнительных инструментов помимо стандартного реестра и клиента OCI.
Red Hat уже предоставляет строительные блоки, необходимые для реализации этого на практике, и активно сокращает разрыв в том, чего еще не хватает. Для архитектуры многоуровневого реестра Red Hat Quay предоставляет 2 взаимодополняющих механизма распространения. Георепликация позволяет одному развертыванию Quay хранить данные образов в нескольких связанных регионах. Когда вы отправляете образ, данные попадают в ближайшее серверное хранилище и реплицируются в фоновом режиме на остальные. Ближайшее доступное хранилище всегда обслуживает запросы на извлечение, что делает распространение прозрачным для клиента. Это хорошо работает для уровня «ядро-регион», где узлы поддерживают надежную связь.
Для узлов с прерывистым или запланированным подключением зеркалирование репозиториев использует отдельные независимые развертывания Quay, которые извлекают контент из вышестоящего реестра по настраиваемому расписанию. Каждое зеркало работает автономно и может продолжать обслуживать запросы на извлечение даже при отключении от источника. Это подходит для уровня «регион-периферия», где подключение не может быть гарантировано. Red Hat Quay хранит и обслуживает образы, сжатые с помощью zstd:chunked, поэтому загрузка частичных слоев и локальное повторное использование фрагментов, описанные в этой статье, работают «из коробки». Совместимые среды выполнения (Podman, CRI-O) обрабатывают дедупликацию на уровне фрагментов автоматически, без необходимости создавать или обслуживать дополнительный реестр.
Что касается бинарных дельт, Red Hat создает oci-delta, инструмент, призванный значительно упростить использование рабочего процесса tar-diff на практике. Ожидается, что он появится в качестве технического превью в RHEL 10.3 и 9.9. Edge Manager включает его для обеспечения дельта-обновлений образов bootc. На сегодняшний день обеспечение работы бинарных дельта-обновлений требует совмещения tar-diff и собственных скриптов для генерации, хранения и применения патчей. oci-delta нацелен на то, чтобы объединить это в единый поддерживаемый инструмент, снижая порог входа для команд, которым требуется минимально возможный объем передаваемых данных, но которые не хотят создавать и поддерживать собственные инструменты для этого.
Обратите внимание, что в этом разделе рассматривались только дельты образов контейнеров, но существуют и другие виды дельт, которые важны для периферийного ИИ. Вместо того чтобы делать образ контейнера единицей изменений, вы можете создать обновление модели как дельту предыдущей модели. Идея заключается в том, чтобы передавать только те веса модели, которые изменились, например, в файле .ptd, и применять их к модели, уже находящейся на устройстве. Это хорошо работает, когда новая версия лишь переобучает часть модели, или когда вы выполняете тонкую настройку (fine-tuning) большой базовой модели и меняется лишь небольшой набор весов. Преимущества аналогичны описанным ранее: объем передачи намного меньше, обновления доходят до устройств быстрее, а устройства с медленным или прерывистым соединением используют меньше трафика. Это также отлично сочетается с описанными выше опциями, поскольку среда выполнения и базовая модель остаются прежними, а на периферию передается только небольшая дельта весов.
Эта архитектура многоуровневого реестра с рассмотренными нами методами дельт и сжатия справляется с устройствами с медленным или прерывистым подключением, но вам нужен другой подход для устройств, у которых вообще нет сетевого пути ни к какому реестру.
Обновления моделей периферийного ИИ: в изолированных средах и air-gapped
Мы увидели, как выбранный для модели подход к упаковке определяет единицу обновления и механизм доставки при наличии подключенной среды; это в равной степени справедливо и для изолированных архитектур.
Начнем с распространения модели в виде файлов. Когда вы распространяете модель непосредственно в виде файлов, единицей обновления является сам файл модели вместе со всеми сопутствующими метаданными или конфигурацией. В изолированных средах механизмом доставки обычно является ручное копирование. Это означает, что вы помещаете новый файл на физический носитель, переносите его на объект и копируете в каталог, из которого служба вывода производит чтение. Это работает для одного устройства, но плохо масштабируется. Здесь нет встроенного управления версиями, атомарного переключения с одной версии на другую и стандартного способа проверить, соответствует ли файл на месте тому, что планировалось развернуть. Каждый из этих пробелов обычно решается с помощью пользовательских сценариев, что увеличивает нагрузку на обслуживание по мере роста парка устройств.
В этой серии статей мы использовали распространение моделей на основе образов контейнеров. В этом случае, будь то внедрение в контейнер вывода или использование sidecar-контейнера ModelCar, обновление модели представляет собой обычное обновление образа контейнера, за исключением образа ОС bootc, где обновление модели является полным обновлением образа ОС. Механизм доставки в обоих случаях одинаков (архивы OCI, переносимые на физических носителях), но детализация доставляемых данных различается.
Для обновлений моделей на основе образов контейнеров, доставляемых на полностью изолированные объекты, процесс включает в себя экспорт обновленного образа модели в переносимый архив OCI, транспортировку этого архива на физическом носителе (обычно на USB-накопителе или внешнем диске во время планового технического обслуживания) и импорт архива в локальное хранилище контейнеров устройства. После попадания в локальное хранилище модель становится доступной для среды выполнения контейнеров точно так же, как если бы она была загружена из активного реестра.
Для обновлений образов ОС bootc, в которые встроена модель, тот же механизм архивов OCI применяется ко всему образу ОС. Устройство применяет обновление с помощью bootc upgrade из локального архива и перезагружается в новую версию.
В обоих случаях все артефакты остаются подписанными с помощью cosign, и устройство проверяет подписи локально независимо от того, как прибыл артефакт. Обновление, доставленное на USB-накопителе, должно пройти ту же проверку подписи, что и обновление, загруженное из активного реестра. Это особенно важно для развертываний с воздушным зазором, где физический канал доставки находится вне пределов обычного мониторинга.
Мы говорим об обновлении одного устройства, но что происходит на объектах с несколькими устройствами, имеющими эпизодическое, нерегулярное подключение к сети? В этом случае, если у вас достаточно устройств, а пространство и логистика объекта это позволяют, развертывание зеркала локального реестра OCI в качестве промежуточного уровня является отличным подходом. Это зеркало может синхронизироваться вручную в автономном режиме или автоматически во время окон связи, принося пользу не только моделям ИИ, но и любому контейнеризованному приложению и образу bootc. Зеркало выполняет загрузку из регионального реестра при подключении и обслуживает все локальные устройства из своего локального хранилища в любое время, даже во время отключений связи.
Вы можете обновлять RHEL, Red Hat Device Edge и OpenShift, используя либо описанный выше метод на основе файлов, либо подход с зеркалом локального реестра, в зависимости от возможностей объекта.
Когда на периферийном объекте размещается множество устройств, также имеет смысл добавить уровень управления, например Edge Manager, для управления парком периферийного объекта в целом, поскольку инструменты управления Red Hat также поддерживают развертывание в изолированных средах.
Описанные выше методы создают эффективный и надежный конвейер доставки. Но что происходит, когда обновление операционной системы или модели ИИ оказывается ошибочным?
При сбое развертываний: откат неудачных обновлений
Существует 2 различных механизма отката, и они предназначены для разных типов сбоев. Первый — откат модели ИИ.
