Kategorie: Erklärer

Arbeitest du mit einem KI-Agenten an einem komplexen Programmierprojekt, gibst du eine Anweisung, der Agent antwortet. Dann die nächste Anweisung – der Agent muss dieselbe riesige Menge Kontext neu verarbeiten. Als müsstest du jedes Mal ein ganzes Buch neu lesen, um einen Satz zu schreiben. Prompt Caching speichert den berechneten Verarbeitungszustand, sodass der Agent nur den neuen Teil einer Anfrage berechnen muss. Dieser Mechanismus ist fragil und hat weitreichende Auswirkungen auf Latenz, Kosten und das Design von Tools und Sitzungen.

Earendil hat die Funktionsweise und Tücken von Prompt Caching für Coding-Agenten analysiert. Large Language Models werden oft als reine Funktionen betrachtet: Text rein, Text raus. Diese Abstraktion ignoriert einen wesentlichen Fakt: Bei einem Coding-Agenten ist der Großteil der Eingabe von Durchlauf zu Durchlauf identisch. Der Agent sendet System-Prompt, Tool-Definitionen, Projektanweisungen, Konversationsverlauf, Tool-Aufrufe und Ergebnisse. Im nächsten Schritt sendet er fast alles noch einmal, plus ein kleines bisschen Neues. Wächst eine Sitzung auf Zehntausende oder Hunderttausende Tokens an, wird es langsam und teuer, den gesamten Prompt für jeden Schritt neu zu berechnen. Prompt Caching macht es wirtschaftlicher, bleibt aber fragil.

Was ein KV-Cache enthält

Ein Transformer arbeitet in zwei Phasen. Während des Prefills liest er die Eingabe-Tokens und berechnet den Aufmerksamkeitszustand. Während des Decodings erzeugt er neue Tokens einzeln. In jeder Attention-Schicht produziert jeder verarbeitete Token einen Key und einen Value. Das sind Arrays von Zahlen, meist Gleitkommazahlen oder quantisierte Werte. Verarbeitet das Modell einen neuen Token, vergleicht es dessen Query mit den früheren Keys, um die Relevanz jedes früheren Tokens zu bestimmen. Daraus entsteht eine gewichtete Mischung der entsprechenden Values. Ein Key ist das, wonach gesucht wird, ein Value die Information, die abgerufen wird – allerdings unscharf, nicht wie ein exakter Lookup. Diese Keys und Values werden aufbewahrt, damit der nächste generierte Token auf alles Vorherige achten kann, ohne die früheren Tokens neu berechnen zu müssen. Dieser gespeicherte Zustand ist der KV-Cache.

Der Cache entspricht einer bestimmten Token-Präfixfolge. Zwei Prompts mit gleicher Bedeutung, aber unterschiedlicher Tokenisierung, teilen sich keinen KV-Cache. Ändert sich ein Token in der Mitte, ist alles danach eine andere Fortsetzung. Prompt Caching verlängert die Lebensdauer dieses Zustands über eine einzelne Generierung hinaus. Beginnt die nächste API-Anfrage des Coding-Agenten mit denselben Tokens, kann das Inferenzsystem die gespeicherte Arbeit für das passende Präfix wiederverwenden und nur das neue Suffix vorausberechnen.

Wo der Cache lebt

Ein Cache muss gespeichert und adressierbar sein. Es gibt zwei grundlegende Ansätze, wie Inferenzsysteme KV-Caches für spätere Anfragen verfügbar machen. Der einfachere ist die Session Affinity. Der Cache bleibt auf oder nahe der GPU, die ihn berechnet hat. Die nächste Anfrage wird an denselben Worker geroutet. Eine Session-ID oder ein Prompt-Cache-Key dient als einfacher Routing-Hinweis. Das vermeidet, einen sehr großen Cache über das Netzwerk zu bewegen. Es ist schnell, wenn es funktioniert, schränkt aber die Planung ein. Der Worker kann überlastet sein, neu starten oder den Eintrag verdrängen. Ein Router kann auch entscheiden, das Balancieren der Flotte sei wichtiger als die Erhaltung eines Session-Caches. Dennoch ist es attraktiv, weil es mit wenig zusätzlicher Infrastruktur auskommt.

Der andere Ansatz ist die Verteilung des Caches. KV-Blöcke können in einer anderen Speicherebene abgelegt oder über mehrere Worker verfügbar gemacht werden. Eine Anfrage ist dann nicht so stark an eine einzelne GPU gebunden. Das verbessert Scheduling-Flexibilität und Wiederherstellbarkeit. Das Verschieben, Indizieren und Behalten von KV-Blöcken ist selbst ein Systemproblem. Implementierungen mischen GPU-Speicher, Host-Speicher, lokalen Speicher, entfernten Speicher, präfixbewusstes Routing und Verdrängungsstrategien auf unterschiedliche Weise.

Cache und Präfixe: Sitzungen sind Bäume, keine Listen

Ein interessanter Punkt: Viele Coding-Agenten – darunter auch Pi, an dem Earendil arbeitet – modellieren Sitzungen als Bäume. Ein Befehl wie /tree kann die aktive Konversation auf einen früheren Punkt zurücksetzen und entlang eines anderen Zweigs fortsetzen. Ein Zurückspulen kann das aktive Suffix verwerfen, ohne es aus der Sitzungsdatei zu löschen. Ein neuer Zweig kann den größten Teil des alten Kontexts teilen, einen kleinen Teil oder praktisch keinen. Alle drei Zweige können dieselbe Pi-Session-ID haben. Aus Sicht des Routers sind sie eine Sitzung. Aus Sicht des Prompt-Caches sind es drei Token-Sequenzen mit nur teilweisem Präfix-Overlap.

Wenn der Cache wiederverwendbare Präfix-Blöcke behält, kann ein Sprung von D nach F möglicherweise root -> C wiederverwenden. Wenn er nur die heißeste Fortsetzung behält, die gemeinsamen Blöcke verdrängt wurden oder die Anfrage anderswo hin geroutet wird, kann der Treffer viel kleiner ausfallen. Ein Sprung zu Z bewahrt möglicherweise nur den System-Prompt und die anfänglichen Tool-Definitionen, obwohl er von A startet. Das genaue Cache-Management hängt stark vom Anbieter ab. Auch der umgekehrte Fall kann eintreten: Ein Fork oder eine neue Sitzung erzeugt eine neue Session-ID, während ein großer Teil identischen Kontexts übernommen wird. Ein Routingsystem, das Caches nach Session-Key isoliert, übersieht möglicherweise diesen nützlichen Overlap.

Explizites vs. automatisches Präfix-Caching

Anbieter-APIs bieten zwei Hauptstile. Anthropics traditionelles Interface nutzt explizite cache_control-Punkte. Der Client markiert Grenzen nach stabilen Teilen der Anfrage, wie dem System-Prompt, Tool-Definitionen oder dem letztmöglichen cachebaren Konversationsinhalt. Der Server kann den Präfix, der an diesen Punkten endet, schreiben oder nachschlagen. Die Grenze ist explizit, aber die Wiederverwendung erfordert, dass der Inhalt davor übereinstimmt. Auch die Preise sind explizit: Man zahlt für Cache-Schreibvorgänge und kann wählen, wie lange der Cache gehalten wird – zu unterschiedlichen Preisen. Andere APIs verwenden automatisches Präfix-Caching: Der Client sendet die Anfrage normal, der Anbieter findet ein wiederverwendbares Präfix ohne clientseitige Haltepunkte. Ein Prompt-Cache-Key oder Session-Header kann das Routing verbessern, macht aber unterschiedliche Präfixe nicht gleich.

Warum Tool-Loadouts Caches zerstören

Ein häufiges und überraschendes Problem: Tool-Definitionen beeinflussen Caches. Sie erscheinen meist vor der Konversation und werden intern in den System-Prompt eingefügt. Ihre Namen, Beschreibungen und JSON-Schemata sind genauso Modelleingabe wie jeder andere Text. Ein Tool hinzufügen, entfernen, sein Schema ändern oder auch nur die Tools in einer anderen Reihenfolge serialisieren – all das kann den ersten Unterschied weit vorne im Prompt platzieren. Dies ist eine häufige Überraschung bei Plugin-Systemen und MCP-ähnlichen Tool-Katalogen.

Tools nur dann zu laden, wenn sie relevant werden, klingt effizient, weil zunächst weniger Schemata gesendet werden. Bei den meisten Modellen invalidiert das neu erweiterte Loadout jedoch die gecachte Konversation, die darauf folgt. Das Sparen weniger Tool-Schema-Tokens kann dazu führen, dass Zehntausende von Konversations-Tokens erneut verarbeitet werden müssen. Einige neuere Modell-APIs unterstützen additives Tool-Laden. Ein Tool kann zu einem bestimmten Tool-Ergebnis innerhalb des Transkripts verfügbar werden, anstatt in die ursprüngliche Tool-Liste eingefügt zu werden. Das alte Präfix bleibt unverändert. Pi unterstützt dies heute für Modelle mit nativen Deferred-Tool-Mechanismen. Wenn eine Erweiterung eine rein additive Änderung mit setActiveTools() vornimmt, zeichnet Pi die hinzugefügten Namen auf dem Tool-Ergebnis auf. Für unterstützte Anthropic-Modelle verwendet es deferred definitions und tool_reference, für unterstützte OpenAI-Modelle entsprechende Tool-Suche-Einträge. Andere Modelle bekommen einen sicheren Fallback: Pi sendet die komplette aktive Tool-Liste bei der nächsten Anfrage, was funktional korrekt ist, aber den Prompt-Cache löschen kann.

Das Wort „additiv“ ist wichtig. Das Entfernen von Tools, das Ersetzen eines Loadouts durch ein anderes oder das Ändern von Prompt-Schnipseln verändert immer noch die frühere Eingabe. Eine Erweiterung, die den System-Prompt neu aufbaut, die Tool-Reihenfolge mischt, Zeitstempel einfügt oder bei jedem Schritt die aktiven Tools ändert, kann unbeabsichtigt das Caching für die gesamte Sitzung zunichtemachen. Erweiterbarkeit bedeutet, dass Pi die Cache-Stabilität nicht für jede Erweiterung garantieren kann. Es kann cache-freundliche Mechanismen bereitstellen; Erweiterungen müssen sie nutzen. Cache-Effizienz ist für viele Erweiterungen nur ein nachträglicher Gedanke – teilweise, weil bei einem Festpreis-Abo die Kosten von Cache-Fehlern nicht so offensichtlich sind.

Unterbrechungen und TTLs

Standard-Lebensdauern einiger wichtiger Prompt-Caches sind kurz. Anthropics fünf Minuten sind kürzer als viele normale Programmieraktivitäten. Wenn man bei der Nutzung von Fable einen Kaffee trinken geht und zehn Minuten später zurückkommt, kostet eine einzelne „sag hallo“-Nachricht mehr Geld als erwartet. Der Benutzer betrachtet eine Programmier-Sitzung als kontinuierlich aktiv, der Inferenz-Anbieter sieht eine Abfolge isolierter Anfragen. Ein langer Build, eine Testsuite, Mittagessen, ein Meeting oder einfach das Anhalten, um einen Diff zu überprüfen – all das kann die Cache-Lebensdauer überschreiten. Die nächste Anfrage enthält denselben Prompt, aber der gespeicherte KV-Zustand ist weg, und das Präfix wird erneut als Input berechnet.

Pi folgt den fünf Minuten Standard, die Anthropic für API-Benutzer empfiehlt. Ein Blick in Claude Codes Codebasis zeigt, dass Anthropic für seine eigenen Abonnement-Benutzer das Cache-Timeout auf eine Stunde erhöht. Die erhöhten Kosten sind für API-Kunden oft nicht gerechtfertigt. Man kann sich aber dafür entscheiden. Einige Anbieter wie Anthropic bieten längere Aufbewahrungskontrollen an. Für unterstützte Direct-APIs können Pi-Benutzer PI_CACHE_RETENTION=long setzen, um diese anzufordern. Das bleibt aber eine Anfrage: Pi kann ein Gateway nicht zwingen, einen Eintrag zu behalten, eine Verdrängung unter Speicherdruck zu verhindern oder einen Cache am Leben zu erhalten, während keine Modellanfrage gestellt wird.

Die Kosten eines Fehlschlags

Preise für ungecachten Input, Cache-Schreibvorgänge und Cache-Lesevorgänge unterscheiden sich. Cache-Lesevorgänge sind meist vergünstigt, weil die teure Prefill-Arbeit bereits erledigt ist. Cache-Schreibvorgänge können einen Aufschlag verlangen, weil der Anbieter verspricht, den Zustand für die spätere Nutzung aufzubewahren. Betrachten Sie eine Coding-Sitzung mit 100.000 Token Historie, gefolgt von einer kurzen neuen Anfrage. Wenn der Cache funktioniert, wird fast die gesamte Historie zum niedrigeren Cache-Lesepreis abgerechnet. Nur das kleine neue Material wird zum regulären Input-Preis verarbeitet und möglicherweise in den Cache geschrieben. Bei einem Cache-Fehler muss der Anbieter die gesamten 100.000 Token Historie erneut zum regulären Input-Preis verarbeiten. Möglicherweise berechnet er auch das Zurückschreiben dieser Historie in den Cache. Deshalb kann eine kurze Anfrage wie „weiter“ nach einem Cache-Ablauf überraschend teuer sein. In einer langen Coding-Sitzung kann das erneute Lesen des alten Inputs mehr kosten als das Generieren der nächsten Antwort.

Prompt Caching schafft nicht offensichtliche Anreize. Der Benutzer möchte hohe Trefferquoten, weil sie Latenz und Kosten senken. Ein Inferenz-Betreiber, der die GPUs besitzt, sollte sie ebenfalls wollen: Weniger Prefill-Arbeit bedeutet mehr Anfragen mit derselben Hardware. Ein gut entworfener Rabatt auf gecachte Tokens kann beide Seiten in Einklang bringen, während gleichzeitig der Anreiz bleibt, Caching-Mechanismen zu optimieren.

Für Coding-Agenten ist Prompt Caching mehr als ein Implementierungsdetail. Es beeinflusst Latenz, Kosten, Tool-Design, Sitzungsdesign und sogar welche Produktfunktionen überhaupt sinnvoll angeboten werden können. Die Fragilität des Caches – durch Tool-Änderungen, Session-Neustarts, Routing-Entscheidungen oder schlichte Zeitüberschreitungen – macht es zu einer zentralen architektonischen Überlegung. Wer einen KI-Agenten entwickelt oder intensiv nutzt, sollte verstehen, wie der Cache auf den jeweiligen Providern und in der eigenen Anwendung funktioniert. Denn diese unscheinbare Optimierung entscheidet über Geschwindigkeit und Kosten jeder Interaktion.

Quelle: earendil.com

Dein Postfach quillt über. Drei Meetings am Nachmittag, ein Projekt stockt, irgendwo zwischen den Terminen wartet eine Präsentation. Bisher hilft dir eine KI mit Antworten, Zusammenfassungen oder E-Mail-Texten. Nützlich, aber sie nimmt dir die Arbeit nicht ab. Du musst sie immer wieder anschieben. Genau hier setzt ein neues Konzept an: der Agentic PC.

Ein Agentic PC ist ein normaler Arbeitsrechner, ausgelegt darauf, dass KI-Agenten selbstständig für dich arbeiten. Statt auf Befehle zu warten, verstehen sie Kontexte, planen Projekte, sortieren deinen Posteingang, erstellen Entwürfe und führen mehrschrittige Arbeitsabläufe aus. Du delegierst Routineaufgaben an einen lokalen KI-Agenten und behältst die Kontrolle über wichtige Entscheidungen. Für viele Unternehmen wird das 2025 bis 2026 Realität.

Der Unterschied: Assistent vs. Agent

Bisherige KI-Assistenten sind reaktiv. Du stellst eine Frage, sie geben eine Antwort. Sie fassen Texte zusammen, verbessern E-Mails oder durchsuchen Dateien. Dafür reichen zehn bis 30 TOPS. Ein Agentic PC geht weiter. Er versteht Zusammenhänge, plant selbstständig und führt Aufgaben aus deinen Apps heraus aus. Dafür braucht es einen Multi‑Thread‑CPU, großen lokalen Arbeitsspeicher und eine leistungsfähige lokale KI.

Ein gutes Bild: Ein Assistent reicht dir Karteikarten mit Notizen. Du machst die Arbeit selbst. Ein Agent liest die Karteikarten, setzt Prioritäten, erledigt die Recherche und legt dir nur noch die Entscheidung vor. Der Assistent hilft dir, schneller zu arbeiten. Der Agent arbeitet für dich.

Warum das für Unternehmen wichtig wird

Der Reiz für Unternehmen liegt auf der Hand: Zeitersparnis und Effizienz. Wenn ein KI-Agent Meetings vorbereitet, E-Mails kategorisiert und Berichte erstellt, bleiben Mitarbeitern mehr Stunden für strategische Aufgaben. Ein zweiter, oft übersehener Vorteil: Kosten. Viele KI‑Dienste laufen in der Cloud. Jeder Aufruf kostet Geld – Token‑Verbrauch oder Rechenzeit. Ein Agentic PC verlagert einen Großteil dieser Arbeit auf den lokalen Rechner. Die KI läuft direkt auf der Hardware des Mitarbeiters. Das senkt wiederkehrende Cloud‑Kosten und macht die Kostenstruktur kalkulierbarer. AMD spricht von einer „Optimierung des Token‑Verbrauchs“ und einer „vorhersehbareren Kostenbasis“ für Enterprise‑KI.

Hinzu kommt der Datenschutz. Sensible Geschäftsdaten müssen nicht mehr ständig in die Cloud übertragen werden, sondern können lokal verarbeitet werden. Das erleichtert Compliance‑Anforderungen, besonders in regulierten Branchen wie Finanzen, Gesundheitswesen oder Recht.

Die Hardware dahinter: AMD Ryzen AI Max PRO

Für solche Agentic PCs braucht es entsprechende Hardware. AMD hat mit der Ryzen‑AI‑Max‑PRO‑Serie eine Plattform vorgestellt, die speziell für diese Arbeitslasten entwickelt wurde. AMD zufolge ist es der erste x86‑Client‑Prozessor, der große Sprachmodelle mit über 300 Milliarden Parametern lokal ausführen kann. Möglich wird das durch eine Kombination aus leistungsstarken CPU‑Kernen, einer integrierten KI‑Engine und einem großen, einheitlichen Arbeitsspeicher von bis zu 192 GB.

Warum ist so viel Speicher wichtig? KI‑Modelle – vor allem große – brauchen enorm viel Platz im Arbeitsspeicher. Wenn mehrere KI‑Agenten gleichzeitig laufen sollen, wird der Speicher schnell zum Flaschenhals. Mit 192 GB Unified Memory können Unternehmen mehrere Agenten parallel betreiben und mit besonders umfangreichen Modellen arbeiten. AMD nennt konkrete Benchmarks: Ein System mit Ryzen AI Max+ PRO erledigt bestimmte Entwickleraufgaben bis zu sechsmal schneller als ein vier Jahre alter Laptop.

Anwendungsfälle: Vom Helpdesk bis zur Finanzanalyse

Die Praxisbeispiele von AMD für Agentic PCs sind vielfältig. In der IT‑Abteilung könnte ein Agent Server überwachen, Störungen erkennen und automatisch erste Maßnahmen einleiten, während er die Schritte dokumentiert. In der Softwareentwicklung durchforstet der Agent Code, schreibt Tests und erstellt einen Pull‑Request. Für Führungskräfte koordiniert der Agent Kalender, bereitet Briefings vor und plant Reiserouten. Im Kundenservice greift der Agent auf die Account‑Historie zu, beantwortet Anfragen und aktualisiert das CRM.

Auch Cybersicherheit profitiert: Ein Sicherheitsagent erkennt verdächtige Aktivitäten, analysiert die Bedrohung, führt Reaktionsprotokolle aus und hält alles schriftlich fest. In der Finanzanalyse durchsucht der Agent Unternehmenseinreichungen, baut Bewertungsmodelle, identifiziert Risiken und erstellt Investment‑Memoranden. All das geschieht lokal, in Echtzeit und ohne dass der Mitarbeiter jeden Schritt manuell anstoßen muss.

Der Mensch bleibt immer im Entscheidungsprozess. Der Agent schlägt vor, bereitet vor, dokumentiert – aber die finale Entscheidung trifft weiterhin der Mitarbeiter. Das verhindert Kontrollverlust und schafft Vertrauen in die Technologie.

Technische Einordnung: Was bedeutet das konkret?

Für Unternehmen, die über Agentic PCs nachdenken, gibt es einige technische Aspekte zu bedenken. AMD betont, dass die Rechenleistung in TOPS allein nicht ausreicht. Entscheidend ist die Kombination aus CPU‑Leistung, Arbeitsspeicher und der Fähigkeit, mehrere Agenten gleichzeitig auszuführen. Ein Agentic PC muss Multi‑Threaded sein – viele Aufgaben parallel bearbeiten können – und genügend Speicher für große Modelle bieten.

Die aktuelle Generation der Ryzen‑AI‑Max‑PRO‑Prozessoren erreicht bis zu 32 TOPS (beim Max+ Modell), was für anspruchsvolle lokale KI ausreicht. AMD weist darauf hin, dass die Leistung in der Praxis von vielen Faktoren abhängt, etwa vom KI‑Modell, der Softwareversion und der Systemkonfiguration. Die genannten sechsfachen Geschwindigkeitssteigerungen beziehen sich auf einen spezifischen, von AMD definierten Workflow mit sechs parallelen KI‑Agenten und einem großen Modell (ChatGPT 5.5 High). Im Alltag variiert die Verbesserung, aber die Tendenz ist klar: Die Hardware ist bereit für die Agenten‑Ära.

Die Grafik von AMD zeigt: 2023–2024 reichten zehn bis 30 TOPS für Assistenzaufgaben. 2025–2026 braucht es Multi‑Threading und großen Speicher. 2026 und darüber hinaus geht es um autonome Ausführung komplexer Workflows mit hoher lokaler Leistung. Der Übergang von Assistenz zu echter Delegation findet in den nächsten zwei bis drei Jahren statt.

Fazit: Was bedeutet das für Unternehmen?

Agentic PCs sind keine bloße Neuigkeit, sondern eine logische Weiterentwicklung der Arbeitsplatz‑KI. Statt die KI nur als Wissensquelle oder Schreibhilfe zu nutzen, können Mitarbeiter ihr echte Arbeit übertragen. Für Unternehmen bedeutet das weniger Cloud‑Kosten, mehr Datenschutz, höhere Effizienz. Gleichzeitig müssen sie in leistungsfähige Hardware investieren – die sich aber schnell amortisiert, wenn viele Routineaufgaben automatisiert werden.

AMD hat mit der Ryzen‑AI‑Max‑PRO‑Serie eine Plattform geschaffen, die diese Entwicklung unterstützt. Die Kombination aus hoher CPU‑Leistung, großem Unified Memory und dedizierter KI‑Engine macht sie zu einer der ersten ernst zu nehmenden Optionen für Enterprise‑Agentic‑Computing. Die Frage ist nicht mehr, ob lokale KI‑Agenten kommen, sondern wie schnell Unternehmen sie in ihre Arbeitsabläufe integrieren. Wer jetzt die Weichen stellt und auf leistungsfähige PCs setzt, wird morgen einen Vorsprung haben.

Quelle: amd.com

Wenn große Modelle zu teuer sind – und kleine zu dumm

Ein Kundenservice-Chat muss tausende Anfragen pro Minute beantworten. Gemini 3.1 Pro liefert brillante Antworten, aber jede Anfrage würde Latenz und Budget sprengen. Gemini 2.5 Flash ist schnell und günstig, seine Antworten sind oft oberflächlich. Google bietet mit dem Gemini Distillation Service einen Ausweg. Das Wissen eines großen „Lehrer“-Modells wird auf ein schlankes „Schüler“-Modell übertragen – ohne dass der Schüler jedes Mal den Lehrer fragen muss. Kein Zauber, sondern ein systematischer Prozess.

Was ist Model Distillation? Die Lehrer-Schüler-Analogie

Aus der Schulzeit kennst du es: Ein guter Lehrer erklärt den Lösungsweg, nicht nur die Antwort. Bei Distillation ist es ähnlich. Ein großes, fähiges Modell (Lehrer) bekommt Fragen (Prompts) und generiert nicht nur die finale Antwort, sondern auch seine internen Gedankengänge – die rohe Denkstruktur. Der Schüler trainiert darauf, diese Denkmuster zu imitieren. Er lernt nicht nur die richtige Antwort, sondern wie man darauf kommt. Das unterscheidet Distillation von der klassischen überwachten Feinabstimmung (Supervised Fine-Tuning, SFT), die nur finale Antworten als Ziel vorgibt. Der Schüler wird klüger als durch Architektur und Trainingsdaten allein – und bleibt schnell und ressourcenschonend.

Wie Google den Gemini Distillation Service aufgebaut hat

Der Dienst läuft in fünf Schritten ab. Du startest mit einem Datensatz, der nur die Prompts enthält – keine Antworten, kein Ground Truth. Google validiert das Format und verteilt die Daten parallel. Der Lehrer (Gemini 3.1 Pro) durchläuft jeden Prompt und erzeugt eine detaillierte Antwort samt Reasoning-Pfaden. Diese Rohdaten sind der Schatz. Im dritten Schritt startet das Training des Schülers (Gemini 2.5 Flash), der die Denkmuster des Lehrers nachahmt. Nach Abschluss erhältst du ein destilliertes Modell, zehn Zwischen-Checkpoints und automatisch erstellte Prediction-Endpunkte. Die gesamte Pipeline ist als REST-API verfügbar, im Early Access über die Google Cloud Console einsehbar – mit UI-Einschränkungen, aber funktional vollständig.

Wann lohnt sich Distillation wirklich?

Nicht jede Aufgabe braucht diesen Aufwand. Der Dienst entfaltet seine Stärke in vier Szenarien: Erstens bei hochvolumigen, latenzkritischen Anwendungen, die die Reasoning-Fähigkeiten eines Pro-Modells benötigen, aber auf Kosten und Geschwindigkeit eines Flash-Modells angewiesen sind. Zweitens, wenn Ground-Truth-Daten fehlen – du hast zehntausend Benutzeranfragen, aber keine Zeit für manuelle Musterantworten. Distillation umgeht das Problem, weil der Lehrer die Antworten selbst generiert. Drittens bei komplexen Reasoning-Aufgaben: mehrschrittige Logik, Zusammenfassung technischer Dokumente, knifflige Codeprobleme, bei denen der Basis-Flash versagt, der Pro aber glänzt. Viertens, wenn der Lehrer deine spezifische Aufgabe deutlich besser beherrscht als der Schüler – dann besteht genug Wissensgefälle.

So bereitest du dein Projekt vor

Vor dem Start musst du einige Hürden nehmen. Zunächst benötigst du Zugang zur Allowlist – wende dich an deinen Google-Sales-Rep, um deine Projekt-ID freischalten zu lassen. Dann aktivierst du die Agent Platform API in deinem Google Cloud-Projekt. Die IAM-Rolle „Agent Platform Administrator“ (roles/aiplatform.admin) ist Pflicht. Der gesamte Distillation-Job muss in der Region us-central1 laufen. Einmal eingerichtet, ist es für viele Jobs nutzbar.

Datensätze: Nur Prompts, kein Ground Truth

Ein großer Vorteil des Services: Du brauchst keine aufwendig kuratierten Antworten. Dein Datensatz besteht aus JSONL-Dateien in einem Cloud Storage Bucket. Jede Zeile enthält einen Prompt im standardisierten Gemini-Tuning-Format, optional mit Systemanweisungen. Multi-Turn-Gespräche sind möglich, solange die letzte Nachricht vom Benutzer kommt. Die Mindestgröße für spürbare Verbesserungen liegt bei 1.000 Beispielen. Achte auf Diversität: Deine Prompts sollten Randfälle und unterschiedliche Längen abdecken, die in der Produktion vorkommen. Bis zu 50.000 Beispiele sind erlaubt, die Quelldatei maximal 1 GB.

Hyperparameter und Konfiguration – was du einstellen musst

Der Distillation-Job verlangt zwei zentrale Konfigurationen: das Generierungsverhalten des Lehrers und die Hyperparameter des Schülertrainings. Für den Lehrer gibst du candidateCount an (zwischen 1 und 5, Standard 4) – die Anzahl der Antwortvarianten pro Prompt. Mehr Varianten bedeuten mehr trainierbare Beispiele, aber auch mehr Kosten und Zeit. Für den Schüler definierst du epochCount (Anzahl der Durchläufe über den Datensatz, 1 bis 100, Standard 4) und learningRateMultiplier (0,25 bis 4,0, Standard 1). Der Multiplikator passt die Basis-Lernrate an – ein höherer Wert beschleunigt das Lernen, kann aber zu Instabilität führen. Starte mit den Standardwerten und justiere iterativ. Die API erlaubt kontinuierliches Tuning von bereits destillierten Checkpoints – praktisch, wenn du nach und nach mehr Daten hinzufügen möchtest.

Job starten und überwachen

Der Start erfolgt über REST. Du erstellst eine JSON-Datei mit deiner Konfiguration und sendest sie per curl an den Agent Platform API-Endpunkt. Die Antwort enthält eine Job-ID. Mit einem GET-Request fragst du den Status ab: state, Fehlermeldungen und abschließend die Endpunkte. In der Google Cloud Console siehst du den Fortschritt unter Agent Platform > Tuning, allerdings ohne Fortschrittsanzeige während der Lehrer-Sampling-Phase – der Job läuft trotzdem. Du kannst den Job jederzeit abbrechen, über die Konsole oder per POST. Nach erfolgreichem Abschluss wird das destillierte Modell automatisch in der Model Registry registriert, und es werden Prediction-Endpoints erzeugt. Die Evaluierung erfolgt klassisch: Halte einen Teil deiner Prompts zurück (Holdout-Set), sende sie an den neuen Endpunkt und vergleiche die Antworten mit denen des Basis-Flash und des Pro-Lehrers. So siehst du, wie viel Wissen übertragen wurde.

Einschränkungen, die du kennen solltest

Der Dienst befindet sich im Early Access und hat klare Grenzen. Nur die beiden genannten Modelle werden unterstützt, die Eingabe ist auf Text beschränkt – keine Videos, Bilder oder Function Calls. Der Lehrer darf maximal 24.000 Token Ausgabe generieren; bei Überschreitung wird abgeschnitten, was die Schülerqualität mindern kann. Der Input pro Beispiel ist auf 8.000 Token begrenzt – überschreiten mehr als 10 % der Einträge diesen Wert, wird der Job abgebrochen. CMEK ist für Erstanbieter-Modelle nicht verfügbar. Die Hyperparameter sind fest umrissen: epochCount 1–100, learningRateMultiplier 0,25–4,0. Der gesamte Prozess – vom Sampling bis zum Training – ist ein einziger API-Call. Bei großen Datenmengen musst du sie in einem Durchlauf verarbeiten; späteres Hinzufügen neuer Daten erfordert einen neuen Job mit erneutem Sampling. Das solltest du in deiner Planung berücksichtigen.

Fazit: Distillation als Brücke zwischen Power und Effizienz

Der Gemini Distillation Service ist kein Hype-Tool, sondern eine pragmatische Lösung für ein reales Problem: Wie bekommt man die Intelligenz eines Spitzenmodells in ein schlankeres, alltagstaugliches Format? Google hat den Prozess so weit automatisiert, dass du ohne aufwendige Datenannotation auskommst und direkt von der API profitieren kannst. Es gibt Einschränkungen – Token-Limits, fehlende Multimodalität, Abhängigkeit von einem einzigen API-Call – aber der Ansatz ist vielversprechend. Für Teams, die hohe Reasoning-Qualität mit niedrigen Kosten und Latenzen verbinden müssen, ist das ein mächtiges Werkzeug. Du brauchst kein KI-Forscher zu sein. Ein solides Verständnis von Prompt-Engineering und grundlegenden Hyperparametern reicht aus. Probiere es aus, evaluiere kritisch und entscheide dann, ob Distillation der richtige Weg für deine Anwendung ist.

Quelle: docs.cloud.google.com

Ein smartes Alarmsystem für Zuhause erkennt Eindringlinge, schaltet Kameras ein und informiert den Besitzer – aber dieser kann das System nicht verändern. Keine neuen Regeln, keine Patches, keine Analyse-Tools. Wenn das System den Besitzer selbst als Bedrohung einstuft und aussperrt, bleibt er machtlos. Genau das erlebte Hugging Face im letzten Jahr: Ein Sicherheitsvorfall zeigte die Grenzen geschlossener KI-Systeme.

KI-Agenten übernehmen mehr Aufgaben in Unternehmen, Behörden und kritischen Infrastrukturen. Ihre Sicherheit hängt nicht nur von geheimen oder offenen Modellgewichten ab, sondern vom gesamten Ökosystem: Identitäten, Berechtigungen, Zugriffssteuerung, Protokolle und Evaluierungen. Diese Komponenten nennen wir den „Agent-Stack“. Die Open Secure AI Alliance, eine Initiative unter dem Dach der Linux Foundation, baut auf Arbeiten von Akriti und der OpenSSF-Community auf.

Cybersicherheit funktioniert nicht ohne offene Modelle. Weder rein geschlossene noch rein offene Systeme sind die alleinige Lösung. Beide ergänzen sich. Aber für Verteidiger – Unternehmen, Regierungen, Sicherheitsteams – sind offene Modelle und Werkzeuge unverzichtbar. Sie erlauben Inspektion, Anpassung und Ausführung auf eigener Infrastruktur. Kein Extra, sondern eine Notwendigkeit, sobald Angriffe schnell und zielgerichtet erfolgen.

Der Hugging-Face-Vorfall zeigt das deutlich. Geschlossene KI-Tools konnten Angreifer und Verteidiger nicht unterscheiden. Sie blockierten die forensische Analyse. Also nutzte Hugging Face ein offenes Modell – GLM 5.2 – auf eigener Infrastruktur und analysierte über 17.000 Aktionen. Der Eindringling wurde identifiziert, der Schaden begrenzt. Ohne offenes Modell wäre das nicht möglich gewesen. Wer Werkzeuge nicht selbst kontrolliert, wird im entscheidenden Moment blind.

Die Open Secure AI Alliance vereint über 60 Partner aus Cloud, Cybersicherheit, Enterprise-Software, Open-Source-Stiftungen und KI-Forschung: NVIDIA, Microsoft, IBM, Red Hat, Hugging Face, CrowdStrike, Cloudflare, Databricks, Dell Technologies, Cisco, Palo Alto Networks, Salesforce und andere. Sie entwickeln offene Technologien und Werkzeuge für die Sicherheit von Software und KI-Agenten – ein Versuch, Standards für die KI-Abwehr zu etablieren.

Manche argumentieren, offene Modelle seien unsicher, weil Angreifer sie modifizieren könnten. Dieses Risiko existiert, aber geschlossene Systeme lösen es nicht. Entschlossene Angreifer finden Wege an leistungsstarke KI, selbst wenn Gewichte geheim sind. Die richtige Antwort: Offenheit mit starken Sicherheitsvorkehrungen paaren – Missbrauchsregeln, Evaluierungen, schnelle Fehlerbehebung. Sicherer ist der Pfad, der mehr Verteidigern erlaubt, Systeme zu testen und zu stärken.

Konkrete Projekte liefert die Allianz bereits. NVIDIA veröffentlicht das NOOA Framework (GitHub) zur Integration von Modellen in Agent-Harnesses. HPE trägt mit SPIFFE/SPIRE für vertrauenswürdige Identitäten bei. Hugging Face gab Safetensors an die PyTorch Foundation weiter – ein sicheres Speicherformat. IBM und Red Hat arbeiten an Lightwell für signierte Patches in der Lieferkette. Microsoft stellt MDASH bereit für Multi-Modell-Agenten-Scans. SpaceXAI veröffentlicht den Grok Build Agenten und Grok-Modellgewichte unter Open-Source-Lizenz.

Offene Sicherheitsinfrastruktur für KI ist kein abstraktes Konzept mehr. Sie wird gebaut, getestet, eingesetzt. Für Regulierungsbehörden ist das ein Signal. Viele Diskussionen über KI-Sicherheit fragen, ob man offene Modelle einschränken sollte. Die Allianz argumentiert gegenteilig: Offene Modelle, Harnesses und Sicherheitswerkzeuge sind defensive Vermögenswerte. Wer sie pauschal reglementiert, schwächt die Verteidigung und konzentriert Macht bei wenigen Anbietern. Das wäre ein strategischer Fehler.

Regierungen und Unternehmen sollten in gemeinsame offene Infrastrukturen investieren: Datensätze, Evaluierungsframeworks, Angriffssimulatoren, Red-Teaming-Tools. Ähnlich wie frühere Generationen in Open-Source-Software investierten. Diese Investition stärkt Cybersicherheit und erhält technologische Souveränität. Wer Werkzeuge nicht selbst kontrolliert, wird abhängig – keine tragfähige Strategie.

Die Allianz überzeugt: Die Zukunft der KI-Agenten kann shared security und resilience sein. Nicht durch Geheimhaltung allein, sondern durch Systeme, die Prüfung standhalten, flexibel verbessert werden, und offen genug sind, die Verteidiger-Community zu mobilisieren. Die Open Secure AI Alliance lädt Regierungen, Unternehmen und Forscher ein, sich anzuschließen. Die Sicherheit der KI-Ära wird im offenen Dialog gebaut.

Für Unternehmen, die KI einsetzen oder entwickeln, gibt es bald mehr vertrauenswürdige, offene Sicherheitslösungen. Für politisch oder regulatorisch Tätige gibt es ein datenbasiertes Argument gegen pauschale Verbote offener Modelle. Und für alle: Die Allianz zeigt, dass Sicherheit und Offenheit sich nicht ausschließen, sondern bedingen. Offene KI-Sicherheit ist nicht einfacher, aber die klügere Wahl.

Quelle: blogs.nvidia.com

Du sitzt im Auto deines Vertrauens. Der Wagen ist neu, hat jede Menge Assistenzsysteme und fährt fast von allein. Würdest du deshalb aufs Anschnallen verzichten? Wohl kaum. Genau so verhält es sich mit KI-Agenten: Nur weil die Modelle intelligenter werden, heißt das nicht, dass du ihnen blind vertrauen solltest. Die Frage ist nicht, wie gut das Modell ist, sondern wie gut du die Aufgabe kontrollieren kannst.

In der Softwareentwicklung setzen immer mehr Teams auf KI-Agenten, die Code schreiben, refaktorieren oder Pull Requests mergen. Wo liegt die Grenze zwischen sinnvoller Delegation und fahrlässiger Übergabe? Die Antwort liefert ein einfaches Raster mit zwei Fragen: Ist das Ergebnis leicht zu überprüfen? Ist der Schaden im Fehlerfall leicht rückgängig zu machen?

Die zwei Achsen der Delegation

Der Schlüssel liegt nicht im Modell, sondern in der Aufgabe. Code, der gegen Unit-Tests läuft, ist leicht zu prüfen. Eine subjektive Entscheidung wie die Umbenennung einer Variable zur besseren Lesbarkeit dagegen schwer – da braucht es menschliches Urteilsvermögen. Auch die Rückgängigmachung zählt: Ein fehlerhafter Commit im Hauptzweig kann ganze Teams lahmlegen, ein verworfener Entwurf in einem Branch schadet kaum.

Diese zwei Dimensionen – Checkbarkeit und Undo-Kosten – spannen eine 2×2-Matrix auf, die vier Stufen der Autonomie für KI-Agenten definiert. Level 0 bis Level 3. Gehen wir sie durch.

Level 0: Der Agent als Assistent

Die niedrigste Stufe betrifft Aufgaben, die schwer zu prüfen und teuer rückgängig zu machen sind. Hier arbeitet der Agent im Assistentenmodus: Er macht Vorschläge, aber der Mensch entscheidet und führt aus. Genau das, was wir seit 2024 von ChatGPTs Autovervollständigung in Cursor kennen. Für sensible Codebereiche ist das richtig.

Ein Beispiel: Als ein Entwickler bei PostHog das Feature-Flag-System um generisches Property-Targeting erweiterte, musste er eine Annahme ändern, die indirekt in jedem Feature-Flag steckte. Für einen Agenten war das weder durchsuchbar noch deterministisch prüfbar. Die Änderung hatte zudem eine enorme Reichweite – sie betraf Live-Kunden-Flags, API-Response-Formate und Scoring-Funktionen. Der Entwickler zerlegte die Aufgabe in kleine Stücke. Die weniger kritischen Teile – etwa die Verteilung der neuen Logik auf verschiedene SDKs – delegierte er an Agenten, den Kern erledigte er von Hand.

Die Lehre: Zerlege komplexe Aufgaben. Kleine Einheiten machen sofort sichtbar, wo Delegation sicher ist und wo nicht.

Level 1: Human-in-the-Loop

Hier liegen Aufgaben, die schwer zu prüfen, aber billig rückgängig zu machen sind. Typischerweise geht es um subjektive Bewertungen: Code-Lesbarkeit, Kommentare, kleine Umstrukturierungen. Der Agent erstellt einen Vorschlag, der in einem Entwurf bleibt. Ein Mensch prüft ihn, gibt Feedback oder lehnt ab. Ein Undo bedeutet einfach eine weitere Iteration.

Ein gutes Beispiel ist eine Code-Readability-Refaktorisierung – wenige Zeilen, die das Verständnis verbessern, ohne die Logik zu ändern. Ein Agent kann solche Änderungen vorschlagen, aber nicht beurteilen, ob sie wirklich besser sind. Hier hilft der Einsatz eines LLM-as-judge: Man lässt ein großes Sprachmodell die Qualität bewerten. Auch das Definieren eines messbaren Ziels (etwa „Konversionsrate der Landingpage um 3 % steigern“) oder das Schreiben von Custom Skills – spezifischen Regeln für den Agenten – kann die subjektive Prüfung objektivieren.

Level 2: Agentendelegation

Die meisten Entwickleraufgaben befinden sich heute auf dieser Stufe: Der Code ist leicht zu testen (Unit-Tests, Integrationstests), aber der finale Merge ist riskant. Ein Agent schreibt den Code, aber bevor er ins Hauptsystem kommt, wird er durch mehrere Sicherheitsschleusen geschickt.

Ein beeindruckendes Beispiel ist die Neuimplementierung eines SQL-Parsers in Rust bei PostHog. Der Agent hat die Arbeit erledigt, der Entwickler hat kaum eine Zeile gelesen – denn er hatte ein maschinelles Orakel, das die Korrektheit prüfte. Trotzdem wurde der Code nicht einfach gemerged, sondern durchlief einen Schattenmodus in der Produktion und dann eine gestaffelte Umstellung. Das verhindert böse Überraschungen.

Die wichtigste Erkenntnis für Level 2: Ersetze die menschliche Genehmigung durch programmatische Guardrails. Statt jedes Mal selbst zu reviewen, baue Policies ein – Trockenläufe, eingeschränkte Credentials, Feature-Flags. Das entlastet dich und beschleunigt die Entwicklung.

Level 3: Self-Driving Mode

Die höchste Stufe der Autonomie umfasst Aufgaben, die leicht zu prüfen und billig rückgängig zu machen sind. Das sind heute noch kleine Dinge: Dependency-Updates, Lint-Fixes, Hinzufügen von Testabdeckung. Aber die Kategorie wächst rasant – vor allem mit langlebigen Agenten, zielgetriebenen Schleifen und komplexer Orchestrierung.

PostHog treibt diesen Bereich aktiv voran. Mit Scouts etwa laufen Agenten zeitgesteuert, analysieren Produktdaten und erstellen eigenständig Pull Requests. Die Herausforderung ist, dem Agenten beizubringen, wann sich eine Aktion lohnt und wie er echte Signale von Rauschen unterscheidet.

Um Level 3 für weitere Aufgaben zu erschließen, sind drei Hebel entscheidend:

• Domain-spezifische Modelle trainieren: Ein Modell, das gelernt hat, was „gut“ in einer bestimmten Domäne bedeutet, kann Prüfungen übernehmen, die heute noch menschliches Urteil erfordern.
• Experten-Wissensbanken aufbauen: Oft ist mangelnde Autonomie schlicht ein Kontextdefizit. Wer dem Agenten strukturiertes, aktuelles Wissen mitgibt, ermöglicht zuverlässigere Entscheidungen.
• Klare Signale für Scouts definieren: Der Flaschenhals langlebiger Agenten ist die Frage, ob sie überhaupt wissen, wann Arbeit nötig ist. Hier braucht es präzise Metriken und Alarme.

Was bedeutet das konkret?

Die vier Stufen sind keine feste Hierarchie, sondern ein Werkzeug, um für jede einzelne Aufgabe bewusst zu entscheiden, wie viel Autonomie sinnvoll ist. Der entscheidende Punkt: Vertraue nicht blind auf die Intelligenz des Modells – vertraue auf die Nachvollziehbarkeit und Rückholbarkeit der Aufgabe. Das ist wie der Sicherheitsgurt: Egal wie gut das Auto fährt, er rettet dich, wenn etwas schiefläuft.

Indem du Aufgaben in ihre Bestandteile zerlegst und für jedes Teil prüfst, ob du es leicht testen und leicht rückgängig machen kannst, findest du das optimale Maß an Delegation. Und du wirst feststellen: Mit den richtigen Guardrails kannst du immer mehr an Agenten abgeben – ohne die Kontrolle zu verlieren. Die Zukunft gehört nicht den Modellen, sondern dem klugen Design der Aufgaben.

Quelle: newsletter.posthog.com