Replicate im Test: eine Modell-API pro Sekunde abgerechnet, mit allen scharfen Kanten benannt

Replicate ist eine gehostete Inferenzplattform, die tausende offene und proprietäre Modelle hinter einer einzigen Prediction-API bündelt und nur für die Sekunden abrechnet, in denen eine Maschine den Auftrag tatsächlich ausführt. Die Position ist einfach: Für ein Team, das heute Nachmittag ein neues Bild- oder Videomodell ausprobieren will, ohne eine GPU bereitzustellen, ist das der kürzeste Weg auf dem Markt. Für einen Produktionsendpunkt mit Latenzbudget und planbarer Rechnung ist die Abrechnung pro Sekunde der falsche Vertrag, und die Plattform wird erst dann verteidigbar, wenn eine Version gepinnt und das Modell auf ein Deployment gesetzt ist.

Sie liegt zwischen einer eigenen GPU und dem Kauf bei einem Modellanbieter. Auf der einen Seite konkurriert sie mit fal.ai und Baseten, die Inferenz verkaufen statt einen Katalog; auf der anderen mit dem Mieten einer Maschine bei einem GPU-Broker plus eigenem Container. Was sie nicht ersetzt, ist eine token-abgerechnete LLM-API. Replicate serviert gern ein Llama-Modell auf einer H100, aber niemand rechnet einen Chat-Endpunkt pro Sekunde GPU-Zeit ab.

Was Replicate tatsächlich ist

Drei Dinge teilen sich einen Account und eine API. Erstens einen öffentlichen Katalog von Modellen, die ihre Autoren veröffentlicht haben: Feintunes, Community-Implementierungen, Forschungscode. Zweitens eine Menge offizieller Modelle, die Replicate selbst pflegt, laut Dokumentation über einhundert, die immer warm sind, pro Ausgabeeinheit abgerechnet werden und ein stabiles Input-Schema haben. Drittens private Modelle, die man selbst mit Cog paketiert und auf dedizierter Hardware betreibt, wo man für die gesamte Lebensdauer der Instanz zahlt statt für die Arbeit, die sie leistet.

• Jeder Lauf ist ein Prediction-Objekt mit Eingaben, Ausgaben, Status, Timing-Metriken und einer Cancel-URL, egal was das Modell tut.
• Abrechnung pro Sekunde zu den veröffentlichten Raten: 0,000025 $ für eine kleine CPU, 0,000225 $ für eine T4, 0,001400 $ für eine A100 mit 80 GB, 0,001525 $ für eine H100.
• Offizielle Modelle rechnen pro Ausgabe ab: flux-1.1-pro mit 0,04 $ pro Bild, ideogram-v3-quality mit 0,09 $, deepseek-r1 mit 3,75 $ pro Million Input-Tokens.
• Asynchron ist der Standard; synchron wird es mit dem Header Prefer: wait, der die Anfrage 60 Sekunden offen hält.
• Vorkauf statt Abo. Guthaben gilt ein Jahr ab Kauf und ist nicht erstattungsfähig.
• Apache-2.0-Clients für Node.js, Python, Swift und Go sowie ein gehosteter MCP-Server auf mcp.replicate.com, der der HTTP-API folgt.

Wie eine Prediction läuft

Das Anlegen einer Prediction liefert sofort ein Objekt mit dem Status starting, und dieses Objekt bleibt die Arbeitseinheit für den Rest des Laufs. Drei Dinge bestimmen dann, wie lange man wartet: ob das Modell warm ist, wie lange das Modell selbst braucht, und ob man pollt, die HTTP-Verbindung offen hält oder auf einen Webhook wartet.

Die Status sind wenige und tragen die betriebliche Information. starting dauert normalerweise weit unter einer Sekunde; bleibt es länger, ist es ein Cold Boot, und das Laden mehrerer Gigabyte Gewichte kann Minuten dauern. processing ist die eigene predict()-Methode des Modells. Danach beendet einer der Status succeeded, failed, canceled oder aborted den Lauf, und der Unterschied zwischen den letzten beiden ist, ob die Maschine je gestartet ist.

Predictions laufen nach 30 Minuten in einen Timeout, und eine Frist pro Prediction erlaubt der Anwendung, früher aufzugeben. Die Abrechnungsregel folgt dieser Trennung exakt: Eine vor dem Start abgebrochene Prediction wird nicht berechnet, eine abgebrochene nach dem Start für die Sekunden, die sie lief. Das ist ein wirklich gutes Design und zugleich der einzige Grund, warum man eine Frist aggressiv setzen darf.

Erste Schritte

Der Node.js-Client fasst den Lebenszyklus in run() zusammen. Für ein Modell, das in Sekunden fertig ist, ist das die komplette Integration, sonst gibt es nichts zu schreiben.

import Replicate from "replicate";
import { writeFile } from "node:fs/promises";

// Reads REPLICATE_API_TOKEN from the environment.
const replicate = new Replicate();

const [image] = await replicate.run("black-forest-labs/flux-schnell", {
  input: {
    prompt: "An astronaut riding a rainbow unicorn, cinematic lighting",
  },
});

await writeFile("output.png", image);
console.log("saved output.png");

Längere Modelle brauchen den asynchronen Weg, und ein Webhook ist der einzige sinnvolle Weg, das Ergebnis zu erfahren. Zwei Details führen zu Fehlern. Die Signatur deckt den rohen Request-Body ab, die Prüfung muss also vor jedem JSON-Parsing laufen. Und der Client wandelt den Byte-Body vor der HMAC-Berechnung wieder in einen String um, was jede Signaturprüfung stillschweigend brechen würde.

import express from "express";
import Replicate from "replicate";
import { createHmac, timingSafeEqual } from "node:crypto";

const replicate = new Replicate();
const app = express();

// Verify first, parse second: the signature covers the raw body bytes.
app.post("/webhook", express.raw({ type: "application/json" }), (req, res) => {
  const key = process.env.REPLICATE_WEBHOOK_KEY.replace("whsec_", "");
  const signed = `${req.headers["webhook-id"]}.${req.headers["webhook-timestamp"]}.${req.body}`;
  const expected = createHmac("sha256", key).update(signed).digest("base64");
  const seen = String(req.headers["webhook-signature"]).split(" ").map((p) => p.split(",")[1]);
  const valid = seen.some((sig) => {
    const a = Buffer.from(sig), b = Buffer.from(expected);
    return a.length === b.length && timingSafeEqual(a, b);
  });
  if (!valid) return res.status(401).end();

  const prediction = JSON.parse(String(req.body));
  res.sendStatus(204); // Replicate retries terminal webhooks on 4xx and 5xx.
  console.log(prediction.id, prediction.status);
});

app.post("/image", async (req, res) => {
  const prediction = await replicate.predictions.create({
    model: "black-forest-labs/flux-schnell",
    input: { prompt: req.body.prompt },
    webhook: "https://example.com/webhook",
    webhook_events_filter: ["completed"],
  });
  res.json({ id: prediction.id });
});

Was es kostet

Der öffentliche Katalog misst Rechenzeit pro Sekunde, und der Satz gehört zur Hardware, nicht zum Modell. Die veröffentlichte Tabelle rechnet zusätzlich einen Stundensatz aus, der zum Vergleich taugt, aber nicht abgerechnet wird. Hochlaufzeit und Leerlauf auf geteilter Kapazität sind kostenlos; nur die Verarbeitungszeit wird berechnet.

Offizielle Modelle brechen dieses Muster, und dort wird die Rechnung planbar. flux-1.1-pro kostet 0,04 $ pro Ausgabebild, flux-schnell 3,00 $ pro tausend Bilder, ideogram-v3-quality 0,09 $ und deepseek-r1 wird pro Token abgerechnet. Jedes private Modell dreht das um: Es läuft auf dedizierter Hardware, und man zahlt für Hochlauf, Leerlauf und aktive Zeit gleichermaßen, eine Instanz kostet also auch dann, wenn sie den ganzen Nachmittag niemand aufruft.

Bezahlt wird im Voraus. Guthaben wird vorab gekauft, mit der Nutzung verbraucht, gilt ein Jahr und ist nicht erstattungsfähig. Ist die Balance bei null, wird laufende Infrastruktur abgeschaltet und keine neue Arbeit gestartet. Eine Prediction, die das Guthaben überzieht, wird zum Monatsende über die hinterlegte Zahlungsmethode abgerechnet. Auto-Reload gibt es, mit einer dokumentierten Untergrenze von 5 $ Schwelle und 15 $ Nachschub, und ist der billigste Schutz vor einer Schlange gedrosselter Anfragen.

Deployments und Cold Boots

Ein Deployment pinnt eine Modellversion auf einen Hardwaretyp und eine Instanzspanne und beantwortet damit das Cold-Boot- und das Leerlaufproblem gleichzeitig. Der Preis ist explizit: Eine dauerhaft warme T4 kostet 0,81 $ pro Stunde, also 583 $ für einen dreißigtägigen Monat ohne Leerlauf, gegenüber nichts für dasselbe Modell mit hundert Aufrufen am Tag auf geteilter Kapazität. Beim Deployment hört die Replicate-Abrechnung auf elastisch zu sein und wird zur Position im Budget.

• Die getestete Version pinnen. Eine neue Modellversion kann dann das Verhalten unter Last nicht mehr ändern.
• min_instances auf 1 setzen, und der Cold Boot samt mehrerminütigem Gewichts Laden verschwindet.
• Dedizierte Hardware heißt keine Warteschlange mit anderen Nutzern, kostet aber jeden Leerlaufstunde.
• Dieselbe Trennung gilt für offizielle Modelle, die Replicate pflegt und warm hält, und Community-Modelle, die ihre Autoren pflegen und die kalt starten können.

Datenaufbewahrung, Tokens und Webhooks

Alles, was über die API geht, ist standardmäßig flüchtig. Für über die API erstellte Predictions nennt die Dokumentation, dass Eingabeparameter, Ausgabewerte, Ausgabedateien und Logs nach einer Stunde entfernt werden und eigene Kopien nötig sind. Über die Weboberfläche erstellte Predictions bleiben dagegen dauerhaft. Diese Asymmetrie ist die überraschendste betriebliche Tatsache der Doku, weil dasselbe Modell je nach Oberfläche in zwei sehr unterschiedlichen Aufbewahrungsregeln steht.

• API-Tokens sind 40 Zeichen lang, beginnen mit r8_, gehen als Bearer-Token mit, sind pro Umgebung benannt und einzeln widerrufbar.
• Replicate sucht in öffentlichen Repositories nach exponierten Tokens und deaktiviert kompromittierte automatisch, mit einer erklärenden E-Mail. Praktisch, aber auch ein Weg, wie ein Fehlalarm die Produktion stoppt.
• Webhooks tragen webhook-id, webhook-timestamp und webhook-signature; signiert wird die mit Punkten verbundene Kombination, mit HMAC-SHA256.
• Der Signing-Secret kommt von GET /v1/webhooks/default/secret, und die Doku empfiehlt, ihn zu cachen statt ihn pro Zustellung zu holen.
• Die Grenzen liegen bei 600 Prediction-Erzeugnissen pro Minute und 3.000 Anfragen pro Minute für alle anderen Endpunkte, mit einem 429-Body, der das Reset-Fenster nennt.

Wo es weh tut

Der Katalog ist das Produkt, und der Katalog ist das Risiko. Ein Community-Modell ist ein Container, den jemand Fremdes veröffentlicht hat: Das Input-Schema kann sich zwischen Versionen ändern, die Autorin oder der Autor kann verschwinden, und Replicates eigene Dokumentation sagt, dass Community-Modelle unterschiedliche Grade an Stabilität, Dokumentation und Support haben können. Nur offizielle Modelle haben eine stabile API, und eine gepinnte Version plus ein Test sind das Mindestmaß für alles, was Kunden sehen.

Das zweite Problem ist, dass die Rechnung nie die Rechnung ist, die die Finanzabteilung erwartet. Ein Modell mit 0,04 $ pro Bild und eines mit 5,49 $ pro Stunde können beide hinter einer achtlosen Schleife liegen, und die einzige Angabe pro Lauf liefert die API im metrics-Objekt einer einzelnen Prediction, das standardmäßig niemand aggregiert.

Drittens sind die Client-Bibliotheken unausgewogen. Der Node.js-Client steht bei 1.4.0, der Python-Client bei 1.0.7, eine 2.0-Linie ist noch Beta statt freigegeben. Ein Python-Dienst sollte direkt die HTTP-API ansprechen, statt zu warten, und das OpenAPI-Schema sowie der llms.txt-Endpunkt machen das unangenehm leicht.

Fazit

Replicate ist das beste Preis-Leistungs-Verhältnis für genau ein Problem: ein offenes Modell zu betreiben, ohne eine GPU zu besitzen. Für alles andere passt es schlecht, und der Grund ist strukturell und nicht ein Frage der Reife. Die Abrechnung pro Sekunde optimiert die Auslastung der Hardware des Anbieters, und die eigene Rechnung ist der Störterm in dieser Optimierung.

1. Teams, die ein neues Bild-, Video- oder Sprachmodell prototypen und diese Woche eine Antwort brauchen.
2. Teams, die bereit sind, eine Version zu pinnen, das Input-Schema stabil zu halten und alles in ein hartes Kostenlimit zu wickeln.
3. Alle, die Breite an Modellen wollen statt eine Plattform, und akzeptieren, dass der größte Teil dieses Katalogs ohne Wartung ist.
4. Nicht wählen für einen interaktiven Endpunkt, in dem Tail-Latenz ein Produktmerkmal ist, und nicht für eine gleichmäßige Last über wenige Prozent Auslastung hinaus, wo eine reservierte GPU schlicht billiger ist.
5. Nicht wählen, wenn Eingabedateien geschützte personenbezogene Daten enthalten und ein Ein-Stunden-Fenster nicht der eigenen Richtlinie genügt.

Quellen

1. Replicate pricing
2. Replicate Doku: About predictions
3. Replicate Doku: Create a prediction
4. Replicate Doku: Prediction lifecycle
5. Replicate Doku: Rate limits
6. Replicate Doku: Data retention
7. Replicate Doku: Verify webhooks
8. Replicate Doku: Official models
9. fal.ai pricing
10. Baseten pricing