Finanzmodelle für Rechenzentren: Zehn Einsichten aus der Praxis, die zeigen das die Modellierung nicht trivial und zeitgleich mächtig ist
Ein Rechenzentrum kann die ganze Nacht Strom fressen, seine Hardware altern lassen und dabei keinen Cent verdienen. Physisch läuft der Betrieb, kommerziell steht er still. Genau an dieser Stelle scheitern viele Finanzmodelle: Sie behandeln die Anlage wie ein abstraktes Gebäude. Dabei ist sie ein Übersetzungssystem – aus physischem Kapital wird verkäufliche Rechenleistung, und erst daraus wird Cashflow. Die entscheidenden Eingangsgrößen stehen deshalb nicht in einer gewöhnlichen Gewinn-und-Verlust-Rechnung. Sie heißen IT-Kapazität, Anschlusslast, Kühlbedarf, PUE, Strompreis, Hardware-Tausch, Auslastung und Verkaufseinheit. Wer sie sauber modelliert – die Arbeiten von Edward Bodmer machen das vorbildlich vor –, bekommt ein Werkzeug für Entscheidungen. Wer sie in einer Zelle zusammenrührt, bekommt eine Tabelle. Zehn Einsichten aus der Praxis.
1. Erst das Produkt, dann das Gebäude
Ein Rechenzentrum lässt sich in Quadratmetern beschreiben, in Racks, Megawatt, GPUs oder Tokens – und keine dieser Einheiten ist gegen die andere austauschbar. Der Colocation-Anbieter verdient je vertraglich zugesagtem Kilowatt oder Rack, die GPU-Cloud verkauft GPU-Stunden, die KI-Plattform bepreist reservierte Cluster, erledigte Workloads oder Tokens. Der Hyperscaler wiederum bewertet Kapazität über das Geschäft seiner digitalen Dienste. Dieselbe Million Dollar wirkt je Gebäude sparsam, je Kilowatt teuer und je Million Tokens entweder attraktiv oder ruinös. Die Einheit entscheidet über das Urteil. Deshalb gehört die Produktionskette sichtbar ins Modell: installierte IT-Kapazität, verfügbare Rechenkapazität, genutzte Kapazität, verkäuflicher Output, Umsatz. Jeder Pfeil dazwischen braucht eine eigene Annahme. Wer direkt von Megawatt auf Umsatz springt, versteckt die wichtigsten kommerziellen Risiken in einer einzigen Zelle.
2. IT-Last ist nicht Anschlussleistung
„Ein 100-Megawatt-Rechenzentrum“ – klingt präzise, sagt aber nichts. Gemeint sein kann die Leistungsaufnahme der IT oder der Bedarf des gesamten Standorts, und dazwischen liegt die Kühlung. Die Brücke schlägt die Power Usage Effectiveness: Gesamtenergie des Standorts gleich IT-Energie mal PUE. Bezeichnen die 100 Megawatt die IT-Kapazität und liegt der PUE bei 1,20, braucht der Standort 120 Megawatt. Bezeichnen sie den Netzanschluss, fällt die IT-Kapazität entsprechend kleiner aus – und mit ihr Output und Umsatz. Deshalb gehören ins Modell Etiketten wie MW_IT und MW_Standort statt eines nackten „MW“, und die Investitionskosten je Kilowatt brauchen denselben Zusatz. Ein einziges zweideutiges Label pflanzt sich durch Hunderte Formeln fort und liefert am Ende ein Ergebnis, das in sich stimmig ist und physikalisch falsch. Das Rechenwerk merkt davon nichts. Der Investor später schon.
3. Lastfaktor ist nicht Auslastung
Zwei Größen, die gern verwechselt werden: Der Lastfaktor sagt, wie viel der installierten Elektro- und Kühlkapazität über die Zeit tatsächlich aktiv ist. Die kommerzielle Auslastung sagt, wie viel nutzbare Kapazität verkauft wird. Ein Rechenzentrum kühlt, hält Redundanzen vor und betreibt seine Nebensysteme auch dann, wenn die Kundennachfrage dem Plan hinterherhinkt. Es gleicht einem Hotel, das geheizt und mit Personal dasteht, während die Zimmer leer bleiben. Die Belegung bestimmt den Umsatz, die Betriebskosten folgen dem Gebäude. Ins Modell gehören darum drei getrennte Zeilen: installierte IT-Kapazität, betriebliche Last oder Verfügbarkeit, kommerzielle Auslastung des verkäuflichen Outputs. Am wichtigsten ist die Trennung in der Hochlaufphase, wenn die Anlage schon abgenommen ist, die Cluster noch installiert werden, die Kunden noch migrieren und die Software noch optimiert wird. Wer diese Stadien zu einem Prozentsatz zusammenschnurren lässt, lässt den frühen Cashflow kräftiger aussehen, als der Betrieb es hergibt.
4. Erst das operative Geschäft, dann die Finanzierung
Fremdkapital kann ein schwaches Projekt raffiniert aussehen lassen. Gesund machen kann es das Projekt nicht. Deshalb empfiehlt sich eine feste Reihenfolge: erst der Betrieb, dann der unverschuldete Cashflow, dann der erforderliche Preis und die Projektrendite, dann Steuern, dann Schulden, dann die Eigenkapitalrendite. Diese Ordnung hat zwei Vorzüge. Rendite und erforderlicher Verkaufspreis lassen sich ohne Finanzierungsrauschen testen, bevor Bauzeitzinsen, Schuldendimensionierung, Steuerschilde, Covenants und Cash Sweeps ihre Zirkelbezüge durch die Mappe ziehen. Und die Verantwortung wird sortiert: Technik und Vertrieb müssen die Betriebsannahmen verteidigen, bevor Treasury und Banken die Kapitalstruktur darum herum optimieren. Nicht umgekehrt.
5. Monatlich rechnen, wo sich monatlich etwas ändert
Ein Jahresmodell kann ein acht Monate langes Bauprogramm nicht sauber abbilden. Stufenweise Energetisierung, ein sechsmonatiger Hochlauf, ein Hardware-Tausch im Betriebsmonat 28 – dafür ist das Raster zu grob. Es bügelt außerdem die Saisonalität der Strompreise und die temperaturabhängige Kühllast glatt. Der praktische Kern ist deshalb ein Monatsmodell, mit einer Jahreszusammenfassung obendrauf fürs Berichtswesen. Auf Monatsebene werden sichtbar: Bau- und Betriebsflags, Tage und Stunden je Periode, Kapazitätszugänge, Hochlauf, Tauschereignisse, Preisindizes und wetterfühlige Betriebskosten. Der Hardware-Tausch nach einer Zahl von Betriebsmonaten statt nach Kalenderjahren entspricht dem Leben der Anlage – und verschiebt Capex und Produktionsausfall gleich mit. Feiner als monatlich muss es nur werden, wo Stunden tatsächlich über Wert entscheiden: bei Strommarktexposure, beim Abgleich mit erneuerbarer Erzeugung, beim Batterieeinsatz.
6. Capex in Jahrgängen denken
Gebäudehülle und Rechentechnik teilen sich kein wirtschaftliches Leben. Hülle, Netzanschluss und Elektroinfrastruktur überdauern mehrere Generationen von IT-Equipment. GPUs, Netzwerktechnik und Flüssigkühlungs-Schnittstellen sind kommerziell schneller von gestern. Also gehören die Investitionen getrennt: IT-Equipment, elektrische und mechanische Infrastruktur, Bau- und Standortarbeiten, spätere Ersatz- und Ausbauinvestitionen – jede Kategorie mit eigenem Inbetriebnahmedatum, eigener Betriebsdauer, eigener Ersatzquote und eigener Preisannahme. Denn IT-Preise können fallen, während Leistungsdichte und Infrastruktur je Rack teurer werden. Eine pauschale Inflationsrate fängt diese Kombination nicht ein. Und der Tausch selbst ist eine Betriebsfrage, keine Buchungszeile: Steht die ganze Halle still oder wird stufenweise gewechselt? Steigt mit dem Refresh der Token-Output je Kilowatt? Wandert die Alt-Hardware ins Inferencing, in die Reserve oder in den Verkauf?
7. Der PUE ist keine Naturkonstante
Kaum eine Kennzahl bekommt im Modell mehr Gewissheit zugesprochen, als das dahinterliegende System hergibt. Der Kühlaufwand hängt an Außentemperatur, Teillast, Gerätezustand und Regelstrategie – ein Jahresmittelwert ist dünn, wenn Strom der größte Kostenblock ist. Das Minimum sind drei Fälle, niedrig, Basis, hoch. Besser ist ein PUE, der an Monatstemperatur und Last hängt. Wer stündlichen Strompreisen oder variabler Erzeugung ausgesetzt ist, rechnet mit stündlichen Wetter- und Einsatzdaten. Die Formelkette bleibt dabei bewusst schlicht. IT-Energie gleich MW_IT mal Betriebsstunden mal Lastfaktor. Standortenergie gleich IT-Energie mal PUE als Funktion von Last, Temperatur und Alter. Stromkosten gleich Standortenergie mal geliefertem Strompreis. Getrennte Schritte zeigen Fehler – und erlauben es, eine Kühlungs-Nachrüstung zu testen, ohne am Umsatzmotor zu drehen.
8. Strom ist ein Portfolio, kein Preisschild
Ein flacher Jahresdurchschnittspreis reicht für eine Überschlagsrechnung, aber selten für einen Investitionsbeschluss. Er versteckt die teuren Stunden, die Ausgleichskosten und die Lücken zwischen erneuerbarer Erzeugung und Dauerlast. Real beschafft ein Rechenzentrum sein Portfolio aus Netzbezug, PPAs, Eigenerzeugung, Speichern und Restmenge am Markt. Das Modell rechnet deshalb erst den physischen Verbrauch und verteilt ihn dann auf die Quellen – je Quelle mit verfügbarer Menge, Preisregel, Lieferprofil und verbleibendem Risiko. Eine Batterie kommt nur mit ausformulierter Betriebsregel ins Modell: wann sie lädt, wann sie entlädt, was der Wirkungsgrad kostet und wie viel Kapazität nach Degradation übrig ist. Und wo das kommerzielle Versprechen vom Abgleich variabler Erzeugung mit nahezu konstanter Last lebt, braucht es die Stundenauflösung: Eine Jahresenergiebilanz beweist nur, dass zwei Summen zusammenpassen. Zwei Szenarien mit identischem Jahresmittel können sehr verschiedene Rechnungen produzieren, wenn die teuren Stunden ausgerechnet dann kommen, wenn sich die Last nicht drosseln lässt.
9. Den nötigen Preis ausrechnen, nicht nur die erhoffte Rendite
Das Standardmodell nimmt einen Verkaufspreis an und rechnet daraus die interne Verzinsung. Oft ist die umgekehrte Frage die nützlichere: Welcher Preis wäre nötig, um die Zielrendite zu erreichen? Technisch ist das eine Zielwertsuche – der Barwert des unverschuldeten freien Cashflows wird beim Zieldiskontsatz auf null gesetzt, variiert wird der Stückpreis. Ökonomisch ist es ein Wettbewerbstest. Heraus kommt ein erforderlicher Preis je GPU-Monat, je Kilowatt-Monat oder je Million Tokens, und der lässt sich gegen echte Kundenverträge, beobachtbare Marktangebote oder den internen Wert der Rechenleistung halten. Die Lücke zwischen erforderlichem und erzielbarem Preis sagt mehr als eine einzelne Rendite aus einer optimistischen Umsatzannahme. Die Intuition dahinter: Teurer Strom hebt den erforderlichen Preis. Ein langsamer Hochlauf hebt ihn weiter, weil sich Fixkosten und Kapital auf weniger Output verteilen. Und mehr Leistung je Watt senkt ihn nur, wenn Software und Workload die theoretische Leistung auch in nützliche Produktion verwandeln. Das beste Modell zeigt beide Richtungen: die Rendite aus dem angenommenen Preis und den Preis für die verlangte Rendite.
10. Transparenz ist eine Kontrolle, keine Formatierungsfrage
Verschachtelte Lookups, volatile Indirekt-Bezüge und große Array-Formeln machen Formeln kürzer und die Geschäftslogik unsichtbarer. Spätestens wenn die Mappe Monate nach ihrem Autor geprüft wird, wird aus der Cleverness eine Last. Die Gegenmittel sind unspektakulär: konstante Eingaben, Zeitreihen, Berechnungen, Szenarien und Ausgaben getrennt halten, kurze Formelketten, ausgewiesene Einheiten, klare Zeitflags, und Quellenblätter mit Datum, Technologie, Region und Benchmark-Basis. Niedrig, Basis und Hoch bleiben sichtbar stehen, statt vom jeweils aktiven Szenario überschrieben zu werden. Das deckt sich mit den FAST-Prinzipien – flexibel, angemessen, strukturiert, transparent –, die Verständlichkeit verlangen und keine dekorative Einheitlichkeit. Ein Wort noch zur KI: Wenn sie Kandidaten für Eingabewerte liefert, sind das Hypothesen, keine Fakten. Geprüft wird gegen Herstellerdaten, Betriebsaufzeichnungen und Verträge. Ins Modell wandern Quelle und Bandbreite, nicht bloß die bequemste Antwort.
Fünf Proben aufs Exempel
Bevor die Mappe vor den Investitionsausschuss kommt, lohnen fünf Handgriffe.
Erstens die Kapazitätsprobe: Kann das Modell IT-Megawatt von Standort-Megawatt unterscheiden? Wenn nicht, ist hier Schluss.
Zweitens die Auslastungstest: Wird die kommerzielle Auslastung gesenkt, während die physische Last steht – verschwinden dann Strom- und Kühlkosten im Gleichschritt mit dem Umsatz, stimmt die Betriebslogik nicht.
Drittens der Projektplanungtest: Inbetriebnahme und ersten Hardware-Tausch um einige Monate verschieben. Ändert sich der Cashflow kaum, sind die Zeitflags zu grob.
Viertens die Preistest: Zielrendite setzen, Stückpreis ausrechnen lassen und gegen einen belastbaren Markt- oder internen Vergleichswert halten.
Fünftens die Nachvollzugsprobe: Ein unbeteiligter Modellierer verfolgt eine Umsatzeinheit und eine Stromkosteneinheit vom Input bis zum Cashflow. Braucht er dafür den Autor, ist die Mappe noch kein Investitionswerkzeug.
Was ein gutes Modell leistet
Ein Finanzmodell soll Entscheidungen sichtbar machen, nicht Gewissheit fabrizieren. Beim Rechenzentrum kommt die Physik vor der Finanz. Erst die Definition der Kapazität, die Grenze zwischen IT- und Standortlast, die Kühlung, die Last und Wetter folgt, die alternde und zu tauschende Hardware, der tatsächlich verkaufte Output. Dann erst ergeben Preise und Renditen einen Sinn. Ein gutes Modell verhält sich deshalb weniger wie ein Taschenrechner und mehr wie ein gut geordnetes Argument. Jede wichtige Schlussfolgerung lässt sich auf einen Betriebsmechanismus zurückverfolgen. Jede kritische Annahme trägt Einheit, Quelle und Szenario. Und jede scheinbare Effizienz lässt sich anzweifeln, ohne dass die Mappe auseinanderfällt. Unsicher bleiben die Zahlen am Ende trotzdem. Aber man sieht, worauf die Unsicherheit steht – und genau das brauchen Investoren, Ingenieure und Betreiber, um besser zu entscheiden.
Quellen:
Edward Bodmer: Data Center Modelling – Modellbeispiele und Arbeitsmappen, https://edbodmer.com/data-center-modelling/
The Green Grid: PUE – A Comprehensive Examination of the Metric
FAST Standard Organisation: The FAST Standard, https://www.fast-standard.org/
NVIDIA: Power and Thermals – GB200 NVL Multi-Node Tuning Guide