--- title: "Kleine Modelle sollten entscheiden, was große Modelle sehen" description: "Es ist mittlerweile üblich, dass ein großes Modell kleinere orchestriert. Ich glaube, der größere Gewinn liegt darin, kleine Modelle darum herum zu platzieren: Sie wählen den Kontext aus, filtern die Tool-Ergebnisse und komprimieren diese, solange sie noch aktuell sind." date: 2026-07-16 updated: 2026-09-15 language: de canonical: https://gduv.club/de/articles/small-models-around-big-ones source: gduv.club --- Es wird immer üblicher, ein leistungsstarkes KI-Modell als Orchestrator für kleinere Modelle einzusetzen. Das große Modell plant die Arbeit und delegiert Klassifizierungen, Extraktionen oder vorhersehbare Bearbeitungen an schnellere und günstigere Modelle. Das ist sinnvoll. Aber es optimiert nur die Frage, *wer welche Aufgabe ausführt*. Ich glaube, es gibt ein noch größeres Effizienzpotenzial: kleine Modelle nicht nur **unter** dem großen Modell einzusetzen, sondern **um** es herum. Sie könnten den Kontext vorbereiten, bevor das Modell schlussfolgert, die Ausgaben seiner Tools filtern und nützliche Informationen bewahren, während die Session wächst. Das große Modell würde weiterhin die schwierigen Entscheidungen treffen. Aber da es intelligent, langsam und teuer ist, sollte jeder Token, den es verarbeitet, seinen Platz verdienen. ## Kontext vorbereiten statt ansammeln Coding-Agenten bauen eine lange Arbeitshistorie auf: Nachrichten, Pläne, Befehlsausgaben, Dateien, Fehler und veraltete Versionen derselben Information. Jedes Element mag einmal nützlich gewesen sein. Nur wenige bleiben für jede spätere Entscheidung relevant. Aktuelle Systeme sammeln dieses Material oft an, bis sie Tool-Ergebnisse löschen, Erinnerungen speichern oder die Konversation komprimieren. In der Dokumentation von Anthropic wird irrelevanter Kontext als Bedrohung für den Fokus des Modells behandelt, nicht nur für die Kapazität des Kontextfensters. Ein kleines Modell könnte vor jedem wichtigen Schritt der Argumentation den Kontext auswählen. Die Ausgabe könnte so aussehen: ```json { "include_messages": [2, 7, 11], "include_files": [ { "path": "src/auth.ts", "lines": "48-126" }, { "path": "tests/auth.test.ts", "match": "refresh token" } ], "include_tool_results": ["call_184"], "durable_notes": ["Der Benutzer lehnte cookie-basierte Sessions ab."], "omit_reason": "Unrelevante Build-Logs und veraltete Dateien" } ``` Das große Modell würde die ausgewählten Quellpassagen erhalten und nicht eine vage Zusammenfassung der gesamten Historie. Das ist Retrieval über den sich entwickelnden Workspace des Agenten. _Der Workspace behält alles. Was das Modell erreicht, ist nur das, was für die nächste Entscheidung nötig ist._ ## Tool-Ausgaben filtern, bevor das Hauptmodell sie liest Eine API oder ein MCP-Server liefert möglicherweise Dutzende von Feldern, obwohl der Agent nur drei benötigt. IDs, Zeitstempel, Paginierungs-Metadaten und wiederholte Beschreibungen bleiben dann im Transkript und werden in späteren Durchläufen eventuell erneut verarbeitet. Ein kleines Modell könnte zwischen der Tool-Antwort und dem Hauptmodell sitzen. Es würde die Rohausgabe anhand des aktuellen Ziels filtern, eine typisierte Teilmenge zurückgeben und einen Verweis auf das unveränderte Ergebnis bewahren. Dies ist besonders wertvoll, wenn der Entwickler des Agenten das externe Tool nicht ändern kann. Dieselbe Schicht könnte Dateien klassifizieren, relevante Abschnitte lokalisieren und generierte Inhalte ausschließen, bevor das große Modell sie liest. _Der Filter reduziert die Menge der Informationen, die das Modell erreichen, während die rohe Antwort abrufbar bleibt._ ## Informationen komprimieren, solange sie aktuell sind Kompression ist meist reaktiv: Sobald der Kontext einen Schwellenwert erreicht, wird eine lange Historie zu einer kurzen Zusammenfassung. Bis dahin hat das Hauptmodell verbose Inhalte möglicherweise schon mehrfach gelesen. Eine späte Zusammenfassung muss zudem Details aus mehreren Phasen bewahren, deren zukünftige Relevanz schwer vorhersehbar ist. Die Historie eines Agenten hat zwei Leser mit unterschiedlichen Bedürfnissen. Menschen benötigen die vollständigen Nachrichten und natürliche Sprache, um zu verstehen und zu prüfen, was passiert ist. KI-Modelle benötigen dieselben Fakten in so wenigen zuverlässigen Tokens wie möglich. Ein kleines Modell könnte beide Versionen parallel führen, während Informationen eingehen: das vollständige, für Menschen lesbare Transkript und eine kompakte, maschinenlesbare Darstellung im aktiven Kontext. Jedes komprimierte Element würde zurück auf sein Original verlinken. Die Maschinenversion benötigt keine geschliffene Prosa. Sie könnte sich am aktuellen "Caveman"-Trend bei Coding-Agenten orientieren: telegrafische Aussagen, die Artikel, Höflichkeitsfloskeln, Weichmacher und Füllwörter entfernen, aber technische Details beibehalten. Es geht nicht darum, dass Menschen so sprechen. Es geht darum, nicht mehr dafür zu bezahlen, dass große Modelle Sprache lesen, die für Menschen geschrieben wurde. Ein 2.000 Token langes Testlog könnte so aussehen: > 14 Tests bestanden. `refreshes expired token` fehlgeschlagen, da `expiresAt` `undefined` war in `auth.test.ts:88`. Vollständige Ausgabe: Artefakt `test-run-184`. Das Ergebnis, der Fehler, der relevante Wert, die Position und der Weg zurück zum Beleg bleiben erhalten. Das Rauschen verschwindet. Dies ist kontinuierliche Datenpflege statt einer Notfall-Kompression. _Bei einer späten Kompression zahlen Sie in jedem Durchgang für dieselben Tokens, bis der Schwellenwert erreicht ist. Komprimieren während des Prozesses bedeutet, nur einmal zu zahlen._ ## Die Wirtschaftlichkeit ist plausibel Die zusätzliche Inferenz lohnt sich nur, wenn sie mehr einspart, als sie an Geld, Latenz und Fehlern kostet. Ein einfaches Modell zeigt, dass die finanzielle Schwelle niedrig sein kann. Betrachten wir eine beispielhafte Coding-Session mit 20 Schritten. Das große Modell erhält insgesamt 1,45 Millionen Input-Tokens. Ein Kontext-Modell liest dieselbe Historie, gibt 10.000 Tokens an Auswahlbefehlen aus und reduziert den Input des großen Modells auf 560.000 Tokens. Beide Versionen produzieren 40.000 Output-Tokens des großen Modells. _Das kleine Modell amortisiert sich doppelt, wenn das Entfernte teurer zu lesen ist, als das Modell zu betreiben._ Unter Verwendung der Standard-API-Preise vom 4. Juli 2026 ergibt die Kombination von Gemini 3.1 Flash-Lite (0,25 $ Input und 1,50 $ Output pro Million Tokens) mit Claude Fable 5 (10 $ Input und 50 $ Output) Folgendes: | | Ohne Filterung | Mit Filterung | | :--- | ---: | ---: | | Input großes Modell | 1,45M Tokens | 0,56M Tokens | | Kosten großes Modell | 16,50 $ | 7,60 $ | | Kosten Kontext-Modell | keine | 0,38 $ | | **Gesamt** | **16,50 $** | **7,98 $** | **Gesamtkosten einer 20-Schritte-Session** | | Value | | :--- | ---: | | Ohne Filterung | $16.50 | | Mit Filterung | $7.98 | _Die letzte Tabellenzeile, maßstäblich gezeichnet. Die Ersparnis beträgt 8,52 $ oder 51,7 %._ Die Filterung rentiert sich bereits nach dem Entfernen von 37.750 Fable-Input-Tokens, was nur 2,6 % des rohen Inputs entspricht. **Dies sind Annahmen, keine Messwerte** Das Modell lässt Orchestrierungskosten und Latenz außen vor, setzt unveränderte Output- und Aufgabenqualität voraus und vergleicht Anbieter mit unterschiedlichen Tokenizern. Prompt Caching verringert zudem den Spielraum. Wenn jeder Fable-Input-Token den Cache-Hit-Preis von 1 $ pro Million erhielte, würde die Ersparnis auf etwa 0,51 $ sinken. Semantische Filterung ist am wertvollsten, wenn der Kontext groß, dynamisch und schlecht cachebar ist. Stabile Präfixe werden besser durch Caching gelöst. ## Der Filter kann scheitern Durch das Entfernen von Kontext kann auch der Hinweis verloren gehen, der die Aufgabe löst. Ein kleines Modell könnte eine ungewöhnliche Log-Zeile verwerfen, eine Nutzerbedingung verzerren oder eine Kennung löschen, die für den nächsten Tool-Aufruf benötigt wird. Die Architektur benötigt daher einige strikte Regeln: - rohe Inputs müssen abrufbar bleiben; - Filterentscheidungen müssen strukturiert und prüfbar sein; - Nutzeranweisungen oder Sicherheitsbeschränkungen dürfen niemals komprimiert werden; - unsichere Informationen müssen eingeschlossen werden; - das Hauptmodell muss die originalen Belege anfordern können; - der Aufgabenerfolg muss gemessen werden, nicht nur die Token-Ersparnis. Kleine Modelle sollten den Zugang zu Belegen verwalten und nicht selbst zu einer unsichtbaren Instanz der Wahrheit werden. ## Das Experiment zählt mehr als die Schätzung Die Idee sollte gegen drei Alternativen getestet werden: roher akkumulierter Kontext, schwellenwertbasierte Kompression und kontinuierliche semantische Filterung. Jedes System sollte dieselben Coding-Aufgaben bearbeiten. Die Auswertung sollte die Gesamtkosten der Tokens, die Latenz, die Cache-Auslastung und den Aufgabenerfolg messen. Zudem sollte jeder Fall dokumentiert werden, in dem die Filterung Belege entfernt, die das Hauptmodell später benötigt. 1. **Ein Aufgabenset**. Die gleiche Coding-Arbeit für jeden 2. **Drei Systeme**. Roh, Schwellenwert-Kompression, kontinuierliche Filterung 3. **Vier Messwerte**. Kosten, Latenz, Cache-Hits, Erfolg 4. **Ein Urteil**. Günstiger zählt nur, wenn es immer noch funktioniert _Token-Ersparnisse allein würden den aggressivsten Filter zum Gewinner erklären, weshalb die Qualität der Fertigstellung das entscheidende Maß ist und keine Randnotiz._ Die Architektur gewinnt nur, wenn sie die Kosten senkt, ohne die Qualität der Ergebnisse zu beeinträchtigen. Bis ein solcher Test existiert, sind die wirtschaftlichen Überlegungen ein Grund zum Experimentieren, aber kein Beweis für die Funktionsfähigkeit des Systems. ## Eine neue Rolle für kleine Modelle Model Routing fragt: Welches Modell sollte diese Aufgabe ausführen? Diese Architektur fragt: Was verdient die Aufmerksamkeit des besten Modells? **Model Routing** (Wer führt die Arbeit aus) - Liest die Aufgabe, wählt ein Modell - Das günstige Modell erledigt die einfachen Jobs - Kontext ist das, was sich angesammelt hat **Kleine Modelle um das große herum** (Worauf die Arbeit basiert) - Das beste Modell trifft die schwierigen Entscheidungen - Kleine Modelle wählen aus, was es liest - Kontext wird vor jedem Schritt ausgewählt _Die beiden sind keine Alternativen. Routing entscheidet, wer antwortet, dies entscheidet, worauf die Antwort basiert._ Kleine Modelle könnten zu Kontext-Bibliothekaren, Payload-Editoren und Memory-Wartern werden. Sie würden den Workspace vorbereiten, bevor das Hauptmodell schlussfolgert, und anschließend die nützlichen Ergebnisse bewahren, nachdem es gehandelt hat. Die Idee ist besonders relevant für Coding-Agenten, da diese so viel Zwischenmaterial erzeugen. Sie gilt auch für Forschung, Support und andere langfristige Workflows, die Konversationen, Tools und externe Daten kombinieren. Das fähigste Modell sollte nicht jede Zeile lesen, nur weil das System sie senden kann. Jeder Token sollte einen Grund haben, dort zu sein. ## Quellen - [Anthropic: context editing](https://platform.claude.com/docs/en/build-with-claude/context-editing) - [Anthropic: context engineering with memory, compaction and tool clearing](https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools) - [Caveman: token-efficient communication for coding agents](https://caveman.so/) - [Google: Gemini 3.1 Flash-Lite](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-flash-lite) - [Anthropic: Claude API pricing](https://platform.claude.com/docs/en/about-claude/pricing) - [Model Context Protocol: tools specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)