architektura Microsoft Foundry (klasyczna)

Aktualnie wyświetlane:Wersja - Przełączanie do wersji dla nowego portalu Foundry

Uwaga

Linki w tym artykule mogą otwierać zawartość w nowej dokumentacji Microsoft Foundry, w przeciwieństwie do dokumentacji Foundry (klasycznej), którą przeglądasz obecnie.

Microsoft Foundry organizuje obciążenia sztucznej inteligencji za pomocą architektury warstwowej: zasób Foundry do zarządzania, projekty do izolacji programistycznej i połączone usługi Azure na potrzeby zarządzania magazynowaniem, wyszukiwaniem i zarządzaniem sekretami.

Ten artykuł dostarcza zespołom operacji IT i bezpieczeństwa szczegółowych informacji na temat zasobu Foundry i bazowej architektury usługi Azure, jej składników oraz relacji z innymi typami zasobów Azure. Skorzystaj z tych informacji, aby dowiedzieć się, jak dostosować wdrożenie rozwiązania Foundry do wymagań organizacji. Aby uzyskać więcej informacji na temat wdrażania platformy Foundry w organizacji, zobacz Wdrażanie usługi Foundry.

Kiedy należy używać tej architektury

Rozważ model zasobów Foundry, gdy scenariusz obejmuje:

  • Konfiguracja po raz pierwszy: uruchamiasz nowy projekt sztucznej inteligencji i chcesz utworzyć pojedynczy zasób, który łączy dostęp do modelu, hosting agenta i narzędzia do oceny.
  • Dostęp do wielu zespołów: wiele zespołów potrzebuje izolowanych projektów z udostępnionymi wdrożeniami modeli i scentralizowanym ładem.
  • Projekt oparty na zgodności: Twoja organizacja wymaga prywatnej sieci, szyfrowania zarządzanego przez klienta lub Azure kontroli dostępu opartej na rolach na poziomie zasobów i projektu.
  • Azure OpenAI migracja: Przechodzisz z autonomicznego zasobu Azure OpenAI i chcesz zachować istniejące zasady i kontrolę dostępu opartą na rolach, jednocześnie dodając możliwości agenta i oceny.

W przypadku eksploracji przez jednego dewelopera zasób Foundry z jednym projektem jest zalecanym ustawieniem domyślnym. Jeśli obciążenie wymaga tylko ukończeń OpenAI Azure bez hostowania lub oceny agenta, może wystarczyć samodzielny zasób OpenAI Azure.

Typy zasobów i dostawcy usług sztucznej inteligencji w Azure

W ramach rodziny produktów Azure AI można użyć tych dostawców zasobów Azure, które obsługują potrzeby użytkowników na różnych poziomach stosu technologicznego.

Dostawca zasobów Cel Obsługiwane usługi
Microsoft. CognitiveServices Obsługuje tworzenie aplikacji Agentic i GenAI oraz dostosowywanie wstępnie utworzonych modeli. Odlewnia; Azure OpenAI; Azure Speech w narzędziach Foundry; Azure Language w narzędziach Foundry; Azure Vision w narzędziach Foundry
Microsoft. Szukaj Obsługuje wydobywanie wiedzy z danych Wyszukiwanie AI platformy Azure

W przypadku większości scenariuszy rozwoju sztucznej inteligencji, w tym tworzenia agentów, wdrażania modeli i w ramach przepływów pracy związanych z oceną, zasób Foundry jest zalecanym punktem wyjścia. Zasoby Foundry dzielą przestrzeń nazw dostawcy Microsoft.CognitiveServices z usługami takimi jak Azure OpenAI, Speech, Vision i Language. Ta przestrzeń nazw wspólnego dostawcy pomaga wyrównać interfejsy API zarządzania, wzorce kontroli dostępu, funkcje sieciowe i zachowania zasad w powiązanych zasobach sztucznej inteligencji.

Skorzystaj z poniższej tabeli, aby zidentyfikować typ zasobu zgodny z obciążeniem. Przedstawia określone typy zasobów i możliwości w dostawcy Microsoft.CognitiveServices.

Typ zasobu Dostawca zasobów i typ Rodzaj Obsługiwane możliwości
Microsoft Foundry Microsoft.CognitiveServices/accounts AIServices Agenci, oceny, Azure OpenAI, mowa, przetwarzanie obrazów, język i interpretacja zawartości
Projekt Foundry Microsoft.CognitiveServices/accounts/projects AIServices Podzasób do powyższego
Azure Speech w narzędziach Foundry Microsoft.CognitiveServices/accounts Speech Mowa
Azure Language in Foundry Tools (Język Azure w narzędziach Foundry) Microsoft.CognitiveServices/accounts Language Język
Azure Vision w narzędziach Foundry Microsoft.CognitiveServices/accounts Vision Wizja

Typy zasobów w tych samych przestrzeniach nazw dostawcy współdzielą te same interfejsy API zarządzania i używają podobnych akcji kontroli dostępu opartej na rolach w Azure (Azure RBAC), konfiguracji sieci oraz aliasów dla konfiguracji zasad Azure Policy. Jeśli przechodzisz z Azure OpenAI do Foundry, Twoje istniejące niestandardowe zasady Azure i akcje RBAC Azure będą nadal stosowane.

Hierarchia zasobów programu Foundry

Na poniższym diagramie przedstawiono zasób Foundry z wdrożeniami modelu, ustawieniami zabezpieczeń, połączeniami i dwoma projektami. Połączone usługi Azure, takie jak Storage, Key Vault i Wyszukiwanie AI platformy Azure, są oddzielnymi zasobami Azure w ramach własnych granic zarządzania.

Diagram przedstawiający hierarchię zasobów Foundry z granicą ładu zawierającą wdrożenia modelu, ustawienia zabezpieczeń, połączenia i dwa projekty. Połączone zasoby, takie jak Storage, Key Vault i Wyszukiwanie AI platformy Azure, są wyświetlane jako oddzielne granice ładu.

Ważne

Połączone zasoby, takie jak zasoby Storage, Key Vault i Wyszukiwanie AI platformy Azure, są niezależnymi zasobami Azure z własnymi granicami zarządzania. Zarządzasz ustawieniami sieci, zasadami dostępu i zgodności dla tych zasobów oddzielnie od zasobu foundry.

Użyj tego modelu podczas planowania architektury i granic dostępu:

  • Foundry resource: zasób najwyższego poziomu Azure, w którym zarządzasz ustawieniami zarządzania, takimi jak sieci, zabezpieczeń i wdrażania modeli.
  • Project: Granica programowania wewnątrz zasobu foundry, w którym zespoły tworzą i oceniają przypadki użycia. Projekty umożliwiają zespołom tworzenie prototypów w wstępnie skonfigurowanym środowisku, ponowne użycie istniejących wdrożeń modelu i połączeń bez powtarzanej konfiguracji IT.
  • Zasoby projektu: Pliki, agenty, oceny i powiązane artefakty ograniczone do projektu.
  • Łączone zasoby: usługi Azure, takie jak Storage, Key Vault i Wyszukiwanie AI platformy Azure, do których odwołuje się zasób Foundry za pośrednictwem połączeń. Te zasoby mają oddzielne granice zarządzania, w związku z czym zarządzasz ich zasadami sieciowymi i dostępu niezależnie.

Dzięki temu zespoły IT mogą stosować scentralizowane mechanizmy kontroli na poziomie zasobów, podczas gdy zespoły programistyczne pracują w granicach na poziomie projektu.

Uwaga

Większość nowych interfejsów API jest dostępna w zakresie projektu. Jednak niektóre funkcje pierwotnie obsługiwane na poziomie konta za pośrednictwem usług Azure OpenAI, Speech, Vision i Language są dostępne tylko na poziomie zasobu Foundry, a nie w zakresie projektu. Na przykład interfejs API usługi Translator jest dostępny tylko z poziomu zasobu Foundry. Zaplanuj strukturę wdrażania na podstawie zakresów interfejsu API, których wymagają obciążenia.

Rozdzielenie obowiązków kierowane przez aspekty bezpieczeństwa

Foundry wymusza wyraźną separację między operacjami zarządzania i rozwoju w celu zapewnienia bezpiecznych i skalowalnych obciążeń AI.

Nadzór nad zasobami najwyższego poziomu

Zarządzanie zasobami najwyższego poziomu w Foundry obejmuje takie operacje jak konfigurowanie zabezpieczeń, ustanawianie łączności z innymi usługami Azure oraz zarządzanie wdrożeniami. Dedykowane kontenery projektów izolują działania programistyczne i zapewniają granice dla kontroli dostępu, plików, agentów i ocen.

Kontrola dostępu oparta na rolach

Działania RBAC w Azure odzwierciedlają tę separację obowiązków. Akcje płaszczyzny sterowania, takie jak tworzenie wdrożeń i projektów, różnią się od akcji płaszczyzny danych, takich jak agenci kompilacji, uruchamianie ocen i przekazywanie plików. Przypisania RBAC można określić zarówno na poziomie zasobów najwyższego poziomu, jak i na poziomie poszczególnych projektów. Przypisz tożsamości zarządzane na dowolnym poziomie zakresu, aby obsługiwać bezpieczny dostęp do usług i automatyzacji. Aby uzyskać więcej informacji, zobacz Role-based access control for Microsoft Foundry.

Przykładowe przypisania początkowe dla wdrażania z minimalnymi uprawnieniami obejmują:

  • Foundry User dla tożsamości każdego dewelopera w zakresie zasobu Foundry.

    Ważne

    Niedawno zmieniono nazwy ról RBAC w usłudze Foundry. Użytkownik Foundry, właściciel Foundry, właściciel konta Foundry i menedżer projektu Foundry były wcześniej nazywane odpowiednio użytkownikiem Azure AI, właścicielem Azure AI, właścicielem konta Azure AI i menedżerem projektu Azure AI. Poprzednie nazwy mogą być nadal widoczne w niektórych miejscach, podczas gdy zmiana nazwy jest wdrażana. Identyfikatory ról i uprawnienia podstawowe są niezmienione przez zmianę nazwy.

  • Użytkownik usługi Foundry dla każdej tożsamości zarządzanej projektu w zakresie zasobów usługi Foundry.

Aby uzyskać wskazówki dotyczące planowania definicji ról i zakresu, zobacz Kontrola dostępu oparta na rolach dla Microsoft Foundry.

Monitorowanie i obserwowanie

Azure Monitor segmentuje metryki według zakresu. Metryki zarządzania i użycia można wyświetlać w zasobie najwyższego poziomu, podczas gdy metryki specyficzne dla projektu, takie jak wydajność oceny lub działanie agenta, są ograniczone do poszczególnych kontenerów projektów.

Najważniejsze możliwości monitorowania obejmują:

  • Metryki na poziomie zasobu: Użycie tokenu, opóźnienie modelu, liczba żądań i współczynniki błędów we wszystkich projektach.
  • Project-level metrics: Wyniki oceny przebiegu, liczby wywołań agentów i aktywność operacji na plikach.
  • Logowanie diagnostyczne: Włącz ustawienia diagnostyczne, aby kierować dzienniki do Log Analytics, magazynu lub usługi Event Hubs na potrzeby analizy i przechowywania.

Aby uzyskać więcej informacji, zobacz Azure Monitor overview.

Infrastruktura obliczeniowa

Foundry zarządza infrastrukturą obliczeniową na potrzeby hostowania modeli, uruchamiania agentów i przetwarzania wsadowego.

Typy wdrożeń modelu

Standardowe wdrożenie w zasobach platformy Foundry zapewnia architekturę przeznaczoną do hostingu modeli.

Zarządzane obliczenia dla agentów i ocen

Aplikacje monitorujące, ewaluacje i zadania usługi Batch są uruchamiane jako zarządzane obliczenia kontenerowe, w pełni zarządzane przez Microsoft. Oceny wywołują punkty końcowe modelu i porównują dane wyjściowe z kryteriami klasyfikacji. Narzędzie Foundry przechowuje wyniki w zakresie projektu, dostępne za pośrednictwem portalu lub zestawu SDK.

Integracja z siecią wirtualną

Gdy agenci łączą się z systemami zewnętrznymi, można odizolować ruch sieciowy za pomocą iniekcji kontenerowej, gdzie platforma wprowadza podsieć do sieci wirtualnej, umożliwiając lokalną komunikację z zasobami Azure w tej samej sieci wirtualnej.

Rozwiązanie Foundry obsługuje dwa modele sieci na potrzeby izolacji ruchu wychodzącego:

Model Jak to działa Kompromis
Sieć wirtualna zarządzana przez klienta (BYO) Podaj sieć VNet i dedykowaną podsieć delegowaną do Microsoft.App/environments. Platforma wstrzykuje się do Twojej podsieci, umożliwiając lokalną komunikację z Twoimi prywatnymi zasobami Azure. Pełna kontrola nad konfiguracją sieci; wymaga własnego zarządzania siecią.
Zarządzana sieć wirtualna (VM) (wersja próbna) Usługa Foundry zarządza siecią wirtualną w Twoim imieniu. Prostsza konfiguracja; ogranicza opcje dostosowywania. Aby uzyskać szczegółowe informacje, zobacz Konfigurowanie zarządzanej sieci wirtualnej.

Uwaga

Niektóre scenariusze izolowane w sieci wymagają zestawu SDK lub interfejsu wiersza polecenia zamiast portalu. Na przykład wdrożenia z prywatnymi punktami końcowymi, które blokują cały dostęp publiczny, nie są konfigurowalne za pośrednictwem interfejsu użytkownika portalu. Aby uzyskać szczegółowe informacje, zobacz How to configure a private link for Foundry (Jak skonfigurować link prywatny dla rozwiązania Foundry).

Izolacja najemcy

Zarządzane przez Microsoft obliczenia działają w logicznie izolowanych środowiskach dla każdego projektu. Kod klienta nie udostępnia kontenerów środowiska uruchomieniowego innym dzierżawcom.

Bezpieczeństwo zawartości i bariery ochronne

Narzędzie Foundry integruje mechanizmy kontroli bezpieczeństwa zawartości z potokiem wnioskowania modelu i agenta. Zabezpieczenia definiują zagrożenia do wykrywania, punkty interwencji do przeszukiwania (dane wejściowe użytkownika, dane wyjściowe, wywołania narzędzi (wersja przeglądowa) oraz odpowiedzi narzędzi (wersja przeglądowa)) i działania w odpowiedzi po wykryciu ryzyka. Filtry zawartości działają w linii z żądaniami modelu i można je konfigurować na podstawie wdrożenia. Aby uzyskać więcej informacji, sprawdź Omówienie reguł i kontroli oraz Stopnie filtrowania zawartości.

Skalowanie

Zarządzane obliczenia dla agentów i ocen są skalowane automatycznie na podstawie zapotrzebowania na obciążenia. Model hostingu skaluje się na podstawie konfiguracji wdrożenia.

Dostępność regionalna

Możliwości obliczeniowe różnią się w zależności od regionu Azure. Dostępność modelu, opcje typu wdrożenia i obsługa funkcji, takie jak Agenci lub oceny, mogą się różnić w różnych regionach. Przed aprowizowaniem upewnij się, że region docelowy obsługuje wymagane możliwości. Aby uzyskać bieżącą dostępność, zobacz Dostępność funkcji w różnych regionach chmury.

Magazyn danych

Platforma Foundry udostępnia elastyczne i bezpieczne opcje przechowywania danych, aby obsługiwać szeroką gamę obciążeń sztucznej inteligencji.

Zarządzana pamięć na potrzeby przesyłania plików

W domyślnej konfiguracji program Foundry używa kont magazynu zarządzanych Microsoft, które są logicznie oddzielone i obsługują bezpośrednie przekazywanie plików do wybranych przypadków użycia, takich jak modele OpenAI i agenci, bez konieczności posiadania konta magazynu dostarczonego przez klienta.

Przynieś własną przestrzeń dyskową

Opcjonalnie możesz połączyć własne konta Azure Storage. Narzędzia odlewnicze, takie jak oceny i przetwarzanie wsadowe mogą odczytywać dane wejściowe z tych kont oraz zapisywać do nich dane wyjściowe. Aby uzyskać szczegółowe informacje na temat obsługiwanych scenariuszy, zobacz Używanie własnych zasobów za pomocą usługi Agent.

Przechowywanie stanu agenta

  • Po skonfigurowaniu podstawowego agenta, usługa agenta przechowuje wątki, komunikaty i pliki w wielodostępnym magazynie zarządzanym przez Microsoft, zapewniającym logiczną separację.
  • W przypadku konfiguracji standardowego agenta dostarczasz własne zasoby Azure dla wszystkich danych klientów, w tym plików, konwersacji i magazynów wektorowych. W tej konfiguracji dane są izolowane według projektu w ramach kont magazynowych.

Szyfrowanie kluczy zarządzanych przez klienta

Domyślnie usługi Azure szyfrują dane w spoczynku i podczas przesyłania przy użyciu kluczy zarządzanych przez Microsoft z 256-bitowym szyfrowaniem AES zgodnym z FIPS 140-2. Nie są wymagane żadne zmiany kodu.

Aby zamiast tego użyć własnych kluczy, przed włączeniem kluczy zarządzanych przez klienta dla rozwiązania Foundry potwierdź następujące wymagania wstępne:

  • Key Vault jest wdrażany w tym samym regionie Azure co zasób usługi Foundry.
  • Ochrona przed miękkim usuwaniem i przed oczyszczeniem jest włączona w Key Vault.
  • Tożsamości zarządzane mają wymagane uprawnienia związane z kluczami, takie jak Key Vault Crypto User podczas korzystania z Azure RBAC.

Przynieś własne Key Vault

Domyślnie Foundry przechowuje wszystkie tajne dane połączeń oparte na kluczach interfejsu API w zarządzanej usłudze Azure Key Vault. Jeśli wolisz samodzielnie zarządzać sekretami, połącz magazyn kluczy z zasobem Foundry. Jedno połączenie Azure Key Vault zarządza wszystkimi tajemnicami połączenia na poziomie projektowym i zasobowym. Aby uzyskać więcej informacji, zobacz Jak skonfigurować połączenie Azure Key Vault z usługą Foundry.

Aby dowiedzieć się więcej na temat szyfrowania danych, zobacz Klucze zarządzane przez klienta na potrzeby szyfrowania za pomocą rozwiązania Foundry.

Miejsce przechowywania i zgodność danych

Foundry przechowuje wszystkie dane w spoczynku w wyznaczonej lokalizacji geograficznej Azure. Inferencja danych (żądań i wyników) jest przetwarzana zgodnie z typem wdrożenia: wdrożenia globalne mogą być kierowane do dowolnego regionu Azure, wdrożenia stref danych pozostają w strefach USA lub UE, a standardowe lub regionalne wdrożenia są przetwarzane w regionie wdrożenia. Aby uzyskać szczegółowe informacje, zobacz Typy wdrożeń. Foundry nie obsługuje automatycznego przełączania awaryjnego między regionami. Jeśli twoja organizacja wymaga dostępności w wielu regionach, wdróż oddzielne zasoby usługi Foundry w każdym regionie docelowym i zarządzaj synchronizacją danych i routingiem w warstwie aplikacji. Aby uzyskać szczegółowe informacje na temat certyfikacji zgodności, zobacz dokumentację dotyczącą zgodności Azure.

Weryfikowanie decyzji dotyczących architektury

Przed wdrożeniem zweryfikuj następujące elementy dla środowiska docelowego:

Powiązana zawartość

  • Ostatnia aktualizacja o