Kategorie: Erklärer

Wird Oracle der nächste Lizenzfall der EU-Kommission? Ein Bericht von The Register vom 7. September 2026 legt das nahe. Die Kommission hat demnach begonnen, die Lizenzpraktiken des US-Konzerns zu prüfen – nicht in einem förmlichen Verfahren, sondern in einer vorsichtigen Erkundungsphase. Wer Oracle-Lizenzen einsetzt oder eine Verlängerung verhandelt, sollte sich ansehen, was bei SAP passiert ist. Dort liegt ein Ergebnis vor, das als Vorlage für den nächsten Schritt dienen könnte.

Am einfachsten versteht man die Sache, wenn man Softwarewartung mit einem Servicevertrag für eine Heizung vergleicht. Solange alles läuft, ist der Vertrag mit dem Hersteller bequem. Irgendwann will der Betreiber einen unabhängigen Techniker beauftragen, weil er günstiger ist oder schneller kommt. Wenn der Hersteller technisch und vertraglich durchsetzt, dass nur seine eigenen Leute Hand anlegen dürfen, wird aus dem Serviceversprechen eine Fessel. Um dieses Muster geht es im europäischen Kartellrecht, und hier setzt die Kommission seit Jahren an.

Was die Kommission bei SAP durchgesetzt hat

Die Kommission hatte geprüft, ob SAP den Wettbewerb im nachgelagerten Markt für Wartung und Support seiner lokalen ERP-Software eingeschränkt hat. Der Vorwurf lautete nicht, das Produkt sei zu teuer, sondern der Weg zurück zum Hersteller sei künstlich verengt worden. Im Juli nahm die Behörde die Zusagen des deutschen Konzerns an und erklärte sie für bindend. The Register nennt drei Kernpunkte: die Abschaffung von Wiedereinsetzungsgebühren, geringere Nachzahlungen für rückwirkende Wartung und weitere Zugeständnisse, die Drittanbietern den Marktzugang erleichtern sollen.

Die Wiedereinsetzungsgebühr ist der anschaulichste Punkt. Wer die Wartung zwei Jahre aussetzt und später wieder einsteigen will, musste bisher für die Lücke zahlen – obwohl er in dieser Zeit keine Leistung erhalten hat. Der Hersteller verlangte Geld für einen Zeitraum, in dem er nichts getan hatte, und zwar nicht als Strafe, sondern als Preis für die Rückkehr. Gartner begrüßte die Zusagen, weil sie Kunden bei älteren SAP-Anwendungen mehr Optionen geben und Drittanbieter-Support zu einer echten Alternative zur Migration machen. Der Zeitdruck ist real: Der Herstellersupport für einige ältere SAP-Produkte läuft 2027 aus. Wer bis dahin nichts entscheidet, entscheidet faktisch für die teuerste Variante.

Warum Oracle jetzt in den Blick der Behörden gerät

Nach Informationen des Fachdienstes MLex hat die Kommission begonnen, die Lizenzierungspraktiken von Oracle zu prüfen – im Vorfeld einer möglichen förmlichen Untersuchung. Eine Quelle sagte der Publikation, die Behörde sammle derzeit Einschätzungen von Dritten. Der Satz klingt unspektakulär, wiegt aber schwer: Eine solche Marktabfrage ist meist der erste Schritt, bevor aus einem Verdacht ein Verfahren wird. Sie soll klären, ob es tragfähige Beschwerden gibt und wie der relevante Markt abzugrenzen wäre.

Ein Sprecher der Kommission sagte The Register, die Untersuchung zu SAP sei abgeschlossen, man werde aber mögliche weitere wettbewerbswidrige Praktiken und Missbrauch in diesem Sektor weiter beobachten. Derzeit gebe es keine förmliche Untersuchung gegen irgendein Unternehmen. Die Formulierung ist offen: Sie verneint nichts für die Zukunft, nur den aktuellen Verfahrensstand. The Register hat Oracle um eine Stellungnahme gebeten. Der Anbieter hält seine Lizenzpraxis seit Jahren für fair – angesichts der wiederkehrenden Kritik aus Kunden- und Beraterszene bleibt das erklärungsbedürftig.

Java: Wenn die Mitarbeiterzahl zur Lizenzgröße wird

Häufig kritisiert wird der Umgang mit Java, das nach der Übernahme von Sun Microsystems 2009 unter Oracles Kontrolle kam. OpenJDK, die Referenzimplementierung der Plattform, ist Open Source. Kostenpflichtig sind dagegen proprietäre Entwicklungs-Kits, Laufzeitumgebungen und Support. Im Januar 2023 kündigte Oracle ein neues Lizenzregime für Oracle Java SE an und nannte es ein einfaches, günstiges Monatsabonnement, das Lizenzierung und Support für Desktop, Server und Cloud abdeckt.

Darin liegt der Streit. Branchenkenner wiesen damals darauf hin, dass Unternehmen selbst bei begrenzter Nutzung nach der Gesamtzahl ihrer Mitarbeiter zur Kasse gebeten werden könnten. Das bricht mit der bisherigen Logik: Die alte Frage war, wie viel jemand tatsächlich einsetzt. Die neue lautet, wie viele Menschen bei ihm arbeiten. Gartner schätzte das Modell pro Mitarbeiter auf das Zwei- bis Fünffache der alten Lizenzvariante. In der Heizungsanalogie: Abgerechnet wird nicht nach verbrauchter Wärme, sondern nach der Zahl der Zimmer – unabhängig davon, ob dort jemand wohnt.

Die Unlimited License Agreement: Was daran problematisch ist

Ein zweites Modell sorgt regelmäßig für Diskussionen: die Unlimited License Agreement. Der Gedanke klingt verlockend – ein pauschaler Betrag, dafür darf das Unternehmen eine Produktfamilie in einem definierten Zeitraum unbegrenzt einsetzen, ohne bei jeder Installation nachzählen zu müssen. Lizenzberater halten dagegen, dass dieses All-you-can-eat-Angebot oft einen schlechten Gegenwert bietet. Wer einmal pauschal bezahlt hat, verliert den Anreiz, seinen tatsächlichen Bedarf zu messen, und wird an den Anbieter gebunden.

Entscheidend ist die Bindung. Ein solcher Vertrag mag Budgets vereinfachen, verringert aber den Spielraum, einzelne Komponenten durch Alternativen zu ersetzen, weil das Paket nur als Ganzes funktioniert. Bei der Verlängerung sitzt der Kunde in einer schwächeren Position als bei einzeln verhandelten Lizenzen. Oracle hält entgegen, die Vereinbarung biete Flexibilität und ein gutes Preis-Leistungs-Verhältnis. Beides kann stimmen – es hängt von der Verhandlungsposition des Kunden ab und davon, wie genau er seinen Bestand kennt.

Was das Kartellrecht in diesem Markt prüft

In der Sache geht es um den Missbrauch einer marktbeherrschenden Stellung. Typisch ist dieser Prüfungsansatz: Ein Anbieter ist bei der Grundsoftware stark, und Kunden können nach der Einführung kaum noch wechseln. Diese Bindung eröffnet einen zweiten, nachgelagerten Markt für Wartung, Support und Rückkehr in den Vertrag, in dem der Anbieter die Bedingungen praktisch allein setzt. Hier setzt die Prüfung an – nicht bei der Frage, ob ein Produkt teuer ist, sondern ob der Wettbewerb nach dem Kauf künstlich ausgeschaltet wird.

Ein Unterschied wird dabei oft verwischt: Die Kommission hat Zusagen angenommen, keinen Verstoß festgestellt. Ein Verpflichtungsverfahren korrigiert einen Markt schnell, ohne jahrelange Beweisaufnahme und ohne Geldbuße. Darin liegt auch die Botschaft an die Branche. Wenn die Behörde ausdrücklich von diesem Sektor spricht und ankündigt, die Entwicklung weiter zu beobachten, hält sie sich die Tür offen. Für Oracle heißt das: keine laufende Untersuchung, aber eine Beobachtung, die jederzeit dichter werden kann.

Was Oracle-Kunden in den nächsten Monaten tun können

Zuerst geht es darum, den eigenen Bestand wirklich zu kennen – Java eingeschlossen. Wo läuft welche Laufzeitumgebung, welche Version, in welcher Umgebung, und wie viele Mitarbeiter hat das Unternehmen insgesamt? Beim Modell pro Kopf ist die Personalzahl eine Lizenzgröße. Die Frage wandert damit aus der IT in die Personalabteilung. Wer diese Zahl bei einer Prüfung nicht parat hat, verhandelt aus einer schwachen Position, egal wie gut sein Anwalt ist.

Als Zweites die Vertragsakte. Wiedereinsetzungsregeln, Nachzahlungsklauseln, Definitionen von Nutzung und Mitarbeiter – an diesen Stellen entscheidet sich später alles. Wer heute eine Verlängerung verhandelt, kann versuchen, solche Klauseln zu entschärfen, und sei es nur, indem er den Wiedereinstieg nach einer Pause ausdrücklich regelt. Drittens die Frage, ob Drittanbieter-Support für einzelne Produkte eine Option ist – bei SAP ist er inzwischen ausdrücklich als Weg neben der Migration anerkannt. Das ist keine Ideologie, sondern eine Rechenaufgabe mit Haltbarkeitsdatum.

Ein Bericht ist noch kein Verfahren

Es gibt derzeit keine förmliche Untersuchung gegen Oracle. Der Bericht von The Register stützt sich auf eine Marktabfrage, deren Ergebnisse niemand außerhalb der Kommission kennt. Es gibt aber ein abgeschlossenes Verfahren gegen SAP, dessen Zusagen als Maßstab für den Sektor gelten können. Wer Oracle-Lizenzen einsetzt, muss heute nicht umplanen, sollte aber wissen, wie er dasteht, wenn die Fragen kommen. Ein gut dokumentierter Bestand ist dann mehr wert als ein unklarer – nicht beim Preis, sondern in der Verhandlung.

Quelle: theregister.com

600 Millionen Parameter stecken in dem kleinen Sprachmodell, das in einer Browser-Demo zeigt, wie Aufmerksamkeit in Large Language Models tatsächlich funktioniert. Der Autor hat eine interaktive Visualisierung gebaut, die sichtbar macht, welche vergangenen Token ein gerade entstehendes Wort beeinflussen. Beim Kopieren einer Adresse leuchten die Quell-Token hell auf, beim Wort „remain“ verschmelzen Informationen aus zwei Sätzen zu einem neuen Token. Das sieht aus wie Spielerei, ist aber ein Blick in den Mechanismus, der Sprache erzeugt.

Was Attention in einem Transformer überhaupt leistet

Transformer-Modelle erzeugen Text Token für Token, also in kleinen Bedeutungseinheiten, die oft kürzer sind als ganze Wörter. Bei jedem neuen Token hat das Modell Zugriff auf alle vorher erzeugten Token. Das allein reicht nicht. Wenn jedes frühere Token gleich stark wirkte, ginge das Signal im Rauschen unter. Die Architektur braucht einen Mechanismus, der entscheidet: Welche vergangenen Token sind gerade wichtig, welche weniger? Genau das übernimmt der Attention-Mechanismus.

Stell dir einen Assistenten vor, der ein neues Wort formulieren soll und Dutzende Karteikarten mit dem bisherigen Text vor sich hat. Manche Karten sind relevant, andere Hintergrund. Attention ist das Gewicht, das der Assistent jeder Karte gibt. In technischen Begriffen handelt es sich um gelernte Koeffizienten, die bestimmen, wie stark der Wert eines Tokens in die nächste Vorhersage einfließt. Heraus kommen die Attention Heads, also parallel arbeitende Einheiten, die unterschiedliche Aspekte des Kontexts erfassen.

Wie die Visualisierung die Aufmerksamkeit sichtbar macht

Die Demo nutzt Transformers.js, eine JavaScript-Bibliothek, die Modelle direkt im Browser ausführt. Normalerweise gibt eine solche Bibliothek nur die fertig generierten Token zurück. Für die Visualisierung braucht es mehr: Die internen Attention-Gewichte, die Value-Vektoren und den vollständigen Schichtaufbau des Modells. Das Standard-Interface stellt diese Werte nicht bereit.

Der Autor musste deshalb einen eigenen Generierungs-Loop improvisieren, im Text als „vibe-code“ bezeichnet. Gemeint ist explorative Programmierung, bei der man sich Stück für Stück an die richtigen Zugriffe herantastet. Dabei entstand das Problem, dass die ONNX-Dateien den kompletten Rechengraphen in WebAssembly enthalten, also in kompiliertem Binärcode, der direkt im Browser läuft. An interne Zwischenwerte kommt man über die übliche Schnittstelle nicht heran. Die Lösung war ein kleines Skript, das die ONNX-Datei minimal verändert, um die nötigen Werte freizugeben. Dieses instrumentierte Modell liegt auf einem eigenen Hugging-Face-Repository und wird von der App explizit von dort geladen.

Ein praktischer Punkt: Selbst ein 600-Millionen-Parameter-Modell ist einige hundert Megabyte groß. Diese Datenmenge beim ersten Aufruf der Seite zu laden, wäre kaum zumutbar. Deshalb hat der Autor mehrere vorberechnete Prompts hinterlegt. Wer die Demo öffnet, bekommt sofort sichtbare Ergebnisse, ohne auf den Modell-Download zu warten.

Was die Visualisierung tatsächlich zeigt und was sie weglässt

Die Darstellung arbeitet mit einer einzigen Zahl pro vergangenem Token. Sie berechnet das Attention-Gewicht, multipliziert es mit der Länge des Value-Vektoren-Anteils, der in dieses Token fließt, und addiert die Ergebnisse über alle Heads und alle Schichten. Das klingt kompliziert, ist im Kern eine Aggregationsstrategie: Aus den abertausenden Attention-Werten pro Token wird ein einziger Helligkeitswert. Der höchste Wert bekommt volle Deckkraft, alle anderen werden relativ dazu skaliert. Beim Hover über ein generiertes Token leuchten die vergangenen Token hervor, die am stärksten zu seiner Entstehung beigetragen haben.

Dabei gehen viele Informationen verloren. Der Autor betont, dass die Bezeichnung „beeinflusst“ streng genommen nicht exakt ist, weil die Visualisierung eine starke Vereinfachung darstellt. In Wirklichkeit sind Attention-Muster mehrdimensional, abhängig vom Kontext und über viele Köpfe verteilt. Trotz dieser Reduktion entstehen nachvollziehbare Muster. Bemerkenswert, denn ursprünglich hatte der Autor selbst bezweifelt, dass aus einem einzigen Zahlenwert pro Token noch etwas Lesbares hervorgehen würde.

Warum LLMs besser kopieren als der Zufall erlauben würde

Eine häufige Irritation betrifft das Kopieren. Wer schon einmal eine Adresse, ein Datum oder einen Funktionsnamen von einem KI-System reproduzieren ließ, staunt oft, wie fehlerfrei das gelingt. Die intuitive Erwartung sagt: Wenn ein Modell probabilistisch arbeitet, müssten sich über die Länge eines kopierten Abschnitts doch irgendwann Fehler einschleichen. Jeder Schritt habe eine kleine Fehlerwahrscheinlichkeit, und die summiere sich.

Die Visualisierung zeigt, warum diese Rechnung nicht aufgeht. Beim Kopieren greift das Modell gezielt auf genau die Token zurück, die es reproduzieren will. Im „Office Move Summary“-Beispiel genügt es, über die kopierte Stelle zu hovern, und die Quell-Token leuchten hell auf. Das Modell muss die zu kopierende Sequenz nicht aus einem begrenzten internen Zustand rekonstruieren, sondern kann jederzeit direkt auf das Original zugreifen. Die Fehlerwahrscheinlichkeit bleibt niedrig, weil der Mechanismus das Kopieren aktiv unterstützt.

Wenn das Modell Information aus mehreren Quellen kombiniert

Aufschlussreich ist ein Detail aus dem gleichen Demo-Prompt. Der Satz „Existing access cards and phone numbers remain“ enthält das Wort „remain“, und ein Hover darüber zeigt, dass das Modell Informationen aus zwei Stellen des Kontexts zusammenführt. Aus dem Satz „Existing employee access cards will work“ wird das Wort „work“ herangezogen, aus einem anderen Satz das Wort „stay the same“. Das resultierende Token ist eine Art Kompositum aus beiden Bedeutungen.

Das illustriert ein Grundprinzip der Transformer-Architektur: Neue Token entstehen nicht aus einem einzigen Hinweis, sondern durch die gewichtete Mischung vieler Hinweise. Das Modell lernt während des Trainings, welche Kombinationen sinnvoll sind. Im konkreten Fall hat es offenbar gelernt, dass Bedeutungen wie „weiterhin gültig sein“ sowohl mit „work“ als auch mit „stay the same“ ausgedrückt werden können, und nutzt diese Assoziation, um ein Token zu erzeugen, das die zugrundeliegende Intention transportiert.

Was das für den Blick auf Sprachmodelle bedeutet

Die Visualisierung räumt mit einer verbreiteten Vorstellung auf: LLMs sind keine Blackbox, deren Innenleben sich jeder Einsicht entzieht. Viele Details bleiben opak, aber zumindest der Attention-Mechanismus lässt sich mit vertretbarem Aufwand darstellen und interpretieren. Das schlägt eine Brücke zwischen der abstrakten Mathematik der Transformer und dem konkreten Verhalten im Output.

Wer die Demo selbst ausprobieren möchte, findet sie auf der Projektseite. Der Quellcode liegt auf GitHub, das angepasste Modell auf Hugging Face. Die Vorgehensweise – ein ONNX-Modell minimal instrumentieren, einen eigenen Generierungs-Loop schreiben, vorberechnete Prompts anbieten – ist auch für andere Visualisierungsprojekte brauchbar. Sie zeigt, dass selbst in der stark optimierten Browser-Inferenz noch Spielraum besteht, um Modelle von innen sichtbar zu machen, solange man bereit ist, ein wenig über den Standardweg hinauszugehen.

Quelle: ishamf.dev

Die meisten Teams führen langsame Datenbanken auf zu wenig CPU, zu große Tabellen oder ein träges Netzwerk zurück. Oft ist das falsch. Ein dokumentierter Fall: Ein Nachtjob lädt 100.000 Zeilen aus einer Datei in Postgres und braucht 41 Minuten. Die Maschine hat kaum Last, die Zeilen sind klein, die Tabelle hat nur drei Indizes. Das sind ungefähr 40 Zeilen pro Sekunde. Wer so eine Zahl sieht, vermutet einen Defekt. Es liegt keiner vor. Der Job schickt 100.000 einzelne Statements, jedes in einer eigenen Transaktion, über eine Leitung mit 0,4 ms Latenz. Jede dieser Transaktionen wartet einzeln darauf, dass das Speichermedium den Schreibvorgang bestätigt – daher die 41 Minuten. Stellt man auf COPY um, sinkt die Laufzeit auf 11 Sekunden. Die Ursache liegt woanders.

Die Arbeit steckt nicht in der Zeile, sondern rundherum

Bei einem kleinen Insert ist das Einfügen selbst nicht der teure Teil. Der Aufwand entsteht rundherum. Jedes Statement kostet einen Netzwerk-Roundtrip. Der Server parst den SQL-Text, plant die Ausführung und führt sie aus. Die Transaktionsmaschinerie öffnet, protokolliert und committet. Danach geht das Ergebnis zurück, der Client beginnt mit der nächsten Zeile. Der reine Insert dauert rund 20 Mikrosekunden. Die übrigen 980 Mikrosekunden sind Overhead. Batching setzt genau hier an: Man zahlt den Overhead nicht pro Zeile, sondern pro Batch. Das ist dieselbe Rechnung wie beim N+1-Problem, bei dem 400 schnelle Queries teurer sind als eine langsame. Lesen und Schreiben folgen derselben Logik: Übersteigt der Overhead die eigentliche Arbeit, ist die Anzahl der Operationen die Stellschraube.

Die Batch-API, die nicht batcht

Der folgende JDBC-Code sieht auf den ersten Blick korrekt aus. Er nutzt das Standardrezept für JDBC-Batching. Mit MySQL-Standardeinstellungen schickt er trotzdem 100.000 einzelne INSERT-Statements. Der Treiber nimmt sie in einen Batch auf und sendet sie einzeln, weil er Multi-Value-Statements nur nach expliziter Aktivierung baut. Der entscheidende Parameter ist rewriteBatchedStatements=true in der JDBC-URL. Ohne ihn ist addBatch eine clientseitige Bequemlichkeit, die am Draht nichts bewirkt. Mit ihm kombiniert der Treiber die Zeilen zu INSERT INTO events VALUES (...), (...), (...). Die Zahl der Roundtrips bricht ein. Bei Postgres heißt der Parameter reWriteBatchedInserts=true. Beide sind standardmäßig deaktiviert. Beide erzeugen Code, der Reviews besteht, Tests besteht und sich verhält, als hätte er nie gebatcht. In der Praxis hat dieser Schalter mehrfach den kompletten Inhalt eines Performance-Fixes ausgemacht – die API weist nicht darauf hin. Setze eine Batch-Größe explizit, statt alle Zeilen auf einmal zu sammeln. Sonst baut der Treiber die gesamte Anweisung im Speicher auf. Zwischen 500 und 5.000 Zeilen pro Batch ist ein guter Bereich. Darüber wird das Statement so groß, dass Speicher und Parse-Zeit den Gewinn auffressen.

Autocommit verwandelt jede Zeile in eine Barriere

setAutoCommit(false) bewirkt mehr, als der Name vermuten lässt. Bei aktivem Autocommit ist jeder Insert eine eigene Transaktion. Jede Transaktion committet, und jeder Commit ist eine Durability-Barriere: Das Speichermedium muss bestätigen, dass der Write-Ahead-Log-Eintrag sicher liegt. Diese Barriere ist keine CPU-Arbeit, die man parallelisieren könnte. Sie ist Wartezeit auf das Gerät und begrenzt den Durchsatz auf etwa einen Commit pro Flush-Latenz. 100.000 autocommittete Inserts erzeugen 100.000 Flushes. Verpackt man die gesamte Last in eine Transaktion, gibt es nur eine Barriere für den kompletten Lauf. Die WAL-Records werden weiter geschrieben, geflusht wird am Ende. Das hat Grenzen: Eine Transaktion über 100 Millionen Zeilen hält Locks für die gesamte Dauer, erhält jede Zeilenversion für VACUUM und rollt bei einem einzelnen Fehler den gesamten Lauf zurück. Eine Aufteilung in Transaktionen von einigen zehntausend Zeilen bringt fast die volle Ersparnis und hinterlässt einen Wiederaufsetzpunkt.

Die Leiter und wo COPY steht

Weil jede Sprosse einen anderen Overhead entfernt, multiplizieren sich die Gewinne. Die Stufen im Überblick: Einzelsätze mit Autocommit verursachen einen Roundtrip pro Zeile, einen Parse pro Zeile und eine Transaktion pro Zeile. Einzelsätze in einer Transaktion senken die Transaktionen auf eine, lassen Roundtrips und Parses unverändert. JDBC-Batch ohne das Flag verhält sich wie Einzelsätze. JDBC-Batch mit Flag reduziert Roundtrips und Parses auf einen pro Batch. COPY und LOAD DATA INFILE streamen die Zeilen direkt: kein Roundtrip pro Zeile, kein Parse pro Zeile, eine Transaktion insgesamt. COPY ist kein schnelleres Statement, sondern ein anderer Protokollpfad. Es gibt kein SQL, das pro Zeile geparst wird, keinen Plan, keine Statement-Verwaltung. Der Client streamt, der Server schreibt. Für echte Massenladungen ist das das richtige Werkzeug. Der Unterschied ist deutlich. Aber dieser Pfad ist kein allgemeiner Schreibpfad: Ältere Postgres-Versionen unterstützen kein ON CONFLICT, generierte Schlüssel lassen sich nicht zurückgeben, und Fehler brechen den Stream ab. Ein gängiges Muster ist, via COPY in eine UNLOGGED-Tabelle zu laden und das Ergebnis mit einem einzigen INSERT ... SELECT ... ON CONFLICT in die Zieltabelle zu überführen. Das verbindet Tempo mit Konfliktbehandlung.

Dasselbe Prinzip auf der Leseseite

Lesen hat dasselbe Problem, nur unsichtbarer, weil eine Schleife mit Queries wie normaler Code aussieht. IN-Listen sollten begrenzt bleiben. Einige tausend Werte sind in Ordnung, 100.000 machen das Statement so groß, dass schon das Parsen langsam wird. Bei Postgres kann außerdem das Limit für Bind-Parameter reißen. Teile die IDs in Seiten zu tausend Werten und schicke wenige Abfragen. Auch hier gilt: Abfragen bündeln statt einzeln abfeuern.

Was du konkret prüfen solltest

Drei Checks trennen Ursache von Vermutung. Erstens: Führe den Ladevorgang mit gesetztem rewriteBatchedStatements oder reWriteBatchedInserts aus und vergleiche die Zeiten. Ändert sich etwas, hat der Code nie gebatcht. Jede weitere Optimierung wäre dann auf einer falschen Grundlage. Zweitens: Zähle Roundtrips, statt zu spekulieren. log_statement = 'all' bei Postgres oder die Query-Count-Metriken des Connection-Pools zeigen in einer einzigen Zahl, ob der Batch am Draht angekommen ist. Drittens: Prüfe Autocommit auf jedem Codepfad, der mehr als eine Handvoll Zeilen schreibt. Die meisten Treiber aktivieren es standardmäßig, und es ist der größte Multiplikator dieser Aufzählung. Alle diese Hebel sind am Aufrufort unsichtbar. Die Schleife sieht identisch aus, egal ob sie einen Roundtrip auslöst oder hunderttausend. Die Batch-API sieht identisch aus, egal ob der Treiber sie nutzt oder ignoriert. Autocommit ist eine Connection-Eigenschaft, die an anderer Stelle gesetzt wird. Der Code verrät nicht, welche Variante vorliegt. Nur der Draht kann es.

Quelle: ankit-rana.com

Berichte über OpenAIs Modell Astra sorgen in der KI-Szene für Aufsehen. Sie erwähnen eine neuartige „Recurrent Depth“-Architektur oder einen „Looped Transformer“. Die Grundidee ist weder brandneu noch ein Geheimnis aus dem Hause OpenAI. Nanbeige 4.2, ein offenes Modell, veröffentlichte die technischen Details vor etwa zwei Monaten und nutzt genau diesen Ansatz. Die Beschreibung „Nanbeige4.2-3B ist von Grund auf mit 28 Billionen Tokens trainiert und verwendet einen Looped Transformer, der den Layer-Stack wiederverwendet, um die Kapazität ohne zusätzliche Parameter zu erhöhen“, fasst das Prinzip knapp zusammen. Weil viele Halbwahrheiten kursieren, lohnt ein genauer Blick auf die Architektur.

Was ein Looped Transformer technisch macht

Die Grundidee ist einfach: Statt einen Stapel Transformer-Layers einmal zu durchlaufen, wird derselbe Stapel mehrfach auf die Daten angewendet. Bei Nanbeige 4.2 umfasst der Kern 22 Transformer-Layers. Üblicherweise durchlaufen Eingabetokens den Stapel genau einmal. Im Looped-Design sind es zwei Durchläufe, also effektiv 44 Layer. Die Gewichte werden dabei nicht dupliziert.

Das hat zwei Konsequenzen, die oft verwechselt werden. Erstens bleibt der Speicherbedarf nahezu gleich, weil keine Parameter hinzukommen. Zweitens verdoppeln sich die Rechenkosten, weil pro Token doppelt so viele Layer-Berechnungen anfallen. Wer einen Looped Transformer für eine kostenlose Kapazitätssteigerung hält, liegt falsch. Es ist ein Trade-off: Speicher sparen, Rechenzeit investieren.

Die Nanbeige-Forscher fanden, dass zwei Durchläufe den optimalen Punkt darstellen. Mehr Durchläufe brachten kaum messbare Qualitätsgewinne, verlängerten aber das Training und trieben den Rechenaufwand in die Höhe. Zwei Passes erreichten rund 75 Prozent der Token-Effizienz eines klassischen, tieferen Modells. Das klingt nach einem Kompromiss. In der Praxis ist es oft attraktiv, weil Deployments meist unter Speicher- und Latenzbeschränkungen leiden, nicht unter Trainingsbudgets.

Herkunft: Mixture-of-Recursions und die Wurzeln der Idee

Die Idee, denselben Layer-Stapel mehrfach zu verwenden, ist älter als Nanbeige. Das NeurIPS-Papier „Mixture-of-Recursions: Learning dynamic recursive depths for adaptive token-level computation“ formulierte den Grundgedanken und entwickelte ihn weiter. Statt jeden Token gleich oft durch den Loop zu schicken, lernt ein kleines Routing-Modul pro Token, wie viele Durchläufe nötig sind. Einfache Tokens verlassen den Stapel früh, schwierige Tokens erhalten zusätzliche Recursion-Durchläufe.

Diese dynamische Variante ist flexibler als ein starrer Loop mit fester Wiederholungszahl. Sie passt die Rechenkosten an die Schwierigkeit jedes Tokens an. Ein Satz wie „Hallo, wie geht es dir?“ benötigt weniger Recursion als eine mehrstufige mathematische Herleitung. Das ist keine simple Verdopplung der Tiefe, sondern ein fein einstellbares Rechenbudget.

Nanbeige 4.2 nutzt derzeit einen festen Faktor von zwei und verzichtet auf adaptives Routing. Das hält die Implementierung einfach und die Trainingspipeline vorhersagbar. Allerdings entgeht ihm so der Effizienzgewinn, den Mixture-of-Recursions verspricht.

Astra, Recurrent Depth und die Aussage zur Chain-of-Thought

Zur eigentlichen Kontroverse: In Berichten über Astra heißt es, die neue Technik mache das Chain-of-Thought-Reasoning unsichtbar. Wer mit Modellen arbeitet, die vor der Antwort explizite Gedankenschritte generieren, kann diese mitlesen und steuern. Die neue Architektur, so die Behauptung, verschleiere diesen Zwischenschritt.

So pauschal ist das nicht haltbar. Ein Looped Transformer macht Chain-of-Thought nicht unsichtbar. Was tatsächlich passiert: Mehr Recursion-Durchläufe verlagern einen Teil der Verarbeitung in die internen Hidden States. Diese Aktivierungen existieren, werden aber nicht als Text ausgegeben. Mehr Berechnung in den Hidden States heißt: Es sind weniger explizite Reasoning-Tokens nötig, um zur gleichen Antwort zu kommen.

Derselbe Effekt tritt auf, wenn man ein klassisches Transformer-Modell einfach tiefer skaliert. Vergleicht man GPT-Modelle unterschiedlicher Größe, braucht das größere weniger sichtbare Zwischenschritte, weil es pro Layer mehr Denkleistung erbringt. Das ist keine neue Eigenschaft von Looped Transformers, sondern ein generelles Muster beim Skalieren.

Wahrscheinlich vermengen Journalistinnen und Journalisten zwei Dinge: die Recurrent-Depth-Architektur und einen unabhängigen Effekt, der bei jeder Form gesteigerter Berechnung auftritt. Recurrent Depth mag bei Astra eine Rolle spielen. Warum Chain-of-Thought kürzer wirkt, erklärt allein das nicht.

Speicher versus Rechenzeit: der Trade-off

Ein häufiges Missverständnis betrifft den Unterschied zwischen Modellgröße und Rechenaufwand. Ein Looped Transformer spart VRAM, weil die Gewichte nur einmal vorliegen. Das ist nützlich für Self-Hosting, Edge-Deployment und Szenarien, in denen Speicher der limitierende Faktor ist. In Cloud-Setups mit H100-Clustern wiegt dieser Vorteil weniger, weil dort oft die Rechenzeit der knappe Faktor ist.

Was ist dann der strategische Sinn? OpenAI, Mistral und andere Anbieter betreiben riesige GPU-Farmen, Speicher ist dort relativ günstig. Warum also auf Looped Transformer setzen? Eine Erklärung: Astra soll auch auf Endgeräten laufen, und dort ist Speicher knapp. Eine andere: Kleinere Modelle laden schneller und ermöglichen so eine Latenz-Optimierung.

Für alle, die Modelle selbst betreiben: Ein Looped Transformer ist kein Allheilmittel, sondern eine Designentscheidung mit klaren Kompromissen. Wer Speicher sparen muss und etwas mehr Rechenzeit investieren kann, profitiert. Wer Rechenzeit optimieren muss, fährt mit einem klassischen tieferen Modell besser.

Was bleibt von der Aufregung

Was Astra wirklich leistet, hängt von Trainingsdaten, Alignment und Gesamtarchitektur ab. Recurrent Depth ist ein Baustein von vielen, nicht der revolutionäre Kern. Wer die Berichterstattung verfolgt, sollte drei Dinge auseinanderhalten: die Architekturinnovation, die sichtbare Chain-of-Thought und die Frage, wie viel Reasoning in den Hidden States geschieht.

Die Looped-Transformer-Idee ist keine Erfindung von OpenAI. Nanbeige 4.2 hat sie kürzlich in einem offenen Modell demonstriert. Mixture-of-Recursions lieferte die theoretischen Grundlagen. Astra setzt vermutlich eine leistungsfähige Variante ein, aber die zugrundeliegende Mechanik ist verstanden.

Für Entwicklerinnen und Entwickler, die mit KI-Modellen arbeiten, heißt das: Lasst euch nicht vom Hype blenden. Prüft, ob die Architektur zu eurem Use Case passt, ob der Speichervorteil den Rechenzeitnachteil aufwiegt und ob das Modell hält, was Schlagzeilen versprechen. Entscheidend ist die Leistung in der konkreten Anwendung, nicht die Architekturbezeichnung auf dem Papier.

Quelle: sebastianraschka.com

Anthropic hat den System-Prompt von Claude Code um 80 Prozent reduziert. Context Engineering ist nicht mehr die Kunst des Hinzufügens, sondern des Weglassens. Wer in den letzten Monaten AGENTS.md-Dateien befüllt hat, sollte prüfen, ob sie den Agenten inzwischen behindern.

Jina Yoon beschreibt auf dem PostHog-Blog genau diesen Umschwung. Früher ging es darum, fehlendes Wissen in den Kontext zu packen, weil die Modelle bestimmte Dinge nicht wussten. Inzwischen sind die Modelle besser, und derselbe Kontext bremst sie. Beispiel: Ein Onboarding-Wizard landete in Monorepos oft im falschen Projekt, weil die Skripte standardmäßig auf das Root-Verzeichnis zeigten. Das Modell erkannte die Struktur längst selbst; die explizite Anweisung erzeugte nur Fehler.

Der Wandel: Vom Anreichern zum Ausdünnen

Context Engineering hat sein Ziel verändert. Früher galt: mehr relevante Informationen, besserer Agent. Heute gilt das Gegenteil. Zu viel Kontext senkt die Entscheidungsqualität. Anthropic hat den System-Prompt von Claude Code deshalb um 80 Prozent reduziert. Labs raten von übermäßigen Regeln und Wiederholungen ab – sie setzen auf Urteilsfähigkeit, klare Schnittstellen und progressive Gewöhnung.

Für deine Arbeit heißt das: Eine AGENTS.md, die du mühsam aufgebaut hast, kann dich inzwischen ausbremsen. Boris Cherny, der Schöpfer von Claude Code, empfiehlt, die eigene CLAUDE.md alle sechs Monate komplett zu löschen. Der Entwickler Theo berichtet, dass sich das handschriftliche Neuschreiben seiner AGENTS.md gelohnt hat. Klingt radikal, ist aber konsequent: Wenn weniger mehr ist, musst du regelmäßig ausmisten.

Methode 1: Mit claude doctor und einem ehrlichen Blick aufräumen

Der einfachste Weg, deinen Kontext gesund zu halten, ist, ihn selbst zu lesen und zu bearbeiten. Die meisten Coding-Agents bieten dafür einen integrierten Befehl an, bei Claude heißt er /doctor. Das Werkzeug führt grundlegende Checks durch: Es löscht redundante Prompts, erkennt kaputte Einstellungen, findet ungenutzte Plugins und optimiert für Lazy Loading. Am Ende erscheint ein Bericht, der anzeigt, wie oft jede Datei verwendet wurde und wie viel Kontext sich einsparen ließe.

Auf der PostHog-Website schlug der Befehl vor, drei ungenutzte Plugins und drei Skills zu deaktivieren. Das sparte durchschnittlich 6.000 Tokens pro Session. Ordentlich, aber verlass dich nicht darauf, dass der Arzt alle Fehler findet. claude doctor prüft nur, was sich aus dem Code ableiten lässt. Nicht, ob eine Anweisung inhaltlich noch stimmt.

Ein Beispiel aus dem Beitrag: Das PostHog-Team hatte in der AGENTS.md notiert, dass alle Merges in master über die Trunk-Merge-Queue laufen müssen und gh pr merge nie ausgeführt werden darf. Nach ein paar Tagen pausierte das Team die Queue, um fehlgeschlagene Tests zu beheben – und vergaß, die Anweisung zu aktualisieren. Die Agents arbeiteten 21 Stunden lang mit falschen Vorgaben. Ein Pull-Request hing zehn Stunden fest, ein anderer Entwickler verlor 45 Minuten bei der Fehlersuche. claude doctor hätte das nicht erkannt: Der Zustand der Queue liegt in einer GitHub-Einstellung, nicht im Code.

Die Empfehlung: Führe claude doctor nach jedem Update aus, lies die Datei danach aber selbst noch einmal durch. Für jede Zeile gilt: Kann ich genau benennen, welchen Fehler sie verhindert? Wenn nicht, streiche sie. Diese Regel ist einfach und überraschend wirkungsvoll.

Methode 2: Evals als Regressionstests für deinen Kontext

Die zweite Methode überträgt ein bekanntes Konzept aus der Softwareentwicklung auf den Kontext: Evals. Beim Beheben eines Bugs schreibst du einen Regressionstest. Beim Korrigieren deiner AGENTS.md legst du eine Prüfung an, die den ursprünglichen Fehler abfängt. Mit der Zeit entsteht so eine Test-Suite für die teuersten Kontextpassagen.

PostHog nutzt das in aufwendiger Form. Das Team betreibt einen wizard-ci, der den Onboarding-Wizard auf etwa 40 Beispiel-Apps laufen lässt und für jede App einen Pull-Request erstellt. Ein zweiter Agent, der pr-evaluator, bewertet diese PRs anhand der Diffs und Session-Logs. Das deckt Schwachstellen auf, etwa wenn der Wizard die Installation von PostHog überspringt, weil er fälschlich annimmt, das SDK sei schon vorhanden. So werden technische Fallstricke aus echten Läufen zu konkreten Anweisungen in den Kontextdateien.

Du musst diese Infrastruktur nicht nachbauen. Der Kern ist einfach: Jedes Mal, wenn ein Agent einen Fehler macht, nimm den Prompt, der ihn ausgelöst hat, und lege ihn in einer failures.md ab. Beim nächsten Umbau deiner AGENTS.md führst du diese Prompts erneut aus. So bekommst du schnell eine Rückmeldung, ob deine Streichungen den Fehler wieder ermöglichen. Ein pragmatischer Weg, Vertrauen in das Kürzen zu gewinnen.

Methode 3: Agents selbst nach Feedback fragen

Die dritte Methode ist fast zu naheliegend: Frag den Agenten. Agents können gut beschreiben, welche Informationen ihnen gefehlt haben oder welche Anweisungen verwirrend waren. Viele Entwickler nutzen das für Skills. Man kann es zur Standardroutine machen, indem man es direkt in den Prompt schreibt.

Beim PostHog-Wizard ist die letzte Anweisung, dass der Agent einen kurzen Kommentar über aufgetretene Fehler hinterlässt. Die Frage lautet ungefähr: Welche Information oder Anleitung wäre bei dieser Aufgabe nützlich gewesen, um Werkzeugfehler, falsche Bearbeitungen oder verschwendete Versuche zu verhindern? Daraus entsteht ein kontinuierlicher Strom von Fehlerberichten – eine einfache Form von AI-Observability.

Das Team geht noch weiter: Die Rückmeldungen werden in eine Art context-mill eingespeist, die daraus neue Anweisungen generiert. Wichtig ist die Verifikation, denn Agents sind nicht immer präzise. Die Rückmeldungen werden geclustert. Bei auffälligen Mustern wird ein Subagent losgeschickt, um das Problem nachzuvollziehen. Erst dann wird versucht, es zu beheben. Für dich reicht es, Agents in deinen Prompts zu bitten, die verwendeten Kontextdateien zu notieren. In Pull-Request-Vorlagen kann das ausreichen, um Inkonsistenzen zu entdecken.

Was du konkret für deine AGENTS.md tun kannst

Es geht nicht darum, deine AGENTS.md pauschal zu löschen. Behandle den Kontext als wartbares Produkt. Eine Datei, die einmal richtig war, kann kurz darauf schädlich sein. Die Werkzeuge dafür sind mechanisch, empirisch und sozial. Wer alle drei kombiniert, bekommt ein System, das sich selbst verbessert.

Der Aufwand ist überschaubar. Der erste Schritt: ein Termin mit claude doctor und eine ehrliche Revision deiner Regeln. Der zweite Schritt: eine failures.md, in der du zu jedem gemeldeten Agentenfehler den auslösenden Prompt festhältst. Der dritte Schritt: eine Frage an deinen Agenten – im Alltag, nicht nur in Testläufen.

Das ersetzt keine gesunde Skepsis. Vertrau keinem Bericht blind, auch nicht dem von claude doctor. Aber nutze die Signale, um deinen Kontext so schlank zu halten, dass die Modelle ihre Stärken ausspielen können. Das Ziel ist nicht, keine AGENTS.md zu haben, sondern eine, die nur das enthält, was ein modernes Modell nicht selbst erkennen kann.

Quelle: newsletter.posthog.com