Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Microsoft Foundry упорядочивает рабочие нагрузки ИИ с помощью многоуровневой архитектуры: ресурс Foundry верхнего уровня для управления, проекты для изоляции разработки и подключенные службы Azure для хранения, поиска и управления секретами.
В этой статье команды ИТ-операций и обеспечения безопасности получают подробную информацию о ресурсе Foundry и базовой архитектуре службы Azure, его компонентах и их взаимосвязях с другими типами ресурсов Azure. Используйте эти сведения, чтобы настроить развертывание Foundry в соответствии с требованиями вашей организации. Дополнительные сведения о том, как развернуть Foundry в организации, см. в разделе "Развертывание Foundry".
Когда следует использовать эту архитектуру
Рассмотрим модель ресурсов Foundry, если этот сценарий включает в себя следующее:
- При первой настройке: вы запускаете новый проект ИИ и хотите один ресурс, который объединяет доступ к модели, размещение агентов и средства оценки.
- Доступ к нескольким командам: для нескольких команд требуются изолированные проекты с развертываниями общей модели и централизованным управлением.
- Проект, основанный на соблюдении требований: Ваша организация требует частного сетевого подключения, шифрования, управляемого клиентом, или области применения Azure RBAC на уровне ресурсов и проектов.
- Миграция Azure OpenAI. Вы переходите от автономного ресурса Azure OpenAI и хотите сохранить существующие политики и RBAC, одновременно добавляя возможности агента и оценки.
Для исследования, проводимого одним разработчиком, рекомендуемым по умолчанию является ресурс Foundry с одним проектом. Если для вашей рабочей нагрузки требуется только выполнения OpenAI в Azure без размещения или оценки агента, может быть достаточно автономного ресурса Azure OpenAI.
Azure типы ресурсов AI и поставщики
В семействе продуктов ИИ Azure вы можете использовать эти поставщики ресурсов Azure, которые поддерживают потребности пользователей на разных уровнях в стеке.
| Поставщик ресурсов | Цель | Поддерживаемые службы |
|---|---|---|
| Microsoft. CognitiveServices | Поддерживает разработку приложений Agentic и GenAI для создания и настройки предварительно созданных моделей. | Foundry; Azure OpenAI; Azure Speech в средствах Foundry; Azure Language в средствах Foundry; Azure Vision в инструментах Foundry |
| Microsoft. Поиск | Поддерживает извлечение знаний из ваших данных | Поиск с использованием ИИ Azure |
Для большинства сценариев разработки ИИ, включая сборку агентов, развертывание модели и рабочие процессы оценки, ресурс Foundry является рекомендуемой отправной точкой. Ресурсы Foundry делятся пространством имен поставщика Microsoft.CognitiveServices с такими службами, как Azure OpenAI, Speech, Vision и Language. Это пространство имен общего поставщика помогает выровнять API управления, шаблоны управления доступом, сетевые сети и поведение политики в связанных ресурсах ИИ.
Используйте следующую таблицу, чтобы определить тип ресурса, соответствующий рабочей нагрузке. В нем показаны конкретные типы ресурсов и возможности в поставщике Microsoft.CognitiveServices.
| Тип ресурса | Поставщик ресурсов и тип | Тип | Поддерживаемые возможности |
|---|---|---|---|
| Microsoft Foundry | Microsoft.CognitiveServices/accounts |
AIServices |
Агенты, оценки, Azure OpenAI, речь, зрение, язык и понимание содержимого |
| Проект Foundry | Microsoft.CognitiveServices/accounts/projects |
AIServices |
Подресурс, относящийся к вышеупомянутому |
| Azure Speech в средствах Foundry Tools | Microsoft.CognitiveServices/accounts |
Speech |
Речи |
| язык Azure в средствах Foundry | Microsoft.CognitiveServices/accounts |
Language |
Язык |
| Azure Vision в инструментах Foundry | Microsoft.CognitiveServices/accounts |
Vision |
Видение |
Типы ресурсов в рамках одного пространства имен поставщика используют одни и те же API управления и аналогичные операции Azure управление доступом на основе ролей (Azure RBAC), конфигурации сетей и псевдонимы для конфигурации Политика Azure. Если вы обновляете с Azure OpenAI на Foundry, ваши существующие пользовательские политики Azure и действия Azure RBAC продолжают применяться.
Иерархия ресурсов Foundry
На следующей схеме показан ресурс Foundry с развертываниями моделей, параметрами безопасности, подключениями и двумя проектами. Подключенные службы Azure, такие как хранилище, Key Vault и Поиск с использованием ИИ Azure, являются отдельными Azure ресурсами в соответствии с собственными границами управления:
Диаграмма с иерархией ресурсов Foundry с границей управления, содержащей развертывания моделей, параметры безопасности, подключения и два проекта. Подключенные ресурсы, такие как хранилище, Key Vault и Поиск с использованием ИИ Azure, показаны как отдельные границы управления.
Важно
Подключенные ресурсы, такие как хранилище, Key Vault и Поиск с использованием ИИ Azure являются независимыми Azure ресурсами с собственными границами управления. Вы управляете сетями, политиками доступа и параметрами соответствия для этих ресурсов отдельно от ресурса Foundry.
Используйте эту модель при планировании архитектуры и границ доступа:
- ресурс Foundry: ресурс Azure верхнего уровня, где вы управляете параметрами управления, такими как сетевые развертывания, безопасность и модели.
- Project: граница разработки в ресурсе Foundry, где команды создают и оценивают варианты использования. Проекты позволяют командам создавать прототипы в предварительно настроенной среде, повторно использовать существующие развертывания моделей и подключения без повторной настройки ИТ-отдела.
- Ресурсы проекта: файлы, агенты, оценки и связанные артефакты, относящиеся к проекту.
- Подключенные ресурсы: службы Azure, такие как Storage, Key Vault и Поиск с использованием ИИ Azure, на которые ресурс Foundry ссылается через подключения. Эти ресурсы имеют отдельные границы управления, поэтому вы управляете своими сетями и политиками доступа независимо.
Это разделение позволяет ИТ-командам применять централизованные элементы управления на уровне ресурсов, а команды разработчиков работают в границах уровня проекта.
Примечание
Большинство новых API доступны в области проекта. Однако некоторые возможности, изначально поддерживаемые на уровне учетной записи через службы Azure OpenAI, Speech, Vision и языковые службы, доступны только на уровне ресурсов в Foundry, а не в рамках проекта. Например, API Переводчика доступен только на уровне ресурса Foundry. Запланируйте структуру развертывания на основе областей API, необходимых для рабочих нагрузок.
Разделение проблем на основе безопасности
Foundry обеспечивает четкое разделение между операциями управления и разработки, чтобы обеспечить безопасные и масштабируемые рабочие нагрузки искусственного интеллекта.
Управление ресурсами верхнего уровня
Операции управления ресурсами верхнего уровня Foundry, такие как настройка безопасности, установка подключения к другим службам Azure и управление развертываниями. Выделенные контейнеры проектов изолируют действия разработки и предоставляют границы для управления доступом, файлов, агентов и оценки.
Управление доступом на основе ролей
Действия RBAC в Azure отражают это разделение обязанностей. Действия уровня управления, такие как создание развертываний и проектов, отличаются от действий плоскости данных, таких как создание агентов, выполнение оценки и отправка файлов. Назначения RBAC можно применять как на уровне ресурса верхнего уровня, так и на уровне отдельного проекта. Назначьте управляемые удостоверения на любом уровне для поддержки безопасной автоматизации и доступа к службам. Для получения дополнительной информации см. управление доступом на основе ролей для Microsoft Foundry.
Распространенные начальные задания для внедрения с минимальными привилегиями включают:
Foundry User для каждого участника-разработчика в области ресурсов Foundry.
Важно
Недавно были переименованы роли RBAC в Foundry. Foundry User, Foundry Owner, Foundry Account Owner и Foundry Project Manager ранее назывались пользователь Azure AI, владелец Azure AI, владелец учетной записи Azure AI и руководитель проекта Azure AI. Пока новое название внедряется, в некоторых местах вы всё ещё можете видеть прежние названия. Идентификаторы ролей и основные разрешения не меняются из-за переименования.
Пользователь Foundry для каждого управляемого удостоверения проекта в области действия ресурса Foundry.
Рекомендации по определению ролей и планированию областей см. в разделе Управление доступом на основе ролей для Microsoft Foundry.
Мониторинг и наблюдаемость
Azure Monitor сегментирует метрики по области. Вы можете просматривать метрики управления и использования на ресурсе верхнего уровня, а метрики, относящиеся к проекту, такие как производительность оценки или действие агента, относятся к отдельным контейнерам проектов.
К ключевым возможностям мониторинга относятся:
- Метрики уровня ресурсов: потребление маркеров, задержка модели, количество запросов и частота ошибок во всех проектах.
- Метрики уровня проекта: результаты оценки, количество вызовов агента и активность операций с файлами.
- Диагностическое ведение журнала: Включите параметры диагностики для маршрутизации журналов в Log Analytics, Хранилище или Центры событий для анализа и сохранения.
Дополнительные сведения см. в обзоре Azure Monitor.
Инфраструктура вычислений
Foundry управляет вычислительной инфраструктурой для размещения моделей, выполнения агента и пакетной обработки. В этом разделе рассматриваются типы развертывания, инфраструктура агента и оценка, интеграция виртуальной сети, изоляция клиентов, элементы управления безопасностью содержимого и региональная доступность.
Типы развертывания модели
Foundry поддерживает несколько типов развертывания для размещения моделей, сгруппированных по области обработки данных: глобальная (межрегиональная), зона данных (в пределах определенной границы) и региональный (один регион). Каждый тип балансирует задержку, пропускную способность и расположение обработки данных по-разному:
| Тип развертывания | Обработка данных | Выставление счетов |
|---|---|---|
| Глобальный стандарт | Межрегионное управление, осуществляемое Azure | Оплата за токен |
| Глобально предоставлено | Межрегионное управление, осуществляемое Azure | Почасовая зарезервированная емкость |
| Глобальная пакетная обработка | Межрегионное управление, осуществляемое Azure | Ценообразование на токены для пакетной обработки |
| Стандарт зоны данных | Внутри границы зоны данных | Оплата за токен |
| Предоставленная зона данных | Внутри границы зоны данных | Почасовая зарезервированная емкость |
| Пакет зоны данных | Внутри границы зоны данных | Ценообразование на токены для пакетной обработки |
| Стандартный | Один регион | Оплата за токен |
| Региональное предоставление | Один регион | Почасовая зарезервированная емкость |
| Разработчик | Любой регион Azure (без гарантии территориальной привязки данных) | Оплата за токен (оценка дообученной модели; срок действия 24 часа; без соглашения об уровне обслуживания) |
Дополнительные сведения о выборе подходящего типа развертывания см. в разделе "Типы развертывания" для моделей Foundry.
Агенты, оценки и пакетная обработка
Агенты, оценки и пакетные задания полностью управляются Microsoft. Рабочие нагрузки агента выполняются в инфраструктуре контейнеров платформы, которая поддерживает интеграцию виртуальной сети для сценариев, изолированных от сети. Оценки вызывают конечные точки модели, сравнивают выходные данные с критериями оценки и хранят результаты в области проекта. Очереди пакетной обработки занимаются постановкой инференс-запросов в очередь для асинхронного выполнения по сниженной цене за токен. Результаты для всех трех типов рабочих нагрузок доступны через портал или пакет SDK.
Интеграция виртуальной сети
При подключении агентов к внешним системам можно изолировать сетевой трафик с помощью внедрения container, где платформа внедряет подсеть в виртуальную сеть, обеспечивая локальное взаимодействие с ресурсами Azure в одной виртуальной сети.
Foundry поддерживает две сетевые модели для исходящей изоляции:
| Модель | Принцип работы | Компромисс |
|---|---|---|
| Управляемая клиентом виртуальная сеть (BYO) | Вы предоставляете виртуальную сеть и выделенную подсеть, делегированную Microsoft.App/environments. Платформа интегрируется в вашу подсеть, обеспечивая локальную связь с вашими частными ресурсами Azure. |
Полный контроль над конфигурацией сети; требует собственного управления сетью. |
| Управляемая виртуальная сеть | Foundry управляет виртуальной сетью от вашего имени. | Упрощенная настройка; ограничивает параметры настройки. Дополнительные сведения см. в разделе "Настройка управляемой виртуальной сети". |
Примечание
Для некоторых сценариев, изолированных от сети, вместо портала требуется пакет SDK или CLI. Например, развертывания с частными конечными точками, которые блокируют весь общий доступ, не настраиваются с помощью пользовательского интерфейса портала. Дополнительные сведения см. в разделе "Настройка приватного канала для Foundry".
Изоляция клиента
Рабочие нагрузки выполняются в логически изолированных средах для каждого ресурса Foundry. Клиентский код не предоставляет общий доступ к контейнерам среды выполнения с другими клиентами.
Безопасность содержимого и ограничители
Foundry интегрирует элементы управления безопасностью содержимого в конвейер вывода модели и агента. Ограничения определяют риски, которые нужно выявлять, точки вмешательства, в которых выполняется проверка, и ответные действия при обнаружении риска. Точки вмешательства включают входные данные пользователя, выходные данные, вызовы инструментов (предварительная версия) и ответы инструментов (предварительная версия). Фильтры содержимого выполняются вместе с запросами модели и могут быть настроены для каждого развертывания. Дополнительные сведения см. в разделе Обзор систем защиты и элементов управления и Уровни серьезности фильтрации контента.
Региональная доступность
Возможности вычислений зависят от Azure региона. Доступность модели, параметры типа развертывания и поддержка функций, например агенты или оценки, могут отличаться в разных регионах. Убедитесь, что целевой регион поддерживает необходимые возможности перед подготовкой. Сведения о текущей доступности см. в разделе "Доступность компонентов" в облачных регионах.
Хранилище данных
Foundry предоставляет гибкие и безопасные возможности хранения данных для поддержки широкого спектра рабочих нагрузок ИИ.
Управляемое хранилище для отправки файлов
В настройке по умолчанию Foundry использует управляемые Microsoft учетные записи хранения, которые логически разделены и поддерживают прямые отправки файлов для выбора вариантов использования, таких как модели OpenAI и агенты, не требуя учетной записи хранения, предоставленной клиентом.
Создание собственного хранилища
При необходимости можно подключить собственные учетные записи служба хранилища Azure. Инструменты литейного производства, такие как анализы и пакетная обработка, могут считывать данные из этих учетных записей и записывать результаты. Дополнительные сведения о поддерживаемых сценариях см. в статье "Перенос собственных ресурсов" со службой агента.
Хранилище состояний агента
- При установке агента basic agent служба агента хранит потоки, сообщения и файлы в управляемом многотенантном хранилище Microsoft с логическим разделением.
- При стандартной настройке агента вы предоставляете собственные Azure ресурсы для всех данных клиента, включая файлы, беседы и векторные хранилища. В этой конфигурации данные изолированы проектом в учетных записях хранения.
Шифрование ключей, управляемых клиентом
По умолчанию службы Azure шифруют данные на хранении и при передаче, используя ключи, управляемые Microsoft, с шифрованием AES с длиной ключа 256 бит, соответствующее стандарту FIPS 140-2. Никаких изменений кода не требуется.
Чтобы вместо этого использовать собственные ключи, подтвердите выполнение этих предварительных условий перед включением ключей, управляемых клиентом, для Foundry:
- Key Vault развертывается в том же регионе Azure, что и ресурс Foundry.
- В Key Vault включены функции мягкого удаления и защиты от удаления.
- Для управляемых удостоверений требуются необходимые разрешения на ключи, например роль Key Vault Crypto User при использовании Azure RBAC.
Используйте собственный Key Vault
По умолчанию Foundry хранит все секреты подключения на основе ключей API в управляемом Azure Key Vault. Если вы предпочитаете самостоятельно управлять секретами, подключите хранилище ключей к ресурсу Foundry. Одно Azure Key Vault подключение управляет всеми секретами подключения на уровне проекта и ресурсов. Дополнительные сведения см. в разделе как настроить подключение Azure Key Vault к Foundry.
Дополнительные сведения о шифровании данных см. в разделе ключей, управляемых клиентом, для шифрования с помощью Foundry.
Размещение данных и соответствие требованиям
Foundry хранит все данные, не находящиеся в активной обработке, в заданной Azure географии. Данные для вывода (запросы и завершения) обрабатываются в зависимости от типа развертывания: глобальные развертывания могут направляться в любой регион Azure, развертывания в зонах данных остаются в пределах зоны США или ЕС, а стандартные или региональные развертывания обрабатываются в своем регионе. Дополнительные сведения см. в разделе "Типы развертывания". Foundry не поддерживает автоматическое переключение при отказе между регионами. Если для организации требуется доступность с несколькими регионами, разверните отдельные ресурсы Foundry в каждом целевом регионе и управляйте синхронизацией данных и маршрутизацией на уровне приложений. Для получения информации о сертификации соответствия см. документацию по соответствию Azure.
Проверка решений по архитектуре
Перед развертыванием проверьте следующее для целевой среды:
- Убедитесь, что необходимые модели и компоненты доступны в регионах развертывания. Дополнительные сведения см. в разделе "Доступность компонентов" в облачных регионах.
- Убедитесь, что назначения ролей правильно ограничены как на уровне ресурса Foundry, так и на уровне проекта. Дополнительные сведения см. в разделе Управление доступом на основе ролей в Microsoft Foundry.
- Проверьте требования к сетевой изоляции и частные пути доступа. Дополнительные сведения см. в разделе "Настройка приватного канала для Foundry".
- Подтвердите требования к шифрованию и управлению секретами, включая ключи, управляемые клиентом, и интеграцию Azure Key Vault. Дополнительные сведения см. в разделе Управляемые ключи для шифрования с помощью Foundry и как настроить подключение Azure Key Vault к Foundry.
- Просмотрите квоты и ограничения целевых ресурсов, включая ограничения развертывания модели и ограничения скорости. Для получения подробной информации см. квоты и ограничения Azure OpenAI и ограничения, квоты и регионы службы агента.
Связанное содержимое
- Развертывание Foundry системы в моей организации
- Контроль доступа на основе ролей для Microsoft Foundry
- Ключи, управляемые клиентом для шифрования с помощью Foundry
- Настройка приватного канала для Foundry
- Использование собственных ресурсов с помощью службы агента
- Обзор Azure Monitor
- Квоты и ограничения Azure OpenAI
- Типы развертывания для моделей Foundry
- Обзор ограничителей и элементов управления
- Доступность функций в облачных регионах