Fehler 504: was tun, wenn grok-build-0.1 fehlschlägt

Ein 504 bedeutet, dass das Gateway beim Warten auf das vorgelagerte Modell in einen Timeout gelaufen ist: Die Anfrage wurde gesendet, aber der vorgelagerte Dienst antwortete nicht innerhalb des Gateway-Timeouts.

504 Gateway Timeout bedeutet, dass das Gateway das Warten auf die Upstream-Antwort aufgegeben hat. Die Anfrage wurde weitergeleitet, aber innerhalb des Gateway-Limits kam kein Ergebnis zurück. Kürzere Ausgabe, Streaming oder ein niedrigeres max_tokens lösen das meist.

grok-build-0.1 wird von xAI bereitgestellt. Alles auf dieser Seite — Ursachen, Lösungen und gemessene Daten — basiert auf dem tatsächlichen Laufzeitverhalten dieses Modells auf der Gatewayschicht.

An diesem Gateway ist die häufigste Ursache: Der vorgelagerte Dienst brauchte länger als das Gateway-Timeout erlaubt. Empfohlene erste Maßnahme: Wechseln Sie zur Streaming-Ausgabe.

Häufige Ursachen

  • Der vorgelagerte Dienst brauchte länger als das Gateway-Timeout erlaubt
  • Ein langer Kontext hat die Inferenzzeit erhöht
  • Ein vorgelagerter Knoten hängt
  • Eine nicht gestreamte Anfrage mit sehr langer Ausgabe

So beheben Sie es

  • Wechseln Sie zur Streaming-Ausgabe
  • Kürzen Sie den Kontext und senken Sie max_tokens
  • Versuchen Sie es nach kurzer Wartezeit erneut
  • Nutzen Sie ein Modell mit schnellerer Inferenz

Wiederholung mit exponentiellem Backoff

Der folgende Code wiederholt den Aufruf, wenn grok-build-0.1 504 liefert: bis zu 5 Versuche, mit wachsender Wartezeit und zufälligem Jitter, damit parallele Anfragen nicht gleichzeitig wiederholen. Base-URL und API-Key werden aus Umgebungsvariablen gelesen — nicht hart codieren.

import os, time, random
import requests

BASE  = os.getenv("OPENAI_BASE_URL")   # e.g. https://<your-gateway>/v1
KEY   = os.getenv("OPENAI_API_KEY")
MODEL = 'grok-build-0.1'


def chat(messages, retries=5):
    """Retry with exponential backoff + jitter."""
    for i in range(retries):
        try:
            r = requests.post(
                BASE + "/chat/completions",
                headers={"Authorization": "Bearer " + KEY},
                json={"model": MODEL, "messages": messages, "stream": True},
                timeout=60,
            )
            if r.status_code == 429 or r.status_code >= 500:
                time.sleep(min(2 ** i + random.uniform(0, 1), 30))
                continue
            r.raise_for_status()
            return r.json()
        except requests.exceptions.Timeout:
            time.sleep(min(2 ** i + random.uniform(0, 1), 30))
    raise RuntimeError("gave up after " + str(retries) + " retries")


print(chat([{"role": "user", "content": "hello"}]))

Wichtige Daten zu diesem Modell

API-Endpunkthttps://api.airai.cc/v1
OpenAI-kompatibelOpenAI-compatible
AnbieterxAI
Kontext256K
FunktionenReasoning, Tools, Files, Vision
API-Formateopenai, openai-response, openai-response-compact, anthropic, gemini, openai-alpha-search
Abrechnungsformelp * 1 + cr * 0.2 + c * 2) : tier("200k_plus", p * 2 + cr * 0.4 + c * 4

Häufige Fragen

Wie sollte ich Batch-Jobs planen, wenn grok-build-0.1 504 liefert?

Parallelität und Timeouts sind hier die eigentlichen Variablen, nicht das Modell. Senken Sie zuerst die Parallelität — die meisten Durchsatzprobleme verschwinden dann. Dieses Modell hat ein Kontextfenster von 256K und stammt von xAI. Ein 256K-Kontext bedeutet, dass lange Eingaben die First-Token-Latenz deutlich erhöhen. Glätten Sie Spitzen mit Batching oder einer Warteschlange — stabiler als Parallelität spontan zu erhöhen.

Zählen fehlgeschlagene Anfragen zum Rate-Limit-Kontingent?

Keine Berechnung: Nur tatsächlich erzeugter Output zählt zum Verbrauch. Die Abrechnung folgt p * 1 + cr * 0.2 + c * 2) : tier("200k_plus", p * 2 + cr * 0.4 + c * 4, ohne Ausgabe also keine Kosten. Bei Abrechnung nach p * 1 + cr * 0.2 + c * 2) : tier("200k_plus", p * 2 + cr * 0.4 + c * 4 stammen die Kosten langer Ausgaben vor allem aus Output-Tokens. Prüfen Sie zuerst Guthaben und Rate-Limits in der Konsole, dann den Code.

Exponentielles Backoff oder festes Intervall?

Ein Retry ist der wirksamste erste Schritt. Bei der Abrechnung p * 1 + cr * 0.2 + c * 2) : tier("200k_plus", p * 2 + cr * 0.4 + c * 4 werden fehlgeschlagene Anfragen nicht angerechnet. Setzen Sie die Obergrenze auf 3–5 Versuche und ergänzen Sie Jitter.

Behebt ein vergleichbares Modell eines anderen Anbieters 504?

Halten Sie zusätzlich ein Ausweichmodell bereit. Dieses Modell von xAI hat mehrere Upstream-Knoten, zwischen denen das Gateway wechseln kann. Halten Sie ein leichteres Ersatzmodell bereit, damit der Hauptfluss nicht abbricht. Legen Sie den Modellnamen in die Konfiguration, dann braucht ein Upstream-Wechsel keine Codeänderung.

Weitere Fehler bei diesem Modell

Andere Modelle mit demselben Fehler

Zurück zur Modellseite

Daten aktualisiert: 2026-10-10 18:35

Technischer SupportLive-Support
Nach oben