Hoe GR00T N1.7 te trainen op uw eigen SO-100 Dataset

NVIDIA levert een fine-tuning voorbeeld voor precies de arm die u waarschijnlijk bezit. Binnen de Isaac-GR00T repository bevindt zich een map genaamd demo_data/cube_to_bowl_5: vijf afleveringen, 4.148 frames met 30 fps, reeds geschreven als LeRobot v2.1, met een overeenkomstige modaliteitsconfiguratie onder examples/SO100/. Het meta/info.json rapporteert robot_type: so101_follower, wat in LeRobot dezelfde configuratieklasse is als so100_follower. Dat is oprecht nuttig, omdat het betekent dat het referentiepad voor GR00T N1.7 op een zes-vrijheidsgraden hobbyarm wordt onderhouden door de mensen die het model hebben geschreven. Het is geen verkleinde humanoïde demo, het is dezelfde arm.

Het slechte nieuws is de afstand tussen I recorded 60 episodes en the arm does the task. Er zijn ongeveer zes plaatsen waar deze pijplijn stilzwijgend faalt in plaats van luidruchtig, en vier daarvan bevinden zich in bestanden die de meeste mensen nooit openen: meta/modality.json, de Python-dataconfiguratie, meta/relative_stats.json, en de eigen versie string van de dataset. Deze gids doorloopt de handmatige route van begin tot eind met de echte commando's, en toont vervolgens dezelfde taak als een formulier op AY-Robots. Alles hieronder is gecontroleerd tegen de Isaac-GR00T main branch per 20 augustus 2026 (de n1.7-release lijn) en lerobot 0.6.1, gepubliceerd op PyPI op 3 augustus 2026. Upstream beweegt snel, en waar een flag is hernoemd, vermeldt dit artikel dat.

Wat GR00T N1.7 werkelijk is

GR00T N1.7 is een visie-taal-actiemodel met de duale-systeemindeling zoals beschreven in het originele GR00T N1-artikel: een visie-taalmodule die de camera's en de instructie leest, en een diffusietransformator die dat omzet in een reeks continue motorcommando's. N1.7 verving de eerste helft. De Eagle-backbone van N1.6 is verdwenen, ingeruild voor nvidia/Cosmos-Reason2-2B op een Qwen3-VL-architectuur, en het model werd voorgetraind op ongeveer 20.000 uur egocentrische menselijke video bovenop de robotdata. NVIDIA's eigen verslag vermeldt het cijfer op 20.854 uur en rapporteert dat het verhogen van 1k naar 20k uur de gemiddelde taakvoltooiing meer dan verdubbelt.

De tweede helft veranderde ook, op manieren die van belang zijn voor jouw uitvoering. De actie-head daalde van 32 diffusielagen naar 16, de voorspelde actiechunk groeide van 16 stappen naar 40, en de maximale toestand- en actiebreedte ging van 29 naar 132. Die drie getallen komen uit de changelog in de README van de repository; NVIDIA's eigen lanceringsbericht beschrijft Systeem 1 nog steeds als een 32-laags DiT, dus waar de twee verschillen, vertrouw dan op de repo die je gaat klonen. Acties worden standaard uitgedrukt in een relatieve eindeffector ruimte, delta's van de huidige pose in plaats van absolute doelen, wat het mogelijk maakt dat manipulatie-prioriteiten geleerd uit menselijke video überhaupt overgaan in robotbesturing. De head zelf is een flow-matching diffusietransformator, dezelfde familie als Pi0.5 maar met een andere backbone ervoor. Als je nog op de vorige generatie zit, N1.7 versus N1.5 behandelt of de upgrade het opnieuw doen van je pijplijn rechtvaardigt.

Die laatste drie rijen verklaren het grootste deel van de teleurstelling die mensen melden. De headline van 27.9 ms is een TensorRT-engine op een H100 met één camera en vier denoising-stappen. Puur PyTorch op dezelfde kaart is 85.8 ms, en de modelkaart geeft het verschil aan als 3.08x. Geen van beide cijfers omvat een serving-laag, een tweede camera of een netwerkhop. De 152 ms per actiestap die AY-Robots opgeeft voor zijn geserveerde GR00T N1.7 is het cijfer met serving in de loop, en een roundtrip via het openbare internet komt daar nog bovenop. Meer hierover aan het einde. Voor de cijfers naast andere modellen, GR00T N1.7 versus Pi0.5 en GR00T N1.7 versus SmolVLA zetten ze naast elkaar.

Wat de run nodig heeft voordat je iets typt

Stap 0: de afleveringen zelf

Alles hieronder gaat ervan uit dat je al opgenomen afleveringen hebt. Als je dat niet hebt, is dat de echte eerste stap en het is degene die bepaalt hoe goed het resultaat kan zijn, want imitatieleer kan geen informatie herstellen die niet in de gegevens zit. Kalibreer eerst beide armen, rijd dan met de volger met een leiderarm terwijl lerobot-record de parquet-bestanden en de camerastreams schrijft. Als kalibratie niet klopt, beschrijven de gewrichtswaarden in je dataset een iets andere robot dan degene die later het beleid zal uitvoeren, en geen enkele hoeveelheid training lost dat op.

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

Het advies van LeRobot zelf is om minstens 50 afleveringen op te nemen, ongeveer 10 per objectlocatie, de camera's vast te houden en het grijpgedrag consistent te houden. Voeg variatie later toe, niet aan het begin. De vuistregel om te onthouden: als je de taak zelf niet kon uitvoeren met alleen de camerabeelden, kan het beleid ook niet. Voor de arms-specifieke setup, SO-100 aan de slag en de SO-100 LeRobot pagina behandelen poorten, kalibratie en camera-indices. Op AY-Robots kun je dit ook via internet vanuit de browser doen met behulp van teleoperatie en direct vanuit de sessie opnemen.

Stap 1: de dataset moet LeRobot v2.1 zijn

Dit is het meest voorkomende struikelblok. De huidige CODEBASE_VERSION van LeRobot op main is v3.0, dus alles wat je vandaag opneemt met een huidige toolchain komt uit als v3.0. De loader van GR00T verwacht v2. De repository is expliciet over de reden: veel upstream datasets zoals DROID, LIBERO en Bridge zijn gepubliceerd in v2, en native ondersteuning voor beide is gepland maar nog niet geleverd. De conversie is dus aan jou, en deze draait in zijn eigen virtualenv om een concrete reden: scripts/lerobot_conversion heeft zijn eigen pyproject dat vraagt om Python 3.10 of 3.11 en lerobot vastpint op één git commit, terwijl Isaac-GR00T zelf Python 3.12 vereist. Installeer de converter vanuit de root van de repository en je krijgt het gr00t pakket in plaats daarvan, wat de fout is waar de README voor waarschuwt. Als je nieuw bent met het formaat, legt de LeRobot dataset woordenlijstvermelding uit wat er precies in zit.

# 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

De structuur die GR00T wil na conversie is de klassieke v2-indeling: meta/info.json, meta/episodes.jsonl, meta/tasks.jsonl, parquet-bestanden onder data/chunk-000/, MP4-bestanden onder videos/chunk-000/observation.images./, en één extra bestand dat standaard LeRobot niet heeft. Dat extra bestand is waar de meeste resterende fouten zich bevinden.

Stap 2: modality.json, de zes getallen die alles bepalen

In een LeRobot dataset worden de robotstatus en de actie opgeslagen als platte float32-arrays. Voor een SO-100 hebben beide de vorm [6]: vijf armgewrichten en een grijper. De demodataset noemt ze shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos, wrist_flex.pos, wrist_roll.pos, gripper.pos, maar die namen staan in info.json en niets in het parquet-bestand zegt welke index welke is. meta/modality.json levert die mapping, en GR00T zal er niet zonder trainen. Hier is degene die de repository levert voor de SO-100, woordelijk.

{
  "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"
    }
  }
}

Kopieer het naar uw geconverteerde dataset op meta/modality.json en hernoem de videotoetsen naar hoe uw camera's daadwerkelijk heten. Als u heeft opgenomen met één overheadcamera genaamd top, dan is original_key observation.images.top en de 'friendly name' is waarnaar uw dataconfiguratie zal verwijzen. De twee moeten overeenkomen, en geen van beide controleert de ander voor u. De taalannotatie is erger, omdat dezelfde sleutel op drie plaatsen moet verschijnen.

Stap 3: de dataconfiguratie, relatieve arm en absolute grijper

De modaliteitsconfiguratie is een Python-bestand in plaats van JSON, omdat het ook bepaalt hoe elke actiegroep wordt weergegeven. Dit is het deel van de N1.7-workflow dat niet in dezelfde vorm bestond in N1.5, en het deel dat de moeite waard is om twee keer te lezen. De meegeleverde SO-100-configuratie voorspelt de vijf armgewrichten als RELATIEVE delta's vanuit de huidige toestand en de grijper als een ABSOLUTE doelpositie, omdat een binair open-of-gesloten signaal zich beter gedraagt als een doel dan als een 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)

Twee details hier zullen je een dag kosten als je ze niet kent. Ten eerste, action_configs is positioneel: de documentatie vereist dezelfde lengte en dezelfde volgorde als modality_keys, en ze zijn duidelijk over de consequentie van een fout, namelijk dat de verkeerde representatie stilzwijgend wordt toegepast. Je grijper wordt getraind als een delta en je arm als een absolute doelpositie, en er is geen foutmelding. Ten tweede, register_modality_config beweert dat de tag nog niet is geregistreerd, dus een tweede NEW_EMBODIMENT-configuratie in hetzelfde Python-proces sterft met Embodiment tag ... already registered. Je kunt niet twee hiervan in één script importeren. Een derde regel wordt later afgedwongen, bij de implementatie: de actie delta_indices moet het aaneengesloten bereik zijn dat begint bij nul. Een dun venster zoals [0, 4, 8] wordt afgewezen, omdat alles stroomafwaarts de voorspelde chunk lineair indexeert en anders de verkeerde rijen zou uitvoeren.

Stap 4: de omgeving

N1.7 heeft de repository verplaatst naar en Python 3.12. Het oude conda plus pip install -e . pad bestaat nog steeds in een ingeklapte sectie van de README, maar het waarschuwt dat GPU-afhankelijkheden, waaronder flash-attn en TensorRT, mogelijk handmatige installatie vereisen. Gebruik uv tenzij u een specifieke reden heeft om dit niet te doen. Wat flash-attn betreft, één detail voorkomt verwarring: u zult Installing flash-attn zien verschijnen bij elke uv run. Het wordt niet opnieuw opgebouwd. uv valideert opnieuw een URL-gepinde wheel die al in de cache staat, en dit duurt twee of drie seconden.

1. 1
   Installeer git-lfs en kloon vervolgens met submodules

   git-lfs is vereist, niet optioneel. Zonder dit komen de parquet-bestanden in demo_data/ binnen als pointer-stubs, en de demo-uitvoering mislukt op een dataset die wel aanwezig lijkt in de bestandslijst.

   bash

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

2. 2
   Installeer uv en synchroniseer de omgeving

   De standaardinstallatie haalt de GPU-afhankelijkheden op, waaronder flash-attn en TensorRT. Op een nieuwe A100- of H100-image is dit de langste afzonderlijke stap, dus doe dit voordat u aandacht besteedt aan iets anders.

   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
   Authenticeer tegen Hugging Face

   Doe dit vóór de eerste trainingslancering, niet nadat deze na acht minuten mislukt.

   bash

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

4. 4
   Sanity-check op de meegeleverde SO-100 demogegevens

   Voordat u uw eigen opname aanraakt, voert u 2000 stappen uit op demo_data/cube_to_bowl_5. Het zijn vijf afleveringen, het is snel klaar en het bewijst de omgeving in plaats van uw gegevens. Als deze uitvoering mislukt, zal niets wat u met uw dataset doet helpen.

   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

Stap 5: het fine-tune commando en de werkelijke standaardwaarden van de flags

Vervang de demo dataset door de jouwe en voeg de gewenste instellingen toe. Hieronder staat de volledige vorm die de repository gebruikt in zijn eigen new-embodiment tutorial, inclusief de augmentatie- en checkpointing flags die het korte README-voorbeeld weglaat. Dit is in de strikte zin: de taal-backbone en de visuele encoder blijven bevroren, en wat getraind wordt, zijn de projector en de diffusie-actie-head.

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

Die laatste rij is geen typefout. launch_finetune.py is een tyro CLI gegenereerd uit een dataclass, en die dataclass heeft geen seed-veld. De README vermeldt afzonderlijk een variantie van 5 tot 6 procent tussen runs, veroorzaakt door niet-deterministische beeldaugmentatie. Twee runs met identieke flags zullen geen identieke checkpoints produceren, wat veel uitmaakt wanneer je probeert te beslissen of een hyperparameterwijziging heeft geholpen of dat je geluk hebt gehad. Ter vergelijking, lerobot's eigen trainer gebruikt standaard seed 1000, en het LeRobot GR00T recept geeft --seed=42 expliciet mee.

Wat een run van 20000 stappen kost

GR00T N1.7 heeft een 80 GB kaart nodig, dus de kostenkwestie heeft een beperkt antwoord. Op AY-Robots draait de groot1.7 trainer op de A100 80 GB of H100 80 GB tier, waar een run 3 tot 6 uur duurt tegen 1.20 tot 2.00 USD per uur op de spotmarkt. Dat is ruwweg 4 tot 12 USD voor de standaardtaak van 20000 stappen. Dezelfde taak op SmolVLA of ACT draait op een 24 GB kaart tegen 0.30 tot 0.60 USD per uur en 1 tot 3 USD per run. Dat is de echte afweging: GR00T kost ongeveer vier keer zoveel per poging, en je kunt het niet draaien op de 4090 onder je bureau.

Het minimum van 50 aflevering is een ondergrens, geen doel. NVIDIA's eigen FAQ is veeleisender: ongeveer 100 trajecten voor een eenvoudige pick-and-place op een vaste locatie, 500 of meer voor complexe of meerstaps scènes, en 100 tot 500 voor fijne manipulatie. Als je op 20 afleveringen zit, besteed dan de middag aan opnemen in plaats van de avond aan afstemmen. De handleiding voor gegevensverzameling behandelt wat een nuttige aflevering onderscheidt van een verspilde, neem je eerste dataset op is de korte versie, en SO-100 gegevensverzameling is de arm-specifieke.

Stap 6: open-lus evaluatie voordat je de arm aanraakt

Plaats geen nieuw controlepunt op een fysieke arm om te achterhalen of de training heeft gewerkt. Voer eerst de open-lus evaluatie uit. Deze speelt een opgenomen episode opnieuw af, vraagt het model om acties bij elke stap, en plot de voorspelling tegen de grondwaarheid met MSE en MAE. Het kost niets en vangt de mappingfouten van stap 2 en 3 op.

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

De repository weigert bewust een doel-MSE voor aangepaste data te publiceren, en dat is terecht: het getal hangt af van uw actie-eenheden, uw taak en de grootte van uw dataset, dus een drempelwaarde gekopieerd van de arm van iemand anders betekent niets. Wat wel betekenisvol is, is de trend. Hier is de referentierun die de repository documenteert op een enkele H100 met de demo-dataset van vijf episodes en 2000 stappen.

De vorm is het signaal, niet de absolute waarden. De fout zou gestaag moeten dalen naarmate zich opstapelen. Gemiddeld over alle vijf trainingsepisodes in plaats van alleen traject 0, scoorde het uiteindelijke checkpoint van de repository ruwweg 7.5 MSE en 1.5 MAE, dus zelfs de referentierun leest anders afhankelijk van welke episodes je middelt. Leg je eigen baseline vast met de ongewijzigde democommando voordat je iets aan je eigen gegevens verandert: als je een bekende-goede run niet kunt reproduceren, kun je een configuratiefout niet onderscheiden van een gegevensprobleem. De repository brengt ook de veelvoorkomende symptomen in kaart met hun oorzaken, en elk daarvan is operationeel in plaats van een modelfout.

De andere route: lerobot-train in plaats van Isaac-GR00T

De huidige LeRobot release, 0.6.1 op PyPI sinds 3 augustus 2026, biedt een tweede en heel andere manier om dezelfde basisgewichten te fine-tunen. LeRobot exposeert GR00T N1.7 als een beleidstype en traint het via zijn eigen lerobot-train entry point. Twee dingen zijn hier van belang. De LeRobot CLI is een set van console scripts, dus alles wat je leest dat zegt python lerobot/scripts/train.py is verouderd en zal niet werken. En LeRobot heeft de ondersteuning voor GR00T N1.5 volledig verwijderd, waarbij N1.5 checkpoints en configuraties worden afgewezen met een migratienotitie, dus als je N1.5 via LeRobot nodig hebt, moet je lerobot==0.5.1, de laatste release die het ondersteunt, gepubliceerd op 7 april 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

Twee manieren om hetzelfde checkpoint te verkrijgen

Het checkpoint terug op de arm krijgen

Isaac-GR00T gebruikt een server-client splitsing over ZMQ. Het beleid draait op de GPU, en een dunne client op de robotmachine stuurt observaties en ontvangt actiechunks. Het SO-100 voorbeeld is compleet genoeg om te kopiëren: start run_gr00t_server.py met je checkpoint en --embodiment-tag NEW_EMBODIMENT, voer dan eval_so100.py uit aan de robotzijde met de seriële poort, de robot-ID, de camera-indices en de taalinstructie. De cameranamen in dat commando moeten overeenkomen met de vriendelijke namen uit je modality.json, niet met de OS-apparaatnummers.

# 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"

Nu het eerlijke deel over waar het beleid draait, want training en serving hebben verschillende hardwareverhalen. Fine-tuning vereist 40 GB of meer. Inferentie niet: de README vermeldt 16 GB of meer en noemt de RTX 4090 expliciet, dus een kaart die u al bezit, kan een checkpoint serveren dat het nooit had kunnen produceren. Wat bepaalt of het beleid responsief aanvoelt, is niet VRAM, maar waar de server zich bevindt. Op AY-Robots is GR00T N1.7 alleen in de cloud beschikbaar, dus de controlelus betaalt een round trip via het openbare internet bovenop de 152 ms per actiestap, en alleen SmolVLA en ACT draaien ook lokaal. Voor langzame pick-and-place is een externe pod te overleven. Voor alles wat reactief is, is dat niet het geval: het beleid wordt aarzelend op een manier die precies lijkt op een trainingsfout en dat niet is. ACT met 20 ms per actiestap is het model dat de strakste lus tolereert, SmolVLA zit op 245 ms, en geen enkele hoeveelheid latentie-afstemming koopt een round trip terug die al is verbruikt. Voer uw eerste beleid uit doorloopt de serving-kant van begin tot eind.

Wat er daadwerkelijk misgaat

• GatedRepoError bij de eerste uitvoering. U heeft geen toegang gekregen tot nvidia/Cosmos-Reason2-2B, of u heeft zich niet geauthenticeerd. Dit gebeurt nadat de GPU-klok al is gestart.
• Dataset geweigerd bij laden. Bijna altijd een v3.0 dataset. Converteer het naar een oudere versie. Zie dataset geweigerd als v3.
• IndexError over niet-overeenkomende booleaanse dimensies. U heeft delta_indices gewijzigd en de statistieken niet opnieuw gegenereerd.
• Onvoldoende geheugen bij batch 32. Verlaag --global-batch-size en verhoog --gradient-accumulation-steps, of verlaag --num-shards-per-epoch, wat de configuratie expliciet suggereert wanneer VRAM beperkt is. Zie onvoldoende geheugen tijdens training.
• Verlies daalt, beleid doet niets. Er is standaard geen validatiesplit, dus een schone trainingscurve bewijst weinig. Deze pagina behandelt de diagnose.
• Werkt in uw opstelling en nergens anders. Verwacht bij een kleine dataset gefilmd onder één lichtconditie. NVIDIA raadt kleurjitter-augmentatie plus 20 tot 50 afleveringen onder verschillende lichtomstandigheden aan. Meer hier.
• Grijper sluit nooit goed. Controleer of de grijperactie ABSOLUUT is en de armgewrichten RELATIEF, in die volgorde in action_configs. Grijper sluit niet vermeldt de andere oorzaken.
• Een camera valt stil uit tijdens de opname. De aflevering wordt nog steeds opgeslagen en de videosleutel bestaat nog steeds, daarom is dit zo vervelend. Camera niet gedetecteerd behandelt dit.

De volledige index van storingsmodi vindt u op de fix-pagina's. Als u kiest tussen modellen in plaats van er een te debuggen, de beleidsvergelijking en de arena-vermelding voor GR00T N1.7 hebben benchmarkcijfers met bronnen, en ACT versus GR00T N1.7 is de vergelijking die de meeste mensen daadwerkelijk nodig hebben, omdat het de keuze is tussen een model dat u kunt trainen op de kaart onder uw bureau en een model waarvoor u een 80 GB node moet huren om te fine-tunen. Voor achtergrondinformatie over waarom deze modellen zich gedragen zoals ze doen, zijn de VLA-overzicht en de SO-100 complete gids het eerst waard om te lezen. En als u nog geen arm bezit, de live arm streamt een fysieke SO-100 zonder aanmelding.