Kategorie: Erklärer

Stell dir vor, du bist Detektiv, aber du darfst nur in einem Raum ermitteln. Du siehst Akten aus diesem Raum, hörst Zeugen aus diesem Raum – und ziehst deine Schlüsse. Was du nicht siehst: die Beweise im Nebenzimmer, die Protokolle im Keller, die Aussagen aus dem Nachbargebäude. Dein Urteil klingt trotzdem souverän, weil es auf dem basiert, was du hast. Nur: Es ist unvollständig. Genau das passiert, wenn wir KI-Agenten auf eine Datenplattform setzen, die nicht alle Quellen erreicht.

Vergangene Woche wurde bekannt, dass SAP Dremio übernimmt. Auf den ersten Blick wirkt das wie eine weitere Konsolidierung im Data-Engine-Markt. Genauer betrachtet zeigt sich: Die Ära der reinen Lakehouse-Engines ist mit dem Aufkommen von KI-Agenten vorbei. Wer nur im eigenen See fischt, wird für die neuen Workloads irrelevant.

Der Lakehouse-Kompromiss – und warum er für Analytics funktionierte

Um zu verstehen, was hier geschieht, müssen wir kurz ausholen. Ein Lakehouse ist im Kern ein Data Warehouse, das auf einem Data Lake aufsetzt. Die Idee: Statt Daten in teure, proprietäre Speicher zu kopieren, liegen sie in offenen Formaten wie Parquet auf einem Objektspeicher wie S3 oder ADLS. Eine Engine wie Dremio oder Trino (Presto) kann darauf direkt lesend zugreifen, optimiert durch Caching, Precomputing und intelligente Abfrageplanung. Für klassische Business Intelligence – Dashboards, Reports, feste Kennzahlen – war das ein Segen. Du materialisierst die häufigsten Abfragen als sogenannte „Reflections“ oder „Materialized Views“, planst nachts einen Refresh, und am Morgen läuft alles blitzschnell. Der Trade-off war klar: Du bringst die Daten in den See, baust dort dein Modell, und die Engine liefert Performance für die vorhersehbaren Fragen.

Dieses Modell hatte in den vergangenen Jahren enorme Erfolge. Viele Unternehmen haben ihre Data Warehouses abgelöst oder ergänzt. Die Kostenvorteile und die Flexibilität der offenen Formate waren überzeugend. Und für den Menschen, der einmal am Tag ein Dashboard öffnet, war die Latenz von Sekunden völlig ausreichend. Das Problem: KI-Agenten ticken fundamental anders.

Wie KI-Agenten das Modell zerbrechen

Ein KI-Agent ist kein menschlicher Analyst, der sich einen Kaffee holt, während ein Report rendert. Ein Agent ist eine automatisierte Einheit, die in Echtzeit Entscheidungen trifft – und dafür benötigt sie Zugriff auf das gesamte Datenökosystem, nicht nur auf einen vorbereiteten Ausschnitt. Der Artikel, den wir hier analysieren, macht einen entscheidenden Punkt: Die Reichweite einer Engine (Reach) ist keine Performance-Kennzahl mehr, sondern eine Vertrauenskennzahl.

Stell dir vor, ein Agent soll das Kündigungsrisiko eines Kunden bewerten. Er hat Zugriff auf das CRM, aber nicht auf das Ticketsystem. Er sieht: Der Kunde hat seit drei Monaten nichts gekauft. Er schlussfolgert: hohes Risiko. Was er nicht sieht: Der Kunde hat gestern einen Premium-Support-Fall eröffnet, der auf eine bevorstehende Verlängerung hindeutet. Der Agent liefert eine Antwort – aber sie ist nicht nur unvollständig, sie ist zuversichtlich falsch. Und anders als ein Mensch hat der Agent kein Bauchgefühl, das ihm sagt: „Moment, hier fehlt was.“ Er gibt die Antwort mit derselben Sicherheit, als hätte er alle Systeme abgefragt. Das ist ein gefährlicherer Fehlermodus als jede Latenz. Latenz sagt dir: Irgendwo hakt es. Eine zuversichtliche Fehlantwort tut das nicht.

Hinzu kommt ein zweites, subtileres Problem: die Unvorhersagbarkeit von Agenten-Workloads. Ein Dashboard fragt immer dieselben Dinge ab: „Umsatz letzte Woche“, „Top 10 Produkte“. Du kannst diese Abfragen vorberechnen. Ein Agent dagegen generiert seine Abfragen dynamisch. Er startet mit einer Frage, bekommt eine Antwort, und leitet daraus die nächste Frage ab – die du nie vorhergesehen hast. Du kannst keine Materialized Views bauen für Fragen, die erst fünf Sekunden vor Ausführung entstehen. Eine Engine, die auf Precomputing angewiesen ist, wird mit einem Agenten, der zur Laufzeit neue Pfade erkundet, strukturell nie mithalten können, egal wie gut sie optimiert ist.

Was KI wirklich von einer Datenplattform fordert

Aus diesen Beobachtungen leitet der Autor eine klare Anforderungsliste ab, die nichts mit Markennamen zu tun hat, sondern mit Architekturentscheidungen. Lass uns diese Anforderungen durchgehen, denn sie sind der Maßstab, an dem sich jede Plattform messen lassen muss.

Erstens: Reichweite muss nahezu vollständig sein. Nicht „die meisten unserer Daten“, sondern alle relevanten Quellen – relationale Datenbanken, Data Warehouses, Objektspeicher, SaaS-Systeme. Ein System, das ein Agent nicht erreicht, ist nicht etwa eine Lücke, die er umsichtig umgeht. Es ist eine stille Wissenslücke, die weder du noch der Agent bemerken, bis die falsche Entscheidung getroffen ist.

Zweitens: Parallelität muss skalieren, als wären tausend Analysten gleichzeitig am Werk. Ein Mensch öffnet ein Dashboard. Ein Agentenfleet feuert Dutzende parallele Abfragen ab – und die Plattform muss unter dieser Last genauso schnell sein wie im Leerlauf. Eine Engine, die für einen Benutzer schnell ist, aber unter realer Last einbricht, wird genau dann langsamer, wenn es am kritischsten ist.

Drittens: Kontext muss begrenzt und relevant sein. Ein Agent bekommt nicht das gesamte Schema einer Datenbank oder einen ganzen Dokumenten-Pool – das würde seinen Kontext aufblähen mit Rauschen und zu Fehlschlüssen führen. Stattdessen braucht er den spezifischen Ausschnitt: die richtigen Tabellen, die richtigen Spalten, die passenden Business-Definitionen, zugeschnitten auf die aktuelle Frage.

Viertens: Aktualität muss strukturell sein, nicht geplant. Die Frage eines Agenten entsteht 90 Sekunden vor der Antwort. Er braucht Daten von diesem Moment, nicht vom letzten nächtlichen Refresh. Die Frage „Wie aktuell darf es sein?“ war früher eine Business-Entscheidung. Für viele agentische Anwendungen liegt die Antwort heute bei null Sekunden.

Fünftens: Governance muss mit den Daten reisen, nicht daneben sitzen. Wenn zwei Agenten auf unterschiedliche Systeme zugreifen, die unterschiedliche Geschäftslogik anwenden, und sie kommen zu widersprüchlichen Ergebnissen – dann ist das nicht nur eine kleine Inkonsistenz. Es untergräbt das Vertrauen in den gesamten KI-Ansatz. Governance muss zur Abfragezeit durchgesetzt werden, nicht nachträglich.

Was das für die Branche bedeutet

Keine dieser Anforderungen ist neu, aber zusammen ergeben sie ein Profil, das reine Lakehouse-Engines strukturell nicht erfüllen können. Dremio ist kein Einzelfall – es steht exemplarisch für eine ganze Kategorie von Anbietern, die auf „Bring your data to the lake“ gesetzt haben. Der Verkauf an SAP ist der deutlichste Hinweis darauf, dass dieser Ansatz an seine Grenzen stößt.

Der Autor des zugrundeliegenden Artikels argumentiert, dass die Lösung in einer föderierten Architektur liegt: Daten dort lassen, wo sie sind, und über eine Engine abfragen, die alle Quellen gleichzeitig erreicht, ohne sie vorher zu bewegen. Das ist die Design-Philosophie hinter Starburst (dem Unternehmen, für das der Autor arbeitet) – aber es ist auch eine logische Schlussfolgerung aus den Anforderungen, die KI mitbringt. Ob man Starburst mag oder nicht: Die Fragen, die im Raum stehen, sind systemunabhängig. Kann meine Plattform alles erreichen, was meine Agenten brauchen? Hält sie unter der Last stand, die Agenten erzeugen? Kann sie Fragen beantworten, die vor fünf Sekunden noch nicht existierten?

Wenn ein Anbieter auf diese Fragen mit „arbeiten wir dran“ antwortet, ist das ehrlich. Aber dann solltest du sicherstellen, dass du die Fragen stellst, bevor du dich bindest – nicht hinterher, wenn der Agent bereits falsche Entscheidungen trifft.

Dremios Verkauf ist ein Datenpunkt. Er ist nicht die Geschichte selbst, sondern der Moment, in dem eine Verschiebung für einen Anbieter sichtbar wurde. Die Verschiebung ist größer und wird nicht mit einer Übernahme enden. Wer KI ernsthaft einsetzen will, muss Datenplattformen so bauen, dass sie dem Denken von Agenten folgen – nicht umgekehrt. Das ist kein Feature-Wettbewerb mehr. Es ist die neue Grundlage für Vertrauen in automatisierte Entscheidungen.

Quelle: starburst.io

Du gehst in eine Bäckerei, die ihr bestes Brot kostenlos auf die Straße stellt. Jeder bedient sich, ohne zu bezahlen. Gleichzeitig verdient die Bäckerei Millionen – mit Kaffee, Butter und dem Wissen, wie man Teigführung optimiert. Klingt widersprüchlich? Genau das tut das chinesische KI-Startup Z.ai (früher Zhipu). Laut Bloomberg ist das Unternehmen auf dem Weg, als erster unabhängiger chinesischer KI-Anbieter eine Milliarde Jahresumsatz zu knacken – und verschenkt seine leistungsfähigsten Modelle. Wie funktioniert das? Was sagt das über den Wettbewerb zwischen Ost und West?

Die Zahlen hinter dem Aufstieg

Die Nachricht kombiniert eine beeindruckende Zahl mit einer wichtigen Einschränkung. Z.ai erzielte 2025 einen Umsatz von umgerechnet 724 Millionen Yuan (etwa 100 Millionen Dollar) – ein Plus von 132 Prozent zum Vorjahr. Darauf basiert die Prognose: JPMorgan erwartet für 2026 rund 4,6 Milliarden Yuan, für 2028 dann 30,9 Milliarden Yuan – dann soll das Unternehmen profitabel sein. Die Milliardengrenze, von der Bloomberg spricht, ist vorsichtig: Sie stützt sich teilweise auf annualisierte wiederkehrende Umsätze, also eine Hochrechnung. Auch JPMorgans Schätzung für 2026 liegt in Dollar unter der Milliardenschwelle. Der Trend ist real.

Wie verdient Z.ai sein Geld? Der Mix ist stark unternehmensorientiert. Ein großer Teil stammt aus lokalen Installationen für Staatsbetriebe und Finanzinstitute – Modelle, die direkt auf den Servern der Kunden laufen. Dazu kommt ein schnell wachsendes Cloud-Geschäft. Die API-Sparte ist der Wachstumstreiber: Die annualisierten wiederkehrenden Einnahmen von der offenen Plattform liegen bei 1,7 Milliarden Yuan – ein Sechzigfaches innerhalb eines Jahres. Das klingt nach einem klassischen Plattform-Geschäftsmodell: Einmal aufgesetzt, skalieren die Einnahmen mit der Nutzung.

Warum das Verschenken funktioniert

Doch hier liegt der scheinbare Widerspruch: Z.ai gibt seine leistungsstärksten Modelle, darunter GLM-5.2, als Open Source frei. Jeder kann sie herunterladen und kostenlos nutzen. Das ist, als würde ein Autohersteller sein neuestes Elektroauto mit den Plänen im Internet veröffentlichen – und trotzdem Geld verdienen. In westlicher Logik müsste das die Monetarisierung zerstören. Z.ai setzt auf den gegenteiligen Effekt: Kostenlose Modelle treiben die Verbreitung voran. Wer die Software kennt, kauft die dazugehörige Cloud-Infrastruktur, bezahlt für Support oder bestellt eine maßgeschneiderte On-Premise-Lösung. Es ist das alte Modell „Rasiermesser verschenken, Klingen verkaufen“ – nur dass die Rasiermesser hier KI-Modelle mit Milliarden Parametern sind.

Gründer Tang Jie hat diese Philosophie öffentlich verteidigt. KI sollte der Menschheit gehören, nicht hinter Bezahlschranken verschwinden. Klingt idealistisch? Vielleicht. Aber die Umsatzzahlen liefern die kommerzielle Bestätigung. In China scheint das zu funktionieren, während westliche Labore wie OpenAI oder Google mit enormen Verlusten kämpfen. Im Westen ist das dominante Modell: teure Modelle über APIs verkaufen, leistungsschwächere Versionen sind kostenlos. Z.ai dreht den Spieß um: Die besten Modelle sind frei, die Bezahlung kommt aus dem Ökosystem drumherum.

Das führt zu einer grundsätzlichen Frage: Was ist ein „KI-Modell“? Stell dir ein großes Modell wie GLM-5.2 als eine Art superschnelles Gehirn vor, das aus Milliarden Beispielen gelernt hat, Texte zu verstehen und zu generieren. Dieses Gehirn kann man als Datei herunterladen – ähnlich wie ein Buch. Um es zu nutzen, braucht man einen leistungsstarken Computer, Speicherplatz, Daten und oft Hilfe bei der Anpassung. Genau das bietet Z.ai an: die Dienstleistung, das Modell für dich zu hosten, zu warten und zu optimieren. So wie ein Buch kostenlos im Internet stehen kann, während du für die Einführung in den Stoff bezahlst.

Haken und Risiken der Prognose

Die Zahlen von Z.ai sind beeindruckend, aber nicht ohne Haken. Die Milliardengrenze bleibt eine Prognose, und Prognosen in der KI-Welt haben eine kurze Haltbarkeit. Das Unternehmen macht immer noch Verluste – die Ausgaben steigen schneller als die Einnahmen. Ein großer Teil der Kunden sind staatliche Unternehmen, was die Grenze zwischen kommerzieller Nachfrage und politischer Unterstützung verschwimmen lässt. Die Bewertung liegt bei rund 112 Milliarden Dollar, nach einem Kursanstieg von über 1.000 Prozent seit dem Börsengang im Januar. Das ist viel Vertrauen in die Zukunft. Z.ai hat bereits Milliarden durch eine weitere Aktienplatzierung eingesammelt – der Preis spiegelt die Erwartung wider, dass die Prognosen wahr werden, nicht die aktuelle Realität.

Hinzu kommt der brutale Wettbewerb auf dem chinesischen Markt. Chinesische Modelle unterbieten sich gegenseitig bei den Preisen – auch die US-Labore müssen mitziehen. Die Margen sind knapp. Eine Milliarde Umsatz zu erreichen ist das eine, daraus Profit zu schlagen ein anderes. Aber genau das macht die Geschichte von Z.ai interessant: Sie zeigt, dass chinesische KI-Unternehmen nicht nur technisch aufholen, sondern gelernt haben, Technologie in Umsatz umzuwandeln. Die oft beschriebene „chinesische Art der Kommerzialisierung“ – schnell skalieren, effizient monetarisieren trotz niedriger Preise – findet hier ihre Anwendung auf große Sprachmodelle.

Die Lektion für den Westen

Für Beobachter bedeutet das: Der Wettlauf der KI-Supermächte wird nicht allein durch Rechenleistung oder Forschungserfolge entschieden. Es geht auch um Geschäftsmodelle. Z.ai zeigt, dass Open Source kein Hindernis für kommerziellen Erfolg sein muss. Im Gegenteil: Es kann der Hebel sein, der die Adoption so stark beschleunigt, dass die Nebeneinnahmen alles andere übertreffen. Vielleicht ist das die Lektion, die westliche Unternehmen lernen müssen: Nicht zu fragen, wie viel man für ein Modell verlangen kann, sondern wie man diejenigen bezahlt bekommt, die es nutzen – auch wenn das Modell selbst gratis ist.

Die nächsten Jahre werden zeigen, ob Z.ai die Profitabilität erreicht. Der Pfad ist vorgezeichnet: wachsende Cloud-Umsätze, steigende Zahl von Enterprise-Kunden, eine Community, die die Modelle weiterentwickelt. Die Gefahr lauert im Preisverfall: Wenn alle Modelle ähnlich gut sind und gratis, wird der Wettbewerb zum reinen Preiskampf auf den Dienstleistungen. Dann zählt nicht die Technologie allein, sondern die Servicequalität, die Kundenbindung und die Fähigkeit, das Ökosystem zu managen. Genau das ist die Herausforderung für Z.ai.

Bis dahin bleibt eine Erkenntnis: Die Idee, dass man sein bestes Produkt verschenken muss, um Geld zu verdienen, ist nicht neu. Z.ai zeigt, dass sie auch in der Welt der künstlichen Intelligenz funktioniert. Das reicht über China hinaus. Denn am Ende geht es nicht darum, ob KI teuer oder billig ist. Sondern darum, wie wir sie nutzbar machen – ohne den Zugang zu beschränken. Vielleicht ist das der Schlüssel zu einer KI, die allen dient.

Quelle: thenextweb.com

Ein Unternehmen kauft teure Grafikprozessoren, um damit bereits trainierte KI-Modelle auszuführen – Inference-Aufgaben. GPUs sind für das Training optimiert, einer rechenintensiven Phase, die hohe Parallelleistung braucht. Für die Inference zählen Effizienz und niedrige Betriebskosten, nicht maximale Rohleistung. Das Startup General Compute hat jetzt einen 400-Millionen-Dollar-Kredit von der Investmentfirma Upper90 erhalten – besichert durch spezialisierte Inference-Chips. Es könnte der erste Kredit dieser Art sein.

Das Geschäftsmodell von General Compute

General Compute wurde von CEO Finn Puklowski und CTO Jason Goodison gegründet. Im Mai startete es mit einer 15-Millionen-Dollar-Startkapitalrunde. Das Unternehmen baut eine Neocloud – eine Cloud speziell für KI-Workloads, anders als die Infrastruktur von AWS oder Azure. Die Basis bilden SN50-Chips von SambaNova, unterstützt von Intel. Diese Chips sind für Inference entwickelt: stromsparend, keine teuren Wasserkühlungen, flexibler einsetzbar als GPUs. General Compute verspricht eine 16-mal schnellere Inference als vergleichbare GPU-Clouds.

Wie kommt ein neues Unternehmen an genug dieser Chips? Upper90 hilft. Mitgründer und CEO Billy Libby, ehemaliger quantitativer Trader bei Goldman Sachs, erprobte diesen Ansatz 2021. Damals vergab Upper90 einen Kredit an das Startup Crusoe – besichert durch GPUs. Es war der erste Kredit, der den Wert fortschrittlicher Chips als Sicherheit nutzte. Traditionelle Banken mieden solche Deals wegen der Unsicherheit über GPU-Werte. Nachdem CoreWeave chip-besicherte Kredite zu einem Geschäftsmodell und später zu einem Börsengang machte, ist diese Finanzierungsform heute üblich.

Chips als neue Kreditsicherheit

„Als wir als erste Gruppe Nvidia-GPUs finanziert haben, war der Markt ineffizient“, sagte Libby. „Wir konnten als frühe Teilnehmer etwas aufbauen und für das Risiko entschädigt werden.“ GPUs sind heute gut verstanden, vielleicht überkauft. Upper90 richtet den Blick auf Inference-Chips. „Wir glauben, dass Open-Source-Modelle wichtig werden. Wir suchten nach einem Player im Inference-Bereich. Nicht jeder braucht einen Supercomputer, aber jeder braucht Inference und KI.“

Diese These gewinnt an Fahrt. Unternehmen wie OpenRouter und Fireworks erzielten hohe Bewertungen. Neue Modelle wie Kimis K3 zeigen in Codierungs-Benchmarks, dass sie mit Anthropic und OpenAI mithalten können. Chip-Hersteller wie Groq und Cerebras ziehen Interesse auf sich. General Computes Zugang zu Chips außerhalb des Nvidia-Ökosystems ist bedeutsam. TensorWave, ein weiteres KI-Infrastruktur-Unternehmen, setzt mit AMD auf eine ähnliche Strategie.

Inference wird zum Massengeschäft

„Es gibt Chips, die skalieren und eine bessere Gesamtbetriebskosten oder höhere Geschwindigkeit als Nvidia bieten – aber noch wenige Abnehmer“, sagte Puklowski. „Durch die Zusammenarbeit mit Upper90 geht es nicht nur um ein Startup, das Geld für Rechenleistung bekommt. Das ist das erste Signal: Kapital organisiert sich, Nvidias Monopolstellung bröckelt.“

Der 400-Millionen-Dollar-Kredit von Upper90 an General Compute ist mehr als eine Finanzierungsrunde. Er zeigt, wohin die Reise in der KI-Infrastruktur geht. Das Training großer Modelle erfordert teure GPUs. Die Ausführung dieser Modelle – Inference – wird zum Massengeschäft. Kosten pro Anfrage, Energieeffizienz und Skalierbarkeit zählen. Spezialisierte Inference-Chips wie der SambaNova SN50 bieten einen Vorteil, vor allem kombiniert mit Open-Source-Modellen ohne Lizenzgebühren. Die Finanzierung auf Basis dieser Chips zeigt: Der Markt investiert in diese Richtung, GPU-Finanzierer positionieren sich neu.

Die Analogie zum Supersportwagen und zum Kleinwagen passt. Für das Training braucht es die Kraft eines Supersportwagens – GPUs für tausende parallele Berechnungen. Für die alltägliche Nutzung reicht ein sparsamer Kleinwagen. Diese Alltagstauglichkeit wird den Großteil der KI-Kosten ausmachen. Unternehmen, die früh gehen, sichern sich einen Vorteil.

Offene Fragen und Risiken

Skepsis bleibt angebracht. Die Behauptung von General Compute, eine 16-mal schnellere Inference zu bieten, muss sich im Praxiseinsatz beweisen. Die Skalierbarkeit der SambaNova-Chips ist nicht im großen Maßstab erprobt. Upper90 geht ein Risiko ein. Sollte der Markt langsamer wachsen, könnten die Sicherheiten an Wert verlieren. Genau dieses Risiko bestand auch bei GPU-Krediten – und sie wurden zur Goldgrube.

Für Entwickler bedeutet dieser Deal: Günstigere Inference-Dienste könnten bald verfügbar sein. Open-Source-Modelle wie Llama 3 oder Mistral lassen sich zu einem Bruchteil der Kosten betreiben. Das senkt die Hürde für KI-Startups und ermöglicht neue Geschäftsmodelle. Rechenzentren können flexibler auf verschiedene Chip-Architekturen setzen, statt an Nvidia gebunden zu sein. Für die Chip-Industrie ist es ein Signal: Der Kampf um den Inference-Markt beginnt.

Bleibt die Frage, ob dieser Deal den Wendepunkt markiert oder eine Randnotiz bleibt. GPU-Finanzierung belohnte frühe Moves. Crusoe bekam 2021 seinen GPU-Kredit, viele zweifelten. Heute ist Crusoe ein Milliardenunternehmen. General Compute und Upper90 setzen auf die gleiche Dynamik – mit einer neuen Chip-Generation. Die kommenden Monate zeigen, ob die Rechnung aufgeht. Klar ist: Die Dominanz von Nvidia bekommt Risse, Kapital strömt in die Lücken.

Quelle: techcrunch.com

Netflix betreibt Large Language Models in eigener Infrastruktur, nicht über externe APIs. Die Integration erfolgt tief in die bestehende Produktionsumgebung. Kein separater ML-Silo, sondern eine durchgängige Einbettung.

Der Netflix Technology Blog beschreibt vier Design-Entscheidungen: Wahl der Inference-Engine, Verpackung der Modelle, Gestaltung der API-Oberfläche und Deployment-Strategie. Jede baut auf der vorherigen auf. In der Theorie klar, zeigten sich unter Produktionslast unerwartete Nebenwirkungen.

Die Architektur im Überblick

Netflix betreibt ein einheitliches JVM-basiertes Serving-System für Routing, A/B-Tests, Candidate Generation, Feature Fetching, Inferenz, Post-Processing und Logging. Es gibt einen Echtzeit-Pfad (gRPC) und einen Batch-Pfad (HTTP). Kleine CPU-Modelle laufen direkt im Prozess des Serving-Systems – das spart Remote-Call-Overhead. Größere Modelle benötigen GPUs. Das Serving-System übernimmt Vor- und Nachbereitung, delegiert die Inferenz an den Model Scoring Service (MSS). MSS ist der gemeinsame Inference-Backend für XGBoost, TensorFlow, PyTorch und LLMs. Darunter liegt NVIDIA Triton Inference Server für Modell-Loading, Batching und GPU-Scheduling. Darüber ein Java-Control-Plane für Deployment, Versioning, Health Checks, Autoscaling und Multi-Region-Rollout. Modellautoren packen Artefakte und konfigurieren das Deployment; das Control Plane stellt GPU-Instanzen bereit, konfiguriert Triton und orchestriert Zero-Downtime-Upgrades.

Engine-Wahl: Warum vLLM der Standard wurde

Ursprünglich setzte Netflix auf TensorRT-LLM. Leistungsfähig, in Triton integriert. Bis Sommer 2025 hatten Open-Source-Engines den Performance-Vorsprung spezialisierter Stacks weitgehend aufgeholt. Der Workload-Mix wurde vielfältiger – Embedding-Generierung, Prefill-only-Inferenz für Ranking und Retrieval, autoregressives Decoding und kundenspezifische Modelle mit komplexer Constraint-Logik. Netflix benchmarkte erneut und wählte vLLM aus operativen Gründen: vLLM lädt benutzerdefinierte Modellarchitekturen ohne mehrstufige Compilation-Pipeline – das beschleunigt Iterationen bei nicht-standardisierten Modellen. Es bietet Erweiterungshooks für eigene Decoding-Logik, die für das spätere Constrained Decoding entscheidend sind. Die Debugbarkeit ist besser als bei einem kompilierten Engine wie TensorRT-LLM, weil Fehler und Zwischenzustände leichter inspizierbar sind. Viele ML-Praktiker nutzen vLLM bereits in der Forschung, was den Übergang zur Produktion vereinfacht.

Integration von vLLM in Triton: Zwei Wege, eine Entscheidung

Nach der Engine-Wahl musste Netflix entscheiden, wie die Modelle für vLLM verpackt werden. Triton unterstützt zwei Backends. Das Python-Backend erfordert, dass der Autor explizite Input/Output-Tensor-Spezifikationen zur Packzeit definiert. Diese Spezifikationen werden im Artefakt eingefroren und müssen mit dem Request-Builder des Frontends übereinstimmen. Jedes Frontend-Update, das I/O-Spezifikationen ändert, erfordert eine koordinierte Änderung des Verpackungscodes. Das vLLM-Backend erwartet nur eine JSON-Config, die auf Modellgewichte und Tokenizer verweist. Tritons vLLM-Backend generiert I/O-Tensor-Spezifikationen dynamisch zur Deployment-Zeit – der Autor definiert sie nie. Modelle und Frontend entwickeln sich unabhängig voneinander. Für Netflix ist das vLLM-Backend der architektonisch korrekte Standard. Zwei Probleme traten in der Produktion auf: Triton/vLLM-Versionsinkompatibilitäten (Tritons vLLM-Backend ist gegen eine spezifische vLLM-API-Version kompiliert) und benutzerdefinierte Modelllogik, die das Python-Backend erfordert, wenn das Modell nicht standardkonform ist. Dieser Escape-Hatch wird wohl für eine Teilmenge der Modelle nötig bleiben.

API-Design: OpenAI-kompatibel als zweite Front

Jedes Modell – XGBoost-Ensemble oder großes LLM – wird über denselben gRPC-Aufruf gescort. Das ermöglicht Wiederverwendung von Client-Bibliotheken, Health Checking und Deployment-Pipelines. Die OpenAI-kompatible API ist inzwischen der De-facto-Standard für das LLM-Ökosystem. Inference-Engines, Orchestrierungs-Frameworks, Evaluierungstools und Client-Bibliotheken sprechen sie alle. Netflix entschied sich, diese API als zusätzliches Frontend neben gRPC anzubieten. Der Vorteil: Der Weg von der Experimentierphase zur Produktion – von einem gehosteten Modell zu einem feinabgestimmten, selbst gehosteten – wird nahezu nahtlos. Gleiche API, minimale Code-Änderungen. Hinter der API nutzt Netflix das Triton OpenAI-kompatible Frontend von NVIDIA. Es startet einen eingebetteten Triton-Server, wickelt Requests in Triton-Inferenz-Requests um und liefert Antworten über FastAPI. Zusätzlich sind KServe-HTTP/gRPC-Frontends aktiv, sodass dieselbe Triton-Instanz auch über gRPC erreichbar bleibt. Eine Lücke zeigte sich: Das response_format-Feld wurde stillschweigend verworfen, bevor es vLLM erreichte. Ein Caller, der JSON-Output anforderte, bekam keine Guided-Decoding-Constraints – und konnte malformed JSON erhalten, ohne dass die Plattform einen Fehler meldete. Netflix patchte das Frontend, um response_format in vLLMs Guided-Decoding-Parameter zu übersetzen.

Deployment-Strategien: Rot-Schwarz oder Versioniert

GPU-Deployments brauchen länger zum Hochfahren als CPU-Dienste. Das I/O-Schema kann sich zwischen Modellversionen ändern – ein Koordinationsproblem. Netflix bietet zwei Strategien an. Red-Black deployt die neue Version neben der aktuellen. Wenn die neue Instanz die Health Checks besteht, wird der Traffic phasenweise umgeschaltet – die neue skaliert hoch, die alte herunter. Bei Fehlern erfolgt ein atomarer Rollback. Red-Black ist die richtige Wahl bei stabilem Modell-Interface. In der Praxis zeigte sich eine Koordinationslücke: Wenn eine neue Version ein I/O-Schema-Update erfordert (z.B. neue Tensor-Dimensionen), kann der Upstream-Consumer seine Konfiguration erst aktualisieren, wenn das neue Modell vollständig live ist. Während des Migrationsfensters sendet er „alte“ Requests an das „neue“ Deployment – die schlagen fehl. Versioned schließt diese Lücke, indem es für jedes (modelId, modelVersion)-Paar ein unabhängiges Deployment unterhält. Mehrere Versionen laufen gleichzeitig, was Modell-Deployment von Consumer-Updates entkoppelt: Der Consumer wartet, bis die neue Version bereit ist, dann schaltet er um. Die alte Version bedient solange Legacy-Traffic. Das erhöht temporär die GPU-Kosten. Netflix empfiehlt, variable Konfigurationen (z.B. Tensor-Shapes) direkt in das Inferenz-Modell einzubetten, um es versionsagnostisch zu machen, sodass der günstigere Red-Black-Pfad genutzt werden kann. Versioned bleibt seltenen Fällen mit breaking changes vorbehalten.

Operative Details: Boot-Sequenz und Metriken

Zwei operative Details verdienen besondere Aufmerksamkeit. Erstens die Boot-Sequenz: Das Herunterladen großer LLMs von S3 oder Hugging Face beim Start ist zu langsam – es übersteigt die Cold-Start-Latenz, die Scheduler tolerieren. Netflix materialisiert die Modelle auf Amazon FSx zum Zeitpunkt der Modell-Ankündigung, sodass Warm-Starts auf ein High-Performance-Dateisystem zugreifen. Wenn Consumer die OpenAI-kompatible API benötigen, läuft Triton als eingebetteter Server im OpenAI-Frontend-Prozess; sonst eigenständig. Der Rest der Boot-Sequenz ist mechanisch: Paket extrahieren, benutzerdefinierte vLLM-Plugins installieren, Prometheus-Multiprocess-Verzeichnis bereinigen und gRPC-Port erst öffnen, wenn die Engine bereit ist.

Zweitens die Metriken: vLLM schreibt Metriken in PROMETHEUS_MULTIPROC_DIR als .db-Dateien; Triton meldet Server-Metriken über einen eigenen Prometheus-Endpunkt. Keiner weiß vom anderen. Tritons eingebaute Brücke liefert nur 9 von über 40 vLLM-Metriken – wichtige wie Token-Durchsatz, KV-Cache-Auslastung und Prefix-Cache-Trefferquote fehlen. Netflix baute einen leichten HTTP-Proxy, der beide in einem einzigen /metrics-Endpunkt zusammenführt: Er holt Triton-Metriken über HTTP, liest vLLM-Metriken von der Festplatte mit Prometheus’ MultiProcessCollector und gibt die kombinierte Ausgabe zurück. Bestehende Dashboards und Alarme funktionieren ohne Änderung.

Constrained Decoding im Produktionsmaßstab

Einige Netflix-Produktionsworkloads erfordern fein granulare Kontrolle über die Token-Generierung. Statt Geschäftslogik nach der Inferenz anzuwenden – ungültige Generierungen bezahlen und dann wiederholen oder reparieren – schiebt Netflix die Constraints in die Decode-Schleife. Das Modell erzeugt Ausgaben, die von Natur aus konform sind. Umsetzung erfolgt über vLLMs Custom-Logits-Processor-Schnittstelle: Jede Constraint wird als Zustandsmaschine modelliert, die sich mit der generierten Token-Historie entwickelt und bei jedem Schritt Token-Eligibility-Masken ausgibt. Jeder Request bekommt seinen eigenen konfigurierten Processor, da verschiedene Requests unterschiedliche Regeln haben.

Die Skalierung dieser Constraint-Logik war eine Herausforderung. In der ersten Implementierung auf vLLM V0 lief die Logit-Processing pro Request – der GPU produziert Logits für den gesamten Batch, die CPU kopiert sie rüber und wartet auf den Transfer, dann läuft die Constraint-Logik sequenziell für jeden Request – sequenziell, weil die GIL Python daran hindert, die Arbeit pro Request zu parallelisieren. CPU-Zeit im Logit-Processing wurde zum Flaschenhals. Netflix migrierte später auf vLLM V1, das diese Einschränkung adressiert. Die Details der V1-Architektur und wie sie das Problem löst, sind im Originalblog nachzulesen – aber die Lektion ist klar: Nicht jeder Algorithmus, der funktioniert, skaliert auch linear. Besonders bei LLMs müssen Engine und Decoding-Logik aufeinander abgestimmt sein.

Was bedeutet das konkret?

Netflix zeigt, dass die Kontrolle über die gesamte LLM-Infrastruktur Vorteile bringt – wenn man bereit ist, in die Tiefe zu gehen. Die Entscheidungen sind nicht trivial, und unter Produktionslast tauchen immer wieder unerwartete Details auf. Der Vorteil ist eine Architektur, die nicht an die Grenzen eines Drittanbieters gebunden ist. Entwickler und Architekten können diese Erkenntnisse nutzen, auch wenn sie nicht im Netflix-Maßstab denken. Die Lektionen sind universell: Wähle eine Engine, die zu deinem Workload-Mix passt – nicht nur nach Benchmark-Zahlen. Setze auf standardisierte APIs, um den Ökosystem-Zugang zu öffnen. Baue Deployment-Strategien, die Schemamigrationen einkalkulieren. Teste die Skalierung von Constraints in der Decode-Schleife unter realistischer Last. Die Frage ist nicht, ob eigene LLMs betrieben werden sollten, sondern wie tief die Detailarbeit gehen muss. Netflix hat den Weg gezeigt.

Quelle: netflixtechblog.com

Eine Fabrik umzurüsten, während die Produktion läuft – so ähnlich fühlt es sich an, Code von einer Programmiersprache in eine andere zu übersetzen. Manuelles Vorgehen ist zeitaufwendig und fehleranfällig. Anthropic, das Unternehmen hinter dem KI-Assistenten Claude, setzt auf einen systematischen Prozess, der große Sprachmodelle mit Prüfmechanismen verbindet. Dieser Beitrag beschreibt, wie Anthropic solche Migrationen plant und umsetzt.

Der Ausgangspunkt jeder Migration ist nicht der erste Code, sondern ein verlässlicher Richter. Ohne ein klares Kriterium für den Erfolg tappt man im Dunkeln. Dieser Richter – „Judge“ genannt – muss alten und neuen Code nach denselben Maßstäben bewerten. Das klingt einfacher, als es ist: Testsuiten für die ursprüngliche Sprache greifen oft auf interne Funktionen zurück, die es in der Zielsprache nicht gibt. Anthropic löst das, indem es bestehende Tests kategorisiert: Welche lassen sich als externe Aufrufe formulieren? Welche hängen von Interna ab, die nicht portiert werden? Aus den brauchbaren Tests werden portable Assertions gebaut – Prüfungen, die gegen beide Versionen laufen. Und damit diese Prüfungen nicht schwächer werden, setzt man gegnerische KI-Agenten ein, die versuchen, die neuen Tests zu umgehen. Ein guter Judge besteht nicht nur den Originalcode, sondern fällt auch gezielt durch, wenn man manipulierten Code einschleust.

Ein konkretes Beispiel: Mike, ein Entwickler bei Anthropic, portierte einen Python-Code nach TypeScript. Da die vorhandenen Tests nicht einfach übertragbar waren, baute er ein kleines „Parity-Harness“ aus sieben realen Szenarien. Jede Abweichung im Verhalten galt als Bug. Das zeigt: Ein Judge muss nicht riesig sein, sondern treffsicher.

Der Sechs-Schritte-Plan: Vom Regelbuch zur finalen Prüfung

Anthropic hat den Prozess in sechs Schritte gegliedert, die auf zwei großen Migrationen basieren: Jarreds Portierung von Zig nach Rust (über 1.400 Dateien) und Mikes Python-zu-TypeScript-Übersetzung. Die Abläufe sind generalisiert, die Prinzipien gelten sprachübergreifend.

Schritt 1: Fundament legen – Regelbuch, Abhängigkeitskarte und Lückeninventar

Bevor eine Zeile Code geschrieben wird, entsteht ein Regelwerk. Es legt fest, wie die Übersetzung ablaufen soll. Es gibt zwei Szenarien: Entweder die neue Codebasis folgt derselben Struktur wie die alte (dann ist das Regelbuch eine Übersetzungstabelle für Typen und Idiome), oder sie wird komplett neu designt (dann ist es ein Architekturdokument). Jarred erstellte sein Regelbuch, indem er mit Claude diskutierte und für jede Unklarheit eine Policy formulierte. Acht spezialisierte Unteragenten prüften das Regelbuch auf typische Fehlermuster – basierend auf Jarreds eigener Erfahrung.

Parallel entsteht eine Abhängigkeitskarte. Denn wenn man mehrere Dateien parallel migriert, muss man wissen, welche Dateien zuerst kommen müssen. Für moderne Sprachen gibt es oft Manifestdateien, aber bei Legacy-Codebasen oder Sprachen wie C/C++ und Python müssen die Abhängigkeiten erst ermittelt werden. Claude Code kann hier Agenten losschicken, die ein deterministisches Skript schreiben und ausführen, um die Karte zu erstellen.

Zum Fundament gehört auch das Lückeninventar: Welche Konzepte der alten Sprache haben in der neuen keine direkte Entsprechung? Beispiel: Python verlangt keine Verträge über die Form von Objekten oder Rückgabewerten, TypeScript schon. Solche impliziten Annahmen müssen erfasst werden. Jarred inventarisierte die Lücken vor der Übersetzung, Mike übersetzte erst und auditierte dann. Beide Vorgehensweisen sind möglich, oft eine Kombination sinnvoll.

Schritt 2: Die Generalprobe – Regeln im Kleinen testen

Bevor der große Angriff startet, folgt ein Stresstest. Drei Dateien werden nach dem Regelbuch übersetzt, drei weitere von einem Agenten, der sich wie ein „Senior Rust Engineer“ verhält. Aus dem Unterschied zwischen beiden Versionen werden neue Übersetzungsregeln abgeleitet. Dieser Schritt deckte bei Jarreds Migration zwei kritische Probleme auf, die sonst tausendfach durchgeschlagen wären. Die erzeugten Dateien werden verworfen. Ziel ist es, die Regeln zu schärfen, nicht Fortschritt zu machen.

Für Design-getriebene Migrationen (wie Mikes) ist der Ersatztest eine konfrontative Prüfung des Entwurfsdokuments durch gegnerische Gutachter, gefolgt von einem komplett durchlaufenen E2E-Durchlauf, der ebenfalls verworfen wird.

Schritt 3: Die Übersetzungswelle

Jetzt geht es an die Massenfertigung. Eine Multi-Agenten-Schleife aus Implementierung, Review und Korrektur kommt zum Einsatz. Die Implementierer können kleinere, günstigere Modelle sein – Anthropic nutzte hier Claude Sonnet für zwölf Subagenten. Die Warteschlange ist mechanisch: Ein Batch-Skript prüft, ob die Zieldatei bereits auf der Festplatte existiert, und teilt die restlichen Dateien in Batches auf. Die Migration ist jederzeit fortsetzbar, auch nach einem Abbruch.

Ein Problem: Agenten neigen zur Übervorsicht. Die Lösung ist eine deutliche Anweisung: „Der Compiler fängt Fehler im nächsten Schritt – mach einfach.“ Alles, was der Übersetzer nicht sicher kann, markiert er mit // TODO(port): <Grund>. Diese offenen Punkte werden in Schritt 4 abgearbeitet. Zwei gegnerische Reviewer bewerten die Arbeit der Implementierer. Wenn ein Reviewer immer denselben Fehler sieht, wird nicht jede Datei einzeln geflickt, sondern das Regelbuch um einen Satz ergänzt und der betroffene Batch neu generiert. Der Code wird niemals von Hand gegen das Regelbuch korrigiert.

Ein wichtiger Design-Entscheid: Wo sitzt der Compiler? Mike ließ den TypeScript-Compiler in jeder Schleife laufen (weil er in Sekunden fertig ist), Jarred verbannte ihn aus der Schleife (weil cargo Minuten braucht) und verschob ihn in den nächsten Schritt.

Schritte 4–6: Kompilieren, Testen, Verhalten abgleichen

Diese drei Schritte teilen sich dieselbe Schleifenarchitektur und brauchen zunehmend weniger menschliches Eingreifen. Schritt 4 (Kompilieren) kann je nach Sprache und Umfang in Schritt 3 aufgehen. Bei Jarred rief ein Orchestrator-Skript den Compiler einmal über das gesamte Workspace auf. „Fixer Agents“ arbeiteten die Fehlerliste parallel ab, wieder mit gegnerischem Review. Dabei half es, systematische Fehler zu erkennen – zum Beispiel Tausende von Rust-Modul-Fehlern, die durch zyklische Importe entstanden, welche Zigs lazy compilation toleriert hatte. Der Fix war eine Logik im Loop, die entscheidet, welche Abhängigkeit gelöscht, verschoben oder neu strukturiert wird.

Schritt 5 (Ausführen) hat eine ähnliche mechanische Wahrheitsquelle: Abstürze aus dem Smoke-Test. Wieder werden die Fehler nach Ursache gruppiert und durch gegnerische Subagenten geprüft. Schritt 6 vergleicht das Verhalten beider Codebasen. Die übersetzten Dateien sind kompiliert, getestet – jetzt wird die Testsuite aus dem Prerequisites-Schritt gegen sie laufen gelassen. Fixer Agents untersuchen fehlgeschlagene Tests anhand beider Codebasen. Ein Build-Daemon ist der einzige Prozess, der das Binary neu bauen darf. Die Fixer schreiben Patches, der Daemon sammelt sie, baut einmal neu, führt die betroffenen Tests aus und liefert die Ergebnisse zurück. Das serialisiert den teuersten Vorgang.

Wiederholt sich derselbe Fehler in vielen Tests, wandert der Fix nach oben: Die Regel, die den Bug verursacht hat, wird geändert und nur die Dateien werden neu generiert, die diese Regel betrifft. Mikes Ansatz ist hier aufschlussreich: Da er keine portierte Testsuite hatte, ließ er Claude ein kleines Skript bauen, das sieben reale Szenarien gegen beide Versionen laufen ließ und die Ergebnisse per Diff verglich. Jedes fehlschlagende Szenario bekam einen eigenen Fix-Agenten. Dann ging er noch weiter: Claude entwarf eine eigene E2E-Testsuite und ließ sie autonom über Nacht laufen, reparierte, was kaputtging, und wiederholte das vier Nächte lang. So wurden auch die kleinen Fehler erwischt, die keine Szenarioliste vorhergesehen hätte. Fehlt eine Testsuite, baut Claude eine.

Best Practices für Code-Migrationen

Jede Migration lehrt etwas Neues. Einige Grundsätze haben sich bei Anthropic bewährt:

• Befolge diesen Leitfaden nicht blind. Jede Migration ist anders. Nutze die Struktur als Ausgangspunkt und plane deine spezifische Migration mit Claude, bevor du loslegst.
• Konzentriere dich nicht auf einzelne Fehler. Einzelfehler sind der Job der Fixer-Agenten. Deine Aufmerksamkeit gehört den Mustern.
• Mache Reviews gegnerisch und Verifikation mechanisch. Gegnerisches Review lohnt sich bei langlebigen Aufgaben oft. Lass Skripte – Compiler, Diff, Testsuite – den Schiedsrichter spielen.
• Nutze nicht das größte Modell für alles. Tokens kosten Geld, besonders in Schleifen. Kleinere Modelle bewältigen die Massenimplementierung gut; spare dir das große Modell für Reviewer und für alles, was Regeln schreibt, die andere Agenten befolgen.
• Investiere Zeit am Anfang. Das Regelbuch und der Stresstest sind der zeitaufwändigste Teil. Danach brennen im Wesentlichen die Warteschlangen ab.
• Mache die Warteschlange mechanisch und fortsetzbar. „Erledigt“ bedeutet: Die Ausgabedatei existiert auf der Festplatte.

Ergebnisse und Einordnung

Jarreds Bun-Migration läuft inzwischen in Produktion. Keine Migration ist perfekt: Etwa 4 % des Rust-Codes liegen in „unsafe“-Blöcken – meist einzeilige Zeigeroperationen an C/C++-Grenzen. Aber die neue Codebasis ist messbar besser. Alle vom Tooling erfassbaren Speicherlecks sind behoben: Ein Benchmark mit 2.000 Wiederholungen sank von 6.745 MB Speicher auf 609 MB. Das Binary ist auf Linux und Windows 19 % kleiner. Sprachübergreifende Optimierungen brachten 2–5 % mehr Geschwindigkeit bei HTTP-Serving und realen Workloads.

Wenn du vor einer ähnlichen Aufgabe stehst – Legacy-System in eine moderne Sprache überführen oder kritische Infrastruktur erneuern –, zeigt dieser Prozess, dass KI nicht nur beim Schreiben von Code hilft, sondern vor allem bei der Systematik. Die Kunst liegt nicht im Übersetzen, sondern im Entwerfen der Regeln und Prüfmechanismen. Der Rest ist Mechanik – und die kann man automatisieren.

Quelle: claude.com