Von KI-Coding-Agenten zu KI-Inferenzplattformen

Ich heiße Dora. Den ganzen Monat über habe ich mit Gründern über ihre KI-App-Stacks gesprochen. Immer wieder zeigt sich dasselbe Muster. Sie schließen ein Backend in drei Wochen ab, während Codex parallele Agenten-Threads ausführt. Endpunkte werden schneller geliefert, als Tests geschrieben werden. Dann versuchen sie, Bild- oder Videogenerierung hinzuzufügen – und alles stockt. Der Coding-Agent kann den API-Client schreiben. Er kann nicht dafür sorgen, dass der zugrunde liegende Inferenz-Betrieb skaliert.

Das ist die Lücke. Die Coding-Agent-Schicht hat sich 2026 schnell weiterentwickelt. Die darunter liegende KI-Inferenz-Plattform-Schicht – das Ding, das die Modelle tatsächlich ausführt – bekommt weniger Aufmerksamkeit, obwohl dort die meisten Produktionsprobleme entstehen. Dieser Artikel beschreibt, wie der Stack für generative KI-Apps 2026 tatsächlich aussieht, und wo Coding-Agents aufhören und Inferenz-Infrastruktur beginnt.

Warum Coding-Agents nur eine Schicht des generativen App-Stacks sind

Was Codex für die Entwicklungsgeschwindigkeit verändert

OpenAIs Codex-App zur Verwaltung mehrerer Coding-Agents überstieg bis März 2026 zwei Millionen wöchentlich aktive Nutzer. Der Grund ist keine Neuheit. Es ist die Tatsache, dass die Hürde beim Schreiben von CRUD-Endpunkten, API-Clients und Integrations-Klebecode wirklich zusammengebrochen ist. Ein einzelner Entwickler kann mehrere Agent-Threads parallel laufen lassen, die jeweils an einem anderen Teil der Codebasis arbeiten. Einen Spec in Code umzuwandeln ist nicht mehr der Flaschenhals.

Das ist besonders für KI-App-Entwickler relevant. Die Infrastruktur – Webhooks, Queue-Worker, Retry-Logik, Auth-Flows – hat früher Wochen gefressen. Mit agentischen Coding-Tools schrumpft das auf Tage. Das ist real.

Was es für Produktions-Inferenz nicht löst

Codex schreibt den Aufruf. Es führt das Modell nicht aus. Wenn die App echte Nutzer bedient – besonders wenn diese Nutzer Bilder oder Videos generieren – verschiebt sich der Flaschenhals. Cold Starts. Rate-Limits pro Modellanbieter. Queue-Tiefe. Kosten pro Anfrage, die nicht sauber zum eigenen Abrechnungsmodell passen. Der Coding-Agent wird keines davon beheben. Er hat nur den Client geschrieben, der jetzt dagegen läuft.

Hier braucht der generative KI-App-Stack eine andere Schicht unter dem Code.

Der generative KI-App-Stack 2026

Der Stack, den ich in funktionierenden Apps heute sehe, hat meist vier Schichten. Die Bezeichnungen variieren. Die Form nicht.

UI- und Orchestrierungs-Schicht

Frontend, Prompt-Orchestrierung, Konversationszustand, nutzerseitige Logik. Das ist das, was Codex und ähnliche KI-Entwickler-Tools am besten produzieren. Die meisten Entwickler fangen hier an und bleiben länger hier als sie sollten.

Modell- und Inferenz-Schicht

Die eigentlichen Modellaufrufe. Text, Bild, Video, Audio, Embeddings. Hier sitzt die Inferenz-Plattform – zwischen dem App-Code und der zugrunde liegenden GPU-Infrastruktur. Sie verwaltet Routing, Batching, Retries, Fallback, asynchrones Job-Management. Entwickler unterschätzen diese Schicht tendenziell, bis sie in der Produktion sind.

Storage, Monitoring und Workflow-Automatisierung

Objektspeicher für generierte Assets. Observability dafür, was jeder Aufruf gekostet hat und wie lange er gedauert hat. Workflow-Tools (n8n, Temporal, Custom-Orchestratoren) zum Verketten von Generierungsschritten. Diese Schicht taucht später auf. Sie taucht immer auf.

Was eine KI-Inferenz-Plattform tut

Eine KI-Inferenz-Plattform ist die Schicht, die aus „Ich möchte Modell X aufrufen” macht: „Der Aufruf kehrt zurück, pünktlich, zu bekannten Kosten, mit behandelten Retries.” Sie ersetzt keine Modellanbieter. Sie sitzt vor ihnen.

Modellzugriff und Routing

Die Inference Providers-Dokumentation von Hugging Face beschreibt das allgemeine Muster gut – eine einheitliche Proxy-Schicht, die zwischen der Anwendung und mehreren KI-Anbietern sitzt und Authentifizierung, Routing und Failover an einem Ort übernimmt. Man wechselt Modelle mit einem Parameter, nicht durch eine Re-Integration. Das ist wichtiger als es klingt. Das Modell, das man in Woche eins wählt, ist selten das Modell, mit dem man ausliefert. Wenn ein Wechsel bedeutet, den Client neu zu schreiben, bleibt man länger auf dem falschen Modell als man sollte.

Durchsatz, Retries und Skalierung

Was man von einer Inferenz-Plattform wirklich braucht, ist keine Geschwindigkeit im Marketingsinne. Es ist Vorhersagbarkeit. Keine Cold Starts bei Traffic-Spitzen. Idempotente Retries, wenn eine Generierung fehlschlägt. Concurrency-Limits, die man nachvollziehen kann. Stripes Ingenieure haben eine der besseren öffentlichen Referenzen zu Idempotenz für verteilte Systeme geschrieben – der Stripe-Engineering-Artikel über den Entwurf robuster APIs mit Idempotenz-Keys ist es wert, gelesen zu werden, bevor man eine eigene Retry-Schicht baut.

Einheitliche Abrechnung und operative Kontrollen

Wenn man vier Modellanbieter aufruft, zahlt man vier Rechnungen, jede in einer anderen Einheit. Tokens für einen. Generierungen für einen anderen. Compute-Sekunden für einen dritten. Eine einheitliche Abrechnungsoberfläche flacht das ab. Eine Zahl pro Monat, aufgeschlüsselt nach Modell. Das allein verändert, wie Teams Modellauswahl-Entscheidungen treffen, weil der Kostenvergleich keine Tabellenkalkulation und kein Meeting mehr erfordert.

Warum Bild- und Video-APIs andere Backend-Anforderungen schaffen

LLM-APIs sind größtenteils Request-Response mit Streaming. Eine Bild-Video-API ist das nicht. Das ist der Teil, den die meisten Entwickler unterschätzen, wenn sie von Text zu Multimodal expandieren.

Async-Jobs und lang laufende Media-Aufgaben

Ein Video-Generierungsaufruf kann 30 Sekunden dauern. Oder drei Minuten. Man kann eine HTTP-Verbindung nicht so lange offen halten, und man sollte es auch nicht. Jede ernsthafte Bild-Video-API läuft asynchron – man sendet einen Job, erhält eine Job-ID, dann empfängt man einen Webhook oder pollt das Ergebnis ab.

Wenn der Coding-Agent standardmäßig synchronen API-Client-Code generiert hat, wird man das auf die harte Tour herausfinden.

Asset-Handling und Output-Storage

Text-Outputs sind klein. Ein 6-Sekunden-Video sind 5–15 MB. Wo lebt es nach der Generierung? Wie lange? Wer zahlt für den Speicher? Hält der Modellanbieter es vor, hält man es selbst, beide? Das sind Entscheidungen, und sie müssen vor dem Launch getroffen werden, nicht danach. Die meisten Plattformen halten generierte Outputs standardmäßig etwa 7 Tage vor – man sollte die Richtlinie der gewählten Plattform überprüfen, bevor man Annahmen trifft.

Modellspezifische Limits und Fallback-Design

Verschiedene Modelle haben unterschiedliche Concurrency-Caps, unterschiedliche Content-Filter, unterschiedliche Output-Formate. Wenn Modell A einen Fehler zurückgibt oder ein Rate-Limit erreicht, sollte die Plattform auf Modell B zurückfallen können. Das selbst zu bauen kostet ein Viertel eines Ingenieursjahres. Es zu kaufen ist ein Konfigurationsfeld. So lag also der Flaschenhals.

Wie Entwickler ihren Stack wählen sollten

Der richtige Stack hängt davon ab, wo man sich befindet. Drei grobe Phasen.

Kleiner Prototyp vs. Produktions-App

Wenn man testet, ob eine Idee funktioniert, sind direkte API-Aufrufe zu einem Anbieter in Ordnung. Codex schreibt diese Integration an einem Nachmittag. Nicht über-engineeren. Wenn der Prototyp Zugkraft bekommt, wird man die Inferenz-Schicht sowieso neu bauen – das ist normal. Die Kosten vorzeitiger Aggregation sind höher als die Leute denken, wenn sie noch nie über den Prototyp hinaus geliefert haben. Der umgekehrte Fehler – mit einer einzigen direkten Integration zu bleiben, nachdem es sinnvoll wäre – kostet mehr, zeigt sich aber später und ist schwerer zuzuordnen.

Direkte APIs vs. Aggregations-Schicht

Sobald man über den Prototyp hinaus ist, lautet die Frage: Wie viele Modelle ruft man auf, und wie oft tauscht man sie? Ein Modell, niedrige Frequenz – direktes API. Drei oder mehr Modelle, häufiges A/B-Testing – eine Aggregations-Schicht rechnet sich schnell. Selbst auf SDK-Ebene zeigt sich dasselbe Muster – die AI SDK Provider Registry-Dokumentation von Vercel beschreibt, wie Teams mehrere Anbieter über ein einziges Interface verwalten, um zu vermeiden, dass Integrationscode über die App verstreut wird. Auf der Inferenz-Ebene erweitert eine Aggregations-Plattform wie WaveSpeedAI diese Idee – Hunderte von Modellen hinter einem Endpunkt, einer Auth, einer Abrechnungsoberfläche. Der Punkt ist nicht die Modellanzahl. Es geht darum, nicht jedes Mal neu integrieren zu müssen, wenn etwas Besseres erscheint.

Wann Orchestrierung und Observability hinzufügen

Das Signal, dass man Orchestrierung braucht: Man hat angefangen, Generierungsschritte zu verketten (Bild → Upscale → Video) und die Kette bricht an nicht offensichtlichen Stellen. Das Signal für Observability: Die monatlichen Modellkosten haben sich verdoppelt und niemand kann sagen, welches Feature es verursacht hat.

Beides hinzufügen, bevor man diese Momente trifft, nicht danach. Das lerne ich immer wieder auf die harte Tour.

FAQ

Was ist eine KI-Inferenz-Plattform?

Eine KI-Inferenz-Plattform ist die Schicht zwischen dem App-Code und den Modellanbietern. Sie verwaltet Modell-Routing, Retries, Async-Jobs, Output-Storage und Abrechnung über mehrere Modelle hinweg. Man kann sie sich als das Äquivalent vorstellen, was ein CDN für Web-Traffic tut – eine Abstraktion über die chaotische zugrunde liegende Infrastruktur.

Wie unterscheidet sich eine Inferenz-Plattform von einem Coding-Agent?

Ein Coding-Agent schreibt den Code, der ein Modell aufruft. Eine Inferenz-Plattform führt den Modellaufruf aus und verwaltet alles drum herum – Queueing, Retries, Fallback, Abrechnung. Codex und ähnliche KI-Entwickler-Tools sitzen upstream der Inferenz-Schicht, nicht als Ersatz dafür. Sie produzieren den Client. Die Plattform verwaltet, was passiert, nachdem der Client eine Anfrage sendet.

Wie verbinden KI-Apps Coding-Agents mit Modell-APIs?

Meist über einen generierten Client. Der Coding-Agent schreibt einen API-Client (oft auf einen einzelnen Anbieter zeigend), die App ruft diesen Client auf, und der Client trifft das Modell. Wenn man eine Inferenz-Plattform dazwischenschaltet, zeigt der Client auf die Plattform, und die Plattform fächert zu den eigentlichen Modellanbietern auf. Die Übergabe ist unkompliziert – was sich ändert, ist alles, was die Plattform verwaltet, was der ursprüngliche Client nicht tat.

Wann braucht ein Team eine Inferenz-Plattform?

Wenn mehr als ein Modell aufgerufen wird, wenn Bild oder Video involviert ist (Async-Muster machen das fast obligatorisch), oder wenn Produktionszuverlässigkeit wichtiger zu werden beginnt als Geschwindigkeit der ersten Version. Unterhalb dieser Schwelle funktionieren direkte API-Aufrufe. Darüber verändert sich die Rechnung schnell. Die schwierigere Frage – genau wann ein bestimmtes Team diese Schwelle überschreitet – hängt von Nutzungsfrequenz und Concurrency-Anforderungen ab und sollte eher anhand aktueller Anbieter-Dokumentation geprüft werden als durch Annahmen.

Fazit

Der generative KI-App-Stack 2026 hat sich in zwei klar unterschiedliche Schichten aufgeteilt. Coding-Agents oben – dieser Teil ist weitgehend gelöst. KI-Inferenz-Plattformen darunter – hier lebt noch immer der größte Teil der Produktionsreibung. Für Entwickler, die multimodale Apps ausliefern, ist eine KI-Inferenz-Plattform kein Luxus mehr. Sie ist der Unterschied zwischen einem MVP, das gut in Demos funktioniert, und einer App, die echten Traffic verarbeitet, ohne darunter zu brechen.

Probiere es selbst aus. Das wird mehr sagen als alles, was ich schreibe.

Frühere Beiträge: