In diesem Beitrag
NVIDIA Run:ai Open Source: GPU-Flotte und Softwarefabrik
Geprüft am anhand der NVIDIA-Dokumentation und öffentlicher Quellcode-Repositories. Dies ist eine Quellenanalyse, kein Run:ai-Deployment, ESF-Integrationstest oder GPU-Benchmark.
Die GPUs sind ausgelastet. Die Software ist trotzdem nicht bereit für den Release.
Genau diese Lücke macht NVIDIAs Run:ai-Ankündigung interessant. Rechenleistung zu verteilen und eine Softwareänderung abzunehmen sind zwei verschiedene Aufgaben. Open-Source-GPU-Orchestrierung kann die erste verbessern. Die zweite verschwindet dadurch nicht.
Die entscheidende Frage lautet deshalb nicht, ob Run:ai jede KI-Plattform ersetzt. Sondern: Welchen Teil des Systems müssen Sie nicht mehr selbst bauen, und welche Entscheidungen müssen unter Ihrer Kontrolle bleiben?
Was hat NVIDIA tatsächlich als Open Source veröffentlicht?
Am 13. Oktober 2026 kündigte NVIDIA die vollständige Run:ai-Plattform als Open Source an, nicht nur den KAI Scheduler. Die Veröffentlichung ordnet Run:ai der NVIDIA DSX AI Factory Platform zu. Sie umfasst eine integrierte Plattform und Komponenten, die sich einzeln einsetzen lassen. Zur offiziellen Ankündigung von NVIDIA.
Das Run:ai-Repository enthält die Control Plane, Cluster-Dienste, Installer, CLI, MCP-Server und Entwicklungsumgebung. Für den eigenen Code nennt es Apache-2.0. Für eingebundene Drittanbieterbestandteile und Markenmaterial gelten zusätzliche Hinweise. Präziser als „alles unter Apache-2.0“ ist deshalb: „Der Plattformcode steht unter Apache-2.0; ergänzende Lizenzen bleiben zu beachten.“ Umfang und Lizenzhinweise im Repository prüfen.
Das verändert die Entscheidung zwischen Eigenentwicklung und Zukauf. Teams können Infrastrukturkomponenten untersuchen und anpassen, für die bisher eine kommerzielle Plattformentscheidung nötig war. Nicht automatisch kostenlos werden dadurch sämtliche Abhängigkeiten, Modellgewichte, Supportleistungen oder GPUs.
Ist Open-Source-Run:ai kostenlos nutzbar?
Laut Ankündigung benötigt das NGC Community Product weder ein bezahltes Run:ai-Abonnement noch einen NVIDIA-Supportanspruch. Enterprise-Support von NVIDIA ist nicht enthalten. Für den Download dieser Distribution müssen weiterhin die jeweils geltenden NVIDIA-Software- und KI-Produktbedingungen akzeptiert werden. Quellcodelizenz, Bedingungen der fertigen Distribution und Supportvertrag sind getrennte Fragen.
Beim Zugang gibt es einen praktischen Vorbehalt. Die verlinkte NGC-Sammlung zeigte bei unserer Prüfung noch Abonnementhinweise und den Aktualisierungsstand . Diese ältere Katalogseite widerlegt die neuere Ankündigung nicht. Wir haben aber weder eine Anmeldung noch einen Community-Download abgeschlossen. Prüfen Sie deshalb Chart, Image-Versionen und Zugangsweg vor der Rollout-Planung. Verlinkte NGC-Sammlung und angezeigte Bedingungen ansehen.
Null Lizenzkosten lassen Hardware oder Cloud-Miete, Strom, Speicher, Netzwerk, Updates, Störungsbehebung und Arbeitszeit nicht verschwinden. Bessere Auslastung spart erst dann tatsächlich Geld, wenn eine Rechnung sinkt oder zusätzliche Kapazität vermieden wird. Eine bereits bezahlte GPU besser zu nutzen schafft Kapazität, aber noch keine Rückzahlung.
Run:ai oder KAI Scheduler: Welche Schicht wird gebraucht?
Wählen Sie die kleinste Komponente, die ein nachgewiesenes Problem löst. Eine bestehende Kubernetes-Plattform braucht möglicherweise nur einen Scheduler oder GPU-Sharing, nicht eine weitere vollständige Verwaltungsebene.
| Komponente | Hauptaufgabe | Kein Ersatz für |
|---|---|---|
| Run:ai-Plattform | Workloads, Organisationsrichtlinien, Zugriff und Übersicht über angebundene Cluster koordinieren. | Abnahmekriterien und Freigaben für Software. |
| KAI Scheduler | Workloads anhand von Warteschlangen, Quoten, Fairness, Prioritäten und Gang Scheduling platzieren. | Eine Inferenz-Engine oder die Entscheidungslogik eines Agenten. |
| GPU Fractioning Operator | Unterstützte GPU-Speicheranteile auf den Nodes durchsetzen und Metriken bereitstellen. | Zusätzlichen physischen Speicher oder universelle Hardware-Isolation. |
| KAI Resource Management | Projekte, Abteilungen, Node Pools und Ressourcenansprüche abbilden. | Produktprioritäten oder die Berechtigung zum Merge. |
| Workload Map | Die Struktur verschiedener Kubernetes-Workload-Typen einheitlich beschreiben. | Eine geprüfte Pipeline von der Aufgabe bis zum Patch. |
KAI dokumentiert hierarchische Quoten, Gewichtungen oberhalb der Quote, die Rückforderung von Ressourcen, zeitbasierte Fairness und die gemeinsame Platzierung zusammengehöriger Workloads. Dahinter stehen unterschiedliche Aufgaben: Quoten definieren Ansprüche, Fairness regelt Konkurrenz, und Gang Scheduling hilft verteilten Jobs, die erforderliche Ressourcengruppe gemeinsam zu erhalten. Nichts davon bestätigt die fachliche Richtigkeit des Ergebnisses. Scheduling-Funktionen von KAI nachlesen.
KAI Resource Management ergänzt diese Warteschlangen um eine Organisationsstruktur. Das ist hilfreich, wenn mehrere Teams unterschiedliche GPU-Typen gemeinsam nutzen. Weniger überzeugend ist es, wenn ein einzelnes Team bereits vorhersehbare Aufgaben auf dedizierter Hardware ausführt. Die Ressourcenverwaltung im Detail ansehen.
Run:ai hat durchaus eigene Semantik. Workload Map kennt Struktur, Rollen und Status eines Workloads und unterstützt damit einheitliche Verwaltungswerkzeuge. Nicht beschrieben wird dadurch, ob ein erzeugter Patch die Kundenanforderung erfüllt. Genau dort verläuft die relevante Grenze. Den Aufgabenbereich von Workload Map prüfen.
Sind MIG, Time-Slicing und GPU Fractioning dasselbe?
Nein. Sie teilen Hardware auf unterschiedliche Weise und bieten unterschiedliche Grenzen. Das Bild von GPU-Pizzastücken ist einprägsam. Für Mandantentrennung und Latenz reicht es nicht.
MIG erzeugt auf unterstützten GPUs hardwareseitig partitionierte Instanzen. NVIDIA beschreibt dedizierte Rechen- und Speicherressourcen sowie Isolation zwischen diesen Instanzen. Welche Profile und Kombinationen möglich sind, hängt von der GPU ab. NVIDIAs Einführung zu MIG lesen.
Beim Time-Slicing nutzen mehrere Workloads die GPU abwechselnd. NVIDIA grenzt das ausdrücklich von MIG ab: Gewöhnliches Time-Slicing isoliert weder Speicher noch Fehler zwischen den Replikaten. Mehr ausgewiesene Ressourcenplätze erzeugen keine zusätzliche physische GPU-Kapazität. Die Zusicherungen des GPU Operators zum Time-Slicing vergleichen.
Der neue GPU Fractioning Operator bindet CUDA-native Speicherlimits ein. Laut Dokumentation werden Limits vor dem Containerstart gesetzt und vom Treiber durchgesetzt; hinzu kommen Metriken pro Pod. Voraussetzungen sind unter anderem CUDA 13.4/r615 oder neuer, eine kompatible Container-Laufzeit mit NRI sowie passende Versionen von GPU Operator, Toolkit und Device Plugin. Das betrifft diesen Fractioning-Pfad, nicht pauschal jede Run:ai-Installation. Verhalten und vollständige Kompatibilitätsanforderungen prüfen.
| Verfahren | Nutzbare Grenze | Erforderlicher Test |
|---|---|---|
| MIG | Hardwareseitig partitionierte Instanzen auf kompatiblen GPUs. | Passt ein unterstütztes Profil zu Modell, Cache und Latenzanforderung? |
| Time-Slicing | Zeitlich geteilter Zugriff ohne MIG-gleichwertige Isolation. | Wie wirken Konkurrenz und Fehler, und dürfen diese Mandanten gemeinsam laufen? |
| CUDA-natives Fractioning | Treiberseitige GPU-Speicherlimits bei kompatiblem Softwarestand. | Werden Limits wirklich durchgesetzt, und was passiert bei Speichermangel und Konkurrenz? |
Ein hartes Speicherlimit garantiert weder konstante Tokens pro Sekunde noch gleiche Rechenzeit oder eine vollständige Sicherheitsgrenze zwischen feindlichen Mandanten. Planen Sie Modellgewichte, Laufzeitspeicher, Kontext-Cache und Parallelität ein. Weniger zugewiesener Speicher macht ein zu großes Modell nicht passend. Modellkompression und verteilte Inferenz sind eigene Entscheidungen.
Zur Serving-Schicht statt zur Ressourcenverteilung führt unsere Analyse von vLLM und Triton im Produktivbetrieb. Run:ai kann die Kapazität des Inferenzservers verwalten. Das Modell korrekt bereitzustellen bleibt Aufgabe des Servers.
Machen RBAC, SSO und OPA Coding-Agenten sicher?
Sie regeln bestimmte Zugriffe und Richtlinien. Sie beweisen keine Softwarequalität. Die Run:ai-Dienstereferenz dokumentiert Identity-Provider-Anbindung, rollenbasierte Rechte, Workload-Richtlinien, Audit-Dienste und Laufzeitlimits. Das sind echte Funktionen. Ihre Bedeutung sinkt nicht dadurch, dass sie unterhalb eines Agenten liegen. Identitäts-, Richtlinien- und Audit-Dienste nachvollziehen.
Die OPA-Aussage braucht eine genauere Einordnung. Der geprüfte Leitfaden zur Benutzeridentität nennt Gatekeeper als Möglichkeit für clusterweite Kontrollen auf Kubernetes ohne OpenShift. Daraus folgt nicht, dass jede Run:ai-Installation bereits einen vollständigen, korrekt konfigurierten OPA-Regelsatz enthält. Die dokumentierten Grenzen von OpenShift und Gatekeeper lesen.
Die Erlaubnis, einen Workload zu starten, darf nicht zur Erlaubnis werden, dessen Prüfrichtlinien umzuschreiben. Trennen Sie Infrastrukturadministration, Modellzugänge, Repository-Schreibrechte und Release-Freigaben. Prüfen Sie API- und Automatisierungsidentitäten ebenso wie den Browser-Login. Eine überzeugende SSO-Anmeldung belegt nicht, dass jeder andere Zugangsweg eingeschränkt ist.
| Entscheidung | Verantwortliche Schicht | Erforderlicher Nachweis |
|---|---|---|
| Wer bekommt GPU-Kapazität? | Run:ai und der konfigurierte Scheduler. | Warteschlangen, Quoten, Zuteilung und Rückforderung. |
| Welches Modell erhält eine Anfrage? | Inferenz-Endpunkt und vom Betreiber kontrolliertes Routing. | Modellversion, Zieladresse und Anfrageidentität. |
| Was darf der Agent ändern? | Aufgabenrichtlinie, Sandbox und Repository-Rechte. | Freigegebener Ausgangs-Commit, Schreibbereich und Negativtests. |
| Erfüllt der Patch die Anforderungen? | Unabhängige Verifikation und Review. | Patch-Prüfsumme, Prüfvorgaben, Testergebnisse und Befunde. |
| Darf diese Version veröffentlicht werden? | Release-Verantwortliche außerhalb des Coding-Agenten. | Freigabe für genau den geprüften Stand. |
Das ist unser Vorschlag für die Zuständigkeitsverteilung. Es ist keine Behauptung, dass Run:ai alle fünf Schichten automatisch verbindet.
Wo passt ESF hinein, und gibt es eine fertige Integration?
ESF steht im genannten Projekt für Engineering Software Factory. Es ist ein unabhängiges, MIT-lizenziertes Projekt auf Basis von Machinist. Das README beschreibt Temporal als Koordinator für Coding-Agenten in CubeSandbox-MicroVMs, deterministische Prüfungen sowie gesicherte Patches und Ausführungsnachweise. ESF erzeugt demnach Änderungen zur Begutachtung, entscheidet aber nicht selbst über den Release. Zum Prüfzeitpunkt wird Version 0.6.2 als Release Candidate beschrieben, nicht als uneingeschränkt produktionsqualifiziert. Architektur und Reifegrad von ESF nachlesen.
Run:ai und ESF können sich damit ergänzen. Ein nachgewiesenes Komplettpaket sind sie nicht. Wir haben weder einen unterstützten Run:ai-ESF-Adapter verifiziert noch beide gemeinsam betrieben. Die CubeSandbox-Umgebung von ESF lässt sich nicht allein deshalb durch einen Run:ai-Workload ersetzen, weil beide Arbeit isolieren.
Ein begrenzter Integrationstest könnte ESF-Workflow und Sandbox beibehalten. Die Agenten würden einen Modell-Endpunkt aufrufen, dessen GPU-Kapazität Run:ai verwaltet. Eine gemeinsame Korrelationskennung verbindet Factory-Lauf, Inferenzanfrage und Infrastrukturprotokolle. Nicht jeder Coding-Agent benötigt eine eigene GPU, nur weil die Inferenz an anderer Stelle GPUs nutzt.
In diesem vorgeschlagenen Aufbau gehören GPU-Quoten zu den Inferenzdiensten. Anfragegrenzen und Ausgabenbudgets pro Agent müssen dagegen an der Gateway- oder Anwendungsschicht durchgesetzt und mit den Factory-Läufen verknüpft werden. Ein gemeinsamer GPU-Anspruch ist nicht automatisch ein Budget für jeden aufrufenden Agenten.
Der Abnahmevertrag sollte Aufgabe, Ausgangs-Commit, Harness-Version, Modellversion, Patch-Prüfsumme, geschützte Prüfvorgaben, Ergebnisse, Review-Entscheidung und Bereinigung verbinden. Prüfvorgaben müssen außerhalb der Schreibrechte des Agenten liegen oder unabhängig auf Integrität geprüft werden. Ein neuer Patch macht die bisherige Freigabe ungültig.
Unser Leitfaden zu Agent Harness Engineering behandelt die übergeordnete Workflow-Schicht. Der Google-AX-Check untersucht Ausführung und Wiederaufnahme von Agenten. Hier geht es dagegen um die GPU-Kapazitätsgrenze von Run:ai, nicht um einen weiteren allgemeinen Orchestrierungsvergleich.
Was muss ein Run:ai-Softwarefactory-Pilot nachweisen?
Beginnen Sie mit zwei Testprojekten, einem Wegwerf-Repository und einem festen Aufgabensatz. Erfassen Sie den Ausgangszustand vor dem Scheduler-Wechsel. Lassen Sie Modellqualität und Prüfkriterien während der Infrastrukturbewertung unverändert. Die folgenden Punkte sind vorgeschlagene Abnahmetests, keine von uns gemessenen Benchmark-Ergebnisse.
| Test | Bestanden, wenn |
|---|---|
| Quote und Rückforderung | Ein Team nur richtlinienkonform freie Kapazität ausleiht und zurückkehrender Bedarf den vorgesehenen Anspruch ohne endlose Neustarts wiederherstellt. |
| Speicheranteil | Eine absichtlich übergroße Zuweisung im vorgesehenen Workload scheitert und ein benachbarter Workload sein vereinbartes Serviceziel einhält. |
| Gruppenplatzierung | Ein verteilter Test nicht dauerhaft Teilkapazität blockiert, während notwendige Partner noch nicht eingeplant sind. |
| Identität und Umgehung | UI, API, CLI und aktivierte MCP-Zugänge dieselbe unberechtigte projektübergreifende Aktion ablehnen. |
| Verdrängung und Wiederherstellung | Ein unterbrochener Lauf anhand dokumentierten Zustands fortgesetzt oder wiederholt wird, ohne externe Schreibaktionen zu verdoppeln oder alte Ergebnisse zu akzeptieren. |
| Integrität der Prüfungen | Ein Patch durch Abschwächen der Prüfungen keine fehlerhafte Änderung in eine akzeptierte verwandeln kann. |
| Nachweise und Freigabe | Jede akzeptierte Änderung exportierbare Nachweise für exakt diesen Patch besitzt und Agenten ihren eigenen Release nicht freigeben können. |
| Rollback und Kosten | Das Team den bisherigen Scheduler oder die Zuteilungsrichtlinie wiederherstellen und den gemessenen Kapazitätsgewinn samt zusätzlichem Betriebsaufwand erklären kann. |
Messen Sie Wartezeiten, hohe Latenzperzentile, abgeschlossene Aufgaben, verworfene Änderungen, wiederholte Arbeit und Betriebsaufwand. Eine stärker ausgelastete GPU ist kein Erfolg, wenn Anfragen ihr Latenzziel verfehlen oder Reviewer mehr fehlerhafte Patches erhalten. Für die übergeordnete Kostenbewertung nutzen Sie unsere Methodik zu Kosten pro KI-Agentenaktion.
Sollten Sie Run:ai einsetzen, um Ihre KI zu kontrollieren?
Dann, wenn gemeinsam genutzte GPU-Kapazität ein relevantes Problem ist und jemand den Betrieb verantworten kann. Eine Kubernetes-Umgebung mit mehreren Teams und konkurrierenden Trainings-, Inferenz- und Entwicklungsaufgaben passt grundsätzlich. Ein reines API-Team, eine einzelne lokale Workstation oder eine Pipeline mit unzuverlässigen Tests braucht möglicherweise zuerst etwas anderes.
Unsere Einordnung des Markteffekts: Offene Infrastruktur erhöht die Anforderungen an Produkte, die hauptsächlich Scheduling neu verpacken. Zuverlässiger Betrieb, spezialisierte Abläufe, Integrationen und Verifikation bleiben wertvoll. Auch NVIDIA beschreibt in der Ankündigung Partnerangebote, nicht das Ende aller angrenzenden Softwareunternehmen.
„Die eigene KI kontrollieren“ wird als betrieblicher Test greifbar: Können Sie das Modell wechseln, Datenziele bestimmen, Zugänge widerrufen, Nachweise exportieren und Workloads verlagern? Das kann auch eine Cloud-Lösung ermöglichen. Umgekehrt kann Self-Hosting stark von einem Anbieter abhängen. Kein Betriebsort garantiert, dass ein Modell in Ihrem Interesse handelt.
Bevor Sie weitere GPUs kaufen, klären Sie den Engpass: Kapazität, Inferenz, Rechte oder Verifikation? Wavects KI-Entwicklung unterstützt diese Trennung. Die Twinsoft-AI-Fallstudie zeigt Anwendungsentwicklung, kein Run:ai-Deployment. Unsere QA-Checkliste für Software-Releases hilft bei den Freigabekriterien. Oder besprechen Sie Ihren GPU- und Agentenworkflow mit uns.
FAQ zu Run:ai Open Source und Softwarefabriken
Was hat NVIDIA im Oktober 2026 als Open Source veröffentlicht?
Braucht Run:ai Open Source eine kostenpflichtige Lizenz?
Was unterscheidet Run:ai vom KAI Scheduler?
Ist GPU Fractioning dasselbe wie MIG?
Passt durch Fractioning ein größeres Modell auf eine kleinere GPU?
Ersetzt Run:ai CI/CD oder die Softwareprüfung?
Was ist ESF, und ist die Run:ai-Integration produktionsreif?
Enthält jede Run:ai-Installation OPA-Richtlinien?
Soll ein kleines Team mit reiner API-Nutzung Run:ai einsetzen?
Garantiert Self-Hosting die Kontrolle über die eigene KI?
Fazit
Run:ai verteilt knappe GPU-Kapazität. Unabhängige Prüfungen entscheiden, ob generierte Änderungen abgenommen werden können. Open Source macht die erste Ebene einsehbar, aber die zweite nicht überflüssig.