
SmolVLA est un VLA de 450 millions de paramètres qui s'affine sur une seule carte de 24 Go. Les vraies commandes lerobot 0.6.1, les valeurs par défaut réelles, les pièges qui coûtent une journée et le coût d'une exécution.
SmolVLA en un coup d'œil
- •450 millions de paramètres, dont environ 100 millions sont un expert d'action de correspondance de flux. lerobot n'entraîne que cet expert et maintient le VLM gelé, c'est pourquoi il tient sur une seule carte.
- •Le guide de calcul de LeRobot estime que le groupe smolvla nécessite environ 10 à 16 Go de VRAM de pointe avec un batch de 8 et AdamW. D'où 24 Go.
- •Le point d'entrée est lerobot-train. Le billet de blog SmolVLA de juin 2025 affiche toujours python lerobot/scripts/train.py, un chemin qui n'existe plus. Tout ce qui suit concerne lerobot 0.6.1.
- •Le programme cosinus est préréglé pour décroître sur 30000 étapes. lerobot 0.6.1 le réduit pour une exécution plus courte et le logue, mais jamais à la hausse : l'exécution standard de 100000 étapes se termine sur le plancher de 2.5e-6 pendant 70000 étapes.
- •Trente épisodes est le minimum d'AY-Robots, sur un niveau de 24 Go coûtant 1 à 3 USD par exécution contre 4 à 12 pour les modèles de 80 Go.
La plupart des gens qui veulent un modèle d'action vision-langage sur un bras réel s'arrêtent à la ligne matérielle. GR00T N1.7 et Pi0.5 ont environ trois milliards de paramètres chacun et nécessitent une A100 80 Go ou une H100. Si vous possédez un PC de jeu avec une RTX 4090, c'est la fin du chemin. SmolVLA est l'exception : 450 millions de paramètres, au sein de LeRobot, conçu pour être affiné sur une carte grand public et servi depuis un CPU.
La voie manuelle d'abord : installez lerobot, téléchargez le lerobot/smolvla_base checkpoint, exécutez la commande réelle, lisez l'exécution pendant qu'elle se déroule. Ensuite, la voie de la plateforme, et là où elle n'aide pas.
Ce qu'est SmolVLA, en chiffres vérifiables
SmolVLA est une correspondance de flux politique boulonnée sur un petit modèle de langage visuel. L'architecture est SmolVLM2-500M-Video-Instruct ; l'article ne conserve que les 16 premières couches de son modèle de langage, limite chaque image de caméra à 64 jetons visuels avec un mélange de pixels (pixel shuffle) au lieu d'un pavage d'images, et intercale l'attention croisée avec une couche d'auto-attention tous les deux blocs. Le coût d'inférence était une contrainte de conception, pas une réflexion après coup.
| Propriété | Valeur | Source |
|---|---|---|
| Paramètres totaux | about 450 M | paper |
| Expert en action | about 100 M, flow matching | paper |
| Architecture VLM | HuggingFaceTB/SmolVLM2-500M-Video-Instruct | vlm_model_name |
| Couches VLM utilisées | first 16 of the language model | num_vlm_layers = 16 |
| Jetons visuels par image | 64, pixel shuffle, no tiling | paper |
| Pré-entraînement | 481 community datasets, 22.9 K episodes, 10.6 M frames; 200000 steps at global batch 256 on 4 GPUs | paper |
Les benchmarks expliquent pourquoi les gens s'intéressent à un modèle de 450 M. Sur LIBERO, il obtient en moyenne 87,3 percent contre 76,5 pour OpenVLA à 7 B et 86,0 pour un Pi0 pré-entraîné en robotique à 3,3 B ; sur Meta-World, 57,3 contre 47,9. Sur du matériel SO-100 réel, l'entraînement multi-tâches donne 75 percent sur le ramassage et le placement, 90 sur l'empilement, 70 sur le tri, avec une moyenne de 78,3, là où ACT entraîné par tâche obtenait en moyenne 48,3. Les mêmes lignes figurent à côté de chaque VLA publié dans l' entrée de l'arène SmolVLA et la comparaison ACT contre SmolVLA.
SmolVLA n'est pas meilleur qu'un modèle de 3 B dans tous les domaines. Le tableau SO-101 de l'article le révèle : 90 percent de succès en distribution, 50 percent hors distribution, sur une plateforme sur laquelle il n'a jamais été pré-entraîné. Ce qu'il affirme, et soutient, c'est que par rapport à Pi0, il s'entraîne environ 40 percent plus vite avec 6 times moins de mémoire.
Pourquoi une carte de 24 Go est le bon choix pour une première exécution
LeRobot fournit un guide de dimensionnement du calcul, la page la plus utile du dépôt à cet effet. Il regroupe les politiques par taille de backbone et attribue une enveloppe de VRAM par groupe, mesurée avec une taille de lot de 8 et AdamW, la valeur par défaut de lerobot. L'état de l'optimiseur seul ajoute 30 à 100 pour cent par rapport à un simple passage avant et arrière, il ne s'agit donc pas de chiffres basés uniquement sur les poids.
| Groupe | Politiques | VRAM maximale (lot 8, AdamW) | GPU de démarrage |
|---|---|---|---|
| BC léger | act, vqbet, tdmpc | environ 2 à 6 Go | RTX 3060, L4 |
| Diffusion | diffusion, multi_task_dit | environ 8 à 14 Go | RTX 4070+, L4 |
| VLA petit | smolvla | environ 10 à 16 Go | RTX 4080+, L4, A10G |
| VLA grand | pi0, pi0_fast, pi05, xvla, wall_x | environ 24 à 40 Go | A100 40 GB+ |
| Multimodal | groot, eo1 | environ 24 à 40 Go | A100 40 GB+ |
Dix à seize gigaoctets avec un lot de 8, tel est l'argument : une carte de 24 Go peut gérer cela plus le dataloader. AY-Robots place SmolVLA sur la RTX 4090 ou toute carte de 24 Go, avec un minimum de 30 épisodes, LeRobot v3.0 de données, 245 ms par étape d'action. En location, cela représente 2 à 5 heures à 0,30 à 0,60 USD de l'heure, soit environ 1 à 3 USD par réglage fin d'exécution, contre 4 à 12 USD sur le niveau de 80 Go dont GR00T et Pi0.5 ont besoin (tarification). Une exécution SmolVLA échouée coûte un café ; une exécution GR00T échouée, un déjeuner.

- Compatible avec le matériel que vous possédez peut-être déjà : environ 10 à 16 Go avec un lot de 8.
- Une exécution ratée coûte des heures et quelques dollars, vous pouvez donc vous permettre de vous tromper sur le jeu de données.
- Pré-entraîné sur des jeux de données communautaires partagés sous le tag lerobot, avec de vrais résultats SO-100 et SO-101.
- Il est intégré à lerobot : pas de dépôt fournisseur, et smolvla_base n'est pas restreint.
- 450 M reste 450 M : le succès hors distribution chute de 90 à 50 pour cent dans le tableau SO-101 de l'article.
- Il nécessite des données LeRobot v3.0 ; un enregistrement v2.1 doit être converti (dataset rejected v3).
- 245 ms par étape d'action est un contrôleur de pick and place compétent, pas un contrôleur réactif.
- L'exemple de la documentation exécute un lot de 64 sur un A100 ; sur 24 Go, vous échangez la taille du lot contre le temps réel.
Étape 0 : le jeu de données décide de l'exécution, pas les drapeaux
Rien de ce qui suit n'a d'importance si l'enregistrement est mauvais. La page LeRobot SmolVLA est claire : le jeu de données de référence était de 50 épisodes répartis sur 5 positions de cube, 10 par position, et la même tâche avec 25 épisodes a mal fonctionné. La répétition par variation généralise, le nombre brut d'épisodes non. Vous n'en avez jamais enregistré ? Commencez par enregistrer votre premier jeu de données avec le client de bureau, qui écrit le format LeRobot à partir d'une téléopération session, ou empruntez-en un depuis le répertoire de jeux de données.
- Au moins 30 épisodes sur AY-Robots, environ 50 pour la recette de référence LeRobot.
- Chaque variation attendue lors du déploiement, répétée plusieurs fois.
- Une chaîne de caractères de tâche, orthographiée de manière identique lors de l'enregistrement et du déploiement. Le modèle est conditionné par ce texte.
- Caméras fixes. Une caméra déplacée entre l'enregistrement et le déploiement est la raison la plus courante pour laquelle une courbe de perte propre donne un bras immobile.
- Une variation mise de côté sur laquelle vous n'avez jamais entraîné, afin d'avoir quelque chose d'honnête à tester.
SmolVLA, Pi0.5 et ACT nécessitent LeRobot v3.0. GR00T N1.7 et N1.5 nécessitent v2.0 ou v2.1 et leur chargeur plante avec v3.0. Enregistrez une fois, prévoyez de comparer les modèles plus tard, et vous convertirez d'une manière ou d'une autre : jeu de données rejeté v3.
# v2.1 -> v3.0: aggregates per-episode files into shards and writes the episode offsets
python -m lerobot.scripts.convert_dataset_v21_to_v30 --repo-id=${HF_USER}/so100_pick_placePlus d'informations à ce sujet dans comment collecter des données d'entraînement VLA de haute qualité. En bref : 30 à 50 épisodes propres d'une tâche avec une variation délibérée sont plus efficaces que 200 épisodes bâclés de trois tâches, avec une marge qu'aucun hyperparamètre ne peut combler.
Installer lerobot 0.6.1
# LeRobot needs Python 3.12 or newer as of 0.6.x
conda create -y -n lerobot python=3.12
conda activate lerobot
# TorchCodec decodes the dataset videos and wants ffmpeg
conda install ffmpeg -c conda-forge
# Base package is deliberately thin; extras pull the rest
pip install 'lerobot[smolvla,training,core_scripts]'
# Sanity check: prints the lerobot version, the GPU torch sees, and the console scripts you got
lerobot-infoL'installation de base lerobot est légère et masque les dépendances lourdes derrière des extras : smolvla ajoute transformers, num2words et accelerate, training la pile de données et wandb, core_scripts les dépendances matérielles et de visualisation. Sous Linux, le chemin d'installation détermine également votre roue CUDA : la valeur par défaut de PyPI est une roue cu130 avec un pilote minimum de 580.65, donc sur un pilote plus ancien, installez d'abord torch à partir de l'index cu128, puis lerobot.
--policy.path=lerobot/smolvla_base charge le point de contrôle pré-entraîné de 450 M et l'affine. --policy.type=smolvla construit un nouveau SmolVLA, et la valeur par défaut de la configuration load_vlm_weights = False signifie qu'il ne télécharge même pas les poids du backbone SmolVLM2 à moins que vous ne le demandiez. Si vous vous trompez, l'exécution s'entraîne joyeusement, coûte le même prix et n'apprend rien de transférable.
L'exécution de l'entraînement, commande par commande
- 1S'authentifier auprès du Hub
Le point de contrôle de base provient du Hub, et votre jeu de données probablement aussi.
bashhf auth login - 2Lire les options une fois
Chaque champ de la configuration du pipeline et de la politique est un drapeau. Parcourez-le avant de plonger dans le code source.
bashlerobot-train --help - 3Lancer le réglage fin
L'exemple de la documentation exécute un lot de 64 sur une seule A100 ; l'ancre A100 40 Go du guide de calcul est un lot de 16, et 8 est l'équivalent pour 24 Go. Pas de drapeau de planificateur ici volontairement, voir ci-dessous.
bashlerobot-train \ --policy.path=lerobot/smolvla_base \ --dataset.repo_id=${HF_USER}/so100_pick_place \ --batch_size=8 \ --steps=20000 \ --save_freq=2000 \ --log_freq=200 \ --seed=1000 \ --output_dir=outputs/train/smolvla_pick_place \ --job_name=smolvla_pick_place \ --policy.device=cuda \ --wandb.enable=true - 4Lire la ligne de journal, pas seulement la perte
Toutes les --log_freq étapes, lerobot affiche loss, grdn, lr, updt_s, data_s, smp/s et, sur CUDA, mem_gb. mem_gb indique si le lot tient, lr si le programme décroît, et data_s approchant updt_s signifie que le dataloader est le goulot d'étranglement, pas le GPU.
bash# if data_s creeps toward updt_s lerobot-train ... --num_workers=8 - 5Collecter les points de contrôle que vous pouvez comparer
save_freq est par défaut à 20000, donc une exécution de 20000 étapes ne laisse qu'un seul point de contrôle et rien à comparer. Définissez 2000. Pousser vers le Hub nécessite --policy.repo_id.
bash--save_freq=2000 \ --policy.repo_id=${HF_USER}/smolvla_pick_place \ --save_checkpoint_to_hub=true - 6Reprendre si la machine s'arrête
Pointez --config_path vers le train_config.json à côté du point de contrôle. lerobot refuse de démarrer dans un output_dir existant à moins que vous ne repreniez, vous ne pouvez donc pas écraser une exécution par accident.
bashlerobot-train \ --config_path=<path to the saved train_config.json> \ --resume=true
Les drapeaux qui modifient réellement le résultat
| Drapeau | Ce qu'il fait | Sur 24 Go |
|---|---|---|
| --batch_size | Échantillons par étape, à peu près linéaire en VRAM | 4 à 8 |
| --steps | Nombre total d'étapes de l'optimiseur | 20000 premier passage |
| --policy.scheduler_decay_steps | Longueur de décroissance cosinus, préréglée à 30000 | N'agit qu'au-delà de 30000 |
| --policy.use_amp | Précision mixte ; SmolVLA n'a pas de champ dtype | true lorsque la mémoire est limitée |
| --num_workers | Processus du dataloader, par défaut 4 | Augmenter jusqu'à ce que data_s cesse de grimper |
| --dataset.eval_split | Fraction des épisodes mis de côté par tâche | 0.1, avec --eval_steps |
| --policy.freeze_vision_encoder | Maintient la tour de vision gelée | true sur 24 Go |
| --policy.train_expert_only | Seul l'expert d'environ 100 M reçoit des gradients | true en premier |
SmolVLA prédéfinit un calendrier cosinus : `scheduler_warmup_steps = 1000`, `scheduler_decay_steps = 30000`, `scheduler_decay_lr = 2.5e-6`. Les anciens conseils indiquent qu'une exécution de 20000 étapes stagne donc à mi-décroissance. Dans la version 0.6.1, ce n'est pas le cas : `CosineDecayWithWarmupSchedulerConfig.build()` reçoit `--steps`, et en dessous de `num_decay_steps`, il redimensionne les deux, le warmup de 1000 à 666 et le decay de 30000 à 20000, affichant Auto-scaling LR scheduler ce faisant. Il ne redimensionne jamais à la hausse : la décroissance est limitée par `min(current_step, decay_steps)`, de sorte que le `--steps=100000` par défaut reste au minimum de l'étape 30000 jusqu'à la fin, soit 70 percent de l'exécution. Seule cette longue période nécessite encore `--policy.scheduler_decay_steps`. La colonne `lr` est l'endroit où vérifier.
Les valeurs par défaut que vous héritez si vous ne touchez à rien
Une politique configuration dans lerobot contient son propre optimiseur et préréglage de planificateur, et à moins que vous ne définissiez use_policy_training_preset=false ces préréglages l'emportent. La moitié des questions que les gens posent sur l'entraînement de SmolVLA trouvent leur réponse dans une valeur par défaut dont ils ignoraient l'existence.
| Paramètre | Valeur par défaut dans lerobot 0.6.1 | Défini dans |
|---|---|---|
| chunk_size / n_action_steps | 50 / 50 | SmolVLAConfig |
| num_steps (débruitage par correspondance de flux) | 10 | SmolVLAConfig |
| optimizer_lr | 1e-4 | SmolVLAConfig |
| scheduler_warmup_steps | 1000 | SmolVLAConfig |
| scheduler_decay_steps | 30000 | SmolVLAConfig |
| scheduler_decay_lr | 2.5e-6 | SmolVLAConfig |
| freeze_vision_encoder | true | SmolVLAConfig |
| train_expert_only | true | SmolVLAConfig |
| batch_size / steps | 8 / 100000 | TrainPipelineConfig |
| seed / save_freq / num_workers | 1000 / 20000 / 4 | TrainPipelineConfig |
Les deux lignes qui surprennent sont freeze_vision_encoder et train_expert_only, toutes deux vraies. Par défaut, vous entraînez environ 100 millions de paramètres, pas 450 millions, c'est pourquoi cela tient sur 24 Go. L'exécution de référence de LeRobot sur un cluster H100 à quatre GPU les passe toutes deux à faux ; sur une carte de 24 Go, cela transforme une exécution fonctionnelle en .
Le conseil du guide lorsque vous êtes limité par la mémoire est de réduire la taille du lot (batch size) et d'utiliser l'accumulation de gradients pour retrouver le lot effectif. Il n'y a pas d'accumulation de gradients dans lerobot 0.6.1 : TrainPipelineConfig n'a pas un tel champ et la chaîne de caractères n'apparaît nulle part dans le package publié. Le formulaire AY-Robots indique une valeur d'accumulation de gradients de 8 pour SmolVLA et ne l'applique pas non plus. Vos leviers sur 24 Go sont --batch_size, les deux valeurs par défaut de gel (freeze defaults), et --policy.use_amp.
Combien de temps dure l'exécution et combien d'étapes sont suffisantes
LeRobot publie des points de référence en temps réel pour cinq époques sur un ensemble de données d'environ 50 épisodes, soit environ 45000 images à 30 ips. Des chiffres d'ordre de grandeur, disent les documents, mais ils représentent la différence entre s'attendre à une heure et à une journée.
| Configuration | Politique | Lot | Temps réel |
|---|---|---|---|
| L4 / A10G unique (24 Go) | smolvla | 4 | environ 3 à 6 h |
| A100 40 Go unique | smolvla | 16 | environ 1 à 2 h |
| 4 x H100 80 Go avec accélération | smolvla | 32 | environ 1 à 2 h |
| RTX 4090 / RTX 3090 unique (24 Go) | act | 8 | environ 30 à 60 min |
La règle est de 5 à 10 époques sur l'ensemble de données, pas un nombre fixe d'étapes : steps_per_epoch = ceil(total_frames / (num_gpus x batch_size)). Sur l'ensemble de données de référence indiqué dans la documentation, lerobot/svla_so100_pickplace, les métadonnées rapportent 50 épisodes et 19631 images : un lot de 8 donne environ 2454 étapes par époque, donc 20000 étapes représentent environ 8 époques. Réduisez le lot de moitié et le même budget permet d'acheter la moitié des époques, alors refaites ce calcul chaque fois que vous modifiez --batch_size.
Exécuter la politique affinée sur le bras
lerobot-rollout \
--strategy.type=base \
--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}}" \
--task="Grasp the cube and put it in the box." \
--policy.path=${HF_USER}/smolvla_pick_placeLes 245 ms par étape d'action sont faciles à mal interpréter : la politique émet chunk_size = 50 actions par passe avant et exécute n_action_steps = 50 d'entre elles, donc la fréquence à laquelle vous payez ce coût est définie par ces paramètres, et non par la fréquence à laquelle les servomoteurs reçoivent une commande. C'est ce que le découpage d'actions permet, et pourquoi un modèle de 245 ms peut piloter un bras à 30 Hz. Ce qui reste est la latence d'inférence à la fin du chunk.
| Mesure (SmolVLA, SO-100 réel) | Synchrone | Asynchrone |
|---|---|---|
| Temps d'achèvement, prise et dépose, 10 essais | 13.75 s | 9.70 s |
| Cycles de prise et dépose dans une fenêtre de temps fixe | 9 | 19 |
| Taux de succès moyen sur les trois tâches | 78.3 % | 73.3 % |
Cette troisième ligne est ce que la plupart des articles omettent. L'inférence asynchrone est environ 30 % plus rapide et double approximativement le débit dans une fenêtre fixe, et l'article qualifie les taux de succès de comparables, ce qu'ils sont en moyenne. En dessous, le tri est passé de 70 à 50 % tandis que la prise et dépose a gagné 5. lerobot 0.6.1 intègre l'autre levier dans le même binaire : --inference.type=rtc bascule le déploiement vers le découpage en temps réel, ce que le bloc d'utilisation du script recommande pour les VLAs lents, Pi0, Pi0.5 et SmolVLA.
La boucle de contrôle est de 20 à 485 ms par étape d'action selon le modèle, et les allers-retours sur l'internet public transforment en plus une politique fonctionnelle en une politique hésitante. L'inférence à distance est viable pour la prise et dépose lente, pas pour les mouvements réactifs rapides : si la tâche nécessite des corrections rapides, le GPU doit être sur le même réseau local que le bras.
Hors sujet pour un entraînement, mais cela met fin à plus de projets SO-100 que n'importe quel hyperparamètre. Les servomoteurs Feetech STS3215 des SO-100 et SO-101 fonctionnent à 7,4 V ; 12 V les détruit. Le LeKiwi combine un bras de 7,4 V avec une base de 12 V, c'est ainsi que la mauvaise prise d'alimentation trouve la mauvaise douille.
Deux chemins vers le même point de contrôle
Vous possédez la machine, l'environnement et le débogage. La seule dépendance au cloud est le téléchargement du point de contrôle de base depuis le Hub. La bonne approche si vous souhaitez modifier la politique, si les données ne peuvent pas quitter votre réseau, ou si la carte est inactive.
- Vous contrôlez la roue CUDA, le pilote, la compilation ffmpeg et le dataloader.
- Vous pouvez patcher configuration_smolvla.py et réentraîner le même après-midi.
- Vous payez en électricité et en temps, pas par exécution, et déboguez TorchCodec vous-même.
pip install 'lerobot[smolvla,training,core_scripts]'
hf auth login
lerobot-train \
--policy.path=lerobot/smolvla_base \
--dataset.repo_id=${HF_USER}/so100_pick_place \
--batch_size=8 --steps=20000 \
--save_freq=2000 --seed=1000 \
--output_dir=outputs/train/smolvla_pick_place \
--job_name=smolvla_pick_place \
--policy.device=cuda --wandb.enable=trueLa même exécution derrière un formulaire : vous choisissez le modèle et le jeu de données, le backend loue un GPU en fonction de la VRAM requise, exécute l'entraîneur et écrit points de contrôle vers le stockage d'objets. Le jeu de données peut provenir d'un ID de dépôt Hugging Face, du répertoire, ou de votre machine. Commencez par SmolVLA sur SO-100, ou la matrice sur la page d'entraînement.
| Champ | Valeur par défaut envoyée par la plateforme pour SmolVLA | Remarque |
|---|---|---|
| taille du lot | 2 | Conservateur pour le niveau 24 Go |
| taux d'apprentissage | 1e-4 | Le préréglage lerobot |
| étapes max | 20000 | L'exécution de référence dans la documentation LeRobot |
| accumulation de gradient | 8 | Affiché dans le formulaire, non appliqué |
| paramètres supplémentaires | seed, logFreq | Seed rend l'exécution reproductible |
- 2 à 5 heures sur le niveau 24 Go, environ 1 à 3 USD par exécution.
- Les mêmes opérations depuis un terminal à /cli et depuis des agents IA à /mcp.
- Les pods d'inférence sont équipés d'un chien de garde d'inactivité, de sorte qu'un pod oublié se détruit au lieu de facturer discrètement.
- Pas encore de bras ? /live diffuse un SO-100 physique que vous pouvez piloter sans inscription.
Un travail bloqué dans la file d'attente est un symptôme du marché spot, pas un bug : travail d'entraînement bloqué en file d'attente. Étape par étape : entraînez votre première politique et la documentation d'entraînement.
Quand SmolVLA est le mauvais choix
Le critère pour savoir si SmolVLA était le bon premier essai n'est pas s'il a fonctionné, mais si l'échec vous a appris quelque chose. Atteignez 60 ou 70 pour cent et un modèle plus grand est un investissement raisonnable : les données contiennent un signal. Atteignez 10 pour cent et un modèle de 3 milliards atteindra très probablement aussi 10 pour cent, ce que vous venez d'apprendre pour trois dollars au lieu de douze.

À lire avant de dépenser plus : Pi0.5 contre SmolVLA pour plus de capacité sur la même idée, et GR00T N1.7 contre SmolVLA pour la voie NVIDIA, les deux en catégorie 80 Go à 4 à 12 USD par exécution. L'autre option, ACT est la base de référence moins chère : 80 M paramètres, 20 ms par étape d'action, pas de conditionnement linguistique. Les cinq se trouvent sur la page des politiques; l'arène contient 85 modèles et 332 résultats de benchmark.

La liste de contrôle avant de passer à l'échelle
- Le
lra-t-il atteint son seuil de 2.5e-6 ? En dessous de 30000 étapes, lerobot rééchelonne la décroissance et l'indique au démarrage ; au-delà, définissez vous-même--policy.scheduler_decay_steps. - Plus d'un point de contrôle, et des épisodes mis de côté avec
--dataset.eval_splitpour que la perte d'évaluation ait un sens. - La politique bouge-t-elle du tout ? Une perte qui diminue avec un bras immobile a des causes spécifiques : la perte diminue, la politique ne fait rien.
- Survit-elle à un changement de scène ? Sinon : la politique ne fonctionne que dans une seule configuration.
- Avez-vous noté la graine (seed) ? lerobot utilise 1000 par défaut, de sorte que deux exécutions non modifiées restent comparables.
- Seulement ensuite : plus d'épisodes, plus de variation, ou un modèle plus grand. Dans cet ordre.
Pour comprendre pourquoi ces modèles existent et ce qu'ils font avec l'entrée linguistique, est le contexte ; décrit l'assemblage, de la à la première exécution d'. Pour le point de contrôle final, ; si le bras n'apparaît jamais, consultez .
Entraînez SmolVLA sur votre propre bras
Choisissez le modèle et le bras, et le guide vous donnera les valeurs par défaut exactes, le format du jeu de données et le coût de l'exécution. SmolVLA se situe sur le niveau 24 Go à 1 à 3 USD par exécution.
Ouvrir les guides de formationPuis-je vraiment affiner SmolVLA sur une RTX 4090 ?▾
Oui. Le guide de calcul de LeRobot estime la VRAM de pointe de SmolVLA à environ 10 à 16 Go pour un batch de 8 avec AdamW et indique que les cartes grand public de 24 Go sont confortables pour cela. Le batch de 64 dans l'exemple de la documentation est associé à un seul A100. La mémoire évolue à peu près linéairement avec le batch, utilisez donc 4 ou 8 et surveillez mem_gb.
De combien d'épisodes ai-je réellement besoin ?▾
AY-Robots fixe le minimum à 30. La documentation de LeRobot recommande environ 50 et rapporte que 25 épisodes de la même tâche ont donné de mauvais résultats. La structure l'emporte sur le nombre : l'ensemble de référence était de 5 positions de cube avec 10 épisodes chacune, et cette répétition est ce qui généralise.
La documentation indique un batch de 64, la plateforme envoie un batch de 2. Lequel est correct ?▾
Les deux, pour différents matériels. L'exemple de la documentation utilise un batch de 64 et mentionne environ 4 heures pour 20000 étapes sur un seul A100 ; l'ancre A100 40 Go du guide de calcul est un batch de 16. Le batch de 2 est ce que AY-Robots envoie sur le niveau 24 Go. Localement, 4 à 8 est le juste milieu, et l'arithmétique des époques change avec cela.
SmolVLA ou ACT pour une première exécution sur un SO-100 ?▾
ACT si la tâche est un mouvement répétitif et que vous voulez la boucle la plus rapide : 20 ms par étape d'action, 80 M de paramètres, pas de conditionnement linguistique. SmolVLA si vous voulez un conditionnement linguistique, plusieurs chaînes de tâches dans un seul checkpoint, et une base pré-entraînée. Les deux se situent sur le niveau 24 Go, donc le choix est la tâche, pas le budget.
Dois-je définir --policy.scheduler_decay_steps ?▾
Seulement lorsque --steps est supérieur à 30000. SmolVLA prérègle la décroissance cosinus à 30000 étapes, et lerobot 0.6.1 la réduit automatiquement pour une exécution plus courte, en enregistrant "Auto-scaling LR scheduler" lorsqu'il le fait. Il ne l'augmente jamais, donc le --steps=100000 par défaut laisse les 70000 dernières étapes au plancher de 2.5e-6.
Sources
- SmolVLA : Un modèle Vision-Langage-Action pour une robotique abordable et efficace
- SmolVLA : Modèle Vision-Langage-Action efficace (blog Hugging Face)
- Fiche modèle lerobot/smolvla_base
- Documentation LeRobot : SmolVLA
- Documentation LeRobot : Guide matériel de calcul pour l'entraînement LeRobot
- Documentation LeRobot : Installation
- Documentation LeRobot : LeRobotDataset v3.0 et le convertisseur v2.1
- Documentation LeRobot : Inférence asynchrone
- lerobot v0.6.1 : configuration_smolvla.py
- lerobot v0.6.1 : TrainPipelineConfig
- lerobot v0.6.1 : CosineDecayWithWarmupSchedulerConfig
- lerobot v0.6.1 : lerobot_rollout.py (stratégies et inférence RTC)
- lerobot v0.6.1 : pyproject.toml (extras et points d'entrée console)
- lerobot sur PyPI
- Jeu de données lerobot/svla_so100_pickplace (50 épisodes, 19631 images, v3.0)
Sources
- SmolVLA: A Vision-Language-Action Model for Affordable and Efficient Robotics
- SmolVLA: Efficient Vision-Language-Action Model (Hugging Face blog)
- lerobot/smolvla_base model card
- LeRobot docs: SmolVLA
- LeRobot docs: Compute HW Guide for LeRobot Training
- LeRobot docs: Installation
- LeRobot docs: LeRobotDataset v3.0 and the v2.1 converter
- LeRobot docs: Asynchronous Inference
- lerobot v0.6.1: configuration_smolvla.py
- lerobot v0.6.1: TrainPipelineConfig
- lerobot v0.6.1: CosineDecayWithWarmupSchedulerConfig
- lerobot v0.6.1: lerobot_rollout.py (strategies and RTC inference)
- lerobot v0.6.1: pyproject.toml (extras and console entry points)
- lerobot on PyPI
- lerobot/svla_so100_pickplace dataset (50 episodes, 19631 frames, v3.0)
Ready for high-quality robotics data?
AY-Robots connects your robots to skilled operators worldwide.
Get Started