KI-Kosten senken: fünf Techniken mit dem größten Hebel

Kostenposten für KI-Features auf Finanz-Dashboards haben eine unterhaltsame Eigenschaft: Sie wachsen nicht-linear mit dem Traffic, und sie werden immer schlimmer, je beliebter dein Produkt wird. Hier sind die fünf Techniken mit dem größten Hebel, bei denen wir gesehen haben, dass sie tatsächlich etwas bewegen — mit lauffähigem Code für jede einzelne.

Ein durchgerechnetes Beispiel: Ein Chat-Produkt mit 100K Calls/Tag bei durchschnittlich 3K Input / 500 Output Tokens auf Claude Sonnet 4.6 kostet direkt rund $4.500/Monat. Dieselbe Last mit den fünf Techniken unten landet meist bei etwa $900–$1.200/Monat — ein Schnitt von 70–80%, ohne die Output-Qualität nennenswert zu verschlechtern.

1. Prompt-Caching — der mit Abstand größte Hebel

Wenn dein System-Prompt oder Kontextblock mehr als ~2K Tokens umfasst und über mehrere Calls hinweg wiederverwendet wird, zahlst du zu viel. Anthropic und Google rechnen gecachten Input beide mit etwa 0,1×–0,2× des normalen Inputs ab — eine 5–10×-Ersparnis bei jedem Call, sobald der Cache warmgelaufen ist. Brievio reicht die gesamte Ersparnis durch und betreibt einen Affinity-Router, der wiederholte Prompts immer auf denselben Upstream-Knoten lenkt, sodass der Cache selbst bei geringer Nebenläufigkeit am Leben bleibt.

Den vollständigen Leitfaden findest du unter /docs/caching.

import anthropic

client = anthropic.Anthropic(
    api_key="sk-brievio-...",
    base_url="https://api.brievio.com",
)

# Markiere die langen, statischen Teile des Prompts als cachebar. Der nächste
# Call mit demselben Präfix trifft Anthropics Cache — 10% der Kosten.
resp = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "<<dein 20K-Token-System-Prompt — Schema, Regeln, Beispiele>>",
            "cache_control": {"type": "ephemeral"},   # als cachebar markieren
        },
    ],
    messages=[{"role": "user", "content": "Aktuelle Frage…"}],
)

Erwartete Ersparnis: 40–70% auf die Input-Kosten bei Workloads mit langem System-Prompt. Oft die größte Einzelverbesserung.

2. Modell-Tiering — zahle nicht für Leistung, die du nicht nutzt

Das günstigste vernünftige Modell, das noch akzeptablen Output liefert, gewinnt. Die meisten LLM-Workloads haben eine Long-Tail-Verteilung der Schwierigkeit — die durchschnittliche Klassifizierungs- oder Zusammenfassungsaufgabe braucht kein Opus.

Bau dir eine einfache Schwierigkeitsschätzung (Heuristik, Klassifizierer oder Haiku selbst als Triage) und route entsprechend. Über 50+ Brievio-Accounts hinweg haben wir gesehen, dass allein das die Chat-Kosten um 40–60% gesenkt hat.

def pick_model(task_difficulty: int) -> str:
    """
    Das günstigste Modell, das noch gut genug ist, gewinnt.
    Wähle nach gefühlter Schwierigkeit, validiere dann über die Output-Qualität.
    """
    if task_difficulty <= 2:
        return "claude-haiku-4-5"     # ~10x günstiger als Opus
    if task_difficulty <= 4:
        return "gemini-2.5-flash"       # sehr stark, beim Output sogar günstiger
    if task_difficulty <= 7:
        return "claude-sonnet-4-6"
    return "claude-opus-4-7"          # nur wenn wirklich nötig

Erwartete Ersparnis: 40–60% bei chat-artigen Workloads, sobald ein nennenswerter Anteil auf Haiku / Gemini Flash geroutet wird.

3. Output-Deckel und Spending-Limits

Output-Tokens kosten ungefähr 5× mehr als Input. Ein Bug, der einen Prompt in einer engen Schleife eine 16K-Token-Antwort anfordern lässt, ist genau die Art, wie man aus Versehen an einem Nachmittag $400 verbrennt. Verteidige beide Ebenen — das max_tokens pro Call und das Spending-Limit auf Budget-Ebene im Dashboard.

# Zweistufige Deckelung: max_tokens pro Call, plus ein hartes Budget-Limit auf dem Key.
resp = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[...],
    max_tokens=800,       # Output pro Call deckeln
    stop=["</answer>"],   # an einem bekannten Terminator abschneiden
)

# Im Brievio-Dashboard: /app/keys → "Spending limit" auf jedem Key setzen.
# Produktions-Key: $50/Tag. Experiment-Key: $5/Tag. CI-Key: $1/Tag.

Bei Brievio: /app/keys lässt dich pro Key ein Tageslimit setzen. CI-/Test-Keys mit $1/Tag verhindern außer Kontrolle geratene Skripte; Produktions-Keys können großzügig bleiben.

4. Parallelität — gleichzeitig heißt nicht teurer

Sequenzielle Calls sparen kein Geld gegenüber parallelen — sie verschwenden aber Echtzeit (Wall-Clock), was oft dadurch „gelöst" wird, dass man dem LLM mehr Kontext oder ein größeres Modell gibt. Feuere unabhängige Calls parallel ab; werde schneller fertig; stufe herunter.

# Zahle nicht für sequenzielles Reasoning, wenn N Aufgaben unabhängig sind.
import asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI(
    api_key=os.environ["BRIEVIO_API_KEY"],
    base_url="https://api.brievio.com/v1",
)

async def classify_one(text: str) -> str:
    resp = await client.chat.completions.create(
        model="claude-haiku-4-5",     # parallel + günstig = Gewinn
        messages=[{"role": "user", "content": f"Classify: {text}"}],
        max_tokens=20,
    )
    return resp.choices[0].message.content

results = await asyncio.gather(*(classify_one(t) for t in batch))

Erwartete Ersparnis: indirekt — meist 10–20%, indem du die Falle „mach das Modell größer, damit es schneller ist" vermeidest.

5. Retries, die nicht doppelt abrechnen

Bei Brievio werden fehlgeschlagene Requests (4xx, 5xx) nie berechnet — aber frei ist nur der Call, der fehlschlägt. Wenn deine Retry-Logik bei jedem vorübergehenden Aussetzer ohne Backoff feuert, kannst du die Kosten an einem schlechten Upstream-Tag um das 2–3× vervielfachen. Respektiere Retry-After, unterscheide 4xx (dein Bug) von 5xx (vorübergehend), deckle die Versuche.

from openai import APIError, RateLimitError
import time, random

def call_with_backoff(client, **kwargs):
    for attempt in range(5):
        try:
            return client.chat.completions.create(**kwargs)
        except RateLimitError as e:
            # Retry-After respektieren, wenn vorhanden.
            ra = getattr(e, "retry_after", None) or (2 ** attempt + random.random())
            time.sleep(min(ra, 30))
        except APIError as e:
            if 500 <= e.status_code < 600:
                time.sleep(2 ** attempt + random.random())
                continue
            raise           # 4xx — dein Bug, kein vorübergehender
    raise RuntimeError("exhausted retries")

Die vollständigen Retry-Regeln findest du unter /docs/errors.

Der zusammengesetzte Effekt

Jede Technik für sich genommen bringt einen moderaten Schnitt. Gestapelt verstärken sie sich: 50% weniger durch Caching × 50% weniger durch Tiering × 10% weniger durch Deckelung = 22% der ursprünglichen Kosten = 78% gespart. Das ist der Unterschied dazwischen, ob KI ein Budgetposten ist oder ob KI zur Produktionsmarge beiträgt.

Brievios eigenes Pricing — jedes Modell ~15% unter der offiziellen Liste, abgerechnet auf echten Token-Zahlen — ist ein flacher Multiplikator obendrauf auf alle fünf Techniken. Der klügste Weg, um 2026 Frontier-KI zu betreiben, ist: echte Modelle auf einer Infrastruktur zu wählen, die stabil läuft, und ihnen dann die richtigen Techniken abzuringen. Beide Ebenen zählen.

Willst du eine kostenlose Auswertung deines aktuellen Verbrauchs, um zu sehen, wo der Hebel liegt? Schreib eine Mail an contact@brievio.com mit einer groben Beschreibung, und wir machen die Analyse.