Viele Teams wählen bei der Kling-Einbindung zuerst einen Relay- oder Proxy-Zugang: Base URL und Key ändern, und es wirkt einfacher als eine Direktverbindung. Videogenerierung ist jedoch eine asynchrone Aufgabe, und ein Relay hat gegenüber Textschnittstellen zusätzliche Glieder: Aufgabenpersistenz, Statusabbildung, Callback-Weiterleitung und Ergebnisspeicherung. Ist eines davon schwach ausgeprägt, zeigt sich das als „Senden erfolgreich, aber kein Video“.

Dieser Beitrag geht von der tatsächlichen Relay-Kette aus und erklärt Aufgaben-Zuverlässigkeit, Ergebnisaufbewahrung, Abrechnungstransparenz, Key-Risiken sowie die Abnahme bei einer Migration von der Direktverbindung.

Hinweis: Kling ist eine Marke oder eingetragene Marke von Kuaishou und verbundenen Unternehmen. Dieser Beitrag dient der technischen Erläuterung und begründet keine Zugehörigkeit oder Kooperation mit Kuaishou. Schnittstellen, Modelle und Abrechnungsregeln richten sich nach der offiziellen Dokumentation und den Modellpreisen dieser Website; Preise können sich ändern.

1. Vier Arten von „Relay“ – zuerst klären, was gekauft wird

Typ Tatsächliches Angebot Hauptrisiko Geeignete Situation
Reverse Proxy Leitet Anfragen an die Upstream-Schnittstelle weiter Einzelpunkt, Ausgangsbandbreite, Auth-Konfiguration Eigene Betriebskompetenz, nur einheitlicher Ausgang gewünscht
Aggregations-Gateway Einheitlicher Einstieg, bündelt mehrere Videoanbieter Statusabbildung, Parameterunterschiede, Ergebnisspeicherung Mehrere Modelle, kleine Teams
Wiederverkauf/Aufladung Verkauft Kontingente oder zahlt stellvertretend Upstream-Stabilität, Servicethemen, Guthabensicherheit Kurztest, kleiner Bedarf
Selbst betriebenes Gateway Eigene Deployments und Wartung der Weiterleitung Server, Zertifikate, Missbrauchsschutz vollständig selbst Datensouveränität, eigenes Technikteam

Ob „technischer Service“ oder „Modellkontingent“ gekauft wird, entscheidet, wer bei Störungen haftet, wer die Rechnung stellt und mit wem Datenklauseln geschlossen werden. Vertrag und Rechnung an dieser Unterscheidung prüfen, nicht nur daran, ob „Kling“ auf der Seite steht.

2. Wie Aufgabenstatus durch die Relay-Kette laufen

Ihr Geschäftssystem
  → Relay-Einstieg (Authentifizierung, Limits, Abrechnung)
  → Upstream erstellt Aufgabe, liefert Aufgaben-ID
  → Relay speichert Zuordnung von Aufgaben-ID und Geschäftsnummer
  → Relay fragt Upstream ab oder empfängt Callback
  → Abbildung auf einheitlichen Status, Abfrage-API oder Webhook
  → Sie laden das Ergebnis und speichern es um

Die offizielle neue Schnittstelle nutzt üblicherweise submitted, processing, succeeded, failed; die alte Schnittstelle schreibt den Erfolg eventuell als succeed. Bildet ein Relay nur Erfolg und Fehler ab, wartet die Anwendung unter Umständen dauerhaft auf processing; laufen Upstream-Aufgaben ab, braucht es zusätzlich einen Ausgang wie expired.

Mit jedem zusätzlichen Sprung entsteht eine Stelle, an der Status verloren gehen kann: Nach einem Relay-Neustart verschwindet die In-Memory-Zuordnung; der Upstream hat eine Aufgabe erstellt, das Relay meldet aber Fehler, und ein erneuter Aufruf erzeugt zwei Aufgaben; Callbacks ohne Idempotenzschlüssel führen zu doppelten Einträgen. Bei der Bewertung fragen: Wo liegt die Aufgaben-ID, wie lange, ist eine Rückwärtssuche über die Geschäftsnummer möglich, und wie werden Fehler kompensiert?

3. Ergebnisaufbewahrung und Übertragung

Laut offizieller Dokumentation werden URLs generierter Ergebnisse nach 30 Tagen bereinigt und tragen zudem Hotlink-Schutz. Drei übliche Relay-Verfahren haben völlig unterschiedliche Verantwortlichkeiten:

  • Upstream-Adresse durchreichen: Der Aufrufer trägt die Verantwortung für die Übertragung innerhalb von 30 Tagen.
  • Cache- oder Proxy-Adresse: Ob nach Ablauf erneut beim Upstream angefragt wird, wie lange der Cache gilt und ob Zusatzkosten entstehen, muss klar dokumentiert sein.
  • Verwaltete Übertragung: Das Relay lädt herunter und speichert langfristig; Speicherort, Zugriffsrechte, Löschmechanismus und Aufbewahrungsfrist sind zu bestätigen.

„Permanente Links“ klingen bequem, doch wenn das Relay nur die eigene Domain auf eine ablaufende Upstream-Adresse zeigt, ist nach Ablauf ebenfalls nichts erreichbar. Bei der Abnahme den Link 24 Stunden nach Erfolg und nochmals kurz vor Ablauf der 30 Tage aufrufen.

4. Wie Abrechnungstransparenz geprüft wird

Kling-Video wird üblicherweise nach Sekunden, Auflösung, Audio- oder Bewegungskontrolle kombiniert abgerechnet; auch Ressourcenpakete und Parallelitäts-Slots sind möglich. Ein Relay kann Aufschläge, Mindestumsätze oder geänderte Paketlaufzeiten hinzufügen; nur auf beworbene Rabatte zu achten reicht nicht.

Für den Abgleich mindestens verlangen: Aufgaben-ID, Geschäftsnummer, Modell, Dauer, Auflösung, Status, abgebuchter Betrag und Währung. Das offizielle billing-Feld im Callback unterscheidet Bar- und Paketabbuchung und nennt Betrag, Währung und Tariftyp; ob ein Relay diese Felder unverändert weitergibt, ist ein direktes Indiz für Transparenz.

Ebenso klären, ob Fehler, Timeouts, Abbruch und Prüfungsablehnung jeweils berechnet werden, ob doppelte Sendungen dedupliziert werden und wie Rückerstattung und Rechnung behandelt werden. Konkrete Preise stehen in den Modellpreisen; vor Vertragsabschluss eine Woche lang 20 bis 50 kleine Aufgaben laufen lassen und Erfolge, Fehler und Rechnung Zeile für Zeile abgleichen.

5. Key, Daten und Upstream-Risiken

Da Anfragen über Dritte laufen, können Prompts, Startbilder und generierte Videos eingesehen oder gespeichert werden. Vor dem Einkauf klären:

  1. Lässt sich der Key nach Kontingent, IP und Laufzeit begrenzen; kann er nach Offenlegung schnell gesperrt werden?
  2. Werden Anfragen und Ergebnisse gespeichert, wie lange, wo und mit welchen Zugriffsrechten?
  3. Werden Daten für Training oder Serviceverbesserung genutzt; lassen sich Datenverarbeitungsbedingungen unterzeichnen?
  4. Ist der Upstream ein einzelner oder mehrere Kanäle; wie wird über Modellabschaltung oder Versionswechsel informiert?
  5. Erlauben die Servicethemen Wiederverkauf oder Vertretung, und wo verlaufen Haftungsgrenzen?
  6. Wer signiert Callbacks, wie lang ist das Zeitfenster, und wie werden Replay-Anfragen abgelehnt?

Produktions-Keys gehören nicht in Frontend, Repository oder Ticket-Screenshots. Für besonders sensible Materialien Anbieter wählen, die keine Speicherung anbieten oder einen Vertrag ermöglichen; bei Unsicherheit vor dem Upload anonymisieren. Der Kling-Key wird in der Konsole meist nur einmal vollständig angezeigt; bei Verlust neu erstellen statt zu raten.

6. Von der Direktverbindung zum Relay migrieren

  1. Bestehende Aufrufe erfassen: Modelle, Parameter, Parallelität, durchschnittliche Dauer und Fehlertypen.
  2. Eine Schnittstellenzuordnung erstellen: Domain, Authentifizierung, Felder, Statuswerte und Fehlercodes.
  3. In der Testumgebung alle vier Pfade testen: Erstellen, Abfragen, Callback und Download.
  4. Mit derselben Aufgabencharge einen Schattenbetrieb durchführen: Direkt und Relay parallel, nur vergleichen, nicht umschalten.
  5. Erfolgsrate, P95-Laufzeit, Downloadquote und Kosten pro erfolgreichem Video vergleichen.
  6. Mit 5 bis 20 Prozent Traffic schrittweise umstellen und einen Rollback-Schalter zur Direktverbindung behalten.
  7. Drei bis sieben Tage beobachten und bestätigen, dass Rechnung, Aufgabendetails und Geschäftsnummern zusammenpassen.
  8. Nach der Vollumstellung eine Zeit lang beide Kanäle als Fallback behalten und die Architektur danach vereinfachen.

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

7. Wie ein Relay geprüft wird

# 1. Minimale Aufgabe senden, Aufgaben-ID, Geschäftsnummer und Sendezeit notieren
curl -X POST "$RELAY_BASE_URL/text-to-video/kling-2.6" \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Eine Katze gähnt am Fenster",
    "settings": {"duration": 5, "resolution": "720p", "aspect_ratio": "16:9"},
    "options": {"external_task_id": "relay-test-20261019-01"}
  }'

# 2. Alle 10 Sekunden abfragen, vollständigen Statusverlauf und Fehlermeldungen notieren
curl "$RELAY_BASE_URL/tasks?task_ids=$TASK_ID" \
  -H "Authorization: Bearer $RELAY_API_KEY"

Beim Test gezielt Ausnahmen erzeugen: direkt nach dem Senden abbrechen, falsche Modell-ID übergeben, Parallelitätslimit überschreiten, Download mittendrin abbrechen, Callback doppelt senden. Beobachten, ob Status, Fehlercodes und Abbuchung des Relays konsistent sind. Nach 24 Stunden die Ergebnisadresse aufrufen, nach 7 Tagen den Aufgabendatensatz prüfen und nahe der 30-Tage-Grenze erneut kontrollieren, ob Link und Datensatz noch existieren.

8. Monitoring und Rollback nach der Migration

  • Aufgaben nach Status zählen, besonders Anteil von failed, cancelled und abgelaufenen Aufgaben.
  • Gesamtzeit von Senden bis Erfolg erfassen und Wartezeit von Generierungszeit trennen.
  • Erfolgsquote der Ergebnisdownloads überwachen; fehlgeschlagene Aufgaben in eine Kompensationsqueue geben statt endlos zu wiederholen.
  • 401, 404, 429 und 5xx zählen und Key-, Modell-, Parallelitäts- und Upstream-Störungen unterscheiden.
  • Kosten pro erfolgreichem Video berechnen, nicht nur den Preis pro Anfrage.
  • Rollback-Schwellen setzen, etwa bei deutlich unter Baseline liegender Erfolgsrate über zwei Stunden zur Direktverbindung zurückkehren.

Häufige Fragen

Sind Videos über ein Relay identisch mit denen der Direktverbindung?

Das hängt davon ab, ob dasselbe Upstream-Modell mit denselben Parametern weitergeleitet wird. Modellversion, Dauer, Auflösung und Audiofähigkeit können abweichen; vor der Einbindung mit identischem Prompt und identischen Parametern mehrere Ergebnisse vergleichen.

Speichert ein Relay meine Videos?

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

Was tun, wenn eine Aufgabe auf der Relay-Seite verloren geht?

Zuerst die lokale Historie über die Geschäftsnummer prüfen, dann Relay-Logs und Upstream-Aufgaben. Ist keine Wiederherstellung möglich, bleibt nur eine erneute Sendung. Deshalb vor der Migration klären, ob das Relay Aufgaben-Zuordnungen persistiert und eine Suche nach Geschäftsnummer bietet.

Warum passen Rechnung und Aufgabenzahl nicht zusammen?

Häufige Ursachen sind doppelte Sendungen, Wiederholungen nach Fehlern, unterschiedliche Abbruchregeln, Mindestumsatz oder abgelaufene Pakete. Eine Aufschlüsselung der Abbuchungen nach Aufgaben-ID verlangen und Zeile für Zeile prüfen, nicht nur die Summe.

Wie viel Code muss bei einer Migration geändert werden?

Ist das Relay zur offiziellen Aufgabenschnittstelle kompatibel, meist nur Domain, Key und wenige Felder; unterscheiden sich Statusabbildung oder Callback-Format, müssen Polling und Persistenz angepasst werden. Ein Schattenbetrieb deckt die meisten Unterschiede vorab auf.

Nächster Schritt

Zuerst im ZSQH AI Gateway einen Test-Key erstellen und mit einer minimalen Aufgabe die vier Ketten Erstellen, Abfragen, Callback und Abrechnung prüfen, dann schrittweise migrieren. Modelle und Preise richten sich nach den Modellpreisen; ob Kling-Video unterstützt wird, steht in der Plattformdokumentation.

Weiterlesen: