Ein einziger Satz lässt die KI eine Inferenz-Engine erzeugen, die 6,3 Mal schneller ist. Jia Yangqing verlässt NVIDIA und gibt offiziell sein zweites Startup bekannt: AI Infra entwickelt sich von „Verwaltung der Rechenleistung“ zu „Systementwicklung“.

Vor einem Monat berichteten wir über die Geschichte von Jia Yangqing, der NVIDIA verließ.

Damals gab es in der Öffentlichkeit Spekulationen: Er würde höchstwahrscheinlich wieder an den Tisch des GPU-Cloud-Geschäfts zurückkehren.

Schon seit seiner Zeit bei Alibaba Cloud über LeptonAI bis hin zu NVIDIA DGX Cloud befasste sich Jia Yangqing in den letzten Jahren ständig mit Infrastrukturproblemen wie Rechenkapazitätsplanung, Multi-Cloud-Bereitstellung und GPU-Auslastung. Anfang Juni stellte der GPU-Cloud-Dienstleister Hyperbolic ihn erneut als Berater ein, und die Geschäftsrichtung schloss sich nahtlos an die alte Route von LeptonAI an.

Doch nun ist die wahre Antwort aufgetaucht.

Gemeinsam mit erfahrenen Fachleuten im Open-Source-Bereich wie Junjie Bai, Xiang L. und Casber Wang hat Jia Yangqing offiziell das neue Unternehmen Intent Lab gegründet. Diesmal hat er nicht weiter an der GPU-Cloud-Plattform gearbeitet und auch nicht einfach den alten Weg der KI-Infrastruktur wiederholt, sondern versucht, ein Problem auf einer höheren Ebene zu lösen:

Wenn Modelle immer besser darin werden, Code zu schreiben, welcher Schritt fehlt der KI noch, um wirklich selbstständig eine produktionsreife Software zu entwickeln?

Gemeinsam mit der offiziellen Ankündigung wurden die ersten Ergebnisse von Intent Lab vorgestellt:

1) Eine GLM-5.2-Inferenz-Engine, die auf zwei Grace-Blackwell-Knoten die Ausgabegeschwindigkeit von 102 Tokens/s auf 647 Tokens/s steigert, was einer 6,3-fachen Erhöhung entspricht;

2) Eine Datenbank-Engine, die ausgehend von einer unscharfen Anforderung schließlich 6 Millionen SQLite-Kompatibilitätstests erfolgreich durchläuft;

3) Ein verteiltes Dateisystem mit formaler Verifizierung, das Datenbeschädigungsfehler im Code erkennen kann, der von gewöhnlichen Codierungs-Agenten erzeugt wurde.

Von der Inferenz-Engine über die Datenbank bis hin zum Proxy-Dateisystem handelt es sich alle um untergeordnete Werkzeuge, die scheinbar keinen Zusammenhang aufweisen. Tatsächlich möchte Jia Yangqing jedoch die Fähigkeiten des dahinterstehenden einheitlichen Systems Fleet demonstrieren.

Jia Yangqing definiert Fleet als „das weltweit erste autonome Team, das Absichten in produktionsreife Software umwandelt“. Das bedeutet, dass Benutzer der KI nicht mehr den Befehl „Schreibe einen Codeabschnitt“ geben, sondern ein Ziel auf einer höheren Ebene vorschlagen, das von einer Gruppe von Agenten selbstständig verstanden, entworfen, codiert, verifiziert und weiterentwickelt wird.

Dadurch erhält Jia Yangqings neues Unternehmen eine branchenspezifische Bedeutung, die mehr Aufmerksamkeit verdient als die Nachricht „Ein KI-Experte verlässt NVIDIA“.

Die grundlegende Fragestellung der KI-Infrastruktur hat sich geändert

In den letzten zehn Jahren hat Jia Yangqing an Caffe, ONNX und PyTorch 1.0 gearbeitet und ist ein anerkannter Gründervater der KI-Frameworks der vorherigen Generation; außerdem hat er bei Alibaba und NVIDIA am Aufbau groß angelegter KI-Infrastrukturen mitgewirkt. Bei LeptonAI versuchte er, die Hürden für Entwickler bei der Nutzung von GPUs und der Bereitstellung von Modellen zu senken.

Und nun bei Intent Lab geht es darum, die KI direkt dazu zu bringen, grundlegende Software mit Lieferfähigkeit zu erstellen.

Dahinter verbirgt sich tatsächlich eine Neubewertung des Werts der KI-Infrastruktur.

Wie wir in unserem vorherigen Bericht erörtert haben, schien die Fragestellung, die Hürden für Entwickler bei der Nutzung und Verwaltung von GPU-Clustern zu senken, im Jahr 2023 ein Problem zu sein, für dessen Lösung sich die Investition von mehreren hundert Millionen Dollar lohnt. Doch heute haben sich die Lösungsansätze und Hürden gelockert.

Die Agentic-Coding-Werkzeuge, vertreten durch Cursor, Claude Code und Codex, gestalten die grundlegende Logik der Softwareentwicklung neu. Entwickler können Anforderungen bereits in natürlicher Sprache beschreiben, und KI-Agenten generieren, debuggen und bereitstellen automatisch vollständigen Infrastrukturcode.

Das bedeutet auch, dass die Komplexität, die die traditionelle KI-Infrastruktur durch Produktisierung zu kapseln versucht, von Agentic Coding durch Codegenerierung direkt umgangen wird.

Plattformen auf Werkzeugebene, die nur darauf abzielen, „die Ingenieurarbeit einfacher zu machen“, stehen vor einer systemischen Herausforderung, durch Open-Source-Komponenten und Kombinationen von Agenten ersetzt zu werden. Dies ist auch der objektive Hintergrund für eine Reihe von Problemen, darunter dass DGX Lepton die Erwartungen von Jensen Huang nicht erfüllt und die Open-Source-Versprechen nicht eingelöst wurden.

Daher lautet die zentrale Frage für das Unternehmertum im Bereich der KI-Infrastruktur: Löst du oberflächliche Komplexität oder unterliegende Knappheit?

Jia Yangqing gibt mit Intent Lab seine Antwort darauf. In seinem offiziellen Beitrag drückt er es sehr direkt aus:

„Wir haben unser gesamtes Berufsleben den größten verteilten Systemen und KI-Infrastrukturen der Welt gewidmet, immer mit sorgfältigem Architekturentwurf und jeweils einem System nach dem anderen. Aber jetzt interessieren wir uns mehr für das System, das tausend Systeme auf einmal erzeugen kann.“

Keine Middleware zur Kapselung von Komplexität zu erstellen, sondern das „System, das tausend Systeme erzeugen kann“ – das ist die grundlegende Logik hinter seinem neuen Unternehmen.

Nicht KI, die Code schreibt, sondern die Schaffung eines Ingenieurteams

Das Kernprodukt von Intent Lab heißt Fleet. Gemäß seiner Positionierung ist es kein schnelleres Code-Vervollständigungswerkzeug und auch kein neues IDE-Plugin, sondern ein autonomes Agententeam für Produktionssysteme.

Worin besteht der Unterschied?

Die meisten heutigen Codierungs-Agenten lösen das Problem der „Codegenerierung“. Der Benutzer gibt eine Anweisung, die KI schreibt eine Funktion, behebt einen Fehler, ergänzt eine Reihe von Tests und realisiert sogar eine kleine Funktion. Das ist bereits sehr wertvoll, aber es liegt noch weit hinter der realen Softwareentwicklung zurück.

Wahre Ingenieurarbeit endet nicht mit dem Schreiben von Code. Zuerst müssen Anforderungen verstanden, Ziele aufgeteilt, Architekturen entworfen, Schnittstellen festgelegt, Leistung und Kosten abgewogen werden, bevor man in Codierung, Test, Prüfung, Verifizierung und Inbetriebnahme eintritt. Nach der Inbetriebnahme muss der Betriebszustand beobachtet und das System entsprechend der tatsächlichen Last weiter korrigiert und weiterentwickelt werden.

Intent Lab möchte diese gesamte Kette der KI übergeben.

Fleet soll ausgehend von einer unscharfen menschlichen Absicht End-to-End-Entwurf, Implementierung und Verifizierung durchführen und sich in der Produktionsumgebung ständig weiterentwickeln. Es automatisiert nicht nur einzelne Aktionen menschlicher Ingenieure, sondern versucht, den vollständigen Zusammenarbeitsprozess eines zuverlässigen Ingenieurteams nachzubilden.

Aus diesem Grund hat Intent Lab zuerst keine Chat-Anwendung oder keine Website-Demo vorgestellt, sondern Inferenz-Engines, Datenbanken und Dateisysteme.

Alle diese Dinge haben eines gemeinsam: Sie sind keine Anwendungsschicht-Software, die nur „laufen muss“, sondern Systemsoftware mit extrem hohen Anforderungen an Leistung, Zuverlässigkeit, Kompatibilität und Korrektheit.

Insbesondere das Beispiel der GLM-5.2-Inferenz-Engine eignet sich gut, um die Fähigkeitsgrenzen von Fleet zu demonstrieren.

Das ursprüngliche Ziel für Fleet war nur eine hochrangige Absicht: TensorRT-LLM umzubauen, damit GLM-5.2 auf Grace-Blackwell-Knoten schneller läuft, und Optimierungsmöglichkeiten selbst zu erkennen, zu implementieren und zu verifizieren.

Beachten Sie: Es geht nicht darum, von Grund auf eine Spielzeug-Inferenzdienst zu schreiben, sondern die Leistung auf dem bereits hochgradig optimierten TensorRT-LLM-System von NVIDIA weiter zu steigern. Mit anderen Worten: Fleet hat es nicht mit „niedriggradiger Codegenerierung“ zu tun, sondern mit harter Systemoptimierung.

Schließlich lieferte es vier Arten von Optimierungen.

Kernel-Ebenen-Optimierung: Durch Kernel-Fusion sowie die direkte Generierung von PTX und SASS umgeht der Agent den Pfad gewöhnlicher Compiler und erhält eine feingranulare Steuerung auf Anweisungsebene.

Laufzeitoptimierung: Durch H2D-Batching wird die Metadatenkopie von CPU zu GPU in der stabilen Decodierungsphase stark reduziert, wodurch unnötiger Planungsaufwand verringert wird.

Kommunikationsoptimierung: Residual-Add und RMSNorm werden in die fusionierte All-Reduce-Operation integriert, wodurch Kernel-Startvorgänge pro Schicht und Speicherzugriffe reduziert werden.

Spekulative Decodierungsoptimierung: In Kombination mit einem besseren Drafter lässt das Modell mehrere Tokens auf einmal vorschlagen, die dann vom großen Modell in einem Stapel verifiziert werden, wodurch der Ausgabedurchsatz deutlich gesteigert wird.

Das Endergebnis ist, dass die Ausgabegeschwindigkeit von GLM-5.2 von 102 Tokens/s auf 647 Tokens/s gesteigert wurde, was einer Leistungssteigerung um das 6,3-fache entspricht.

Was jedoch noch mehr Aufmerksamkeit verdient, ist die Arbeitsweise von Fleet. Es verlässt sich nicht darauf, dass Menschen alle Optimierungsregeln im Voraus schreiben, sondern arbeitet wie ein Systemingenieursteam: Zuerst führt es eine Engpassanalyse durch, dann schlägt es Lösungen vor, implementiert sie und verifiziert die Ergebnisse. Bei Misserfolgen wird zurückgerollt, und nach Erfolg wird der nächste Engpass gesucht.

Das ähnelt nicht mehr einem gewöhnlichen Codierungs-Agenten, sondern einem automatisierten Systemingenieur-Zyklus.

Warum Datenbanken und Dateisysteme?

Wenn die GLM-5.2-Inferenz-Engine die Fähigkeit zur Leistungsoptimierung demonstriert, dann zeigen Datenbanken und Dateisysteme eine andere Art von Fähigkeit: die Korrektheit komplexer Systeme.

Das zweite von Intent Lab vorgestellte Beispiel ist die Generierung einer Datenbank-Engine aus einer einzigen Anweisung, die schließlich 6 Millionen SQLite-Kompatibilitätstests erfolgreich durchläuft.

Man muss wissen, dass Datenbanken keine gewöhnliche Geschäftslogik sind. Sie müssen nicht nur SQL ausführen, sondern auch Abfragesemantik, Speicherstrukturen, Transaktionsverhalten, Randbedingungen und Kompatibilitätsprobleme verarbeiten. Viele Fehler treten nicht in einfachen Tests auf, sondern tauchen allmählich in komplexen Anweisungen, ungewöhnlichen Eingaben, gleichzeitigen Zuständen und historischer Kompatibilität auf.

Wenn ein Agent nur eine Datenbank schreibt, die „anscheinend läuft“, ist das nichts Besonderes. Die wahre Schwierigkeit besteht darin, dass er sich in ein strenges Testsystem einbinden und Schritt für Schritt korrigieren kann, bis sein Verhalten den Anforderungen eines echten Produktionssystems entspricht.

Das dritte Beispiel ist AgentFS, ein Dateisystem-Agent, ein verteiltes Dateisystem speziell für KI-Agenten, dessen Schwierigkeit in der direkten Zustandsverwaltung liegt.

Warum ein neues Dateisystem erstellen? Weil Agenten bei der Ausführung in der Cloud ständig Sandboxes starten, Verzeichnisse durchsuchen und viele kleine Dateien lesen und schreiben, die sich oft in gemeinsam genutzten Cloud-Speichern befinden. Traditionelle Lösungen wie Amazon EFS und S3FS funktionieren, sind aber nicht für diese Hochfrequenz-, Kleindatei- und Stark-Konkurrenz-Arbeitslast von Agenten geeignet. Die Herausforderung besteht darin, in allen möglichen Randfällen Konsistenz und Wiederherstellbarkeit so weit wie möglich aufrechtzuerhalten.

Daher hat Fleet AgentFS von Grund auf neu erstellt. Die Ergebnisse zeigen, dass AgentFS bei grundlegenden Vorgängen wie Verzeichniserstellung