NVIDIA/GenerativeAIExamples: Referenzpipelines für RAG und Agenten auf beschleunigter Infrastruktur

Ein Startpunkt für Teams, die bereits im NVIDIA-Stack arbeiten

Das Repository beschreibt sich selbst als Ausgangspunkt für Entwickler, die sich in das NVIDIA-Software-Ökosystem integrieren wollen. Das ist eine engere Zielgruppe, als der Name vermuten lässt. Wer eine RAG-Pipeline, einen Agenten-Workflow oder ein Fine-Tuning-Projekt aufsetzt und dabei auf NVIDIA NIM, NeMo Microservices oder TensorRT-LLM setzt, findet hier fertige Notebooks und Compose-Dateien, die den Integrationsaufwand zwischen diesen Bausteinen zeigen. Wer dagegen einen möglichst providerunabhängigen Stack sucht, ist hier falsch: Die Beispiele sind um NVIDIA-Komponenten herum gebaut, und der Einstieg im README verlangt zuerst einen API-Key aus dem NVIDIA API Catalog.

Die Themenliste im Repository macht den Umfang greifbar: gpu-acceleration, llm-inference, microservice, nemo, rag, tensorrt, triton-inference-server. Das sind nicht sieben unabhängige Schlagworte, sondern eine Kette. Die Beispiele setzen voraus, dass Inferenz als Microservice betrieben wird, typischerweise über NIM-Container, und dass die Beschleunigung auf NVIDIA-Hardware stattfindet. Der Nutzen liegt also weniger im Algorithmus als in der Verkabelung: Wie verbindet man einen Retriever mit einem NIM-Endpunkt, wie ruft ein LLM ein Tool auf, wie hängt man Guardrails davor. Genau diese Fragen beantwortet Dokumentation selten vollständig, und hier liegen lauffähige Beispiele.

Wie die Beispiele aufgebaut sind: Notebooks, Compose-Dateien, Submodule

Die Struktur folgt einer Aufteilung nach Themen statt nach Schichten. Es gibt Verzeichnisse für RAG, für NeMo-Workflows unter nemo/data-flywheel und nemo/NeMo-Guardrails, für Vision-Workflows unter vision_workflows und nim_workflows sowie ein Verzeichnis community für Beiträge von außerhalb. Die RAG-Seite ist weiter unterteilt in Notebooks, Examples, Tools und Projects. Ein Beispiel wie RAG/examples/basic_rag/langchain/ enthält eine docker-compose-Datei, die den RAG-Playground zusammen mit den benötigten Diensten startet. Die Notebooks daneben zeigen denselben Ablauf Schritt für Schritt, etwa agentic_rag_with_nemo_retriever_nim.ipynb für einen Agenten auf Basis von Llama 3.1 und NeMo Retriever NIM.

Bemerkenswert ist der Umgang mit Submodulen. Die Vision-Workflows liegen nicht im Hauptbaum, sondern werden über git clone --recurse-submodules mitgezogen. Wer ohne diesen Schalter klont, bekommt ein Verzeichnis vision_workflows, das leer bleibt. Das ist eine häufige Fehlerquelle und einer der wenigen Punkte, an denen das Repository einen Stolperstein einbaut, ohne ihn im Fließtext hervorzuheben. Der Hinweis steht im README, aber er steht im Abschnitt zu Vision NIM Workflows, nicht in der Schnellstartanleitung.

Der kürzeste Weg zum laufenden RAG-Playground

Das README gibt einen vierstufigen Einstieg vor. Zuerst wird ein API-Key im NVIDIA API Catalog erzeugt und als Umgebungsvariable exportiert: export NVIDIA_API_KEY=nvapi-... Danach folgt der Klon des Repositories, dann der Wechsel in das Beispielverzeichnis und der Start:

cd GenerativeAIExamples/RAG/examples/basic_rag/langchain/ docker compose up -d --build

Anschließend ist der Playground unter https://localhost:8090/ erreichbar, und docker compose down beendet die Container wieder. Das ist die vollständige dokumentierte Prozedur für den Basisfall. Wer die Vision-Workflows braucht, klont stattdessen mit --recurse-submodules und arbeitet anschließend in vision_workflows beziehungsweise in den Unterverzeichnissen nim_workflows/vlm_alerts, nim_workflows/nvclip_multimodal_search, nim_workflows/vision_text_extraction und nim_workflows/nvdinov2_few_shot.

Auffällig ist, was das README nicht nennt: Es gibt keine Angabe zu GPU-Voraussetzungen, keine Versionsmatrix für Docker oder den NVIDIA Container Toolkit und keinen Hinweis darauf, welche Modelle der API-Key freischaltet. Der Key wird im Katalog an einem Modell erzeugt, aber ob derselbe Key für alle im Repository referenzierten NIMs gilt, bleibt offen. Das ist bei einem Referenz-Repository dieser Größe eine Lücke, die sich erst beim Start zeigt.

Data Flywheel und NeMo: der aufwendigere Teil

Die Data-Flywheel-Tutorials sind konzeptionell der interessanteste Teil des Repositories und gleichzeitig der, der am meisten Infrastruktur voraussetzt. Das README beschreibt einen Data Flywheel als selbstverstärkenden Zyklus, in dem Nutzerinteraktionen Daten erzeugen, die Modelle verbessern, was wiederum mehr Nutzer anzieht. Im Repository konkretisiert sich das in zwei End-to-End-Tutorials: Tool-Calling-Fine-Tuning mit Llama-3.2-1B-Instruct auf dem xLAM-Function-Calling-Datensatz, und Embedding-Fine-Tuning mit anschließender Evaluation.

Beide Beispiele setzen die NeMo-Microservices-Plattform voraus, namentlich NeMo Datastore, NeMo Entity Store, NeMo Customizer, NeMo Evaluator und NeMo Guardrails, dazu NIMs für die Inferenz. Das README nennt als Betriebsumgebung Kubernetes-Cluster, in der Cloud oder on-premises. Das ist ein anderer Aufwand als der RAG-Schnellstart über Docker Compose. Wer nur eine Vektorsuche mit einem gehosteten Modell ausprobieren will, braucht diesen Teil nicht und sollte ihn auch nicht als Einstieg wählen. Der Fine-Tuning-Zyklus lohnt sich erst, wenn tatsächlich Interaktionsdaten anfallen, die man zurückspielen will.

Ebenfalls unter NeMo verortet sind die Beispiele zu NeMo Auditor und parallelen Guardrails. Das Auditor-Notebook dient laut README dazu, Modelle auf Anfälligkeit gegenüber unsicheren Prompts zu prüfen. Das Parallel-Rails-Tutorial zeigt, wie mehrere Rails gleichzeitig laufen, um Latenz zu senken und Durchsatz zu erhöhen. Beide sind als Notebooks abgelegt, nicht als deploybare Dienste, und das ist ein Muster, das sich durch das ganze Repository zieht.

Wo das Repository an seine Grenzen kommt

Die größte Einschränkung ist die Abhängigkeit vom NVIDIA-Ökosystem. Der Einstieg verlangt einen NVIDIA_API_KEY, die Beispiele referenzieren NIM-Microservices, und die Data-Flywheel-Tutorials setzen eine NeMo-Installation auf Kubernetes voraus. Das ist kein verstecktes Detail, sondern der Kern des Projekts. Wer diesen Stack nicht ohnehin betreibt, baut hier eine Abhängigkeit auf, die sich später nur mit Aufwand lösen lässt. Der Nutzen liegt in der Zeitersparnis bei der Integration, nicht in der Portabilität.

Die zweite Einschränkung betrifft den Charakter des Materials. Ein erheblicher Teil besteht aus Jupyter-Notebooks. Notebooks sind gut zum Nachvollziehen und schlecht zum Betreiben. Wer den Ablauf aus agentic_rag_with_nemo_retriever_nim.ipynb in einen Dienst überführen will, muss den Code selbst extrahieren, Fehlerbehandlung ergänzen und die Zustandsführung aus dem Notebook-Kontext lösen. Das Repository liefert dafür keine Vorlage, jedenfalls nicht im dokumentierten Umfang.

Drittens die Release-Kadenz. Die drei jüngsten Releases sind v0.6.0 vom 10. Mai 2024, v0.7.0 vom 18. Juni 2024 und v0.8.0 vom 21. August 2024. Der letzte Push auf main liegt dagegen deutlich später, im August 2026. Zwischen den veröffentlichten Tags und dem Stand des Hauptzweigs liegt also ein längerer Zeitraum, in dem Änderungen offenbar ohne Release-Tag einfließen. Wer reproduzierbare Builds braucht, sollte auf einen Tag pinnen und nicht auf main setzen, sonst verschiebt sich die Basis zwischen zwei Builds. Welche Änderungen zwischen v0.8.0 und dem aktuellen main liegen, lässt sich aus dem vorliegenden Material nicht ableiten.

Alternative: Haystack oder LlamaIndex statt NIM-gekoppelter Pipelines

Der naheliegende Vergleich ist ein RAG-Framework wie Haystack oder LlamaIndex. Der Unterschied liegt nicht in der Funktionalität, sondern in der Kopplung. Haystack und LlamaIndex definieren eine Abstraktion für Retriever, Generator und Pipeline und lassen sich mit unterschiedlichen Backends betreiben, von lokalen Modellen über OpenAI bis zu gehosteten Inferenzdiensten. Der Wechsel des Modells ist dort eine Konfigurationsfrage. In GenerativeAIExamples ist der Inferenzpfad dagegen auf NIM beziehungsweise TensorRT-LLM und Triton ausgerichtet, und die Beispiele sind entsprechend zugeschnitten.

Das ist kein Nachteil, wenn man die beschleunigte Infrastruktur ohnehin betreibt. Triton Inference Server mit TensorRT-LLM ist auf Durchsatz bei hoher Last ausgelegt, und die NIM-Container verpacken dieses Setup als Dienst. Wer diesen Pfad gewählt hat, bekommt hier Beispiele, die genau dazu passen und die man in einem generischen Framework erst nachbauen müsste. Wer den Pfad noch nicht gewählt hat und offen bleiben will, sollte mit einem der Frameworks beginnen und die Inferenzschicht später austauschen. Die Entscheidung ist damit keine Geschmacksfrage, sondern eine Frage der Bindung an eine Beschleunigungsplattform.

Lizenz und Wartungsaufwand

Das Hauptrepository steht unter Apache-2.0, und die Quelldateien tragen entsprechende SPDX-Header, sichtbar etwa im README selbst mit SPDX-License-Identifier: Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation unter den üblichen Bedingungen der Lizenz, einschließlich der Pflicht, Änderungen zu kennzeichnen und den Lizenztext beizulegen. Das ist keine Rechtsberatung, und die Lizenz des Hauptrepositories sagt nichts über die eingebundenen Submodule. Genau dort liegt der Prüfpunkt: Die Vision-Workflows liegen als Submodule vor, und für jedes Submodul gilt eine eigene Lizenz, die man vor der Übernahme in ein Produkt separat prüfen muss.

Der Wartungsaufwand hängt an der Kopplung. Wer den RAG-Schnellstart nutzt, muss im Wesentlichen die Compose-Dateien, das Basis-Image und den API-Key aktuell halten. Wer die NeMo-Beispiele nutzt, muss zusätzlich die Microservices auf dem Kubernetes-Cluster pflegen. Beides skaliert mit der Geschwindigkeit, in der NVIDIA seine Container und Endpunkte aktualisiert. Da zwischen den Release-Tags und dem Hauptzweig ein längerer Zeitraum liegt, ist ein Upgrade nicht einfach ein Versionssprung: Man muss prüfen, ob die eigenen Anpassungen noch zum aktuellen Stand von main passen. Ein Upgrade-Pfad oder ein Changelog, der diese Prüfung abkürzt, ist im vorliegenden Material nicht dokumentiert.

Redaktionelles Fazit

Wer bereits NIM-Microservices oder NeMo betreibt und eine lauffähige Referenz für RAG, Tool-Calling oder Vision-Workflows sucht, bekommt hier eine Vorlage, die sich mit docker compose up -d --build im Verzeichnis RAG/examples/basic_rag/langchain/ direkt starten lässt. Wer einen herstellerneutralen RAG-Stack auf eigener Infrastruktur ohne NVIDIA_API_KEY aufbauen will, sollte zu Haystack oder LlamaIndex greifen. Vor dem ersten Commit in ein eigenes Projekt ist zu prüfen, ob der Submodule-Baum vollständig geklont wurde, welche der drei Releases v0.6.0, v0.7.0 und v0.8.0 zur eigenen NIM-Version passt und ob die Lizenzangaben der eingebundenen Submodule mit der Apache-2.0-Lizenz des Hauptrepositories vereinbar sind.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. NVIDIA/GenerativeAIExamples on GitHub
4. README
5. Releases