Frankfurt ist voll: Warum Rechenzentren bis Mitte der 2030er warten müssen

Wer in Frankfurt ein großes Rechenzentrum bauen will, erhält von seinem Stromnetzbetreiber eine Warteschleifen-Angabe bis Mitte der 2030er Jahre. Dieser Beitrag beantwortet die Frage, was diese Auskunft für Menschen bedeutet, die ihre KI-Workloads ohnehin nicht in eigener Regie betreiben, sondern über Cloud-Anbieter laufen lassen. Die kurze Antwort vorweg: Für bestehende Anlagen ändert sich nichts, für neue Großprojekte wird der Standort Frankfurt zur Frage des Zeitpunkts, und für einzelne Agentenbetreiber lohnt sich der Blick auf die eigenen Ausfallstufen, lange bevor ein Netz eng wird.

Der Energieversorger Mainova teilt laut dpa-Bericht von Mitte März mit, dass insbesondere große, leistungsstarke Neuanschlüsse erst ab Mitte der 2030er Jahre erneut bereitgestellt werden können. Zur Begründung werden der Bau neuer Leitungen, hoher innerstädtischer Ausbaubedarf, anspruchsvolle Genehmigungsprozesse und Fachkräftemangel genannt. Der Punkt ist administrativ sauber abgegrenzt: Bestehende Rechenzentren können weiterbetrieben und im Rahmen vorhandener Kapazitäten erweitert werden. Auch Projekte, deren Anschlussleistung bereits vor längerer Zeit angemeldet und zugesagt war, sind nicht gemeint. Die Einschränkung betrifft also neue Großanfragen, nicht den laufenden Betrieb.

Die Größenordnung der Nachfrage zeigt dieselbe Quelle: Im Schnitt 5 bis 10 Anfragen von Betreibern pro Jahr gehen bei der Netztochter ein, 55 Rechenzentren stehen im Stadtgebiet, 13 weitere sollen bis 2030 dazukommen. Das Rhein-Main-Gebiet ist attraktiv wegen seiner Nähe zum Internetknoten DE-CIX, und genau diese Nähe macht den Engpass wirksam. Ein Beispiel aus dem Bericht: Der Betreiber Firstcolo wollte am Standort Frankfurt-Ost erweitern, die benötigte Stromleistung wäre vor 2035 nicht verfügbar gewesen. Das Unternehmen baut nun in einem größeren Radius um die Stadt herum, ein neues KI-Rechenzentrum im Wetteraukreis soll Ende 2027 ans Netz gehen.

Drei Lesarten sind falsch, und jede taucht regelmäßig in der Debatte auf. Erstens: Frankfurt hat keinen Stromausfall und keine allgemeine Versorgungslücke, der Engpass betrifft neue Großanschlüsse. Zweitens: Es ist kein KI-Verbot, betrieben und Erweiterungen innerhalb vorhandener Kapazitäten sind ausdrücklich möglich. Drittens: Die Angabe Mitte der 2030er ist ein Zeitplan des Netzbetreibers unter heutigen Bedingungen, keine Naturkonstante; sie hängt von Leitungsbau, Genehmigungen und Fachkräften ab, und genau diese Faktoren sind als Ursachen genannt.

Was man daraus belastbar lesen kann, ist eine Standortentscheidung mit Signalwirkung: Wenn im wichtigsten deutschen Rechenzentrumsknoten die Anschlussleistung für Neubauten jahrelang ausgebucht ist, verlagert sich das Wachstum in Umland und Bundesgebiet. Die 23 geplanten Regionalstandorte außerhalb Frankfurts sind genau diese Verschiebung in Zahlen. Für die Gesamtnachfrage nach Rechenleistung ändert das wenig, für die Netzplanung und die Standortentscheidungen einzelner Betreiber sehr viel.

Der klassische Fehler solcher Nachrichten in der Agenten-Debatte ist die Zweitellung: entweder Cloud oder komplett offline, und offline heißt auf dem eigenen Rechner mit eigener GPU. Mein Setup auf einem 45-Euro-Handy lebt in der Praxis in drei Stufen, und die Unterscheidung ist genau das, was bei Netz- oder Provider-Problemen den Unterschied zwischen Ausfall und Drosselung macht. Stufe eins ist die volle Cloud-Arbeit: Modell-Anfragen, Recherchen und Verifikation laufen über Anbieter, das ist der Normalzustand und bei Weitem der häufigste.

Stufe zwei ist die gedrosselte Cloud: Das eigene Skript-Universum läuft weiter, aber die Modell-Aufrufe werden auf das Notwendigste reduziert, Batch-Aufträge werden zusammengelegt, und die Reihenfolge folgt einer Prioritätenliste statt einer Latenz-Erwartung. Genau diese Stufe habe ich am 05.09.2026 dokumentiert: Die komplette Verarbeitung eines 54-minütigen Videos hat 0,5 Prozent meines Ollama-Fünf-Stunden-Fensters verbraucht, weil der mechanische Anteil des Workflows keine Modell-Anfragen verbraucht. Drosselung bedeutet hier also nicht Stillstand, sondern Verschiebung und Konzentration der Aufrufe.

Stufe drei ist der Offline-Kern: Automatisierungen, die ohne Cloud auskommen, Watchdogs, Monitoring, lokale Vorverarbeitung, und ein Gedächtnis, das lokal liegt. Diese Stufe ersetzt keine Cloud-Inferenz, und der Text behauptet das nicht. Das ist ein konzeptionelles Stufenmodell, geplant als Reaktion auf Engpässe. Einen Test dieses Workflows unter realer Provider-Drosselung habe ich noch nicht durchgeführt. Was ich tatsächlich belegt habe, ist die Kontingentseite: die Video-Messung im nächsten Absatz. Die drei Stufen zusammen beantworten die Frankfurt-Frage auf persönlicher Ebene: Der Standort eines Rechenzentrums ist mein Problem nicht, meine Abhängigkeit von dessen Kapazität aber schon, und die lässt sich stufenweise managen.

Der Frankfurter Engpass wirkt so groß, weil der Standort mehr kann als Strom verbrauchen: Am DE-CIX, einem der größten Internetknoten der Welt, laufen Verbindungen mit kurzen Wegen und kleinen Wartezeiten zusammen, und Rechenzentren in der Nähe bedienen diesen Markt direkt. Für klassische Internet-Dienste ist diese Nähe echtes Geld, weil jede Millisekunde zu Kunden zählt. Für die Frage dieses Blogs ist der entscheidende Punkt ein anderer: Wer KI-Dienste über eine Programm-Schnittstelle nutzt, kauft Rechenleistung als Dienst und nicht als Fläche am Knoten. Verlagert ein Betreiber sein Wachstum aus Frankfurt ins Umland, merkt ein API-Nutzer davon im Idealfall gar nichts, solange Anbieter und Anbindungen mithalten.

Genau deshalb ist die Nachricht für Agentenbetreiber weniger bedrohlich als für Betreiber von Handelsplattformen, und genau deshalb lohnt die Stufenlogik: Die eigene Abhängigkeit sitzt nicht am Frankfurter Grundstück, sondern am Vertrag mit dem Anbieter. Wie verlässlich dieser Vertrag wächst, wenn die Kapazität an anderer Stelle gebaut wird, entscheidet über Antwortzeiten und Preise, nicht über die Existenz des Dienstes. Wer dagegen eigene Server am Knoten betreibt, spürt die Standortfrage direkt, weil Fläche, Anschluss und Latenz sein Produkt sind.

Viele Agenten-Setups kommen mir ohne eigene Backup-Strategie vor, für den Fall, dass Cloud-Angebote knapper werden; belastbare Zahlen dazu habe ich nicht, es ist eine Beobachtung aus meinen Gesprächen und Lektüren. Das klingt dramatischer als es gemeint ist: Es geht nicht um den Blackout, sondern um die unspektakulären Fälle, Preissteigerungen, Kontingentkürzungen, Warteschlangen, regionale Drosselungen. Die Frankfurt-Auskunft ist ein Beispiel dafür, wie solche Begrenzungen aussehen, lange bevor irgendetwas ausgefallen ist: Es gibt einen Zeitplan, es gibt Ausnahmen, es gibt eine Verlagerung ins Umland. Wer seine eigene Stufenlogik kennt, reagiert auf solche Nachrichten mit Anpassung statt mit Überraschung.

Zwei konkrete Vorsichtsmaßnahmen haben sich hier bewährt. Erstens: Wichtige Ergebnisse landen lokal, nicht nur in der Cloud, weil ein Kontingent-Ende oder eine Provider-Sperre den Zugriff sonst mit vereinnahmt. Zweitens: Die eigene Rechnung führt Kontingent und Nutzung getrennt, so dass eine Drosselung messbar ist und nicht nur als Gefühl im Workflow auftaucht. Wie die Entsprechung dieser Logik im Stromnetz aussieht, also im Großen, behandelt der Texas-Beitrag, der dieselbe Debatte auf US-Ebene begleitet.

Vier Einschränkungen gehören in diesen Text. Erstens: Meine Quelle für die Mainova-Auskunft ist der dpa-Bericht bei ZEIT vom 18.03.2026, das Spiegel-Original liegt hinter einer Paywall und war nicht direkt zugänglich; die tagesschau-Redaktion hat denselben Vorgang mit derselben Zeitangabe berichtet. Zweitens: Die Zahlen zu 55, 13 und 23 Standorten stammen aus derselben Berichterstattung und sind als Presseangaben, nicht als amtliche Statistik zu lesen. Drittens: Die 0,5-Prozent-Messung ist eine Einzelmessung aus meinem Projektbetrieb, dokumentiert im Projekt-Log, keine Testreihe. Viertens: Ob die Netzausbauplanung bis Mitte der 2030er hält, ist eine Prognose des Netzbetreibers, keine Gewähr.

Ich bin Marcel, Grafikdesigner und Betreiber der d4sn3st-Seiten. Seit 2026 betreibe ich KI-Agenten auf einem gebrauchten Google Pixel 6a und dokumentiere auf diesem Blog, wie der Betrieb mit begrenzten Ressourcen im Alltag aussieht. Diesem Beitrag liegen der dpa-Bericht bei ZEIT vom 18.03.2026 und die tagesschau-Berichterstattung zugrunde sowie eigene Messwerte vom 05.09.2026. Zuletzt fachlich geprüft am 05.09.2026.