Управляемые пакеты и модели для каждого этапа потока в Anaconda Platform

Источник: Anaconda•

Управляемые пакеты и модели для каждого этапа потока в Anaconda Platform

Теперь Anaconda Platform сопоставляет каждый этап потока с каталогом управляемых пакетов и моделей Anaconda и записывает, что именно использовалось при каждом запуске.

Поток, который безупречно работает на вашем ноутбуке, все равно может застопориться перед выходом в продакшн из-за ручной проверки безопасности каждого пакета и модели, от которых он зависит, — проверки, которая обычно проводится уже после написания кода. С сегодняшнего дня эта проверка происходит автоматически благодаря выпуску управляемых пакетов и моделей в рамках AI Orchestration в Anaconda Platform. Добавьте декораторы Anaconda в поток, и каждый шаг будет выполняться с использованием пакетов и моделей, одобренных вашей организацией.

Как только ИИ-проект достигает стадии продакшна, он обычно запускается как повторяемая задача. Он извлекает новые данные, обучает или дообучает модель, проводит оценку и отправляет модель в работу только в том случае, если она соответствует установленному вами порогу. В Anaconda Platform вы пишете эту задачу как поток: класс Python, где каждый метод является шагом. Один и тот же код работает на вашем ноутбуке, на облачных GPU или по ночному расписанию. Потоки построены на Metaflow, фреймворке с открытым исходным кодом, который перешел в Anaconda вместе с приобретением Outerbounds в апреле 2026 года.

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

  • Какие пакеты на самом деле использует этот шаг?
  • Откуда взялась эта модель и разрешено ли нам использовать ее в продакшене?

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

Этот релиз привносит такой фундамент непосредственно в сам поток. Теперь каждый шаг получает свои пакеты и модели из управляемых источников Anaconda. Когда вы объявляете, что нужно для шага, платформа создает среду из каналов, которые разрешено использовать вашей команде, и извлекает модель только в том случае, если ваша политика в отношении моделей это позволяет. Она также записывает оба этих действия вместе с запуском, поэтому любой результат можно проследить до того, что его породило. Ваша команда безопасности устанавливает правила один раз, а разработчики продолжают писать направленные ациклические графы (DAGs) так, как они привыкли.

Управление пакетами Anaconda теперь в ваших потоках

Чтобы использовать доверенные пакеты Anaconda в потоке, добавьте декоратор @anaconda_base к вашему потоку и перечислите версию Python и пакеты, которые ему нужны. Платформа создает OCI-совместимые образы, используя пакеты из управляемых каналов Anaconda, поэтому нет необходимости настраивать среду вручную. Вот пример потока, который зависит от pytorch и pandas, сохраненный как pytorch_flow.py:

Определение @anaconda_base применяется к каждому шагу в потоке, и все, что находится ниже него, является обычным кодом Python. За этим единственным объявлением каждый шаг получает:

  • Курируемые и проверенные на безопасность каналы Anaconda в качестве источника пакетов
  • Политики пакетов вашей организации, такие как правило блокировки известных уязвимостей, применяемые до установки чего-либо
  • Пакеты, которые Anaconda создает и поддерживает, подкрепленные метаданными безопасности и спецификациями состава программного обеспечения (SBOM), которые документируют их компоненты, лицензии и происхождение

Эти каналы опираются на Trusted Distribution от Anaconda: более 19 000 проверенных пакетов, созданных, протестированных и подписанных цифровой подписью инженерами Anaconda, прежде чем поток сможет их использовать.

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

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

Администраторы устанавливают политики пакетов для каналов каждого периметра в платформе. Политика — это набор правил исключения, основанных на метаданных безопасности пакетов Anaconda, таких как оценка общих уязвимостей и рисков (CVE), статус или семейство лицензий, и каждый канал предлагает рекомендуемую политику по умолчанию, которую администраторы могут настроить.

Политика канала, исключающая пакеты с критическими активными CVE.

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

Чтобы перенести поток из разработки в продакшн, вы продвигаете его через существующий конвейер непрерывной интеграции и непрерывной доставки (CI/CD), включая любые этапы утверждения, которые уже использует ваша команда, такие как проверка кода, тестовые запуски или согласования. Код остается прежним, и с этого момента применяются политики производственного периметра. Подробности см. в нашей недавней публикации о периметрах.

Модели поступают из нашего каталога, отфильтрованные по политике

Шаги, которым нужна модель, извлекают ее из каталога моделей Anaconda. Ваша команда видит только те модели, которые разрешает ее периметр, а администраторы пишут правила, используя метаданные модели: издатель, лицензия, страна происхождения, размер модели и ожидаемые требования к памяти. Правило может быть таким простым, как «в продакшене используются только модели, лицензия которых разрешает коммерческое использование».

Каталог содержит более 77 курируемых моделей. Каждая из них автоматически отбирается, квантуется и проходит бенчмаркинг, а затем проверяется командой Anaconda перед публикацией. Модели поставляются со своей спецификацией состава ИИ (AIBOM), документацией по лицензии и результатами бенчмарков, поэтому ваша команда может проверить происхождение и риски модели, прежде чем кто-либо ее развернет.

Как только политики установлены, ваша команда может использовать одобренные модели несколькими способами: внутри шага потока с помощью декоратора @anaconda_models, загрузив для локальной работы или в качестве выделенного развертывания вывода с собственной конечной точкой API.

Наш вывод моделей создан для производственных нагрузок. Каждая модель доступна на нескольких уровнях квантования, поэтому вы можете пожертвовать некоторой точностью ради меньшего размера и более быстрого времени отклика, когда шаг должен выполняться в больших объемах. Разверните на конечной точке с автоматическим масштабированием GPU в облаке или загрузите ту же модель локально с помощью Desktop. Оба пути предоставляют один и тот же API, поэтому код, который вызывает модель, не меняется при переходе от тестирования к продакшну.

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

На каждой странице модели показано, как использовать модель в потоке, локально или в качестве развертывания.

Реагируйте на рекомендации по безопасности с помощью изменения в одну строку

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

Поиск пакетов PyTorch и их известных CVE в канале.

Например, CVE-2025-32434 влияла на то, как PyTorch загружает файлы моделей в версиях до 2.5.1, и была исправлена в версии 2.6.0. Поскольку каждый поток (flow) объявляет свои пакеты в коде, поиск потоков, привязанных к уязвимой версии, сводится к поиску по вашим репозиториям. Обновление выполняется путем изменения одной строки с версией пакета и последующего перезапуска. Платформа сохраняет артефакты каждого запуска, поэтому вы можете сравнить новый запуск непосредственно с предыдущим:

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

Объединяя все вместе

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

Запросите демо-версию, чтобы увидеть, как управляемые пакеты и модели работают в потоке в вашей собственной облачной учетной записи.

Ознакомьтесь с документацией, чтобы узнать больше.

О чём эта статья

Ещё в разделе «Разработка ПО»

Все →

Ещё от Anaconda