Context Length Exceeded bei LLM-API-Aufrufen: Lösungen, Kompromisse und Modellauswahl

Ihr LLM-API-Aufruf hat gerade Folgendes zurückgegeben:

{
  "error": {
    "message": "This model's maximum context length is 128000 tokens. However, your messages resulted in 142837 tokens.",
    "type": "invalid_request_error",
    "code": "context_length_exceeded"
  }
}

Das bedeutet, dass Ihre Eingabe (System-Prompt + Gesprächsverlauf + Benutzernachricht) das Kontextfenster des Modells überschreitet. Die Anfrage wurde abgelehnt, bevor überhaupt Tokens generiert wurden.

Anders als Rate-Limit-Fehler (bei denen es um die Anfragehäufigkeit geht) betreffen Context-Length-Fehler die Anfragegröße. Die Lösung besteht nicht darin, langsamer zu werden — sondern die Eingabe zu reduzieren, die Anfrage umzustrukturieren oder auf ein Modell mit größerem Kontextfenster zu wechseln.

Kurzfassung

• Context Length Exceeded = Ihre Eingabe ist zu groß für das Token-Fenster des Modells.
• Sie haben vier Optionen: kürzen, zusammenfassen, aufteilen oder das Modell wechseln.
• Jede Option hat unterschiedliche Auswirkungen auf Kosten, Qualität und Latenz.
• Nutzen Sie die Entscheidungstabelle unten, um den richtigen Ansatz für Ihren Anwendungsfall zu wählen.
• In Produktionssystemen sollten Sie das Problem abfangen, bevor der Nutzer es sieht — nicht erst danach.

Schnellcheck-Checkliste

Bevor Sie eine Strategie wählen, prüfen Sie zuerst diese häufigen Ursachen:

Wenn keine dieser Schnelllösungen zutrifft, brauchen Sie einen strukturellen Ansatz.

Entscheidungstabelle: Kürzen vs. Zusammenfassen vs. Aufteilen vs. Modellwechsel

Strategie 1: Kürzen — das Unwichtigste weglassen

Kürzung ist der einfachste Ansatz. Entfernen Sie die ältesten oder am wenigsten relevanten Teile der Eingabe.

Sliding Window für Chat

def sliding_window(messages: list, max_tokens: int, system_prompt: str) -> list:
    """Keep system prompt + most recent messages within token budget."""
    # Always keep system prompt
    result = [{"role": "system", "content": system_prompt}]
    token_count = count_tokens(system_prompt)

    # Add messages from newest to oldest
    for msg in reversed(messages):
        msg_tokens = count_tokens(msg["content"])
        if token_count + msg_tokens > max_tokens:
            break
        result.insert(1, msg)  # Insert after system prompt
        token_count += msg_tokens

    return result

Wann Kürzung gut funktioniert

• Multi-Turn-Chats, in denen der aktuelle Kontext am wichtigsten ist
• RAG-Pipelines, bei denen Sie bei Bedarf erneut abrufen können
• Batch-Verarbeitung, bei der Sie in Reihenfolge verarbeiten können

Wann Kürzung gefährlich ist

• Agenten-Workflows, bei denen frühe Anweisungen das spätere Verhalten beeinflussen
• Rechtliche oder Compliance-Kontexte, in denen Vollständigkeit wichtig ist
• Mehrstufiges Reasoning, bei dem das Weglassen von Schritten die Antwort verändert

Strategie 2: Zusammenfassen — komprimieren, ohne die Bedeutung zu verlieren

Die Zusammenfassung nutzt ein günstigeres, schnelleres Modell, um den bisherigen Kontext zu komprimieren:

async def summarize_context(messages: list, client) -> str:
    """Compress older messages into a summary."""
    context_text = "\n".join(
        f"{m['role']}: {m['content']}" for m in messages
    )

    response = await client.chat.completions.create(
        model="gpt-4o-mini",  # Cheaper model for summarization
        messages=[{
            "role": "user",
            "content": f"Summarize this conversation context in under 500 tokens. "
                       f"Preserve key decisions, facts, and pending actions:\n\n{context_text}"
        }],
        max_tokens=500
    )

    return response.choices[0].message.content

Kostenvergleich: Zusammenfassen vs. Kürzen

Die Zusammenfassung fügt einen günstigen Aufruf hinzu, reduziert aber oft die Input-Tokens des Hauptaufrufs erheblich — was bei teuren Modellen netto eine Kostenersparnis bedeuten kann.

Strategie 3: Aufteilen und Zusammenführen — für lange Dokumente

Wenn die Eingabe ein einzelnes langes Dokument ist (kein Gespräch), ist das Aufteilen oft der richtige Ansatz:

async def process_long_document(
    document: str,
    question: str,
    client,
    chunk_size: int = 50000
) -> str:
    """Process a long document by chunking."""
    chunks = split_into_chunks(document, chunk_size)
    chunk_results = []

    for i, chunk in enumerate(chunks):
        response = await client.chat.completions.create(
            model="gpt-4o",
            messages=[{
                "role": "user",
                "content": f"Analyze chunk {i+1}/{len(chunks)} of a document.\n"
                           f"Question: {question}\n\n"
                           f"Chunk content:\n{chunk}"
            }]
        )
        chunk_results.append(response.choices[0].message.content)

    # Merge chunk results
    merge_response = await client.chat.completions.create(
        model="gpt-4o",
        messages=[{
            "role": "user",
            "content": f"Merge these partial analyses into a final answer.\n"
                       f"Question: {question}\n\n"
                       f"Partial results:\n" + "\n---\n".join(chunk_results)
        }]
    )

    return merge_response.choices[0].message.content

Abwägungen beim Aufteilen

• Vorteil: Verarbeitet beliebig lange Eingaben
• Nachteil: Chunk-übergreifender Kontext geht verloren
• Nachteil: Mehrere API-Aufrufe = höhere Gesamtkosten und Latenz
• Gegenmaßnahme: Chunks um 10-20% überlappen lassen, um den Kontext an den Grenzen zu erhalten

Strategie 4: Auf ein Modell mit größerem Kontext wechseln

Wenn Ihre Eingabe wirklich groß bleiben muss, wechseln Sie zu einem Modell mit größerem Kontextfenster:

Kostenauswirkung von Modellen mit größerem Kontext

Größere Kontextfenster bedeuten in der Regel höhere Kosten pro Token. Berechnen Sie, ob die Qualitätsverbesserung die Kosten rechtfertigt:

Option A: Auf 80K kürzen + GPT-4o = $X
Option B: Volle 150K Eingabe + Claude Sonnet = $Y
Option C: Volle 150K Eingabe + Gemini Flash = $Z

Vergleichen: Qualitätsunterschied vs. Kostenunterschied

Ein Routing-Gateway für die Modellauswahl nutzen

Anstatt die Modellauswahl fest zu codieren, können Sie ein Gateway verwenden, das basierend auf der Eingabegröße an das passende Modell weiterleitet:

from openai import OpenAI

client = OpenAI(
    api_key="your-evolink-key",
    base_url="https://api.evolink.ai/v1"
)

# Let the Smart Router choose based on your workload
response = client.chat.completions.create(
    model="evolink/auto",
    messages=your_messages
)

Produktionsmuster: Vorprüfung vor dem Senden

Warten Sie nicht, bis die API Ihre Anfrage ablehnt. Prüfen Sie die Eingabegröße vor dem Senden:

import tiktoken

def check_context_length(messages: list, model: str, max_tokens: int) -> dict:
    """Pre-check whether messages fit within the model's context window."""
    encoder = tiktoken.encoding_for_model(model)
    total_tokens = sum(
        len(encoder.encode(m["content"])) for m in messages
    )

    if total_tokens > max_tokens:
        return {
            "fits": False,
            "total_tokens": total_tokens,
            "excess": total_tokens - max_tokens,
            "suggestion": "truncate" if total_tokens < max_tokens * 1.5
                          else "summarize_or_switch"
        }

    return {"fits": True, "total_tokens": total_tokens}

So vermeiden Sie verschwendete Latenz durch abgelehnte Anfragen und können die richtige Strategie anwenden, bevor der Nutzer einen Fehler sieht.

Verwandte Artikel

• Fix OpenRouter 429 "Provider Returned Error" — wenn das Problem Rate Limits sind, nicht die Eingabegröße
• AI API Timeout: Causes, Retry Patterns, and Fallback Design — wenn lange Eingaben Timeouts statt Ablehnungen verursachen
• How to Reduce 429 Errors in Agent Workloads — Anfragevolumen neben der Anfragegröße verwalten
• Best AI API Platform for Production Reliability — eine Plattform wählen, die Modell-Routing übernimmt

FAQ

Was bedeutet "context length exceeded"?

Es bedeutet, dass Ihre Eingabe (System-Prompt + Nachrichten + eingefügter Kontext) mehr Tokens enthält, als das maximale Kontextfenster des Modells zulässt. Die Anfrage wird abgelehnt, bevor die Generierung beginnt.

Ist "context length exceeded" dasselbe wie ein Rate-Limit-Fehler?

Nein. Rate-Limit-Fehler (429) betreffen das Anfragevolumen — zu viele Anfragen in einem Zeitfenster. Context-Length-Fehler betreffen die Anfragegröße — eine einzelne Anfrage, die zu groß ist. Sie erfordern unterschiedliche Lösungen.

Was ist besser: Kürzung oder Zusammenfassung?

Kürzung ist einfacher und günstiger, aber es gehen Informationen verloren. Zusammenfassung bewahrt die Bedeutung, erfordert aber einen zusätzlichen API-Aufruf und führt zu Kompressionsartefakten. Verwenden Sie Kürzung für Chat-Verläufe, bei denen Aktualität am wichtigsten ist; verwenden Sie Zusammenfassung für Agenten-Workflows, bei denen der angesammelte Kontext wichtig ist.

Kann ich Context-Length-Fehler vermeiden, indem ich ein größeres Modell verwende?

Ja, aber zu einem Preis. Modelle mit größeren Kontextfenstern (Gemini 1M+, Claude 200K) können größere Eingaben verarbeiten, kosten aber in der Regel mehr pro Token. Berechnen Sie, ob die Qualitätsverbesserung die zusätzlichen Kosten rechtfertigt.

Wie zähle ich Tokens, bevor ich eine Anfrage sende?

Sollte ich diesen Fehler im Anwendungscode oder auf Gateway-Ebene behandeln?

Beides. Der Anwendungscode sollte die Eingabegröße vorab prüfen und die passende Strategie anwenden (kürzen, zusammenfassen, aufteilen oder wechseln). Ein Routing-Gateway kann zusätzlich ein Modell mit einem ausreichend großen Kontextfenster für Ihre Anfrage auswählen.