Bei der Anbindung von Seedance wählen viele Teams zuerst einen Relay- oder Proxy-Zugang: Base URL und Key ändern, fertig – scheinbar weniger Aufwand als eine Direktverbindung. Videoerzeugung ist jedoch asynchron, und die Relay-Kette hat mehr Glieder als eine Text-Schnittstelle: Aufgabenspeicherung, Statusabbildung, Ergebnissicherung und Callbacks. Ist ein Glied schwach, zeigt sich das als „Aufgabe erfolgreich eingereicht, aber kein Video verfügbar“.

Dieser Artikel folgt der tatsächlichen Relay-Kette und erklärt Aufgabenzuverlässigkeit, Ergebnisaufbewahrung, Abrechnungstransparenz, Key-Risiken und die Abnahme bei einer Migration weg von der Direktverbindung.

Hinweis: Seedance ist der Name eines Videogenerierungsmodells von ByteDance/Volcengine; die Marken gehören den jeweiligen Rechteinhabern. Dieser Artikel dient ausschließlich der technischen Erläuterung; es besteht keine Zugehörigkeit oder Kooperation mit ByteDance. Schnittstellen, Modelle und Preise richten sich nach der offiziellen Dokumentation und Modellpreise.

1. Vier Arten von „Relay“ unterscheiden

Typ Aufgabe Hauptrisiko Geeignet für
Reverse Proxy Anfragen an die offizielle Schnittstelle weiterleiten Einzelpunkt, Ausgangsbandbreite, Auth-Konfiguration Teams mit Betriebskompetenz
Aggregations-Gateway Einheitlicher Zugang zu mehreren Modellanbietern Statusabbildung, Parameterunterschiede Unternehmen mit mehreren Modellen
Wiederverkauf oder stellvertretende Aufladung Upstream-Kontingent weiterverkaufen oder bezahlen Upstream-Stabilität, Geschäftsbedingungen Kleine Tests, kurzfristiger Bedarf
Eigenes Gateway Weiterleitungsschicht selbst betreiben Vollständige Verantwortung Technikteam mit Datenkontrolle

Ob man „technische Dienstleistung“ oder „Modellkontingent“ kauft, entscheidet darüber, wer bei Problemen haftet. Vertrag, Rechnung und Datenverarbeitungsbedingungen müssen zu dieser Unterscheidung passen.

2. Welche zusätzlichen Glieder eine asynchrone Aufgabe im Relay erhält

Ihr Dienst
  → Relay-Eingang (Authentifizierung, Rate-Limit, Abrechnung)
  → Upstream erstellt Aufgabe, liefert task_id
  → Relay speichert Zuordnung von task_id und Vorgangsnummer
  → Relay fragt Upstream ab oder empfängt Callback
  → Statusabbildung, Bereitstellung über Polling-Schnittstelle oder Webhook
  → Sie laden das Ergebnis herunter und sichern es

Jede zusätzliche Station ist ein möglicher Ort für Statusverlust:

  • Das Relay startet neu oder wechselt die Instanz; die Zuordnung im Speicher geht verloren.
  • Der Upstream läuft in einen Timeout, hat die Aufgabe aber erstellt; das Relay meldet Fehler, der Aufrufer wiederholt und erzeugt zwei Videos.
  • Der Upstream meldet expired, das Relay bildet nur Erfolg und Fehler ab; die Anwendung wartet endlos.
  • Das Relay cached die Ergebnis-URL unter eigener Adresse, holt nach Ablauf aber nicht vom Upstream nach.
  • Webhook-Wiederholungen haben keinen Idempotenzschlüssel; die Anwendung speichert doppelt.

Bei der Bewertung nicht nur fragen „unterstützt es Seedance“, sondern wie Aufgaben-IDs persistiert, Status abgebildet und Fehler kompensiert werden.

3. Aufgabenstatus und Ergebnisaufbewahrung

Laut Volcano-Ark-Dokumentation umfassen Seedance-Aufgabenstatus üblicherweise queued, running, succeeded, failed, cancelled und expired. Aufgabenabfragen decken meist nur die letzten 7 Tage ab; die Video-URL erfolgreicher Aufgaben wird üblicherweise nach 24 Stunden bereinigt.

Ein Relay muss über diesen beiden Grenzen eine eigene Schicht bieten:

  • Werden Aufgaben aufgezeichnet? Wie lange? Sind sie nach 7 Tagen noch abfragbar?
  • Lädt das Relay Videos selbst herunter? Wie lange werden sie gespeichert, kostet das extra?
  • Gibt es die temporäre Upstream-URL zurück oder eine eigene dauerhafte Adresse?
  • Wie werden Abbruch, Timeout und Prüfablehnung auf Status abgebildet?

Ein reines „Durchreichen“ lässt die 24-Stunden-Sicherung beim Aufrufer. Ein „Hosting“-Ansatz muss Speicherort, Zugriffsrechte und Löschmechanismus offenlegen. Beides ist möglich, Unklarheit nicht.

4. Abrechnungstransparenz prüfen

Bei Videoaufgaben entstehen leichter Streitfälle als bei Text, weil Fehler, Wiederholungen und Abbruch in der asynchronen Phase liegen. Vor Vertragsabschluss klären:

  • Abrechnung nach Dauer, Auflösung, Aufgabe oder Token-Äquivalent?
  • Werden Fehler, Timeout, Abbruch und Prüfablehnung jeweils berechnet?
  • Werden doppelte Einreichungen und Wiederholungen doppelt berechnet, gibt es Idempotenz?
  • Gibt es Mindestumsatz, Vorauszahlungsschwelle, Rückerstattungsregeln und Rechnungsart?
  • Enthält die Nutzungsdetails Aufgaben-ID, Modell, Dauer, Auflösung, Status und abgebuchten Betrag?

Nicht nur den Rabatt auf der Werbeseite betrachten. Mit 20 bis 50 kleinen Aufgaben über eine Woche Erfolgs- und Fehlerzahlen sowie Rechnung Zeile für Zeile abgleichen; das ist verlässlicher als jede mündliche Zusage. Konkrete Preise stehen unter Modellpreise.

5. Keys und Upstream-Risiken

Ein Relay bedeutet, dass Anfrageinhalte durch Dritte laufen. Mindestens klären:

  1. Werden Prompt, Startbild und erzeugtes Video gespeichert, wie lange?
  2. Werden Daten zum Training oder zur Dienstverbesserung verwendet?
  3. Lassen sich Keys nach Kontingent, IP und Ablaufdatum begrenzen?
  4. Wie wird bei Leck oder Missbrauch benachrichtigt und gesperrt?
  5. Ist der Upstream ein einzelner Kanal oder mehrere, und wie wird bei Modellabkündigung migriert?
  6. Erlauben die Geschäftsbedingungen Wiederverkauf oder Proxy, und wie ist die Haftungsgrenze?

Produktions-Keys gehören nicht ins Frontend oder in öffentliche Repositories. Bei sehr sensiblen Materialien Anbieter mit nicht gespeicherten Daten oder Datenverarbeitungsvertrag wählen; ist das nicht bestätigt, keine unanonymisierten Kundenmaterialien hochladen.

6. Migration von der Direktverbindung zum Relay

  1. Bestehende Aufrufe erfassen: Modell-ID, Parameter, Parallelität, Durchschnittsdauer und Fehlertypen.
  2. Schnittstellenpfad, Authentifizierung und Feldunterschiede des Relays klären und eine Zuordnungstabelle erstellen.
  3. In der Testumgebung die vier Pfade Erstellen, Abfragen, Abbrechen und Download durchspielen.
  4. Dieselbe Aufgabengruppe als Shadow-Betrieb über Direktverbindung und Relay senden, nur vergleichen, nicht umschalten.
  5. Erfolgsquote, P95-Dauer, Downloadquote und Kosten pro Video vergleichen.
  6. Mit 5 bis 20 Prozent Traffic stufenweise umstellen und einen Rückfallschalter zur Direktverbindung behalten.
  7. Drei bis sieben Tage beobachten und Rechnung sowie Aufgabendetails abgleichen.
  8. Nach der Vollumstellung kurzzeitig beide Kanäle als Absicherung behalten und die Architektur erst nach Stabilität vereinfachen.

Während der Migration den Direktverbindungs-Key nicht löschen und beide Aufgabensätze nicht unter derselben Vorgangsnummer speichern, sonst ist der Abgleich nicht mehr möglich.

7. Ein Relay testen

# 1. Minimale Aufgabe senden, task_id und Sendezeit speichern
curl -X POST "$RELAY_BASE_URL/contents/generations/tasks" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"Modell-ID laut Relay-Dokumentation","content":[{"type":"text","text":"Eine Katze gähnt am Fenster"}]}'

# 2. Alle 10 Sekunden abfragen und den vollständigen Statusverlauf festhalten
curl "$RELAY_BASE_URL/contents/generations/tasks/$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

Gezielt Ausnahmen erzeugen: sofort nach dem Senden abbrechen, falsche Modell-ID senden, parallel einreichen, Download mittendrin abbrechen. Beobachten, ob Status, Fehlermeldung und Rechnung konsistent sind. Nach 24 Stunden die Ergebnisadresse erneut aufrufen und prüfen, ob der Download noch möglich ist; nach 7 Tagen die Aufgabe erneut abfragen, ob der Datensatz noch existiert.

8. Monitoring und Rückfall nach der Migration

  • Aufgabenzahl nach Status zählen, besonders Anteil von failed, cancelled und expired.
  • Gesamtdauer von Einreichung bis Erfolg sowie Warte- und Erzeugungszeit erfassen.
  • Download-Erfolgsquote überwachen und für Fehler eine Kompensationsqueue vorhalten.
  • 401, 404, 429 und 5xx zählen und Key-, Modell- und Rate-Limit-Probleme trennen.
  • „Kosten pro erfolgreichem Video“ berechnen, nicht nur den Anfragepreis.
  • Rückfallschwellen definieren, etwa bei zwei Stunden deutlich unter Baseline liegender Erfolgsquote zurück zur Direktverbindung.

Häufige Fragen

Hat ein Relay dieselben Modellfähigkeiten wie die Direktverbindung?

Das hängt davon ab, ob dasselbe Upstream-Modell mit denselben Parametern weitergeleitet wird. Modell-ID, Dauer, Auflösung und Audiofähigkeiten können abweichen. Vor der Anbindung mit identischem Prompt Ausgabe und Parameterunterstützung vergleichen.

Speichert das Relay meine Videos?

Das ist bei jedem Dienst anders. Klären, ob gespeichert wird, wie lange, wo, wer zugreifen kann und wie gelöscht wird. Bei Kundenmaterialien Anbieter mit klaren Bedingungen bevorzugen.

Was tun, wenn eine Aufgabe im Relay verloren geht?

Zuerst über die Vorgangsnummer den lokalen Datensatz prüfen, dann Relay-Logs und Upstream-Aufgabe. Lässt sich nichts wiederherstellen, bleibt nur eine Neueinreichung. Deshalb vor der Migration klären, ob das Relay Aufgaben-Zuordnungen persistiert und Abfragen nach Vorgangsnummer erlaubt.

Warum passen Rechnung und Aufgabenzahl nicht zusammen?

Häufige Ursachen sind doppelte Einreichungen, Wiederholungen nach Fehlern, abweichende Abbruchregeln, Mindestumsatz oder Cache-Treffer. Eine Aufschlüsselung nach Aufgaben-ID anfordern und Zeile für Zeile prüfen, nicht nur die Summe.

Ist für die Migration eine Codeänderung nötig?

Ist das Relay OpenAI- oder offiziell kompatibel, genügen meist Base URL, Key und wenige Felder. Weichen Statusabbildung oder Callback-Format ab, müssen Polling und Speicherlogik angepasst werden. Ein Shadow-Betrieb zeigt die meisten Unterschiede vorab.

Nächste Schritte

Zuerst bei ZSQH AI Gateway einen Test-Key erstellen und mit einer minimalen Aufgabe die vier Pfade Erstellen, Abfragen, Download und Rechnung prüfen, dann stufenweise migrieren. Modelle und Preise stehen unter Modellpreise.

Weiterlesen: