Die Rechnung der Seedance-Video-API ist selten einfach „Anzahl erzeugter Videos mal Festpreis“. Bei gleicher Fünf-Sekunden-Länge verändern Auflösung, Modellstufe, Videoeingabe, fehlgeschlagene Retries und Speicherung der Ergebnisse die tatsächlichen Ausgaben. Wer mit dem Listenpreis kalkuliert, sieht nach dem Start häufig eine höhere Rechnung – meist nicht wegen gestiegener Stückpreise, sondern weil diese Variablen nicht eingerechnet wurden.

Dieser Artikel zerlegt die Abrechnung in vier Dimensionen: Dauer, Auflösung, Retries und Speicher. Dazu gibt es Schätzformeln, Testschritte und Methoden zur Budgetkontrolle. Konkrete Stückpreise und Abrechnungsgrundlagen ändern sich; maßgeblich sind die Seite Modellpreise und die Abrechnungsdokumentation des Anbieters.

Hinweis: Seedance ist ein Videogenerierungsmodell von ByteDance. Seedance, Doubao, Volcano Engine und BytePlus sind Marken der ByteDance Ltd. und ihrer verbundenen Unternehmen. Dieser Artikel dient ausschließlich der technischen Erläuterung; es besteht keine Zugehörigkeit und kein Vertretungsverhältnis zu den Rechteinhabern. Preise, Schnittstellen und Abrechnungsregeln richten sich nach der Anbieterdokumentation und der Preisseite.

1. Warum die Video-API nicht pro „Stück“ kalkuliert werden kann

Text-APIs haben eine relativ einheitliche Abrechnungseinheit, Video-APIs nicht. Hinter einer Anfrage „erzeuge ein Video“ stehen mindestens vier Variablen: Dauer, Auflösung, Modellstufe und Eingabeart. Ändert sich eine davon, kann die Rechnung anders aussehen.

Erschwerend kommt hinzu: Eine Übermittlung bedeutet nicht automatisch ein brauchbares Ergebnis. Ablehnungen durch die Prüfung, Timeouts und unbrauchbare Bilder führen zu Retries; nach Ablauf eines Ergebnislinks muss neu generiert oder umgespeichert werden. Wer nur „Anzahl mal Stückpreis“ rechnet, unterschätzt die Kosten systematisch.

2. Vier Abrechnungsdimensionen

Dimension Wirkung auf die Kosten Bei der Schätzung erfassen Kontrollmaßnahme
Dauer Wird nach Sekunden oder umgerechneten Tokens summiert; länger bedeutet mehr Verbrauch Übermittelte Dauer, Filmlänge, Segmentierung Zuerst kurze Stufe testen, fertige Szenen später zusammenfügen
Auflösung Die Pixelmenge steigt mit der Auflösung, oft zusätzlich beeinflusst von der Bildrate Ausgabeauflösung, Bildrate, Seitenverhältnis Entwurf in niedriger Auflösung, finale Fassung höher
Modell und Eingabe Generation, Stufe und Eingabeart haben unterschiedliche Preise Modellname, Startbild oder Referenzvideo Nach Aufgabenschwierigkeit aufteilen, nicht standardmäßig die höchste Stufe
Fehler und Retries Doppelte Übermittlung kann doppelt kosten; Regeln für Fehlaufgaben variieren Aufgabenstatus, Fehlercode, Retry-Anzahl Fehler klassifizieren, Idempotenz, Retries begrenzen
Speicher und Traffic Um speichern, Vorhalten und Ausliefern entstehen Zusatzkosten Dateigröße, Aufbewahrungstage, Zugriffe Lebenszyklus-Bereinigung, bedarfsgerechte Auslieferung

Neuere Seedance-Generationen werden in der Anbieterdokumentation nach Tokens gemessen; der Verbrauch hängt von Auflösung, Dauer und Eingabeszenario ab. Einige Gateways rechnen das in Sekunden oder Stück um. Klären Sie vor Vertragsabschluss die Abrechnungseinheit der Rechnung.

3. Wie Dauer und Auflösung den Verbrauch vervielfachen

Die Dauer ist die offensichtlichste Variable. Übliche Stufen sind fünf und zehn Sekunden, aber zehn Sekunden sind nicht zwangsläufig genau doppelt so teuer: Manche Plattformen haben eine Mindestabrechnungseinheit, andere rechnen auf gerundete Sekunden. Für das Budget zählt der tatsächliche Abzug auf der Rechnung, nicht eine Rückrechnung aus der Filmlänge.

Der Einfluss der Auflösung ist weniger offensichtlich. Von 720p auf 1080p steigt die Pixelmenge etwa auf das 2,25-Fache; wird gleichzeitig die Bildrate erhöht, steigt der Verbrauch weiter. Die Rechnung folgt aber nicht zwingend genau diesem Faktor, weil Modellstufe, Rabatte und Rundung mitspielen. Richtig ist ein Vergleichstest mit festem Prompt und fester Dauer, bei dem nur die Auflösung geändert und die Differenz der Abbuchung notiert wird.

Auch das Seitenverhältnis beeinflusst die Pixelmenge. Hoch- und Querformat können bei derselben „Auflösungsstufe“ unterschiedliche Pixelzahlen haben; legen Sie dafür getrennte Budgets an statt eines gemeinsamen Monatsdurchschnitts.

4. Warum Retries und Speicher oft vergessen werden

Fehlgeschlagene Retries sind der am leichtesten außer Kontrolle geratende Teil der Videokosten. Parameterfehler sollten nicht wiederholt werden, wiederholte Übermittlungen nach einer Prüfungsablehnung sind meist wirkungslos; nur Rate-Limits und bestimmte Serverfehler eignen sich für einen Backoff-Retry.

Legen Sie die Aufgaben-ID in der Datenbank ab, prüfen Sie vor der Übermittlung auf Idempotenz und verwenden Sie bei einem Retry denselben Geschäftsdatensatz. Sonst kann eine Skriptschleife innerhalb weniger Minuten Dutzende identische Aufgaben einreichen, und die Rechnung wird unangenehm.

Speicherkosten werden häufig übersehen. Ergebnislinks haben meist eine begrenzte Gültigkeit; nach Ablauf ist eine Neugenerierung nötig. Nach dem Umspeichern in den Objektspeicher entstehen Speicher-, Anfrage- und ausgehende Traffic-Kosten. Speichern Sie nach Erfolg und legen Sie Bereinigungsregeln fest: Entwürfe sieben Tage aufbewahren, fertige Filme projektbezogen archivieren, verworfene Materialien zeitnah löschen.

5. Die Kosten pro Video als Formel

Aussagekräftiger als „Stückpreis mal Dauer“ ist der Kostenwert pro brauchbarem Video:

Kosten pro brauchbarem Video = (Kosten erfolgreicher Aufgaben + Kosten fehlgeschlagener, aber berechneter Aufgaben + Speicher und Traffic + manuelle Prüfung) ÷ Anzahl der geprüften, direkt verwendbaren Videos

Der Nenner zählt brauchbare Filme, nicht Übermittlungen. Das folgende Python-Beispiel rechnet um; die Beträge werden aus der Rechnung gelesen und nicht im Code festgeschrieben:

def cost_per_usable_video(task_costs, usable_count, storage_cost=0.0, review_cost=0.0):
    """task_costs: Rechnungsbetrag je Aufgabe; usable_count: Anzahl brauchbarer Filme"""
    if usable_count == 0:
        raise ValueError("Keine brauchbaren Filme – zuerst Prompt, Material und Parameter prüfen")
    total = sum(task_costs) + storage_cost + review_cost
    return total / usable_count

# Beträge aus der Rechnung exportieren und Platzhalter ersetzen, Einheit beibehalten
weekly_task_costs = [0.0] * 40
print(cost_per_usable_video(weekly_task_costs, usable_count=28))

Erfassen Sie im Antwortobjekt außerdem Modell, Dauer, Auflösung, Status und Laufzeit. Nur mit einheitlicher Definition lassen sich Wochen vergleichen; mischen Sie keine Daten aus verschiedenen Kanälen.

6. Standardablauf für einen kleinen Testlauf

  1. Eine Modellstufe, eine Dauer und eine Auflösung als Basislinie festlegen.
  2. Zwanzig bis dreißig echte Geschäfts-Prompts und Startbilder vorbereiten, nicht nur reibungslos durchlaufende Beispiele.
  3. Pro Aufgabe Status, Fehlercode, Laufzeit und Rechnungsabzug notieren.
  4. Fehlgeschlagene Aufgaben in die Gesamtkosten einrechnen und die Kosten pro brauchbarem Video berechnen.
  5. Sieben Tage beobachten, mit dem Tagesdurchschnitt auf den Monat hochrechnen und Speicher, Traffic sowie Prüfaufwand addieren.
  6. Jeweils nur eine Variable ändern, etwa die Auflösung um eine Stufe erhöhen, um die Kostensensitivität zu ermitteln.
  7. Aus den Ergebnissen eine „Teststufe“ und eine „Finalstufe“ ableiten und in die Teamrichtlinie schreiben.

Der Wert eines kleinen Testlaufs liegt nicht nur in einer Zahl, sondern in der Erkenntnis, auf welche Variable die Kosten am stärksten reagieren.

7. Konkrete Budgetkontrolle

  • Ein Projekt, ein Key; Test und Produktion trennen, damit die Kosten nicht vermischt werden.
  • In der Konsole ein Ausgabenlimit für den Key setzen und Warnungen für Tages- oder Wochenverbrauch konfigurieren.
  • Vor der Übermittlung mit den aktuellen Parametern eine Schätzung durchführen; oberhalb eines Schwellenwerts pro Video manuell bestätigen lassen.
  • Parallelität und maximale Retry-Anzahl begrenzen, besonders bei Batch-Skripten.
  • Entwürfe einheitlich in niedriger Auflösung erzeugen; nur geprüfte Szenen in hoher Auflösung rendern.
  • Ergebnisse zeitnah umspeichern und einen Lebenszyklus einrichten; wöchentlich nach Projekt, Modell und Auflösung abstimmen.

Gateway-seitig gibt es üblicherweise Key-Kontingente, Modell-Whitelists und Verbrauchsexporte; maßgeblich ist die Konsole. Warnungen müssen eine Person erreichen – eine Nachricht in einer Gruppe, die niemand liest, ist so gut wie keine Warnung.

8. Reihenfolge der Kostensenkung und drei häufige Irrtümer

Die Kostensenkung sollte nach Wirkung sortiert ablaufen: zuerst die Erfolgsquote erhöhen, dann unnötige Retries reduzieren, danach Auflösungsstufen und Dauer straffen, anschließend den Speicher bereinigen und erst zuletzt den Kanal wechseln. Bei umgekehrter Reihenfolge lautet das typische Ergebnis: Der Stückpreis sinkt, Fehlerquote und Gesamtkosten steigen.

Drei häufige Irrtümer:

  1. Nur den Listenpreis betrachten, nicht Erfolgsquote und Retries. Ein billiger, aber häufig scheiternder Kanal kann pro brauchbarem Video teurer sein.
  2. Mit der kürzesten Dauer testen, in der Produktion aber die längste Dauer und hohe Auflösung verwenden; dann passt das Budget nicht.
  3. Die Gültigkeit der Ergebnislinks ignorieren und nach Ablauf neu generieren – das bedeutet, zweimal zu zahlen.

Häufige Fragen

Wird die Seedance-API pro Aufruf, pro Sekunde oder pro Token abgerechnet?

Neuere Seedance-Generationen werden laut Anbieterdokumentation üblicherweise nach Tokens gemessen; der Verbrauch hängt von Auflösung, Dauer und Eingabeart ab. Einige Gateways rechnen in Sekunden oder Stück um. Klären Sie vor der Anbindung die Abrechnungseinheit und beachten Sie die Seite Modellpreise.

Verdoppeln sich die Kosten beim Wechsel von 720p auf 1080p?

Die Pixelmenge steigt etwa auf das 2,25-Fache, die tatsächliche Abbuchung hängt aber zusätzlich von Modellstufe, Mindestabrechnungseinheit und Rabatten ab und lässt sich nicht einfach verdoppeln. Ein Vergleichstest mit demselben Prompt ist verlässlicher.

Werden fehlgeschlagene oder abgelehnte Aufgaben berechnet?

Die Regeln unterscheiden sich je nach Plattform und Fehlerursache. Manche Systemfehler werden nicht berechnet, bei anderen wird nach dem Anlegen der Aufgabe abgerechnet. Klären Sie das vor der Anbindung mit einer Testbestellung und rechnen Sie Fehlkosten in die Kosten pro Video ein.

Warum ist der Test günstig, die Rechnung nach dem Start aber hoch?

Häufige Ursachen: Im Test fünf Sekunden bei niedriger Auflösung, in der Produktion zehn Sekunden in hoher Auflösung; mehr fehlgeschlagene Retries; zusätzliche Kosten für Umspeichern und Auslieferung; mehrere Personen nutzen denselben Key, sodass keine Zuordnung möglich ist. Legen Sie Keys pro Projekt an und erfassen Sie Rechnungen auf Aufgabenebene.

Wie setzt man ein Budgetlimit für die Videogenerierung?

Mindestens auf drei Ebenen: Kontingent pro Key, Budget pro Projekt und Schätzung vor der Übermittlung auf Aufgabenebene. Bei Erreichen eines Schwellenwerts nicht kritische Aufgaben pausieren und Verantwortliche benachrichtigen, statt nur auf die Monatsrechnung zu warten.

Nächste Schritte

Erstellen Sie zuerst in der ZSQH AI Gateway einen Test-Key und lassen Sie zwanzig bis dreißig Aufgaben mit der niedrigsten Konfiguration laufen. Notieren Sie Erfolgsquote, Laufzeit und Abbuchung und rechnen Sie anschließend mit den Preisen auf der Seite Modellpreise das Monatsbudget hoch. Wenn Sie zuerst den Ablauf asynchroner Aufgaben verstehen möchten, lesen Sie die Anbindungsanleitung im Blog.

Verwandte Artikel: