Replicate AI: Modelle per API nutzen und Kosten planen

Am 5. November 2026 anhand der aktuellen Preise und Dokumentation von Replicate geprüft. Die Bewertung stützt sich auf dokumentiertes Verhalten und durchgerechnete Kostenbeispiele.

Was ist Replicate AI?

Replicate führt Modelle auf selbst verwalteter Infrastruktur aus. Ein Modell ist hier ein als Paket bereitgestelltes Programm, das Eingaben verarbeitet und Ausgaben liefert. Die Anwendung schickt einen Prompt, eine Datei oder andere modellspezifische Eingaben. Replicate erstellt daraus eine Prediction, so heißt dort ein einzelner Durchlauf, und gibt das Ergebnis oder eine Auftragskennung für spätere Statusabfragen zurück. Der Katalog umfasst Open-Source-Modelle ebenso wie proprietäre Modelle. Dass ein Modell bei Replicate verfügbar ist, macht es also noch nicht zu Open Source. Replicate gehört inzwischen zu Cloudflare: In der Ankündigung vom November 2025 erklärte Replicate, Marke und API würden weiterbestehen. Cloudflares Mitteilung zum Abschluss der Übernahme bestätigte, dass Replicate seit dem 1. Dezember 2025 offiziell zu Cloudflare gehört. Das bedeutet nicht, dass jedes Replicate-Modell am Netzwerkrand gehostet wird. Maßgeblich sind die dokumentierten Fähigkeiten des jeweiligen Endpunkts.

Für wen eignet sich Replicate – und für wen nicht?

Replicate passt zu Entwicklern, die Modellinferenz, also die Ausführung eines trainierten Modells, in ein Produkt integrieren möchten. Die Anwendung sollte bereits Benutzer, Aufträge und Dateien verwalten können. Das kann eine Bildgenerierungsfunktion in einer SaaS-Anwendung sein, ein asynchroner Videoeditor oder ein eigener Bildklassifikator. Der Betrieb von GPU-Servern entfällt. Für den Produktablauf und die Entscheidung, welche Ergebnisse akzeptabel sind, bleibt jedoch das eigene Team zuständig.

Welche Anbieter in die engere Wahl gehören, hängt von der Arbeitslast ab. Die folgenden Einschätzungen beziehen sich auf Einsatzbereiche, nicht auf gemessene Geschwindigkeitsranglisten.

Modal passt besser, wenn eine eigene GPU-Anwendung samt Umgebung in Python beschrieben werden soll. Das codebasierte Ausführungsmodell bietet mehr Kontrolle auf Anwendungsebene, verlangt aber auch mehr eigenen Bereitstellungscode. Welche Kosten daraus entstehen, erläutert der Beitrag zu den Modal-Preisen.

fal AI oder Replicate: Was passt besser?

Bei einem Produkt rund um generative Medien lohnt sich zuerst der Vergleich mit fal. Replicate ist der naheliegende Vergleichskandidat, wenn dieselbe Anwendung auch Community-Modelle oder ein eigenes, paketiertes Modell benötigt. Bieten beide das gewünschte Modell an, sollten Eingabemöglichkeiten, Abrechnungseinheit, Betriebssteuerung und Datenregeln der jeweiligen Endpunkte verglichen werden. Eine pauschale Aussage, eine Plattform sei immer schneller oder günstiger, taugt nicht als Kaufregel.

Ist längst klar, dass dauerhaft Hardwarekapazität eingekauft werden muss, hilft ein Vergleich nach Modellkatalog kaum weiter. Für diese Entscheidung bietet der Vergleich von GPU-Cloud-Anbietern den breiteren Überblick. Wer ohne technischen Hintergrund einen fertigen Supportagenten oder eine Videoschnittanwendung sucht, sollte ebenfalls die fertige Anwendung kaufen. Ein Modellendpunkt lässt noch erhebliche Produktarbeit offen.

Ein Modell ausführen: Von der Auswahl zum API-Aufruf

Der erste Integrationsschritt ist bei Replicate überschaubar. Was die Anwendung senden und empfangen muss, legt aber weiterhin das API-Schema des Modells fest: die Liste zulässiger Eingaben und zurückgegebener Felder.

Welche Modelle bietet Replicate AI?

Replicate unterscheidet zwischen offiziellen Modellen und Community-Modellen. Die Dokumentation zu offiziellen Modellen verspricht stets betriebsbereite Instanzen, stabile Ein- und Ausgabe-APIs, aktive Wartung und eine vorhersehbare Abrechnung nach Eingabe oder Ausgabe. Ein offizielles Modell lässt sich über Eigentümer und Modellnamen aufrufen, ohne eine Versionskennung anzugeben.

Für Community-Modelle beschreibt die Dokumentation andere Bedingungen: API-Aufrufe nennen eine bestimmte Version, abgerechnet wird in der Regel nach Hardwarelaufzeit, und selten genutzte Modelle können Kaltstarts verursachen. Die Bindung an eine Version legt eine bestimmte paketierte Revision fest. Sie vereinheitlicht weder Lizenzen noch Eingabefelder verschiedener Modelle.

Für eine Produktfunktion sollte das Modell feststehen, bevor die Integration beginnt. Zu prüfen sind Lizenz, akzeptierte Dateitypen, Pflichtparameter, Ausgabeformat und Preiseinheit. Einen Request für ein Bildmodell zu kopieren und nur dessen Namen durch den eines Sprachmodells zu ersetzen, reicht wegen der unterschiedlichen Eingaben nicht aus.

Bilder mit Replicate AI generieren

Replicate stellt die Bildgenerierung über einzelne Modellendpunkte bereit. Black Forest Labs FLUX Schnell nimmt beispielsweise einen Textprompt entgegen und liefert generierte Bilder zurück. Wer eine Funktion für Konzeptbilder entwickelt, kann die Modelleingaben zunächst in der Browseroberfläche auswählen und anschließend dasselbe Schema im Backend verwenden.

Dazu wird im Konto ein API-Token erstellt und im Backend in der Umgebungsvariablen REPLICATE_API_TOKEN hinterlegt. Die Token-Dokumentation behandelt Tokens wie Passwörter. Sie gehören nicht in Code, der an den Browser ausgeliefert wird; verschiedene Umgebungen sollten eigene Tokens erhalten.

Ist die Variable gesetzt, lässt sich der folgende HTTP-Request ausführen. Er nutzt das eigene Replicate-Konto und kann die Kosten des Modells auslösen.

curl --fail-with-body --silent --show-error \
  https://api.replicate.com/v1/models/black-forest-labs/flux-schnell/predictions \
  --request POST \
  --header "Authorization: Bearer $REPLICATE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Prefer: wait" \
  --data '{"input":{"prompt":"A matte ceramic teapot on a wooden kitchen table","num_outputs":1}}' \
  > prediction.json

Die Antwort ist ein Prediction-Objekt. Die Felder status, output und error müssen geprüft werden: Ein erfolgreicher HTTP-Request bedeutet noch nicht, dass die Generierung abgeschlossen ist. Laut Dokumentation zur Erstellung von Predictions wartet ein Request mit Prefer: wait standardmäßig 60 Sekunden. Das ist eine Einstellung für die Wartezeit des Requests, keine Latenzzusage. Ist der Durchlauf noch nicht fertig, enthält die Antwort eine Prediction mit dem Status starting oder processing sowie eine Adresse unter urls.get für weitere Abfragen.

Ohne Prefer: wait greift das standardmäßige asynchrone Verhalten. Die API liefert dann eine Auftragskennung zurück, ohne auf den Abschluss zu warten. Offizielle Modelle, Community-Modelle und Deployments verwenden unterschiedliche Erstellungsrouten, die in der HTTP-API-Referenz dokumentiert sind. Maßgeblich ist das generierte Beispiel für das gewählte Modell oder Deployment.

Hintergrundverarbeitung für Video, Sprache und Text aufbauen

Bei längeren Aufträgen funktioniert Replicate am besten, wenn die Anwendung einen Auftragsdatensatz führt und die Ergebnisse nach der Einreichung abholt. Ein Webhook, also eine HTTP-Benachrichtigung an den eigenen Server, ermöglicht die Reaktion auf den Abschluss. So muss kein Request offen bleiben, während der Benutzer wartet.

Ein Beispiel ist ein Produkt, das ein vom Kunden freigegebenes Skript in einen illustrierten Clip umwandelt. Dafür werden die Medien generiert, die Prediction-ID dem Kundenauftrag zugeordnet und die fertigen Dateien vor dem Zusammenbau des Endprodukts eingesammelt. Die Webhook-Dokumentation unterstützt ausdrücklich das Speichern von Prediction-Daten und die Weitergabe der Ausgabe eines Modells an ein anderes. Die Ablaufsteuerung und der abschließende Auftragsstatus für den Kunden bleiben Aufgabe der Anwendung.

Für Videos bietet die Text-to-Video-Sammlung den Einstieg. Danach ist die API des gewählten Modells zu prüfen. Ein Text-to-Video-Modell benötigt anderes Ausgangsmaterial als ein Image-to-Video-Modell. Das gewählte Modell und seine Eingaben sollten zusammen mit dem Auftrag gespeichert werden, damit sich ein fehlgeschlagenes oder unbefriedigendes Ergebnis später nachvollziehen lässt.

Sprachausgabe mit Replicate

Die Text-to-Speech-Sammlung enthält Modelle, die geschriebenen Text in Audio umwandeln. Für eine vertonte Produktführung wird ein Modell gewählt, dessen Sprach- und Stimmeinstellungen zum Skript passen. Anschließend wird die Erzählstimme generiert und die Audiodatei beim übrigen Auftrag gespeichert. Dass Sprachmodelle vorhanden sind, belegt noch keine Eignung für interaktive Telefongespräche. Dafür muss das Antwortverhalten des konkreten Endpunkts in der Anwendung bewertet werden.

Replicate hostet außerdem große Sprachmodelle, die Text erzeugen und interpretieren, darunter die Einträge in der Sprachmodell-Sammlung. Ein solches Modell kann einen Sprechertext entwerfen oder eine eingehende Anfrage klassifizieren. Vor der Übergabe an den nächsten Verarbeitungsschritt muss die Ausgabe geprüft werden. Skriptfreigabe und Endmontage gehören in den Anwendungsablauf, damit aus einem schlechten Zwischenergebnis kein fertiges Kundenprodukt wird.

Eigene Modelle mit Cog bereitstellen

Fehlt die benötigte Logik im öffentlichen Katalog, kann Replicate ein eigenes trainiertes Modell bereitstellen. Das Open-Source-Werkzeug Cog verpackt Code, Abhängigkeiten und Modellgewichte in einen Container, also eine reproduzierbare Softwareumgebung.

Ein Händler kann beispielsweise einen vorhandenen Klassifikator für Produktbilder paketieren und als private API anbieten. Dieser Ablauf stellt ein bereits vorhandenes Modell bereit. Allein durch das Hochladen eines Ordners entsteht noch kein brauchbar trainierter Klassifikator.

Die Anleitung zur Bereitstellung eigener Modelle und die Cog-Push-Anleitung beschreiben den folgenden Weg.

Die praktische Hürde bleibt die Verantwortung für das Paket. Der GPU-Cluster muss nicht mehr selbst betrieben werden, doch funktionierender Inferenzcode, kompatible Abhängigkeiten, passende Hardware und ein nützliches Modell sind weiterhin nötig. Braucht das Modell mehr Speicher als die gewählte Maschine bietet, beseitigt eine API-Hülle diese Anforderung nicht.

Kapazität über ein Deployment steuern

Replicate-Deployments bieten einen dedizierten Endpunkt sowie Kontrolle über Hardware und Skalierung. Das wird relevant, sobald das Produkt von einem Modell abhängt und eine gemeinsam genutzte Warteschlange betrieblich nicht mehr ausreicht.

Die Deployment-Dokumentation beschreibt minimale und maximale Instanzzahlen, die Skalierung auf null, Monitoring und schrittweise Versionsupdates. Eine Instanz ist eine laufende Kopie des Modells. Ein Minimum von 1 hält eine Kopie verfügbar; ein Minimum von 0 erlaubt das Abschalten ungenutzter Kapazität. Eine betriebsbereite Kopie bedeutet nicht, dass beliebig große Lastspitzen ohne zusätzliche Kapazität auskommen.

Bei einem Bildklassifikator mit Kundenzugriff richtet sich das Minimum nach den Anforderungen an die Reaktionszeit, das Maximum nach der finanzierbaren Kapazität. Neben Fehlern und Anfragelatenz sollten aktive, untätige und startende Instanzen beobachtet werden. Steht ein Deployment große Teile des Tages ungenutzt bereit, gehört die Kapazitätsentscheidung in die Kostenprüfung. Erreicht es regelmäßig sein Maximum, schaffen zusätzliche API-Wiederholungsversuche keine weitere konfigurierte Kapazität.

Was kostet Replicate?

Replicate rechnet nach Nutzung ab. Die Einheit wird für jedes Modell einzeln festgelegt. Laut aktueller Preisseite werden manche Modelle nach Hardware und Zeit, andere nach Ein- und Ausgabe berechnet. Einen einheitlichen Preis pro Anfrage für die gesamte Plattform gibt es nicht.

Die folgenden veröffentlichten Beispiele sind keine Aussage darüber, welche Modelle für eine bestimmte Arbeitslast die neuesten oder besten sind:

Für kleine Entwicklungsteams ist ein öffentliches Modell mit passender Ausgabe und Abrechnungseinheit ein sinnvoller Einstieg. Bei einem öffentlichen Modell mit Zeitabrechnung wird die Verarbeitung der eigenen Anfragen berechnet; Setup und Leerlauf sind kostenlos. Bei Deployments und den meisten privaten Modellen verschiebt sich diese Grenze: Setup, aktive Laufzeit und Leerlauf der Instanzen sind kostenpflichtig. Die dokumentierte Ausnahme für private Modelle sind als schnell startend gekennzeichnete Fine-Tunes, bei denen nur die aktive Verarbeitung berechnet wird.

Die Abrechnungsdokumentation unterscheidet außerdem zwischen Prepaid-Konten und nachträglicher Abrechnung. Bei Prepaid wird die Nutzung vom Guthaben abgezogen. Bei nachträglicher Abrechnung wird zu Monatsbeginn die Nutzung des Vormonats berechnet.

Zwei Rechenbeispiele zeigen, warum diese Unterscheidung zählt. 10,000 FLUX-Schnell-Ausgabebilder im Monat kosten $30 zum aufgeführten Ausgabepreis, ohne weitere Dienste oder zusätzlich generierte Bilder. Separat betrachtet kostet eine T4, die einen Monat mit 30 Tagen durchgehend online bleibt, $583.20: 720 Stunden mal $0.81, ohne zusätzliche skalierte Instanzen. Das sind unterschiedliche Einkaufsmodelle. Der Vergleich behauptet nicht, dass eine T4 dieselben Ergebnisse oder denselben Durchsatz wie der Bilddienst liefert.

Grundsätzlich werden fehlgeschlagene Durchläufe nicht berechnet. Die Abrechnungsdokumentation nimmt davon jedoch aktive Instanzen privater Modelle und Deployments, die bis zum Abbruch verbrauchte Zeit bei zeitbasierten Modellen sowie mögliche Abbruchgebühren offizieller Modelle aus. Ruft ein Modell weitere Modelle auf, können auch dort Kosten entstehen, selbst wenn der gesamte Durchlauf scheitert. Die Kostenschätzung muss deshalb den vollständigen geplanten Ablauf abdecken.

Welche Grenzen sind im Produktionsbetrieb entscheidend?

Replicate nimmt der ersten Integration den GPU-Betrieb ab. Aus der Dokumentation ergeben sich dennoch konkrete Grenzen, mit denen die Anwendung umgehen muss.

Kaltstarts und gemeinsam genutzte Kapazität

Replicate nennt einen Kaltstart „Cold Boot“: Bevor ein Modell eine Anfrage verarbeiten kann, müssen seine Umgebung und Gewichte geladen werden. Laut Erklärung zur Plattformarchitektur hält die laufende Nutzung beliebte öffentliche Modelle häufig betriebsbereit. Weniger genutzte Modelle sind öfter von Kaltstarts betroffen. Für offizielle Modelle gilt die zuvor beschriebene separate Zusage ständiger Betriebsbereitschaft.

Für die Anwendung folgt daraus etwas Konkretes: Eine interaktive Funktion mit einem selten genutzten Community-Modell braucht einen Wartezustand oder ein Deployment, das Kapazität verfügbar hält. Eine Stapelverarbeitung im Hintergrund kann mit Startzeiten anders umgehen als ein Benutzer, der sofort ein Ergebnis erwartet. Eine allgemeingültige Latenzzahl ersetzt die Bewertung des konkreten Modells unter der eigenen Arbeitslast nicht.

Bei niedrigem Guthaben greifen strengere Anfragelimits

Die Dokumentation zu Anfragelimits nennt 600 Anfragen zur Erstellung von Predictions pro Minute und 3,000 Anfragen pro Minute für andere Endpunkte. Kurze Spitzen oberhalb dieser Standardwerte sind möglich. Bei Drosselung wird HTTP 429 zurückgegeben; höhere Limits müssen bei Replicate angefragt werden. Es handelt sich um API-Anfragelimits, nicht um eine Zusage, dass ein Modell entsprechend viele Aufträge pro Minute abschließt.

Weniger offensichtlich ist die Begrenzung durch den Kontostand. Mit sinkendem Guthaben verschärft Replicate die Anfragelimits und empfiehlt automatisches Aufladen, damit der Saldo über $20 bleibt. Für Konten mit gewährtem Guthaben, aber ohne Zahlungsmethode gilt ein separates Limit von 1 Anfrage pro Sekunde, begrenzt auf 6 pro Minute.

Eine Warteschlange kann dadurch schon wegen des Abrechnungsstatus langsamer werden, bevor das Entwicklungsteam irgendeine Deployment-Einstellung verändert hat. Guthaben und Anfragefehler sollten gemeinsam überwacht werden. Bei Drosselung helfen begrenzte Wiederholungsversuche mit wachsenden Warteabständen. Häufige Statusabfragen verbrauchen dagegen unnötig das Kontingent für andere Endpunkte.

API und Browser speichern Daten unterschiedlich lange

Laut Dokumentation zur Datenaufbewahrung werden Eingabeparameter, Ausgabewerte, Ausgabedateien und Protokolle von API-Predictions standardmäßig nach einer Stunde gelöscht. Die Anwendung muss benötigte Daten vorher sichern. Eine zurückgegebene Datei-URL ist daher kein dauerhafter Medienspeicher.

Daten von im Browser erstellten Predictions bleiben unbegrenzt gespeichert. Auf der Website lassen sich eine Prediction und ihre zugehörigen Ausgabedaten und Dateien über Delete löschen. Für einen Browsertest und eine API-Integration gelten somit unterschiedliche Aufbewahrungsregeln. Aus dem einen Verhalten darf nicht auf das andere geschlossen werden.

Im Produktionsablauf sollten fertige Medien in einem selbst kontrollierten Speicher landen. Modell, Eingaben und Auftragsstatus werden so lange vorgehalten, wie der Supportprozess sie benötigt. Die Modellsichtbarkeit ist eine eigene Frage: Ein privates eigenes Modell begrenzt den Zugriff, begründet aber keine andere Aufbewahrungszusage. Ebenso belegt die Seite zur Datenaufbewahrung allein keine pauschalen Aussagen über Trainingsnutzung, regionale Datenspeicherung oder sämtliche vertraglichen Anforderungen an den Umgang mit Daten.

Die Modellauswahl bleibt Aufgabe der Anwendung

Replicates Katalog dient der Verteilung und Ausführung von Modellen. Kommerzielle Nutzungsrechte hängen weiterhin von der jeweiligen Modelllizenz ab; die Schemas der Community-Modelle unterscheiden sich. Ein Modellwechsel sollte deshalb wie eine Anwendungsänderung behandelt werden: Eingabevalidierung, Ausgabedateien, Nutzungsrechte und Kosten prüfen, bevor produktive Anfragen umgeleitet werden. Eine einheitliche Plattform macht ihre Modelle nicht beliebig austauschbar.

Fazit: Gemeinsam starten, dedizierte Kapazität gezielt einkaufen

Replicate ist eine starke Wahl, wenn der Wert des Produkts in der Anwendung rund um das Modell liegt und der entfallende GPU-Betrieb eine frühere Veröffentlichung ermöglicht. Ein geeigneter öffentlicher Endpunkt ist der richtige Ausgangspunkt. Ein offizielles Modell ist vorzuziehen, wenn dessen dokumentierte Verfügbarkeit, stabile Schnittstelle und Abrechnungseinheit die Anforderungen erfüllen.

Der Wechsel zu einem Deployment braucht einen klaren Grund: eigenen Inferenzcode, Kontrolle über Hardware, dedizierte Kapazität oder eine betriebsbereite Instanz für eine Funktion mit Kundenzugriff. Setup- und Leerlaufkosten gehören dann zur Entscheidung. Ist dagegen ein medienorientierter Katalog, die Bereitstellung von Sprachmodellen, ein Hub-basiertes Deployment oder eine umfassendere Python-Rechenanwendung ausschlaggebend, bilden die genannten Alternativen die passende Vorauswahl.

Der erste Meilenstein der Implementierung sollte ein vollständiger Auftrag sein: einreichen, Abschluss erkennen, Ausgabe speichern und Kosten erfassen. Erst danach fällt die Entscheidung, ob der öffentliche Endpunkt oder ein dediziertes Deployment in Produktion geht.

Häufige Fragen zu Replicate

Die Checkliste für den Audit von KI-Geschäftsabläufen hilft, die Arbeit rund um das Modell zu erfassen, bevor die Funktion verbindlich eingeplant wird.