So wählen Sie Full-Stack-Observability für NVIDIA-KI-Fabriken

So wählen Sie Full-Stack-Observability für NVIDIA-KI-Fabriken

Wenn eine KI-Fabrik Tausende von NVIDIA-GPUs, ein InfiniBand-Netzwerk, verteilten Speicher und einen Scheduler umfasst, der rund um die Uhr Batch-Jobs startet, funktioniert ein gewöhnlicher Monitoring-Stack nicht mehr. Sie haben nicht länger ein paar Server mit ein paar Metriken; Sie haben eine Maschine, bei der jede Ebene – Silizium, Firmware, Treiber, Container-Runtime, Framework und Orchestrierung – am selben Tag zum Engpass werden kann. Ein einziges lautloses Verhalten, etwa eine GPU, die beginnt, die Speichertakte zu drosseln, kann einen gesamten Trainingslauf verlangsamen, und keines Ihrer Anwendungs-Dashboards wird es bemerken.

Full-Stack-Observability für NVIDIA-KI-Fabriken ist nicht nur ein größeres Dashboard. Es ist eine bewusste Entscheidung darüber, welche Daten gesammelt werden, wie diese Daten über Ebenen hinweg verknüpft werden und wer darauf reagiert. Dieser Artikel stellt einen praktischen Entscheidungsrahmen vor und zeigt, wie man einen minimalen, GPU-bewussten Referenz-Stack aufsetzt, der das Full-Stack-Muster mit echten Befehlen demonstriert.

Was „Full-Stack“ in einer KI-Fabrik bedeutet

In der traditionellen IT bedeutet Full-Stack-Observability in der Regel, die Anwendung, die Laufzeitumgebung und das Host-Betriebssystem zu verknüpfen. Eine KI-Fabrik fügt mehrere Ebenen hinzu, die leicht übersehen werden:

• Die Silizium-Ebene: GPU-Auslastung, Speicherauslastung, Temperatur, Stromverbrauch, Taktdrosselung und Fehler, die über die NVML- und DCGM-Schnittstellen von NVIDIA sichtbar werden.
• Die System- und Fabric-Ebene: CPU- und Hostspeicher, NVMe-Health, PCIe-Link-Probleme und das InfiniBand- oder RoCE-Fabric, das GPUs untereinander und mit dem Speicher verbindet. Ein degradierter Link kann kollektive Operationen verlangsamen, ohne dass im Anwendungsprotokoll ein einziger Fehler auftaucht.
• Die Runtime- und Orchestrierungsebene: Scheduling-Verhalten von Kubernetes oder Slurm, Container-Health, GPU-Zeitscheiben oder MIG-Isolation sowie die Wartezeiten in der Warteschlange, die jedem Trainingslauf vorausgehen.
• Die Anwendungs- und Framework-Ebene: Wie viele Trainingsschritte pro Sekunde der Workload erreicht, Data-Loader-Durchsatz, Loss-Kurven und der Zustand der Inferenz-Endpunkte von Triton oder einem benutzerdefinierten Serving-Container.

Die zentrale Designentscheidung ist die Korrelation. Unabhängig auf jeder Ebene gesammelte Metriken sind in einer KI-Fabrik nahezu nutzlos, da Produktionsprobleme in der Regel ebenenübergreifend sind. Ein niedriger GPU-Auslastungswert sollte mit den Data-Loader-Metriken verknüpft werden, um festzustellen, ob die GPUs wegen I/O-Mangels idle sind oder weil der Scheduler den Job drosselt. Observability zu wählen bedeutet daher, ein Modell dafür zu wählen, wie Telemetriedaten aus verschiedenen Ebenen verbunden werden.

Anforderungen, die Sie klären sollten, bevor Sie Werkzeuge vergleichen

Bevor Sie ein Produkt bewerten, schreiben Sie die konkreten Anforderungen auf. Vier sind für KI-Fabriken besonders wichtig.

Erstens: Definieren Sie die SLOs, die Ihnen tatsächlich wichtig sind. Beim Training ist das wichtigste Service-Level-Ziel ein stetiger Fortschritt: Die Schritte pro Sekunde müssen über einem Schwellenwert bleiben, und der Job darf nicht still und leise langsamer werden. Bei der Inferenz sind die SLOs Latenz, Durchsatz und die GPU-Auslastung der Serving-Flotte. Observability-Tools sollten danach bewertet werden, ob sie genau diese Signale erzeugen können, nicht nur einen allgemeinen Status „System gesund“.

Zweitens: Entscheiden Sie, ob Sie Echtzeit- oder Post-hoc-Sichtbarkeit benötigen. Eine KI-Fabrik ist eine Umgebung mit hoher Kardinalität: Jeder Job hat seinen eigenen Satz von Containern, GPUs und Prozessen. Sie müssen entscheiden, wie viele Metriken pro Sekunde die Pipeline verkraften kann und wie lange Daten aufbewahrt werden müssen. Volle-Fidelity-Telemetrie in 15-Sekunden-Intervallen über 10.000 GPUs ist etwas ganz anderes als gesampelte Telemetrie, die einen Monat lang aufbewahrt wird.

Drittens: Klären Sie die Frage der Multi-Tenancy. In vielen Fabriken teilen sich mehrere Teams den Cluster. Observability-Daten können unbeabsichtigt Informationen über die Workloads anderer Benutzer preisgeben – zum Beispiel kann die genaue Leistungsaufnahme eines benachbarten Jobs Aktivitätsmuster offenbaren. Wählen Sie einen Stack, der mandantenfähige Dashboards unterstützt und detaillierte Rohmetriken in einem Datenspeicher mit Berechtigungskontrollen aufbewahrt.

Viertens: Bestimmen Sie den operativen Verantwortlichen. Full-Stack-Observability scheitert, wenn niemand den gesamten Stack besitzt. In der Praxis verwalten Cluster-Administratoren die Silizium- und Fabric-Metriken, ML-Plattform-Teams die Framework-Metriken und Anwendungsteams die Trainingskurven. Die ausgewählten Werkzeuge müssen klare Verantwortungsgrenzen definieren und es dennoch einem Team ermöglichen, von einem Loss-Ausschlag direkt zu einer XID-Fehlermeldung zu drillen.

Was instrumentiert werden sollte: Von XID-Fehlern bis zum Datendurchsatz

Ein häufiger Fehler ist, nur die GPU-Auslastung zu instrumentieren. NVIDIAs DCGM bietet eine viel umfangreichere Sammlung von Metriken, einschließlich Speicherauslastung, SM-Belegung, Stromverbrauch, Temperatur, Taktdrosselungsgründe und Fehlerzähler. Unter Linux können Sie die Gesundheit der GPUs auf Ihrem Knoten schnell mit der NVIDIA System Management Interface überprüfen:

# How to Choose Full-Stack Observability for NVIDIA AI Factories
nvidia-smi

# List detailed metrics for every GPU in JSON format
nvidia-smi --query-gpu=index,uuid,temperature.gpu,utilization.gpu,utilization.memory,power.draw,clocks.sm --format=csv

Manuelle Inspektion ist jedoch keine Observability. Wichtig ist die kontinuierliche Erfassung. DCGM unterstützt auch einen strengeren Health-Check-Modus:

# Run DCGM's diagnostic suite once to identify hardware issues
dcgmi diag -r 1

Diese Befehle zeigen, warum die Full-Stack-Frage ebenso sehr mit der Metrik-Taxonomie zu tun hat wie mit den Werkzeugen. Bevor Sie einen Anbieter wählen, legen Sie fest, welche dieser Signale Pflicht sind:

• XID-Fehler und Fehler auf Treiberebene, die Hardware- oder Software-Fehlzustände anzeigen;
• Drosselungsgründe, da eine GPU zu 100 % Rechenauslastung haben kann, aber immer noch auf 70 % ihres Takts gedrosselt ist;
• Fabric-Fehler, qualifiziert als entweder korrigierte (gutartige) oder unkorrigierte (fatale);
• PCIe- und HBM-Lese-/Schreibraten, die eine Sättigung der Speicherbandbreite aufdecken;
• Job-Metadaten auf Auftragsebene vom Scheduler, damit jede Metrik einem Workload-Eigentümer zugeordnet werden kann.

Wenn ein vorgeschlagenes Tool diese Signale nicht in angemessener Granularität erfassen kann, ist es keine Full-Stack-Lösung für eine KI-Fabrik. Der Rest ist Dekoration.

Schritt-für-Schritt-Referenzinstallation

Es gibt keinen einzigen „richtigen“ Observability-Stack, aber es gibt ein bewährtes Open-Source-Muster, das alle oben genannten Prinzipien demonstriert: DCGM-Exporter für GPU-Metriken, Prometheus für das Scraping und die Speicherung und Grafana für Dashboards. Die folgenden Befehle sind eine illustrative Referenzimplementierung. Verwenden Sie einen dedizierten Monitoring-Namespace und pinnen Sie die exakten Versionen der Container-Images in Ihrer eigenen Umgebung fest, da sich Versionen häufig ändern.

Schritt 1 – Starten Sie einen GPU-Metriken-Exporter.

NVIDIA veröffentlicht den DCGM-Exporter als Container-Image. Er liest Telemetriedaten von den Host-Treibern und stellt sie als Prometheus-formatierte Metriken auf Port 9400 bereit. Der folgende Befehl führt ihn auf einem Knoten mit installierten NVIDIA-Treibern aus:

# Start the DCGM-Exporter on the default port
docker run -d --gpus all --rm \
  --name dcgm-exporter \
  -p 9400:9400 \
  nvcr.io/nvidia/k8s/dcgm-exporter:latest

Wenn Sie lieber keinen Container ausführen möchten, ist der DCGM-Exporter auch als eigenständige Binärdatei von der Release-Seite des Projekts auf GitHub erhältlich. Überprüfen Sie, dass er funktioniert, indem Sie seinen Metrik-Endpunkt mit curl abfragen:

# Confirm that GPU metrics are being exported
curl -s http://localhost:9400/metrics | head -20

Sie sollten Metriknamen sehen, die mit DCGM_FI_DEV_ beginnen, wie DCGM_FI_DEV_GPU_UTIL und DCGM_FI_DEV_MEM_COPY_UTIL.

Schritt 2 – Konfigurieren Sie Prometheus, um den Exporter zu scrapen.

Erstellen Sie eine minimale Prometheus-Konfigurationsdatei. Das entscheidende Detail ist das Anhängen eines Labels, das den physischen Knoten identifiziert, sodass die Metriken, wenn ein Job auf einem beliebigen Knoten im Cluster läuft, weiterhin dem richtigen Host zugeordnet werden können:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "dcgm"
    static_configs:
      - targets: ["gpu-node-01:9400", "gpu-node-02:9400"]
        labels:
          cluster: "ai-factory-east"

Dann führen Sie Prometheus aus:

# Run Prometheus with the configuration above
docker run -d --name prometheus \
  -p 9090:9090 \
  -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus:latest

Schritt 3 – Richten Sie ein Grafana-Dashboard ein.

Grafana kann Metriken direkt von der Datenquelle abrufen, daher ist kein Agent-Daemon erforderlich:

# Start Grafana and connect it to the Prometheus instance on port 9090
docker run -d --name grafana \
  -p 3000:3000 \
  -e GF_SECURITY_ADMIN_PASSWORD=admin \
  grafana/grafana:latest

Nachdem die Container laufen, öffnen Sie die Grafana-Weboberfläche auf Port 3000, melden Sie sich an, fügen Sie eine Prometheus-Datenquelle hinzu, die auf http://prometheus:9090 zeigt, und erstellen Sie ein Dashboard mit Panels, die die Metriken DCGM_FI_DEV_GPU_UTIL und DCGM_FI_DEV_POWER_USAGE abfragen.

Nutzungsbeispiele

Der wahre Wert des Stacks zeigt sich, wenn Sie beginnen, ebenenübergreifende Fragen zu stellen. Hier sind drei nützliche Muster.

1. GPU-Drosselung erkennen, die nicht als niedrige Auslastung in Erscheinung tritt.

Eine GPU, die mit 100 % ihres aktuellen Taktslimits läuft, kann dennoch langsamer laufen als ihre deklarierte Maximalrate. Mit Python und der Prometheus-API kann diese Diskrepanz sichtbar gemacht werden. Das folgende Beispiel fragt die SM-Taktbelegung und die Drosselungsgründe ab:

import requests

prometheus_url = "http://localhost:9090/api/v1/query"

queries = {
    "throttle_reasons": 'DCGM_FI_DEV_CLOCK_THROTTLE_REASONS',
    "sm_clock": 'DCGM_FI_DEV_SM_CLOCK',
}

for name, query in queries.items():
    response = requests.get(prometheus_url, params={"query": query}).json()
    for result in response["data"]["result"]:
        print(name, result["metric"].get("gpu_uuid"), result["value"][1])

Eine von Null verschiedene Drosselungs-Grund-Bitmaske verrät, was den Chip einschränkt – thermisch, Leistung oder andere Faktoren – und der SM-Taktwert zeigt, was die GPU dagegen zu tun beschlossen hat.

2. Einen langsamen Job mit der Datenladeebene korrelieren.

Angenommen, Ihr Job läuft mit 300 Schritten pro Sekunde statt der erwarteten 450. Die GPU-Auslastung sieht gut aus, was verdächtig ist. Die folgende Abfrage berechnet die durchschnittliche Speicherkopier-Auslastung jeder GPU über die letzten fünf Minuten, was oft einen Datenladestau aufdeckt:

import requests

prom = "http://localhost:9090/api/v1/query"
query = 'avg_over_time(DCGM_FI_DEV_MEM_COPY_UTIL[5m])'

response = requests.get(prom, params={"query": query}).json()
for result in response["data"]["result"]:
    metric = result["metric"]
    print(metric.get("kubernetes_pod_name"),
          metric.get("gpu_uuid"),
          round(float(result["value"][1]), 2))

Wenn die Speicherkopier-Auslastung hoch ist, während die Rechenauslastung nur moderat ist, verbringt der Workload mit ziemlicher Sicherheit seine Zeit damit, Tensoren zwischen Host und Gerät oder innerhalb des Fabrics zu kopieren, anstatt zu rechnen.

3. Einen einfachen Alarm für lautlose GPU-Fehler erstellen.

Ein zuverlässiger Alarm kann direkt in PromQL geschrieben werden, wobei die dcgm_exporter-Metriken verwendet werden, um eine GPU zu markieren, deren Fehlerzähler im Laufe der Zeit ansteigt:

increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0

Dieser Alarm ist weitaus aussagekräftiger als ein generischer „Node down“-Alarm, da er über die angehängten Labels die GPU und den Job benennt, der sie teilt.

Was standardisiert werden sollte und wer es besitzt

Der schwierigste Teil bei der Auswahl von Full-Stack-Observability ist nicht die Installation, sondern die Standardisierung von Namen und die Organisation der Zuständigkeiten.

Standardisieren Sie zunächst die Beschriftung (Labeling) über alle Metriken hinweg. Wenn Ihr GPU-Exporter, Ihr Kubernetes-Exporter und Ihr Scheduler alle dieselbe Job-Kennung verwenden, können Sie sie zur Abfragezeit verknüpfen. Wählen Sie eine kleine Anzahl von Labels – job_id, cluster, node, gpu_uuid – und erzwingen Sie die Konvention beim Ingest.

Zweitens: Entscheiden Sie, wer die Metriken löscht. Eine KI-Fabrik erzeugt einen kontinuierlichen Telemetriestrom, der während eines aktiven Vorfalls wertvoll und nach Abschluss des Vorfalls größtenteils nutzlos ist. Legen Sie eine Aufbewahrungsrichtlinie pro Stufe fest: hochauflösende Metriken für die letzten Tage, heruntergesamplete Metriken für einige Monate und rohe GPU-Fehlerprotokolle für ein Jahr, um Hardware-Garantiestreitigkeiten zu unterstützen.

Drittens: Denken Sie sorgfältig über den Kompromiss zwischen Erfassungsaufwand und Wiedergabetreue nach. DCGM-Metriken sind günstig zu scrapen, aber die Fabric- und Frame-Ebene-Metriken sind teurer. Instrumentieren Sie die tiefen Ebenen nur auf Knoten, auf denen aktive Trainingsjobs laufen, nicht im gesamten Cluster, und Sie halten Ihren Overhead nahezu bei null.

Fallstricke, die Sie vermeiden sollten

Mehrere häufige Fehler erklären, warum KI-Fabriken am Ende Überwachungs-Stacks haben, die beeindruckend aussehen, aber in der Praxis versagen. Einer ist, GPUs so zu instrumentieren, als wären sie CPUs, was Dashboards erzeugt, die eine durchschnittliche Auslastung zeigen – eine Metrik, die bedeutungslos ist, wenn ein Job vier GPUs weitaus stärker beansprucht als ein anderer. Ein weiterer ist, nur ein einziges Ziel zu scrapen, etwa eine einzelne Prometheus-Instanz, und Daten zu verlieren, wenn das Netz des Rechenzentrums kurz stockt. Ein dritter ist die Wahl eines Tools, das eine schöne Visualisierung bietet, aber Ihre Telemetrie durch einen proprietären Agenten zwingt, den Ihr Sicherheitsteam zu Recht ablehnt zu installieren.

Es gibt auch einen rein administrativen Fallstrick: eine Observability-Plattform zu kaufen und anzunehmen, dass sie das organisatorische Problem löst. Das Tool wird nicht entscheiden, wer einen Fabric-Fehler behebt; das muss das Fabrik-Betriebsteam tun. Wenn Ihre Organisation nicht bereits die Frage „Wem gehört das Netzwerk-Fabric?“ beantworten kann, wird Ihnen kein Produkt helfen, das Netz klar genug zu sehen, um es zu beheben.

Fazit

Full-Stack-Observability für NVIDIA-KI-Fabriken ist eine vielschichtige Entscheidung. Definieren Sie Ihre SLOs, legen Sie fest, welche Telemetrie Sie sich leisten können und wie lange Sie sie speichern müssen, bestätigen Sie, dass das Kandidaten-Tool die NVIDIA-Signale auf niedriger Ebene wie Drosselungsgründe und XID-Fehler sichtbar macht, und korrelieren Sie diese Signale dann mit Scheduler- und Anwendungsdaten. Ein minimaler Referenz-Stack aus DCGM-Exporter, Prometheus und Grafana ist ein zuverlässiger Weg, diese Anforderungen in Ihrer eigenen Umgebung zu testen, bevor Sie sich auf eine breitere Bereitstellung einlassen. Beginnen Sie mit den Metriken auf Siliziumebene, fügen Sie Fabric- und Job-Metadaten hinzu und setzen Sie von Anfang an eine strikte Kennzeichnungskonvention durch. Die GPU-Fabrik arbeitet in einem anderen Tempo als die normale IT-Infrastruktur, und ihre Observability muss so gebaut sein, dass sie mithält.