Foundry Local auf Azure Local in nicht verbundenen Umgebungen – Übersicht

Sie können Foundry Local auf Azure Local in getrennten Umgebungen bereitstellen, indem Sie ein Bereitstellungsmodell verwenden, das weitgehend mit verbundenen Szenarien übereinstimmt. Es gibt jedoch mehrere wichtige Unterschiede, wenn die Internetverbindung nicht verfügbar ist.

In diesem Artikel wird erläutert, wie sich getrennte Bereitstellungen von Foundry Local auf Azure Local von verbundenen Bereitstellungen unterscheiden, sodass Sie sichere, Offlinemodellvorgänge planen können.

Important

• Foundry Local ist in der Vorschau verfügbar. Vorschauversionen bieten frühzeitigen Zugriff auf Features, die sich in der aktiven Bereitstellung befinden.
• Features, Ansätze und Prozesse können sich ändern oder über eingeschränkte Funktionen verfügen, bevor die allgemeine Verfügbarkeit (GA) verfügbar ist.

Was sich bei getrennten Bereitstellungen ändert

In getrennten Umgebungen unterscheiden sich erweiterungsverfügbarkeit, Zertifikatverwaltung, Modellartefaktbeschaffung, Telemetrieverhalten, Identitäts- und Zugriffsflüsse von verbundenen Bereitstellungen.

• Verfügbarkeit der Erweiterung: Bevor Sie die Erweiterung „Foundry Local Azure Arc“ installieren können, müssen Sie das Foundry Local-Erweiterungspaket herunterladen und in die nicht verbundene Umgebung importieren.

• Modellkatalogquelle: Foundry Local ruft Modellartefakte aus der lokalen edgeartifacts Container-Registry ab. Modellerweiterungspakete füllen diese Registrierung auf.

• Gebündelte Netzwerkabhängigkeiten: Bei Bereitstellungen ohne Internetverbindung stellt das Foundry Local Erweiterungspaket die Netzwerkabhängigkeiten bereit, die Bereitstellungen mit Internetverbindung aus Onlinequellen beziehen. Während der Installation des Erweiterungspakets werden diese Ressourcen in edgeartifacts importiert, darunter Istio-Control-Plane-Komponenten (istio-base, istiod), benutzerdefinierte Ressourcendefinitionen (CRDs) der Kubernetes Gateway API, CRDs der Gateway API Inference Extension (einschließlich InferencePool) sowie das Container-Image des Endpoint Picker (EPP).

• Bereitstellungszeit-Internetabhängigkeit: Da diese Abhängigkeiten lokal über das Erweiterungspaket importiert werden, erfordert die Bereitstellung keine ausgehende Internetverbindung, um diese Netzwerkkomponenten zu installieren.

• Zertifikatverwaltung: Die azure-cert-manager Erweiterung ist in getrennten Umgebungen nicht verfügbar. Stattdessen müssen Sie Folgendes installieren:

  cert-manager trust-manager

  Diese Helm-Diagramme und Containerimages sind im Erweiterungspaket "Foundry Local" enthalten.

• Telemetry: Telemetrie wird nicht an Microsoft übertragen. Verwenden Sie den Befehl az k8s-extension troubleshoot, um Diagnosedaten für den Support zu sammeln.

• Authentication: Die Authentifizierung verwendet keine öffentlichen Microsoft Entra ID Endpunkte. Stattdessen wird Foundry Local in die Active-Directory-Infrastruktur integriert, die in der nicht verbundenen Azure Local-Umgebung konfiguriert ist.

• Authorization: Autorisierung verwendet standardmäßige Azure RBAC-Rollen für die Findry-Erweiterungsressource:

  • Reader ist für schreibgeschützte Vorgänge vorgesehen, z. B. das Auflisten und Abrufen von Modellkatalogeinträgen.
  • Contributor ist für Schreibvorgänge der Steuerungsebene (z. B. POST, PUT, PATCH, DELETE für Modelle und Bereitstellungen) und für Inferenzvorgänge der Datenebene wie predict und chat/completions erforderlich.

  Dieses Autorisierungsmodell unterscheidet sich von verbundenen Bereitstellungen, die in der Regel Rollen wie Cognitive Services OpenAI-Benutzer verwenden, um Zugriff auf Inference-Endpunkte zu gewähren.

• Paketierung von GPU-Abhängigkeiten: Spiegeln Sie in getrennten autonomen Umgebungen nvidia/k8s-device-plugin:v0.11.0 nach edgeartifacts unter dem Pfad, den das automatisch bereitgestellte DaemonSet erwartet.

• Modellauswertung: Auswertungen werden vollständig auf dem Cluster ausgeführt. Keine Auswertungsdaten verlassen die getrennte Umgebung.

Überlegungen zur Kapazität für getrennte Cluster

Wenn Sie einen isolierten Cluster dimensionieren, berücksichtigen Sie die Basiskapazität sowohl für die Modellbereitstellung als auch für unterstützende Komponenten.

• Planen Sie für vLLM-Bereitstellungen mit mehreren Replikaten einen zusätzlichen EPP-Pod pro ModelDeployment ein.
• Die Standard-EPP-Ressourcen sind etwa 512 MiB-Speicheranforderung und 2 GiB-Speichergrenzwert pro Bereitstellung.
• Die Standardgröße des Workers az aksarc create (Standard_A4_v2) ist in der Regel zu klein für Workflows zum Zwischenspeichern und Bereitstellen von Modellen in Foundry Local.

Konfigurationsdetails finden Sie unter "ModelDeployment" und "Operatorkonfigurationsreferenz". Informationen zu Fehlersymptomen und Anleitungen zur Problembehebung finden Sie unter Problembehandlung für Foundry Local auf Azure Local in nicht verbundenen Umgebungen.

Architekturzusammenfassung

Foundry Local in Azure Local in nicht verbundenen Umgebungen verwendet denselben Arc-aktivierten Kubernetes-Cluster und dieselbe operatorbasierte Steuerungsebene wie verbundene Bereitstellungen. Der Hauptunterschied besteht darin, dass Katalogmodellartefakte und Erweiterungskomponenten über lokal installierte Erweiterungspakete in die getrennte Umgebung importiert werden, anstatt von in internetgekoppelten Registrierungen abgerufen zu werden.

Auf hoher Ebene:

• Der Kubernetes-Ableitungsoperator überwacht den Clusterzustand und gleicht Modellressourcen wie bei verbundenen Bereitstellungen ab.
• Sie definieren Modell - und ModelDeployment-Ressourcen als deklarative Einheiten für Modellmetadaten und Laufzeitabsichten.
• Bei Katalogmodellen ruft ein Cacheauftrag Modellartefakte aus der lokalen EdgeArtifacts-Containerregistrierung ab, anstatt aus dem Foundry-Cloudkatalog abzurufen. Sie füllen diese Registrierung aus, indem Sie Erweiterungspakete für Foundry-Modelle vor der Installation importieren.
• Sie können BYO-Modelle aus einer vom Kunden verwalteten OCI-kompatiblen Containerregistrierung in der getrennten Umgebung abrufen.
• Anwendungen rufen Inference-Endpunkte über interne Dienste oder Gateway-API-Routen auf. Die Authentifizierung ist in Ihre lokale Active Directory Infrastruktur integriert, anstatt sich auf öffentliche Microsoft Entra ID Endpunkte zu verlassen.
• Sie können bereitgestellte Modelle an Testdatensätzen mithilfe von NLP-Metriken oder eines zweiten Modells als Bewertungsinstanz auswerten. Auswertungsdaten verbleiben im Cluster und verlassen die Umgebung nicht.

Das folgende Diagramm zeigt, wie diese Komponenten in einer getrennten Umgebung zusammenarbeiten.

Diagramm, das foundry Local auf Azure Local in einer getrennten Umgebung zeigt. Links erreicht ein Kunde oder Entwickler den Cluster über einen Eingangscontroller für Steuerebene und Rückschlussverkehr. Innerhalb des Arc-fähigen Kubernetes-Clusters enthält die Erweiterung „Foundry Local“ Control-Plane-APIs, benutzerdefinierte Ressourcen, einen Inferenzoperator und Serving-Pods für ONNX-, vLLM-, Predictive- und Chatproxy-Workloads. Oben rechts werden Erweiterungspakete in Azure Local für getrennte Vorgänge importiert und füllen die lokale EdgeArtifacts-Containerregistrierung. Bei Katalogmodellen löst der Ableitungsoperator einen lokalen Cacheauftrag aus, der Modellartefakte von EdgeArtifacts abruft und diese in der lokalen Modellcacheregistrierung speichert, bevor Pods Modelle laden. Ein separater BYO-Pfad ruft Modellartefakte aus einer vom Kunden verwalteten OCI-kompatiblen Registrierung in denselben lokalen Cache und den gleichen Dienstablauf ab. Anwendungen greifen dann über interne Dienste oder Gateway-API-Routen auf Inference-Endpunkte zu, und ein Chatclient kann den generativen Chatdienstpfad aufrufen.

Informationen zum Kontext der verbundenen Architektur finden Sie unter What is Foundry Local on Azure Local?

Nächster Schritt

Vorbereiten der Bereitstellung von Foundry Local auf Azure Local in nicht verbundenen Umgebungen

Verwandte Inhalte

• Übersicht über die Bereitstellung von "Foundry Local" auf Azure Local
• Foundry Local auf Azure Local in einer nicht verbundenen Umgebung bereitstellen
• Bereitstellen Ihres ersten Modells in einer getrennten Umgebung
• Authentifizierung und Autorisierung für Foundry Local auf Azure Local in Umgebungen ohne Netzwerkverbindung konfigurieren
• Problembehandlung für Foundry Local auf Azure Local in Umgebungen ohne Verbindung