Sunday Latte: Warum KI so viel Rechenleistung braucht Canonical episode: https://move37.app/cafe/de/episodes/sunday-latte-why-ai-needs-so-much-compute-de/ Published: 2026-08-17T07:48:19Z Language: de TRANSCRIPT Willkommen in Andy's Café, wo Maschinen brühen und Menschen genießen. Heute servieren wir einen Sunday Latte. Nehmen Sie sich Zeit und hören Sie in Ruhe zu. Eine kurze Frage, eine große Maschine Eine kurze Frage wird eingetippt. Wenige Augenblicke später steht eine ausführliche Antwort auf dem Bildschirm. Der Vorgang wirkt leicht und beinahe mühelos. Gleichzeitig entstehen Rechenzentren voller Spezialchips, nur damit solche Modelle lernen und anschließend benutzt werden können. Wie passt das zusammen? Zunächst gilt eine wichtige Einschränkung: Künstliche Intelligenz ist kein einzelnes Verfahren. Ein kleines System, das Maschinengeräusche überwacht, braucht nicht dieselbe Ausstattung wie ein sehr großes Sprachmodell. Hier geht es vor allem um Modelle, die Text schrittweise erzeugen und deren Kern aus vielen dicht miteinander verbundenen Rechenschichten besteht. Bei ihnen fallen zwei verschiedene Rechnungen an. Die erste entsteht beim Training. Dabei lernt das Modell sehr viele Zahlenwerte, die Gewichte genannt werden. Die zweite entsteht bei jeder Nutzung. Dann werden diese Gewichte auf die Eingabe und auf jeden weiteren Teil der Antwort angewendet. Das Training ist eine große Investition im Voraus. Die Nutzung wiederholt einen kleineren Aufwand immer wieder. Ein Sprachmodell ist im Kern eine gewaltige erlernte Zahlenfunktion. Es durchsucht für eine Antwort nicht jedes Mal seine gesamten Trainingsdaten. Stattdessen führt es eine lange Folge mathematischer Operationen aus. Jede einzelne davon ist einfach. Teuer wird das Ganze durch die enorme Zahl der Wiederholungen und durch die Daten, die dabei ständig durch Speicher und zwischen Maschinen bewegt werden müssen. Mit Rechenaufwand ist deshalb nicht nur die Geschwindigkeit eines Chips gemeint. Es geht auch um Speicherplatz, Datenverkehr, Wartezeiten und darum, wie gut alle Teile gemeinsam ausgelastet werden. Um die große Maschine hinter der kleinen Antwort zu verstehen, müssen wir zuerst anschauen, was sie eigentlich berechnet. Wie Sprache zur Rechnung wird Bevor ein Modell mit einem Satz arbeiten kann, zerlegt es ihn in Token. Das sind kleine Texteinheiten, die ein Wort, einen Wortteil oder ein Satzzeichen umfassen können. Jedes Token wird als Vektor dargestellt, also als eine geordnete Reihe von Zahlen. Diese Zahlen sind keine Definition aus einem Wörterbuch. Sie sind eine erlernte Darstellung, mit der das Modell Beziehungen im Text verarbeiten kann. In jeder Schicht werden solche Vektoren verändert. Ein zentraler Schritt heißt Aufmerksamkeit. Das Modell bildet mehrere Darstellungen eines Tokens und vergleicht sie mit dem übrigen Kontext. So kann eine Stelle im Satz stärker von einem weit zurückliegenden Namen abhängen als von ihrem direkten Nachbarn. Danach folgen weitere Umformungen, die auf jede Position angewendet werden. Ein großer Teil dieser Arbeit besteht aus Matrixmultiplikationen. Eine Matrix ist eine rechteckige Anordnung von Zahlen. Eine einzelne Multiplikation mit anschließender Addition kostet fast nichts. Doch das Modell führt sie für sehr viele Zahlen gleichzeitig aus, in vielen Schichten, für jedes Token und für jede Anfrage. Nicht der einzelne Rechenschritt ist außergewöhnlich, sondern seine Vervielfachung. Gewöhnliche Hauptprozessoren sind für sehr unterschiedliche Aufgaben gebaut. Grafikprozessoren und besondere Beschleuniger widmen einen großen Teil ihrer Fläche der parallelen Zahlenarbeit. Sie können viele ähnliche Operationen gleichzeitig durchführen und passen deshalb gut zu großen Matrizen. Das macht sie nicht zu schnelleren Universalrechnern. Ihr Vorteil zeigt sich nur, wenn sich eine Aufgabe in genügend große, regelmäßige Blöcke zerlegen lässt. Auch die angegebene Höchstleistung eines Beschleunigers ist lediglich eine Obergrenze. Die Recheneinheiten müssen fortlaufend mit Daten versorgt werden. Sind die Arbeitsblöcke ungünstig geformt, kommt der Speicher nicht nach oder wartet ein Gerät auf ein anderes, bleibt ein Teil der möglichen Leistung ungenutzt. Der Chip kann rechnen, aber das Gesamtsystem bestimmt, wie viel davon tatsächlich ankommt. Lernen durch Korrektur Beim Training erhält das Modell Text und versucht vorherzusagen, welches Token als Nächstes folgt. Seine Vorhersage wird mit dem tatsächlichen Text verglichen. Daraus entsteht ein Fehlerwert. Anschließend wird berechnet, welchen Anteil die vielen Gewichte an diesem Fehler hatten und in welche Richtung sie leicht verändert werden sollten. Ein Optimierungsverfahren führt diese Änderungen aus. Dieser Ablauf wiederholt sich immer wieder: vorhersagen, Fehler bestimmen, Korrekturen berechnen, Gewichte anpassen. Dann kommt der nächste Ausschnitt aus den Trainingsdaten. Für ein gewöhnliches dichtes Sprachmodell wächst die Rechenarbeit grob sowohl mit der Zahl der Gewichte als auch mit der Menge der verarbeiteten Token. Das ist eine nützliche Vorstellung, aber keine unveränderliche Kostenformel für jede Architektur. Das Training benötigt außerdem viel mehr Speicher als das fertige Modell allein. Für die Korrektur müssen zahlreiche Zwischenergebnisse aufbewahrt oder später erneut berechnet werden. Hinzu kommen die berechneten Änderungsrichtungen und zusätzliche Zustände des Optimierungsverfahrens. Ein Modell, das sich nach dem Training gerade noch auf einige Beschleuniger verteilen lässt, kann beim Lernen ein Vielfaches dieser Ausstattung beanspruchen. Die Gewichte speichern dabei keine sauber sortierte Bibliothek von Sätzen. Sie nehmen statistische Regelmäßigkeiten aus den Daten auf. Dadurch kann das Modell neue Formulierungen bilden und bekannte Muster auf einen neuen Zusammenhang anwenden. Aus demselben Grund kann es aber auch eine überzeugend klingende Aussage erzeugen, für die es keine verlässliche Grundlage gibt. Viel Rechenaufwand verwandelt eine Vorhersage nicht automatisch in Wissen. Auch die Datenmenge allein entscheidet nicht über den Lernerfolg. Wiederholungen, Fehler und schlecht ausgewählte Beispiele können Ressourcen verbrauchen, ohne dem Modell das Richtige beizubringen. Ebenso wichtig ist das Trainingsziel. Das Modell verbessert, was dieses Ziel belohnt. Es entdeckt nicht von selbst, welche Eigenschaften Menschen später als wahr, hilfreich oder verantwortungsvoll ansehen. Rechenleistung ermöglicht das Lernen, ersetzt aber keine gute Auswahl von Daten und Zielen. Die richtige Mischung Viele Fortschritte der vergangenen Jahre folgten einem erkennbaren Muster. Wurden Modelle, Datenmengen und Trainingsaufwand größer, sank der durchschnittliche Vorhersagefehler oft recht regelmäßig. Solche Beobachtungen werden in Skalierungsgesetzen zusammengefasst. Sie beschreiben empirische Zusammenhänge innerhalb bestimmter Modellfamilien und Größenbereiche. Empirisch bedeutet: gemessen, nicht von der Natur garantiert. Ein Skalierungsgesetz sagt nicht, dass jede Fähigkeit gleichmäßig besser wird. Es kann sich ändern, wenn die Architektur, die Datenqualität, das Trainingsverfahren oder die Bewertung wechselt. Vor allem zeigt es nicht, dass eine einzelne falsche Antwort mit wachsender Größe zuverlässig verschwindet. Eine bekannte Versuchsreihe machte deutlich, wie wichtig die Verteilung des Rechenbudgets ist. Das Sprachmodell Chinchilla hatte siebzig Milliarden Parameter, also lernbare Gewichte. Ein früheres Vergleichsmodell hatte zweihundertachtzig Milliarden. Chinchilla wurde mit ungefähr viermal so vielen Daten trainiert und erzielte bei ähnlichem Trainingsaufwand in den berichteten Prüfungen bessere Ergebnisse. Ein kleineres Modell konnte also gewinnen, weil es länger und mit mehr Material lernte. Daraus folgt keine ewige Idealzahl. Die passende Mischung hängt unter anderem von der Güte der Daten, von Wiederholungen, von der Architektur und vom späteren Einsatz ab. Die Lehre ist bescheidener und nützlicher: Wer nur die Parameterzahl vergrößert, kann einen erheblichen Teil des Rechenaufwands verschwenden. Modellgröße, Datenmenge und Trainingsdauer müssen zusammenpassen. Hinzu kommen abnehmende Erträge. Für eine weitere kleine Senkung des Fehlers ist häufig ein vielfach größeres Budget nötig. Das bedeutet nicht, dass Skalierung wirkungslos geworden ist. Eine geringe Verbesserung kann in einem wichtigen Einsatzgebiet sehr wertvoll sein. Sie ist nur nicht kostenlos. Mehr Rechenaufwand kann eine vorhersehbare Verbesserung bringen, ohne zu garantieren, dass das Ergebnis seinen Preis wert ist. Auch die spätere Nutzung gehört in diese Rechnung. Ein kompakteres, gründlicher trainiertes Modell kann über Jahre hinweg bei jeder Anfrage günstiger sein. Wird es jedoch nur selten gebraucht, kann der zusätzliche Trainingsaufwand schwerer wiegen. Die beste Entscheidung hängt deshalb nicht nur vom Trainingstag ab, sondern von der erwarteten Lebensgeschichte des Modells. Wenn Daten unterwegs sind Nehmen wir als grobe Vorstellung ein Modell mit siebzig Milliarden Gewichten. Werden für jedes Gewicht zwei Byte verwendet, belegen allein diese Zahlen ungefähr einhundertvierzig Gigabyte. Zwischenergebnisse, Arbeitsspeicher für laufende Anfragen und die zusätzlichen Trainingszustände sind noch nicht enthalten. Ein einzelner Beschleuniger reicht dann schnell nicht mehr aus. Große Modelle werden deshalb zu verteilten Systemen. Man kann verschiedene Datengruppen, Schichten oder Teile einer Matrix auf mehrere Geräte aufteilen. Diese Geräte müssen Informationen austauschen und sich an bestimmten Stellen abstimmen. Mehr Beschleuniger erhöhen zwar die theoretische Rechenleistung. Zugleich entstehen mehr Verbindungen, mehr Wartepunkte und mehr Möglichkeiten für eine ungleichmäßige Auslastung. Ein ähnliches Gefälle gibt es innerhalb eines Geräts. Direkt an den Recheneinheiten sitzt ein sehr kleiner, sehr schneller Speicher. Daneben gibt es einen größeren Speicher mit hoher Bandbreite, der dennoch weiter entfernt und langsamer ist. Die Kapazität entscheidet, ob die nötigen Daten überhaupt hineinpassen. Die Bandbreite entscheidet, wie schnell sie bereitstehen. Beides wird umgangssprachlich oft einfach Speicher genannt, obwohl es verschiedene Engpässe sind. Eine moderne Verbesserung des Aufmerksamkeitsverfahrens zeigt, wie wichtig diese Wege sind. Sie ordnet dieselbe Rechnung so um, dass weniger Daten aus dem größeren Speicher gelesen und dorthin zurückgeschrieben werden. Einige Zwischenwerte können bei Bedarf neu berechnet werden, statt sie lange aufzubewahren. Dadurch fallen unter Umständen mehr Rechenoperationen an, und trotzdem ist das Ergebnis früher fertig. Dieser scheinbare Widerspruch ist der Schlüssel: Rechnen kann billiger sein als Bewegen. Eine bloße Zahl der Rechenoperationen sagt daher weder die Laufzeit noch den Energiebedarf zuverlässig voraus. Speicherbandbreite, Verbindungen zwischen Geräten, Software und Auslastung sind ebenso Teil der Maschine. Wenn ein schneller Chip auf Daten wartet, ist seine beeindruckende Spitzenleistung für diesen Moment wertlos. Die Arbeit an einer Antwort Nach dem Training werden die Gewichte bei einer normalen Anfrage nicht mehr verändert. Trotzdem durchläuft die Eingabe viele Schichten. Zuerst verarbeitet das Modell die Frage und den bisherigen Gesprächsverlauf. In dieser Eingabephase lassen sich viele Token gleichzeitig bearbeiten. Ein langer Kontext verlängert die Arbeit und belegt zusätzlichen Speicher, noch bevor das erste neue Wort erscheint. Danach beginnt die Ausgabe. Das Modell berechnet eine Verteilung für das nächste Token, wählt eines aus und fügt es dem bisherigen Text hinzu. Erst jetzt kann der nächste Schritt beginnen, denn er hängt vom gerade erzeugten Token ab. Diese serielle Abhängigkeit begrenzt die Geschwindigkeit. Innerhalb eines Schritts lässt sich vieles parallelisieren, die Reihenfolge der Schritte selbst jedoch nicht beliebig überspringen. Damit ältere Teile des Gesprächs nicht in jedem Schritt vollständig neu berechnet werden, bewahrt das System bestimmte Zwischenergebnisse der Aufmerksamkeit auf. Sie werden oft als Schlüssel und Werte beschrieben. Dieser Zwischenspeicher gehört zur aktuellen Textfolge. Er ist weder das Langzeitgedächtnis des Modells noch eine Kopie seiner Trainingsdaten. Mit jedem zusätzlichen Token und mit jeder gleichzeitig laufenden Anfrage wächst er. Der Speicher muss deshalb sorgfältig verteilt werden. Freie Bereiche können in unpassende Stücke zerfallen, obwohl ihre Summe eigentlich groß genug wäre. Gute Verfahren ordnen diese Bereiche flexibel zu und erlauben, mehr Anfragen gemeinsam zu verarbeiten. Durch solche Gruppen kann der Beschleuniger besser ausgelastet werden. Doch auch hier gibt es einen Zielkonflikt. Wer auf eine größere Gruppe von Anfragen wartet, steigert womöglich die Gesamtzahl der Antworten pro Minute, verlängert aber die Wartezeit einer einzelnen Person. Hoher Durchsatz und kurze Verzögerung sind nicht dasselbe. Ein Dienst muss entscheiden, welchen Wert er unter den gegebenen Bedingungen bevorzugt. Die einzelne Antwort kann billig wirken, während der gesamte Betrieb groß wird. Zu jeder Frage kommen Eingabetoken, Ausgabetoken, längere Gespräche, erneute Versuche und manchmal externe Werkzeuge. Das Training verursacht einen konzentrierten Aufwand. Die Nutzung verursacht wiederkehrende Kosten. Was über die gesamte Lebensdauer überwiegt, hängt von Modellgröße, Verkehr, Antwortlänge, Auslastung und Nutzungsdauer ab. Training oder Nutzung pauschal zum größeren Posten zu erklären, wäre irreführend. Mehr Zeit für schwere Fragen Bei schwierigen Aufgaben kann ein System während der Antwort mehr Rechenzeit einsetzen. Es kann einen längeren Lösungsweg entwickeln, einen früheren Schritt überarbeiten, mehrere Vorschläge erzeugen oder einen Prüfer auswählen lassen. Diese zusätzliche Arbeit verändert nicht nachträglich das ursprüngliche Training. Sie erhöht den Aufwand genau in dem Moment, in dem die konkrete Frage bearbeitet wird. Mehr erzeugter Text ist allerdings nicht automatisch mehr Denken. Viele nahezu gleiche Versuche können weniger nützen als eine gezielte Korrektur. Ein Prüfer hilft nur, wenn er gute von schlechten Lösungen tatsächlich unterscheiden kann. Und ein langer Lösungsweg kann einen frühen Fehler immer weiter fortschreiben, statt ihn zu beseitigen. Untersuchungen deuten darauf hin, dass die beste Methode stark von der Schwierigkeit der Aufgabe abhängt. Bei einer einfachen Frage ist ein großes Zusatzbudget oft verschwendet. Bei einer anspruchsvollen Aufgabe können mehrere Ansätze oder eine Überprüfung den Unterschied ausmachen. Sinnvoll wäre daher ein System, das seinen Aufwand an die jeweilige Frage anpasst, anstatt jede Anfrage gleich lange zu bearbeiten. Auch hier nehmen die Erträge ab. Die erste Überprüfung findet vielleicht einen offensichtlichen Fehler. Viele weitere Prüfungen bestätigen womöglich nur dasselbe Ergebnis. Zusätzlicher Rechenaufwand ist damit eine wertvolle Stellschraube, aber kein Wahrheitsautomat. Quellen, ein geeignetes Verfahren und ein überprüfbares Ziel bleiben unverzichtbar. Leistung, Energie und Preis In Gesprächen über den Ressourcenverbrauch werden mehrere Größen leicht vermischt. Elektrische Leistung beschreibt, wie schnell in einem Augenblick Energie umgesetzt wird. Energie ist diese Leistung über eine Zeitspanne hinweg. Ein neuer Beschleuniger kann während des Betriebs mehr Leistung aufnehmen und für dieselbe Aufgabe dennoch weniger Energie benötigen, wenn er erheblich schneller fertig wird. Emissionen sind wieder eine andere Größe. Dieselbe Energiemenge kann je nach Ort, Zeitpunkt und Stromerzeugung mit sehr unterschiedlichen Emissionen verbunden sein. Auch der Preis eines Rechendienstes ist nicht bloß der Strompreis. Er umfasst Hardware, Speicher, Netzwerke, Kühlung, Gebäude, Fachkräfte und bezahlte Kapazität, die nicht ununterbrochen ausgelastet ist. Schon bei einer einzigen Anfrage hängt das Ergebnis davon ab, was mitgezählt wird. Betrachten wir nur den Beschleuniger, solange er Token erzeugt? Oder auch den Hauptprozessor, den Speicher, das Netzwerk, die Kühlung und einen Anteil der gerade wartenden Geräte? Eine Messung aus einem großen kommerziellen Dienst kam bei einer umfassenderen Systemgrenze auf mehr als den doppelten Wert einer engeren Rechnung. Das ist keine allgemeine Konstante für eine Anfrage. Es zeigt vor allem, wie stark die Grenze der Messung das Ergebnis prägt. Auch eine kleine Zahl pro Antwort beantwortet nicht die Frage nach dem Gesamtsystem. Sehr viele kurze Anfragen, längere Kontexte und neue Anwendungen können sich zu einem erheblichen Bedarf addieren. Rechenzentren sind zudem geografisch konzentriert. Eine Belastung kann für ein regionales Stromnetz bedeutsam sein, obwohl ihr Anteil am weltweiten Verbrauch bescheiden aussieht. Umgekehrt darf der gesamte Strombedarf aller Rechenzentren nicht einfach durch eine angenommene Zahl von Fragen geteilt werden. Rechenzentren erledigen zahlreiche andere Aufgaben, und Sprachmodelle unterscheiden sich erheblich in Größe, Auslastung und Antwortlänge. Eine glaubwürdige Zahl braucht deshalb einen klaren Gegenstand: welches Modell, welche Anfrage, welche Hardware, welcher Standort, welcher Zeitraum und welche Systemgrenze. Rechenoperationen, Laufzeit, elektrische Leistung, Energie, Emissionen und Geld beschreiben also verschiedene Seiten derselben Anlage. Sie hängen zusammen, sind aber nicht austauschbar. Wer sie sauber trennt, kann über Kosten und Nutzen sprechen, ohne aus einer einzelnen Messung eine scheinbar universelle Wahrheit zu machen. Genug Rechenaufwand, richtig eingesetzt An vielen Stellen lässt sich der Aufwand verringern. Kleinere Modelle können einfache Aufgaben übernehmen. Bei der Destillation lernt ein kompakteres Modell von einem größeren. Quantisierung speichert Zahlen mit geringerer Genauigkeit, wodurch weniger Speicherplatz und Datenverkehr nötig sind. Je nach Modell und Hardware kann das die Nutzung beschleunigen, doch starke Verringerungen der Genauigkeit können auch die Qualität beeinträchtigen. Andere Architekturen aktivieren für jedes Token nur einen Teil ihrer spezialisierten Modellbereiche. Weitere Verfahren lassen ein kleines Modell mehrere Token vorschlagen und das große Modell diese gemeinsam prüfen. Bessere Speicherverwaltung erhöht die Auslastung, geschicktere Rechenverfahren vermeiden Datenbewegungen, und neue Hardware schafft mehr Arbeit pro eingesetzter Energie. Jede Verbesserung hat Grenzen. Ein Modell mit auswählbaren Experten muss die übrigen Gewichte weiterhin speichern und Daten zum richtigen Teil leiten. Größere Anfragegruppen erhöhen den Durchsatz, können aber die einzelne Antwort verzögern. Geringere Genauigkeit spart Speicher, ist jedoch nicht für jede Aufgabe ohne Verlust geeignet. Wird ein Engpass beseitigt, kann der nächste sichtbar werden. Hinzu kommt ein wirtschaftliches Paradox. Wenn eine Antwort deutlich günstiger wird, muss der Gesamtverbrauch nicht sinken. Niedrige Kosten ermöglichen mehr Nutzer, längere Gespräche, zusätzliche Lösungsvorschläge und Anwendungen, die zuvor zu teuer gewesen wären. Eingesparte Trainingsleistung kann in einen noch größeren Lauf fließen. Effizienz senkt den Aufwand für eine festgelegte Aufgabe. Was insgesamt verbraucht wird, hängt davon ab, wie Nachfrage und Ansprüche darauf reagieren. Damit sind wir wieder bei der kurzen Frage auf dem Bildschirm. Ihre Antwort entsteht aus Gewichten, die durch unzählige Korrekturen gelernt wurden. Sie entsteht aus wiederholter Matrizenrechnung, aus Datenverkehr durch Speicher und Netzwerke und aus technischen Entscheidungen über Genauigkeit, Geschwindigkeit und Auslastung. Nichts daran ist ein einzelner magischer Denkakt. Rechenaufwand ist für die heutigen Verfahren notwendig, aber er reicht nicht aus. Mehr Hardware liefert keine fehlenden Belege, wählt kein sinnvolles Ziel und macht eine ungeeignete Methode nicht passend. Die entscheidende Frage lautet deshalb nicht, wie viel Rechenleistung sich maximal einsetzen lässt. Entscheidend ist, welche Verbindung aus Modell, Daten, Verfahren und Hardware ein gewünschtes Ergebnis zuverlässig erreicht. Genug Rechenaufwand, richtig eingesetzt. Das war's für heute. Das Café ist immer geöffnet. Bis bald. MORE INFORMATION TEXT LICENSE This transcript, description and original Andy's Café editorial text are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). License: https://creativecommons.org/licenses/by/4.0/ Attribution: Andy's Café — https://move37.app/cafe/de/episodes/sunday-latte-why-ai-needs-so-much-compute-de/ Indicate changes when adapting. Identified third-party quotations and linked source material remain under their own terms. AUDIO AND OTHER MATERIAL The composed episode has separate component terms because its piano cues are third-party material. Artwork and the Andy's Café brand are not included in the CC BY licence. Rights map: https://move37.app/cafe/welcome/#reuse Contact: hello@move37.app