Wie können Organisationen Compute-, Storage-, Netzwerk-, Strom- und Kühlkapazität prognostizieren?

Organisationen können Compute-, Storage-, Netzwerk-, Strom- und Kühlkapazität prognostizieren, indem sie jede Ressource getrennt messen, verfolgen, wie sich deren Nutzung im Zeitverlauf verändert, geplante Reservierungen und Wachstum einbeziehen und dann identifizieren, welche benötigte Ressource wahrscheinlich zuerst ihr Limit erreicht.

Das Kapazitätsmodell der Quelle wendet immer wieder dieselbe Betriebsregel an: Ein Deployment wird durch das kürzeste Brett begrenzt. Freies Compute nützt nichts, wenn der Strom ausgeschöpft ist, und freier Rack-Platz nichts, wenn die Kühlung am Limit ist. Freie Storage-Kapazität garantiert auch noch keinen ausreichenden Durchsatz. Kapazitätsprognosen müssen deshalb mehrere Dimensionen abdecken.

Warum sollte Kapazität nach Domäne prognostiziert werden?

Infrastruktur-Ressourcen wachsen unterschiedlich schnell und haben unterschiedliche Vorlaufzeiten. Die Compute-Nachfrage kann schnell steigen, während die Storage-Kapazität eher stetig wächst. Netzwerkanforderungen springen, wenn ein neuer Cluster dazukommt. Strom kann zur physischen Grenze werden, und nach einem Strom-Upgrade ist oft die Kühlung das nächste Limit.

Prognostiziert man diese Domänen unabhängig voneinander, ohne sie je zu vergleichen, bleibt die eigentliche Beschränkung für das Deployment leicht unentdeckt. Das Quellenmaterial nennt ausdrücklich die Prognose der Compute- und Storage-Kapazität, die Rack- und Strom-Kapazitätsplanung, Kühlungsbeschränkungen, Netzwerk- und Storage-Engpässe sowie die Vorhersage des Erweiterungstermins. Die Prognose sollte diese Sichten in einem gemeinsamen Planungsmodell zusammenführen.

Was sollte für Compute prognostiziert werden?

Die Compute-Prognose sollte zwischen installierten, verfügbaren, allokierten, gesunden und reservierten Ressourcen unterscheiden. Für KI-Infrastruktur nennen die Quellenbeispiele die Gesamtzahl der Beschleuniger-Karten, verfügbare Karten, den Allokationsgrad, Ressourcenspezifikationen, den Queue-Status, Fragmentierung, Kapazitäts-Alerts und einen prognostizierten Erweiterungstermin.

Eine reine Kartenanzahl reicht nicht. Verschiedene Beschleuniger-Modelle sind nicht unbedingt austauschbar, eine degradierte Karte sollte nicht als voll verfügbar zählen, und eine freie Karte erfüllt vielleicht nicht die Speicher- oder Topologieanforderung eines wartenden Jobs. In heterogenen Umgebungen sollte die Prognose deshalb mit Ressourcenklassen oder Spezifikationen arbeiten.

Für die Allokationsschicht erklärt wie GPU-Resource-Pooling und -Scheduling in Kubernetes und KI-Infrastruktur funktionieren, warum nutzbares Compute von Health, Ressourcenform und Scheduling-Richtlinie abhängt.

Was sollte für Storage prognostiziert werden?

Hängt der Workload von Kapazität und Performance ab, muss die Storage-Prognose beides abbilden. Das Infrastrukturmodell der Quelle überwacht Kapazität, Durchsatz, IOPS und Latenz und umfasst die Vorhersage der Storage-Kapazität.

Ein Storage-System kann reichlich freie Kapazität haben und trotzdem nicht genug Performance für einen weiteren Workload mit hohem Durchsatz. Bei einem einfachen Archiv-Workload zählt meist vor allem die Kapazität, beim KI-Training können Durchsatz und Checkpoint-Performance genauso wichtig sein. Die Prognose muss den Workload also kennen.

Sagen Sie nicht "Storage ist zu 60 Prozent frei" und nehmen dann an, dort sei Platz für jeden künftigen Workload. Fragen Sie, ob sich die Kapazitäts- und Performance-Anforderung des geplanten Workloads abdecken lässt.

Was sollte für Netzwerkkapazität prognostiziert werden?

Die Netzwerk-Prognose sollte die Konnektivität berücksichtigen, die der Workload braucht. Das Quellenmodell umfasst das Trainings-Netzwerk, das Management-Netzwerk, Business- und Inferenz-Einstiegspunkte, dedizierte Standleitungen zwischen Rechenzentren sowie Paketverlust, Latenz, Durchsatz und Port-Kapazität.

Gesamtbandbreite ist nur ein Teil davon. Ein neues Deployment braucht vielleicht bestimmte Hochgeschwindigkeits-Ports, eine bestimmte Topologie, Konnektivität zwischen Rechenzentren, Storage-Netzwerkkapazität oder redundante Pfade. Das Kapazitätsmodell sollte deshalb das Netzwerkprofil des geplanten Workloads oder Servers kennen. Bei einer physischen Erweiterung kann ein Rack mit freiem Platz und Strom trotzdem blockiert sein, weil keine Netzwerk-Ports mehr frei sind.

Was sollte für Strom prognostiziert werden?

Die Strom-Prognose sollte aktuelle Last, Spitzenverhalten, genehmigte Kapazität, Reservierungen und die Redundanzrichtlinie des Standorts berücksichtigen. Das Rack-Kapazitätsmodell der Quelle umfasst A- und B-Zuleitungen, Schaltkreis-Spielraum, PDU- und USV-Daten, Leistungsdichte-Heatmaps und Informationen zu Spitzen- und Schwachlastzeiten.

Der historische Durchschnittsverbrauch allein ist eine schwache Grundlage, weil neue Server-Generationen sich beim Strom ganz anders verhalten können. Das Fallmaterial der Quelle warnt ausdrücklich, dass traditionelle Platzierungsannahmen falsch werden können, wenn neuere Infrastruktur mehr Strom zieht als erwartet. Nutzen Sie gemessenes Produktionsverhalten, um das Geräteprofil mit der Zeit zu verbessern.

Was sollte für Kühlung prognostiziert werden?

Die Kühlungs-Prognose sollte den tatsächlichen Kühlpfad abbilden, der die geplante Ausrüstung versorgt. Das Infrastrukturmodell der Quelle umfasst Luftkühlung, CDU, Verteilungszweig, Vorlauf- und Rücklauftemperatur, Durchfluss, Druckdifferenz, Leckerkennung und Kühlungs-Spielraum.

Bei flüssigkeitsgekühlter Infrastruktur kann die Zweig- oder CDU-Kapazität die Grenze setzen. Bei luftgekühlter Infrastruktur werden oft lokale Rack- oder Zonenbedingungen zum Limit, bevor die Gesamtkühlung der Einrichtung es wird.

Deshalb kommt es auf die physische Zuordnung an. Ein Rack kann elektrisch noch Spielraum haben und trotzdem an einem Kühlungszweig hängen, der kaum noch Kapazität übrig hat. Die Prognose sollte Rack, Ausrüstung und Kühlpfad verknüpfen.

Was ist die Regel des schwächsten Glieds?

Nach der Regel des schwächsten Glieds bestimmt die erste benötigte Ressource, die ihr Limit erreicht, die deploybare Kapazität. Das Quellenmaterial stellt das ausdrücklich für Strom, Kühlung und Schaltkreis-Spielraum fest, und die breitere Quelle zur Kapazitätsplanung nennt auch Netzwerk und Storage als mögliche Ursachen für gebundene (stranded) Kapazität. Die Logik lässt sich also auf das gesamte Deployment-Profil anwenden.

Ein Beispiel: Compute reicht für 20 weitere Nodes, Rack-Platz für 18, Strom für 12, Kühlung für 14, Netzwerk für 10 und Storage-Performance für 16. Deploybar sind damit aktuell 10 Nodes, und das Netzwerk ist der erste Engpass. Erweitert man das Netzwerk auf 20, wird Strom bei 12 zum nächsten Engpass. Diese Aussage hilft deutlich mehr als sechs separate Prozentwerte.

Warum sollte die Prognose ein Deployment-Profil nutzen?

Freie Ressourcen allein sagen nicht, was sich tatsächlich deployen lässt. Ein Deployment-Profil legt die Anforderungen einer geplanten Einheit fest. Bei einem GPU-Node gehören dazu etwa Rack-Höheneinheiten (U), Strombedarf, Kühlmethode, Netzwerk-Ports, Storage-Bedarf, Beschleuniger-Typ und Topologieanforderung.

Die Prognose beantwortet dann die Frage, wie viele weitere Einheiten genau dieses Profils sich unterstützen lassen. Damit kann man mehr anfangen als mit der Frage, wie viel Gesamtkapazität übrig bleibt. Für dasselbe Rack oder denselben Cluster können verschiedene Hardware-Profile unterschiedliche Antworten ergeben.

Wie sollten Reservierungen einbezogen werden?

Reservierte Kapazität gehört getrennt von der allgemein verfügbaren Kapazität ausgewiesen. Das Planungsmodell der Quelle umfasst Reservierung und künftige Erweiterung. Ein Projekt kann Rack-Platz, Strom, Kühlung, Netzwerk-Ports, Compute oder Storage reservieren, und wenn diese Reservierung unsichtbar bleibt, wird dieselbe Kapazität womöglich doppelt zugesagt.

Die Prognose sollte deshalb installierte, allokierte, reservierte, freie und deploybare Kapazität unterscheiden. Das erklärt auch, warum ein Standort unterausgelastet wirken und trotzdem keine neuen Anfragen annehmen kann: Ein Teil der Kapazität ist schon für künftige Arbeit zugesagt.

Wie sollten Wachstumstrends genutzt werden?

Historische Verbrauchstrends sind ein Eingabewert der Prognose. Der Assistent der Quelle bietet Kapazitätsvorhersage und Schwellenwert-Prognosen, und das Website-Material der Quelle behandelt zudem die Prognose von Kapazitätsbedarf und das Erkennen von Trends, die Infrastruktur-Upgrades steuern.

Einen universellen Prognose-Algorithmus definiert das Modell nicht, deshalb sollte die Prognose ihre Methode offenlegen. In einer stabilen Umgebung genügt vielleicht ein einfacher Trend, eine komplexere Umgebung braucht eher szenariobasierte Planung. In beiden Fällen sollte die Prognose das aktuelle Niveau, den jüngsten Trend, reserviertes Wachstum, den Schwellenwert, das Prognosedatum und die Konfidenz oder das Szenario zeigen. Stellen Sie ein Prognosedatum nicht als sicher dar, wenn es von schwankender Nachfrage abhängt.

Warum sollte es mehrere Szenarien geben?

Infrastruktur-Nachfrage verläuft selten entlang einer einzigen festen Linie. Ein praktisches Planungsmodell kann eine Baseline-Nachfrage, erwartetes Wachstum und ein Szenario mit höherem Wachstum enthalten. Das Quellenmaterial zur Kapazitätsplanung stützt Szenariodenken rund um aktuelles, reserviertes, erwartetes und künftiges Wachstum.

Szenarien helfen vor allem beim Timing von Entscheidungen. Erreicht die Baseline das Limit in 12 Monaten, der Fall mit höherem Wachstum aber schon in 6, kann das Team die Vorlaufzeit der Erweiterung gegen beide Möglichkeiten halten. Das ist hilfreicher, als ein Datum als garantiert auszugeben.

Wie sollte die Vorlaufzeit die Kapazitätsprognose beeinflussen?

Kapazitätsplanung sollte das Datum prognostizieren, an dem entschieden werden muss, und nicht nur das Datum, an dem die Kapazität erschöpft ist. Verschiedene Beschränkungen brauchen unterschiedlich lange, bis sie gelöst sind. Netzwerk-Ports sind vielleicht relativ schnell ergänzt, eine Stromerweiterung braucht Engineering-Arbeit, Kühlungs-Upgrades können Bauarbeiten nach sich ziehen, und die Hardware-Beschaffung hat ihre eigene Vorlaufzeit.

Die Prognose sollte also zeigen, wann gehandelt werden muss. Wird Strom in acht Monaten zum limitierenden Faktor und dauert das Upgrade zehn Monate, besteht das Problem schon heute. Die "Vorhersage des Erweiterungstermins" im Quellenmodell nützt nur, wenn sie mit der Zeit verknüpft ist, die man zum Handeln braucht.

Wie kann der laufende Betrieb die Prognose verbessern?

Vergleichen Sie die Planungsannahmen nach dem Deployment mit dem tatsächlichen Verhalten. Das Planungsmaterial der Quelle nutzt Produktionsdaten, um künftige Platzierungs- und Kapazitätsentscheidungen zu verbessern. Vielleicht weicht der tatsächliche Stromverbrauch der Server vom erwarteten ab, der Storage-Durchsatz ist unter gleichzeitiger Last niedriger, die GPU-Auslastung leidet unter Engpässen bei der Datenversorgung, oder ein Kühlungszweig erreicht sein praktisches Limit früher als geplant.

Wenn die Belege es stützen, sollte das Modell seine Ressourcenprofile anpassen. So entsteht eine Feedback-Schleife zwischen Betrieb und Planung.

Wie sollte gebundene Kapazität in der Prognose erscheinen?

Gebundene (stranded) Kapazität sollte getrennt von tatsächlich deploybarer Kapazität ausgewiesen werden. Das Quellenmaterial nennt ausdrücklich Fragmentierung und domänenübergreifende Beschränkungen als Gründe, warum nominale Kapazität schrumpfen kann. Typische Fälle sind freier U-Platz ohne Strom, freie GPUs mit falscher Topologie, freier Storage mit zu wenig Durchsatz oder freier Rack-Strom bei begrenzter Kühlung.

Die Prognose sollte sowohl die nominal freie Ressource als auch die blockierende Beschränkung zeigen.

Für einen detaillierten Ansatz erklärt wie Rechenzentren gebundene Kapazität erkennen, die durch Strom-, Kühlungs-, Netzwerk- oder Storage-Beschränkungen verursacht wird, wie sich der gebundene Anteil klassifizieren lässt.

Was sollte ein Kapazitäts-Dashboard zeigen?

Ein quellenbasiertes Kapazitäts-Dashboard kann Folgendes zeigen:

• Aktuelles Angebot und aktuelle Allokation
• Verfügbare und reservierte Kapazität
• Auslastungstrend
• Schwellenwert-Warnung und prognostiziertes Schwellenwertdatum
• Erste und zweite limitierende Beschränkung
• Vorlaufzeit für Erweiterung
• Gebundene Kapazität

Für KI-Infrastruktur kommen Ressourcenfragmentierung und Kapazität nach Beschleuniger-Spezifikation hinzu. Das Dashboard sollte einen Drill-down nach Standort, Rack, Cluster, Storage-Pool oder Ressourcenklasse erlauben.

Ein Plattformbeispiel, das Kapazitäts-Warnungen, Erweiterungsvorhersage, Fragmentierungserkennung und domänenübergreifende Infrastrukturdaten kombiniert, ist Sensaka.

Wenn ich den Planungsprozess gestalten würde, würde ich aufhören zu fragen "Wann geht uns die Kapazität aus?" und stattdessen fragen "Welche Ressource wird für das nächste geplante Workload-Profil zuerst limitierend, wann passiert das in jedem Wachstumsszenario, und wie lange wird es dauern, diese Beschränkung zu beseitigen?" Mit dieser Prognose kann das Operations-Team tatsächlich arbeiten.