Serverless AI: Warum Cloudflare zum KI-Backend für Web-Apps wird

Das klassische KI-Integrations-Problem

Ein Sprachmodell ist schnell gefunden. Die eigentliche Arbeit beginnt danach.

Wer KI in eine Web-App einbauen will, steht vor einem Stapel aufeinander aufbauender Entscheidungen: Welches Modell? Über welche API? Wie werden Embeddings erzeugt? Wo landen die Vektoren? Wer speichert die Dokumente, über die das Modell reden soll? Wie wird skaliert, wenn Anfragen zunehmen? Wer überwacht Kosten und Fehlerraten?

Jeder dieser Schritte ist technisch lösbar. Zusammen ergibt sich ein Integrationsaufwand, der schnell die eigentliche Feature-Arbeit überlagert. Und das vor dem ersten Produktiv-Request.

Cloudflare adressiert genau dieses Problem – nicht mit einem einzelnen KI-Dienst, sondern mit einem zusammenhängenden Stack.

Was Cloudflare hier anders macht

Das Besondere ist nicht, dass Cloudflare jetzt Modelle anbietet. Das Besondere ist, dass alle relevanten Bausteine auf derselben Plattform laufen – in derselben Runtime, mit demselben Auth-Modell, ohne Netzwerk-Overhead zwischen den Einzelteilen.

Was hier entsteht, ist im Kern ein Edge-native RAG-System: Retrieval, Inferenz und Datenzugriff passieren nicht in einem zentralen Backend, sondern verteilt im Edge-Netzwerk – nah am Nutzer. Das grenzt den Ansatz von klassisch serverlosem Hosting ab: Es geht nicht nur darum, keine Server zu betreiben, sondern darum, Verarbeitungslogik geografisch zu verteilen und Latenz strukturell zu reduzieren.

KI wird damit Teil der Request-Logik – nicht ein externer Dienst. Eine Worker-Funktion ruft das Modell auf, sucht in der Vektordatenbank, liest aus dem Objektspeicher – alles im gleichen Ausführungskontext.

Der Architekturvergleich macht den Unterschied greifbar:

Klassischer Stack:

Frontend → Backend (zentral) → LLM API → Vector DB → Storage

Cloudflare:

Frontend → Worker (Edge, nah am Nutzer)
               ↓
       Workers AI · Vectorize · R2
       (alles lokal im Netzwerk)

Cloudflare eliminiert den Backend-Layer als zentrale Instanz. Kein zusätzlicher Hop zu einem separaten Dienst – das ist der strukturelle Unterschied, nicht nur ein Convenience-Feature.

Wie ein Request abläuft

In Code sieht das so aus – ohne Infrastruktur-Abstraktion, einfach orchestrierte Calls:

const embedding = await ai.run('@cf/baai/bge-base-en-v1.5', {
  text: query,
});

const results = await env.VECTORIZE.query(embedding.data, { topK: 5 });

const docs = await Promise.all(
  results.matches.map((match) => env.R2.get(match.id))
);

const response = await ai.run('@cf/meta/llama-3-8b-instruct', {
  prompt: buildPrompt(query, docs),
});

Die Bausteine

Workers AI

Sprachmodelle, Embedding-Modelle, Bildklassifikation, Sprach-zu-Text – alles per API, ausgeführt auf Cloudflare-eigener GPU-Infrastruktur. Kein eigenes Hosting, kein GPU-Management, kein Modell-Download.

Verfügbare Modellkategorien:

• Text Generation: Llama 3, Mistral, Phi – für Chat, Zusammenfassungen, Klassifikation
• Text Embeddings: Modelle wie @cf/baai/bge-base-en-v1.5 für semantische Suche
• Image Classification: SqueezeNet, ResNet – für einfache Bild-Kategorisierung
• Speech Recognition: Whisper-Varianten – für Audio-zu-Text

Workers haben praktisch keine klassischen Cold Starts. Der Flaschenhals verschiebt sich: Nicht mehr Infrastruktur-Startzeiten, sondern Modell-Inferenz dominiert die Latenz. GPU-Auslastung und Modellgröße bestimmen die Antwortzeit – das ist der neue Bottleneck, nicht die Plattform selbst.

Vectorize

Eine Managed Vektordatenbank für semantische Suche und RAG-Pipelines. Vectorize speichert Embedding-Vektoren und ermöglicht Ähnlichkeitssuche – der Kern jedes Systems, das “über eigene Inhalte reden” soll.

Vectorize läuft direkt im Cloudflare-Netzwerk. Vektoren, die per Workers AI erzeugt wurden, können ohne zusätzlichen Transport direkt in den Index geschrieben werden.

Zwei Punkte, die bei der Planung relevant sind: Vectorize läuft verteilt, was bei Writes zu Eventual Consistency führen kann – Replikation über Edge-Standorte hinweg ist nicht instant. Das ist ein klassischer Trade-off zwischen Latenz und Konsistenz. Und: Worker-Runtime-Limits – Memory, Execution Time, Payload-Größe – erzwingen Chunking bei größeren Dokumenten. Das ist keine optionale Optimierung, sondern eine harte Rahmenbedingung der Runtime.

R2 Storage

Objektspeicher für Dokumente, PDFs, Content-Daten – kompatibel mit S3-APIs, aber ohne Egress-Kosten. Für RAG-Systeme relevant, weil die ursprünglichen Dokumente irgendwo liegen müssen – nah an der Verarbeitungslogik und kosteneffizient abrufbar.

AI Gateway

Eine Schicht über allen KI-API-Aufrufen: Logging, Caching, Rate Limiting – aber das greift zu kurz.

AI Gateway ist im Kern eine Provider-Abstraktion. Wer mehrere Modelle oder externe Anbieter kombiniert, konfiguriert hier Routing, Fallback und Kostenkontrolle zentral:

• Primär: Workers AI
• Fallback: OpenAI, Anthropic oder weitere Anbieter
• Routing: nach Kosten, Latenz oder Verfügbarkeit

Modellwechsel wird zur Konfigurationsfrage statt zur Codeänderung. Für Teams relevant, die Modell-Kosten aktiv steuern oder Provider-Abhängigkeiten absichern wollen. Für DSGVO-Compliance außerdem nützlich: Logging lässt sich gezielt steuern, statt unkontrolliert alle Prompts und Antworten zu speichern.

KI-Suche (Beta)

Eine fertige RAG-Pipeline als Service. Weniger Konfiguration, weniger eigene Orchestrierung – für Anwendungsfälle, wo die Pipeline-Logik nicht selbst geschrieben werden muss.

Einordnung

Vergleichbare Plattformansätze gibt es für andere Bereiche: Firebase für App-Backends, Vercel für Frontend und serverlose Funktionen. Cloudflare belegt eine andere Nische – den Bereich KI plus Daten plus globales Compute in Kombination.

Was das für Entwickler bedeutet: Der Stack löst die Infrastruktur-Frage. Wer Workers AI, Vectorize und R2 kombiniert, hat eine funktionale RAG-Pipeline ohne eigene Server, ohne GPU-Budget, ohne Skalierungsarbeit.

Kostenstruktur: Abrechnung läuft nach Requests, Tokens (Inferenz) und Storage (R2 und Vectorize). Entscheidend: keine Egress-Kosten. Bei Retrieval-intensiven Workloads kann das günstiger sein als klassische Cloud-Setups, wo Datenübertragung zwischen Services separat abgerechnet wird.

Vendor Lock-in passiert auf mehreren Ebenen gleichzeitig: Workers Runtime API, Vectorize Index Format und die Edge-first Architektur selbst. Gleichzeitig ist der Lock-in selektiv. Viele Schnittstellen sind bewusst offen gehalten: R2 ist S3-kompatibel, AI Gateway unterstützt OpenAI-kompatible API-Formate, HTTP-Standards sind durchgehend. Das reduziert die Abhängigkeit auf Datenzugriffs-Ebene, auch wenn die Ausführungsumgebung Cloudflare-spezifisch bleibt. Der Lock-in ist geringer als bei klassischen PaaS-Plattformen – aber er ist vorhanden.

Das ist eine Abwägung, keine Schwäche per se – aber eine Entscheidung, die bewusst getroffen werden sollte.

Was das nicht ist

Cloudflare ist keine spezialisierte ML-Plattform. Was konkret fehlt:

• Kein Fine-Tuning eigener Modelle
• Kein Training-Pipeline-Support
• Kein klassisches Batch Processing
• Kein GPU-Scheduling-Control
• Kein Feature Store
• Keine deterministische Kontrolle über Modellversionen, wie sie self-hosted Setups bieten

Die Stärke liegt in der Integration, nicht in der ML-Tiefe. Wer fertige Modelle nutzen und mit eigenen Daten anreichern will, ist gut aufgehoben. Wer an Modellen selbst arbeitet, Batch-Pipelines für Training benötigt oder präzise Kontrolle über Modellversionen braucht, braucht eine andere Infrastruktur.

Das gilt es bei der Einschätzung im Kopf zu behalten.