Kapitel 9 — Leistung, Skalierung und Kosten

Dies ist Teil 9 einer Serie, die LLM Primer I: How Generative AI Works durchgeht. Gestern sind wir die Anwendungsmuster durchgegangen. Heute sprechen wir darüber, was diese Anwendungen tatsächlich im Betrieb kosten — die operativen Realitäten, die entscheiden, ob ein LLM-Feature ausgeliefert wird oder still im Pilotbetrieb stirbt.

Größer ist nicht immer besser

Die Intuition, dass größere Modelle immer fähiger sind, ist größtenteils richtig — und größtenteils irreführend. Größere Modelle schneiden im Durchschnitt bei den meisten Benchmarks besser ab. Aber die Gewinne schrumpfen, wenn die Modellgröße wächst. Ein Modell mit doppelt so vielen Parametern ist selten doppelt so gut. Oft ist es nur geringfügig besser, kostet aber mehrfach mehr im Betrieb.

Für viele reale Anwendungen schlägt ein kleineres Modell mit gutem Prompting, gutem Retrieval und guter Evaluation ein größeres Modell, das in eine weniger gut ingenieurmäßig gestaltete Pipeline gelegt wurde. Das ist die wichtigste praktische Erkenntnis in Kapitel 9, und das Buch verteidigt sie sorgfältig, weil sie gegen die Marketing-Erzählung jedes Frontier-Labors geht.

Latenz und Throughput ziehen in entgegengesetzte Richtungen

Zwei Metriken dominieren den LLM-Betrieb. Latenz ist die Zeit von der Anfrage bis zur ersten Antwort. Throughput ist, wie viele Anfragen pro Sekunde das System verarbeiten kann.

Der Trade-off zwischen ihnen ist strukturell. Um hohen Throughput zu bekommen, batcht du Anfragen — du lässt viele parallel durch die GPU laufen. Um niedrige Latenz zu bekommen, bearbeitest du jede Anfrage individuell, sobald sie eintrifft. Wähle eines, und du opferst das andere.

Die meisten realen Systeme landen irgendwo dazwischen mit einer Technik namens kontinuierlichem Batching, die neue Anfragen zu einem bereits laufenden Batch hinzufügt. Streaming-Generierung — Tokens an den Nutzer zurückzugeben, während sie produziert werden, statt auf die volle Antwort zu warten — hilft der wahrgenommenen Latenz, selbst wenn die tatsächliche Generierungszeit unverändert ist. Das Buch geht durch, welche Designentscheidungen für welche Produktarten angemessen sind.

Die echte Kostengleichung

Ein LLM zu betreiben ist nicht wie normale Software zu betreiben, und eine der teuersten Lektionen beim Deployment von KI ist, das auf die harte Tour zu lernen. Bei traditioneller Software sind zusätzliche Nutzer nahezu kostenlos, sobald du das System gebaut hast; der Server läuft, ob ihn ein oder tausend Nutzer ansprechen. Bei einem LLM kostet jede Anfrage echte Rechenleistung. Die Kosten skalieren linear mit der Nutzung.

Die dominanten Kostentreiber sind leicht aufzuzählen. Längere Eingaben kosten mehr (die Attention-Berechnung skaliert mit der Eingabelänge). Längere Ausgaben kosten mehr (jeder Output-Token erfordert einen weiteren Forward-Pass durch das Modell). Größere Modelle kosten mehr (mehr Parameter bedeuten mehr FLOPs pro Token). Reasoning-Modelle kosten mehr (sie erzeugen viele Zwischen-Tokens vor der finalen Antwort). Diese addieren sich nicht; sie multiplizieren sich.

Das Buch enthält eine ausgearbeitete Kostenbeispiel-Tabelle, die zeigt, wie sich die monatliche Rechnung einer Anwendung über realistische Szenarien ändert — kleiner Chatbot, Mid-Tier-RAG, agentisches System mit Reasoning. Die exakten Zahlen bewegen sich; die Form der Kurve ist beständig.

Quantisierung, in einfacher Sprache

Einer der mächtigsten Engineering-Tricks zur Kostensenkung ist Quantisierung. Die Parameter des Modells werden normalerweise als Fließkommazahlen gespeichert — oft mit 16-Bit- oder 32-Bit-Präzision. Quantisierung speichert sie mit weniger Präzision, oft 8 Bit oder sogar 4 Bit pro Zahl, mit sorgfältig gewählten Skalierungsfaktoren, die den Informationsverlust begrenzen.

Der Effekt ist dramatisch. Ein quantisiertes Modell verbraucht viel weniger Speicher, was bedeutet, dass es auf kleinerer Hardware Platz findet und schneller läuft (weil Speicherbandbreite und nicht rohe Rechenleistung oft der Engpass ist). Der Qualitätsverlust ist klein, wenn es gut gemacht wird — typischerweise ein paar Prozentpunkte bei Benchmarks, manchmal in der Praxis nicht wahrnehmbar.

Mehrere verwandte Techniken — Pruning, Distillation, Sparsity — treiben die Effizienz weiter. Distillation ist insbesondere, wie du ein kleines Modell bekommst, das ein viel größeres imitiert. Das Buch behandelt jede Technik und wann jede angemessen ist.

Edge- und On-Device-Deployment

Die meisten LLMs in Produktion laufen in Cloud-Datenzentren. Manche Anwendungen können das nicht. Echtzeit-Sprachassistenten, Anwendungen mit harten Datenschutzanforderungen, Geräte, die ohne Netzwerkverbindung funktionieren müssen — diese profitieren davon, ein Modell direkt auf der Hardware des Nutzers laufen zu lassen.

Edge-Deployment ist eine eigene Engineering-Disziplin. Speicher ist begrenzt. Energie ist kostbar. Die verfügbare Rechenleistung ist weit kleiner als die eines Datenzentrums. Das Buch geht durch, wie schwere Kompression, sorgfältige Modellauswahl und hybride Architekturen (kleines lokales Modell für Routinearbeit, Cloud-Modell für schwierige Fälle) das möglich machen.

Was Kapitel 9 vorbereitet

Am Ende von Kapitel 9 kannst du die Kosten und Leistung jeder vorgeschlagenen LLM-Anwendung modellieren, bevor du sie baust. Du weißt, welche Designentscheidungen am meisten für die Kosten zählen, welche für die Latenz und welche Trade-offs verhandelbar gegenüber fundamental sind. Du kannst Anbieter-Preisseiten lesen und verstehen, wofür tatsächlich abgerechnet wird.

Das bereitet die natürliche nächste Frage vor — sobald du ein System im großen Maßstab betreiben kannst, wie stellst du sicher, dass du es tun solltest?

Als Nächstes — Kapitel 10: Sicherheit, Ethik und Vertrauen. Morgen schauen wir auf Halluzinationen, Bias, Prompt-Sicherheit, Erklärbarkeit und die Governance-Frameworks, die LLM-Anwendungen in verantwortungsvolle Produkte verwandeln. Einschließlich der Kontrollen, die hochriskante Deployments tatsächlich einsetzen.