Souveräne KI auf einem 10 Jahre alten Office-PC: NemoClaw auf Dell OptiPlex 5040 mit eigenem Ollama-Server

Warum NemoClaw jetzt in meine KI-Werkstatt einzieht

In den letzten Wochen habe ich euch in mehreren Beiträgen gezeigt, wie ich Stück für Stück meine eigene KI-Infrastruktur aufbaue: einen lokalen Inferenz-Server mit zwei RTX A6000 GPUs unter Ollama, einen ESP-Claw auf einem Guition JC1060P470 als Embedded-Agent und einen eigenen MCP-Server für GPU-Monitoring. Alles lokal, alles ohne Cloud, alles in meiner eigenen KI-Werkstatt.

Jetzt kommt ein weiterer Baustein dazu: NVIDIA NemoClaw. Das ist eine sandboxed Umgebung für OpenClaw-Agenten, die NVIDIA seit März 2026 als Early Preview bereitstellt die NVIDIAs OpenShell verwendet. Die Idee dahinter ist spannend: Ein KI-Agent läuft in einer isolierten Sandbox mit eigenen Network Policies und Capability-Beschränkungen, und die Inferenz wird über ein Gateway auf den eigentlichen LLM-Provider geroutet. Mit anderen Worten: Ich kann meinen eigenen Ollama-Server als Inferenz-Backend nutzen und gleichzeitig den Komfort einer fertigen Agenten-Umgebung haben.

In diesem Beitrag zeige ich euch Schritt für Schritt, wie ich NemoClaw auf einem frisch installierten Ubuntu 24.04 aufsetze, und zwar bewusst auf einer Maschine ohne GPU. Die Inferenz übernimmt mein bestehender Ollama-Server (192.168.2.57). Damit ist NemoClaw bei mir nicht ein „GPU braucht GPU“-Projekt, sondern eine schlanke Agenten-Schicht, die meine vorhandene Inferenz-Hardware nutzt.

Hier ein Bild aus meiner KI-Werkstatt und dem NemoClaw – OpenClaw setup auf meinem Werkstatt-Rechner.

NemoClaw AI Workshop

Meine Test-Hardware: ein gebrauchter Dell OptiPlex 5040

Damit klar ist, auf was für einer Maschine ich NemoClaw aufsetze, hier kurz mein Setup:

• Dell OptiPlex 5040 – ein knapp zehn Jahre alter Office-PC aus der gebrauchten Hardware-Ecke (vorgestellt 2015/2016)
• 4 CPU-Kerne
• 32 GB RAM (33,5 GB nach Anzeige, im Leerlauf knapp 5 % belegt)
• 8,6 GB Swap
• Keine dedizierte GPU – das ist hier ganz bewusst so
• Frisch installiertes Ubuntu 24.04 LTS

Der Punkt, der mir wichtig ist: Das ist keine teure KI-Workstation. Das ist ein ganz normaler gebrauchter Office-PC, wie man ihn auf Kleinanzeigen-Plattformen heute für unter 150 Euro bekommt. Genau das ist für mich der Charme dieses Setups: Die schwere Inferenz-Arbeit übernimmt mein bestehender A6000-Server, und der OptiPlex ist nur die schlanke Agenten-Schicht obendrauf. Wer einen Inferenz-Server im LAN hat, kann den Rest mit minimaler und sehr günstiger Hardware aufbauen.

Damit ist meine Maschine deutlich über dem NemoClaw-Minimum (8 GB RAM, 4 vCPUs) und sogar oberhalb der Empfehlung (16 GB RAM). Während des Image-Push muss ich mir um den OOM-Killer also keine Sorgen machen, und mit 32 GB RAM habe ich genug Luft, später auch noch weitere Container-Workloads parallel laufen zu lassen.

Worum geht es bei NemoClaw?

Bevor wir loslegen, kurz die Architektur. Wer das Konzept verstanden hat, spart sich später viel Verwirrung beim Onboarding-Wizard.

NemoClaw besteht aus mehreren Schichten:

• OpenClaw: das ist der eigentliche Agent, der Fragen beantwortet, Tools aufruft und Aufgaben erledigt.
• OpenShell: die NVIDIA Sandbox-Runtime, in der OpenClaw läuft. Stellt Isolation, Network-Policies und Capability-Drops bereit.
• NemoClaw: die Schicht darüber die ebenfalls von NVIDIA bereitgestellt wird: Onboarding, Inferenz-Routing, Provider-Management, Sicherheitsrichtlinien.

Wichtig für unser Setup: Der Agent in der Sandbox spricht intern immer mit der Adresse inference.local. Das OpenShell-Gateway fängt diesen Traffic auf dem Host ab und leitet ihn an den Provider weiter, den wir beim Onboarding gewählt haben. Das heißt, die Sandbox sieht meine echte Ollama-Adresse 192.168.2.57 nie. Auch der API-Key bleibt auf dem Host. Das ist ein sauberer Sicherheitspfad.

Voraussetzungen

Bevor wir loslegen, ein paar Dinge, die in Ordnung sein müssen:

• Ubuntu 24.04 LTS, frisch installiert
• Mindestens 8 GB RAM (besser 16 GB), 20 GB freier Disk-Speicher (besser 40 GB), 4 vCPUs
• Ein laufender Ollama-Server im LAN, der vom NemoClaw-Host aus erreichbar ist
• Ein OpenAI-kompatibler API-Endpunkt auf diesem Ollama-Server (in meinem Fall http://192.168.2.57:11434/v1)
• Sudo-Rechte auf der Ubuntu-Maschine, damit wir Docker installieren können

Ein wichtiger Hinweis vorab: NemoClaw ist Alpha-Software. Die README sagt das ganz offen, und das gilt auch im Mai 2026 noch. Interfaces, Flag-Namen und das Aussehen des Onboarding-Wizards können sich ohne Vorwarnung ändern. Was ich euch hier zeige, ist der Stand zum Zeitpunkt meiner Installation. Wenn ihr das in einigen Wochen nachbaut, kann der ein oder andere Schritt leicht anders aussehen.

Phase 0: System vorbereiten und Reachability prüfen

Erst einmal das Ubuntu-System auf den aktuellen Stand bringen und ein paar Basis-Tools installieren:

Befehl: sudo apt update && sudo apt upgrade -y

Befehl: sudo apt install -y curl git ca-certificates gnupg lsb-release

Jetzt der Reality-Check, ob mein Ollama-Server vom neuen Host aus überhaupt erreichbar ist. Den Schritt überspringe ich nicht: Es lohnt sich nicht, NemoClaw aufzusetzen, wenn die Inferenz-Strecke später nicht steht.

Befehl: curl http://192.168.2.57:11434/v1/models

Wenn ich eine JSON-Antwort mit meiner Modell-Liste zurückbekomme, ist die Netzwerk-Strecke frei. Falls nicht: Firewall prüfen, Ollama mit OLLAMA_HOST=0.0.0.0 starten, Routing im LAN verifizieren – und erst weitermachen, wenn die Antwort sauber kommt.

Phase 1: Docker installieren

NemoClaw verlangt Docker als Container-Runtime. Auf Ubuntu 24.04 ist der saubere Weg über die offizielle Docker-Apt-Quelle. Erst den GPG-Schlüssel ablegen:

Befehl: sudo install -m 0755 -d /etc/apt/keyrings

Befehl: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Befehl: sudo chmod a+r /etc/apt/keyrings/docker.gpg

Dann das Docker-Repository hinzufügen. Wenn Du den Befehl unten kopierts dann musst Du die \ loeschen und jeweils ein Leerschritt sonst kommt es zu einem Fehler:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Und schließlich die Docker-Pakete installieren:

Befehl: sudo apt update

Befehl: sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Damit ich Docker später ohne sudo benutzen kann, füge ich meinen User der Docker-Gruppe hinzu und übernehme die Gruppe direkt in die aktuelle Shell:

Befehl: sudo usermod -aG docker $USER

Befehl: newgrp docker

Zum Abschluss ein schneller Test:

Befehl: docker run --rm hello-world

Wenn die Hello-World-Ausgabe erscheint, läuft Docker und wir können zu NemoClaw weitergehen.

Phase 2: NemoClaw-Installer ausführen

Bevor ich den Installer starte, setze ich die API-Key-Umgebungsvariable, die NemoClaw für „Other OpenAI-compatible endpoint“ erwartet. Ollama selbst braucht keinen echten Key, aber das Feld muss laut Doku gefüllt sein. Ich nehme einen sprechenden Dummy-Wert:

Befehl: export COMPATIBLE_API_KEY=ollama

Bei mir kam es zu einem Fehler bei dem ersten Versuch der Installation von NemoClaw da die binutils als Paket auf meinem frisch installierten Linux gefehlt haben.

Befehl: sudo apt install -y binutils

Jetzt der Hauptschritt. Der Installer übernimmt selbst die Node.js-Installation über nvm und installiert NemoClaw via npm, alles im User-Home – es braucht hier kein vorgestelltes sudo:

Befehl: curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

Der interaktive Wizard führt mich jetzt durch mehrere Entscheidungen. Auf einer Maschine ohne GPU bekomme ich vom Wizard die Standard-Provider-Liste angeboten. Hier muss ich aufpassen, die richtige Option zu wählen – und das ist nicht „Local Ollama“, weil diese Option laut Doku ausdrücklich nur für ein localhost:11434 auf demselben Rechner gedacht ist.

Stattdessen wähle ich:

• Option 3: Other OpenAI-compatible endpoint

NemoClaw – Inference Provider setup

Der Wizard fragt dann zwei Dinge ab:

• Base URL: http://192.168.2.57:11434/v1
• Model name: einen exakten Slug aus ollama list auf meinem Inferenz-Server. Für den ersten Test nehme ich qwen3.6:27b, weil das ein kleines, schnelles Modell mit Tool-Calling-Support ist. Das nächst größere Modell wie qwen3.6:35b kommen erst, wenn die Kette stabil läuft.

NemoClaw validiert den Endpunkt sofort, indem es eine echte Inferenz-Anfrage über die ganze Strecke schickt. Anschließend habe ich als Sandboxnamen openclawbox gewählt.

NemoClaw – sandbox name

Am Ende des Onboardings sehe ich einen Summary-Block mit dem Sandbox-Namen und dem gewählten Modell. Damit ist die Grund-Installation durch.

Tatsächlicher Disk-Bedarf (gemessen): Die NemoClaw-CLI selbst belegt bei mir etwa 3,3 GB (Node.js, npm-Dependencies, OpenShell-Binaries). Das eigentliche OpenClaw-Sandbox-Image kommt erst beim ersten nemoclaw onboard dazu und schlägt mit weiteren rund 10–12 GB zu Buche. Insgesamt solltest du also mit etwa 15 GB Disk-Nutzung rechnen, plus Puffer für Logs und Updates.

Nach der Installation und Konfiguration habe ich folgende Ausgabe angezeigt bekommen.

NemoClaw ready to run

Wenn das alles soweit geklappt hat empfehle ich noch die COMPATIBLE_API_KEY-Variable dauerhaft in der Shell zu setzen. Sonst scheitern später nicht-interaktive Operationen wie nemoclaw openclawbox rebuild --yes mit der Meldung, dass der API-Key fehlt. Das geht mit den folgenden zwei Befehlen:

Befehl: echo 'export COMPATIBLE_API_KEY=ollama' >> ~/.bashrc

Befehl: source ~/.bashrc

Phase 3: Den Agenten zum ersten Mal ansprechen

Jetzt der spannende Moment: Funktioniert die ganze Kette? Nach Abschluss des Onboardings zeigt mir NemoClaw direkt im Terminal an, wie ich mit dem Agenten sprechen kann. Es gibt zwei Wege: über den Browser oder über das Terminal.

Vorbereitung – Sandbox läuft?

Direkt nach dem Onboarding-Wizard ist die Sandbox aktiv und das OpenClaw-Gateway bereit. Ihr könnt also gleich loslegen. Falls ihr den Rechner zwischenzeitlich neugestartet, das Terminal geschlossen oder die Sandbox per exit verlassen habt, müsst ihr vor dem nächsten Schritt die Sandbox erst wieder hochfahren. Das macht ihr mit dem folgenden Befehl:

Befehl: nemoclaw openclawbox connect

Damit fährt das OpenShell-Gateway hoch und das OpenClaw-Gateway in der Sandbox wird gestartet. Nach dem Befehl landet ihr im Sandbox-Prompt sandbox@xxxx:~$. Im jetzt folgenden Text stelle ich euch zwei Varianten vor, wie ihr mit NemoClaw arbeiten könnt.

Für Variante A („Browser“) verlasst ihr die Sandbox direkt wieder mit exit. Dabei bleibt der Dashboard-Forward auf 127.0.0.1:18789 aktiv und der Browser-Zugriff funktioniert am OpenClaw Host System.

Für Variante B („Terminal“) bleibt ihr in der Sandbox und tippt direkt openclaw tui ein um die Text-Eingabe also den Text Modus zu starten.

Die ausführliche Reboot-Routine die ihr braucht wenn der ganze OpenClaw Host neu gestartet wurde folgt weiter unten im Abschnitt „Nach einem Neustart“.

Variante A: Browser (am bequemsten)

NemoClaw startet eine lokale Web-Oberfläche und gibt mir die URL direkt im Terminal aus:

URL: http://127.0.0.1:18789/

Diese URL im Browser auf dem NemoClaw-Host öffnen. Jetzt werdet ihr nach einem Auth-Token gefragt das ihr aus Sicherheitsgründen heraus benötigt damit nicht jeder im Netzwerk euren OpenClaw bedienen kann. Das Browserfenster sollte jetzt wie folgt aussehen.

OpenClaw Auth-Token Browser UI

Das Token das ihr jetzt braucht steht in der Datei /sandbox/.openclaw/openclaw.json innerhalb der Sandbox. Mit dem folgenden Befehl könnt ihr es euch anzeigen lassen:

Befehl: grep -A 3 "auth" /sandbox/.openclaw/openclaw.json

Die Ausgabe im Terminal-Fenster sah bei mir wie folgt aus:

sandbox@1841e00e8875:~$ grep -A 3 "auth" /sandbox/.openclaw/openclaw.json
    "auth": {
      "token": "eJ6AjBbDC85w1se6YLjTx6tpie3bDrTV4Lcs_2x8JOM"
    }
  },

Wenn ihr das Token, hier bei mir lautet es eJ6AjBbDC85w1se6YLjTx6tpie3bDrTV4Lcs_2x8JOM, heraus kopiert habt fügt ihr es im Browser in das Feld „Gateway Token“ ein und klickt auf Connect. Damit landet ihr direkt im Chat-Frontend von OpenClaw. Das sieht dann wie im folgenden Bild aus.

OpenClaw Web Frontend

Der Browser merkt sich das Token für die aktuelle Session. Solange ihr den Tab nicht schließt oder den Browser-Storage nicht leert, müsst ihr das Token nicht erneut eingeben. Das Token selbst bleibt übrigens stabil – auch nach einem Reboot des Host-Rechners oder nach stop/connect-Zyklen. Erst ein nemoclaw openclawbox rebuild würde ein neues Token generieren.

Zugriff aus dem LAN: SSH-Tunnel vom Arbeitsrechner

Wenn ich von einem anderen Rechner im Netzwerk auf das Dashboard zugreifen möchte – zum Beispiel von meinem Windows-Arbeitsplatz aus – reicht der Aufruf von http://127.0.0.1:18789/ auf dem Arbeitsrechner natürlich nicht, denn dort läuft kein NemoClaw. Der NemoClaw-Dashboard-Port bindet auf dem Host außerdem standardmäßig nur an Loopback. Aus Sicherheits­gründen ist das auch sinnvoll.

Laut Doku sollte für LAN-Zugriff die Umgebungs­variable NEMOCLAW_DASHBOARD_BIND=0.0.0.0 vor dem nemoclaw connect reichen. In meiner installierten Version hat das aber nicht funktioniert denn der Port blieb auf 127.0.0.1 gebunden. Ich habe dann versucht, den Forward mit openshell forward start --background 0.0.0.0:18789 openclawbox manuell umzubiegen. Das öffnet zwar den Port im LAN, hat aber eine unangenehme Nebenwirkung: Der manuell aufgesetzte Forward blockiert den Port, den das interne OpenClaw-Gateway in der Sandbox eigentlich selbst nutzen will. Wir landen also in einer Sackgasse.

Der saubere und zuverlässige Weg für LAN-Zugriff ist daher: ein SSH-Tunnel vom Arbeitsrechner zum NemoClaw-Host. Damit bleibt der Loopback-Bind auf dem NemoClaw-Host unangetastet, und der Browser auf meinem Windows-Rechner sieht das Dashboard so, als käme die Verbindung vom Loopback-Interface.

Schritt 1: SSH-Server auf dem NemoClaw-Host bereitstellen. Falls noch nicht geschehen, installiere ich auf dem OptiPlex den OpenSSH-Server:

Befehl: sudo apt install -y openssh-server

Befehl: sudo systemctl enable --now ssh

Schritt 2: SSH-Tunnel vom Arbeitsrechner aufbauen. Auf meinem Windows-Rechner öffne ich eine PowerShell und führe den folgenden Befehl aus. Diesen müsst ihr natürlich anpassen so das Benutzername und IP-Adresse zu eurem NemoClaw Host passen:

Befehl: ssh -L 18789:127.0.0.1:18789 ingmar@192.168.178.142

Damit baue ich einen lokalen Tunnel auf: Anfragen auf meinem Windows-Rechner an 127.0.0.1:18789 werden durch die SSH-Verbindung an den NemoClaw-Host weitergeleitet, wo sie auf 127.0.0.1:18789 ankommen. Aus Sicht des Dashboards kommt die Verbindung also über Loopback – genau wie wenn ich direkt am NemoClaw-Host sitzen würde.

Schritt 3: Browser auf dem Arbeitsrechner öffnen. Im Browser auf meinem Windows-Rechner rufe ich jetzt genau diese IP-Adresse und Port auf:

URL: http://127.0.0.1:18789/

Auch hier erscheint die Auth-Maske – schließlich ist der Browser auf dem Windows-Rechner ein anderer Browser als der auf dem OptiPlex und kennt das Token noch nicht. Ich trage dasselbe Gateway-Token ein, das ich oben aus /sandbox/.openclaw/openclaw.json ausgelesen habe, klicke auf Connect und lande im Chat-Frontend. Solange die SSH-Verbindung offen ist, bleibt der Zugriff bestehen.

Bonus: Die Verbindung ist durch SSH verschlüsselt. Das macht den Zugriff auch in unsicheren WLANs unbedenklich. Ich kann den SSH-Tunnel mit demselben Befehl auch von unterwegs über mein VPN aufbauen, solange der NemoClaw-Host per SSH erreichbar ist.

Stolperstein, wenn der NemoClaw-Host neu aufgesetzt wurde: SSH speichert beim ersten Verbinden den Host-Key des Servers in known_hosts. Wird der Host neu aufgesetzt, ändert sich dieser Key, und SSH verweigert die Verbindung mit der Warnung „REMOTE HOST IDENTIFICATION HAS CHANGED!“. Das ist ein gutes Sicherheits­verhalten – aber in unserem Fall völlig harmlos, weil wir den Host ja selbst neu aufgesetzt haben. Den alten Eintrag lösche ich mit dem folgenden Befehl auf dem Arbeitsrechner:

Befehl: ssh-keygen -R 192.168.178.142

Beim nächsten ssh -L-Aufruf fragt SSH dann sauber nach dem neuen Host-Key, und ich bestätige mit yes.

Variante B: Terminal (für die Maker-Seele)

Ich verbinde mich mit der Sandbox. Wichtig dabei ist der Sandbox-Name, den ihr beim Onboarding vergeben habt. Bei mir ist das openclawbox (das ist der Default, falls man nichts anderes eingibt):

Befehl: nemoclaw openclawbox connect

Damit lande ich in der Sandbox-Shell. Dort starte ich die OpenClaw-TUI:

Befehl: openclaw tui

Wenn die TUI startet und ich eine Nachricht abschicken kann, die tatsächlich von meinem Ollama auf 192.168.2.57 beantwortet wird, steht die komplette Kette: Sandbox → OpenShell-Gateway → Ollama → Modell-Antwort → zurück durch die Kette.

Bei mir hat alles funktioniert und mein Inferenz-Server wurde angesprochen und das LLM entsprechend geladen und die ersten Tokens für den NemoClaw generiert.

NemoClaw running and inferencing

Nach einem Neustart: NemoClaw wieder hochfahren

Eine Sache, die mir beim ersten Neustart des OptiPlex sofort aufgefallen ist: NemoClaw startet nach einem Reboot des Hosts nicht automatisch wieder mit hoch. Docker selbst kommt zwar als systemd-Service zurück, aber das OpenShell-Gateway und der Sandbox-Container müssen manuell wieder ans Netz.

Symptom: Wenn ich direkt nach dem Reboot versuche, mich mit der Sandbox zu verbinden oder den Forward zu prüfen, bekomme ich einen Connection refused-Fehler. Das Gateway antwortet nicht, weil es schlicht nicht läuft. Die Lösung ist einfach aber manuell. Ich muss die Sandbox mit dem connect-Befehl neu starten:

Befehl: nemoclaw openclawbox connect

NemoClaw erkennt selbst, dass die Sandbox neu gestartet werden muss, und gibt das auch direkt aus: „OpenClaw gateway is not running inside the sandbox (sandbox likely restarted). Recovering…“. Das OpenShell-Gateway wird hochgefahren, der Sandbox-Container gestartet, das OpenClaw-Gateway in der Sandbox initialisiert, und am Ende lande ich automatisch im Sandbox-Prompt. Im Kern ist das dieselbe Routine wie bei der Vorbereitung zu Beginn der Phase 3 – nur halt eben aus einem komplett kalten Zustand.

Mein typischer Ablauf nach einem Reboot besteht damit aus drei kleinen Schritten:

1. nemoclaw openclawbox connect auf dem Host dann fährt die Sandbox hoch und ich lande direkt im Sandbox-Prompt.
2. Mit exit verlasse ich die Sandbox-Shell und bin zurück auf dem Host. Der Dashboard-Forward auf 127.0.0.1:18789 bleibt aktiv.
3. Vom Arbeitsrechner aus öffne ich jetzt einen SSH-Tunnel zu dem NemoClaw Rechner: ssh -L 18789:127.0.0.1:18789 ingmar@192.168.178.142 . Sobald der SSH-Tunnel steht kann ich im Browser meines Arbeitsrechners http://127.0.0.1:18789/ aufrufen und sehe im Browser die OpenClaw Web-Oberfläche.

Das ist machbar, aber für einen Maker-Workflow nicht ideal. In einem Folge-Beitrag werde ich daraus einen systemd-Service bauen, der NemoClaw beim Boot des OptiPlex automatisch hochfährt. Dann reicht ein Druck auf den Power-Knopf, der SSH-Tunnel vom Arbeitsrechner muss noch aufgebaut werden, und das Dashboard ist im Browser erreichbar. Das dann alles ohne weitere manuelle Schritte auf dem Host unter Einhaltung der NemoClaw Sicherheitsvorgaben.

Status, Logs, Modellwechsel

NemoClaw zeigt am Ende der Installation gleich die wichtigsten Verwaltungs-Befehle an, die für mich später relevant werden:

• Status prüfen: nemoclaw openclawbox status
• Logs verfolgen: nemoclaw openclawbox logs --follow
• Modell wechseln (ohne Re-Onboarding): nemoclaw inference set --model <modell> --provider <provider> --sandbox openclawbox
• Network Policies anpassen: nemoclaw openclawbox policy-add

Genau diese Befehle nutze ich später, um zwischen meinen Ollama-Modellen zu wechseln und der Sandbox Zugriff auf weitere Endpunkte zu erlauben.

Was kommt als Nächstes?

Mit diesem Setup habe ich eine sandboxed OpenClaw-Instanz auf einer schlanken Ubuntu-Maschine, die meinen bestehenden Ollama-Server als Inferenz-Backend nutzt. Damit sind mehrere spannende Folge-Experimente möglich, die ich in den nächsten Beiträgen Stück für Stück angehe:

• Automatischer Start beim Boot: Aktuell muss ich nach jedem Reboot manuell die Sandbox hochfahren. Im nächsten Beitrag baue ich daraus einen systemd-Service, der NemoClaw beim Boot automatisch startet.
• Modelle ohne Re-Onboarding wechseln: Die NemoClaw-Doku verweist auf nemoclaw inference set als Mechanismus, das Modell zur Laufzeit zu wechseln. Ich werde nacheinander qwen3.6:27b, nemotron3:33b und qwen3.6:35b durchprobieren und Tool-Calling-Verhalten und Antwortzeiten vergleichen.
• Network Policies anpassen: NemoClaw bringt restriktive Egress-Regeln mit. Mich interessiert, wie ich der Sandbox erlaube, mit meinem eigenen MCP-Server (192.168.2.57:8765) zu sprechen – das wäre die Brücke zwischen NemoClaw und meiner bestehenden GPU-Monitoring-Infrastruktur.
• Model Router ausprobieren: Die experimentelle Model-Router-Funktion von NemoClaw routet je nach Query-Komplexität auf unterschiedliche Modelle in einem Pool. Das ist konzeptionell genau das, was ich für effizienten LLM-Einsatz in meiner Werkstatt brauche.

Mein persönliches Fazit

Was mich an NemoClaw überzeugt: Es ist keine reine NVIDIA-Cloud-Schiene. Im Gegenteil das Konzept „Sandbox plus generisches OpenAI-kompatibles Backend“ passt erstaunlich gut zur Idee einer souveränen KI in der eigenen Werkstatt. Ich kann die Sandboxing-Vorteile von NVIDIA nutzen, aber meine eigene Inferenz behalten. Keine Cloud-API, kein API-Key bei einem Drittanbieter, kein Cloud-Abo. Mein Ollama-Server bleibt das Herzstück, NemoClaw ist die Schicht obendrauf.

Im nächsten Beitrag teile ich meine ersten Erfahrungen mit dem laufenden System: Wie reagiert die Sandbox auf verschiedene Modelle? Wie sehen die Antwortzeiten aus, wenn die Anfrage über zwei Hops geht (NemoClaw-Host zu Ollama-Server)? Und vor allem: Bekomme ich die Sandbox dazu, mit meinem eigenen MCP-Server zu sprechen?

Bis dahin: Viel Erfolg beim Nachbauen, und meldet euch gerne in den Kommentaren.

Wir lesen uns im nächsten Teil!