NeMo Gym: Umgebungen für Agenten-Evaluierung und RL-Training
Evaluate and improve models and agents using environments
Auf einen Blick
- Was ist das?
- NVIDIA veröffentlicht mit NeMo Gym eine Bibliothek, die Evaluierung, Rollout-Erzeugung und Training in einem Umgebungsmodell zusammenführt. Das Projekt steht laut README noch am Anfang, die API ändert sich, und für einfache Prüfungen ist ein Skript die günstigere Wahl.
- Für wen ist es gedacht?
- Wer zustandsbehaftete Agentenläufe mit Sandbox, Tool-Aufrufen und mehreren Wiederholungen pro Aufgabe reproduzierbar messen oder direkt in RL-Training überführen will, findet hier eine Struktur, die genau diese vier Teile eines Laufs benennt. Wer nur Modellausgaben gegen einen festen Erwartungswert prüft, bleibt beim eigenen Skript, das sagt die Dokumentation selbst.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem die Bibliothek adressiert
Die Bewertung eines Agenten ist kein einzelner Modellaufruf. Sobald ein Modell Code ausführt, Tools aufruft oder in einer Sandbox mehrere Schritte hintereinander läuft, hängt das Ergebnis vom Zustand zwischen den Schritten ab. Ein Skript, das eine Antwort gegen einen Erwartungswert hält, verliert genau diese Information. NeMo Gym setzt hier an und definiert eine Umgebung als vollständiges System aus vier Teilen: einem Dataset mit den zu lösenden Aufgaben, einem Agent Harness, der beschreibt, wie das Modell mit der Welt interagiert, einem Verifier, der die Aufgabenerfüllung bewertet, und dem State als Ausführungskontext pro Aufgabe. Diese Aufteilung ist der eigentliche Beitrag. Wer sie einmal übernommen hat, kann Harness und Verifier austauschen, ohne das Dataset neu zu schreiben, und kann dieselbe Umgebung für Evaluierung und für Training verwenden. Zielgruppe sind Teams, die mehrere Wiederholungen pro Aufgabe fahren oder tausende gleichzeitige Anfragen für einen Trainingslauf erzeugen müssen. Das README nennt die Grenze selbst: Wer Modellausgaben mit einem zustandslosen Check bewertet und weder Skalierung noch Training braucht, ist mit einem Skript besser bedient.
Dataset, Harness, Verifier, State: der Aufbau eines Laufs
Die vier Bestandteile sind nicht nur eine Begriffsklärung, sondern bestimmen, wo im Code eine Änderung ansetzt. Der Harness kapselt die Interaktion mit der Welt, im Repository liegen dafür Verzeichnisse wie responses_api_agents mit Einträgen für OpenHands, Mini SWE Agent und LangGraph. Der Verifier sitzt am Ende eines Rollouts und erzeugt das Signal, das sowohl eine Auswertung als auch ein Trainingsschritt konsumiert. Der State trägt den Kontext einer einzelnen Aufgabe über mehrere Schritte, weshalb die Release Notes zu v0.6.0 die Erhaltung exakter Token-IDs über mehrstufige Läufe als eigenes Highlight aufführen. Das ist der Punkt, an dem Evaluierung und Training auseinanderfallen, wenn die Kette zwischen Modellaufruf und Belohnung nicht durchgängig erhalten bleibt. Für die Beobachtbarkeit nennt das README optionales OpenTelemetry-Tracing über Agent-, Modell- und Ressourcen-Server hinweg. Die Release Notes zu v0.5.0 beschreiben zusätzlich ein standardisiertes ng_trajectory-Schema, das Modellaufrufe und Agentenbeobachtungen zusammenführt. Wie die Verzeichnisse im Einzelnen zugeschnitten sind, geht aus dem vorliegenden Material nicht hervor; die Struktur ist nur über die genannten Pfade belegt.
Installation und die dokumentierten Befehle
Das Paket liegt auf PyPI unter dem Namen nemo-gym, die Installation erfolgt entsprechend mit pip. Als Python-Version nennt das README 3.13.14 oder höher, was für ein Projekt dieser Art ungewöhnlich hoch angesetzt ist und die Auswahl der Laufzeitumgebung einschränkt. Als Betriebssysteme sind Linux ab Ubuntu 20.04, macOS ab 11.0 für x86_64 beziehungsweise 12.0 für Apple Silicon und Windows über WSL2 angegeben. Eine GPU ist für den Betrieb der Bibliothek selbst nicht erforderlich, kann aber für einzelne Ressourcen-Server oder Modellinferenz nötig werden. Die Kommandozeile firmiert unter dem Namen gym; die Release Notes zu v0.4.0 nennen eine vereinheitlichte gym-CLI als Bestandteil dieser Version. Konkret belegt ist aus dem Material ein Unterbefehl: `gym eval reverify` berechnet Belohnungen aus gespeicherten Rollouts neu, ohne die Inferenz erneut auszuführen. Das ist der praktisch nützlichste Eintrag in der Liste, weil er erlaubt, eine geänderte Verifier-Logik gegen bereits erhobene Läufe zu prüfen, statt Rechenzeit für neue Rollouts zu verbrauchen. Weitere Unterbefehle, Konfigurationsdateien oder Schlüsselnamen werden im vorliegenden Ausschnitt nicht genannt, und ich erfinde hier keine.
Sandboxen, Harnesses und die Kosten der Anbindung
Die Release Notes zu v0.5.0 zählen sieben Sandbox-Anbieter auf: Docker, Daytona, ECS Fargate, Enroot und OpenShell kommen zu OpenSandbox und Apptainer hinzu. Diese Breite ist kein Selbstzweck. Sie bestimmt, ob ein Lauf lokal auf einer Maschine oder verteilt auf Cloud-Ressourcen stattfindet, und sie bestimmt, wie viel Betriebsaufwand neben der eigentlichen Auswertung anfällt. Jeder zusätzliche Anbieter ist eine zusätzliche Abhängigkeit, die aktualisiert, konfiguriert und bei Ausfällen debuggt werden will. Die Release Notes zu v0.5.0 verbuchen für OpenSandbox ausdrücklich Verbesserungen der Zuverlässigkeit bei großem Maßstab, was implizit sagt, dass es dort vorher Probleme gab. Ähnlich verhält es sich mit den Harnesses. v0.5.0 bringt Codex CLI, KiloCode, RemoteAgent und anyswe_agent, v0.4.0 brachte OpenCode, OpenClaw und Pi, v0.3.0 Claude Code und Hermes. Wer einen dieser Harnesses produktiv nutzt, hängt an der Pflege eines Fremdprojekts, dessen Schnittstelle sich ändern kann. Das README verspricht, dass man eigene Agenten verwenden oder auf mitgelieferte Harnesses zurückgreifen kann; der Preis für die mitgelieferten ist die Abhängigkeit von ihrer Weiterentwicklung.
Skalierung und der Übergang ins Training
Der Anspruch, tausende gleichzeitige Umgebungen zu betreiben, ist der Punkt, an dem sich NeMo Gym von einem Evaluierungsskript unterscheidet. Die Release Notes zu v0.6.0 nennen das Skalieren von vLLM-Evaluierungsjobs über GPUs oder Slurm-Knoten für höhere Rollout-Nebenläufigkeit. Damit verschiebt sich die Engstelle von der Bewertungslogik zur Infrastruktur: Wer diese Größenordnung fährt, betreibt faktisch einen Cluster, und die Umgebung wird zum Teil des Systems, das überwacht werden muss. Für den Übergang ins Training nennt das README NeMo RL, Unsloth und VeRL als Trainingsframeworks sowie SFT und RL als Verfahren. Der Nutzen der viergeteilten Umgebungsdefinition zeigt sich hier: Dieselbe Umgebung, die eine Auswertung erzeugt, liefert auch die Rollouts für einen Trainingslauf. Die Release Notes zu v0.6.0 fügen einen Punkt hinzu, der in dieser Kette leicht übersehen wird: die Nutzung unterstützter externer Agent Harnesses während des RL-Trainings, wobei exakte Token-IDs über mehrstufige Läufe erhalten bleiben. Ohne diese Erhaltung lässt sich eine mehrstufige Trajektorie nicht sauber als Trainingssignal verwenden. Ob das in der eigenen Konfiguration tatsächlich greift, ist eine der Fragen, die vor dem ersten Trainingslauf zu klären sind.
Reifegrad und der Umgang mit der eigenen Warnung
Das README enthält einen hervorgehobenen Hinweis, der deutlicher kaum sein könnte: Das Projekt befinde sich in früher Entwicklung, man solle mit sich ändernden APIs, unvollständiger Dokumentation und gelegentlichen Fehlern rechnen. Für Änderungen wird gebeten, zuerst ein Issue zu öffnen. Diese Selbstauskunft ist ernst zu nehmen, denn sie widerspricht dem Bild, das die Liste der Umgebungen und Integrationen erzeugt. Zwischen v0.3.0, v0.4.0, v0.5.0, v0.5.1 und v0.6.0 liegen laut den veröffentlichten Daten nur wenige Monate, und jede dieser Versionen bringt neue Umgebungen, Harnesses oder Sandbox-Anbieter. Diese Geschwindigkeit bedeutet, dass eine Umgebung, die heute funktioniert, in der nächsten Version ein anderes Verhalten zeigen kann. Wer NeMo Gym einsetzt, sollte die Version festnageln und nicht gegen den Hauptzweig entwickeln. Die Lizenz ist Apache-2.0, was die Weitergabe und Modifikation erlaubt und für den kommerziellen Einsatz günstig ist. Zu den Pflichten aus dieser Lizenz, etwa Hinweisen auf Änderungen, gebe ich hier keine rechtliche Einschätzung; das gehört in eine Prüfung durch die zuständige Stelle. Einzelne Ressourcen-Server können eigene Bedingungen mitbringen, das ist im vorliegenden Material nicht aufgeschlüsselt.
Wann ein eigenes Skript die bessere Wahl bleibt
Die ehrlichste Aussage im README steht in der Liste, wann man NeMo Gym nutzen sollte: Wenn man Modellausgaben mit einem zustandslosen Check bewertet und weder Skalierung noch Training braucht, reicht wahrscheinlich ein Skript. Das ist keine Marketingformel, sondern eine brauchbare Entscheidungsregel. Der Aufwand für NeMo Gym liegt nicht in der Installation, sondern im Aufsetzen von Dataset, Harness, Verifier und State sowie im Betrieb der Sandbox-Anbieter. Wer zwanzig Aufgaben einmalig gegen ein Modell prüft, zahlt diesen Aufwand ohne Gegenwert. Wer dagegen dieselbe Umgebung über mehrere Teams hinweg teilen will, um reproduzierbare Ergebnisse zu erhalten, gewinnt genau dadurch, dass Verifier und Dataset als geteilte Artefakte existieren statt als Kopie in jedem Repository. Der Unterschied zu einem reinen Benchmark-Runner liegt in der Rückkopplung: Ein Runner liefert eine Zahl, NeMo Gym liefert Rollouts, aus denen sich Belohnungen neu berechnen und Trainingsläufe speisen lassen. Wer diese Rückkopplung nicht braucht, sollte die schlankere Variante wählen.
Redaktionelles Fazit
Wer zustandsbehaftete Agentenläufe mit Sandbox, Tool-Aufrufen und mehreren Wiederholungen pro Aufgabe reproduzierbar messen oder direkt in RL-Training überführen will, findet hier eine Struktur, die genau diese vier Teile eines Laufs benennt. Wer nur Modellausgaben gegen einen festen Erwartungswert prüft, bleibt beim eigenen Skript, das sagt die Dokumentation selbst. Vor jedem Einsatz ist zu klären, ob die Umgebung, die man braucht, im Environment Hub vorhanden ist oder selbst geschrieben werden muss, und ob `gym eval reverify` auf den gespeicherten Rollouts die eigene Rewards-Funktion korrekt nachrechnet. Beides lässt sich vor dem ersten Trainingslauf an einer einzelnen Aufgabe prüfen.
Community-Notizen