Comment entraîner GR00T N1.7 sur votre propre jeu de données SO-100

NVIDIA fournit un exemple de réglage fin pour exactement le bras que vous possédez probablement. Dans le dépôt Isaac-GR00T, il y a un dossier appelé demo_data/cube_to_bowl_5 : cinq épisodes, 4 148 images à 30 ips, déjà écrits au format LeRobot v2.1, avec une configuration de modalité correspondante sous examples/SO100/. Son meta/info.json rapporte robot_type: so101_follower, qui dans LeRobot est la même classe de configuration que so100_follower. C'est vraiment utile, car cela signifie que le chemin de référence pour GR00T N1.7 sur un bras de loisir à six degrés de liberté est maintenu par les personnes qui ont écrit le modèle. Ce n'est pas une démo humanoïde réduite, c'est le même bras.

La mauvaise nouvelle est la distance entre I recorded 60 episodes et the arm does the task. Il y a environ six endroits où ce pipeline échoue silencieusement plutôt que bruyamment, et quatre d'entre eux se trouvent dans des fichiers que la plupart des gens n'ouvrent jamais : meta/modality.json, la configuration des données Python, meta/relative_stats.json, et la chaîne de version propre au jeu de données. Ce guide parcourt la voie manuelle de bout en bout avec les commandes réelles, puis montre le même travail sous forme de formulaire sur AY-Robots. Tout ce qui suit a été vérifié par rapport à la branche principale d'Isaac-GR00T au 20 août 2026 (la ligne de version n1.7-release) et à lerobot 0.6.1, publié sur PyPI le 3 août 2026. L'amont évolue rapidement, et si un drapeau a été renommé, cet article le mentionne.

Ce qu'est réellement GR00T N1.7

GR00T N1.7 est un modèle vision-langage-action avec l'architecture à double système décrite dans le document original GR00T N1 : un module vision-langage qui lit les caméras et l'instruction, et un transformeur de diffusion qui transforme cela en un bloc de commandes motrices continues. N1.7 a remplacé la première moitié. Le backbone Eagle de N1.6 a disparu, remplacé par nvidia/Cosmos-Reason2-2B sur une architecture Qwen3-VL, et le modèle a été pré-entraîné sur environ 20 000 heures de vidéo humaine égocentrique en plus des données du robot. Le propre rapport de NVIDIA indique le chiffre de 20 854 heures et rapporte que passer de 1k à 20k heures fait plus que doubler le taux moyen d'achèvement des tâches.

La seconde moitié a également changé, d'une manière qui compte pour votre exécution. La tête d'action est passée de 32 couches de diffusion à 16, le bloc d'action est passé de 16 à 40 étapes, et la largeur maximale d'état et d'action est passée de 29 à 132. Ces trois chiffres proviennent du journal des modifications dans le README du dépôt ; le propre article de lancement de NVIDIA décrit toujours le Système 1 comme un DiT à 32 couches, donc là où les deux sont en désaccord, faites confiance au dépôt que vous êtes sur le point de cloner. Les actions sont exprimées par défaut dans un espace effecteur final relatif, des deltas par rapport à la pose actuelle plutôt que des cibles absolues, ce qui permet aux priors de manipulation appris à partir de vidéos humaines de se transférer dans le contrôle du robot. La tête elle-même est un transformeur de diffusion flow-matching, de la même famille que Pi0.5 mais avec un backbone différent devant. Si vous êtes toujours sur la génération précédente, N1.7 comparé à N1.5 explique si la mise à niveau justifie de refaire votre pipeline.

Ces trois dernières lignes expliquent la majeure partie de la déception rapportée par les utilisateurs. Le chiffre principal de 27.9 ms correspond à un moteur TensorRT sur un H100 avec une caméra et quatre étapes de débruitage. PyTorch pur sur la même carte est de 85.8 ms, et la fiche modèle indique un écart de 3.08x. Aucun de ces chiffres n'inclut une couche de service, une deuxième caméra ou un saut de réseau. Les 152 ms par étape d'action citées par AY-Robots pour son GR00T N1.7 servi sont le chiffre avec le service en boucle, et un aller-retour sur internet public s'ajoute à cela. Plus de détails à ce sujet à la fin. Pour les chiffres comparés à d'autres modèles, GR00T N1.7 comparé à Pi0.5 et GR00T N1.7 comparé à SmolVLA les présentent côte à côte.

Ce dont l'exécution a besoin avant de taper quoi que ce soit

Étape 0 : les épisodes eux-mêmes

Tout ce qui suit suppose que vous avez déjà enregistré des épisodes. Si ce n'est pas le cas, c'est la véritable première étape et c'est celle qui détermine la qualité du résultat, car l'apprentissage par imitation ne peut pas récupérer les informations qui ne sont pas dans les données. Calibrez d'abord les deux bras, puis pilotez le bras suiveur avec un bras leader pendant que lerobot-record écrit les fichiers parquet et les flux de caméra. Si le calibrage est incorrect, les valeurs articulaires de votre ensemble de données décrivent un robot légèrement différent de celui qui exécutera la politique plus tard, et aucune quantité d'entraînement ne peut corriger cela.

lerobot-record \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --robot.id=my_follower_arm \
    --robot.cameras="{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30}}" \
    --teleop.type=so100_leader \
    --teleop.port=/dev/ttyACM1 \
    --teleop.id=my_leader_arm \
    --dataset.repo_id=${HF_USER}/cube-into-bowl \
    --dataset.num_episodes=60 \
    --dataset.single_task="put the cube in the yellow bowl" \
    --display_data=true

Le conseil de LeRobot est d'enregistrer au moins 50 épisodes avec environ 10 par emplacement d'objet, de garder les caméras fixes et de maintenir un comportement de préhension cohérent. Ajoutez de la variation plus tard, pas au début. La règle d'or à retenir : si vous ne pouviez pas accomplir la tâche vous-même à partir des seules images de la caméra, la politique ne le pourra pas non plus. Pour la configuration spécifique au bras, le guide de démarrage du SO-100 et la page LeRobot du SO-100 couvrent les ports, le calibrage et les indices de caméra. Sur AY-Robots, vous pouvez également le faire via Internet depuis le navigateur en utilisant la téléopération et enregistrer directement depuis la session.

Étape 1 : le jeu de données doit être LeRobot v2.1

C'est l'obstacle le plus courant. La CODEBASE_VERSION actuelle de LeRobot sur main est la v3.0, donc tout ce que vous enregistrez aujourd'hui avec une chaîne d'outils actuelle sort en v3.0. Le chargeur de GR00T s'attend à la v2. Le dépôt est explicite sur la raison : de nombreux jeux de données en amont tels que DROID, LIBERO et Bridge sont publiés en v2, et le support natif pour les deux est prévu mais pas encore livré. La conversion vous incombe donc, et elle s'exécute dans son propre virtualenv pour une raison concrète : scripts/lerobot_conversion contient son propre pyproject qui demande Python 3.10 ou 3.11 et épingle lerobot à un commit git, tandis qu'Isaac-GR00T lui-même nécessite Python 3.12. Installez le convertisseur depuis la racine du dépôt et vous obtiendrez le package gr00t à la place, ce qui est l'erreur contre laquelle son README met en garde. Si vous débutez avec le format, l'entrée de glossaire Jeu de données LeRobot explique ce qu'il contient réellement.

# from the Isaac-GR00T repo root
cd scripts/lerobot_conversion
uv venv
source .venv/bin/activate
uv pip install -e . --verbose

# pulls the dataset from the Hub and writes a v2.1 copy into the default cache
python convert_v3_to_v2.py --repo-id <your-hf-user>/<your-dataset>

# or, back in the repo root, keep it next to the SO-100 example
uv run --project scripts/lerobot_conversion \
  python scripts/lerobot_conversion/convert_v3_to_v2.py \
  --repo-id <your-hf-user>/<your-dataset> \
  --root examples/SO100/my_dataset_lerobot

La structure que GR00T attend après conversion est la disposition classique v2 : meta/info.json, meta/episodes.jsonl, meta/tasks.jsonl, des fichiers parquet sous data/chunk-000/, des fichiers MP4 sous videos/chunk-000/observation.images./, et un fichier supplémentaire que LeRobot standard n'a pas. C'est dans ce fichier supplémentaire que se trouvent la plupart des échecs restants.

Étape 2 : modality.json, les six nombres qui décident de tout

Dans un jeu de données LeRobot, l'état du robot et l'action sont stockés sous forme de tableaux float32 plats. Pour un SO-100, les deux ont la forme [6] : cinq articulations de bras et un préhenseur. Le jeu de données de démonstration les nomme shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos, gripper.pos, mais ces noms se trouvent dans info.json et rien dans le fichier parquet n'indique quel index correspond à quoi. meta/modality.json fournit ce mappage, et GR00T ne s'entraînera pas sans lui. Voici celui que le dépôt fournit pour le SO-100, tel quel.

{
  "state": {
    "single_arm": {
      "start": 0,
      "end": 5
    },
    "gripper": {
      "start": 5,
      "end": 6
    }
  },
  "action": {
    "single_arm": {
      "start": 0,
      "end": 5
    },
    "gripper": {
      "start": 5,
      "end": 6
    }
  },
  "video": {
    "front": {
      "original_key": "observation.images.front"
    },
    "wrist": {
      "original_key": "observation.images.wrist"
    }
  },
  "annotation": {
    "human.task_description": {
      "original_key": "task_index"
    }
  }
}

Copiez-le dans votre jeu de données converti à l'emplacement meta/modality.json et renommez les clés vidéo pour qu'elles correspondent aux noms réels de vos caméras. Si vous avez enregistré avec une seule caméra zénithale nommée top, alors original_key est observation.images.top et le nom convivial est celui que votre configuration de données référencera. Les deux doivent concorder, et aucun d'eux ne vérifie l'autre pour vous. L'annotation linguistique est pire, car la même clé doit apparaître à trois endroits.

Étape 3 : la configuration des données, le bras relatif et le préhenseur absolu

La configuration de modalité est un fichier Python plutôt que JSON, car elle décide également de la manière dont chaque groupe d'actions est représenté. C'est la partie du flux de travail N1.7 qui n'existait pas sous la même forme dans N1.5, et la partie qui mérite d'être lue deux fois. La configuration SO-100 fournie prédit les cinq articulations du bras comme des RELATIFS deltas par rapport à l'état actuel et la pince comme une position cible ABSOLUE, car un signal binaire ouvert-ou-fermé se comporte mieux comme une cible que comme un delta.

from gr00t.configs.data.embodiment_configs import register_modality_config
from gr00t.data.embodiment_tags import EmbodimentTag
from gr00t.data.types import (
    ActionConfig, ActionFormat, ActionRepresentation, ActionType, ModalityConfig,
)

so100_config = {
    "video": ModalityConfig(
        delta_indices=[0],                       # current frame only
        modality_keys=["front", "wrist"],        # must match modality.json
    ),
    "state": ModalityConfig(
        delta_indices=[0],
        modality_keys=["single_arm", "gripper"],
    ),
    "action": ModalityConfig(
        delta_indices=list(range(0, 16)),        # predict 16 future steps
        modality_keys=["single_arm", "gripper"],
        action_configs=[
            ActionConfig(rep=ActionRepresentation.RELATIVE,   # arm joints
                         type=ActionType.NON_EEF,
                         format=ActionFormat.DEFAULT),
            ActionConfig(rep=ActionRepresentation.ABSOLUTE,   # gripper
                         type=ActionType.NON_EEF,
                         format=ActionFormat.DEFAULT),
        ],
    ),
    "language": ModalityConfig(
        delta_indices=[0],
        modality_keys=["annotation.human.task_description"],
    ),
}

register_modality_config(so100_config, embodiment_tag=EmbodimentTag.NEW_EMBODIMENT)

Deux détails ici vous coûteront une journée si vous ne les connaissez pas. Premièrement, action_configs est positionnel : la documentation exige la même longueur et le même ordre que modality_keys, et elle est très claire sur la conséquence d'une erreur, à savoir que la mauvaise représentation est appliquée silencieusement. Votre pince est entraînée comme un delta et votre bras comme une cible absolue, et il n'y a pas de message d'erreur. Deuxièmement, register_modality_config affirme que le tag n'est pas déjà enregistré, donc une deuxième configuration NEW_EMBODIMENT dans le même processus Python échoue avec Embodiment tag ... already registered. Vous ne pouvez pas en importer deux dans un même script. Une troisième règle est appliquée plus tard, lors du déploiement : les delta_indices de l'action doivent être une plage contiguë commençant à zéro. Une fenêtre éparse telle que [0, 4, 8] est rejetée, car tout ce qui est en aval indexe le bloc prédit linéairement et exécuterait autrement les mauvaises lignes.

Étape 4 : l'environnement

N1.7 a déplacé le dépôt vers et Python 3.12. L'ancien chemin conda plus pip install -e . existe toujours dans une section repliée du README, mais il avertit que les dépendances GPU, y compris flash-attn et TensorRT, peuvent nécessiter une installation manuelle. Utilisez uv à moins d'avoir une raison spécifique de ne pas le faire. Concernant flash-attn, un détail évite la confusion : vous verrez Installing flash-attn affiché à chaque uv run. Il ne s'agit pas d'une reconstruction. uv revalide une roue épinglée par URL qui est déjà mise en cache, et cela prend deux ou trois secondes.

1. 1
   Installer git-lfs, puis cloner avec les sous-modules

   git-lfs est requis, non optionnel. Sans lui, les fichiers parquet dans demo_data/ sont téléchargés comme des stubs de pointeur, et l'exécution de la démo échoue sur un jeu de données qui semble présent dans la liste des fichiers.

   bash

   sudo apt install git-lfs && git lfs install
   git clone --recurse-submodules https://github.com/NVIDIA/Isaac-GR00T
   cd Isaac-GR00T

2. 2
   Installer uv et synchroniser l'environnement

   L'installation par défaut télécharge les dépendances GPU, y compris flash-attn et TensorRT. Sur une image A100 ou H100 fraîche, c'est l'étape la plus longue, alors faites-le avant de vous concentrer sur autre chose.

   bash

   curl -LsSf https://astral.sh/uv/install.sh | sh
   sudo apt-get update && sudo apt-get install -y ffmpeg
   uv sync --python 3.12
   uv run python -c "import gr00t; print('GR00T installed successfully')"

3. 3
   S'authentifier auprès de Hugging Face

   Faites cela avant le premier lancement de l'entraînement, pas après qu'il ait échoué après huit minutes.

   bash

   uv run huggingface-cli login   # or: export HF_TOKEN=<your_token>

4. 4
   Vérification de bon fonctionnement sur les données de démonstration SO-100 fournies

   Avant de toucher à votre propre enregistrement, exécutez 2000 étapes sur demo_data/cube_to_bowl_5. Il s'agit de cinq épisodes, cela se termine rapidement et cela prouve l'environnement plutôt que vos données. Si cette exécution échoue, rien de ce que vous ferez à votre jeu de données n'aidera.

   bash

   CUDA_VISIBLE_DEVICES=0 uv run python \
       gr00t/experiment/launch_finetune.py \
       --base-model-path nvidia/GR00T-N1.7-3B \
       --dataset-path demo_data/cube_to_bowl_5 \
       --embodiment-tag NEW_EMBODIMENT \
       --modality-config-path examples/SO100/so100_config.py \
       --num-gpus 1 \
       --output-dir /tmp/test_finetune \
       --max-steps 2000 \
       --global-batch-size 32 \
       --dataloader-num-workers 4

Étape 5 : la commande de fine-tuning et les valeurs par défaut de ses options

Remplacez le jeu de données de démonstration par le vôtre et ajoutez les paramètres que vous souhaitez réellement. Vous trouverez ci-dessous la forme complète que le dépôt utilise dans son propre tutoriel de nouvelle incarnation, y compris les options d'augmentation et de checkpointing que le court exemple du README omet. Il s'agit de au sens strict : le backbone linguistique et l'encodeur visuel restent figés, et ce qui est entraîné est le projecteur et la tête d'action de diffusion.

export NUM_GPUS=1
CUDA_VISIBLE_DEVICES=0 uv run python \
    gr00t/experiment/launch_finetune.py \
    --base-model-path nvidia/GR00T-N1.7-3B \
    --dataset-path ./my_dataset_lerobot \
    --embodiment-tag NEW_EMBODIMENT \
    --modality-config-path examples/SO100/so100_config.py \
    --num-gpus $NUM_GPUS \
    --output-dir /tmp/so100 \
    --save-total-limit 5 \
    --save-steps 2000 \
    --max-steps 20000 \
    --use-wandb \
    --global-batch-size 32 \
    --color-jitter-params brightness 0.3 contrast 0.4 saturation 0.5 hue 0.08 \
    --dataloader-num-workers 4

Cette dernière ligne n'est pas une faute de frappe. launch_finetune.py est une interface CLI tyro générée à partir d'une dataclass, et cette dataclass n'a pas de champ de graine (seed). Le README mentionne séparément une variance de 5 à 6 pour cent entre les exécutions, causée par une augmentation d'image non déterministe. Deux exécutions avec des drapeaux identiques ne produiront pas de checkpoints identiques, ce qui est très important lorsque vous essayez de décider si un changement d'hyperparamètre a été utile ou si vous avez eu de la chance. À titre de comparaison, l'entraîneur de lerobot utilise par défaut la graine 1000, et la recette LeRobot GR00T passe --seed=42 explicitement.

Ce que coûte une exécution de 20000 étapes

GR00T N1.7 nécessite une carte de 80 Go, la question du coût a donc une réponse limitée. Sur AY-Robots, l'entraîneur groot1.7 s'exécute sur le niveau A100 80 Go ou H100 80 Go, où une exécution prend 3 à 6 heures à 1.20 à 2.00 USD par heure sur le marché spot. Cela représente environ 4 à 12 USD pour la tâche par défaut de 20000 étapes. La même tâche sur SmolVLA ou ACT s'exécute sur une carte de 24 Go à 0.30 à 0.60 USD par heure et 1 à 3 USD par exécution. C'est le véritable compromis : GR00T coûte environ quatre fois plus cher par tentative, et vous ne pouvez pas l'exécuter sur la 4090 sous votre bureau.

Le minimum de 50 épisodes est un plancher, pas un objectif. La FAQ de NVIDIA est plus exigeante : environ 100 trajectoires pour un simple ramassage et placement à emplacement fixe, 500 ou plus pour des scènes complexes ou multi-étapes, et 100 à 500 pour une manipulation fine. Si vous êtes à 20 épisodes, passez l'après-midi à enregistrer plutôt que la soirée à ajuster. Le guide de collecte de données couvre ce qui sépare un épisode utile d'un épisode gaspillé, enregistrez votre premier jeu de données est la version courte, et collecte de données SO-100 est celle spécifique au bras.

Étape 6 : évaluation en boucle ouverte avant de toucher le bras

Ne mettez pas un nouveau point de contrôle sur un bras physique pour savoir si l'entraînement a fonctionné. Exécutez d'abord l'évaluation en boucle ouverte. Elle rejoue un épisode enregistré, demande au modèle des actions à chaque étape, et trace la prédiction par rapport à la vérité terrain avec le MSE et le MAE. Elle ne coûte rien et elle détecte les erreurs de mappage des étapes 2 et 3.

uv run python gr00t/eval/open_loop_eval.py \
    --dataset-path ./my_dataset_lerobot \
    --embodiment-tag NEW_EMBODIMENT \
    --model-path /tmp/so100/checkpoint-20000 \
    --traj-ids 0 \
    --execution-horizon 16 \
    --steps 400 \
    --modality-keys single_arm gripper

Le dépôt refuse délibérément de publier un MSE cible pour les données personnalisées, et c'est la bonne approche : le nombre dépend de vos unités d'action, de votre tâche et de la taille de votre jeu de données, donc un seuil copié du bras de quelqu'un d'autre ne signifie rien. Ce qui est significatif, c'est la tendance. Voici l'exécution de référence documentée par le dépôt sur un seul H100 avec le jeu de données de démonstration de cinq épisodes et 2000 étapes.

La forme est le signal, pas les valeurs absolues. L'erreur devrait diminuer régulièrement à mesure que les s'accumulent. En moyenne sur les cinq épisodes d'entraînement plutôt que sur la seule trajectoire 0, le point de contrôle final du dépôt a obtenu environ 7.5 MSE et 1.5 MAE, de sorte que même l'exécution de référence se lit différemment selon les épisodes que vous moyennez. Enregistrez votre propre ligne de base sur la commande de démonstration non modifiée avant de modifier quoi que ce soit concernant vos propres données : si vous ne pouvez pas reproduire une exécution connue comme bonne, vous ne pouvez pas distinguer une erreur de configuration d'un problème de données. Le dépôt associe également les symptômes courants aux causes, et chacun d'eux est opérationnel plutôt qu'un bug du modèle.

L'autre voie : lerobot-train au lieu d'Isaac-GR00T

La version actuelle de LeRobot, 0.6.1 sur PyPI depuis le 3 août 2026, offre une deuxième manière, très différente, d'affiner les mêmes poids de base. LeRobot expose GR00T N1.7 comme type de politique et l'entraîne via son propre point d'entrée lerobot-train. Deux choses sont importantes ici. L'interface de ligne de commande de LeRobot est un ensemble de scripts console, donc tout ce que vous lisez qui dit python lerobot/scripts/train.py est obsolète et ne fonctionnera pas. Et LeRobot a entièrement supprimé le support de GR00T N1.5, rejetant les points de contrôle et les configurations N1.5 avec une note de migration, donc si vous avez besoin de N1.5 via LeRobot, vous devez épingler lerobot==0.5.1, la dernière version qui le prend en charge, publiée le 7 avril 2026.

pip install "lerobot[groot]" "lerobot[training]"
hf auth login

lerobot-train \
  --dataset.repo_id=$HF_USER/$DATASET_NAME \
  --dataset.image_transforms.enable=true \
  --policy.type=groot \
  --policy.device=cuda \
  --policy.base_model_path=nvidia/GR00T-N1.7-3B \
  --policy.embodiment_tag=new_embodiment \
  --policy.chunk_size=16 \
  --policy.n_action_steps=16 \
  --policy.use_relative_actions=true \
  --policy.relative_exclude_joints='["gripper"]' \
  --policy.use_bf16=true \
  --seed=42 \
  --batch_size=64 \
  --steps=20000 \
  --save_freq=5000 \
  --output_dir=$OUTPUT_DIR

Deux façons d'obtenir le même point de contrôle

Remettre le checkpoint sur le bras

Isaac-GR00T utilise une architecture client-serveur via ZMQ. La politique s'exécute sur le GPU, et un client léger sur la machine robot envoie les observations et reçoit les morceaux d'action. L'exemple SO-100 est suffisamment complet pour être copié : démarrez run_gr00t_server.py avec votre checkpoint et --embodiment-tag NEW_EMBODIMENT, puis exécutez eval_so100.py côté robot avec le port série, l'ID du robot, les indices de caméra et l'instruction linguistique. Les noms de caméra dans cette commande doivent correspondre aux noms conviviaux de votre modality.json, et non aux numéros de périphérique du système d'exploitation.

# GPU side
uv run python gr00t/eval/run_gr00t_server.py \
  --model-path /tmp/so100/checkpoint-20000 \
  --embodiment-tag NEW_EMBODIMENT \
  --device cuda:0 \
  --host 0.0.0.0 --port 5555

# robot side, from gr00t/eval/real_robot/SO100
uv run --no-sync python eval_so100.py \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM2 \
  --robot.id=orange_follower \
  --robot.cameras="{ front: {type: opencv, index_or_path: 6, width: 640, height: 480, fps: 30}, wrist: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30}}" \
  --policy_host=localhost --policy_port=5555 \
  --lang_instruction="put the cube in the yellow bowl"

Maintenant, la partie honnête sur l'endroit où la politique s'exécute, car l'entraînement et le service ont des histoires matérielles différentes. Le réglage fin nécessite 40 Go ou plus. L'inférence non : le README l'estime à 16 Go ou plus et nomme explicitement la RTX 4090, donc une carte que vous possédez déjà peut servir un checkpoint qu'elle n'aurait jamais pu produire. Ce qui décide si la politique semble réactive n'est pas la VRAM, c'est l'emplacement du serveur. Sur AY-Robots, GR00T N1.7 est uniquement dans le cloud, donc la boucle de contrôle paie un aller-retour sur Internet public en plus des 152 ms par étape d'action, et seulement SmolVLA et ACT s'exécutent également localement. Pour un ramassage et placement lent, un pod distant est supportable. Pour tout ce qui est réactif, ce n'est pas le cas : la politique devient hésitante d'une manière qui ressemble exactement à un échec d'entraînement et n'en est pas un. ACT à 20 ms par étape d'action est le modèle qui tolère la boucle la plus serrée, SmolVLA est à 245 ms, et aucune quantité de réglage de la latence ne rachète un aller-retour déjà effectué. Exécuter votre première politique explique le côté service de bout en bout.

Ce qui ne va pas réellement

• GatedRepoError lors de la première exécution. L'accès à nvidia/Cosmos-Reason2-2B ne vous a pas été accordé, ou vous ne vous êtes pas authentifié. Cela se produit après que l'horloge du GPU a déjà démarré.
• Jeu de données rejeté au chargement. Presque toujours un jeu de données v3.0. Convertissez-le vers une version antérieure. Voir jeu de données rejeté en tant que v3.
• IndexError concernant des dimensions booléennes incompatibles. Vous avez modifié delta_indices et n'avez pas régénéré les statistiques.
• Manque de mémoire au lot 32. Réduisez --global-batch-size et augmentez --gradient-accumulation-steps, ou réduisez --num-shards-per-epoch, ce que la configuration suggère explicitement lorsque la VRAM est limitée. Voir manque de mémoire pendant l'entraînement.
• La perte diminue, la politique ne fait rien. Il n'y a pas de division de validation par défaut, donc une courbe d'entraînement propre prouve très peu de choses. Cette page couvre le diagnostic.
• Fonctionne dans votre configuration et nulle part ailleurs. Attendu avec un petit jeu de données filmé sous une seule condition d'éclairage. NVIDIA recommande une augmentation de la gigue de couleur (colour jitter augmentation) plus 20 à 50 épisodes sous différents éclairages. Plus d'informations ici.
• La pince ne se ferme jamais correctement. Vérifiez que l'action de la pince est ABSOLUE et les articulations du bras RELATIVES, dans cet ordre dans action_configs. La pince ne se ferme pas liste les autres causes.
• Une caméra se déconnecte silencieusement en cours d'enregistrement. L'épisode est toujours sauvegardé et la clé vidéo existe toujours, c'est pourquoi c'est un problème délicat. Caméra non détectée couvre ce cas.

L'index complet des modes de défaillance se trouve à . Si vous choisissez entre des modèles plutôt que d'en déboguer un, et ont des chiffres de référence avec des sources jointes, et est la comparaison dont la plupart des gens ont réellement besoin, car c'est le choix entre un modèle que vous pouvez entraîner sur la carte sous votre bureau et un autre pour lequel vous devez louer un nœud de 80 Go pour le fine-tuning. Pour comprendre pourquoi ces modèles se comportent de cette manière, la et le méritent d'être lus en premier. Et si vous ne possédez pas encore de bras, diffuse un SO-100 physique sans inscription.