Seedance ist ein Videogenerierungsmodell von ByteDance. Anders als bei Textmodellen arbeitet die API mit asynchronen Aufgaben: Nach dem Einreichen erhält man nur eine Aufgaben-ID, muss den Status abfragen und das Video nach Erfolg herunterladen. Für Teams in China geht es daher nicht nur darum, ob eine Anfrage überhaupt hinausgeht, sondern auch um Zahlung und Rechnung, Wartezeiten, Ergebnisübertragung und Störungsumschaltung.

Dieser Artikel vergleicht drei übliche Wege: die offizielle Direktverbindung über Volcano Ark, einen selbst betriebenen Reverse-Proxy und ein inländisches AI-Gateway. Dazu kommen Methoden für Abfrage, Lieferung und Validierung.

Hinweis: Seedance ist ein Videogenerierungsmodell von Volcano Engine unter ByteDance; die zugehörigen Marken gehören ihren Inhabern. Dieser Artikel dient ausschließlich der technischen Erläuterung und begründet keine Zugehörigkeit oder Geschäftsbeziehung zu ByteDance. Schnittstellen, Modelle und Preise richten sich nach der offiziellen Dokumentation und der Seite Modellpreise.

1. Drei Wege in einer Tabelle

Dimension Offizielle Direktverbindung Eigener Proxy Inländisches AI-Gateway
Zugang Offizielle Volcano-Ark-Adresse Selbst betriebener Reverse-Proxy Einheitlicher OpenAI-kompatibler Zugang
Netzwerk Abhängig vom lokalen Ausgang und der Region Abhängig vom Proxyserver Vom Anbieter betrieben, lokales Netz bleibt relevant
Zahlung Über offiziell unterstützte Auflademethoden Server und Bandbreite zunächst selbst tragen Aufladung im Portal, Regeln laut Seite
Rechnung Nach offiziellen Regeln beantragen Selbst abwickeln Nach den Rechnungsregeln des Anbieters
Modellumfang Offiziell freigegebene Seedance-Modelle Durch Proxy-Konfiguration bestimmt Je nach Freischaltung, eventuell mehrere Videomodelle
Betriebsaufwand Niedrig Hoch Mittel
Geeignete Teams Einzelmodell, offizieller Ablauf machbar Mit Netzwerkbetriebserfahrung Mehrere Modelle, einheitliche Rechnung

Kein Weg passt für alle. Die Prüfreihenfolge lautet: Kann der Betrieb Ausfälle akzeptieren? Werden mehrere Modelle und Rechnungen gebraucht? Gibt es jemanden, der den Proxy dauerhaft betreut?

2. Offizielle Direktverbindung: zuerst eine asynchrone Aufgabe durchlaufen

Die Videogenerierungsschnittstelle von Volcano Ark besteht üblicherweise aus zwei Schritten: Aufgabe anlegen und Aufgabe abfragen. Die Base URL sieht etwa so aus: https://ark.cn-beijing.volces.com/api/v3. Tatsächlich verfügbare Regionen, Modell-IDs und Felder richten sich nach Konsole und Dokumentation.

  1. In der Volcano-Ark-Konsole das Videogenerierungsmodell aktivieren und Konto- sowie Compliance-Anforderungen prüfen.
  2. Einen eigenen API Key anlegen, zum Beispiel seedance-test, und nicht mit dem Produktions-Key mischen.
  3. Die Modell-ID aus der Konsole kopieren, nicht aus dem Gedächtnis mit Versionssuffix zusammensetzen.
  4. Eine Testaufgabe mit kürzester Dauer und niedrigster Auflösung einreichen.
  5. Die zurückgegebene Aufgaben-ID notieren und den Status bis zum Abschluss abfragen.
export ARK_API_KEY="dein-schluessel"
export BASE_URL="https://ark.cn-beijing.volces.com/api/v3"

curl -X POST "$BASE_URL/contents/generations/tasks" \
  -H "Authorization: Bearer $ARK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "modell-id-aus-der-konsole",
    "content": [
      {"type": "text", "text": "Stadtstraße nach dem Regen, langsamer Kameraschwenk, filmische Optik"}
    ]
  }'

Wenn die Anfrage in eine Zeitüberschreitung läuft, in der Konsole aber eine Aufgabe erscheint, wurde sie bereits angelegt. Nicht sofort erneut einreichen, sonst entstehen zwei Videos und doppelte Kosten. Zuerst anhand der Geschäftsvorgangsnummer nach der Aufgabe suchen, dann über eine Wiederholung entscheiden.

3. Eigener Proxy: löst den Ausgang, nicht die Warteschlange

Ein eigener Proxy wird üblicherweise als Reverse-Proxy auf einem Server betrieben, der die offizielle Schnittstelle stabil erreicht. Das mildert Probleme am lokalen Ausgang, bringt aber neue Arbeit:

  • Der Proxyserver ist ein Single Point of Failure; bei Ausfall scheitern alle Aufgaben gemeinsam.
  • TLS, Authentifizierung, Zugriffskontrolle und Protokolle müssen abgesichert werden, damit der Proxy nicht missbraucht wird.
  • Videoanfragen sind groß und dauern lange; Bandbreite und Verbindungszahl des Proxys werden leicht zum Engpass.
  • Eine weitere Weiterleitung beschleunigt die Warteschlange der Vorleistung nicht; in Stoßzeiten bleibt die Wartezeit.
  • Netzwerk- und Compliance-Verantwortung bleiben beim Team.

Ohne feste Betreuung wird aus dem Proxy schnell eine „temporäre Lösung“, die zur Dauerlast wird. Er kann als Übergang dienen, sollte aber nicht der einzige Zugang sein.

4. AI-Gateway: Zugang, Rechnung und Wechsel an einem Ort

Der Wert eines inländischen AI-Gateways liegt darin, Key-Verwaltung, Aufladung, Verbrauchsdetails, Rechnungen und Modellwechsel zu bündeln. Der Geschäftscode kennt nur einen Zugang; ein Modellwechsel ändert die Konfiguration, nicht den Code. Für Teams, die Text-, Bild- und Videomodelle parallel nutzen, ist das wichtiger als einige Millisekunden Latenz.

Bei der Gateway-Auswahl prüfen: Ist die Seedance-Videofunktion freigeschaltet, welche Modelle und Parameter werden unterstützt, wie werden Aufgabenstatus abgebildet, wie werden Fehler und Abbruch abgerechnet, wie lange bleiben Ergebnis-URLs gültig, wie wird bei Störungen informiert. Bei ZSQH AI Gateway lässt sich ein Test-Key anlegen, eine minimale Aufgabe durchlaufen und anschließend die Seite Modellpreise sowie die Abrechnungslogik prüfen.

Ein Gateway verändert die Kapazität der Vorleistung nicht. Es vereinheitlicht den Zugang und erleichtert die Störungsbehandlung, kann aber keine Warteschlangenfreiheit in Stoßzeiten zusagen.

5. Abfrage und Ergebnislieferung: die eigentliche Schwierigkeit der Videoschnittstelle

Laut Volcano-Ark-Dokumentation umfassen Aufgabenstatus üblicherweise queued, running, succeeded, failed, cancelled und expired. Die Aufgabenabfrage deckt in der Regel nur die letzten 7 Tage ab, und die video_url einer erfolgreichen Aufgabe wird meist nach 24 Stunden bereinigt. Diese beiden Punkte bestimmen das Systemdesign direkt.

  • Einreichen und Abfragen trennen; eine HTTP-Anfrage nicht mehrere Minuten synchron warten lassen.
  • Die Abfrage mit 5 Sekunden beginnen und schrittweise auf 15–30 Sekunden zurücknehmen; ein Gesamt-Timeout setzen.
  • Erfolgreiche Antworten können ein error-Objekt enthalten; bei Fehlschlag error.code und error.message protokollieren.
  • Nach Erhalt der video_url sofort in den eigenen Object Storage herunterladen; die temporäre URL nicht dauerhaft im Geschäftsbetrieb verwenden.
  • Nach dem Download Dateigröße und Abspielbarkeit prüfen, dann eine eigene signierte URL oder CDN-Adresse erzeugen.
  • Das Abbrechen von Aufgaben wirkt üblicherweise nur bei Aufgaben in der Warteschlange; genaue Regeln laut Dokumentation.

Die Ergebnislieferung sollte ein eigener Schritt sein: Download, Transkodierung, Prüfung und Ablage jeweils wiederholbar. So gehen bei Ablauf der Vorleistungs-URL nicht zugleich Geschäftsdaten verloren.

6. Zahlung, Rechnung und Vertrag

  • Teams mit Zahlung per Firmenkonto sollten Auflademethode, Gutschriftszeit, Rechnungsart und Abrechnungszyklus vorab klären.
  • Klären, wie Fehlschlag, Zeitüberschreitung und Abbruch abgerechnet werden und ob Erstattung oder Kontingentrückgabe möglich ist.
  • Verbrauchsdetails pro Aufgabe oder Key anfordern, mindestens mit Aufgaben-ID, Modell, Dauer und Status.
  • Datenbedingungen lesen und prüfen, ob hochgeladene Bilder, Prompts und Ergebnisse aufbewahrt oder zur Serviceverbesserung genutzt werden.
  • Produktions-Keys gehören nicht ins Frontend und nicht in öffentliche Repositories; nach Umgebung trennen und Obergrenzen setzen.

7. Störungsumschaltung: Wiederholungen richtig bauen

Wiederholungen bei Videoaufgaben sind teurer als bei Text, denn jeder Versuch ist eine vollständige Generierung. Empfohlen:

  1. Für jede Geschäftsvorgangsnummer eine eindeutige Anfragekennung erzeugen und vor dem Einreichen prüfen, ob bereits eine Aufgabe existiert.
  2. Nur bei 429, 5xx und Verbindungs-Timeout mit Backoff wiederholen; Parameterfehler und Moderationsablehnung nicht.
  3. Bei aufeinanderfolgenden Fehlern bis zur Schwelle eine Unterbrechung (Circuit Breaker) auslösen, um eine Wiederholungslawine zu vermeiden.
  4. Ersatz-Zugang oder Ersatzmodell vorbereiten, nach dem Wechsel aber den Aufgabenstatus neu prüfen, damit nicht beide Wege je ein Video erzeugen.
  5. Täglich abgleichen: Aufgabenzahl, Erfolgszahl und abgerechnete Zahl vergleichen und bei Auffälligkeiten den Verkehr stoppen.

8. Prüfliste vor dem Start

  1. Eine minimale Aufgabe lässt sich erfolgreich einreichen, die Aufgaben-ID kommt stabil zurück.
  2. Alle sechs Aufgabenstatus werden korrekt erkannt und gespeichert.
  3. Abfrage-Timeout, maximale Wiederholungen und Circuit-Breaker-Schwelle sind konfiguriert.
  4. Erfolgreiche Ergebnisse werden innerhalb von 24 Stunden übertragen; für Downloadfehler gibt es Ausgleichsaufgaben.
  5. Abrechnungsregeln für Fehlschlag, Abbruch und Timeout sind bestätigt.
  6. Das Ratenlimitverhalten bei parallelen Einreichungen ist getestet, 429 erhält Backoff.
  7. Rechnung und Aufgaben details lassen sich Position für Position abgleichen.
  8. Über 7 Tage Erfolgsquote, P95-Dauer und Kosten pro Video erfassen, dann über Skalierung entscheiden.

Häufige Fragen

Lässt sich die Seedance API aus China direkt aufrufen?

Das hängt von Konto, Region, Netzwerk und Compliance-Bedingungen ab. Die offizielle Direktverbindung ist ein möglicher Weg, aber Produktionsumgebungen brauchen dennoch Timeout, Wiederholungen und einen Ersatzzugang. Maßgeblich sind offizielle Dokumentation und lokale Vorschriften.

Was ist stabiler: Direktverbindung oder Gateway?

Eine einheitliche Antwort gibt es nicht. Die Direktverbindung spart eine Weiterleitung, lässt aber die Störungsbehandlung beim Team; das Gateway vereinheitlicht Zugang und Rechnung, fügt aber eine Abhängigkeit hinzu. Mit derselben Aufgabenmenge Erfolgsquote und P95 vergleichen und dann nach Betriebsfähigkeit entscheiden.

Wie lange dauert die Erzeugung eines Videos?

Abhängig von Warteschlange, Dauer, Auflösung und Last der Vorleistung sind wenige Dutzend Sekunden bis mehrere Minuten üblich. Produktionssysteme sollten ein Gesamt-Timeout setzen und den Aufgabenstatus für den Fachbereich sichtbar machen.

Wie lange bleiben Ergebnisse erhalten?

Laut Volcano-Ark-Dokumentation deckt die Aufgabenabfrage üblicherweise die letzten 7 Tage ab, und Ergebnis-URLs werden meist nach 24 Stunden bereinigt. Ergebnisse sofort in den eigenen Object Storage übertragen und nicht auf temporäre Links verlassen.

Werden fehlgeschlagene oder abgebrochene Aufgaben berechnet?

Die Regeln unterscheiden sich je Plattform und Fehlerursache. Vor der Anbindung klären, wie Moderationsablehnung, Systemfehler, Timeout und aktiver Abbruch abgerechnet werden; maßgeblich sind die Rechnungsdetails.

Nächster Schritt

Zuerst bei ZSQH AI Gateway einen Test-Key anlegen und eine Seedance-Aufgabe mit minimaler Konfiguration ausführen. Statusübergänge, Ergebnisübertragung und Abrechnungslogik prüfen, dann über den Produktionsweg entscheiden. Modelle und Preise richten sich nach Modellpreise.

Weiterlesen: