Gemini Batch API fuer Doc-Pipeline
Bisher habe ich meine Dokumenten-Pipeline für Notizen und Web-Clippings synchron betrieben, was bei steigendem Volumen die Systemressourcen blockierte und hohe API-Kosten verursachte. Um die Ausgaben zu senken und die Stabilität zu erhöhen, habe ich das Setup komplett auf die Gemini Batch API umgestellt.
Asynchrone Verarbeitung mit Gemini
Statt jedes Dokument sofort einzeln an die KI zu schicken, sammelt mein Server nun die eingehenden Texte und sendet sie ab einem bestimmten Volumen gebündelt an das kosteneffiziente Modell gemini-2.5-flash-lite.
Die Pipeline arbeitet dabei in zwei Phasen: Zuerst extrahiert das Modell alle relevanten Fakten und Kernzitate aus dem Rohtext. Im zweiten Schritt werden diese Daten zu sauberen, strukturierten Notizen für meine Wissensdatenbank synthetisiert. Da das System nicht mehr auf eine sofortige Antwort wartet, prüft ein Cronjob alle zehn Minuten im Hintergrund, ob Google den Batch-Job abgeschlossen hat. Schlägt ein Job technisch fehl, greift ein Fallback auf die klassische synchrone Verarbeitung zurück. Das Ergebnis dieses Umbaus ist eine Ersparnis von rund 50 Prozent der LLM-Kosten für die Datenverarbeitung.
Kostenkontrolle und Maschinenlesbarkeit
Da automatisierte Pipelines bei Fehlern (wie Endlosschleifen) schnell teuer werden können, habe ich einen lokalen Budget-Tracker integriert. Dieser summiert die geschätzten Kosten jedes Batch-Jobs auf und stoppt den Prozess automatisch, sobald mein striktes Limit von 10 US-Dollar pro Monat erreicht ist.
Parallel zur Backend-Optimierung habe ich meinen Blog für KI-Crawler (Answer Engine Optimization) maschinenlesbar gemacht. Neben expliziten Freigaben in der robots.txt für Bots wie GPTBot oder Claude-Web nutze ich nun eine llms.txt. Diese Textdatei bietet Entwicklern und KI-Agenten eine perfekte, token-sparende Zusammenfassung der Website-Struktur.
Kern-Erkenntnisse für eigene Setups: * Für Hintergrundaufgaben wie das Kategorisieren großer Datenmengen sind Batch-APIs essenziell – der asynchrone Aufbau ist komplexer, spart aber massiv Kosten und umgeht Timeout-Probleme. * Bei nutzungsbasierten APIs ist ein lokal implementiertes, hartes Ausgabenlimit im Code absolute Pflicht, um sich vor teuren Fehlern zu schützen.