Wie Sie LLM-Kosten senken: Komprimierung von Logs und Daten reduziert Token um 60–95 %

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meinem DennisCraft AI Studio setze ich KI-Systeme für DACH-B2B-Kunden in Logistik, Finanzen und Industrieautomation um – auf Basis von Claude, Supabase, n8n, Doppler und eigenem Postgres. Im April 2024 bemerkte ich in einem Produktionssystem einen 60 %-Anstieg der LLM-Kosten – nicht wegen komplexer Prompts, sondern durch stetig wachsende Log- und Kontextdaten. Hier zeige ich, wie Sie mit datengetriebener Komprimierung 60–95 % an Token sparen, ohne Auditanforderungen zu verletzen.

Warum Logs und Kontextdaten Ihre Token-Bilanz dominieren

In regulierten Märkten wie Fintech oder Industrie ist Nachvollziehbarkeit Pflicht – jeder LLM-Aufruf erhält neben dem Prompt umfangreiche Logdaten, Prozesshistorien oder Sessions, meist als JSON oder Fließtext. In meinen Systemen liegt der eigentliche Prompt oft bei 300–400 Token, während das Kontextpaket 3.000–10.000 Token erreicht. Ein IoT-Agent kam auf 12.000 Token pro Inferenz, davon 10.000 aus Logdaten. Hauptursachen: unkomprimierte Rohlogs, redundante Events, Duplikate und zu lange Schlüssel.

Komprimierungsverfahren mit echtem Effekt

1. Semantische Log-Aggregation

Statt rohe Events zu übergeben, fasse ich Logs zu prägnanten Statusübergängen zusammen. 100 Einträge werden so zu 3–5 Kernereignissen (“User X änderte Y auf Z, Status: OK”). Das spart in der Praxis 60–75 % der Token. Realisiert wird das mit n8n-Workflows, die Logs nach Eventtyp clustern und zusammenfassen.

2. Strukturierte Komprimierung mit Brotli/zlib

JSON- und Textlogs lassen sich mit Brotli oder zlib sehr effizient komprimieren. Im Produktivbetrieb nutze ich folgenden Ansatz:

import brotli
import json

def compress_log(log_dict):
    json_str = json.dumps(log_dict, ensure_ascii=False)
    return brotli.compress(json_str.encode('utf-8'))

def decompress_log(compressed):
    return json.loads(brotli.decompress(compressed).decode('utf-8'))

Für die Speicherung optimal, für LLM-Kontexte werden zusätzlich irrelevante Felder entfernt und Schlüssel maximal gekürzt. Typischer Spareffekt liegt bei 85 %+, wenn Sie Nullwerte und überflüssige Felder eliminieren. Siehe Brotli-Dokumentation für Details.

3. Syntaktische und lexikalische Verdichtung

Wiederkehrende Muster (“user_id”: “123”, “event”: “clicked”, “timestamp”: “…”) werden durch kurze Schlüssel (“u”: “123”, “e”: “c”, “t”: “…”) ersetzt. Für Serien identischer Events setze ich Run-Length-Encoding (RLE) ein:

def rle_events(events):
    compressed = []
    prev = None
    count = 1
    for ev in events:
        if ev == prev:
            count += 1
        else:
            if prev is not None:
                compressed.append({'event': prev, 'count': count})
            prev = ev
            count = 1
    if prev:
        compressed.append({'event': prev, 'count': count})
    return compressed

In echten Workflows kürzt das Event-Ketten um 70–90 %, ohne dass der LLM-Kontext darunter leidet.

Komprimierung im produktiven Datenpipeline

Phasen im Überblick

In Supabase und eigenem Postgres speichere ich ausschließlich komprimierte Logs. Für den Prompt werden nur relevante Ausschnitte dekomprimiert und aggregiert.

Automatisierung mit n8n und Supabase

Mit n8n erstelle ich Workflows, die nach jedem Prozessschritt Logs mittels Python-Node verdichten und anschließend in Supabase speichern. In Bereichen mit DSGVO- oder BSI-Anforderungen ist Komprimierung essenziell, um Kosten und Auditierbarkeit im Gleichgewicht zu halten.

Vergleich der Verfahren im Produktivbetrieb

FAQ

Wie ist vollständige Nachvollziehbarkeit mit Komprimierung vereinbar?

Speichern Sie vollständige Logs in Postgres, aber reichen Sie in die LLM-Pipeline nur verdichtete Ausschnitte weiter. Über Event-IDs können Sie vollständige Ketten im Auditfall rekonstruieren.

Wo liegen Risiken bei der Log-Aggregation?

Feindetails für die Ursachenanalyse könnten verloren gehen. Daher werden nur Routine-Events aggregiert, kritische Fehler bleiben unkomprimiert.

Wie automatisieren Sie die Komprimierung?

Mittels n8n-Workflows mit Python-Nodes zur Komprimierung/Aggregation und Speicherung in Supabase. Typische Umsetzung: 1–2 Tage.

Gibt es Nachteile bei Brotli/zlib?

Ein geringer Zeitaufwand (10–50 ms pro Event) für die (De-)Komprimierung, der in typischen Produktivlasten kaum ins Gewicht fällt.

Wie erfolgt die Integration in Claude Code oder andere LLMs?

Daten werden vor dem Prompt serialisiert und dekomprimiert; nur relevante, aggregierte Inhalte gehen in den LLM, keine Binärdaten.

In welcher Phase Ihrer Pipeline explodieren die Token-Kosten durch Logs – schon bei der Prompt-Erstellung oder erst in der Speicherung? Ich freue mich auf Vergleichswerte. Ich biete DACH-Unternehmen einen kostenlosen 30-min Stack-Audit für KI-Systeme im regulierten Umfeld an. Kontaktieren Sie mich auf LinkedIn oder unter @ger_dennis_ai.