AI-Infrastruktur-Observability für GPU-Cluster
Erkennen Sie, was jeden Trainings- und Inferenz-Workload ausbremst.
Sensaka führt Daten zu GPU, Container, Knoten, Netzwerk, Storage, Leistungsaufnahme, Temperatur, Flüssigkeitskühlung und Hardware-Zustand in einer Betriebsansicht zusammen. Statt nur festzustellen, dass die GPU-Auslastung niedrig ist, können Infrastrukturteams die Bedingungen rund um den Workload untersuchen und ermitteln, ob der wahrscheinliche Engpass von Compute, Kommunikation, Datenbereitstellung oder dem physischen Knoten ausgeht.
Niedrige GPU-Auslastung ist meist ein Symptom
Eine GPU kann zugewiesen und online sein und dennoch kaum nutzbare Arbeit leisten. Der Workload wartet möglicherweise auf Daten, wird durch Netzwerkkommunikation blockiert, ist von Storage-Latenz betroffen, konkurriert mit einem anderen Container oder läuft auf einem Knoten mit Problemen bei Temperatur, Leistungsaufnahme oder Hardwarezustand.
Wird jeder Bereich in einem separaten Tool überwacht, sehen Teams nur unterschiedliche Ausschnitte desselben Ereignisses. GPU-Administratoren prüfen Beschleuniger-Metriken. Netzwerkteams betrachten RoCE- oder RDMA-Zähler. Storage-Teams prüfen Durchsatz und Latenz. Rechenzentrumsteams schauen auf Leistungsaufnahme und Kühlung. Anwendungsteams untersuchen Workload-Protokolle.
Sensaka bringt diese Signale zusammen, sodass Teams den gesamten Infrastrukturpfad hinter einem AI-Workload untersuchen können.
Eine Zeitachse für Compute, Netzwerk und Storage
Sensaka korreliert Betriebskennzahlen aus den wichtigsten Infrastrukturbereichen, die die Leistung von AI-Workloads beeinflussen.
Transparenz über GPUs und Knoten
Erfassen Sie Beschleunigerauslastung, Speichernutzung, Temperatur, Leistungsaufnahme, ECC-Zustände und Knotenzustand. Betrachten Sie die Leistung nach Beschleunigermodell, Knoten, Cluster oder Projekt, um Unterschiede in den Auslastungsmustern zu erkennen.
Container- und Workload-Kontext
Verknüpfen Sie Workloads und Container mit den GPUs, die sie nutzen. Verfolgen Sie die Beziehung von einer Aufgabe zu ihrem Container, ihrer GPU, ihrem physischen Knoten, Netzwerkport und ihrer Storage-Abhängigkeit. Dieser Kontext hilft, einen stark ausgelasteten Beschleuniger von einem überallozierten oder ungenutzten zu unterscheiden.
Observability für Hochgeschwindigkeitsnetzwerke
Überwachen Sie RoCE- und RDMA-Datenverkehr, einschließlich Paketverlust, Neuübertragung, Latenz und Portzustand. Netzwerkindikatoren lassen sich gemeinsam mit der GPU-Auslastung betrachten, um zu ermitteln, ob Kommunikationswartezeiten das verteilte Training einschränken.
Observability für Storage und Datenbereitstellung
Analysieren Sie Durchsatz, IOPS, Lese- und Schreiblatenz, Ladezeit der Daten und Schreibzeit von Checkpoints. Diese Signale helfen zu ermitteln, ob GPUs warten, weil Trainingsdaten nicht schnell genug bereitgestellt werden.
Zustand der physischen Infrastruktur
Kombinieren Sie In-Band-Leistungsdaten mit Out-of-Band-Hardwareinformationen aus BMC-Schnittstellen. Temperatur, Leistungsaufnahme, ECC und Komponentenzustand bleiben wichtig, wenn die Sicht auf Betriebssystem oder Workload das Problem nicht erklären kann.
Von Metriken zu einem Untersuchungspfad
Sensaka gliedert AI Infrastructure Observability in vier miteinander verbundene Phasen.
Überwachen
Erfassen Sie GPU- und Knotenstatus, Netzwerkverluste und -latenz, Storage-Leistung, Leistungsaufnahme, Temperatur, Flüssigkeitskühlung und Hardware-Zustandsdaten.
Korrelieren
Verknüpfen Sie Aufgaben mit Containern, Container mit GPUs, GPUs mit physischen Knoten und Knoten mit Netzwerk- und Storage-Ressourcen. Ordnen Sie den betroffenen Workload seinem Projekt- und Servicekontext zu.
Diagnostizieren
Vergleichen Sie zeitlich synchronisierte Signale, um Hinweise auf einen Compute-Engpass, ein Netzwerkkommunikationsproblem, einen Storage-Lieferengpass oder einen Hardwarezustand am Knoten zu erkennen. Die Plattform zeigt die zugehörigen Indikatoren und den wahrscheinlichen Auswirkungsbereich, damit Betreiber eine fundierte Entscheidung treffen können.
Optimieren
Wandeln Sie die Diagnose in eine betriebliche Empfehlung um, etwa die Workload-Priorität zu prüfen, GPU-Ressourcen neu zuzuweisen, einen fehlerhaften Knoten zu isolieren, eine betroffene Aufgabe neu zu starten oder eine Warteschlangen- und Scheduling-Richtlinie anzupassen. Die Ausführung kann an eine Freigabe gebunden und für Audits protokolliert werden.
Typische Probleme der AI-Infrastruktur untersuchen
GPU-Auslastung sinkt während des Trainings
Stellen Sie GPU-Auslastung, Netzwerklatenz und Storage-Wartezeit auf derselben Zeitachse dar. Prüfen Sie Datenladezeiten und Kommunikationswartezeiten im betroffenen Zeitraum und ermitteln Sie, welcher Infrastrukturbereich die stärksten Hinweise auf einen Engpass zeigt.
Verteiltes Training verlangsamt sich
Prüfen Sie RoCE- oder RDMA-Verluste, Neuübertragungen und Portzustand gemeinsam mit der GPU-Aktivität. Ermitteln Sie, ob ein Kommunikationsproblem einen einzelnen Knoten, einen einzelnen Port oder einen größeren Teil des Clusters betrifft.
Checkpoint-Schreibvorgänge dauern zu lange
Vergleichen Sie Storage-Durchsatz, IOPS und Schreiblatenz mit dem Checkpoint-Timing des Workloads. Ermitteln Sie, ob die Storage-Leistung den Workload verzögert und Beschleuniger im Leerlauf lässt.
Ein Container nutzt weniger GPU als angefordert
Vergleichen Sie angeforderte Ressourcen im Zeitverlauf mit der tatsächlichen Nutzung. Identifizieren Sie Workloads, die teure Kapazität belegen, aber wenig Aktivität erzeugen, und prüfen Sie, ob Ressourcenvorgaben oder Scheduling-Regeln angepasst werden sollten.
Ein Knoten wirkt in Kubernetes gesund, doch Workloads schlagen fehl
Nutzen Sie Out-of-Band-Hardware-Monitoring, um Temperatur, Leistungsaufnahme, ECC und Komponentenzustände unabhängig vom Betriebssystem zu prüfen. Das liefert eine zusätzliche Beweisquelle, wenn das Monitoring auf Softwareebene den Fehler nicht aufdeckt.
Wie sich DCIM-Anforderungen für AI- und GPU-Cluster verändern
Ein Modell für das Infrastrukturmanagement im Rechenzentrum (DCIM), das für herkömmliche Serverräume gut funktioniert, muss in der Regel erweitert werden, bevor es für einen AI-Cluster nützlich ist. Die Disziplinen sind dieselben. Die Dichte, die Änderungsgeschwindigkeit und die Reichweite eines einzelnen Fehlers sind es nicht.
| Anforderung | Herkömmliche Server | AI- und GPU-Cluster |
|---|---|---|
| Leistung pro Rack | Ein herkömmliches Server-Rack wird um einen stabilen Leistungsrahmen herum geplant, und die Leistung auf Rack-Ebene wird in der Regel periodisch statt kontinuierlich geprüft. | Ein AI-Rack konzentriert weit mehr Leistung auf derselben Stellfläche, und die Leistungsaufnahme ändert sich mit dem jeweiligen Job. Leistungsdaten müssen auf Rack- und Stromkreisebene so häufig erfasst werden, dass die sprunghaften Änderungen sichtbar werden, die Workloads erzeugen. |
| Kühlung | Luftkühlung mit Temperaturüberwachung von Raum und Gang reicht normalerweise aus, und der Raumdurchschnitt ist ein brauchbarer Näherungswert für die Bedingungen am einzelnen Server. | Dicht bestückte Beschleuniger-Racks kombinieren häufig Luft- und Flüssigkeitskühlung. Vorlauf- und Rücklauftemperatur des Kühlmittels, Differenzdruck, Durchflussindikatoren und Leckage-Ereignisse werden zu Betriebsdaten, und ein Raumdurchschnitt kann ein Rack verdecken, das bereits kritisch ist. |
| Kapazitätsmodell | Freie Rack-Einheiten sind in den meisten herkömmlichen Räumen ein brauchbares Maß für die verbleibende Kapazität. | Rack-Einheiten, Leistungsreserve und Kühlkapazität müssen gemeinsam bewertet werden. Ein Rack kann freien Platz bieten, während Leistungs- oder Temperaturbedingungen den Einbau weiterer Geräte verhindern. |
| Asset-Datensatz | Ein Server, sein Standort, seine Konfiguration und sein Garantiestatus beschreiben das Asset ausreichend. | Der Datensatz muss zusätzlich die Beschleuniger im Gehäuse, deren Zustand, den Kühlpfad, der sie versorgt, sowie die Workloads und Mandanten enthalten, die von ihnen abhängen. |
| Fehlersignatur | Komponentenfehler wie eine ausgefallene Festplatte, ein ausgefallenes Netzteil oder ein Speicherfehler bleiben in der Regel auf eine einzelne Maschine begrenzt. | Ein einzelner beeinträchtigter Knoten kann einen verteilten Trainingsjob über viele Knoten hinweg zum Stillstand bringen. Die betriebliche Frage lautet daher, welche Workloads betroffen waren, und nicht, welcher Server ausgefallen ist. |
| Erfassungsintervall | Abfrageintervalle, die für Workloads im stationären Betrieb ausgelegt sind, reichen im Allgemeinen aus. | Die Last steigt und fällt sprunghaft, wenn Jobs starten und enden. Intervalle, die zu einem stationär betriebenen Bestand passen, können genau die kurzzeitigen Temperatur- und Leistungszustände übersehen, auf die es am meisten ankommt. |
| Korrelationsumfang | Facility-Daten und IT-Monitoring liegen häufig bei getrennten Teams und in getrennten Tools, ohne dass daraus große Reibung entsteht. | Compute-, Netzwerk-, Storage- und Facility-Daten müssen auf einer gemeinsamen Zeitachse gelesen werden, weil die Erklärung für eine Leistungsänderung häufig in einem anderen Bereich liegt als das Symptom. |
Praktisch bedeutet das, dass DCIM für einen AI-Cluster keine reine Facility-Disziplin bleiben kann. Rack-Leistung, Kühlzustand und physische Kapazität müssen neben dem Zustand der Beschleuniger und dem Workload-Kontext lesbar sein, und genau das ist das Korrelationsmodell, das diese Seite beschreibt.
Entwickelt für teamübergreifenden Betrieb
Die Leistung von AI-Workloads erstreckt sich über mehrere technische Bereiche. Sensaka bietet GPU-, Plattform-, Netzwerk-, Storage- und Rechenzentrumsteams eine gemeinsame Untersuchungsansicht.
Teams arbeiten mit derselben Ereigniszeitachse, denselben Infrastrukturbeziehungen und demselben Kontext des betroffenen Workloads. Das reduziert doppelte Datenerfassung und hilft jedem Team zu verstehen, wie sein Teil der Infrastruktur zum Gesamtergebnis des Workloads beiträgt.
Alles, was das Korrelationsmodell braucht
Observability, die bis in die physische Ebene reicht
Viele Observability-Plattformen setzen erst oberhalb des Betriebssystems an. Sensaka erweitert die Betriebssicht bis in die physische Ebene der AI-Infrastruktur. Die Plattform kombiniert Software-Metriken mit Multi-Vendor-Daten zu Servern, Beschleunigern, Netzwerk, Storage, Leistungsaufnahme, Kühlung und BMC. Das hilft Betreibern, Hardware- und Facility-Zustände zu erkennen, die für Kubernetes- oder Anwendungs-Monitoring allein unsichtbar bleiben können.
Sensaka verknüpft Observability zudem mit Infrastrukturbeziehungen, Workload-Kontext und Betriebs-Workflows. Ziel ist ein praxisnaher Untersuchungspfad von einem Leistungssymptom zu den betroffenen Ressourcen, der wahrscheinlichen Ursache und der nächsten Maßnahme.
Häufig gestellte Fragen
Was ist AI Infrastructure Observability?
AI Infrastructure Observability ist die Fähigkeit zu verstehen, wie sich GPUs, Container, Knoten, Netzwerke, Storage und der Zustand der physischen Infrastruktur auf AI-Trainings- und Inferenz-Workloads auswirken. Das erfordert eine Korrelation über diese Bereiche hinweg statt isolierter Monitoring-Dashboards.
Was unterscheidet das von GPU-Monitoring?
GPU-Monitoring konzentriert sich vor allem auf Beschleuniger-Metriken. Sensaka ergänzt Workload-Beziehungen, Netzwerkkommunikation, Storage-Datenbereitstellung, den Hardwarezustand der Knoten sowie Kontext zu Leistungsaufnahme, Temperatur und Kühlung, um zu erklären, warum sich die GPU-Leistung ändert.
Überwacht Sensaka RoCE- und RDMA-Netzwerke?
Sensaka unterstützt die Erfassung und Analyse von Netzwerkzuständen wie Verlust, Neuübertragung, Latenz und Portzustand. Die genauen Indikatoren und die Integrationsmethode hängen von den Netzwerkgeräten und Telemetrieschnittstellen in der Kundenumgebung ab.
Kann Sensaka eine Ursache automatisch identifizieren?
Sensaka korreliert Hinweise, hebt wahrscheinliche Engpassbereiche hervor und bietet einen Pfad für Untersuchung und Empfehlung. Die endgültige Diagnose und jede betriebliche Maßnahme sollten den Freigabe-, Change- und Audit-Anforderungen des Kunden folgen.
Lässt sich Hardware auch überwachen, wenn das Betriebssystem nicht verfügbar ist?
Sofern vom Server unterstützt, kann Sensaka Hardwareinformationen über Out-of-Band-Management-Schnittstellen wie Redfish und IPMI erfassen. Dieser Monitoring-Pfad arbeitet unabhängig vom produktiven Betriebssystem.
Für welche Umgebungen eignet sich diese Lösung?
Die Lösung ist für Enterprise-AI-Rechenzentren, öffentliche Rechenzentren, Forschungscluster und Multi-Tenant-GPU-Umgebungen konzipiert, die eine gemeinsame Betriebssicht über Compute, Netzwerk, Storage und physische Infrastruktur benötigen.
Die tatsächliche Ursache von GPU-Leistungsproblemen finden
Von isolierten Auslastungsdiagrammen zu einer vernetzten Sicht auf die Infrastruktur hinter jedem Workload.
Weitere Themen: GPU-Nutzungsmessung, AI-Infrastruktur-CMDB, Flüssigkeitskühlungs-Monitoring