Ein Server kann auf Daten warten, während seine Lüfter weiterlaufen. Ein Speichersystem kann freie Kapazität haben und trotzdem einzelne Anfragen ausbremsen. Diese Situationen erklären, warum die Energiefrage eines Rechenzentrums schon bei der Software beginnt. Zusätzliche Hardware beseitigt nicht automatisch die Ursachen dafür, dass vorhandene Geräte schlecht zusammenarbeiten.
Ein heute veröffentlichtes MIT-Porträt von Christina Delimitrou beschreibt ihre Forschung an effizienteren Cloud-Systemen. Im Mittelpunkt stehen unter anderem die Zuteilung gemeinsamer Ressourcen und die Anpassung von Software an vorhandene Hardware. Dahinter liegt eine praktische Frage: Wie viel nützliche Arbeit lässt sich aus einer Anlage holen, bevor ein Betreiber sie vergrößern muss?
Freie Rechenleistung kann am falschen Ort liegen
Eine moderne Anwendung besteht oft aus mehreren Diensten. Ein Dienst nimmt die Anfrage entgegen, ein anderer liest Daten, ein weiterer führt eine Berechnung aus. Für die Person am Bildschirm zählt die gesamte Kette. Wenn ein Teil lange braucht, wird die Antwort langsam, auch wenn anderswo Prozessoren wenig zu tun haben.
Das ist der Unterschied zwischen durchschnittlicher Auslastung und nutzbarer Leistung. Eine Anlage mit vielen freien Ressourcen kann an einem eng begrenzten Teil trotzdem überlastet sein. Zusätzliche Prozessoren im falschen Abschnitt helfen dann wenig. Um sinnvoll zu verteilen, muss die Steuerung verstehen, welche Dienste voneinander abhängen und wo sich Anfragen aufstauen.
Ein vereinfachtes Beispiel macht den Engpass sichtbar. Eine Anwendung kann rechnerisch viele Anfragen pro Sekunde bearbeiten, muss dafür aber jedes Mal Daten von einem ausgelasteten Speicherdienst lesen. Die Berechnung wartet auf diese Daten. Wird nur die Rechenstufe erweitert, steigt ihre theoretische Kapazität, während die langsamere Stufe weiterhin den Ablauf begrenzt. Die entscheidende Änderung kann eine bessere Datenverteilung sein.
Vorhersagen helfen, bevor Nutzer die Verzögerung bemerken
Auf ihrer Forschungsseite beschreibt Delimitrou Arbeiten an Leistung, Vorhersagbarkeit und Ressourceneffizienz von Cloud-Systemen. Werkzeuge wie Seer und Sage untersuchen Probleme verteilter Anwendungen mithilfe maschinellen Lernens. Der Reiz liegt darin, viele Betriebssignale gemeinsam auszuwerten, statt für jede mögliche Störung eine isolierte Regel zu formulieren.
Für einen Administrator ist ein bloßer Alarm allerdings nur begrenzt hilfreich. Er braucht eine handhabbare Erklärung: Welche Ressource ist betroffen? Was verändert sich bei einer Umverteilung? Und welche anderen Dienste hängen davon ab? Eine Steuerung, die ihren Vorschlag nachvollziehbar macht, unterstützt auch die spätere Gestaltung des Systems. So kann aus einer kurzfristigen Korrektur eine Erkenntnis über den Aufbau der Anwendung entstehen.
Die Schwierigkeit ist die Rückkopplung. Sobald Ressourcen verschoben werden, ändert sich das Verhalten, auf dem die Vorhersage beruhte. Eine erfolgreiche Steuerung muss daher ihre eigene Wirkung beobachten. Sie sollte nicht nur auf die letzte Auslastungszahl reagieren, sondern auch prüfen, ob Antworten schneller werden und ob neue Warteschlangen an anderer Stelle entstehen.
Ein SSD-Pool zeigt den Mechanismus im Kleinen
Ein eigenständiges MIT-Forschungsbeispiel stammt von Gohar Chaudhry, Adam Belay und Kollegen. Ihr im April vorgestelltes System Sandook verteilt Arbeit zwischen gemeinsam genutzten SSDs. Solche Laufwerke speichern Daten und liefern sie an Anwendungen. Im Pool stehen sie mehreren Aufgaben zur Verfügung, verhalten sich aber nicht jederzeit gleich.
Sandook berücksichtigt Unterschiede zwischen den Geräten, Konflikte zwischen Lesen und Schreiben sowie interne Aufräumarbeiten. Ein globaler Controller plant die Verteilung, schnellere lokale Controller reagieren auf kurzfristige Veränderungen. Wenn ein Laufwerk vorübergehend langsamer wird, können Aufgaben auf andere Geräte gelenkt werden. Diese Kombination verbindet den Überblick über den Pool mit der Reaktion nahe am betroffenen Gerät.
Im Versuch mit zehn SSDs und mehreren Anwendungstypen meldeten die Forscher gegenüber statischen Methoden zwischen 12 und 94 Prozent höheren Durchsatz. Die Bandbreite gehört zum Ergebnis: Verschiedene Aufgaben profitieren unterschiedlich stark. Sandook zeigt damit konkret, wie Software vorhandene Hardware besser nutzen kann. Die Studie berichtet an dieser Stelle Durchsatzgewinne; eine Stromersparnis in derselben Prozenthöhe wäre eine andere Messgröße.
Mehr Arbeit pro Sekunde und weniger Energie pro Aufgabe
Durchsatz beschreibt, wie viel Arbeit in einer Zeitspanne erledigt wird. Energie beschreibt den über die Zeit aufsummierten Verbrauch. Beide Größen hängen zusammen, sind aber nicht austauschbar. Ein System kann mehr Aufträge pro Sekunde erledigen und dabei auch mehr elektrische Leistung aufnehmen. Ob es pro Auftrag sparsamer wird, ergibt sich erst aus der vollständigen Rechnung.
Eine eigene, bewusst hypothetische Rechnung: Ein Server benötigt zehn Stunden bei durchschnittlich einem Kilowatt, um 1.000 Aufträge abzuschließen. Das sind zehn Kilowattstunden. Eine optimierte Fassung erledigt dieselben 1.000 Aufträge in acht Stunden und nimmt dabei durchschnittlich 1,1 Kilowatt auf. Ihr Verbrauch beträgt 8,8 Kilowattstunden. Obwohl die momentane Leistung höher ist, sinkt die Energie für diese feste Arbeit um 1,2 Kilowattstunden.
Diese Rechnung erklärt den Messansatz, nicht das Ergebnis eines bestimmten Rechenzentrums. Für einen fairen Vergleich müssten die Aufträge, ihre Ergebnisse und die geforderte Antwortqualität übereinstimmen. Auch Netzwerk, Speicher und der zusätzliche Betriebsaufwand gehören zur passenden Systemgrenze. Ein schneller Prozessor allein kann eine langsamere Datenzuführung oder aufwendigere Steuerung nicht aus der Bilanz verschwinden lassen.
Antwortzeiten dürfen in der Rechnung nicht verloren gehen
Betreiber können Ressourcen dichter zusammenlegen und dadurch weniger Geräte benötigen. Werden dabei Anfragen zu lange in Warteschlangen gehalten, verschlechtert sich jedoch der Dienst. Für Nutzer ist nicht nur eine durchschnittliche Antwortzeit relevant. Auch die seltenen besonders langsamen Antworten können eine Anwendung unangenehm machen, etwa wenn eine Suche oder ein Gespräch plötzlich hängen bleibt.
Eine sinnvolle Bewertung verbindet deshalb mindestens drei Fragen: Wie viel Arbeit wird abgeschlossen? Wie schnell erreicht das Ergebnis den Nutzer? Und wie viel Energie verbraucht das System dafür? Optimierung wird erst interessant, wenn diese Größen gemeinsam zum Zweck des Dienstes passen. Einen guten Wert herauszugreifen kann den eigentlichen Engpass verdecken.
Hinzu kommt der Umgang mit frei werdender Kapazität. Ein Unternehmen kann sie nutzen, um dieselbe Arbeit mit weniger Hardware zu erledigen. Es kann damit aber auch weitere Aufgaben bedienen. Im zweiten Fall wächst der Nutzen, während der absolute Stromverbrauch möglicherweise kaum fällt oder steigt. Effizientere Software beeinflusst die technische Möglichkeit; Nachfrage und Betriebsentscheidungen bestimmen den anschließenden Einsatz.
Die nächste Hardwarebestellung beginnt mit einer Diagnose
Die praktische Konsequenz ist ein anderer Blick auf Ausbau. Vor der Frage nach zusätzlichen Servern steht die Frage, wo vorhandene Geräte warten und warum. Liegt die Grenze bei echter Rechenarbeit, bei Datenwegen, bei Konflikten zwischen Aufgaben oder bei einer unpassenden Verteilung? Jede Antwort führt zu einer anderen Änderung.
Software kann diese Grenze verschieben, ohne dass dafür jeder Prozessor ersetzt werden muss. Zugleich bleibt Hardware wichtig: ihre Eigenschaften geben vor, welche Verteilung sinnvoll ist. Der interessante Fortschritt liegt im Zusammenspiel. Ein Rechenzentrum spart nicht automatisch, weil es einen intelligenten Controller besitzt. Es gewinnt dann, wenn dieser aus einem beobachteten Engpass einen messbar besseren Ablauf macht.
Quellen
- Adam Zewe / MIT News: Using AI to mitigate the growing environmental threat of data centers (2026-10-08).
- Adam Zewe / MIT News: Helping data centers deliver higher performance with less hardware (2026-04-07).
- Christina Delimitrou / MIT CSAIL: Research.
Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft.
