718 News-Items, ein geplatztes Budget — und was ich daraus gelernt habe
Wie ich den Token-Verbrauch meiner KI-Pipeline um 62% gesenkt habe, ohne eine einzige Information zu verlieren.
Jeden Sonntag läuft bei mir eine Pipeline. Sie liest 19 Newsletter-Abonnements aus meinem Gmail, baut daraus eine strukturierte Nachrichtendatenbank, einen Wissensgraphen mit klassifizierten Signalen — und schreibt am Ende einen kommentierten Briefing-Newsletter in meinem Stil und mit meiner Meinung.
Funktioniert gut. Bis zu dem Sonntag, an dem es nicht mehr funktioniert hat.
Das Problem: ein teurer Sonntag aka Budgetdiskussion mit meiner besseren Hälfte
Eine ungewöhnlich ereignisreiche Woche — ein KI-Agent hatte die Infrastruktur eines Drittanbieters kompromittiert, ein neues Frontier-Modell war erschienen, ein Open-Weight-Konkurrent hatte es Tage später unterboten, dazu eine Kriegseskalation mit wirtschaftlichen Folgewirkungen. Gutes Newsletter-Material. Schlechter Zeitpunkt, um ein Skalierungsproblem zu entdecken.
718 Nachrichten statt der üblichen ~250. Die Pipeline verbrauchte mein gesamtes monatliches Token-Budget bei weniger als einem Viertel der Arbeit. Nicht weil die Architektur falsch war — sondern weil sie verschwenderisch war, und ruhigere Wochen das versteckt hatten.
Die Ursache: Doppelarbeit im grossen Stil
Der Kern des Problems war einfach: Für jeden einzelnen News-Artikel wurde ein eigener KI-Agent gestartet, der genau diesen einen Artikel las, klassifizierte und als Wissensgraph-Eintrag schrieb.
Das klingt sauber — ist es aber nicht.
Denn von 718 Artikeln waren viele keine 718 eigenständigen Ereignisse. Eine einzige Meldung — ein Modell-Launch, eine Finanzierungsrunde, eine politische Entscheidung — wurde von fünf, sechs, manchmal acht verschiedenen Newslettern aufgegriffen. Unter der alten Architektur: acht Agent-Aufrufe, acht Wissensgraph-Einträge, acht Mal Token-Kosten — für ein einziges Ereignis.
Dazu kam reiner Overhead: jeder Agent öffnete Dateien einzeln, schrieb einzeln, lud den Kontext neu. Arbeit, die keinen Mehrwert produziert. Multipliziert mit 718.
Die Lösung: erst clustern, dann denken
Das Grundprinzip der Neuarchitektur: mechanische Arbeit kostenlos erledigen, bevor das Modell überhaupt involviert wird.
Konkret drei Schritte:
1. Lokal clustern — für null Token. Ein simples Python-Skript (Vektorisierung + Clustering) gruppiert alle Nachrichten nach thematischer Ähnlichkeit. Läuft in Sekunden auf dem lokalen Rechner. Kein Modell-Aufruf, keine Kosten.
2. Gebündelt lesen. Statt Dutzender Einzeldateien bekommt jeder Agent ein konsolidiertes Dokument mit allem aus seinem Cluster. Ein Lesevorgang statt vieler.
3. Das Modell nur für Urteilsfragen. Der Agent entscheidet, wie viele echte Ereignisse in einem Cluster stecken — echte Duplikate zusammenführen, falsch gruppierte trennen, generischen Füllstoff aussortieren. Das ist der einzige Schritt, der wirklich Intelligenz braucht.
Die Zahlen
| Alte Architektur | Neue Architektur | |
|---|---|---|
| Erzeugte Einträge | 182 (Budget erschöpft) | 542 (vollständig) |
| Verbrauchte Token | ~1,14M | ~1,30M |
| Token pro Eintrag | ~6.280 | ~2.410 |
~62% weniger Token pro Eintrag — gleiche Modellqualität, gleiche Klassifikationstiefe, unter halb dem Preis pro Ausgabe-Einheit.
Die alte Architektur hätte für die vollständigen 718 Einträge ~4,5M Token gebraucht. Die neue hat alle 718 Artikel — dedupliziert zu 542 Einträgen — für ~1,3M Token verarbeitet. ~71% Gesamtersparnis für dieselbe Woche.
Eine Bonus-Lektion nebenbei
Beim Neuaufbau des Wissensgraphen fiel mir ein zweites Problem auf: der Layout-Algorithmus berechnete Node-Positionen in einer verschachtelten Python-Schleife — quadratische Komplexität, bei kleinen Graphen unsichtbar. Über ~1.600 Nodes hörte das Skript einfach auf, fertig zu werden.
Die Lösung war kein Redesign. Dieselbe Mathematik, vektorisiert mit NumPy statt Zeile für Zeile in Python, läuft in Sekunden statt Minuten. „Das ist langsam“ und „das muss langsam sein“ sind sehr unterschiedliche Aussagen — es lohnt sich, den Unterschied zu prüfen, bevor man einen Neuschrieb annimmt.
Fazit
Wer eine agentische Pipeline auf vielen kleinen, repetitiven Einheiten betreibt:
- Clustern oder deduplizieren vor dem Modell-Aufruf, nicht danach
- Kontexte gebündelt übergeben, nicht einzeln
- Das Modell für Urteilsfragen reservieren — nicht für Gruppierung, Zählung oder Formatierung
- Messen mit echten Zahlen — Token-Counts für vergleichbare Arbeitseinheiten, nicht Gefühle
Conclusion: Eine Pipeline, die an einem einzigen ereignisreichen Sonntag das Monatsbudget gesprengt hätte, läuft jetzt komfortabel innerhalb eines deutlich kleineren Budgets — mit einem saubereren, besser deduplizierten Wissensgraphen als Nebeneffekt, nicht als Kompromiss.