Kategorie: Erklärer

Wie zeigt man, dass man eine Graphenfärbung kennt, ohne sie zu verraten? Ein Zero-Knowledge-Beweis macht das möglich. Der Autor erklärt das Konzept anhand der 3-Färbung von Graphen. Sein Interesse galt nicht Kryptowährungen, sondern einer Variante, die ein Freund ihm zeigte – sie basiert auf Graphentheorie und ist in wenigen Zeilen implementierbar.

Was ist ein Zero-Knowledge-Beweis?

Ein Zero-Knowledge-Beweis ist ein interaktives Protokoll. Zwei Parteien sind beteiligt: der Beweiser und der Verifizierer. Der Beweiser will den Verifizierer überzeugen, dass er eine Lösung für ein schwieriges Problem hat, ohne auch nur die kleinste Information darüber preiszugeben. Das klingt paradox, ist es aber nicht. Das Standardbeispiel ist die Drei-Färbung eines Graphen. Dabei bekommt jeder Knoten eine von drei Farben, und benachbarte Knoten dürfen nicht dieselbe Farbe haben. Ein Graph besteht aus Knoten und Kanten, die sie verbinden. Die 3-Färbung ist NP-vollständig: Es ist schwer, eine Färbung zu finden, aber leicht, sie zu prüfen – man geht alle Kanten durch und kontrolliert, ob die Endknoten unterschiedlich gefärbt sind. Diese Asymmetrie nutzen Zero-Knowledge-Beweise aus.

Das interaktive Protokoll für die 3-Färbung

Das Protokoll stammt von Goldreich, Micali und Wigderson. Es läuft in mehreren Runden ab, jede mit vier Schritten. Zuerst permutiert der Beweiser die drei Farben zufällig. Die Farben sind nur Platzhalter – wichtig ist nur, dass sie verschieden sind. Er wendet die Permutation auf seine ursprüngliche Färbung an, die damit gültig bleibt. Dann verschlüsselt er jede Farbe mit einem zufälligen Nonce und berechnet einen Hash. Die Hashes schickt er als ‚verschlossene Boxen‘ an den Verifizierer. Ohne Nonce sind die Hashes nicht umkehrbar, also erfährt der Verifizierer nichts. Der Verifizierer wählt zufällig eine Kante aus und teilt sie dem Beweiser mit. Dieser öffnet die zwei Boxen für die Endknoten und schickt Farben und Nonces. Der Verifizierer prüft zwei Dinge: Passen die Hashes zu den Werten, und sind die Farben verschieden? Wenn ja, ist die Runde erfolgreich. Wenn nein, bricht er ab – der Beweiser hat betrogen.

Man kann sich das wie versiegelte Umschläge vorstellen. Der Beweiser legt in jeden Umschlag eine Farbe und einen Geheimcode und klebt ihn zu. Der Verifizierer sieht nur die Umschläge. Er wählt eine Kante aus, also zwei verbundene Knoten, und der Beweiser öffnet die zwei Umschläge. So bekommt der Verifizierer nur die Information über diese eine Kante – und die ist korrekt, wenn der Beweiser eine gültige Färbung hat.

Warum viele Runden nötig sind

Eine einzelne Runde gibt nur geringe Sicherheit. Der Beweiser könnte eine Färbung haben, die nur auf einer Kante stimmt, und hoffen, dass diese nicht abgefragt wird. Deshalb wiederholt man das Protokoll viele Male. Der Autor gibt die Formel (1 – m^{-1})^(m^2) an, wobei m die Anzahl der Kanten ist. Je mehr Runden, desto kleiner die Chance für einen Betrüger. Bei 1000 Kanten liegt die Wahrscheinlichkeit nach 4600 Runden bei etwa einem Prozent, nach 10.000 Runden bei 0,0045 Prozent. Mit m² Runden, wie im Paper vorgeschlagen, ist sie praktisch null. Die Wiederholungen kosten Zeit, machen das Verfahren aber mathematisch wasserdicht – vorausgesetzt, die Zufallszahlen sind wirklich zufällig und die Hashfunktion kryptografisch stark.

Implementierung und praktische Überlegungen

Der Autor hat mit seinem Freund Chris eine Python-Implementierung geschrieben, die das Protokoll in einem Prozess nachbildet. Für das Verständnis reicht das, aber für echte Sicherheit sind Details wichtig. Man sollte nicht die eingebaute hash-Funktion verwenden, sondern eine kryptografische wie SHA-256. Die Nonces brauchen einen sicheren Zufallsgenerator, etwa aus dem secrets-Modul. Für reproduzierbare Tests kann man random.seed(0) setzen, aber in der Praxis wäre das fatal. Um die Trennung von Beweiser und Verifizierer zu zeigen, gibt es auch eine Netzwerk-Demo: Ein Server ist der Beweiser, ein Client der Verifizierer. So läuft die Kommunikation über echte Netzwerkpakete, was die Geheimhaltung besser demonstriert.

Von der Graphenfärbung zu anderen Problemen

Die Graphenfärbung ist kein theoretisches Spielzeug. Jedes NP-vollständige Problem lässt sich auf sie reduzieren. Eine Lösung für ein solches Problem kann man in eine 3-Färbung umwandeln und dann das Zero-Knowledge-Protokoll anwenden. Sudoku ist ein Beispiel: Ein gelöstes Sudoku lässt sich als Graphenfärbung interpretieren, und man könnte einen Zero-Knowledge-Beweis führen, ohne die Lösung zu zeigen. In der Praxis ist die Reduktion oft ineffizient. Bei der Primfaktorzerlegung würde der Graph zu groß, das Verfahren wird unpraktikabel. In der Praxis nutzt man andere Techniken, etwa elliptische Kurven, aber das Grundprinzip bleibt.

Grenzen und Einordnung

Der Autor interessiert sich nicht für Altersverifikation oder Blockchain. Ihm geht es um die theoretische Schönheit. Zero-Knowledge-Beweise sind ein Werkzeug der Kryptographie, das auf einfachen Ideen der Graphentheorie beruht. Die 3-Färbung ist ein lehrreiches Beispiel, weil sie das Prinzip zeigt, ohne tief in die Mathematik einzusteigen. Auch wenn die direkte Umsetzung für praktische Probleme zu aufwendig ist, zeigt das Beispiel, wie man mit einfachen Mitteln Vertrauen aufbaut – ohne Geheimnisse preiszugeben. Es verbindet Einfachheit und Tiefe und ist daher für jeden interessant, der verstehen will, wie moderne Kryptographie funktioniert.

Quelle: bernsteinbear.com

Die gängige Erzählung sieht KI-Infrastruktur als GPUs, Netzwerk und High-Bandwidth-Memory. Speicher gilt als Beiwerk, als Ablage für kalte Daten. Doch Inferenz – der Betrieb von KI-Modellen – ist längst ein Problem der Zustandsverwaltung. Speicher ist der Ort, an dem dieser Zustand lebt. Die Preise für KI-API-Aufrufe zeigen das.

Der teuerste Prozessor im Rechenzentrum wartet auf Bytes

Eine Tatsache wird selten genannt: Während der Textgenerierung rechnet eine GPU die meiste Zeit nicht. Um ein einziges Token auszugeben, muss sie sämtliche Modellgewichte und den kompletten KV-Cache der Sitzung aus dem Speicher streamen. Bei einem 70-Milliarden-Parameter-Modell sind das weit über 100 Gigabyte pro Schritt. Die Arithmetik wartet auf die Daten, nicht umgekehrt. Das Missverhältnis ist quantifizierbar: Bei Batch-Größe eins führt eine Dekodierung ungefähr zwei FLOPs pro gelesenem Byte aus, während ein moderner Beschleuniger auf 300 bis 600 FLOPs pro Byte Speicherbandbreite ausgelegt ist. Die Recheneinheiten bleiben strukturell zu über 99 Prozent untätig, wenn man sie nicht mit großen Batches füllt. Die Batch-Größe ist wiederum dadurch begrenzt, wie viel KV-Cache in den Speicher passt. Speicherkapazität, nicht Rechenleistung, bestimmt also zunehmend die Kosten pro Token.

Die Gewichte selbst sind die am häufigsten bewegten Bytes im Rechenzentrum: Ein 140-Gigabyte-Modell wird bei voller HBM-Bandbreite etwa 24 Mal pro Sekunde komplett gelesen. Das sind rund zwei Millionen komplette Durchläufe pro Tag und Serving-Instanz. Penguin Solutions beziffert den resultierenden Aufwand auf rund 30 Prozent Rechnen und 70 Prozent Speicherzugriff. Die Infrastruktur für KI hat vier Ebenen – Rechnen, Speicher, Netzwerk und Storage. Die letzten drei sind im Kern Varianten desselben Problems: Wie schnell können wir Bytes zur Arithmetik bringen? Das Training hat darauf mit HBM und NVLink geantwortet. Die Branche hielt das für eine dauerhafte Lösung. Aber Inferenz bewegt andere Bytes – Kontext, Gewichte, Adapter, Einbettungen –, und diese Bytes überleben den einzelnen Request. Zustand, der Bestand hat, muss irgendwo landen. Jede Ebene, auf der er landen kann, tauscht Latenz gegen Kapazität und Kosten. Deshalb wird die Optimierung von Inferenz zunehmend zu einer Frage des Speicherhierarchie-Designs, nicht des FLOPs-Einkaufs. Der unterste Teil der Hierarchie, der Storage, ist kein passives Archiv mehr, sondern ein aktiver Teilnehmer am Serving-Prozess.

Folge dem Geld: NAND-Flash explodiert, HBM ist Nebenschauplatz

Beinahe die gesamte Berichterstattung über KI-Speicher dreht sich um HBM. Optimistische Prognosen bezifferten den Markt für 2026 auf rund 55 Milliarden Dollar – bevor es in diesem Jahr zu einer Neubewertung kam. NAND-Flash dagegen, über das fast niemand schreibt, ist 2026 ein Markt von 270,6 Milliarden Dollar und soll 2027 auf 379 Milliarden Dollar wachsen (TrendForce, Mai 2026). Zum Vergleich: Die gesamte Festplattenindustrie erwirtschaftet in einem Jahr weniger Umsatz (rund 23 Milliarden Dollar) als die fünf größten NAND-Anbieter in einem einzigen Quartal (38,9 Milliarden Dollar). Storage blieb außen vor in der KI-Erzählung, weil die Serving-Story das erlaubte: Wenn Inferenz nichts behält, dann ist Storage nur der Ort, an dem kalte Daten billig abgelegt werden. Die letzten achtzehn Monate haben diese Prämisse stillschweigend widerlegt.

Training ist ein gelöstes Problem – Inferenz nicht mehr

Die Trainingsseite war nie leichtgewichtig, aber sie war ein Batch-Problem. Der MLPerf-Checkpoint-Benchmark nennt konkrete Zahlen: Ein 70-Milliarden-Parameter-Modell schreibt einen Checkpoint von 912 Gigabyte, ein 1-Billionen-Modell 15 Terabyte. Die Häufigkeit skaliert mit der Ausfallrate – Metas Llama-3-Lauf verzeichnete 419 Unterbrechungen in 54 Tagen auf 16.000 GPUs. Bei 100.000 Beschleunigern ergibt sich rechnerisch ein Checkpoint alle 90 Sekunden, der in unter fünf Sekunden geschrieben werden muss: ein Burst von rund 3,6 Terabyte pro Sekunde. DeepSeek hat die dafür gebaute Software offengelegt – 3FS, ein Flash-natives Dateisystem mit 6,6 TiB/s aggregiertem Lesedurchsatz. Aber Checkpoints sind periodisch, sequentiell und vorhersehbar: eine gelöste Problemklasse. Was sich 2025 und 2026 geändert hat, ist die andere Seite: Serving ist nicht mehr zustandslos.

Der Zustand, der die Annahme zerstört hat, ist der KV-Cache. Wenn ein Modell deinen Kontext liest, baut es ein Notizbuch aus Zwischenergebnissen auf – Aufmerksamkeits-Keys und -Values für jedes Token. So muss jedes neue Wort nur die Notizen konsultieren, statt den Rohtext erneut zu lesen. Wirft man das Notizbuch weg, muss das Modell die gesamte Konversation von vorne verarbeiten, bevor es etwas sagen kann. Dieses Notizbuch ist groß: Bei einem 70-Milliarden-Parameter-Modell sind es etwa 0,33 Megabyte pro Token. Eine Sitzung mit 128.000 Token trägt also rund 42 Gigabyte Zustand, zusätzlich zu den etwa 140 Gigabyte Modellgewichten. Vier gleichzeitige lange Sitzungen übersteigen den HBM-Speicher jeder bisher ausgelieferten GPU. Konkurrenz multipliziert das ohne Grenzen: Die Arithmetik von VAST Data für einen Dienst in Verbrauchergröße setzt 100.000 gleichzeitige Nutzer bei rund 45 Petabyte gespeichertem Kontext an – drei Größenordnungen jenseits dessen, was HBM und DRAM fassen können. Solidigms Formulierung trifft es: Ein Inferenzdienst wird speicherlimitiert, lange bevor er rechnenlimitiert wird.

Der KV-Cache ist nur das lauteste Mitglied eines wachsenden Inventars. Modellgewichte sind inzwischen heiße Storage-Objekte – DeepSeek-V3 hat 688 Gigabyte auf der Platte, und Serving-Flotten verschieben sie ständig. LoRA-Adapter, jeweils ein paar hundert Megabyte, werden pro Anfrage zu Tausenden getauscht. Agentengedächtnis überdauert Sitzungen per Design. Jedes einzelne Element ist klein neben einem Checkpoint; zusammen, multipliziert mit Nutzern, sind sie die größte neue Datenkategorie im Rechenzentrum.

Agenten und multimodale Inhalte treiben den Speicherbedarf

Agenten haben den Kontext von einer Kostenposition pro Anfrage in ein dauerhaftes Asset verwandelt. Die besten öffentlichen Trace-Daten stammen von LMCache, das 739 echte Claude-Code-Sitzungen repliziert hat: Im Durchschnitt wächst der Kontext einer Sitzung innerhalb einer einstündigen Konversation von etwa 20.000 auf 115.000 Eingabe-Token – eine 5,7-fache Inflation, die bei jeder Runde erneut gesendet wird, wobei 97 Prozent wiederverwendbarer Präfix sind. Bei 70-Milliarden-Parameter-Dichte entspricht das einer Sitzung mit etwa 7 Gigabyte Zustand am Anfang und 38 Gigabyte am Ende. Nun skaliere das: Reasoning- und Tool-Nutzungs-Modelle sind 2025 auf OpenRouter von vernachlässigbar auf mehr als die Hälfte aller Token gestiegen. Kioxia nennt agentische KI inzwischen den „primären Wachstumstreiber für die NAND-Nachfrageexpansion“. Eine Sitzung, die eine Stunde lebt, pausiert und am nächsten Tag fortgesetzt wird, ist kein Problem von DRAM-Caches. Sie ist ein Storage-Problem.

Multimodale Generierung verstärkt den Speicherbedarf von der Ausgabeseite her. Jedes erzeugte Video, Bild und Audio-Clip wird in dem Moment zu einem dauerhaften Asset. Die Fallstudien von Western Digital zeigen, dass jedes KI-generierte Video mindestens siebenmal über Plattformen hinweg gespeichert wird: am Erstellungsort, in den Kopien des Kreativen und auf jedem sozialen Netzwerk, auf dem es geteilt wird. WDs Zusammenfassung ist der strukturelle Punkt dieses gesamten Artikels: Speicherbedarf ist kumulativ und persistent, anders als Rechenbedarf. Diese Asymmetrie ist unterpreist – Rechenbedarf kann über Nacht durch einen einzigen Effizienzdurchbruch fallen; gespeicherte Bytes akkumulieren sich nie zurück. Eine GPU erledigt ihren Job und zieht weiter. Die Bytes bleiben.

Die Preismechanik: Warum Caching auf Flash die Rechnung kippt

Hier ist der Mechanismus in einem Satz: Kontext, den das Modell bereits gesehen hat, wiederzuverwenden bedeutet normalerweise, den vollen Rechenaufwand fürs erneute Lesen zu zahlen. Es sei denn, das Notizbuch wurde gespeichert – dann zahlst du einen Plattenzugriff. Die Preistabellen quantifizieren den Unterschied: Gecachte Eingabe-Token kosten bei OpenAI, Anthropic und Google rund 10 Prozent des frischen Preises, bei DeepSeek rund 1 Prozent. Dessen Cache liegt seit 2024 auf der Platte. Die Hersteller-Benchmarks, alle selbst durchgeführt, weisen in dieselbe Richtung: WEKA berichtet 20-mal schnellere Time-to-First-Token bei 128.000 Kontext durch Flash-residenten Cache. Mooncake, die Architektur hinter Kimi, berichtet 75 Prozent mehr bearbeitete Anfragen auf denselben GPUs durch Pooling von Cache über DRAM und SSD. Einen langen Präfix zu speichern kostet Cent pro Monat; ihn neu zu berechnen kostet jedes Mal dieselben Dollar. Sobald Kontext wiederverwendet wird – und Agenten garantieren Wiederverwendung – gewinnt Flash die Arithmetik.

Machen wir es konkret. Ein Präfix von 50.000 Token – ein Systemprompt plus Codebasis oder der gesammelte Arbeitskontext eines Agenten – trägt rund 16,5 Gigabyte KV-Zustand bei einem 70-Milliarden-Parameter-Modell. Das erneute Lesen kostet etwa 0,25 Dollar bei den üblichen Frischpreisen – jedes einzelne Mal. Das Speichern kostet ungefähr 1,32 Dollar pro Monat bei normalen Cloud-Block-Storage-Tarifen, und das Zurückspielen kostet etwa 0,025 Dollar pro Wiederverwendung zu Cache-Preisen. Die Ersparnis ist kein Rabatt, sondern eine Verschiebung von Rechenaufwand zu Speicherkosten. Und weil die Kosten pro Token sinken, können Anbieter größere Kontexte und längere Agentenläufe anbieten, was wiederum mehr Zustand erzeugt – eine positive Rückkopplung, die Speicher zum strategischen Engpass macht.

Was das für dich bedeutet: Speicher wird zum Differenzierungsmerkmal

Die Grenze zwischen Rechnen und Speichern verschwimmt. Das hat praktische Konsequenzen. Wer ein KI-Produkt betreibt, sollte nicht mehr nur GPUs budgetieren, sondern auch Storage-Kapazität und -Latenz. Die nächste Welle von Optimierungen wird nicht darin bestehen, mehr Chips zu kaufen, sondern darin, den Zustand intelligenter zu verteilen – vom HBM über DRAM, SSD bis hin zu Objektspeichern. Anbieter wie DeepSeek zeigen, dass radikale Kostenreduktion über Flash-Caching möglich ist. Etablierte Hyperscaler ziehen nach. Für Entwickler bedeutet das: Caching-APIs sind kein nettes Extra, sondern ein Kernbestandteil der Kostenkontrolle. Wer den KV-Cache ignoriert, bezahlt am Ende für jeden Token die teure Neuberechnung. Die Speicherhierarchie ist keine statische Gegebenheit, sondern ein Stellhebel für Wirtschaftlichkeit. Rechnen ist billig, aber Erinnern ist noch billiger – und Erinnern braucht Speicher.

Quelle: datagravity.dev

Geoffrey Litt, Design Engineer bei Notion, sitzt vor einem Berg von Code-Diffs. Sein KI-Agent schreibt täglich neue Funktionen, refaktoriert Module und migriert Frameworks. Der Output ist beeindruckend, aber Litt überkommt ein ungutes Gefühl. Er scrollt durch die Änderungen und merkt: Er versteht nur noch die Hälfte davon. Vielen Entwicklern geht es ähnlich. Der Flaschenhals der Softwareentwicklung ist nicht mehr die Fähigkeit der Maschinen, Code zu produzieren. Der Engpass liegt woanders: zu verstehen, was dieser Code tut.

In seinem Vortrag stellt Litt die These auf: Verständnis ist der neue Engpass. Während KI-Agenten mehr Code schreiben, wächst die Kluft zwischen dem, was produziert wird, und dem, was Menschen geistig nachvollziehen können. Die naheliegende Antwort – mehr Vertrauen, weniger Kontrolle – hält er für falsch. Stattdessen schlägt er Techniken vor, die menschliches Verständnis in den KI-Entwicklungsprozess integrieren. Es geht nicht darum, jeden Diff zu lesen. Es geht darum, als Mensch aktiv am kreativen Prozess beteiligt zu bleiben.

Warum Verstehen mehr ist als bloßes Kontrollieren

Die erste intuitive Antwort: Wir verstehen Code, um ihn zu verifizieren. Wir prüfen, ob die Arbeit des Agenten korrekt ist, ob sie der Spezifikation entspricht und ob die Architektur sauber bleibt. Das ist ein Daumen-hoch-oder-Daumen-runter-Spiel. Doch Litt weist darauf hin, dass dieses Argument schwächer wird. KI-Agenten werden besser darin, ihre eigene Arbeit zu prüfen und Fehler zu finden. Das ist gut – niemand will einen Agenten, der Unsinn produziert. Aber wenn die Maschinen ihre Arbeit selbst verifizieren können, wo bleibt dann der Mensch?

Litts Antwort ist anders: Wir verstehen nicht nur, um zu kontrollieren, sondern um zu partizipieren. Ein Projekt ist nie nur eine Schleife aus Prompt und Ergebnis. Es besteht aus vielen iterativen Zyklen, in denen Mensch und Agent zusammenarbeiten. Verständnis ist entscheidend, weil die Konzepte, die du im Kopf hast, die Basis für deine nächste kreative Idee sind. Wenn du nicht fließend mit den Bausteinen des Systems denken kannst, fehlt dir die Basis, um das Projekt sinnvoll weiterzuentwickeln. Deine Fähigkeit, als aktiver Teilnehmer am Gestaltungsprozess aufzutreten, hängt direkt davon ab, wie gut du das System verstehst.

Das Phänomen hat einen Namen. Margaret Storey und Simon Willison prägten den Begriff der kognitiven Schulden. Wie bei technischen Schulden profitierst du eine Weile davon, Dinge nicht zu verstehen. Aber irgendwann holt es dich ein. Wenn Entwicklungsteams den Überblick verlieren, was ihre KI-Agenten tun, entsteht ein stiller Prozess: Der Code wächst, das Verständnis der Menschen wächst nicht mit. Und dann bricht es zusammen.

Erklärungen als erstes Werkzeug gegen die Verständnislücke

Litt hat praktische Antworten auf die wachsende Verständnislücke. Sein erster Ansatzpunkt sind Erklärungen. Wenn ein Agent eine Aufgabe abgeschlossen hat, entsteht natürliches Rohmaterial: ein Code-Diff. Die einfache Methode ist, diesen Diff zu lesen. Aber ist das die beste Art, Verständnis aufzubauen? Litt stellt eine andere Frage: Wie würde die beste Erklärung aussehen? Wenn ein Team – menschlich oder künstlich – Wert darauf legt, etwas gut zu erklären, wie sähe das Ergebnis aus?

Aus dieser Überlegung heraus hat Litt /explain-diff entwickelt. Das Tool erstellt strukturierte Code-Erklärungen als HTML, Markdown oder Notion-Dokumente. Das Prinzip folgt guter Pädagogik. Bevor der veränderte Code gezeigt wird, erklärt die Erklärung den Hintergrund. Am Beispiel eines Videospiels, das die Perspektive wechselt, zeigt Litt, wie das funktioniert: Das Dokument lehrt zuerst die Grundlagen der Spiel-Engine, erläutert Konzepte wie isometrische Projektion und baut so Intuition auf. Erst danach folgt der Code. Entscheidend ist: Intuition vor Details. Anstatt dich mit einer alphabetischen Liste geänderter Dateien zu konfrontieren, bekommst du eine Erzählung. Der Diff wird zu Prosa, die in logischer Reihenfolge durch die Änderungen führt.

Diese Erklärung erreicht ein Ziel. Sie holt dich auf den aktuellen Stand. Du bist nicht mehr derjenige, der hinterherhinkt, sondern gleichwertiger Partner im Gespräch über den Code. Litt setzt zusätzlich auf interaktive Elemente. In manchen Erklärungen kann man direkt in der Seite herumspielen – zum Beispiel Steine in einem isometrischen Garten verschieben und beobachten, wie sich die Koordinaten ändern. So entsteht Verständnis, das über bloßes Lesen hinausgeht.

Quizze als Temporegler für menschliches Verständnis

Eine gute Erklärung allein reicht nicht. Am Ende jedes Explainers wartet ein interaktives Quiz. Fünf Fragen über die Änderungen, die Litt beantworten muss, bevor er zufrieden ist. Seine Regel ist streng: Er schickt keinen Code an andere weiter, bis er das Quiz bestanden hat. Dasselbe Prinzip gilt beim Review des Codes seiner Kollegen. Das mag streng klingen, aber Litt hat gute Gründe.

Das Quiz wirkt als Geschwindigkeitsregler in der KI-Schleife. Mit KI-Agenten passiert es leicht, dass der Entwicklungszyklus schneller läuft als das menschliche Verständnis. Der Agent produziert, der Mensch nickt ab, und irgendwann ist das System ein Fremdkörper. Das Quiz ist die Gegenkraft. Es zwingt dich, die Frage zu beantworten: Verstehe ich das wirklich? Diese Selbstprüfung ist der Schlüssel, um ein vollwertiger kreativer Teilnehmer zu bleiben – nicht nur ein Passagier im eigenen Projekt.

Was für einzelne Entwickler funktioniert, lässt sich auf Teams übertragen. Stellen wir uns vor, jedes Review beginnt mit einer kurzen Wissensabfrage. Das klingt nach Bürokratie, ist aber ein effizienter Weg, um sicherzustellen, dass alle Teammitglieder das gleiche Verständnis haben. Die Zeit für das Quiz spart später viel Verwirrung und Missverständnisse.

Mikrowelten: Spielerisch Systeme begreifen

Die zweite Technik sind Mikrowelten. Litt bezieht sich auf eine Idee des Pädagogen Seymour Papert, der von einem Leben in Mathematikland träumte. Wenn man Französisch lernen will, zieht man nach Frankreich. Also: Wer Mathematik lernen will, sollte in einer Umgebung leben, in der mathematisches Verständnis natürlich wächst. Papert wollte Umgebungen bauen, in denen Kinder Mathematik aus Neugier lernen – ungezwungen und intrinsisch motiviert. Litt überträgt diese Idee auf Code. Kann man Welten bauen, die du bewohnst und in denen du natürlich verstehst, wie ein System funktioniert und wie es sich verändert?

Ein Beispiel: Litt entwickelte letztes Jahr einen Prolog-Interpreter. Während der Arbeit merkte er, dass er Schwierigkeiten hatte, zu verstehen, was im Inneren der Logiksprache passiert. Also bat er seinen Agenten, einen Debugger zu bauen. Das Ergebnis war ein Werkzeug, mit dem er durch die Ausführung seiner Sprache schritt – durch die Zeit scrollte, den Stack inspizierte und sehen konnte, welche Regeln bei jedem Schritt ausgewertet wurden. Sogar Kommentare konnte er hinterlassen. Der Unterschied zwischen einem Tool, das der Agent für dich baut, und einem, das du selbst benutzt, ist groß. Indem du selbst durch den Prozess schrittst, baust du nebenbei Verständnis auf. Du beobachtest nicht nur das Ergebnis, sondern erlebst den Ablauf.

Ein zweites Beispiel. Litt musste seine Website von einem Framework auf ein anderes migrieren. Sein Agent schrieb ein Skript, das das automatisch erledigte. Aber das Review war schwierig – Litt kannte das neue Framework nicht gut und konnte nur sagen: Sieht ungefähr richtig aus. Statt sich mit diesem vagen Gefühl zu begnügen, bat er seinen Agenten, ein Videospiel zu bauen: eine Kommandozentrale, in der er die Migration selbst durchführt, Schritt für Schritt. Die UI zeigte ihm Buttons, um die Migration Teilschritt für Teilschritt auszuführen, während alte und neue Website nebeneinander live liefen. So schaute Litt zu, wie die neue Seite Stück für Stück entstand. Am Ende hatte er ein ähnliches Verständnis, als hätte er alles von Hand gemacht – aber schneller, weil die Erfahrung für ihn aufbereitet war. Der Kern: Agenten können Code schreiben, um Menschen zu helfen, anderen Code zu verstehen.

Gemeinsame Räume: Verständnis im Team entwickeln

Bisher ging es um individuelles Verständnis. Aber die wenigsten arbeiten allein. Litts dritte Technik zielt auf gemeinsame Räume. Wenn mehrere Personen eine gemeinsame Vorstellung des Systems teilen, kommunizieren sie effizient. Ein geteilter Wortschatz ruft dieselben Bilder hervor – das ermöglicht schnelles, kreatives Denken. Ohne diese geteilten Strukturen sind Gespräche über Code und Architektur mühsamer.

Litt mag Umgebungen, in denen Teams gemeinsam Verständnis aufbauen. Als Mitarbeiter von Notion nennt er ein Beispiel: Claude- und Cursor-Agenten laufen inzwischen direkt in Notion-Dokumenten. Wenn diese Agenten einen technischen Plan erstellen, geschieht das in einer kollaborativen Seite. Das Team kann sofort kommentieren und diskutieren. Verständnis entsteht nicht mehr in Silos, sondern im gemeinsamen Raum. Das ist die Weiterentwicklung der Idee: Denken zusammen statt allein.

Das geht über Code hinaus. Laut Litt war es schon immer wichtig für Menschen zu verstehen, wie die Dinge funktionieren. Nicht nur, um Ergebnisse zu verifizieren, sondern um aktiv mitzugestalten. Die Idee ist alt. Vor fast fünfzig Jahren hatte Alan Kay die Vision, dass Computer ein neues Medium sein könnten – besser als Bücher –, um Menschen, insbesondere Kindern, beizubringen, wie man über die Welt denkt. Auf den ersten Blick sah es so aus, als würden Kinder auf einem Tablet Videos schauen. Tatsächlich spielten sie ein interaktives Spiel und bearbeiteten dabei den Code, um die Physik besser zu verstehen. Schon damals war die Idee klar: Nicht nur automatisieren, sondern den Menschen erweitern.

Litt endet mit einer optimistischen Perspektive. KI macht es zugänglich, Simulationen zu erstellen, die uns Dinge beibringen. Diese Technik demokratisiert Bildung und Verständnis. Das ist eine große Möglichkeit, die das Computing eröffnet. Die Werkzeuge, die Litt und andere entwickeln, zielen nicht darauf ab, den Menschen aus der Schleife zu nehmen. Sie versuchen das Gegenteil: uns tiefer in den Prozess zu integrieren. Durch Erklärungen, Quizze, Mikrowelten und gemeinsame Räume wird Verständnis zum gestalteten Teil des Entwicklungsprozesses – nicht als Kontrollmechanismus, sondern als Fundament für kreative Teilhabe. Wenn diese Ideen sich durchsetzen, basiert die Zusammenarbeit zwischen Mensch und Maschine nicht auf Vertrauen oder Kontrolle, sondern auf echtem, gemeinsamem Verständnis.

Quelle: geoffreylitt.com

Ein Sprachmodell wird gefragt, wer das Buch „Der Prozess“ geschrieben hat. Es antwortet korrekt. In einem anderen Test sagt es beim selben Faktum „Franz Kafka“, beim nächsten Mal nur „Kafka“ – oder die Antwort ist falsch. Das wirft eine zentrale Frage auf: Ist der Fehler ein Wissensproblem oder ein Abrufproblem? Fehlt die Information im Modell oder ist sie gespeichert, aber nicht erreichbar?

Bisherige Auswertungen betrachten nur die Genauigkeit der Antworten und vermischen dabei zwei Engpässe. Das ist, als würde man ein Lagerhaus nur danach beurteilen, ob die Regale voll sind – ohne zu prüfen, ob man die Ware auch findet. Eine neue Studie, die unter anderem Gemini-3 und GPT-5 untersucht hat, liefert hier Klarheit. Sie führt eine Methode namens „Knowledge Profiling“ ein, die das Speichern von Wissen (Encoding) vom Zugriff darauf (Recall) trennt. Die Ergebnisse zeigen: Bei den größten Modellen ist das Speichern fast perfekt, der Abruf hinkt hinterher.

Encoding und Recall: Zwei verschiedene Fehlerquellen

Stell dir eine Bibliothek mit Millionen Büchern vor. Fehlende Bücher sind ein Encoding-Fehler. Bücher im Regal, die aber nicht im Katalog stehen, sind ein Recall-Fehler. Beide führen dazu, dass du eine Information nicht bekommst. Die Lösungen sind verschieden: Fehlende Bücher musst du kaufen, versteckte Bücher besser indexieren.

In Sprachmodellen ist es ähnlich. Encoding bedeutet, dass ein Fakt in den Parametern gespeichert ist. Recall bedeutet, dass das Modell das Wissen bei einer konkreten Abfrage abrufen kann. Das Forschungsteam unterscheidet zusätzlich zwischen direktem Abruf (spontan richtig antworten) und Abruf mit Denken (Zwischenschritte wie eine Gedankenkette). Ein drittes Konzept ist die Wiedererkennung: Das Modell erkennt die richtige Antwort, wenn sie als Auswahlmöglichkeit vorgelegt wird.

Die Unterscheidung ist nicht akademisch. Sie bestimmt, welche Maßnahmen zur Verbesserung der Faktenwahrheit sinnvoll sind. Fehlt ein Fakt im Modell, helfen nur größere Modelle oder mehr Trainingsdaten. Ist er gespeichert, aber nicht abrufbar, könnten Methoden helfen, die das vorhandene Wissen besser nutzen – etwa Denkaufforderungen oder Optimierungen nach dem Training.

WikiProfile: Ein Benchmark für Wissensprofile

Um die Theorie zu testen, entwickelte das Team den Benchmark WikiProfile. Dafür extrahierten sie 2.150 Fakten aus Wikipedia. Jeder Fakt besteht aus einer Beziehung zwischen zwei Entitäten – etwa „Franz Kafka hat ‚Der Prozess‘ geschrieben“. Zu jedem Fakt generierten sie zehn Fragen: zwei zum Encoding, vier zum Wissen (direkte und umgekehrte Fragestellungen) und vier Multiple-Choice-Varianten zur Wiedererkennung.

Die Fragen entstanden automatisch, wurden per Suchmaschine gefiltert und manuell validiert. So ist sichergestellt, dass jede Frage eindeutig ist und nur eine korrekte Antwort hat. Das Verfahren ist aufwendig, ermöglicht aber eine präzise Diagnose: Für jeden Fakt lässt sich bestimmen, ob er im Modell vorhanden ist, ob er direkt abrufbar ist oder nur mit Denken. Auch lässt sich feststellen, ob das Modell einen Fakt nur durch Schlüsse aus anderen Fakten herleitet – was die Forscher „Inferenz ohne Encoding“ nennen.

Damit untersuchten sie 13 Sprachmodelle, darunter Gemini-2.5-Pro, Gemini-3-Pro, Gemini-3-Flash und GPT-5. Jedes Modell wurde mit und ohne Denkmodus getestet. Pro Kombination wurden acht Antworten gesampelt und automatisch bewertet – insgesamt etwa 4,5 Millionen Antworten. Diese Menge erlaubt klare statistische Aussagen.

Das Hauptergebnis: Der Engpass ist der Abruf, nicht das Wissen

Die zentrale Erkenntnis: Bei den fortschrittlichsten Modellen ist die Speicherung von Fakten nahezu gesättigt, der Abruf bleibt deutlich zurück. Gemini-3-Pro und GPT-5 erreichen Encoding-Raten von 95 bis 98 Prozent. Das heißt, fast alle getesteten Fakten sind im Modell vorhanden. Doch ohne Denken schaffen sie nur 66 bis 74 Prozent korrekt abzurufen. Selbst mit Denken bleiben 11 bis 12 Prozent Fehler.

Ein Großteil der Fehler entsteht also nicht, weil das Modell die Information nicht kennt, sondern weil es sie nicht zugreifen kann. Es ist, als hätte jemand einen Schlüssel für einen Tresor, findet aber den Tresor nicht. Der Engpass hat sich von der Wissensbeschaffung zur Wissensnutzung verlagert. Das könnte die Prioritäten in der KI-Forschung verschieben.

Das Muster zeigt sich auch beim Skalieren. In der Gemma-3-Familie, die mehrere Modellgrößen umfasst, speichern größere Modelle deutlich mehr Wissen – weniger Encoding-Fehler. Die Recall-Fehler bleiben aber erheblich und machen einen größeren Anteil der verbleibenden Fehler aus. Größere Modelle verbessern eher ihr Speichern als ihren Abruf. Mehr Speicherplatz löst das Problem des unzureichenden Suchindex nicht.

Warum der Abruf scheitert: Seltene Fakten und die Umkehrfrage

Warum speichert ein Modell einen Fakt, ruft ihn aber nicht ab? Die Studie zeigt: Der Abruf hängt an den Bedingungen, unter denen der Fakt beim Training gelernt wurde. Das erinnert an einen Menschen, der eine Vokabel in einem Lied lernt und sie in einem anderen Kontext nicht abrufen kann, obwohl er sie kennt.

Besonders deutlich wird das bei seltenen Fakten. Bisherige Forschung nahm an, dass Sprachmodelle bei seltenen (Long-Tail-)Fakten an Kapazitätsgrenzen stoßen. Die neue Analyse relativiert das: Vergleicht man Fakten mit niedriger und hoher Popularität, ist der Unterschied im Encoding gering. Seltene Fakten sind fast so gut gespeichert wie häufige. Der große Unterschied liegt im Recall. Das Modell hat die seltene Information in seinen Parametern, kann sie aber nicht abrufen, weil sie im Training nicht oft genug vorkam, um einen stabilen Assoziationspfad zu bilden.

Ein zweites Problem betrifft die Umkehrfrage – den „Reversal Curse“. Weiß das Modell, dass A gleich B ist, beantwortet es die Frage „Was ist A?“ oft nicht, obwohl es „Was ist B?“ korrekt beantwortet. Die naheliegende Annahme: Das Modell hat die Beziehung nicht symmetrisch gespeichert. Die Studie zeigt eine verblüffende Dissoziation. In offenen Antworten (Recall) sind Umkehrfragen deutlich schwerer. Bei Mehrfachwahl (Wiedererkennung) sind sie es nicht – oft sogar einfacher. Wenn das Modell die richtige Antwort erkennt, aber nicht aktiv generieren kann, ist das bidirektionale Wissen vorhanden. Das Problem liegt im Abruf: Die Abfrage weicht in ihrer Richtung von der Trainingsform ab. Der Reversal Curse ist primär ein Recall-Problem.

Denken als Rettungsanker: Wie Thinking-Modi helfen

Da der Engpass beim Abruf liegt, stellt sich die Frage: Kann man ihn durch zusätzliche Berechnung überwinden? Genau das testet die Studie mit dem Thinking-Modus. Das Modell wird aufgefordert, vor der endgültigen Antwort mehrere Zwischenschritte zu generieren – eine Gedankenkette, die das gespeicherte Wissen aktiviert.

Die Ergebnisse sind deutlich: Thinking verbessert den Abruf genau dort am stärksten, wo der direkte Abruf am schwächsten ist. Besonders bei seltenen Fakten und Umkehrfragen erzielt das Denken große Gewinne und verringert die Popularitäts- und Richtungslücke. Bei den optimierten Modellen findet Thinking 40 bis 65 Prozent der Fakten wieder, die ohne Denken nicht abrufbar waren. Bei Fakten, die gar nicht gespeichert sind, hilft es kaum – Denken kann nicht kompensieren, was nicht existiert.

Das bestätigt: Thinking wirkt als Abruf-Verstärker, nicht als Ersatz für fehlendes Wissen. Es ist, als würde man im Kopf das Inhaltsverzeichnis durchgehen, um das gesuchte Kapitel zu finden. Doch der Rettungsanker hat seinen Preis: Thinking kostet Rechenzeit, Energie und Geld. Zudem ist unklar, wann man es aktivieren sollte – bei bestimmten Fragetypen oder generell. Die Studie liefert erste Anhaltspunkte, aber keine einfache Regel.

Was das für die Entwicklung von KI bedeutet

Die Studie empfiehlt eine strategische Neuausrichtung. Bessere Faktenwahrheit bei Sprachmodellen erfordert nicht nur größere Modelle oder mehr Trainingsdaten. Bei den bereits sehr großen Modellen ist das Encoding fast perfekt. Der Flaschenhals liegt im Zugriff.

Das eröffnet neue Wege. Methoden zur Verbesserung des Abrufs könnten effektiver sein als weiteres Skalieren. Dazu gehören gezielte Aufforderungen, Trainingsverfahren, die Assoziationspfade stärken, oder Mechanismen, die dem Modell erlauben, seine Wissensbasis besser zu durchsuchen – wie ein leistungsfähiger Katalog in der Bibliothek. Es braucht keinen Buchkauf, sondern bessere Indexierung.

Auch für die KI-Nutzung im Alltag hat das Konsequenzen. Bekommt man keine sofortige Antwort, heißt das nicht, dass das Modell sie nicht weiß. Ein Denkmodus oder eine andere Formulierung der Frage kann die gespeicherte Information hervorlocken. Das ist kein Trick, sondern ein legitimer Weg, vorhandenes Wissen zu heben. Es zeigt aber auch, wie fragil das Wissen von KI ist – es kann existieren, ohne verfügbar zu sein. Methoden, die diese Lücke schließen, werden umso wichtiger. Die Studie liefert dafür eine präzise Diagnose und einen klaren Ansatz.

Quelle: research.google

„Usage based pricing is being talked about a lot lately.“ – so beginnt ein aktueller Beitrag zur Preismodell-Debatte. Viele SaaS-Unternehmen überdenken ihre Abrechnungsstrategie. Die Unit Economics haben sich verändert, flexible Modelle klingen verlockend. Doch nicht jede nutzungsbasierte Abrechnung ist gleich.

Es gibt zwei grundlegend verschiedene Ansätze: die Abrechnung von Inputs (etwa API-Aufrufe, Kontakte oder Rechenzeit) und die Abrechnung von Outputs (also von tatsächlich erzielten Ergebnissen wie gelösten Support-Tickets oder abgeschlossenen Deals). Beide zählen zum nutzungsbasierten Preismodell. Doch sie wirken sehr unterschiedlich auf Kundenverhalten, Produktqualität und langfristigen Unternehmenserfolg.

Der Autor hat beide Systeme anhand von Beispielen analysiert. Sein Fazit: Es gibt kein perfektes Modell, nur das richtige für ein bestimmtes Produkt und seine Nutzer. Wir schauen uns die entscheidenden Unterschiede an, damit du für dein Geschäftsmodell eine fundierte Entscheidung treffen kannst.

Zwei Wege zur nutzungsbasierten Abrechnung

Zunächst die Grundlagen. Beim input-basierten Pricing zahlt der Kunde für den Verbrauch einer Ressource – also für API-Calls, gespeicherte Kontakte, Rechenminuten oder Support-Konversationen. Die Metrik ist klar und technisch leicht zu erfassen. Ein einfacher SQL-Query genügt, um die Nutzung zu messen und die Rechnung zu erstellen. Das macht das Modell attraktiv: transparent, objektiv, wenig Interpretationsspielraum.

Beim output-basierten Pricing zahlt der Kunde nur für ein positives Ergebnis – einen erfolgreich gelösten Fall, einen abgeschlossenen Verkauf oder ein zufriedenstellendes Erlebnis. Aus Kundensicht klingt das verlockend, denn man zahlt genau für den Wert, den das Produkt liefert. Doch die Messung ist viel komplexer. Hier liegen die Tücken.

Beide Modelle lassen sich unterschiedlich ausgestalten – als reine Pay-per-Unit, als abgestufte Tarife mit sinkendem Einzelpreis oder als Kontingente mit fester Monatsgebühr. Diese Ausgestaltungen sind eine separate Ebene. Sie ändern nichts an den grundsätzlichen Unterschieden, die wir gleich betrachten.

Input-basiertes Pricing: Einfach zu messen, aber oft losgelöst vom Wert

Der Hauptvorteil liegt auf der Hand: Es ist einfach umzusetzen. Du brauchst nur eine Zählfunktion und kannst daraus eine Rechnung ableiten. Für viele Softwareanbieter ist das der Grund, auf dieses Modell zu wechseln – besonders wenn Power-User deutlich mehr Ressourcen verbrauchen als leichte Nutzer. Die Abrechnung wird fairer, weil jeder proportional zu seinem Verbrauch zahlt. Das Unternehmen erzielt potenziell mehr Umsatz, ohne die Preise zu erhöhen.

Doch aus Kundensicht entsteht ein Problem: Was abgerechnet wird, korreliert nicht zwangsläufig mit dem tatsächlich erhaltenen Wert. Ein Beispiel aus dem Text: Wer in einem CRM für jeden gespeicherten Kontakt zahlt, aber die Hälfte der Kontakte ist veraltet oder irrelevant – dann bezahlt man für wertlosen Ballast. Ähnlich bei einem Streaming-Dienst, der pro angefangenem Film abrechnet: Wenn der Film nicht gefällt, hat man trotzdem bezahlt. Netflix hat dieses Modell bewusst nicht eingeführt, weil es zu Frustration führt, selbst mit Rückerstattungen.

Nicht jeder reagiert gleich empfindlich. Bei API-Aufrufen, die drei Ebenen tief in einer Software versteckt sind, merkt der Nutzer die Abrechnung kaum – das Produkt wird zum Versorgungsunternehmen wie Strom oder Wasser. In einem idealen Markt sinken dann die Preise, und das Produkt wird zur Commodity. Das ist für Nutzer erfreulich, aber nicht unbedingt ein erstrebenswertes Geschäftsmodell, denn es lässt wenig Raum für Differenzierung.

Wenn du kein Commodity-Produkt anbietest, tritt ein weiteres Phänomen auf: Rationierung. Nutzer, die pro Einheit bezahlen, werden zurückhaltend. Sie überlegen sich genau, ob ein API-Call wirklich nötig ist – und das kann die Nutzung massiv einschränken. Besonders kritisch wird es bei Netzwerkprodukten. Wenn Beiträge auf einer Plattform etwas kosten, posten Nutzer seltener. Weniger Inhalte bedeuten weniger Anreiz für andere, zu konsumieren. Die Netzwerkeffekte – der eigentliche Wert der Plattform – werden ausgehebelt. Der Autor nennt als Beispiel einen Video-Dienst wie TikTok, der bei Bezahlung pro Upload schnell an Attraktivität verlieren würde. Ähnlich kann es in B2B-Marktplätzen zugehen, wenn Händler oder Dienstleister rationieren und dadurch die Auswahl für Käufer schrumpft.

Output-basiertes Pricing: Der beste Preis, wenn er messbar wäre

Beim output-basierten Pricing zahlt der Kunde nur für den erzielten Nutzen. Der Autor führt das Beispiel von Intercom an, das seinen AI-Agenten Fin ursprünglich nach erfolgreich gelösten Support-Tickets abrechnete. Konnte Fin ein Problem nicht lösen, entfiel die Zahlung. Das ist ein sehr kundenfreundliches Modell, das die Wertschöpfung in den Mittelpunkt stellt. Doch hier liegt das Problem: Wie definierst du objektiv, ob ein Ergebnis erreicht wurde?

Im Support-Kontext lässt sich eine Lösung relativ klar als „gelöst“ oder „nicht gelöst“ markieren. Aber selbst dann gibt es Grauzonen: Was, wenn der Kunde das Ticket geschlossen hat, aber unzufrieden ist? Im Vertriebs-CRM, das der Autor beispielhaft nennt, wäre ein ergebnisbasiertes Produkt schwer umsetzbar. Ein sauber gepflegtes Pipelines-Dashboard ist zwar nützlich, aber der eigentliche Wert liegt im Abschluss von Deals. Müsste ein Vertriebsmitarbeiter jeden Deal als „gewonnen“ oder „verloren“ markieren, um die Rechnung zu bestimmen, wäre die Versuchung groß, Deals als verloren zu melden. Die Ehrlichkeit der Nutzer wird zur Achillesferse des Modells.

Es gibt jedoch Situationen, in denen soziale Kontrolle das Problem entschärft. Bei einer Plattform, die Handwerker und Kunden verbindet, würde ein Handwerker, der den Auftrag als „nicht erledigt“ markiert, um die Rechnung zu vermeiden, beim Kunden sofort an Glaubwürdigkeit verlieren – die negative Erfahrung überwiegt den finanziellen Vorteil. Diese mehrseitigen Interaktionen erzeugen einen gewissen sozialen Druck, die Wahrheit zu sagen. In vielen rein digitalen B2B-Szenarien fehlt dieser Effekt.

Rationierung und Unehrlichkeit: Zwei Seiten derselben Medaille

Vergleicht man beide Modelle, zeigt sich: Sowohl input- als auch output-basiertes Pricing führen zu Verhaltensänderungen der Nutzer. Beim input-basierten Pricing rationieren die Nutzer – sie sparen mit Ressourcen, auch wenn das ihren eigenen Output schmälert. Das kann die Produktnutzung und den Wert für alle Beteiligten senken. Beim output-basierten Pricing rationieren die Nutzer durch Unehrlichkeit – sie verschweigen oder verdrehen tatsächliche Ergebnisse, um weniger zu bezahlen. Beides ist suboptimal, aber die Auswirkungen sind unterschiedlich.

Die Rationierung bei input-basierten Modellen kann in netzwerkgetriebenen Produkten verheerend sein. Wenn die Nutzung teuer ist, sinkt die Aktivität, und der Netzwerkeffekt – der Hauptwert – wird geschwächt. Bei output-basierten Modellen ist das Hauptrisiko die Manipulation der Metrik. Das funktioniert nur, wenn es einen klaren, unumstößlichen Beleg für ein Ergebnis gibt und gleichzeitig eine Instanz, die die Wahrheit überprüft. In vielen SaaS-Anwendungen ist das schwer zu garantieren.

Noch ein Aspekt: Output-basiertes Pricing setzt die Preise unter Druck. Pioniere können den Wert eines Ergebnisses zunächst gegen den bisherigen manuellen Aufwand absetzen – etwa: „Wir sparen Ihnen zehn Stunden Arbeit, das ist normalerweise 100 Euro wert, wir verlangen nur 20.“ Doch sobald Wettbewerber auftauchen, wird der Preis zum Referenzpunkt für das Ergebnis selbst, nicht mehr für den ersparten Aufwand. Die ehemalige Ersparnis wird irrelevant, und der Preis sinkt auf ein Marktniveau, das kaum noch Raum für Margen lässt.

Was das für dein SaaS-Unternehmen bedeutet

Wenn du über ein Preismodell nachdenkst, solltest du diese Mechanismen kennen. Folge nicht blind dem Trend, nur weil „Usage-based“ gerade modern ist. Die Idee ist verlockend, dass Power-User mehr zahlen, aber die Effekte auf das Nutzerverhalten können das Produkt selbst schädigen. Bevor du auf input- oder output-basiertes Pricing umstellst, stelle dir folgende Fragen:

Gibt es eine klare, nicht manipulierbare Metrik für den Output? Wenn nicht, ist output-basiertes Pricing riskant – Nutzer werden Wege finden, die Messung zu umgehen, und dein Umsatz leidet. Ist dein Produkt auf hohe Nutzungsfrequenz angewiesen, etwa wegen Netzwerkeffekten? Dann kann input-basiertes Pricing die Aktivität abwürgen. In solchen Fällen ist eine flache monatliche Gebühr oder ein hybrides Modell oft besser geeignet.

Langfristig wird sich eine Aufteilung ergeben: Manche Produkte, die klare, messbare Ergebnisse liefern (wie der AI-Support-Agent Fin), bleiben beim output-basierten Pricing. Andere, die als Commodities fungieren, rechnen input-basiert ab. Der Großteil des SaaS-Marktes wird sich jedoch auf eine vorhersehbare, feste Monatsgebühr zubewegen, um Planungssicherheit zu bieten – für Anbieter und Kunden. Nutzungsbasiertes Pricing wird nicht verschwinden, aber es wird nicht zum Allheilmittel für alle.

Fazit: Kein perfektes Modell, nur das passende

Die Abwägung zwischen input- und output-basiertem Pricing ist im Kern eine Abwägung zwischen Einfachheit und Wertorientierung. Input-basiertes Pricing ist leicht zu implementieren und objektiv, aber es kann den Wert verfehlen und zu Rationierung führen. Output-basiertes Pricing stellt den Kunden in den Mittelpunkt, verlangt aber nach präzisen, überprüfbaren Erfolgsmetriken und birgt das Risiko von Unehrlichkeit.

Experimentiere bewusst – aber mit offenen Augen. Überlege, welche Konsequenzen Rationierung oder unehrliches Nutzerverhalten für dein Produkt hätten. Wenn du ein Marketplace betreibst, ist input-basiertes Pricing möglicherweise fatal. Wenn du ein Tool mit klar abgegrenzten Einheiten wie API-Aufrufen anbietest, könnte input-basiertes Pricing gut funktionieren – sofern deine Kunden den Wert darin sehen.

Am Ende entscheidet nicht die Trendwelle, sondern die Passung zu deinem Geschäftsmodell und deinen Nutzern. Nimm dir die Zeit, die Dynamik deines Marktes zu verstehen, und wähle ein Modell, das nachhaltig Umsatz und Kundenzufriedenheit in Einklang bringt. Das ist die eigentliche Kunst der Pricing-Strategie.

Quelle: elliotcsmith.com