NVIDIA sorgt für Aufsehen mit der Open-Source-Veröffentlichung von Harness: KI modifiziert KI eigenständig radikal

Nach OpenAI hat auch Jensen Huang zugegriffen!

Endlich hat Nvidia sein eigenes Harness – SoL-Pi – mit großer Aufmerksamkeit quelloffen veröffentlicht.

Es verwendet Pi als Grundgerüst und baut darauf eine eigene Effizienz-Erweiterungsebene für Harness auf, sodass KI sich selbst iterieren und optimieren kann.

In diesem strengen automatisierten Arbeitsablauf wird die KI selbst zum Forscher.

Sie beobachtet, wie Agenten arbeiten, ermittelt welche Schritte Token nutzlos verbrauchen, erarbeitet Lösungen, behebt Fehler und leitet die Lösungen anschließend in die Testphase ein.

Die gesamte Suche der KI beginnt mit 152 Kandidatenrichtungen, von denen am Ende vier bahnbrechende Architekturmechanismen übrigbleiben.

Die Messergebnisse sind überwältigend –

Der Token-Verbrauch wird um bis zu 64 % gesenkt, die Kosten für API-Aufrufe sinken abrupt um 50 % bis 54 %.

GitHub-Link: https://github.com/NVlabs/SoL-Pi

In professionellen Forschungsszenarien lassen sich pro Stunde direkt zwischen 8,75 und 13,5 US-Dollar einsparen. Nvidia hat den Schalter für Kosteneinsparungen bei KI quelloffen gemacht.

Die Konfiguration ist sehr einfach: Mit nur einer einzigen Codezeile „pi install git:github.com/NVlabs/SoL-Pi“ lässt es sich auf dem vorhandenen Pi installieren.

Codex schreibt Code im Höchsttempo

Die Hälfte der Token läuft im Leerlauf

Bevor man die KI dazu bringt, sich selbst rekursiv zu verbessern, kann man sie zuerst dazu bringen, die Kosten für die Selbstverbesserung zu senken?

Harness, das gesamte Ausführungsframework, das das Modell bei der Arbeit verwendet, ist derzeit die beste Lösung.

Das Modell ist für die Inferenz zuständig, Harness organisiert Tools, Kontext, Ausführungsrückmeldungen und Aufgabenabläufe, sodass das Modell Dateien lesen, Code ändern, Tests durchführen und auf Basis der Ergebnisse weitere Aktionen ausführen kann.

Bei ein und demselben Modell kann die Arbeitseffizienz stark abweichen, je nachdem in welchem Harness es ausgeführt wird.

Das aktuelle Problem besteht darin, dass die Aufgaben von Programmieragenten immer länger werden.

Von dem Ergänzen weniger Codezeilen über das Beheben von Problemen in mehreren Repositories bis hin zu langfristiger autonomer Arbeit kann eine einzelne Aufgabe mehrere Stunden dauern.

In diesem Fall summieren sich normalerweise unbemerkt bleibende Token-Verschwendungen stetig auf.

Nachdem eine Datei geändert wurde und der nächste Schritt bereits der Testlauf ist, führt das Modell noch eine zusätzliche Inferenz durch. Eine große Datei wurde bereits gelesen, wird aber in nachfolgenden Anfragen immer wieder mitgesendet.

Aus Tausenden von Zeilen Protokollen sind möglicherweise nur wenige Zeilen für die Entscheidungsfindung relevant, aber das teure Modell muss sie alle von Anfang an durchlesen.

Rekursive Selbstverbesserung (RSI) kommt ebenfalls nicht um diese Kosten herum. Jeder Versuch der KI, das System zu verbessern, verbraucht Token. Auch fehlgeschlagene Lösungen werden berechnet.

Das Erscheinen von SoL-Pi soll genau dieses Problem lösen.

Die Endergebnisse zeigen, dass SoL-Pi im Vergleich zum Basis-Pi 45 % bis 49 % weniger Token verbraucht, die Kosten um etwa ein Drittel niedriger liegen und der durchschnittliche Leistungsumfang zu rund 94 % erhalten bleibt.

Im Vergleich zum mit Codex und Claude Code mitgelieferten Harness werden 35 % bis 64 % weniger Token verbraucht, die ausgewiesenen Kosten sinken um 50 % bis 54 %.

Wie erreicht SoL-Pi eine so beeindruckende Leistung? Dazu muss man seine vier Kernmechanismen detailliert aufschlüsseln.

KI treibt ihre eigene Evolution voran – vier starke Maßnahmen kommen zum Einsatz

Der Arbeitsablauf von Nvidia hat am Ende vier Mechanismen hervorgebracht, die alle die Hauptarbeitswege umgehen und speziell für wiederholende Tätigkeiten ausgelegt sind.

Erste Ebene: Aktionsfusion – Bearbeitung und Überprüfung in einem einzigen Aufruf abschließen

Action Fusion zielt direkt auf den überflüssigen Modellentscheidungsschritt zwischen zwei aufeinanderfolgenden Toolaufrufen ab.

In der Ausführungsprotokoll des Basis-Pi besteht die häufigste Sequenz aus dem Ändern einer Datei, dem Empfangen des Ergebnisses und dem anschließenden Aufrufen eines Befehls zum Testen oder Erstellen.

Da die nachfolgenden Befehle bereits eindeutig sind, gibt es für das Hin und Her des Modells in diesem Zwischenschritt ein großes Einsparpotenzial.

Die Aktionsfusion behält eine Bearbeitung und ihre nachfolgenden Befehle in einer lokalen Sequenz bei und spart den zwischengeschalteten Modellentscheidungsschritt ein

Action Fusion kapselt Bearbeitung und nachfolgende Befehle direkt in dieselbe lokale Ausführungssequenz ein.

Harness führt die Änderungen und Befehlsausführungen auf unterster Ebene durch und gibt die kombinierten Ergebnisse auf einmal zurück. Tests werden wie gewohnt ausgeführt, Ergebnisse normalerweise abgerufen, aber der zwischengeschaltete Modellaufruf wird erfolgreich eingespart.

Das entspricht der Zusammenführung von zwei verteilten Anfragen zu einem hocheffizienten geschlossenen Vorgang.

Zweite Ebene: Online-Kontextkompression – dynamische Kostenberechnung pro Teilaufgabe

Online Context Compact löst das Kernproblem „Wann soll die Kompression ausgelöst werden?“.

Je länger der Kontext ist, desto eher werden historische Daten zu einer Belastung für Rechenleistung und Kosten.

Aber Kompression hat auch ihren Preis: Das Umschreiben des Kontexts kann die vorhandene KV-Cache-Wiederverwendung unterbrechen, sodass zusätzliche Verarbeitungskosten anfallen.

Daher ist eine zu frühe Kompression nicht unbedingt kostensparend, in der Vergangenheit wurden Kompressionsvorgänge meist so weit wie möglich nach hinten verschoben.

Die Online-Kontextkompression betrachtet abgeschlossene Teilaufgaben als potenzielle Kompressionspunkte und führt die Kompression erst dann durch, wenn nachfolgende Anfragen die Umschreibkosten decken können

SoL-Pi strukturiert die Bewertungszeitpunkte neu: Es teilt große Aufgaben in Teilaufgaben auf und führt nach Abschluss jedes Schrittes eine Neubewertung durch.

Seine Kernlogik basiert auf präziser Berechnung: Nur wenn die „voraussichtlich in Zukunft eingesparten Kosten“ die „Kosten für das aktuelle Umschreiben“ decken, führt das System den Kompressionsvorgang tatsächlich aus.

Dritte Ebene: Ausgabearchivierung und Indexierung – bedarfsgerechter Abruf großer Dateien

ObservationPack ist speziell für das Problem der wiederholten Kosten zuständig, die durch lange Toolausgaben entstehen.

Eine große Datei oder ein sehr langes Ergebnis verbleibt nach dem ersten Lesen dauerhaft im Kontext. Bei jeder nachfolgenden Anfrage wird es vollständig mitgesendet und verbraucht ständig Cache-Ressourcen.

ObservationPack ersetzt die wiederholte vollständige Ausgabe durch ein stabiles Handle, während der ursprüngliche Inhalt für den seitenweisen Abruf erhalten bleibt

SoL-Pi archiviert den vollständigen Inhalt direkt auf der lokalen Festplatte, im Kontext verbleiben nur ein stabiles kurzes Handle und ein kurzer Auszug.

Das funktioniert so, als würde man nach dem Lesen eines langen Berichts das Originaldokument archivieren und nur den Index und wichtige Zusammenfassungen zur Hand behalten. Wenn das Modell Details einsehen muss, ruft es diese direkt nach Seiten über den Index ab.

Vierte Ebene: Vorprüfung von Protokollen durch kleine Modelle – Einführung eines strengen Mechanismus zur Beweiskontrolle

Der Kern des Evidence-Preserving Reducer besteht darin, das erste Durchlesen langer Protokolle an ein kostengünstigeres Modell zu übergeben.

Erstellungs- und Testprotokolle umfassen oft zehntausende Zeilen, von denen meist nur wenige Zeilen mit Fehlermeldungen die nächste Entscheidung beeinflussen. Es ist sehr teuer, wenn hochmoderne große Modelle jedes Mal das gesamte Dokument durchlesen; wenn man die Aufgabe aber direkt kleinen Modellen zur Zusammenfassung überlässt, besteht die Gefahr von Halluzinationen.

Der beweiserhaltende Reduzierer akzeptiert eine kompakte Diagnosebestätigung nur dann, wenn ihre Beweise anhand der archivierten Protokolle überprüft werden können

SoL-Pi fügt eine strenge Schutzebene ein – die Beweiskontrolle. Nachdem das Hilfsmodell die Protokolle gelesen hat, muss es eine kompakte Diagnosebestätigung ausgeben.

Das System vergleicht diese Bestätigung Punkt für Punkt mit den archivierten Originalprotokollen. Nur Inhalte, die exakt mit dem Originaltext übereinstimmen, werden an das hochmoderne große Modell weitergeleitet.

Das stellt sicher, dass das Hauptmodell nur nachweislich korrekte Informationen erhält, und unterbricht die Fehlerübertragung von der Quelle an.

152 Ideen im harten Wettbewerb – nur 4 überleben

Warum genau diese 4 Mechanismen? Das hängt mit dem echten Ehrgeiz von Nvidia zusammen: RSI (Rekursive Selbstverbesserung).

Da KI Code ändern kann, sollte sie auch in der Lage sein, „das System zur Erzeugung von KI“ umzugestalten.

Aber RSI ist sehr kostspielig, jeder Versuch-und-Irrtum-Schritt verursacht Token-Kosten. Daher verfolgt Nvidia ein anderes Ziel: Zuerst nicht versuchen, die KI intelligenter zu machen, sondern sie kostengünstiger zu machen.

Im Vergleich zur direkten Leistungssteigerung ist die Token-Effizienz schwieriger zu manipulieren. Es ist einfach, Aufgabenscores durch Überanpassung zu verbessern, indem Regeln für bestimmte Aufgaben geschrieben werden. Aber Optimierungen wie das Entfernen von wiederholtem Kontext, das Komprimieren von Toolausgaben und das Zusammenführen ineffektiver Entscheidungen lassen sich auf verschiedene Aufgaben und Modelle übertragen.

Daher wird ein Arbeitsablauf „Agent erforscht Agent“ gestartet:

Das Team erstellt zuerst 535 überprüfbare Umgebungen, lässt die KI 152 Optimierungsvorschläge machen und durchläuft dann drei Auswahlrunden –

Zuerst werden die Gewinne anhand historischer Protokolle geschätzt, Vorschläge ohne Potenzial werden direkt verworfen. Dann lässt die KI selbst Code ändern und Experimente durchführen, während ein Reviewer Agent Fehler und Mängel aufdeckt;

Am Ende werden die Lösungen eingefroren und auf vollständig isolierten, zurückgehaltenen Aufgaben validiert: Die Leistungsfähigkeit darf nicht abnehmen, die Effizienz muss steigen.

Von 152 Ideen überleben am Ende nur 4, im Durchschnitt wird nur etwa jede 40. Idee erfolgreich.

So wird die Kernmethode von SoL-Pi allmählich klar: Die K