Kategorie: Erklärer

Ein verschlüsseltes Denkblock-Fragment einer KI wird in eine schwächere Modell-Sitzung eingespielt. Statt des erwarteten kryptischen Rauschens erscheint der komplette versteckte Reasoning-Verlauf als Klartext. Das ist keine Magie, sondern eine Sicherheitslücke, die Forscher öffentlich gemacht haben.

Große Sprachmodelle wie ChatGPT, Claude oder Gemini zeigen ihre internen Denkschritte nicht mehr offen. Sie liefern verschlüsselte Blöcke, die angeblich nur das Modell selbst lesen kann. Doch diese Verschlüsselung ist löchrig wie ein Schweizer Käse.

Wie die Forscher die Verschlüsselung umgehen

Die Gruppe um Alexander Panfilov hat einen Angriff entwickelt, der auf den ersten Blick einfach wirkt. Sie nehmen den verschlüsselten Reasoning-Block, den ein teures Modell erzeugt hat, und spielen ihn in eine schwächere, aber ähnliche Modellvariante desselben Anbieters ein. Dazu verwenden sie einen Jailbreak-Prompt, der das schwächere Modell dazu bringt, den Inhalt des Blocks zu transkribieren.

Das funktioniert, weil diese Blöcke portabel sind – sie lassen sich außerhalb ihres ursprünglichen Kontexts wiederverwenden. Das Angriffsziel ist nicht das starke Modell selbst, sondern sein kleiner Bruder, der leichter zu manipulieren ist. Und genau dort werden die Gedanken des großen Bruders ausgeplaudert.

Die Forscher demonstrieren das anhand von 120 Codeforces-Aufgaben. Sie verglichen die versteckten Denk-Token-Zahlen mit den dekodierten Token-Längen. Die Übereinstimmung ist fast perfekt – die Punkte liegen auf der Diagonalen bis an die Grenze des Generierungslimits von 12.000 Token.

Warum die Blöcke überhaupt existieren

Warum schickt ein KI-Anbieter überhaupt einen verschlüsselten Block an den Client? Der Grund ist ein Schutz vor Modell-Destillation, also dem Versuch, die Fähigkeiten eines teuren Modells durch Abfragen zu kopieren. Die Idee: Wenn der Client die Gedanken nicht lesen kann, kann er sie auch nicht weiterverarbeiten.

Diese Logik hat einen Haken: Der Block muss zurück zum Server geschickt werden, wenn das Gespräch weitergeht. Die Anbieter vertrauen darauf, dass niemand den Block manipuliert. Genau das nutzen die Forscher aus. Sie spielen den Block nicht an das ursprüngliche Modell zurück, sondern an ein schwächeres Geschwistermodell, das weniger Sicherheitsvorkehrungen hat.

Das Ergebnis ist ein klassischer Replay-Angriff – nur eben auf die KI selbst. Die Verschlüsselung schützt vor direkter Manipulation, nicht vor der Verwendung eines ungeschützten Lese-Ziels.

Vom Denken zur Datenpanne: Secrets in den Traces

Die Forscher gingen noch einen Schritt weiter. Sie sammelten 6.708 öffentlich verfügbare Agent-Trajektorien von GitHub und Hugging Face – also tatsächliche KI-Ausführungen, die echte Aufgaben lösen. In diesen Traces fanden sie 351 verschiedene geleakte Objekte: 204 technische Identifikatoren, 126 persönliche Daten und 23 Zugangsdaten.

Wenn eine KI mit einem Tool interagiert, speichert sie oft sensible Informationen in ihrem Reasoning. Und wenn dieses Reasoning verschlüsselt, aber wiederverwendbar ist, wird es zum Sicherheitsrisiko. Ein Angreifer könnte einen API-Key aus einem öffentlichen Trace extrahieren, ohne das ursprüngliche Modell zu attackieren.

Die Angriffsfläche ist real. Viele Unternehmen setzen Agenten ein, die auf Code-Repos, Datenbanken oder Ticketsysteme zugreifen. Wenn diese Agenten ihren Denkprozess protokollieren, wird das zur Goldgrube für Angreifer – sofern sie die Verschlüsselung wie oben beschrieben umgehen.

Was die gelösten Aufgaben über die Methode verraten

Ein bemerkenswertes Detail der Studie ist die Vielfalt der extrahierten Inhalte. In den Denk-Traces tauchen nicht nur allgemeine Textantworten auf, sondern konkrete algorithmische Lösungen – etwa für Max-Flow-Probleme mit Zeitexpansion oder BFS-basierte Infektionsausbreitung. Du kennst das vielleicht von Plattformen wie Codeforces: Dort entwickelt man unter Zeitdruck einen Algorithmus.

Die Forscher zeigen, dass die entschlüsselten Gedanken exakt den Lösungsweg enthalten – inklusive der Überlegungen zu Zeitfenstern, Pfad-Suche und Optimierung. Nimm die Aufgabe, eine Infektionszeit für Laborzellen zu berechnen: Ein Max-Flow-Modell mit Zeitexpansion ist die Standardmethode. In den gestohlenen Gedanken findest du die exakte BFS-Logik, die der KI durch den Kopf ging, bevor sie die Antwort formulierte.

Auch kombinatorische Probleme sind darunter, etwa die Zählung von Strings mit minimalen Ziffernhäufigkeiten. Die KI denkt über Multinomial-Koeffizienten nach, baut Polymere aus Fakultäten und minimiert letztlich die Zahl. Das ist nicht nur für Wettbewerbsprogrammierer interessant – es zeigt, dass die verschlüsselten Blöcke vollständige Lösungswege enthalten, nicht nur vage Notizen.

Die Sicherheitslücke ist prinzipiell

Was bedeutet das für die Branche? Die Forscher haben bewiesen, dass die Verschlüsselung von Reasoning-Traces keinen Schutz vor Extraktion bietet, solange ein schwächeres Modell derselben Modellfamilie existiert. Solange Anbieter wie OpenAI, Anthropic oder Google mehrere Modellgrößen anbieten, bleibt dieser Angriffsvektor offen.

Die naheliegende Gegenmaßnahme wäre, die Blöcke modell- oder sitzungsgebunden zu machen – also eine Signatur einzuführen, die den Empfänger festlegt. Doch das ist leichter gesagt als getan, schließlich müssen die Blöcke auch bei Kontextverlust noch funktionieren. Eine andere Lösung wäre, die Blöcke gar nicht erst an den Client zu senden, sondern nur auf dem Server zu halten – aber das kollidiert mit der Architektur vieler Produkte.

Für dich als Entwickler oder KI-Nutzer heißt das: Sei vorsichtig, welche Daten du durch einen KI-Agenten schickst. Wenn er mit sensiblen Systemen interagiert, nimm an, dass sein Reasoning abrufbar ist – auch wenn die API eine Verschlüsselung verspricht. Der Schutz durch Verschlüsselung ist nur so gut wie das schwächste Modell im selben Ökosystem.

Die Studie ist ein Weckruf. Sie zeigt, dass Sicherheit nicht durch obskure Kryptographie erreicht wird, sondern durch durchdachte Architektur und die Einschränkung von Wiederverwendbarkeit. Bis dahin gilt: Die Gedanken der stärksten KI sind offen für alle, die den Replay-Trick beherrschen.

Quelle: stolen-thoughts.com

Ein Datenbankadministrator starrt auf sein Monitoring-Dashboard. Die Kurve für Transaktionen pro Sekunde fällt abrupt von rund 7.200 auf 160 ab – ohne dass ein Deployment, ein Schema-Change oder ein Hardware-Problem vorliegt. Er prüft die Replikationsverzögerung, die CPU-Last, die I/O-Werte – alles normal. Erst nach einer Stunde normalisiert sich der Wert wieder. Was ist passiert? Ein einzelner Prozess hat eine Subtransaktion eröffnet, die mehr als 64 verschachtelte Blöcke mit EXCEPTION-Handling durchlief. Genau daran krankt PostgreSQL – und es kann noch schlimmer kommen.

Subtransaktionen sind in PostgreSQL ein mächtiges Werkzeug: Sie erlauben es, innerhalb einer größeren Transaktion Rücksprungpunkte zu setzen. Ein Anwendungsentwickler nutzt sie über SAVEPOINT-Anweisungen, und PL/pgSQL verwendet sie automatisch für jeden Block mit einer EXCEPTION-Klausel. Sinnvoll? Ja. Aber wenn eine einzelne Transaktion zu viele Subtransaktionen aufstapelt, verändert sich das Verhalten des gesamten Datenbanksystems. Zudem kann eine neue Read Replica dauerhaft blockiert werden, obwohl sie die WAL-Daten weiterhin repliziert.

Wie Subtransaktionen entstehen und was sie bewirken

Eine Subtransaktion ist eine Transaktion innerhalb einer Transaktion. Du startest sie implizit mit SAVEPOINT oder in PL/pgSQL, sobald ein Block eine EXCEPTION-Klausel enthält. Jede Subtransaktion erhält eine eigene Transaktions-ID (XID). Das System muss diese IDs verwalten, um atomares Verhalten zu garantieren. Dazu hält jeder Backend-Prozess eine Liste der aktiv zugewiesenen Subtransaktions-IDs im Arbeitsspeicher – den sogenannten Subtransaktions-Cache.

Dieser Cache hat eine feste Größe: PGPROC_MAX_CACHED_SUBXIDS, in der Regel 64. Wenn du also mehr als 64 Subtransaktionen in einer einzigen Top-Level-Transaktion anlegst – explizit oder über Schleifen mit EXCEPTION-Blöcken –, platzt der Cache. PostgreSQL markiert den Cache als überlaufen. Ab diesem Moment kann keine Snapshot-Berechnung mehr alle aktiven Subtransaktions-IDs vollständig erfassen. Das bleibt nicht lokal – die Auswirkung greift auf alle Backends und sogar auf Read Replicas über.

WAL-Replikation und die Rolle der RUNNING_XACTS-Einträge

Um zu verstehen, warum ein Subtransaktions-Overflow eine Replica blockieren kann, musst du kurz die Replikationsarchitektur von PostgreSQL kennen. Die primäre Instanz schreibt alle Änderungen sequenziell in das Write-Ahead Log (WAL). Dieses Log dient als Grundlage für Crash-Recovery, wird aber auch an Replikas gestreamt. Eine Read Replica empfängt den WAL-Stream, dekodiert die Records und wendet sie auf ihre eigene Datenbasis an. Das ist der physikalische Teil der Synchronisation.

Doch für eine konsistente Sicht auf die Daten muss die Replica zusätzlich wissen, welche Transaktionen auf dem Primary noch aktiv sind. Dafür gibt es spezielle WAL-Records: RUNNING_XACTS. Sie werden vom Primary in regelmäßigen Abständen in den WAL-Stream eingefügt. Sie enthalten eine Momentaufnahme der laufenden Transaktionen, inklusive der IDs der aktiven Top-Level-Transaktionen und ihrer Subtransaktionen. Erst wenn eine Replica einen solchen Record verarbeitet hat, kann sie lesenden Zugriff erlauben – sofern Hot Standby aktiviert ist.

Der Trick: Eine Replica startet aus einem Base-Backup und muss den WAL-Stream ab dem Checkpoint des Backups anwenden. Ohne ein RUNNING_XACTS-Record fehlt ihr der Kontext, welche Transaktionen schon vor dem Checkpoint liefen. Deshalb wird dieses Record gezielt injiziert. Solange die Replica einen sauberen, nicht überlaufenen RUNNING_XACTS-Record verarbeitet, kann sie den Zustand aller Transaktionen nachvollziehen und sicher lesen.

Der Subtransaktions-Cache und sein Overflow

Jeder Backend-Prozess verwaltet seinen eigenen Cache mit den XIDs der aktuell verschachtelten Subtransaktionen. Die vollständige Zuordnung von Subtransaktionen zu ihrer Top-Level-Transaktion liegt in der Systemtabelle pg_subtrans, die auf der Platte liegt und über einen SLRU-Cache abgefragt wird. Solange die Anzahl der Subtransaktionen unter der Cache-Grenze liegt, ist alles schnell. Überschreitet sie die Grenze, wird der Cache als „overflowed“ markiert.

Ein Überlauf hat eine kritische Eigenschaft: Er wirkt global. Wenn irgendein Backend auf dem Primary einen Overflow meldet, wird jede danach erzeugte RUNNING_XACTS-Record ebenfalls als overflowed markiert – selbst wenn andere Transaktionen völlig sauber sind. Das liegt daran, dass das Record nur eine Momentaufnahme aller aktiven Transaktionen liefert. Fehlt einem davon die vollständige Subtransaktions-ID-Liste, ist das gesamte Bild unvollständig. Dadurch wird jeder Snapshot, der auf einer solchen Basis aufbaut, ebenfalls als overflowed behandelt.

Cluster-weite Leistungsprobleme durch einen einzigen Overflow

Was passiert konkret mit der Performance? Wenn eine Query eine Zeile liest, muss sie prüfen, ob die Transaktions-ID der Zeile (xmin oder xmax) in der Menge der abgeschlossenen oder aktiven Transaktionen liegt. Dazu wird der Snapshot herangezogen, der normalerweise alle relevanten IDs in einem kompakten Format enthält. Bei einem overflowed Snapshot fehlen jedoch einige Subtransaktions-IDs. Das System muss dann bei jeder Abfrage der pg_subtrans-Tabelle nachschlagen, um die fehlende Zuordnung zu ermitteln – ein teurer Prozess, der SLRU-Locks benötigt und bei hoher Last sogar Disk-I/O auslöst.

Ein einzelner Overflow kann also dazu führen, dass alle Queries auf dem Cluster langsamer werden, selbst wenn sie gar keine Subtransaktionen nutzen. In Benchmarks wurde ein Einbruch der TPS von über 95 Prozent beobachtet. Der Overhead entsteht durch das ständige Nachschlagen in pg_subtrans und die damit verbundenen Lock-Konflikte. Der Effekt ist nicht nur messbar, sondern erstreckt sich über alle Datenbanken, weil SLRU-Locks global sind. Ein einzelner Savepoint-Stapel kann also die Produktivität des gesamten Clusters zerstören.

Warum neue Read Replicas keine Verbindungen annehmen

Die zweite Gefahr betrifft Read Replicas, die während eines Overflows hinzugefügt werden. Sie beziehen ihr Base-Backup vom Primary und beginnen, den WAL-Stream abzuspielen. Wenn sie dabei auf einen overflowed RUNNING_XACTS-Record stoßen, können sie sich kein konsistentes Bild der laufenden Transaktionen machen. Sie wissen nicht, welche Subtransaktionen unterhalb der Grenze existierten. Aus Sicherheitsgründen versetzt PostgreSQL die Replica in den Status STANDBY_SNAPSHOT_PENDING – sie setzt das WAL-Replay fort, erlaubt aber keine Leseabfragen.

Die Replica bleibt in diesem Zustand, bis einer von drei Fällen eintritt: Sie erhält ein vollständiges, nicht überlaufenes RUNNING_XACTS-Record, sie replayt ein Shutdown-Checkpoint, der garantiert, dass keine Transaktionen aktiv sind, oder sie wartet, bis alle Transaktionen, die zum Zeitpunkt des Overflow-Events aktiv waren, abgeschlossen sind. Das kann Minuten oder Stunden dauern. Für einen Administrator, der gerade eine Read Replica hochgefahren hat, um Last abzufangen, ist das ein fataler Schlag: Die Replica wird nicht lesbar, obwohl sie WAL fleißig anwendet.

Was du tun kannst, um Probleme zu vermeiden

Das erste und einfachste Gegenmittel ist, die Anzahl der Subtransaktionen pro Transaktion zu begrenzen. In PL/pgSQL vermeidest du durch Refactoring, dass Schleifen mit EXCEPTION-Klauseln zu viele Subtransaktionen erzeugen. Vermeide EXCEPTION-Blöcke in Schleifen oder fasse sie in separate Funktionen zusammen. Oft lässt sich Logik ohne verschachtelte SAVEPOINTs umsetzen.

Falls du keine Kontrolle über den Code hast, kannst du überwachen, wie viele Subtransaktionen ein Backend erzeugt. PostgreSQL liefert in den Statistiken des pg_stat_database die Zahl der Subtransaktionen, und pg_stat_statements gibt Hinweise auf problematische Queries. Behalte außerdem die Anzahl der gleichzeitig aktiven Transaktionen im Auge – ein einzelner Prozess kann den ganzen Cluster beeinflussen. Einen Parameter, um den Overflow zu verhindern, gibt es derzeit nicht; du kannst nur durch Code-Richtlinien oder Query-Rewriting gegensteuern.

Für das DBA-Team bedeutet das: Teste deine Anwendungen gezielt auf dieses Muster. Simuliere eine Transaktion mit mehr als 64 Subtransaktionen und beobachte die Wirkung auf dein Cluster. Nur so stellst du sicher, dass ein solcher Ausfall nicht in der Produktion passiert. Es ist ein versteckter Fallstrick – aber mit den beschriebenen Mechanismen kennst du die Risiken und kannst sie vermeiden.

Quelle: planetscale.com

Ein Sicherheitsingenieur eines mittelständischen Unternehmens öffnet das Dashboard seiner Cloud-Umgebung und liest die neuesten Sicherheitsupdates. Er stößt auf eine unscheinbare Ankündigung mit weitreichenden Folgen: Google Cloud will seine gesamte Infrastruktur bis 2029 auf quantenresistente Kryptographie umstellen. Die Roadmap dazu ist jetzt veröffentlicht – ein Signal, wie ernst die Bedrohung durch künftige Quantencomputer genommen wird.

Heutige Verschlüsselung könnte in zehn oder fünfzehn Jahren wertlos sein. Ein Quantencomputer mit ausreichender Leistung würde die mathematischen Grundlagen aktueller Verfahren aushebeln. Google arbeitet seit einem Jahrzehnt daran, diese Bedrohung zu entschärfen. Nun liegt ein konkreter Fahrplan vor. Du musst nicht warten, bis es zu spät ist. Die Migration beginnt jetzt – und du kannst dich beteiligen.

Die Bedrohung: Was ist Post-Quanten-Kryptographie?

Deine Haustür hat ein Schloss, das bisher als unknackbar gilt. Ein Dieb entwickelt ein Werkzeug, das es in Sekunden öffnet – spurlos. Genau das droht der heutigen Verschlüsselung durch einen kryptografisch relevanten Quantencomputer. Die Algorithmen, die heute Daten schützen – RSA oder ECC – basieren auf mathematischen Problemen, die klassische Computer kaum lösen. Ein Quantencomputer nutzt die Gesetze der Quantenmechanik, um diese Probleme in überschaubarer Zeit zu knacken.

Post-Quanten-Kryptographie (PQC) umfasst neue Verfahren, die auch Quantenangriffen standhalten. Sie beruhen auf anderen mathematischen Strukturen, die selbst für Quantenrechner schwer zu durchbrechen sind. Die US-amerikanische Standardisierungsbehörde NIST hat mehrere Algorithmen verabschiedet: ML-KEM für Schlüsselaustausch, ML-DSA und SLH-DSA für Signaturen. Das ist keine Zukunftsmusik mehr. Die Verfahren werden bereits in Produkten eingesetzt – auch bei Google Cloud.

Nur: Die Umstellung dauert Jahre. Kein Schalter, der alle Systeme auf neue Algorithmen umlegt. Es braucht durchdachte Migrationen, Tests, Übergangsstrategien. Google Cloud hat eine Roadmap veröffentlicht, die Schritt für Schritt zeigt, wann welche Dienste auf PQC umgestellt werden.

Drei Verteidigungslinien: Die Strategie von Google Cloud

Google gliedert seine Sicherheitsstrategie in drei Bereiche. Der erste heißt „Store Now, Decrypt Later“ (SNDL): Ein Angreifer fängt heute verschlüsselte Daten ab und speichert sie, um sie später mit einem Quantencomputer zu entschlüsseln. Das betrifft vor allem asymmetrische Verschlüsselung bei TLS-Verbindungen und Datenübertragung. Die zweite Verteidigungslinie betrifft Integrität und Nichtabstreitbarkeit: Digitale Signaturen müssen so gestärkt werden, dass ein Quantencomputer sie nicht fälschen kann. Die dritte Linie sind die Grundlagen: kryptografische Agilität und Schlüsselverwaltung.

Diese drei Bereiche greifen ineinander. Du baust heute sichere Verbindungen auf – ML-KEM kommt ins Spiel. Du lieferst Software aus – du brauchst quantensichere Signaturen. Du verwaltest Schlüssel – das System muss flexibel genug sein, um auf neue Algorithmen umzusteigen. Google hat für jeden Bereich konkrete Meilensteine festgelegt, die bis 2027 beziehungsweise 2028 erreicht sein sollen.

Kryptografische Agilität ist zentral. Die IT-Welt hat aus Fehlern gelernt: Wird ein Algorithmus gebrochen, muss man schnell auf Alternativen wechseln. Google setzt auf modulare Systeme, in denen kryptografische Bausteine austauschbar sind. Das ist wie bei einem Leitungssystem, bei dem du einzelne Rohre austauschst, ohne das Gebäude abzureißen.

Der Zeitplan: Was passiert bis 2026 und darüber hinaus?

Die meisten Dienste sollen bis Ende 2027 die SNDL-Mitigation abgeschlossen haben. Einige Meilensteine sind bereits erreicht: Die API-Endpunkte von Google Cloud – google.com und .googleapis.com – unterstützen jetzt ML-KEM in hybriden Modi. Eingehende Verbindungen sind gegen zukünftige Quantenangriffe geschützt. Auch die Application- und Proxy-Load-Balancer bieten quantensicheren Schlüsselaustausch per X25519MLKEM768 – zunächst als Opt-in, damit Kunden die Migration testen können.

Bis 2026 folgen weitere Komponenten. Cloud VPN, Cloud Interconnect, Google Compute Engine OS Login, Cloud SDK und die gcloud CLI werden auf quantensichere Algorithmen umgestellt. Auch Datenpipelines wie Cloud Storage SDK, Storage Transfer Service und BigQuery CLI sind geplant. Ziel: den Datenfluss für Administratoren und Entwickler vollständig abzusichern.

Die Migration endet nicht 2026. Für Integrität und Signaturprüfung hat Google bis 2028 Zeit. Es geht um die Absicherung der Software-Lieferkette: Dienste wie Binary Authorization, Cloud Build und Assured Open Source Software sollen nur noch signierte, unveränderte Software ausführen. Google plant außerdem Merkle-Tree-Zertifikate, um die großen Signaturgrößen der PQC-Verfahren zu bewältigen. Hier arbeitet Google eng mit dem IETF zusammen – die Standards sind noch nicht fertig.

Bis 2029 soll die gesamte Cloud-Infrastruktur PQC-fest sein. Danach geht es weiter: Die Branche erwartet, dass die alten Algorithmen zwischen 2030 und 2035 endgültig abgeschaltet werden – gemäß CNSA 2.0 und NIST IR 8547. Die Umstellung ist kein einmaliges Projekt. Sie erstreckt sich über das kommende Jahrzehnt.

Was bedeutet das für deine Cloud-Workloads?

Nutzt du Google Cloud, fragst du dich: „Muss ich etwas tun?“ Ja, aber du hast Zeit. Die Infrastrukturebene schützt dich bereits automatisch: API-Endpunkte und Load-Balancer, die PQC unterstützen, sichern deine Verbindungen – ohne dein Zutun. Für tiefere Absicherung, etwa bei der Verwaltung deiner Ressourcen, solltest du aktiv werden.

Eine einfache Maßnahme: Verwende die neuesten Client-Versionen und SDKs. Google integriert PQC in Bibliotheken wie Tink und BoringSSL. Hältst du diese aktuell, erhältst du automatisch die neuen Verschlüsselungsmechanismen. Bei Cloud KMS sind die NIST-standardisierten Algorithmen ML-KEM, ML-DSA und SLH-DSA bereits allgemein verfügbar. Du kannst also schon jetzt Schlüssel mit diesen Verfahren erzeugen. Der Import externer Schlüssel (BYOK) folgt 2026.

Überprüfe deine eigenen Sicherheitsrichtlinien. Nutzt du digitale Signaturen für CI/CD-Pipelines, prüfe, ob die Zertifikate später auf PQC umgestellt werden können. Google bietet mit Binary Authorization bereits Ansätze, um nur signierte Images zuzulassen – diese Funktionen werden bis 2026 auf PQC umgestellt. Es ist sinnvoll, sich mit den neuen Algorithmen vertraut zu machen und Testumgebungen einzurichten, um den Wechsel zu üben.

Selbst ohne kritische Daten in der Cloud lohnt die Vorbereitung. Die Umstellung kommt nicht über Nacht, aber sie kommt. Wer sich früh damit beschäftigt, vermeidet späteren Stress – und schützt seine Daten von Anfang an.

Ein gemeinsamer Weg: Verantwortung teilen

Quantensicherheit schultert kein einzelnes Unternehmen allein. Google betont: Sicherheit war immer eine gemeinsame Verantwortung von Anbieter und Kunde. Der Anbieter kümmert sich um Infrastruktur – Server, Netzwerke, globale Front-Ends, das interne Protokoll ALTS. Du als Kunde bist verantwortlich für die Anwendungen, die du in die Cloud stellst, und für die Konfiguration deiner Umgebung. Du musst die neuen Standards in deinem eigenen Code und deinen Prozessen implementieren.

Google arbeitet mit Partnern an Lösungen für Sovereign Clouds – etwa Google Cloud Dedicated und Google Distributed Cloud. Diese richten sich an Unternehmen mit strengen regulatorischen Anforderungen, etwa im öffentlichen Sektor oder Gesundheitswesen. PQC ist dort besonders wichtig, weil Daten über lange Zeit geschützt bleiben müssen.

Für dich heißt das: Überlege, welche Daten besonders schützenswert sind und wie lange sie relevant bleiben. Speicherst du medizinische Daten oder geistiges Eigentum, das in 20 Jahren noch geschützt sein muss, ist PQC kein Nice-to-have, sondern ein Muss. Die Roadmap von Google Cloud liefert den Zeitplan.

Niemand weiß genau, wann ein leistungsfähiger Quantencomputer gebaut wird. Wir wissen, dass die Umrüstung der bestehenden Infrastruktur dauern wird. Deshalb ist es klug, jetzt zu handeln – aus Weitsicht, nicht aus Panik. Die Werkzeuge sind da, die Standards sind gesetzt, die Cloud-Anbieter zeigen den Weg. Du musst nur mitgehen.

Quelle: cloud.google.com

Ein Forscher starrt auf den Bildschirm seines Rechenclusters, während zwei Sprachmodelle parallel trainieren. Die Verlustkurven überlagern sich fast perfekt – obwohl eines von ihnen eine komplette Schichtengruppe vermissen lässt. Genau das beobachtete Henry Ndubuaku bei seiner Studie über Attention-Only-Transformer. Sein Ergebnis: Modelle, die ausschließlich auf Aufmerksamkeitsmechanismen setzen und auf Feed-Forward-Netze verzichten, kommen Standard-Transformatoren sehr nahe. Was bedeutet das für die Architektur von KI-Modellen?

Die Ausgangslage: Zwei Drittel der Parameter sind Feed-Forward

In einem typischen Transformer stecken etwa zwei Drittel der nicht-Embedding-Parameter in den Feed-Forward-Schichten. Das sind die Teile, die nach der Aufmerksamkeitsoperation jede Repräsentation linear transformieren und mit einer nichtlinearen Aktivierung versehen. Die Aufmerksamkeit selbst – mit ihren Query-, Key- und Value-Matrizen – macht nur ein Drittel aus. Seit 2017 galten Feed-Forward-Schichten als unverzichtbar, um komplexe Muster zu lernen. Viele Arbeiten haben ihre Funktion untersucht, aber ein direkter Test, der Parameter, Rechenaufwand und Tiefe gleichzeitig kontrolliert, fehlte. Diese Lücke schließt die neue Studie.

Die Forscher um Ndubuaku trainieren sogenannte Attention-Only-Transformer, die sie Simple Attention Networks (SANs) nennen. Diese Modelle enthalten nur Aufmerksamkeitsblöcke: Die Eingabe wird durch self-attention verarbeitet, dann normalisiert, aber die anschließende Feed-Forward-Transformation entfällt. Das spart Parameter und Rechenaufwand. Für einen fairen Vergleich konstruierten sie die Modelle so, dass sie entweder die gleiche Parameteranzahl, die gleiche Anzahl an Training-FLOPs oder die gleiche Tiefe wie ein Standard-Transformer haben. Dazu variierten sie die Dimensionen und die Anzahl der Aufmerksamkeitsköpfe.

Die Trainingsläufe umfassen Modelle mit 6 bis 87 Millionen Parametern und bis zu 48 Schichten. Die Tokenzahlen reichen bis 105 Milliarden – das ist ein umfangreiches Pretraining, auch wenn es deutlich weniger ist als bei den größten kommerziellen Modellen. Die Architektur der SANs ist simpel: Jede Schicht besteht aus Multi-Head-Self-Attention plus Layer-Normalisierung. Um tiefe Stapel trainierbar zu machen, verwenden sie eine QK-Normalisierung, also eine Normierung der Query- und Key-Matrizen. Diese Technik ist in modernen Transformatoren üblich.

Die Ergebnisse: Die Lücke schrumpft auf ein Minimum

Die naheliegende Erwartung ist, dass das Entfernen der Feed-Forward-Schichten die Leistung deutlich verschlechtert. Und tatsächlich zeigt sich dieser Effekt, wenn man die Tiefe konstant hält: Ein Standard-Transformer mit gleich vielen Schichten hat einen Vorteil von 0,47 nats im Vorhersageverlust. Das ist ein spürbarer Unterschied. Doch dieser Vergleich ist unfair, weil die Modelle dann unterschiedlich viele Parameter haben. Gleicht man die Parameterzahl aus, indem man die Attention-only-Modelle tiefer oder breiter macht, ändert sich das Bild. Bei gleicher Parameteranzahl beträgt der Unterschied nur noch 0,006 nats – das sind 0,27 Prozent des Gesamtverlusts. Diese Differenz ist so klein, dass sie bei wiederholten Läufen mit verschiedenen Seeds auf ein Zehntausendstel genau reproduzierbar ist.

Die Differenz von 0,006 nats bleibt über Budgets von 5, 30 und 105 Milliarden Token nahezu konstant. Sie schrumpft leicht, je größer das Budget wird. Attention-only-Modelle fallen mit mehr Daten also nicht ab, sondern holen minimal auf. Auch die Modellgröße spielt kaum eine Rolle: Über einen Bereich von 29-facher Parametergröße bleibt der Unterschied bei etwa 0,02 nats. Das ist bemerkenswert stabil.

Warum? Die Autoren erklären es mit der Umverteilung des Budgets. Entfernt man die Feed-Forward-Schichten, hat man bei konstanter Parameterzahl die Möglichkeit, mehr Aufmerksamkeitsschichten einzufügen. Diese zusätzliche Tiefe gleicht den Verlust der Feed-Forward-Kapazität fast vollständig aus. Es scheint, als sei die Aufmerksamkeit selbst in der Lage, einen Großteil der Funktionen zu übernehmen, die man normalerweise den Feed-Forward-Schichten zuschreibt. Genauer: Die Gewichtsspektren zeigen, dass sich die Routing-Matrizen (Q und K) früh im Training kristallisieren, während die Content-Matrizen (V und die Ausgabeprojektion) langsam an Rang gewinnen. Ohne Feed-Forward-Schichten verlagert sich dieser Rangaufbau in die Ausgabeprojektion der Aufmerksamkeit. Das Modell kompensiert die fehlende nichtlineare Transformation durch eine Kombination vieler Aufmerksamkeitsschichten.

Wo bleibt die Schwäche? Bei eingebettetem Wissen

Die fast verschwindende Differenz überrascht, aber sie ist nicht null. Die Autoren haben drei Messungen durchgeführt, um den Rest der Lücke zu lokalisieren. Dabei zeigt sich ein klares Muster: Attention-only-Modelle sind besser als Standard-Transformer bei Aufgaben, die sich direkt auf den gegebenen Kontext stützen – etwa beim Verständnis längerer Textpassagen oder beim Befolgen von Anweisungen. Sie sind schlechter, wenn die Antwort aus dem gespeicherten Wissen der Modellgewichte kommt – also bei Faktenabfragen ohne unmittelbaren Kontext. Dieser Unterschied wird mit zunehmendem Trainingsbudget deutlicher: Bei 105 Milliarden Token konzentriert sich der komplette Leistungsnachteil auf Vorhersagen mit wenig Kontext, bei denen das Modell auf sein „parametrisches Gedächtnis“ angewiesen ist.

Die Autoren nennen das „parametrisches Erinnern“ – die Fähigkeit, während des Trainings gelernte Fakten in den Gewichten zu speichern und bei der Inferenz abzurufen. Feed-Forward-Schichten scheinen dafür besonders wichtig zu sein, da sie Wissen schneller und effizienter komprimieren können. Die Attention-only-Modelle kompensieren einen Teil, aber nicht alles. Das bestätigen auch die Gewichtsspektren: Die Content-Matrizen der Attention akkumulieren langsamer Rang als die Feed-Forward-Matrizen, was auf eine begrenzte Fähigkeit hindeutet, viele Fakten gleichzeitig zu kodieren.

Um diese Hypothese zu untermauern, führten die Forscher einen präregistrierten Test durch. Sie sagten voraus, dass die Differenz auf wissensdichtem Webtext – also Texten mit vielen impliziten Fakten – zwischen 0,02 und 0,05 nats liegen würde. Ein Trainingslauf auf dem fein bereinigten Datensatz fineweb-edu ergab 0,040 nats, was exakt in diesen Bereich fällt. Das stützt die Theorie.

Die Rolle der QK-Normalisierung und die Trainierbarkeit tiefer Stacks

Ein weiteres Ergebnis betrifft die Trainierbarkeit. Attention-only-Transformer ohne QK-Normalisierung werden ab etwa 6 Schichten instabil und konvergieren nicht mehr. Erst die Normalisierung der Query- und Key-Matrizen ermöglicht Stacks mit 48 Schichten. Die Aufmerksamkeit braucht also selbst eine Regulierung, um tiefe Architekturen zu stabilisieren. In Standard-Transformatoren übernehmen die Feed-Forward-Schichten eine ähnliche Rolle, wie frühere Arbeiten zeigen.

Die Untersuchung der Gewichtsspektren liefert eine Erklärung: Die QK-Matrizen kristallisieren früh zu einem stabilen Zustand, während die Content-Matrizen langsam an Rang gewinnen. Ohne Feed-Forward-Schichten muss die Ausgabeprojektion der Attention diese Aufgabe übernehmen, was zu einer langsamen Ranganreicherung führt. Die QK-Normalisierung hält die Dynamik der Aufmerksamkeitsgewichte in einem gesunden Bereich und verhindert, dass die Softmax-Ausgaben in Extremwerte kippen. Das ist ein feines Detail, aber es zeigt, wie wichtig die Interaktion zwischen Architekturkomponenten ist.

Die Studie zeigt also nicht nur, dass Attention fast alles kann, sondern auch, dass die verbleibende Lücke sehr spezifisch ist. Es geht nicht um generelle Sprachfähigkeit oder komplexes Reasoning – hier sind die Attention-only-Modelle ebenbürtig. Der Nachteil liegt ausschließlich in der Fähigkeit, komprimiertes Wissen aus den Gewichten abzurufen. In einer Welt, in der Modelle zunehmend mit externen Wissensquellen (etwa Retrieval-Augmented Generation) arbeiten, könnte dieser Nachteil an Bedeutung verlieren. Wenn man die Fakten im Kontext bereitstellt, sind Attention-only-Modelle sogar besser.

Was bedeutet das für die Praxis?

Die Ergebnisse von Ndubuaku sind keine Aufforderung, sofort auf Feed-Forward-Schichten zu verzichten. Dafür sind sie zu neu und der getestete Bereich zu klein – die größten Modelle haben 87 Millionen Parameter, während kommerzielle Modelle Hunderte von Milliarden aufweisen. Aber die Studie liefert Hinweise für die Architekturentwicklung. Sie zeigt, dass eine bewusste Umverteilung von Parametern zugunsten von Aufmerksamkeitstiefe möglich ist, ohne große Qualitätsverluste. Bei festen Rechenbudgets, etwa für Edge-Geräte oder spezialisierte Anwendungen, könnte man auf Feed-Forward-Schichten verzichten und stattdessen mehr Schichten einbauen, um ähnliche Leistung zu erzielen – besonders wenn der Fokus auf Kontextverständnis liegt.

Die präzise Lokalisierung der Schwäche auf parametrisches Erinnern öffnet neue Forschungsfragen: Kann man diese Fähigkeit gezielt in andere Komponenten verschieben? Oder kann man Attention-only-Modelle mit einem schlanken Zusatzmodul ausstatten, das nur für Faktenwissen zuständig ist? Dass die Differenz bei größeren Trainingsbudgets stabil bleibt, deutet darauf hin, dass es sich nicht um ein reines Skalierungsproblem handelt, sondern um eine strukturelle Grenze. Das ist ein Signal für alle, die an alternativen Transformer-Architekturen forschen.

Für Anwender von KI-Modellen heißt das: Die Aufmerksamkeit ist ein weitaus mächtigerer Mechanismus, als viele angenommen haben. Sie übernimmt nicht nur das Routing von Informationen, sondern leistet auch einen Großteil der nichtlinearen Transformationen, die man den Feed-Forward-Schichten zuschreibt. Ob diese Erkenntnis in neue Modellfamilien einfließt, bleibt abzuwarten. Vielleicht stehen wir am Anfang einer Architektur, die deutlich schlanker ist und dennoch ähnlich gut funktioniert – zumindest in Bereichen, in denen der Kontext alles ist.

Quelle: arxiv.org

Ein Entwickler sitzt in einem fensterlosen Büro und starrt auf ein Diagramm. Links die Kosten in Dollar, rechts die Korrektheit in Prozent. Eine Punktwolke aus verschiedenen Programmiersprachen, mal grün, mal blau markiert – statisch, dynamisch, alles durcheinander. Er hat gerade zwei große Benchmarks abgeschlossen, einen mit einem Kompressionsformat, einen mit einem Dokumentkonverter. Und er fragt sich, ob die vielzitierte Weisheit, dass dynamische Sprachen für KI-Agenten effizienter seien, überhaupt noch Bestand hat.

Diese Frage treibt viele um, die mit LLM-basierten Coding-Agents arbeiten. Die ursprüngliche These klingt verlockend: Dynamische Sprachen wie Python oder Clojure benötigen weniger explizite Typdeklarationen, also weniger Token, also weniger Kosten. Einige Studien zeigten extreme Unterschiede – bis zu 2,6-mal effizienter als C. Doch neuere, größere Experimente zeichnen ein deutlich differenzierteres Bild. Wir schauen uns an, was die Daten wirklich hergeben, und warum einfache Erklärungen selten die ganze Wahrheit sind.

Die Ursprungsbehauptung: Dynamische Sprachen als Token-Sparer

Die oft zitierte Analyse basierte auf trivialen Aufgaben von der Rosetta-Code-Seite. Dort ging es etwa darum, ein paar Zeilen auszugeben oder einfache Algorithmen zu implementieren. Die Ergebnisse schienen klar: Clojure brauchte durchschnittlich 109 Token, C dagegen 300 oder mehr. Noch extremer wurde es mit der Array-Sprache J, die angeblich mit 70 Token pro Problem auskam – weniger als ein Drittel von Rust oder Go. Diese Zahlen verbreiteten sich schnell, nicht zuletzt weil Googles KI-Zusammenfassung sie übernahm.

Doch bei genauem Hinsehen zeigt sich ein bekanntes Problem: Triviale Aufgaben sind kein guter Maßstab. Wenn ein Problem in 70 Token lösbar ist, steckt kaum echte Logik dahinter – meistens nur ein print-Statement. Bei solchen Mini-Aufgaben dominieren syntaktische Unterschiede, nicht die tatsächliche Effizienz der Sprache. Das erinnert an die „Caveman-Mode“-Debatte, bei der extrem einfache Prompts angeblich riesige Geschwindigkeitsvorteile brachten – bis man größere, realistischere Probleme testete. Die Verhältnisse brachen komplett ein.

Der Autor des hier besprochenen Artikels hat deshalb eigene Evals entworfen, und zwar mit Aufgaben, die tatsächlich Arbeit erfordern. Seine Vorab-Vermutungen waren deutlich: mit 95% Wahrscheinlichkeit würde der dynamisch-statisch-Unterschied verschwinden, und mit 98% Wahrscheinlichkeit würde die Überlegenheit exotischer Sprachen wie J sich als Illusion herausstellen. Die Ergebnisse bestätigten diese Skepsis weitgehend.

Zwei eigene Experimente: Zstd und Pandoc

Das erste Experiment verlangte die Implementierung eines vollständigen Dekoders für das Kompressionsformat Zstd, basierend auf der offiziellen RFC-Dokumentation. Die Testsuite war den Agenten nicht bekannt, und es gab keine Internetverbindung. Bei mittlerer Anstrengung („medium effort“) sah es zunächst so aus, als lägen dynamische Sprachen vorn – mehrere von ihnen schafften es in die obere linke Ecke des Kosten-Korrektheit-Diagramms. Doch bei hoher Anstrengung („ultra effort“) drehte sich das Bild: Einige statische Sprachen schnitten plötzlich besser ab, und die Streuung war so groß, dass von einem klaren Muster keine Rede sein konnte.

Das zweite Experiment nutzte das Pandoc-ProgramBench-Eval, bei dem Agenten einen Dokumentkonverter implementieren müssen. Hier wurden die Tests aus der Basisversion zur Verfügung gestellt, aber gegen einen Holdout-Satz bewertet. Wieder zeigte sich: Weder die statisch-dynamische Einteilung noch die Dichte einer Sprache hatte einen signifikanten Einfluss auf Kosten oder Korrektheit. Auffällig war nur, dass obskure Sprachen wie Assembly oder selten genutzte Vertreter erwartungsgemäß schlecht abschnitten – einfach weil die Trainingsdaten der Modelle kaum Beispiele für sie enthalten.

Diese Ergebnisse decken sich mit dem, was man bei anderen Benchmarks beobachtet: Sobald Aufgaben ein wenig Komplexität haben, verwässern sich extreme Token-Unterschiede. Die Agenten müssen mehr Code schreiben, mehr Zwischenschritte abwickeln, mehr Fehler korrigieren. Da spielt es kaum noch eine Rolle, ob eine Sprache Typannotationen erfordert oder nicht. Die oft behaupteten Vorteile von Ruby, Clojure, J oder auch Elixir ließen sich in diesen größeren Tests nicht reproduzieren.

Warum Token-Effizienz überschätzt wird

Es ist verlockend, die Token-Anzahl als den entscheidenden Kostenfaktor zu sehen – schließlich zahlt man bei den meisten LLM-APIs pro Token. Aber die Realität ist komplexer. Ein Coding-Agent verbraucht Token nicht nur für den eigentlichen Code, sondern auch für Zwischenüberlegungen, Fehlermeldungen, Compiler-Ausgaben und Rückfragen. Wenn ein Agent einen Fehler macht und den gleichen Compiler-Fehler zehnmal behebt, wie es bei Codex häufig vorkommt, dann schlägt dieser Overhead weit stärker zu Buche als ein paar fehlende Typdeklarationen.

Hinzu kommt: Die synthetischen Trainings- und Verstärkungslern-Daten, die AI-Labore für Agenten erzeugen, konzentrieren sich auf Mainstream-Sprachen. Python, JavaScript, Java, Go, C++ – dafür gibt es Massen an Daten. Für J oder Clojure fast nichts. Ein Agent, der mit diesen Sprachen arbeiten soll, muss erst mühsam die richtigen Muster lernen, was in der Praxis zu zusätzlichen Token und Fehlern führt. Die in diesem Artikel berichteten Daten zeigen tatsächlich eine schwache bis moderate positive Korrelation zwischen Sprachpopularität und Leistung – populärere Sprachen schnitten billiger und korrekter ab.

Das bedeutet nicht, dass dynamische Sprachen prinzipiell schlecht sind. Aber die einfache Gleichung „weniger Token = besser“ greift nicht. Du solltest also nicht deine gesamte Codebasis auf eine exotische Sprache umstellen, nur weil ein Test mit Rosetta-Code-Aufgaben das nahelegt. Die Wahl der Sprache sollte sich an deinen realen Anforderungen orientieren, nicht an theoretischen Token-Einsparungen, die in komplexen Projekten ohnehin verschwinden.

Die Qualität der Evals: Was man aus Benchmarks lernen kann

Ein zentraler Punkt des Artikels ist die Methodik der Evals selbst. Der Autor zeigt detailliert auf, wie leicht man in die Irre geführt wird: Das zweite zitierte Experiment hatte zum Beispiel einen Pfad-Fehler, der dazu führte, dass ein Agent einen Symlink auf eine nicht existierende Datei legte und dadurch alle nachfolgenden Tests mit seiner eigenen ausführbaren Datei liefen – das verfälschte komplett die Ergebnisse für andere Sprachen wie Rust. Solche subtilen Konfundierungen sind die Regel, nicht die Ausnahme.

Ähnlich wie bei früheren Analysen zur „Caveman-Mode“-Optimierung zeigt sich: Ergebnisse aus Mini-Evals lassen sich nicht generalisieren. Erst wenn Aufgaben eine gewisse Größe erreichen – echte Algorithmen, Protokolle, Dateiformate – werden die Unterschiede aussagekräftig. Der Artikel empfiehlt deshalb, vor jeder Evaluation Präregistrierungen zu machen, also Hypothesen festzulegen, bevor man die Daten sieht. Das hilft, den eigenen Bestätigungsfehler zu reduzieren und die Aussagekraft der Ergebnisse realistisch einzuschätzen.

Für dich als Entwickler oder Entscheider bedeutet das: Nimm jedes Benchmark-Ergebnis mit einer gehörigen Portion Skepsis. Prüfe, welche Aufgaben gelöst wurden, ob die Testumgebung sauber war und ob die Effektgrößen auch bei realistischeren Szenarien bestehen bleiben. Oft reicht eine einzige robuste Evaluation, um eine weit verbreitete Behauptung zu widerlegen – so wie hier die Behauptung, dynamische Sprachen hätten prinzipiell niedrigere LLM-Kosten.

Was wirklich zählt: Mainstream-Sprachen und gute Testwerkzeuge

Wenn weder die statisch-dynamische Einteilung noch die Token-Dichte entscheidend ist, was sollte man dann bei Coding-Agents beachten? Die Daten legen nahe, dass die Unterstützung durch das Modell – also Trainingsdaten, Dokumentation, Community-Beispiele – der wichtigste Faktor ist. Sprachen mit großer Verbreitung und guter LLM-Abdeckung liefern konsistent bessere Ergebnisse. Das heißt nicht, dass du auf Rust verzichten solltest, nur weil etwas mehr Token anfallen – wenn dein Projekt das verlangt, ist es die richtige Wahl. Aber du solltest nicht auf eine exotische Sprache setzen, in der Hoffnung auf magische Token-Ersparnis.

Interessant ist auch die Rolle der Teststrategie. Der Autor vermutet, dass eine schnellere Feedback-Schleife – etwa durch kürzere Compile-Zeiten oder bessere Testausgaben – einen positiven Effekt haben könnte, konstatiert aber, dass dies auf Basis der Daten nicht klar belegt ist. In der Praxis siehst du immer wieder, dass Agenten bei langen Build-Zeiten in Warteschleifen verharren oder Fehler wiederholen. Ein guter Coding-Agent braucht also nicht nur eine geeignete Sprache, sondern auch ein sauberes Setup mit schnellen, isolierten Tests. Das ist wichtiger als die Wahl zwischen Java und Python.

Letztlich bleibt eine ernüchternde Erkenntnis: Die Frage „Was ist die beste Programmiersprache für Coding-Agents?“ hat keine universelle Antwort. Es gibt nicht die eine Sprache, die für alle Aufgaben und alle Modelle optimal ist. Statt nach einer goldenen Lösung zu suchen, solltest du eigene, auf deinen Kontext zugeschnittene Evals durchführen. Nutze realistische Aufgaben, prüfe mehrere Sprachen und achte auf die Kosten in Relation zur Korrektheit. Das Ergebnis wird in den meisten Fällen lauten: Der Unterschied zwischen den Mainstream-Sprachen ist kleiner, als die Marketing-Schlagzeilen vermuten lassen – und die Qualität deiner Tests und deines Prompt-Designs hat einen weit größeren Einfluss auf den Erfolg deines KI-Agenten.

Quelle: danluu.com