Wolkenintelligenz: Azure-Compute für KI und Machine Learning

Inhaltsverzeichnis

Nachdem der erste Blog-Artikel der dreiteiligen Kurzserie Wolkenintelligenz die Möglichkeiten zum Training und zur Inferenz von Machine Learning Modellen innerhalb der der AWS-Cloud beschrieben hat, widmet sich der zweite Teil der Microsoft Azure Cloud.

Von Menschen und Maschinen - Lars Röwekamp

Lars Röwekamp, Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als "CIO New Technologies" mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends, mit Schwerpunkt auf den Bereichen Machine Learning und Cloud Computing. Ein besonderes Augenmerk seiner Arbeit liegt in der Einbettung von ML-basierten Prozessen und Anwendungen in die bestehende IT Landschaft von Unternehmen. Gemeinsam mit seinen Kunden analysiert er die Möglichkeiten – und Grenzen - der Erweiterung und Optimierung von Geschäftsprozessen auf Grundlage ML-basierter Ansätze und setzt diese mit Unterstützung seines Teams bis zur Produktionsreife um. Lars ist Autor mehrerer Fachartikel und -bücher.

Azure-Cloud-Ressourcen für KI und ML

Das Training von Machine Learning Modellen sowie deren produktiver Einsatz zur Vorhersage bringt einige besondere Anforderungen an die zugrundeliegenden Recheninstanzen mit sich. Dabei reicht, wie in Teil 1 der Serie ausführlich beschrieben, eine leistungsstarke GPU allein als Heilsbringer nicht aus. Vielmehr ist eine passende Kombination aus CPUs, GPUs, gemeinsam genutzter, optimal dimensionierter Speicher, 1st- und 2nd-Level Caches und Durchsatz für ein optimales Preis-Leistungs-Verhältnis entscheidend. Die verwendeten Ausdrücke passende Kombination und optimal dimensioniert sind dabei leider keine Blaupausen, sondern wiederum stark abhängig von dem verwendeten ML-Modell und den damit zu verarbeitenden Daten.

Die Azure Cloud bietet eine Vielzahl GPU-basierter VMs an, die speziell auf die Bedürfnisse des Trainierens und Abfragens von ML-Modellen abgestimmt sind:

• NVv4 auf Basis von AMD Radeon Instinct MI25 GPU
• NCas T4-v3 auf Basis von NVIDIAs Tesla T4-GPUs
• NCv3 auf Basis von NVIDIA Tesla V100-GPUs
• ND A100-v4 auf Basis von NVIDIA Ampere A100 GPUs
• NDm A100-v4 auf Basis von NVIDIA Ampere A100 GPUs

Virtuelle Maschinen der NVv4-Serie sind die wohl einfachste und kostengünstigste Option, um GPU-basierte Instanzen im Rahmen von ML-Projekten in der Azure Cloud zu betreiben. Grundlage der NVv4 VMs bilden AMD Radeon Instinct MI25 GPUs mit 16 GByte Speicher.

Mit ihrer anteiligen Nutzung der GPUs von einem Achtel mit lediglich 2 GByte GPU-Speicher bis hin zu einer kompletten GPU mit immerhin 16 GByte GPU-Speicher und den damit einhergehenden 4 bis 32 vCPUs mit 14 GByte bis 112 GByte Speicher eignen sie sich allerdings nur bedingt für das Training bzw. die Inferenz von ML-Modellen. Die Azure Cloud selbst empfiehlt sie daher lediglich für kleine Modelle oder zum kostengünstigen Experimentieren.

Etwas leistungsstärker ist die NC T4 v3-Serie, deren VMs mit bis zu vier NVIDIAs Tesla T4-GPUs mit jeweils 16 GByte Speicher ausgestattet sind. Die T4-GPU basiert auf der NVIDIA Turing-Architektur, die mit 70 Watt energieeffizient daherkommt und somit kosteneffizient skaliert werden kann. NC T4 v3 VMs eignen sich aufgrund ihrer Kombination aus 1 bis 4 T4-GPUs und AMD EPYC2 Rom-Prozessor mit 4 bis 64 vCPUs und entsprechend 28 bis 440 GByte Speicher insbesondere für Inferenz-Workload, also zur Vorhersage durch produktiv gestellte ML-Modelle. Auch das Training überschaubar großer Modelle ist mit ihnen möglich. Für das Training von mittleren oder großen Modellen dagegen ist diese VM-Variante eher nicht geeignet.

Dafür kommt das fast namensgleiche Pendant NCv3 ins Spiel. Die NCv3-Serie ist für rechenintensive Anwendungen mit GPU-Beschleunigung wie CUDA- und OpenCL-basierte Anwendungen oder Simulationen und Deep Learning, ausgelegt. Unter der Haube nutzen die VMs die im Vergleich zur T4-GPU deutlich leistungsstärkeren NVIDIA Tesla V100-GPUs mit 16 GByte, die auf der TensorCore basierenden Volta-Architektur aufsetzt. Dadurch eignet sich diese Serie besonders gut für High-Performance-Computing und rechenintensive ML-Trainings. VMs der Serie NCv3 gibt es wahlweise mit 1, 2 oder 4 GPUs und 6 bis 24 vCPUs. Der zugehörige Speicher variiert entsprechend zwischen 112 und 448 GByte.

Deutlich schneller, aber auch teurer wird es dann noch einmal bei der ND-A100-v4-Serie. Der Fokus liegt auf Scale-up und Scale-out Deep Learning Trainings und beschleunigten HPC-Anwendungen. Derzeit bietet die ND-A100 v4-Serie lediglich eine Ausführung mit acht NVIDIA Ampere A100 40 GByte Tensor Core GPUs und 96 vCPUs mit 900 GByte Speicher. Die VMs der ND A100 v4-Serie können bis zu einer vierstelligen GPU-Anzahl skalieren. Die GPUs innerhalb einer VM kommunizieren mittels 1.6 TByte/s Connection. Azure verbindet die zu einer Skalierungsgruppe gehörenden VMs automatisch miteinander über 200-Gigabit-Mellanox-InfiniBand-HDR-Connection.

Noch einen Schritt weiter geht das neue Flaggschiff der Azure-GPU-VM-Familie, NDm-A100-v4. Ausgerichtet auf High-End-Deep-Learning-Trainings und eng gekoppelte Scale-up- und Scale-out-HPC-Workload, nutzen die VMs zwar mit NVIDIA Ampere die gleiche GPU-Architektur wie ND A100 v4, bieten dabei aber pro GPU mit 80 GByte doppelt so viel Speicher. Und auch die 96 vCPUs verfügen mit 1900 GByte Speicher über deutlich mehr Kapazität als ihre Pendants aus der ND A100 v4-Serie. Die Werte für die Kommunikation innerhalb einer VM bzw. zwischen den verschiedenen VMs eines Clusters sind dagegen identisch.

Genauere Information zu den Kosten der einzelnen VMs finden sich auf der Webseite azureprice.net. Dort stehen neben den unterschiedlichen VM-Varianten und deren Detailinformation auch die Preise der verschiedenen Regionen sowie ein Hinweis auf die jeweils günstigste Region. Letztere Information ist durchaus interessant, da sich die Preise je Region von den Preisen für die Region Germany West Germany (Frankfurt) und Germany North (Berlin) teilweise um mehr als 50 Prozent unterscheiden. Ein kleiner Spoiler vorweg: Die beiden deutschen Rechenzentren zeichnen sich nicht durch günstige Preise aus. Ebenfalls hilfreich ist die Funktion find better, die für eine ausgewählte VM mögliche Alternativen aufzeigt und diese in Preis und Leistung bewertet.

Neben den genannten VM-Serien und-Varianten bietet Azure noch einige weitere, auf GPUs basierenden VM-Varianten an. Die meisten von ihnen sind aber lediglich Vorgängerversionen der bereits beschriebenen VM-Serien oder aber explizit für Graphic Acceleration und Gaming empfohlen und eignen sich nicht wirklich für das Training oder die Inferenz von ML-Modellen.

Die Qual der Wahl

Daraus ergeben sich wichtige und gerade beim ersten ML-Projekt nicht leicht zu beantwortende Fragen: Welche der oben genannten Varianten ist nun aber für das eigene Projekt am Ende am besten geeignet? Wie sieht es mit dem Preis-Leistungs-Verhältnis aus? Und muss man bei dem eigenen Modell und den zugehörigen Daten tatsächlich zwischen VMs für das Training und die Inferenz unterscheiden?

Die Microsoft Azure Cloud versucht eine Orientierungshilfe zu geben und bietet verschiedene, vorgefertigte Rundum-sorglos-Pakete für den Einsatz im Umfeld von KI und ML an. Sie sollen den Aufwand reduzieren, die geeignete Kombination für den eigenen Kontext zu finden und dabei die Ressourcen zu optimieren

Microsoft unterscheidet für die Azure Cloud zunächst zwischen vier grundlegenden Zielumgebungen (Compute Targets), die Kunden direkt aus dem Azure Machine Learning Studio heraus ansprechen und konfigurieren können:

• Compute Instance
• Compute Cluster
• Kubernetes Cluster
• Attached Computes

Jede dieser Varianten adressiert ein eigenes KI-/ML-Szenario mit unterschiedlichen Ansprüchen an Rechenkapazität und kommt mit entsprechenden Kostenprofilen daher. Abbildung 7 zeigt die Auswahl innerhalb der Azure-Machine-Learning-Studios.

Compute Instances

Eine AzureML Compute Instance lässt sich am ehesten mit einer vollständig gemanagten, Cloud-basierten Workstation für Data Scientist und ML-Entwickler vergleichen. Sie ist mit den wichtigsten Tools für diese Zielgruppen vorkonfiguriert und lässt sich somit out of the box für Experimente und Anwendungsentwicklung mit Jupyter Notebooks, JupyterLab, VS Code oder R Studio verwenden. Unter den vorinstallierten Tools finden sich unter anderen Treiber für die unterschiedlichen in der Azure Cloud angebotenen GPUs, um sie mit ihren Optimierungen im im eigenen Code anzusprechen. Detaillierte Informationen dazu, was bereits auf einer Compute Instance vorinstalliert ist und was nicht, finden sich auf der Webseite Was ist eine Azure Machine Learning Compute-Instanz?.

Natürlich lassen sich Compute Instances auch für das Training von ML-Modellen nutzen. Da es sich aber um einzelne Instanzen und nicht um eine Cluster-Umgebung handelt, stößt das Training bei größeren oder datenintensiven Modellen schnell an seine Grenzen.

Compute Instance lassen sich sowohl aus dem Azure ML Studio heraus als auch direkt mit dem Azure-ML-Python-SDK erstellen. Hierbei kann man zwischen CPU- und GPU-basierten VMs sowie unterschiedlichen Ressource-Profilen auswählen. Das hilft, den individuellen Anforderungen an Performance und Speicher gerecht zu werden.

Kosten fallen für eine Compute Instance nur dann an, wenn sie aktiv ist. Um unnötige Kosten zu vermeiden, sollten Kunden daher auf jeden Fall ein Scheduling-Profil angeben. Damit können sie unter anderem die Leerlaufzeit konfigurieren, nach deren Ablauf die Instanz deaktiviert wird. Alternativ lassen sich beliebige Start- und Stopp-Zeiten pro Wochentag konfigurieren.

Natürlich kann die Deaktivierung einer Compute Instance auch manuell erfolgen. Wichtig ist, dass sie nicht aktiv verbleibt, wenn keine Workload ansteht. Das verursacht unnötig Kosten – willkommen in der Cloud!

Compute Clusters

Azure ML Compute Cluster sind die Arbeitstiere der Azure Cloud, wenn es um ML-Workloads geht. Im Gegensatz zu den Compute Instances bieten Compute Cluster zwar nicht die Möglichkeit, Jupyter Notebooks für interaktive ML-Experimente zu starten, sie eignen sich aber optimal für das Training mittlerer bis großer ML-Modelle und die automatisierte Ausführung von MLOps-Pipelines.

Ein Compute Clusters anzulegen, ist denkbar einfach. Man muss lediglich die gewünschte GPU- bzw. CPU-VM auswählen, die Anzahl der minimalen und maximalen Cluster-Nodes angeben und abschließend noch entscheiden, ob es sich bei den Virtual Machines um dedizierte oder Low-Priority-Instanzen handeln soll. Fertig ist der Compute Cluster.

Low-Priority-Instanzen sind deutlich günstiger als dedizierte VMs, aber die Azure Cloud kann sie jederzeit unterbrechen beziehungsweise beenden, wenn die Ressourcen an anderer Stelle benötigt werden. Ein Blick auf die Option lohnt sich, wenn die eigenen ML-Tasks nicht zeitkritisch sind oder außerhalb der typischen Peak-Zeiten laufen können.

Bei der Angabe der Anzahl an aktiven Nodes sollte unbedingt darauf geachtet werden, die minimale Anzahl mit null anzugeben. Nur so kann der Cluster bei fehlender Last offline gehen. Andernfalls würde Microsoft auch die Zeit in Rechnung stellen, die der Cluster mit Warten verbringt.

Die maximale Anzahl der aktiven Nodes eines Compute Clusters hängt sowohl von der gewählten Ressource als auch von der dafür im eigenen Konto zur Verfügung stehenden Quota ab. Auf Anfrage lassen sich diese Werte auf den eigenen Bedarf anpassen. Allerdings sollte man beim Warten auf die Antwort zu der dafür notwendigen Support-Anfrage ein wenig Geduld mitbringen.

Kubernetes-Cluster

Mit der AzureML Zielumgebung namens Kubernetes Clusters können Kunden ML-Modelle in einem durch Azure verwalteten AKS-Cluster oder aber in einem selbstverwalteten Kubernetes-Cluster ausrollen.

Eine Kubernetes-Cluster-Zielumgebung bietet deutlich mehr Freiheiten als der Compute Cluster, die allerdings ihren Preis haben. Da ein Kubernetes Cluster eine allgemeine, skalierbare Compute-Umgebung darstellt, ist sie nicht für die spezifischen Anforderungen im ML-Umfeld vorkonfiguriert. Notwendige Frameworks, Libraries und Treiber muss man somit eigenhändig zur Verfügung stellen.

Ursprünglich war diese Variante vor allem für das Deployment trainierter Modelle und deren Inferenz auf Basis von durch die Azure Cloud verwalteten Containern oder Kubernetes Cluster angedacht. Bis letztes Jahr hieß diese Zielumgebung daher Inference Cluster.

Mittlerweile hat Microsoft allerdings erkannt, dass viele Kunden die angebotene Flexibilität der Zielumgebung auch für das Training von ML-Modellen nutzen wollen. Mit Einführung des Azure Machine Learning CLI/Python SDK v2 erfolgte daher eine Umbenennung in den neutraleren Namen Kuberenets Cluster. In diesem Zuge hat Microsoft die Möglichkeit geschaffen, nicht nur Azure-gemanagte Kubernetes Cluster einzubinden, sondern auch solche, die auf einer beliebigen Infrastruktur aufgebaut sein können – dank der Hybrid- und Multi-Cloud Bridge Azure Arc auch außerhalb der Azure Cloud.

"Bring your own Kubernetes clusters in any infrastructure across multi-cloud, on-premises, and the edge to use as a compute target with Azure Machine Learning workspace”, so das Marketing des Kubernetes Clusters.

Attached Compute

Azure ML Attached Compute ist eine Art Bring-your-own-compute-Ansatz. Die Idee dahinter ist, Compute-Ressourcen aus dem eigenen Azure-Account für das Training von ML-Modellen oder anderen Workloads des AzureML-Workspaces zu nutzen. Das ist sinnvoll, wenn Kunden ihre Ressourcen nicht voll ausnutzen, die somit noch Kapazitäten für das Training zur Verfügung haben.

Zu den möglichen Ressourcen gehören Azure Databrick, Data Lake Analytics, HDInsight, Synapse Spark Pool und Virtual Machines auf Ubuntu Basis.

AzureML Compute Schnellreferenz

Zugegeben, das waren jetzt wirklich sehr viele Informationen und Details. Folgende AzureML Compute Quick Reference fasst daher die Zielumgebungen und deren Einsatzszenarien noch einmal zusammen:

Compute Instance: Virtuelle Workstation für ML-Projekte, die bestens für Experimente mit Juypter Notebooks oder JupyterLab geignet sind. Einsatzszenario: während der Entwicklung und dem Testen von Modellen auf Basis von kleinen bis moderaten Datenmengen.

Compute Cluster: Vollständig durch Azure gemanagte ML-Infrastruktur auf Basis von automatisch skalierbarem Cluster, dessen Anzahl der Worker-Nodes sich der Workload anpasst. Einsatzszenario: Minimierung der Trainingszeit durch Parallelisierung der Workloads. Sie bieten eine kosteneffektiven Weg, um Trainings und Experimenten mit großen Datenmengen durchzuführen.

Kubernetes Cluster (ehemals Inference Cluster): durch Azure gemanagte (AKS) oder selbstverwalteten Kubernetes Cluster. Einsatzszenario: Bereitstellen trainierter Modelle für Inferenz oder Training von Modellen bei größtmöglicher Flexibilität.

Attached Compute: Verwenden von Azure-basierten Compute-Umgebungen wie Azure Databricks oder VMs. Einsatzszenario: Einfaches Deployment von AzureML-Ressourcen in nicht ausgelasteten Zielumgebungen, um die Auslastung provisionierter Azure-Komponenten zu optimieren.

AzureML-Ausblick

Mit dem vorliegenden Blogbeitrag wollte ich zeigen, welche GPU-basierten VMs in der Azure Cloud für das Training und die Inferenz von ML-Modellen herangezogen werden können und in welchem Szenario welcher VM-Typ am sinnvollsten ist. Darüber hinaus bin ich auf die vier verschiedenen Compute-Optionen für ML-Workload eingegangen, welche direkt aus dem Azure Machine Learning Studios heraus oder aber via CLI und SDK angesprochen werden können. Natürlich gehen die ML-Angebote von Azure noch deutlich darüber hinaus. Aber das sind Themen für spätere Blogbeiträge.

In diesem Sinne: "Stay connected!".

(rme)