Google schließt Demand-Response-Verträge mit I&M und TVA, um ML-Workloads netzflexibel zu machen

Vom Verschieben eines YouTube-Transcodes zum Verschieben von ML-Jobs

Google erklärt, seine ersten Demand-Response-Funktionen in Rechenzentren hätten darin bestanden, nicht dringende Rechenaufgaben – als Beispiel wird die Verarbeitung eines YouTube-Videos genannt – aus Stunden mit angespannter Netzlage zu verschieben. Diese Funktionen liefen über Partnerschaften mit Centrica Energy und dem Übertragungsnetzbetreiber Elia in Belgien sowie mit der Taiwan Power Company in Taiwan.

Die beiden neuen Vereinbarungen mit Indiana Michigan Power (I&M) und der Tennessee Valley Authority (TVA) übertragen dieselbe Idee auf eine schwierigere Kategorie von Arbeitslasten. Google stellt klar fest, dass diese Verträge 'das erste Mal darstellen, dass wir Demand-Response in Rechenzentren gezielt über Machine-Learning-Workloads (ML) realisieren.' Vorausgegangen ist eine Demonstration mit dem Omaha Public Power District, bei der Google im vergangenen Jahr während drei Netzereignissen den mit ML verbundenen Strombedarf reduzierte.

Diese Entwicklung ist bedeutsam, weil ML-Training und Batch-Inferenz zu den größten und am schnellsten wachsenden Lasten in einem modernen Rechenzentrum zählen. Diese Jobs an Netzbedingungen koppelbar zu machen, ist eine ganz andere Herausforderung als das Verschieben einer Videokodierung – und genau diese Fähigkeit sichert sich Google nun vertraglich zu.

Das eigentliche Produkt ist eine Klassifizierung, welche Jobs warten können

Hinter der Sprache der Energieversorger steckt im Kern eine Scheduling-Aufgabe. Demand-Response funktioniert nur, wenn ein System zuverlässig unterscheiden kann, was sofort laufen muss und was 'zu bestimmten Stunden oder Jahreszeiten' verschoben oder reduziert werden kann, wie es im Beitrag heißt.

Google beschreibt flexible Nachfrage als etwas, das 'schnell eingesetzt werden kann und hilft, die Lücke zwischen kurzfristigem Lastwachstum und langfristigen Lösungen für saubere Energie zu schließen.' In der Praxis kommt diese Geschwindigkeit aus der Software: der Fähigkeit, ML-Jobs auf Signal eines Netzbetreibers zu pausieren, zu drosseln oder zu verlagern. Der Vertrag mit dem Energieversorger ist der Rahmen; der Klassifikator, der entscheidet, was aufschiebbar ist, ist der eigentliche Mechanismus.

Eine harte Zuverlässigkeitsgrenze rund um nutzerorientierte Dienste

Google macht deutlich, dass diese Flexibilität Grenzen hat. Man schreibt, dass es 'Grenzen dafür gibt, wie flexibel ein bestimmtes Rechenzentrum sein kann, da ein hohes Maß an Zuverlässigkeit für Dienste wie Search und Maps sowie für Cloud-Kunden in kritischen Branchen wie dem Gesundheitswesen unerlässlich ist.'

Die Einbindung von ML-Workloads ist ein wichtiger Schritt, um Nachfrageflexibilität in größerem Maßstab zu ermöglichen und dort, wo diese Fähigkeiten eingesetzt werden, Vorteile bei Netzzuverlässigkeit und Kosteneinsparungen zu erzielen.Montana Labs

Dieser Satz zieht die operative Grenze klar. Latenzsensitiver, nutzerorientierter Traffic – das Frontend, mit dem Menschen direkt interagieren – bleibt fest. Die verschiebbare Kapazität stammt aus ML-Arbeiten im Hintergrund. Demand-Response lässt sich genau deshalb skalieren, weil ML-Jobs auf der tolerierbaren Seite dieser Grenze liegen – nicht, weil Google bereit wäre, Search zu verlangsamen.

Was die vertragliche Flexibilisierung von ML-Lasten für netzbewusstes Scheduling bedeutet

Die konkrete Implikation dieser Vereinbarungen mit I&M und TVA ist, dass Google aufschiebbare ML-Rechenlast als verhandelbare Netzressource behandelt – nicht nur als internen Effizienzhebel. Steve Baker von I&M beschreibt Lastflexibilität als 'ein äußerst wertvolles Werkzeug' zur Versorgung von Googles neuem Rechenzentrum in Fort Wayne und verknüpft die schnellere Netzanbindung großer Lasten mit Googles Bereitschaft, die Nachfrage auf Anfrage zu senken.

Google räumt offen ein, dass dies noch in einem frühen Stadium ist und standortabhängig bleibt: Flexibilität 'wird nur an bestimmten Standorten verfügbar sein', und man nennt Investitionen in neue Erzeugungs- und Übertragungskapazitäten als Teil desselben Portfolios. Der strukturelle Punkt jedoch ist, dass die Trennung zwischen dringenden, nutzerorientierten Diensten und verschiebbarer ML-Arbeit nun fest in Verträgen mit Energieversorgern verankert ist. Für Teams, die große ML-Flotten betreiben, macht das Job-Scheduling zu etwas, das nicht nur in Kosten und Durchsatz einen Wert hat, sondern auch in Netzverpflichtungen – und es macht es umso wichtiger, genau zu wissen, welche Workloads sich gefahrlos zum Warten anweisen lassen.