Compute, Energie und die physische Maschine

Eine Antwort ruht auf einer physischen Kette von Maschinen

Du schickst einem Sprachmodell eine Frage mit 600 Tokens. Wenige Sekunden später liest du die Antwort. Dazwischen liegt eine erstaunlich handfeste Kette.

Dein Gerät überträgt die Eingabe durch mehrere Netze in ein Rechenzentrum. Dort nimmt ein Server die Anfrage an. Speicher hält die Modellgewichte bereit. Rechenchips verarbeiten deine Tokens und erzeugen Schritt für Schritt neue. Andere Geräte verteilen Daten, sichern den Betrieb und schicken das Ergebnis zurück. Strom wird dabei zu Rechenarbeit und Wärme. Die Wärme muss wieder aus dem Gebäude heraus.

Bei einem lokalen Modell geschieht dasselbe in kleinerem Maßstab. Die Gewichte liegen im Speicher deines Computers. Sein Prozessor oder seine Grafikkarte rechnet. Der Lüfter transportiert die Wärme in dein Zimmer. Im Rechenzentrum stehen nur viel mehr Geräte dichter zusammen.

Auf unserer Landkarte liegt dieses Kapitel also unter dem Modell und seiner Anwendung. Es geht um die physische Maschine darunter. Sie bestimmt mit, wie schnell, teuer und verfügbar eine KI-Anwendung ist.

Eine KI-Antwort ist Software in Bewegung auf echter Hardware.

CPU, GPU, Beschleuniger, Speicher und Netzwerk

Nehmen wir an, ein Server soll 20 Kundenanfragen gleichzeitig bearbeiten. Dafür teilen sich mehrere Bauteile die Arbeit.

Die CPU ist der vielseitige Hauptprozessor eines Computers. CPU steht für Central Processing Unit. Sie führt das Betriebssystem aus, nimmt Netzwerkanfragen an und verteilt Aufgaben. Ihre Stärke ist Flexibilität.

Die GPU stammt ursprünglich aus der Grafikverarbeitung. GPU steht für Graphics Processing Unit. Sie enthält sehr viele Recheneinheiten, die ähnliche Operationen gleichzeitig ausführen können. Genau das passt zu den großen Zahlenmatrizen eines neuronalen Netzes. Eine Matrix ist einfach eine rechteckige Tabelle aus Zahlen.

Ein Beschleuniger ist ein Chip für eine enger bestimmte Rechenaufgabe. Googles Tensor Processing Units, kurz TPU, sind beispielsweise für Matrixoperationen beim maschinellen Lernen gebaut. GPU und TPU nehmen der CPU also besonders gleichförmige Rechenarbeit ab.

Rechnen allein reicht aber nicht. Der Speicher muss Gewichte und Zwischenwerte schnell liefern. Das Netzwerk bewegt Daten zwischen Geräten, Servern und Gebäuden. Ein schneller Chip wartet sonst auf Zahlen. Dann ist nicht seine Rechenleistung der Engpass, sondern der Weg zu den Daten.

Fortschritt entsteht deshalb aus dem ganzen System. Gordon Moore beobachtete 1965 und erneut 1975, dass immer mehr Bauteile wirtschaftlich auf einen Chip passten. Daraus entstand das sogenannte Mooresche Gesetz. Es beschreibt eine historische Entwicklung, kein Naturgesetz. Mehr KI-Leistung kommt heute auch durch spezialisierte Chips, schnelleren Speicher, bessere Netze und bessere Verfahren.

FLOP und FLOP/s sind unvollkommene Maße

Stell dir zwei Lieferfahrten vor. Die erste ist 100 Kilometer lang. Der Wagen schafft 100 Kilometer pro Stunde. Strecke und Geschwindigkeit tragen dieselbe Einheit im Namen, sagen aber etwas anderes.

Bei Rechenarbeit ist es ähnlich. Eine Gleitkommaoperation verarbeitet Zahlen mit Nachkommastellen. Die Abkürzung FLOP steht für Floating Point Operation. Die gesamte Zahl der FLOP beschreibt den Rechenaufwand einer Aufgabe. FLOP pro Sekunde, geschrieben FLOP/s, beschreibt dagegen eine Rechengeschwindigkeit.

Ein Trainingslauf kann also eine bestimmte Zahl an FLOP erfordern. Ein Chip kann unter bestimmten Bedingungen eine bestimmte Zahl an FLOP/s erreichen. Aus beiden Angaben ließe sich theoretisch eine Laufzeit ableiten. In der Praxis warten Chips aber auf Speicher und Netzwerk. Software verteilt Arbeit ungleich. Manche Recheneinheiten bleiben zeitweise frei.

Auch die Zahlenart zählt. Ein Hersteller nennt andere Spitzenwerte für 64, 32, 16 oder 8 Bit. Bit bezeichnet hier die Zahl der Stellen, mit denen ein Wert gespeichert wird. Niedrigere Genauigkeit erlaubt oft mehr Operationen pro Sekunde. Manche Spitzenwerte setzen außerdem voraus, dass viele Werte null sind.

FLOP und FLOP/s helfen beim Vergleichen. Sie messen weder Antwortqualität noch echte Auslastung, Stromverbrauch oder Kosten.

Trainingscluster und verteiltes Rechnen

Ein großes Pretraining passt oft nicht auf einen Chip. Die Gewichte, Zwischenwerte und Zustände für die Gewichtsänderung brauchen zu viel Speicher. Außerdem würde ein einzelner Chip sehr lange rechnen.

Ein Trainingscluster ist ein Verbund aus vielen Servern und Beschleunigern. Das Training verteilt seine Arbeit auf diesen Verbund. Bei Datenparallelität bearbeiten mehrere Gruppen verschiedene Datenpakete. Bei Modellparallelität teilen sie die Zahlen eines Modells untereinander auf. Pipeline-Parallelität gibt aufeinanderfolgende Modellteile an verschiedene Geräte. Große Systeme verbinden diese Verfahren.

Nach jedem Schritt müssen die beteiligten Geräte Ergebnisse austauschen. Dafür brauchen sie schnelle Verbindungen innerhalb eines Servers und zwischen Servern. Je größer der Verbund wird, desto mehr kann Kommunikation die Rechenchips bremsen. Die theoretische Summe ihrer Spitzenleistung sagt dann wenig über die tatsächlich genutzte Leistung.

Ein Checkpoint ist ein gespeicherter Zwischenstand. Fällt ein Gerät aus, kann der Lauf dort weitergehen. Ohne Checkpoints müsste das Team möglicherweise tagelange Rechenarbeit wiederholen. Auch das Speichern braucht Zeit, Speicherplatz und Netzwerkleistung.

Kapitel 8 erklärt Pretraining, Backpropagation und die Änderung der Gewichte. Dort bleibt auch der technische Tiefgang zum Optimierer Muon. Hier genügt die physische Folge: Training braucht Rechenchips, viel Speicher und laufende Abstimmung zwischen Geräten.

Inferenz, Batching, Latenz und Durchsatz

Nach dem Training beantwortet das fertige Modell Anfragen. Diese Nutzung heißt Inferenz. Die Gewichte bleiben dabei normalerweise unverändert. Trotzdem muss jede Anfrage durch die Schichten des Modells gerechnet werden.

Nehmen wir an, 16 Personen stellen fast gleichzeitig kurze Fragen. Der Server könnte jede Anfrage einzeln bearbeiten. Oft bündelt er mehrere Anfragen zu einem Paket. Dieses gemeinsame Verarbeiten heißt Batching. Ein gut gefülltes Paket nutzt die parallelen Recheneinheiten meist besser.

Die Wartezeit einer einzelnen Anfrage heißt Latenz. Der Durchsatz gibt an, wie viel Arbeit das System in einer Zeit schafft. Bei Sprachmodellen sind das häufig verarbeitete oder erzeugte Tokens pro Sekunde. Ein größeres Batch kann den Durchsatz erhöhen. Es kann aber eine einzelne Anfrage warten lassen, bis genug Arbeit zusammenkommt.

Eine Antwort hat außerdem zwei verschiedene Phasen. Zuerst verarbeitet das Modell alle Tokens der Eingabe. Danach erzeugt es die Ausgabe Token für Token. Eine lange Eingabe belastet die erste Phase. Eine lange Antwort verlängert die zweite, weil jedes neue Token auf den vorherigen beruht.

Für eine Textvervollständigung darf die erste Antwort vielleicht zwei Sekunden brauchen. Bei einer nächtlichen Zusammenfassung von 10.000 Dokumenten zählt eher der Gesamtdurchsatz. Deshalb gibt es kein allgemein bestes Batching.

Eine Firma sollte beides messen: typische und langsame Latenz sowie Durchsatz bei realistischer Last. Ein Durchschnitt allein versteckt die unangenehmen Spitzen.

Speicherbandbreite, HBM und Druck durch den KV-Cache

Nehmen wir ein dichtes Modell mit 70 Milliarden Parametern. Liegt jeder Parameter als 16-Bit-Wert vor, brauchen allein die Gewichte ungefähr 140 Gigabyte. Zwischenwerte und laufende Anfragen kommen noch dazu.

HBM bedeutet High Bandwidth Memory, also Speicher mit hoher Bandbreite. Bandbreite beschreibt, wie viele Daten der Speicher pro Sekunde übertragen kann. HBM sitzt sehr nah am Beschleuniger. Er ist schneller als gewöhnlicher Arbeitsspeicher, aber knapp und teuer.

Ein konkreter, datierter Vergleich macht die Größenordnung sichtbar. Nvidias im August 2026 abgerufene Produktseite nennt für eine H100 SXM 80 Gigabyte HBM3 und 3,35 Terabyte Speicherbandbreite pro Sekunde. Die unkomprimierten Gewichte aus unserem Beispiel passen damit nicht auf eine solche GPU. Mehrere Geräte oder eine kleinere Zahlendarstellung wären nötig. Das ist eine Herstellerangabe für genau dieses Produkt, keine allgemeine Eigenschaft von GPUs.

Während einer Antwort entsteht ein zweiter großer Speicherblock. Der Transformer berechnet für frühere Tokens sogenannte Key- und Value-Vektoren. Er bewahrt sie im KV-Cache auf, damit er sie beim nächsten Token nicht vollständig neu berechnen muss. Ein Cache ist ein schneller Zwischenspeicher.

Der KV-Cache wächst mit der Zahl und Länge gleichzeitiger Gespräche. Lange Kontexte erhöhen die Rechenarbeit und belegen Speicher. Ist der Speicher voll, passen weniger Anfragen in ein Batch. Dann sinkt der Durchsatz oder das System braucht weitere Geräte.

Rechenleistung ohne Speicherbandbreite ist wie eine schnelle Küche mit einer winzigen Ausgabeklappe. Die Zahlen müssen rechtzeitig ankommen.

Dichte Modelle und Mixture of Experts

Ein dichtes Modell nutzt für jedes Token dieselben Schichten und grundsätzlich alle Gewichte darin. Größer bedeutet bei gleicher Bauart meist mehr Speicher und mehr Rechenarbeit pro Token.

Ein Mixture-of-Experts-Modell teilt einige Schichten in mehrere Experten. Die Abkürzung MoE steht für Mixture of Experts, also eine Mischung aus Experten. Ein kleines Auswahlverfahren schickt jedes Token nur an einen Teil dieser Experten.

Stell dir acht Rechenblöcke vor, von denen pro Token zwei arbeiten. Dann bleibt ein großer Vorrat an Gewichten verfügbar, ohne dass jedes Token durch alle acht Blöcke laufen muss. Die genaue Zahl hängt vom Modell ab. Das Prinzip ist die sparsame Aktivierung.

Damit verschwindet der Rest der Maschine aber nicht. Alle Expertengewichte müssen gespeichert werden. Die Auswahl muss Tokens verteilen. In einem Cluster liegen Experten möglicherweise auf verschiedenen Geräten. Dann wächst der Netzwerkverkehr. Eine ungleiche Verteilung kann einzelne Geräte überlasten, während andere warten.

MoE trennt also Gesamtparameter von aktiven Parametern. Es kann Rechenarbeit pro Token senken, aber Speicher, Kommunikation und Betrieb bleiben echte Kosten.

Quantisierung, Destillation und Effizienz

Unser Modell mit 70 Milliarden Parametern brauchte bei 16 Bit ungefähr 140 Gigabyte für seine Gewichte. Mit 8 Bit wären es rechnerisch etwa 70 Gigabyte. Mit 4 Bit ungefähr 35 Gigabyte. Diese gröbere Darstellung heißt Quantisierung.

Quantisierung kann Speicherbedarf und Datenverkehr deutlich senken. Passende Hardware rechnet damit oft schneller. Die Umwandlung kann aber die Qualität verändern. Wie stark, hängt vom Modell, Verfahren und Einsatz ab. Ein Test mit echten Aufgaben bleibt nötig.

Destillation geht einen anderen Weg. Ein großes Lehrermodell erzeugt Ausgaben oder Wahrscheinlichkeiten. Ein kleineres Schülermodell lernt daraus. Das Ziel ist ein kleineres Modell, das wichtige Verhaltensweisen des Lehrers übernimmt. Es übernimmt nicht automatisch jede Fähigkeit oder Grenze.

Auch Caches sparen Arbeit. Bleibt ein langer Textanfang gleich, kann ein System bereits berechnete Teile wiederverwenden. Batching füllt die Hardware besser. MoE aktiviert weniger Gewichte. Neuere Chips können mehr passende Arbeit pro Watt leisten.

Algorithmen verändern ebenfalls den Aufwand. Kapitel 8 zeigt das am Optimierer Muon und qualifiziert die Ergebnisse der dort beschriebenen Versuche. Der technische Ablauf gehört dorthin. Für dieses Kapitel zählt nur die Konsequenz: Effizienz entsteht in Modell, Zahlenformat, Software, Speicher und Hardware gemeinsam.

Weniger Aufwand pro Aufgabe bedeutet noch keinen niedrigeren Gesamtverbrauch. Dazu kommen wir gleich.

Strom, Kühlung, Wasser und die Messgrenzen der PUE

Auf der H100-Produktseite stehen bis zu 700 Watt konfigurierbare thermische Auslegungsleistung. Watt ist Leistung zu einem Zeitpunkt. Eine Kilowattstunde ist dagegen Energie über eine Zeit. Die Herstellerangabe ist weder eine Messung des tatsächlichen Chipverbrauchs noch der Strombedarf eines ganzen Servers.

Zum Server gehören CPU, Beschleuniger, Speicher, Netzteile und Lüfter. Im Gebäude kommen Netzwerk, Stromumwandlung, Notstromversorgung und Kühlung hinzu. Erst die Summe am Stromanschluss beschreibt den Strom des Rechenzentrums.

Die IEA schätzte in ihrem Bericht von 2025 die Verteilung für 2024. Server standen im Durchschnitt für rund 60 Prozent des Stroms moderner Rechenzentren. Der Anteil der Kühlung reichte von etwa 7 Prozent bei effizienten großen Cloud-Rechenzentren bis zu mehr als 30 Prozent bei weniger effizienten Unternehmensrechenzentren. Das sind modellierte Durchschnittswerte und Spannweiten für Rechenzentrumstypen, keine Messung an jedem Standort.

Für den zusätzlichen Gebäudestrom gibt es eine Kennzahl. Power Usage Effectiveness, kurz PUE, teilt die gesamte Energie des Rechenzentrums durch die Energie seiner IT-Geräte. Bei einer PUE von 1,2 kommen auf 100 Kilowattstunden für IT weitere 20 Kilowattstunden für Kühlung, Stromverteilung und andere Gebäudetechnik.

PUE sagt nichts über die geleistete KI-Arbeit. Ein fast leerer Server kann in einem Gebäude mit guter PUE stehen. Die Kennzahl nennt auch weder den Strommix noch Treibhausgase oder Wasser.

Beim Wasser brauchen wir mindestens zwei Grenzen. Direktes Wasser wird am Standort beispielsweise durch Verdunstungskühlung verbraucht. Indirektes Wasser fällt außerhalb des Standorts bei der Stromerzeugung an. Wasserentnahme bezeichnet die entnommene Menge. Wasserverbrauch bezeichnet den Teil, der nicht unmittelbar in dasselbe Wassersystem zurückkehrt.

Der Bericht des Lawrence Berkeley National Laboratory von 2024 modelliert direkte Standortwerte und indirekte Folgen der Stromerzeugung getrennt. Seine Ergebnisse gelten für die Vereinigten Staaten und beruhen teilweise auf Annahmen zu Geräten, Wetter, Kühlung und Stromnetzen. Ein Betreiberbericht hat wieder eine andere Grenze. Google berichtete 2026, dass seine Projekte im Jahr 2025 rund 78 Prozent seines gesamten Süßwasserverbrauchs auffüllten. Diese Firmenkennzahl ist keine Messung des Wassers einer KI-Antwort. Auffüllung ist außerdem nicht dasselbe wie vermiedener Verbrauch am Standort.

Ohne Standort, Zeitraum und Messgrenze sind Umweltzahlen kaum vergleichbar.

Warum eine Energiezahl selten die ganze KI-Nutzung beschreibt

„Wie viel Energie braucht eine KI-Anfrage?“ klingt nach einer einfachen Frage. Nehmen wir zwei Anfragen. Die erste sortiert einen kurzen Satz mit einem kleinen Modell. Die zweite liest 200 Seiten, sucht im Internet, erzeugt ein Video und prüft ihr Ergebnis mehrfach. Beide zählen in einer Oberfläche vielleicht als eine Anfrage.

Der Verbrauch hängt vom Modell, der Zahl der Eingabe- und Ausgabetokens, dem Batch, dem Zahlenformat und der Auslastung ab. Werkzeuge, Suche, Wiederholungen und abgebrochene Versuche kommen hinzu. Danach entscheidet die Messgrenze, ob nur ein Chip, der Server oder das ganze Rechenzentrum gezählt wird.

Training und Inferenz gehören ebenfalls in getrennte Konten. Training verändert Gewichte in einem begrenzten Lauf. Inferenz nutzt diese Gewichte danach möglicherweise sehr oft. Bei einem wenig genutzten Modell kann das Training überwiegen. Bei einem stark genutzten Dienst kann die Summe der Inferenzen größer werden. Ohne Lauf und Nutzung lässt sich das Verhältnis nicht festlegen.

Globale Zahlen brauchen dieselbe Vorsicht. Die IEA schätzte 2025 den Strom aller Rechenzentren für das Jahr 2024 auf rund 415 Terawattstunden. Das waren etwa 1,5 Prozent des weltweiten Stromverbrauchs. Darin stecken KI, klassische Cloud-Dienste, Datenbanken, Speicher und Netzwerke.

Der neuere IEA-Bericht vom 16. April 2026 schätzt für 2025 rund 485 Terawattstunden. Seine mittlere Projektion liegt für 2030 bei rund 950 Terawattstunden und etwa 3 Prozent des weltweiten Stromverbrauchs. Die erste Zahl ist eine nachträgliche Schätzung. Die zweite ist ein Szenario unter Annahmen zu Nachfrage, Effizienz und Ausbau. Sie ist keine Messung aus der Zukunft.

Effizientere Antworten können neue Nutzung anziehen. Dieser Rückkopplungseffekt wird oft Jevons-Paradox genannt. Er ist kein Automatismus. Sinkt der Aufwand pro Aufgabe stärker als die Nutzung wächst, kann der Gesamtverbrauch fallen. Wächst die Nutzung schneller, kann er steigen.

Zu einer vergleichbaren Energieangabe gehören Aufgabe, Modell, Hardware, Zeitraum, Auslastung und Systemgrenze.

Betrieb, Kosten, Kapazität und Umweltbilanz

Nehmen wir an, dein Unternehmen plant einen Assistenten für 500 Beschäftigte. Eine Demo beantwortet zehn Fragen schnell. Für die Betriebsentscheidung fehlen trotzdem wichtige Zahlen.

Beginne mit der akzeptabel gelösten Aufgabe. Miss Kosten, Energie und Zeit pro brauchbarem Ergebnis. Fehlversuche und menschliche Nacharbeit gehören dazu. Ein kleines Modell ist nicht günstig, wenn drei Versuche nötig sind. Ein großes Modell ist nicht wirtschaftlich, nur weil der erste Entwurf gut aussieht.

Für den Betrieb brauchst du mindestens diese Größen:

• Eingabe- und Ausgabetokens pro Aufgabe
• typische Latenz und langsame Spitzen
• Durchsatz bei realistischer gleichzeitiger Nutzung
• Anteil erfolgreicher Aufgaben und nötige Wiederholungen
• belegter Speicher, Auslastung und Reserven
• Preis des Dienstes oder vollständige Kosten eigener Hardware

Bei einem API-Dienst zahlst du möglicherweise pro Token und für zusätzliche Werkzeuge. Eigene Hardware verursacht Anschaffung oder Miete, Strom, Kühlung, Software, Wartung und Bereitschaft. Reservierte Kapazität kostet auch dann, wenn gerade niemand fragt. Dafür kann sie eine zugesagte Verfügbarkeit sichern.

Kapazität beginnt nicht erst beim Chip. HBM, Netzwerk, Rackleistung, Kühlung und Netzanschluss müssen zusammenpassen. Die IEA-Analyse Energy and AI vom April 2025 schätzte, dass Netzengpässe rund 20 Prozent der weltweit bis 2030 geplanten Rechenzentrumskapazität verzögern könnten. Das ist eine Szenarioanalyse, keine Liste sicher ausfallender Projekte.

Auch die Chip-Lieferkette bleibt physisch. Ein Unternehmen entwirft den Beschleuniger. Andere fertigen Silizium, HBM und Gehäuse oder liefern Netzwerkkomponenten. ASML beschreibt EUV-Lithografie als Projektion mit extrem ultraviolettem Licht für besonders feine Chipstrukturen. Solche spezialisierten Schritte verteilen sich über Länder und Anbieter. Verfügbarkeit und Preis hängen von dieser Lieferkette ab.

Für die Umweltbilanz solltest du vier Ebenen getrennt ausweisen: gemessene Geräteenergie, Strom am Standort, direkte Kühlwassernutzung und indirekte Folgen des Stromsystems. Emissionen hängen vom Ort und Zeitpunkt der Stromerzeugung ab. Ein jährlicher Vertrag für erneuerbare Energie beweist nicht automatisch eine passende Versorgung in jeder Betriebsstunde.

Fordere bei einem Anbieter also Grenzen statt Werbewörter: Welche Geräte und Gebäudeteile sind enthalten? Ist der Wert gemessen oder geschätzt? Gilt er für Training oder Inferenz? Welcher Zeitraum, Standort und Strommix zählen? Wie werden Wasserverbrauch und Auffüllprojekte getrennt?

Wähle die Infrastruktur deshalb nach Aufgabe, Last und Messgrenze. Der größte Chipname beantwortet keine dieser Fragen.

Von der Maschine zu Kontrolle und Abhängigkeit

Vier kurze Fälle prüfen das Modell im Kopf:

1. Ein Chip schafft viele FLOP/s. Beweist das niedrige Antwortkosten? Nein. Speicher, Netzwerk, Auslastung und Software fehlen.
2. Ein MoE-Modell aktiviert wenige Experten. Passen deshalb alle Gewichte in kleinen Speicher? Nein. Auch inaktive Experten müssen irgendwo liegen.
3. Ein Rechenzentrum meldet eine PUE von 1,1. Ist seine Klimawirkung damit bekannt? Nein. Strommix, Auslastung, Herstellung und Wasser fehlen.
4. Eine Schätzung nennt Strom pro Anfrage. Was brauchst du zusätzlich? Aufgabe, Modell, Tokenlängen, Hardware, Batch, Zeitraum und Messgrenze.

Die physische Kette reicht vom Gerät über Chips und Speicher bis zu Kühlung und Stromnetz. Ihre Engpässe verschieben sich. Mehr Rechenleistung kann Speicher zum Problem machen. Mehr Server können am Netzanschluss warten. Bessere Effizienz kann Kosten pro Aufgabe senken und zugleich neue Nutzung auslösen.

Damit bleibt eine weitere Frage offen: Wer kontrolliert die Daten, Gewichte und Laufzeit auf dieser Maschine? Kapitel 20 betrachtet Daten, offene Modelle und digitale Souveränität. Dort geht es um Zugriff und Abhängigkeit. Die physische Grundlage dafür kennst du jetzt.