KI-Videos in Masse generieren: Hunderte Clips ohne Pannen

Wenn du zum ersten Mal dreihundert Videogenerierungen aus einem Skript startest, geht etwa bei Job vierzig etwas kaputt. Ein Anbieter liefert ein 429, deine Schleife versucht es sofort erneut, die Retries kollidieren miteinander, und wenn der Lauf endet, hast du 280 Dateien, ein paar doppelt bezahlte Duplikate und ein Dutzend Jobs, deren Ausgabe-Links schon abgelaufen sind. An den Modellen liegt es nicht; der Fehler entsteht, weil ein Batch wie eine einfache for-Schleife behandelt wurde.

Hier ist die Infrastruktur, mit der sich ein KI-Video-Batch unbeaufsichtigt laufen lassen lässt: den Batch vorab kalkulieren, innerhalb der Concurrency-Limits in eine Queue stellen, Retries ohne Doppelzahlung, Rückerstattungen abgleichen und Ausgaben so benennen, dass du sie im nächsten Monat noch findest.

Drei Limits bestimmen, wie schnell ein Batch laufen kann

Generierungs-APIs drosseln auf drei getrennten Achsen, die die Dokumentation von Leonardo.Ai sauber definiert:

• Concurrency ist die Anzahl der Generierungsjobs, die parallel verarbeitet werden.
• Das Queue-Limit (pending) legt fest, wie viele Anfragen warten dürfen, wenn alle Concurrency-Slots belegt sind.
• Das API-Rate-Limit legt fest, wie viele API-Anfragen du in einem Zeitfenster stellen darfst, unabhängig davon, was sie tun.

Die Concurrency begrenzt nicht die Gesamtzahl der Anfragen: Zusätzliche Arbeit wartet in der Queue, sofern dort Platz ist. Die Concurrency bestimmt deinen Durchsatz; das Rate-Limit bestimmt, wie häufig du einreichen und abfragen darfst.

Wie die Standardwerte aussehen

Die Standardwerte sind niedrig und meist pro Organisation statt pro Key gesetzt:

• fal: Neue Accounts starten mit 2 gleichzeitigen Anfragen und wachsen mit den bezahlten Rechnungen der letzten vier Wochen bis auf 40 im Self-Service. Anfragen im Status IN_QUEUE zählen nicht zum Limit, nur IN_PROGRESS.
• Vidu: bis zu 5 gleichzeitige Tasks pro Organisation, und das Limit gilt pro Organisation, nicht pro API-Key.
• LTX: laut Rate-Limit-Seite standardmäßig bis zu 2 gleichzeitige Generierungen, wobei Anfragen über dem Limit mit einem 429 und einem Retry-After-Header beantwortet werden.
• Replicate: 600 Anfragen pro Minute zum Erstellen von Predictions und 3.000 pro Minute für andere Endpunkte, wobei kurze Bursts toleriert werden, bevor gedrosselt wird.

Bei einer Concurrency von 2 füllt ein Lauf mit 300 Clips einen ganzen Abend, egal wie schnell dein Code ist. Behandle ihn als Hintergrundjob mit Manifest und Ziellinie.

Den Batch vor dem Start kalkulieren

Bei Pay-per-Call-Preisen ergibt sich der Batch-Preis aus Zahlen, die du bereits kennst. Die Formel für dein Runbook:

Batch-Kosten = Clips x Sekunden pro Clip x Preis pro Sekunde + Bilder x Preis pro Bild + (Zeichen / 450) x Preis pro 450 Zeichen Sprache.

Mit den öffentlichen Preisen von Aitachyon zum Zeitpunkt des Schreibens (die vollständige Liste steht auf der Modellseite mit dem Preis jedes Aufrufs) kosten realistische Batches von Anfang bis Ende so viel, bei Clips von 5 Sekunden:

• 20 Hooks auf Hailuo 02 zu $0.085/s: 20 x 5 x $0.085 = $8.50.
• Dieselben 20 Hooks auf Kling v3: $16.00 ohne Ton bei $0.16/s oder $32.00 mit nativem Audio bei $0.32/s.
• Dieselben 20 Hooks auf Seedance 2.5: $20.00 in 480p ($0.20/s) oder $44.00 in 720p ($0.44/s).
• 50 Produktbilder auf Seedream 4.0 zu $0.057 pro Bild: $2.85. Auf FLUX.2 [pro] zu $0.057 bis $0.086: $2.85 bis $4.30. Auf Nano Banana zu $0.13: $6.50.
• Eine Woche Shorts, sieben Videos aus je drei Hailuo-02-Clips à 5 Sekunden plus etwa 900 Zeichen ElevenLabs-Sprecher ($0.043 bis $0.086 pro 450 Zeichen): pro Short 15 x $0.085 = $1.275 für das Video und $0.086 bis $0.172 für die Stimme, also etwa $9.53 bis $10.13 für die Woche.
• 300 Clips: 1.500 Sekunden Video. Das sind $127.50 auf Hailuo 02 und $480.00 auf Kling v3 mit Audio.

Derselbe Batch schwankt zwischen den Modellen etwa im Verhältnis vier zu eins, deshalb zählt die Modellwahl bei hohem Volumen stärker. Ein gängiges Muster: alle Varianten auf einem günstigeren Modell generieren, Gewinner auswählen und nur diese auf dem Modell mit dem gewünschten Look oder nativem Audio neu rendern. Die Aufschlüsselung der API-Preise Modell für Modell geht die Abwägungen durch.

Zwei Posten, die gern vergessen werden. Retries: Mit schlechter Retry-Logik wird ein Lauf mit 300 Clips deutlich über 300 Clips abgerechnet. Und die Trefferquote: Wenn du jeden fünften Clip behältst, kostet ein brauchbarer Clip das Fünffache des Preises pro Aufruf. Die Frage davor lautet, wie viele Anzeigen du tatsächlich schalten solltest.

Das Job-Manifest: Jeden Job benennen, bevor du ihn einreichst

Die nützlichste Gewohnheit bei der Massengenerierung ist, den gesamten Batch in eine Manifest-Datei zu schreiben, bevor die erste Anfrage rausgeht. Sie hält fest, was existieren soll, was eingereicht wurde, was fertig ist und was es gekostet hat. Stürzt das Skript bei Job 140 ab, machst du dort weiter, statt zu raten.

Eine Manifest-Zeile, die einen Absturz übersteht

1. job_key: eine deterministische ID aus Kampagne, Shot, Modell und Variante, zum Beispiel spring-launch_hook-07_kling3_v2.
2. Modell und Parameter: Modell-Slug, Dauer, Auflösung, Audio an oder aus, Seed, falls das Modell einen akzeptiert.
3. prompt: der exakt gesendete Text, damit du einen Gewinner reproduzieren kannst.
4. estimated_cost: aus der obigen Formel.
5. status: planned, submitted, running, done, failed.
6. provider_id: die Request- oder Job-ID, die die API beim Einreichen zurückgibt.
7. output_ref und local_path: wo die Datei liegt, sobald du sie hast.
8. actual_cost und attempts: werden bei Abschluss eingetragen.

Summiere estimated_cost und starte nicht, wenn das Budget überschritten wird. Diese Prüfung fängt den Tippfehler ab, der aus 30 Clips 300 macht.

Idempotenz: die Regel gegen doppelte Abrechnung

Der gefährliche Moment ist ein Netzwerk-Timeout beim Einreichen: Du weißt nicht, ob der Job angelegt wurde, und ein blinder Retry kann ihn doppelt abrechnen. Stripe dokumentiert die Standardabwehr für bezahlte POSTs: Der Server speichert Statuscode und Body der ersten Anfrage pro Idempotency-Key, auch bei 500-Fehlern, und gibt dasselbe Ergebnis für Wiederholungen zurück. Keys dürfen bis zu 255 Zeichen lang sein, können nach mindestens 24 Stunden entfernt werden, und die Wiederverwendung eines Keys mit anderen Parametern liefert einen Fehler.

Viele Generierungs-APIs dokumentieren Idempotenz nicht; die Reliability-Seite von fal geht nicht ausdrücklich auf Idempotenz-Garantien ein. Bietet der Anbieter keinen Key, ist dein Manifest die Idempotenz-Schicht: Bevor du einen Job erneut einreichst, dessen Submit in ein Timeout lief, suche ihn beim Anbieter und reiche erst dann erneut ein, wenn du bestätigt hast, dass er nicht existiert.

Arbeit in die Queue stellen, Laufendes deckeln

Video-APIs arbeiten asynchron: einreichen, eine ID erhalten, später das Ergebnis abholen. Die Queue von fal liefert eine request_id, die du für spätere Statusabfragen speicherst, und führt jede Anfrage durch IN_QUEUE, IN_PROGRESS und COMPLETED. Der Video-Leitfaden von OpenAI nutzte dasselbe Schema mit den Status queued, in_progress, completed und failed.

Das Muster, das Massenabweisungen vermeidet, ist laut LTX-Dokumentation eine lokale Queue, die aktive Jobs auf die erlaubte Concurrency begrenzt. In der Praxis:

1. Lade alle geplanten Zeilen aus dem Manifest in eine lokale Queue.
2. Starte einen Worker-Pool in der Größe deines Concurrency-Limits. Zählt der Anbieter nur laufende Jobs, wie fal, kannst du vorab in seine Queue einreichen; fal gibt an, dass Anfragen in der Queue wegen Concurrency-Limits nie verworfen werden, es sei denn, ein start_timeout läuft ab.
3. Jeder Worker reicht einen Job ein, trägt die Anbieter-ID sofort im Manifest ein und wartet auf den Abschluss.
4. Nach Abschluss lädt der Worker die Ausgabe herunter, schreibt die Zeile und nimmt den nächsten Job.
5. Stelle die Jobs, die du brauchst, nach vorn und markiere Massenvarianten, wo möglich, mit niedriger Priorität; fal akzeptiert dafür priority auf low.

Webhooks oder Polling

Bevorzuge Webhooks, wenn du sie empfangen kannst. Replicate sendet HTTP-POSTs, wenn Predictions erstellt, aktualisiert und beendet werden, und fal akzeptiert beim Einreichen eine webhook_url und postet dorthin Request-ID, Status und Ausgabe bei Abschluss. Mach den Handler idempotent: Derselbe Abschluss kann mehrfach eintreffen, also suche den Job über die ID und tue nichts, wenn die Zeile schon auf done steht.

Wenn du pollst, dann langsam. OpenAI empfahl alle 10 bis 20 Sekunden, bei Bedarf mit exponentiellem Backoff. 300 Jobs jede Sekunde abzufragen verbrennt dein allgemeines Rate-Limit (bei Replicate sind es 3.000 Anfragen pro Minute für Endpunkte außerhalb der Erstellung) und führt dazu, dass genau die Aufrufe gedrosselt werden, auf die es ankommt.

Retries, die die Rechnung nicht vervielfachen

Ein Retry nach fester Wartezeit synchronisiert deine Worker: Sie wachen gemeinsam auf und kollidieren erneut. AWS hat das in seiner Untersuchung zu Exponential Backoff und Jitter gemessen. Bei 100 konkurrierenden Clients halbierte Full Jitter die Gesamtzahl der Aufrufe um mehr als die Hälfte gegenüber exponentiellem Backoff ohne Jitter, und der Backoff ohne Jitter brauchte so viel länger, dass er aus dem Diagramm der Abschlusszeiten herausgenommen wurde.

Die Full-Jitter-Formel:

sleep = random(0, min(cap, base x 2^attempt))

Mit base = 1 Sekunde und cap = 60 Sekunden wartet Versuch 3 eine zufällige Zeit zwischen 0 und 8 Sekunden. Die eigene Empfehlung von fal für rohe HTTP-Clients hat dieselbe Form, nämlich Backoff mit 1 s, 2 s, 4 s, 8 s, und das SDK versucht es bis zu 10 Mal.

Eine Entscheidungsregel für Retries

Nicht jeder Fehler verdient einen Retry:

1. 429 mit Retry-After-Header: genau so lange warten, plus etwas Jitter. Die Drosselungsmeldung von Replicate nennt, wann das Limit zurückgesetzt wird, etwa nach 30 Sekunden.
2. 429 ohne Header oder concurrent_requests_limit bei fal (fal setzt außerdem X-Fal-needs-retry: 1): Full-Jitter-Backoff, und reduziere die Worker um einen, wenn es weiter auftritt.
3. 503, 504 oder Verbindungsfehler: mit Backoff wiederholen. Das sind die Fehler, die die Queue von fal neben dem 429 automatisch wiederholt.
4. Timeout beim Einreichen: nicht erneut einreichen, bevor du geprüft hast, ob der Job existiert (siehe Idempotenz oben).
5. 4xx-Validierungs- oder Inhaltsfehler: nicht wiederholen. Zeile mit der Meldung als failed markieren, Prompt oder Parameter korrigieren und als neue Variante erneut einreihen.
6. Job mit Status failed abgeschlossen: einmal mit denselben Parametern wiederholen. Schlägt er erneut fehl, als Prompt-Problem behandeln und weitermachen.

Begrenze die Versuche pro Job (drei sind ein vernünftiger Standard) und die Retries insgesamt pro Lauf. Wenn ein Zehntel der Jobs wiederholt wird, stimmt etwas beim Anbieter nicht: Pausiere den Lauf.

Fehlschläge, Rückerstattungen und Abgleich

Bei hohem Volumen schlagen manche Renderings fehl, und die Frage ist, wer zahlt. fal gibt an, dass fehlgeschlagene Anfragen mit 5xx keine Kosten verursachen. Bei Aitachyon wird ein fehlgeschlagenes Rendering automatisch auf den Cent genau erstattet, und jeder Job ist mit dem verwendeten Modell und seinen Kosten einzeln aufgeführt. Unabhängig von der Richtlinie deines Anbieters: Gleiche nach jedem Lauf ab, statt ihr zu vertrauen.

Checkliste für den Abgleich nach dem Lauf

• Zähle die Zeilen nach Status. Planned minus done minus failed muss null ergeben; was übrig bleibt, hängt fest und braucht eine Statusabfrage.
• Summiere actual_cost und vergleiche mit estimated_cost. Eine Abweichung von mehr als ein paar Prozent deutet meist auf doppelte Einreichungen oder ein Modell oder eine Dauer hin, die vom Plan abwichen.
• Ordne jeden abgerechneten Job einer Manifest-Zeile zu. Eine Abrechnung ohne Zeile ist ein Duplikat aus einem Retry.
• Prüfe, dass jeder fehlgeschlagene Job seine Erstattung oder eine Abrechnung von null zeigt und dass jede done-Zeile eine lokale Datei mit der erwarteten Länge hat.
• Halte die Auswahl fest: welche Ausgaben du behalten hast. Dieses Verhältnis fließt ins Budget des nächsten Batches.

Mit einem Skript dauert das Minuten, und es lässt sich direkt auf die Produktion von 50 UGC-Varianten pro Woche übertragen, wo es die Wochenausgaben konstant hält.

Die Dateien sichern, bevor sie verschwinden

Vom Anbieter gehostete Ausgaben sind vorübergehend. Replicate löscht Ausgabedateien von per API erstellten Predictions nach einer Stunde und fordert dich auf, eine Kopie zu speichern; Predictions aus der Weboberfläche behalten ihre Dateien, sodass ein von Hand funktionierender Ablauf im Skript Dateien verlieren kann. Die Download-URLs für Videos von OpenAI waren höchstens 1 Stunde nach der Generierung gültig.

Wer über Nacht laufen lässt und morgens herunterlädt, bekommt tote Links. Lade im Completion-Handler herunter, in dem Schritt, der die Zeile auf done setzt.

Eine durchsuchbare Namenskonvention

Benenne jede Datei beim Download nach ihrem Job-Key um, zum Beispiel spring-launch_hook-07_kling3_v2.mp4, und halte die Referenz des Anbieters im Manifest fest. Aitachyon gibt jeder generierten Datei eine stabile Ref (img_, scn_, vo_ und so weiter), die Code jederzeit mit GET /api/generations/{ref} abrufen kann; die Ref ist also das dauerhafte Handle und die lokale Datei deine Arbeitskopie. Mit beidem im Manifest ist eine Frage wie "welcher Prompt hat den Hook erzeugt, der im März gewonnen hat" ein grep.

Anbieterabhängigkeit ist ebenfalls ein Batch-Risiko

Der Leitfaden von OpenAI vermerkt inzwischen, dass die Sora-2-Modelle und die Videos API am 24. September 2026 eingestellt wurden. Pipelines, die an diesen Endpunkt gebunden waren, mussten neu geschrieben werden. Wird das Modell als Manifest-Parameter geführt, kostet eine Abkündigung nur eine Konfigurationsänderung.

Kostenkontrolle pro Key und Batches aus einem Agenten starten

Ein fehlerhaftes Skript mit unbegrenztem Guthaben ist die teure Kombination. Replicate wendet zunehmend strengere Limits an, je weiter das Guthaben sinkt, und empfiehlt, das Guthaben mit Auto-Reload über $20 zu halten, während Accounts ohne Zahlungsmittel auf 1 Anfrage pro Sekunde begrenzt sind. Deine eigenen Leitplanken sollten darüber liegen:

Ausgaben-Leitplanken für unbeaufsichtigte Läufe

1. Ein API-Key pro Pipeline. Der nächtliche Shorts-Job, das Skript für Anzeigenvarianten und deine Agent-Sitzung bekommen jeweils einen eigenen Key, sodass sich die Ausgaben zuordnen lassen. Bei Aitachyon hat jeder Key eigene Ausgaben, einen Alarm bei ungewöhnlich schnellem Verbrauch und eine Sperrung mit einem Klick.
2. Eine Prepaid-Obergrenze. Ein Prepaid-Guthaben ist konstruktionsbedingt eine harte Grenze. Das Guthaben bei Aitachyon verfällt nie, sodass ein Aufladen für einen großen Lauf keinen Verbrauchsdruck erzeugt. Der Vergleich von Credits und Pay-per-Call zeigt, wo jedes Modell Geld verliert.
3. Eine Budgetprüfung im Code. Die Manifest-Summe, vor dem Lauf geprüft und danach alle 50 Jobs gegen die tatsächlichen Ausgaben.
4. Ein Notausschalter. Wenn der Alarm pro Key auslöst, sperre den Key. Die Worker brechen bei Authentifizierungsfehlern schnell ab, und genau das willst du.

Derselbe Batch, gesteuert von einem Agenten

Immer öfter schreibt und startet ein Coding-Agent das Skript. Mit einem gehosteten MCP-Server, der mit Claude Code oder Cursor verbunden ist, beschreibst du den Batch ("zwanzig 5-Sekunden-Hooks aus diesen Prompts auf Hailuo 02, gespeichert in ./hooks und benannt nach Hook-Nummer"), und der Agent reicht ein, wartet, lädt herunter und meldet jede Datei mit ihren Kosten. Claude Code mit Aitachyon zu verbinden, ist ein einziger Befehl:

claude mcp add --transport http aitachyon https://aitachyon.com/api/mcp --header "Authorization: Bearer ait_..."

Agent-Läufe brauchen dieselben Leitplanken: einen eigenen Key, ein im Prompt genanntes Budget und das Manifest, das laufend auf die Platte geschrieben wird. Die Anleitung zum Erzeugen von Videos aus Claude Code über MCP zeigt die Einrichtung, und ein funktionierendes Agent-Setup für die Videoproduktion behandelt, wie man Skripte, Clips und Stimme zu fertigen Beiträgen verkettet.

Checkliste vor einem Massenlauf

Kopiere das an den Anfang deines Batch-Skripts oder deines Agent-Prompts:

1. Manifest geschrieben, eine Zeile pro Ausgabe, deterministische Job-Keys.
2. Geschätzte Summe unter dem Budget.
3. Ein eigener API-Key mit Ausgabenalarm.
4. Worker auf das Concurrency-Limit gedeckelt.
5. Full-Jitter-Backoff, Retry-After beachtet, maximal drei Versuche.
6. Timeouts beim Einreichen geprüft, bevor erneut eingereicht wird.
7. Webhook-Handler oder langsames Polling, in beiden Fällen idempotent.
8. Download und Umbenennen bei Abschluss.
9. Ein Testbatch mit fünf Clips, Ende zu Ende durchgelaufen.
10. Abgleich-Skript bereit.

Der Testbatch ist der Schritt, den alle überspringen, und der günstigste: Auf Hailuo 02 kosten fünf Clips à 5 Sekunden zum Zeitpunkt des Schreibens $2.13, und sie fangen das falsche Seitenverhältnis ab, bevor es dich dreihundertfach kostet.

FAQ

Bezahle ich fehlgeschlagene KI-Videogenerierungen?

Das hängt vom Anbieter ab. fal berechnet keine Anfragen, die mit einem 5xx-Fehler scheitern, und Aitachyon erstattet fehlgeschlagene Renderings automatisch auf den Cent genau. In beiden Fällen solltest du deine einzeln aufgeführten Kosten nach jedem Lauf mit deiner Jobliste abgleichen, denn eine doppelte Einreichung durch einen schlechten Retry ist ein erfolgreicher Job, den du bezahlt hast.

Wie lange bleiben generierte Videodateien verfügbar?

Oft nicht lange. Replicate löscht API-Ausgabedateien nach einer Stunde, und die Download-URLs für Videos von OpenAI galten höchstens eine Stunde. Lade jede Datei herunter, sobald ihr Job abgeschlossen ist, und speichere sie unter deinem eigenen Namen. Bei Aitachyon hat jede Ausgabe zusätzlich eine stabile Ref, die du später mit GET /api/generations/{ref} abrufen kannst.

Was kostet es, 100 kurze KI-Videos zu generieren?

Für 100 Clips à fünf Sekunden zu den Preisen von Aitachyon zum Zeitpunkt des Schreibens sind das $42.50 auf Hailuo 02, $80 auf Kling v3 ohne Ton und $100 auf Seedance 2.5 in 480p. Teile durch deine Trefferquote, um die Kosten pro brauchbarem Clip zu erhalten.

Quellen

1. Replicate: Rate Limits
2. Replicate: Ausgabedateien
3. Replicate: Webhooks
4. fal: Concurrency-Limits
5. fal: Asynchrone Inferenz und Queue
6. fal: Zuverlässigkeit
7. Leonardo.Ai: Leitfaden zu Concurrency, Queue und Rate Limit
8. Vidu: Nutzung und Limits
9. Stripe: Idempotente Anfragen
10. AWS Architecture Blog: Exponential Backoff und Jitter

Wenn du solche Batches laufen lassen willst, ohne für jedes Modell einen eigenen Account anzulegen: Aitachyon bündelt Seedance, Kling, Veo, Hailuo, die Bildmodelle und ElevenLabs-Stimmen hinter einem Key, nutzbar über eine HTTP-API oder den gehosteten MCP-Server, mit jedem Job einzeln aufgeführt, erstatteten fehlgeschlagenen Renderings und Ausgaben pro Key. Der Schnellstart für API und MCP beschreibt die Einrichtung.