Die AI-Stack-Frage, die jedes Entwicklerteam stellen wird

Irgendwann wird dein Engineering-Team eine Frage stellen, die im Nachhinein offensichtlich wirkt: Warum geben wir so viel unserer Entwicklungsinfrastruktur an externe Anbieter ab?

Das ist keine rhetorische Frage und kein Aufruf, gehostete AI-Services komplett aufzugeben. Es ist eine praktische Infrastruktur-Überlegung, mit der sich immer mehr Teams beschäftigen, während AI-Coding-Tools fester Bestandteil der täglichen Arbeit werden.

Neulich bin ich über eine interessante Fallstudie gestolpert, die genau zeigt, warum das relevant ist. Ein kleines Team bei Parity hat einen sogenannten „20%-Zeit-Experiment" durchgeführt – im Grunde gaben sie einigen Engineers die Freiheit, auszuprobieren, ob selbst gehostete AI-Modelle für echte Development-Aufgaben funktionieren können. Was als Nachmittags-Test begann, zog sich über Wochen hin. 25 Engineers haben gemeinsam knapp 13 Milliarden Tokens durch ein selbst verwaltetes Inference-Setup verarbeitet.

Die Zahlen sind beeindruckend. In den ersten drei Tagen waren es über 3 Milliarden Tokens bei etwa 0,10 Dollar pro Million Tokens an GPU-Compute-Kosten. Über den gesamten Monat beliefen sich die Gesamtkosten auf rund 1.200 Dollar. Das ist nicht nichts – aber auch nicht das prohibitiv teure Unterfangen, das viele Teams vermuten, wenn sie „selbst gehostete AI" hören.

Die echten Kosten sind anders, als du denkst

Hier ist der Punkt, der mich am meisten überrascht hat: Die GPU-Compute-Kosten waren zwar real, aber tatsächlich der kleinere Posten. Die größere Investition war die Engineering-Zeit – das Aufsetzen der Infrastruktur, das Benchmarking der Performance und das Erlernen, wie man das System zuverlässig betreibt.

Das ist ein Muster, das ich bei Infrastruktur-Entscheidungen immer wieder sehe. Die direkten Kosten sind sichtbar und leicht zu budgetieren. Die versteckten Kosten sind die Zeit und Aufmerksamkeit, die dein Team für den Aufbau von Operations-Wissen rund um neue Systeme aufwendet. Die Wette des Parity-Teams ist, dass dieses Wissen sich potenziert – dass sie durch den Aufbau ihrer Infrastruktur, Benchmarks und Operations-Playbooks jetzt in Fähigkeiten investieren, die sich bei zukünftigen Workloads auszahlen.

Diese Denkweise dürfte jedem bekannt vorkommen, der Entscheidungen über Cloud-Hosting, Container-Orchestrierung oder verwaltete Datenbanken getroffen hat. Du wägst die betriebliche Komplexität gegen die Kontrolle, Kosteneinsparungen und strategische Flexibilität ab, die du gewinnst. Manchmal gewinnt die verwaltete Lösung. Manchmal macht es Sinn, den Stack selbst zu besitzen.

Was „einfache Architektur" tatsächlich bedeutet

Eine Sache, die ich an dem Parity-Artikel geschätzt habe, war, wie explizit sie ihre Architektur beschrieben haben. Sie betrieben keinen maßgeschneiderten, selbst gebauten Inference-Cluster. Ihr Stack war erfrischend straightforward:

Eine gemeinsame Interface-Schicht – sie nutzten LiteLLM – sitzt zwischen den Developer-Tools und den Modellen, die die Requests bearbeiten. Hinter dieser Schnittstelle kümmert sich vLLM um das Model Serving. Die GPU-Kapazität läuft auf gemieteter Infrastruktur bei einem Cloud-Anbieter. Das gesamte Setup ist bewusst so gestaltet, dass Engineers weiterhin ihre gewohnten Coding-Umgebungen und Clients nutzen können, während das Team Flexibilität behält, welche Modelle und Anbieter hinter dem gemeinsamen Endpunkt sitzen.

Das ist der entscheidende Punkt, den viele Teams übersehen, wenn sie selbst gehostete Optionen abtun: Du musst dich nicht zwischen Kontrolle und Bequemlichkeit entscheiden. Eine gut gestaltete Abstraktionsschicht bedeutet, dass deine Developer mit denselben Tools arbeiten wie immer. Der Unterschied ist, dass du entscheidest, welches Modell antwortet, welche Daten geloggt werden und wie die Kosten zugeordnet werden.

Denk an DNS-Management. Deine Developer müssen nicht die Feinheiten verstehen, wie DNS-Propagation funktioniert, um Domainnamen effektiv zu nutzen. Sie interagieren mit einer sauberen Oberfläche. Aber hinter dieser Oberfläche hat jemand bewusste Entscheidungen über Nameserver, TTLs und Redundanz getroffen. Dasselbe Prinzip gilt hier.

Was die Zahlen uns wirklich sagen

Die operationalen Daten aus Paritys Experiment sind da, wo es für Teams, die ähnliche Setups in Betracht ziehen, wirklich interessant wird. Sie haben Context-Lengths, Request-Parallelität, Throughput und Queue-Times über echte Development-Workflows hinweg getrackt.

Ein paar Zahlen, die herausstechen:

99 Prozent der Requests nutzten weniger als 500k Tokens Context. Mehr als die Hälfte der Zeit bediente das System genau einen concurrent Request. In der Spitze erreichten sie Prefill-Processing mit 168k Tokens pro Sekunde, mit einer Mean Time to First Token von rund 3,34 Sekunden.

Die Verteilung der Request-Formen erzählt eine wichtige Geschichte. Die meiste Zeit verarbeitet deine Inference-Infrastruktur relativ moderate, single-threaded Requests von Developern. Die parallelen Request-Szenarien, die dein Setup unter Stress setzen, sind die Ausnahme, nicht die Regel.

Das hat praktische Auswirkungen auf die Capacity Planning. Du musst nicht unbedingt für die Peak-Parallel-Last die meiste Zeit provisionieren. Ein gut gestaltetes System kann dynamisch skalieren und dabei die Baseline-Kosten vernünftig halten.

Die strategische Frage: Kontrolle gegen Bequemlichkeit

Hier liegt meiner Meinung nach der echte Wert in Experimenten wie diesem: Sie zeigen der Branche, was „AI Infrastructure Independence" in der Praxis tatsächlich bedeutet.

Wir befinden uns in einer interessanten Übergangsphase. AI-Coding-Tools werden essenziell dafür, wie Teams Software bauen, aber die Industrie findet noch heraus, was es bedeutet, diese Workloads verantwortungsvoll zu betreiben. Fragen zu Data Retention, Kosten-Vorhersagbarkeit, Modell-Verfügbarkeit und Vendor Lock-in sind allesamt berechtigte Bedenken, die Development-Teams langsam ernst nehmen.

Das Parity-Experiment zeigt, dass selbst gehostete Inference zugänglicher ist als viele annehmen. Du brauchst keine riesige Engineering-Organisation oder Custom-Hardware, um loszulegen. Du brauchst klare Anforderungen, eine sinnvolle Architektur und die Bereitschaft, in Operations-Wissen zu investieren.

Ob dieser Trade-off für dich sinnvoll ist, hängt komplett von deinem Kontext ab. Aber die Tatsache, dass es überhaupt eine realistische Option ist, lohnt sich zu verstehen – besonders wenn AI-Tools tiefer in das integriert werden, wie wir Software ausliefern.

Wo das in die Cloud-Hosting-Landschaft passt

Aus Cloud-Infrastruktur-Perspektive hat dieser Trend interessante Implikationen. Die Möglichkeit, GPU-Kapazität zu mieten, anstatt sie zu kaufen, senkt die Einstiegshürde erheblich. Du bekommst die betriebliche Flexibilität selbst gehosteter Infrastruktur, ohne die Kapitalausgaben für den Kauf von Hardware.

Das ist dieselbe Evolution, die wir in anderen Bereichen des Cloud Computings gesehen haben. Managed Services abstrahieren Komplexität weg – aber sie abstrahieren auch Kontrolle weg. Selbst gehostete Optionen auf Cloud-Infrastruktur geben dir mehr Kontrolle, ohne dass du physische Hardware bauen und warten musst.

Für Teams, die auf Plattformen wie Vibe Hosting aufbauen, stellt sich die Frage: Wie möchtet ihr AI-Fähigkeiten konsumieren? Bevorzugt ihr die Einfachheit vollständig verwalteter AI-Services? Oder schätzt ihr die Fähigkeit, Modelle zu tauschen, Kosten zu kontrollieren und genau zu verstehen, was unter der Haube passiert?

Die ehrliche Antwort für die meisten Teams heute ist wahrscheinlich ein Hybrid-Ansatz – verwaltete Services für einige Workloads, während man selbst gehostete Fähigkeiten für andere aufbaut. Der Schlüssel liegt darin zu verstehen, was du in jede Richtung aufgibst.

Das Fazit

Selbst gehostete AI für Software-Engineering ist kein theoretisches Gedankenspiel mehr und kein Ansatz, der großen Unternehmen mit dedizierten ML-Infrastrukturteams vorbehalten ist. Die Tools sind ausgereift, die Kosten sind gesunken und die operationalen Patterns werden klarer.

Ob du dich entscheidest, deine eigene Inference-Infrastruktur zu betreiben oder bei gehosteten Anbietern zu bleiben – die Trade-offs zu verstehen wird für Engineering-Leader essenzielles Wissen. Die Teams, die sich jetzt die Zeit nehmen, diese Lektionen zu lernen, werden besser positioniert sein, um Infrastruktur-Entscheidungen zu treffen, während sich AI-Tools weiterentwickeln.

Die Zukunft von AI in der Entwicklung geht nicht nur darum, welche Modelle du nutzt – es geht darum, wer den Stack kontrolliert, auf dem diese Modelle laufen. Und diese Frage verdient ernsthafte Überlegung von jedem Team, das seine Entwicklungsinfrastruktur ernst nimmt.

Welchen Ansatz verfolgt dein Team bei der AI-Infrastruktur? Setzt ihr vollständig auf gehostete Services, erkundet ihr selbst gehostete Optionen oder findet ihr ein Gleichgewicht zwischen beidem? Die Diskussion über AI Infrastructure Independence hat gerade erst begonnen.