Zum Hauptinhalt springen

So behebst du Meshy-API-429- und Rate-Limit-Fehler

Meshy API Rate Limits: 429-Fehler beheben

Inhaltsverzeichnis

Wenn deine Integration beim Aufruf der Meshy API auf 429-, RateLimitExceeded- oder NoMoreConcurrentTasks-Fehler stößt, erklärt dir dieser Leitfaden, warum diese Limits existieren und wie du deine Integration so gestaltest, dass sie innerhalb dieser Grenzen funktioniert.

Warum Rate Limits existieren

Meshys API liegt vor gemeinsam genutzter GPU-Rechenleistung, die zur Generierung von 3D-Modellen, Texturen und verwandten Assets verwendet wird. Rate Limits und Concurrency-Beschränkungen schützen diese gemeinsam genutzte Infrastruktur, damit Generierungsqualität und Bearbeitungszeit für jeden Nutzer der Plattform konsistent bleiben. Jedes Konto hat, abhängig von seinem aktuellen Plan, eine maximale Anzahl an Anfragen, die es in einem bestimmten Zeitfenster stellen darf, sowie eine maximale Anzahl an Generierungsaufgaben, die gleichzeitig laufen dürfen (in der Warteschlange oder in Bearbeitung).

Anfragelimit vs. Warteschlangen-/Concurrency-Limit

Es gibt zwei unterschiedliche Limits, und sie treten unterschiedlich auf:

  • Request-Rate-Limit (429 / RateLimitExceeded): Dies begrenzt, wie viele API-Aufrufe (z. B. Aufgabenerstellung, Statusabfragen) du pro Minute machen kannst. Wenn du es überschreitest, rufst du die API zu häufig auf – unabhängig davon, wie viele Aufgaben tatsächlich laufen.

  • Concurrency-/Warteschlangen-Limit (NoMoreConcurrentTasks): Dies begrenzt, wie viele Generierungsaufgaben du gleichzeitig in der Warteschlange haben oder verarbeiten kannst. Wenn du es überschreitest, hast du bereits die maximale Anzahl aktiver Aufgaben und musst warten, bis eine abgeschlossen ist, bevor du eine weitere einreichst.

Überprüfe die aktuellen Anfrage- und Concurrency-Limits deines Plans in deinem Meshy-Dashboard, da diese je nach Planstufe variieren können.

Backoff-Strategie für 429-Fehler

Wenn du eine 429- oder RateLimitExceeded-Antwort erhältst, wiederhole dieselbe Anfrage nicht sofort. Stattdessen:

  • Verwende exponentielles Backoff: Warte ein kurzes Intervall und verdopple es bei jedem weiteren Fehlschlag, bis zu einem sinnvollen Maximum.

  • Füge deinem Backoff-Intervall Jitter (einen kleinen zufälligen Versatz) hinzu, damit mehrere Worker in deinem System nicht alle im selben Moment einen neuen Versuch starten.

  • Beachte alle Retry-After- oder Rate-Limit-Header in der Antwort, falls vorhanden, anstatt eine Wartezeit zu schätzen.

  • Begrenze die Anzahl der Wiederholungsversuche pro Anfrage, damit ein dauerhafter Fehler nicht endlos in einer Schleife läuft.

Planung rund um Concurrency-Limits

Ein NoMoreConcurrentTasks-Fehler bedeutet, dass du bereits das Limit aktiver Aufgaben deines Kontos erreicht hast. Um dies in der Produktivumgebung zu vermeiden:

  • Pflege eine lokale Warteschlange oder einen Job-Scheduler in deiner eigenen Anwendung, der eine neue Generierungsaufgabe erst dann einreicht, wenn eine vorherige abgeschlossen ist oder deine Anzahl aktiver Aufgaben unter das Limit sinkt.

  • Frage den Aufgabenstatus ab (oder verwende Webhooks, falls in deinem Workflow unterstützt), um zu wissen, wann ein Slot frei wird, anstatt spekulativ Aufgaben einzureichen.

  • Fasse Massen-Generierungsjobs in Batches zusammen und drossle sie, anstatt alle Anfragen gleichzeitig abzufeuern – das glättet sowohl deine Anfragerate als auch deine Anzahl gleichzeitiger Aufgaben.

  • Baue auf deiner Seite Monitoring/Alarmierung ein, damit ein Anstieg von 429-/NoMoreConcurrentTasks-Fehlern sichtbar wird, bevor er deine Nutzer betrifft.

Wiederholen fehlgeschlagener oder unzufriedenstellender Generierungen

Die Meshy API unterstützt derzeit keine eingebaute „Wiederholen“-Funktion für eine bestehende Generierung bei Individual- oder Studio-Plänen – wenn ein Ergebnis deine Erwartungen nicht erfüllst, reichst du eine neue Generierungsanfrage ein, die wie üblich Credits verbraucht. Wenn deine automatisierte Pipeline vorübergehende Fehler (wie einen 429) behandelt, stelle sicher, dass deine Retry-Logik die ursprüngliche Anfrage erst nach einem Backoff erneut sendet und nicht jedes Mal doppelte Generierungsaufgaben erstellt.

Wann du einen Plan-Upgrade in Betracht ziehen solltest

Wenn du Backoff und Concurrency-bewusstes Queuing implementiert hast und weiterhin regelmäßig an Rate- oder Concurrency-Limits stößt, ist das meist ein Zeichen dafür, dass der Durchsatzbedarf deiner Integration die Limits deines aktuellen Plans überstiegen hat. Überprüfe in deinem Dashboard die Anfrage- und Concurrency-Zuteilungen deines aktuellen Plans und ziehe ein Upgrade in Betracht oder kontaktiere das Meshy-Vertriebsteam wegen Enterprise-API-Zugang, wenn du dauerhaft einen höheren Durchsatz benötigst.

FAQ

1. Was bedeutet ein 429- oder RateLimitExceeded-Fehler?

Er bedeutet, dass du die Anzahl der API-Anfragen überschritten hast, die in einem bestimmten Zeitfenster für deinen Plan erlaubt sind. Verlangsame deine Anfragerate und verwende exponentielles Backoff, bevor du es erneut versuchst.

2. Was bedeutet NoMoreConcurrentTasks?

Er bedeutet, dass du bereits die maximale Anzahl an Generierungsaufgaben in der Warteschlange oder in Bearbeitung für dein Konto hast. Warte, bis eine bestehende Aufgabe abgeschlossen ist, oder reduziere, wie viele Aufgaben du gleichzeitig einreichst, bevor du weitere einreichst.

3. Woher kenne ich die Rate- und Concurrency-Limits meines Kontos?

Überprüfe dein Meshy-Dashboard auf die Limits, die mit deinem aktuellen Plan verknüpft sind, da diese zwischen Planstufen unterschiedlich sein können.

4. Unterstützt Meshy automatische Wiederholungen für Generierungsaufgaben?

Nein, nicht für Individual- oder Studio-Pläne – eine fehlgeschlagene oder unzufriedenstellende Generierung muss als neue Anfrage erneut eingereicht werden, was üblicherweise Credits verbraucht. Enterprise-Kunden sollten sich wegen einer Retry-Funktion an den Vertrieb wenden.

5. Wie vermeide ich diese Fehler am besten in einer Produktions-Pipeline?

Implementiere eine lokale Warteschlange, die Einreichungen drosselt, um unter deinem Concurrency-Limit zu bleiben, füge für 429-Antworten exponentielles Backoff mit Jitter hinzu und überwache die Fehlerraten, damit du reagieren kannst, bevor sie deine Nutzer beeinträchtigen.

6. Wann sollte ich wegen Rate Limits meinen Plan upgraden?

Wenn du bereits Backoff und Concurrency-bewusstes Queuing implementiert hast und diese Limits dennoch regelmäßig erreichst, hat deine Nutzung deinen aktuellen Plan höchstwahrscheinlich überstiegen – überprüfe dein Dashboard oder kontaktiere den Vertrieb wegen eines Plans mit höherem Durchsatz.


Verwandte Artikel

Hat dies deine Frage beantwortet?