Bringen Sie eine Anfrage wieder auf Kurs.

Prüfen Sie den Servicestatus und trennen Sie dann Probleme bei Kontozugriff, API-Authentifizierung, Modellentdeckung, Inferenz und Zahlung. Ein Modell, das im Katalog erscheint, begründet keine Live-Verfügbarkeit: GET /v1/models listet verbundene Deployments auf.

Ein 503 service_unavailable bedeutet, dass der erforderliche Dienst die Anfrage nicht annehmen kann. Prüfen Sie den Servicestatus und die API-Referenz, bevor Sie es erneut versuchen; wiederholte Anfragen können einen nicht verfügbaren Dienst nicht aktivieren. Warten Sie bei einer dedizierten GPU auf die bestätigte Bereitstellung. Folgen Sie bei Zahlungen den Anweisungen der Bestellung und dem aufgezeichneten Verifizierungsstatus; das Aktualisieren einer Bestellung fügt kein Guthaben hinzu.

Notieren Sie den HTTP-Status und die code und message des Fehlers. Überprüfen Sie die konfigurierte API-Basis-URL, die exakte Modell-ID und die Client-Version, bevor Sie die Anwendungslogik ändern.

• 401: Überprüfen Sie den Bearer-Header und ob der Schlüssel widerrufen wurde. Halten Sie den vollständigen Schlüssel aus Protokollen heraus.
• 403: Wählen Sie ein Modell, das von der Zulassungsliste des Schlüssels erlaubt ist.
• 400 oder 413: Überprüfen Sie JSON, Pflichtfelder, Ausgabelimit und das kombinierte Eingabe-/Ausgabe-Kontextbudget.
• 402: Überprüfen Sie, ob das Konto eine qualifizierte bestätigte Aufladung von mindestens USD 100 hat, dann überprüfen Sie verfügbares Guthaben und das Budget des ausgewählten Schlüssels; qualifizierte Konten müssen kein Guthaben von USD 100 aufrechterhalten.
• 429: Befolgen Sie einen Retry-After-Header, falls vorhanden, verwenden Sie begrenzte Wiederholungsversuche und überprüfen Sie die geltenden Dienstlimits; es gibt kein tägliches kostenloses Testkontingent.
• 502 oder 503: Überprüfen Sie Verfügbarkeit und Fehlermeldung vor einem begrenzten Wiederholungsversuch.

Der Fehlerleitfaden und die Limits erläutern die Wiederherstellungspfade. Eine neue Anfrage kann neue Arbeit erzeugen; gehen Sie nicht davon aus, dass Client-Wiederholungsversuche dedupliziert werden.

Ein geschlossener Browser-Tab, Timeout oder unterbrochener Stream beweist nicht, dass die Generierung gestoppt hat. Speichern Sie jede Antwortkennung und den letzten Nutzungsrahmen, falls empfangen. Der letzte Nutzungsrahmen kann nach der finish_reason der Auswahl eintreffen; ein Netzwerk-Chunk ist nicht unbedingt ein vollständiges Ereignis.

Ein 409 pending_reconciliation oder ein Upstream-Fehler nach dem Versand kann Guthaben reserviert lassen, bis maßgebliche Nutzungsdaten verfügbar sind. Vermeiden Sie doppelte Anfragen, um die Sperre aufzuheben. Vergleichen Sie UTC-Zeit, Modell und Schlüsselname mit der Konsolennutzung und bewahren Sie die Anfragedetails für die Abstimmung auf. Freigabezeiten sind nicht garantiert.

Bei einem Zahlungsproblem notieren Sie Bestellreferenz, Asset, Netzwerk, Betrag und sichtbaren Status. Senden Sie niemals eine weitere Zahlung, nur weil die erste aussteht. Wallet-Abhebungen sind derzeit nicht verfügbar. Das Stornieren einer bezahlten GPU-Bestellung vor der Aktivierung erstattet die Zahlung auf das WeightsAPI-Kontoguthaben; es überweist keine Gelder an eine Wallet.

Ein nützlicher Bericht enthält den Vorgang, den UTC-Zeitstempel, den Endpunktpfad, die Modell-ID, das SDK oder die Integration und Version, die Streaming-Einstellung, das Ausgabetoken-Limit, Status/Fehler, erwartetes Ergebnis und tatsächliches Ergebnis. Fügen Sie eine Antwort- oder Transaktionsreferenz nur hinzu, wenn verfügbar; das Gateway legt derzeit nicht bei jedem Fehler eine Support-ID offen.

Fügen Sie das kleinste synthetische Beispiel hinzu, das das Problem reproduziert. Ersetzen Sie echte Gespräche, Kundendatensätze und private Dokumente durch erfundenen Text. Geben Sie relevante Wiederholungszahlen an und ob das Problem über Anfragen hinweg wiederholt auftritt. Screenshots sollten den Fehler und den Kontext zeigen, nachdem Sie Anmeldeinformationen, Guthaben oder Kennungen entfernt haben, die Sie nicht teilen möchten.

Für eine Bestellung einer dedizierten GPU geben Sie bitte die Bestellreferenz, Konfiguration und den sichtbaren Zahlungs- oder Bereitstellungsstatus an. Eine ausstehende Bestellung ist keine aktive Maschine.

Geben Sie niemals ein API-Geheimnis, einen Authorization-Header, ein Session-Cookie, einen privaten Wallet-Schlüssel, eine Wiederherstellungsphrase oder eine vollständige Umgebungsdatei an. Ein Schlüsselname oder ein absichtlich gekürztes Präfix reicht aus, um Anwendungen zu unterscheiden. Öffentliche Transaktionsreferenzen können weiterhin Aktivitäten mit einer Wallet verbinden; teilen Sie nur, was die Untersuchung benötigt.

Wenn ein Schlüssel offengelegt wurde, erstellen Sie einen Ersatz, aktualisieren Sie die Anwendung und widerrufen Sie den alten Schlüssel. Der Widerruf blockiert neue Zulassungen; zuvor zugelassene Anfragen werden normal abgerechnet. Siehe Authentifizierung für die Schlüsselbehandlung.

Kopieren und überprüfen Sie Ihren Bericht und bewahren Sie ihn mit der relevanten Anfrage- oder Bestellreferenz auf. Das Kopieren reicht kein Ticket ein. Offizielle Support-Kontakte und Servicezeiten sind nicht veröffentlicht; verwenden Sie nur einen bestätigten Kanal, um einen Bericht zu teilen.

Antwortziele, Eskalationskontakte und Servicegutschriften wurden nicht festgelegt. Halten Sie Anmeldeinformationen und sensible Kundeninhalte aus Ihrem Bericht heraus.