NemoClaw sur DGX Spark

1 Installation

La commande officielle est simple, mais sur le DGX Spark il y a un prérequis à connaître.

Le problème : droits npm

La commande curl -fsSL https://nvidia.com/nemoclaw.sh | bash échoue si npm tente d'écrire dans /usr/lib/node_modules/. Pas question d'utiliser sudo pour ça.

# 1. Creer un dossier global npm dans votre home
mkdir -p ~/.npm-global

# 2. Configurer npm pour l'utiliser
npm config set prefix ~/.npm-global

# 3. Ajouter le bin au PATH (persistant)
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

# 4. Lancer l'install NemoClaw (sans sudo)
curl -fsSL https://nvidia.com/nemoclaw.sh | bash

Plus jamais besoin de sudo pour les npm install -g.

2 Le port 8080 & le tunnel Cloudflare

NemoClaw utilise le port 8080 pour exposer le service OpenClaw. Point important à connaître avant l'installation.

Ce que fait NemoClaw avec le port 8080

NemoClaw lance la gateway OpenShell sur le port 8080 (HTTPS). C'est le point d'entrée principal : le dashboard, l'API, et les connexions WebSocket passent tous par ce port. Si un autre service l'occupe déjà sur votre machine, l'installation bloquera avec l'erreur Port 8080 is not available.

Le tunnel Cloudflare : accès distant

Une fois installé, nemoclaw start lance automatiquement un tunnel Cloudflare éphémère (trycloudflare.com) qui expose votre dashboard sur une URL publique :

L'URL change à chaque nemoclaw start. Pour avoir une URL fixe (indispensable si vous voulez piloter l'agent depuis Telegram, Discord, etc.), vous pouvez configurer un tunnel Cloudflare permanent sur votre propre domaine — exactement comme pour n'importe quel service auto-hébergé.

Mon choix : tester en local d'abord

Moi j'ai préféré pour commencer tester avec un accès à OpenClaw en local sur localhost, via un tunnel SSH depuis mon Mac :

ssh -L 18789:127.0.0.1:18789 -L 8080:127.0.0.1:8080 -N -f spark

Puis ouvrir http://127.0.0.1:18789 dans le navigateur. Simple, sécurisé, pas besoin de tunnel Cloudflare pour découvrir le dashboard.

De plus, il faut forwarder les deux ports (18789 pour le dashboard ET 8080 pour la gateway) sinon le dashboard s'affiche mais reste en "Disconnected from gateway".

3 Le script install.sh

L'URL nvidia.com/nemoclaw.sh redirige vers GitHub. Voici ce qu'il fait réellement.

Premier lancement — erreur "Port 8080 is not available"

4 Onboarding en 7 étapes

Une fois le script terminé, nemoclaw onboard prend le relais avec un assistant interactif.

1. Preflight checks — Vérifie Docker, installe openshell CLI v0.0.12, détecte le GPU (1 GPU, 124 610 MB VRAM)
2. Starting OpenShell gateway — Lance la gateway sur le port 8080 (HTTPS)
3. Creating sandbox — Build une image Docker en 22 étapes (node:22-slim + Python 3 + deps). Image de 1545 MiB
4. Configuring inference (NIM) — Demande la clé API NVIDIA (nvapi-*), stockée dans ~/.nemoclaw/credentials.json (mode 600)
5. Setting up inference provider — Choix du modèle cloud. 6 options dont Nemotron 3 Super 120B
6. Setting up OpenClaw inside sandbox — Lance la gateway interne au sandbox
7. Policy presets — Configure les accès réseau du sandbox (npm, pypi, slack, telegram, discord, etc.)

Lancement réussi après libération du port 8080

Choix du modèle (Nemotron 3 Super 120B) et configuration des policy presets

5 Le modèle : cloud par défaut, local possible

Point important : par défaut, le LLM qui fait tourner l'agent ne tourne PAS sur le DGX Spark. Mais on peut changer ça.

Le choix du modèle à l'installation

À l'étape [5/7] de l'onboarding, NemoClaw demande une clé API NVIDIA (générée sur build.nvidia.com/settings/api-keys, format nvapi-*) puis propose 6 modèles cloud :

J'ai choisi le Nemotron 3 Super 120B (choix par défaut). Voici ses caractéristiques :

Comment ça marche concrètement

L'agent envoie ses prompts à la route inference.local, qui est en fait un proxy vers l'API integrate.api.nvidia.com. Le modèle tourne sur les GPU de NVIDIA dans le cloud, pas sur votre DGX Spark. La clé API authentifie les requêtes, et les coûts sont actuellement inclus (affichés à 0 dans le dashboard Usage).

Et en local ? Ça marche !

J'ai testé : le DGX Spark peut faire tourner le Nemotron 3 Super 120B en local via Ollama, entièrement sur le GPU. Le modèle (86 Go en quantification Q4) tient confortablement dans les 128 Go de mémoire unifiée.

Surprise : le Super (120B) est plus rapide que le Nano (30B) ! C'est grâce à l'architecture Mixture-of-Experts — seuls 12B paramètres sont actifs par forward pass, ce qui le rend plus efficace que le Nano dense (30B actifs).

Switcher cloud / local

Le switch se fait en une commande, sans redémarrage :

# Passer en local (Nemotron 3 Super sur GPU)
openshell inference set --provider ollama-local --model nemotron-3-super --no-verify

# Revenir au cloud NVIDIA
openshell inference set --provider nvidia-nim --model nvidia/nemotron-3-super-120b-a12b --no-verify

# Verifier quel modele est actif
openshell inference get

Anecdote : le modèle ne se connaît pas

Détail amusant : quand on demande au Nemotron 3 Nano "quel modèle es-tu ?", il répond "Nemotron 3 Super 120B, un modèle dense de 120 milliards de paramètres". Tout est faux : il n'est pas le Super, il n'est pas dense, et il n'a pas 120B paramètres. Le vrai Super, lui, connaît au moins son nom mais hallucine aussi sur ses specs. Les LLMs ne se connaissent pas eux-mêmes !

6 Architecture

NemoClaw est une matriochka : un conteneur dans un cluster Kubernetes dans Docker.

7 Processus en fonctionnement

Un ps aux | grep claw révèle 6 processus interconnectés.

8 À l'intérieur du sandbox

nemoclaw dgx-assistant connect donne un shell dans l'environnement isolé.

Connexion au sandbox — home /sandbox avec .nemoclaw, .openclaw, .npm

9 Accès au dashboard

Le dashboard OpenClaw tourne dans le sandbox. Deux façons d'y accéder :

# Forwarder les DEUX ports (dashboard + gateway)
ssh -L 18789:127.0.0.1:18789 -L 8080:127.0.0.1:8080 -N -f spark

# Ouvrir dans le navigateur (127.0.0.1, PAS localhost !)
open http://127.0.0.1:18789

10 Overview

Tableau de bord principal : santé, connexion, compteurs.

Status OK, uptime 2h, 1 session active, cron enabled. C'est ici qu'on entre le token pour se connecter à la gateway via WebSocket.

11 Chat

Interface de conversation directe avec l'agent, en temps réel dans le navigateur.

On voit ici la session heartbeat : toutes les 30 minutes, l'agent lit HEARTBEAT.md et répond HEARTBEAT_OK si rien ne nécessite d'attention. C'est le pouls de l'agent.

12 Channels — 8 plateformes

La fonctionnalité la plus impressionnante : piloter l'agent depuis n'importe quelle messagerie.

13 Instances

Qui est connecté à la gateway en ce moment.

Deux instances : la gateway elle-meme (dgx-assistant, Linux arm64, kernel 6.17) et notre navigateur (openclaw-control-ui, role operator avec droits admin/approvals/pairing).

14 Sessions

Gestion fine des sessions de conversation et de leurs paramètres.

Par session, on peut régler le niveau de Thinking (off → xhigh), le mode Verbose, et le Reasoning. C'est le fine-tuning comportemental de l'agent.

15 Usage

Tracking de la consommation de tokens et des coûts.

Filtres temporels, vue tokens/coûts, export. Avec Nemotron via NIM, les coûts affichent 0 — l'inférence cloud NVIDIA est incluse.

16 Cron Jobs

Planifier des tâches automatiques avec delivery sur n'importe quel canal.

Création de jobs avec schedule (every/at/cron), choix de session (main ou isolée), mode d'exécution, timeout, et delivery (announce dans le chat, webhook POST, ou interne). On peut par exemple programmer un brief quotidien envoyé sur Telegram.

17 Agents

Configuration du workspace, de l'identité et du modèle de l'agent.

Un agent "main" avec le modèle Nemotron 3 Super 120B (context 131K). Sous-onglets : Overview, Files, Tools, Skills, Channels, Cron Jobs.

18 Tools — 25 outils

L'arsenal de l'agent, tous activés par défaut (profil "full").

19 Skills — 51 compétences

De GitHub à Spotify en passant par les lampes Philips Hue et les lits Eight Sleep.

Skills immédiatement disponibles (3)

Catalogue complet des 51 skills

Un mot sur la sécurité des skills

En pratique, les skills se répartissent en trois niveaux de confiance :

De plus, une faille connue (Issue #272) fait que les presets de policies n'ont pas de champ binaries: — ce qui signifie que n'importe quel processus dans le sandbox peut utiliser les endpoints autorisés, pas juste le binaire prévu. À garder en tête si vous activez des skills qui accèdent à des services sensibles.

En résumé : traitez chaque skill comme vous traiteriez un plugin dans n'importe quel écosystème — vérifiez ce qu'il installe et à quoi il accède avant de l'activer.

20 Nodes & Sécurité

Contrôle d'accès, appareils pairés, et policies d'exécution.

Par défaut : mode Deny avec Ask on miss. L'agent demande confirmation avant d'exécuter une commande non prévue. Sécurisé par design.

21 Config

Éditeur visuel complet du fichier openclaw.json.

11 catégories : Environment, Updates, Agents, Authentication, Channels, Messages, Commands, Hooks, Skills, Tools, Gateway. Mode Form ou Raw JSON.

22 Debug & Logs

Pour les power users : snapshots JSON, RPC manuel, et logs en direct.

90+ methodes RPC disponibles : chat.send, cron.add, config.patch, sessions.list, skills.install, tts.convert, browser.request...

Logs temps réel avec filtres par niveau (trace → fatal), auto-follow, recherche, et export. Format JSONL avec metadata complètes.

23 En pratique : "Installe-moi un générateur de musique"

Pour tester l'agent en conditions réelles, je lui ai demandé d'installer un modèle de génération musicale locale. Le résultat est très instructif.

Ce que l'agent a fait (en ~7 minutes)

L'agent explore l'environnement, exécute nvidia-smi, détecte les contraintes du sandbox

Le verdict de l'agent

Le proxy du sandbox bloque l'accès à PyPI — le système de policies fait son travail

Ce que ca nous apprend

L'agent est impressionnant : en 7 minutes, sans aucune aide, il a identifié le bon projet (AudioCraft/MusicGen de Meta), cloné le repo, créé un virtualenv Python, lu la documentation, et tenté l'installation. Quand il bloque, il diagnostique proprement les 3 causes et propose des solutions.

Le sandbox fait son travail : les network policies empêchent l'agent d'installer n'importe quoi depuis Internet. C'est la sécurité by design — pas de sudo, pas d'accès libre à PyPI, pas de visibilité sur le GPU hôte. Pour aller au bout, il faudrait configurer correctement le proxy pour autoriser pypi.org et download.pytorch.org dans les policies.

Deuxième tentative : le bug PyPI confirmé

Après investigation, j'ai découvert que le blocage PyPI est un bug connu de NemoClaw (Issue #481 sur GitHub). Le preset pypi est bien marqué comme "appliqué" dans NemoClaw, mais les règles ne sont jamais réellement propagées au proxy du sandbox.

J'ai tenté plusieurs approches :

1. Réappliquer le preset pypi via nemoclaw policy-add → preset marqué OK, mais proxy toujours en 403
2. Appliquer une policy YAML custom via openshell policy set avec pypi.org et files.pythonhosted.org → dit "loaded" mais hosts inchangés
3. Recréer le sandbox from scratch via nemoclaw onboard → même résultat sur un sandbox neuf

Même erreur sur un sandbox fraîchement créé — le bug est confirmé (Issue #481)

La vérification sur les issues GitHub confirme que c'est un problème connu, rapporté par d'autres utilisateurs sur macOS et WSL2. NemoClaw est en alpha ("single-player mode") et ce type de bug est attendu à ce stade.

Conclusion : prometteur, mais pas encore prêt pour la confiance aveugle

Après plusieurs heures d'exploration intensive, voici mon bilan honnête.

Ce qui est impressionnant

NemoClaw est une plateforme d'agent IA autonome complète : multi-canal (WhatsApp, Telegram, Discord, Slack, Signal, iMessage, Google Chat, Nostr), 25 outils, 51 skills, cron jobs, dashboard web, et une architecture sandbox sécurisée. Le modèle Nemotron 3 Super 120B tourne à 17.6 tokens/seconde entièrement en local sur le GPU du DGX Spark — zéro dépendance cloud, zéro coût. Le switch cloud/local se fait en une commande sans redémarrage.

Ce qui pose question

Mon verdict

NemoClaw est super prometteur. La combinaison d'un modèle open-source gratuit (Nemotron 3 Super 120B via NVIDIA NIM, ou en local sur le GPU), d'une plateforme d'agent autonome complète (OpenClaw), et d'une couche de sécurité innovante (OpenShell) est unique sur le marché. Le DGX Spark est la machine idéale pour ça — 128 Go de mémoire unifiée, le modèle tient entièrement en GPU, les performances sont au rendez-vous.

Mais on ne peut pas encore lui faire confiance aveuglément. Les vulnérabilités de conception (policies qui ne se propagent pas, skills tiers sans audit, pas de contrôle granulaire par action) sont trop critiques pour un usage en production ou avec des données sensibles. Brancher votre gestionnaire de mots de passe et vos emails sur un agent autonome dont les barrières de sécurité ne fonctionnent pas encore correctement serait imprudent.

Et si on fait tout soi-même ?

On pourrait se dire : si je crée mes propres skills (accès email, stockage de credentials), que le modèle tourne en local, et que je n'installe aucun skill tiers — le risque disparait, non ?

C'est nettement mieux, effectivement. Modèle local + skills maison + pas de tunnel public = les failles #272 et #481 deviennent sans objet. Mais il reste un problème fondamental que même une version parfaite de NemoClaw ne pourrait pas résoudre :

Alors, on fait quoi ?