Записуйте, навчайте та розгортайте з одного місця за допомогою Strands Agents, LeRobot і Hugging Face Storage Buckets

Записуйте, навчайте й розгортайте в одному місці за допомогою Strands Agents, LeRobot і Storage Buckets Hugging Face Огляд циклу потокової обробки даних у Strands Robots: один агентський цикл записує демонстрації робота, навчається на них, безпосередньо читаючи дані з Hub, і розгортає політику назад на апаратному забезпеченні; при цьому набір даних увесь час зберігається в тому самому дисковому форматі LeRobot.

У вас уже є агент, який може записати демонстрацію та передати її до Hugging Face Hub. Тепер ви хочете запускати цей цикл безперервно: збирати епізоди протягом дня, навчати політику на наборі даних, що зростає, розгортати її та отримувати наступну партію даних для подальшого вдосконалення. Якщо запустити цикл один раз, кожен компонент працює. Але якщо запускати його щодня, ви починаєте знову й знову платити за ті самі передавання байтів. Завантажені записи постійно збільшуються, кожен запуск навчання копіює весь набір даних на графічні процесори ще до початку роботи, а кожна нова контрольна точка передається назовні, поки наступна партія записів надходить назад.

У першій публікації цієї серії було представлено Strands Robots — SDK з відкритим кодом від AWS (Apache 2.0), який надає абстракції для роботів, симуляцію та стек LeRobot як AgentTools, що компонуються в одного агента Strands. Там розглядалися фабрика Robot(), запис демонстрації в симуляції, запуск політики та розгортання того самого коду агента на фізичному SO-101. Ця фабрика зіставляє ім’я з реєстром маніпуляторів, гуманоїдів, мобільних платформ і кистей, тому SO-100, який використовується в цій публікації, є лише одним із багатьох підтримуваних типів роботів. У каталозі роботів наведено всіх роботів, яких знає фабрика. Формат наборів даних LeRobot уже використовується понад 90 000 наборами даних і моделями на Hub від більш ніж 8 000 видавців (LeRobot Project Pulse). Запис Strands Robots є ще одним таким набором, тому будь-який інструмент, призначений для читання даних LeRobot, може читати його без перетворення. Якщо ви вперше працюєте зі Strands Robots, почніть із цієї публікації; тут передбачається, що налаштування вже виконано.

У тій публікації агентський цикл розглядався в одному напрямку — від набору даних на Hub до фізичного робота. Тут ми простежимо рух даних у зворотному напрямку: від першого записаного кадру до розгорнутої політики через Hugging Face Storage Buckets — змінюваний, нев versionований тип репозиторію об’єктного сховища на основі Xet, анонсований у березні 2026 року. Бакет розташований поруч із репозиторіями ваших наборів даних у тому самому просторі імен hf:// і використовує вже наявний у вас CLI hf, тож стає робочим рівнем для зберігання даних між днем їх запису та днем навчання на них.

Хтось має вирішувати, які епізоди залишати, коли сцена достатньо змінилася, щоб записати її знову, чи достатньо сьогоднішньої партії для навчання та яка контрольна точка замінить ту, що встановлена на маніпуляторі. Кожне з цих рішень виникає десятки разів протягом кампанії зі збору даних, і для кожного потрібно переглянути отримані результати, перш ніж виконувати наступну команду. Саме для цього потрібен агент. У цій публікації ви крок за кроком пройдете весь цикл даних усередині одного агента: запишете демонстрацію в Storage Bucket, збережете її так, щоб під час кожної синхронізації завантажувалися лише змінені байти, навчатимете модель потоково безпосередньо з Hub замість завантаження всього набору даних і розгорнете контрольну точку назад на апаратному забезпеченні, змінивши один іменований аргумент. Запущений супровідний приклад доступний за адресою examples/notebooks/05_streaming_data_loop.ipynb.

Що ви створите

Якщо в першій публікації набір даних записувався й передавався на Hub, то агент, якого ви створите тут, записує LeRobotDataset із запиту природною мовою, синхронізує його зі Storage Bucket, а потім потоково повертає той самий набір даних кадр за кадром, декодуючи відео з камер на льоту, без локальної копії. Ви зчитуєте дані в тому самому процесі, який їх записав: той самий Strands Robots Robot(), що записав набір даних, і передає його потоково. Після цього навчена контрольна точка розгортається на тому самому Robot() зі зміною одного іменованого аргументу, а демонстрації, записані на апаратному забезпеченні, повертаються до того самого бакета.

Рисунок 1. Усі чотири етапи використовують один спільний бекенд. Robot("so100") записує LeRobotDataset через спільний DatasetRecorder; sync_dataset_to_bucket(...) синхронізує його зі Storage Bucket; stream_dataset(...) зчитує його назад через Hub без повного завантаження; а навчена контрольна точка розгортається на тому самому Robot за допомогою mode="real". Формат на диску залишається точно таким, яким його записав LeRobot.

Оскільки один Robot() і записує набір даних, і зчитує його назад, збір даних і навчання на них є двома методами одного об’єкта, що працюють через один бекенд. Агент вирішує запустити епізод і викликає один інструмент; після цього виконання триває з частотою керування робота, доки епізод не завершиться, а навчена політика генерує кожну дію. Весь цикл у кількох рядках:

from strands import Agent
from strands_robots import Robot

sim = Robot("so100")                 
agent = Agent(tools=[sim])


agent("Record a pick-the-cube demo and sync it to my-org/robot-fave.")


for batch in sim.stream_dataset("my-org/robot-fave/cube_pick", repo_type="bucket").dataloader(batch_size=64):
    ...

Далі розглянемо, що насправді відбувається всередині цього циклу, крок за кроком.

Передумови

Мінімальні (стандартний шлях симуляції)

• Python 3.12+ у Linux або macOS (Apple Silicon підтримується бекендом MuJoCo).
• Провайдер моделі, сумісний зі Strands, для міркувань агента. Amazon Bedrock з обліковими даними AWS, Anthropic API, OpenAI або Ollama, що працює локально.
• Strands Robots із додатковими компонентами для роботи з наборами даних: uv pip install -U "strands-robots[sim-mujoco,lerobot]>=0.5.1". Додатковий компонент lerobot встановлює LeRobot (>=0.6.1), datasets, av і torchcodec, тому запис і декодування відео працюють без подальшого налаштування. Див. посібник зі встановлення.

Ось і все. Кожен етап цієї публікації працює на ноутбуці з цими трьома компонентами. Працює саме цикл, а не повноцінна політика: стандартний шлях використовує імітаційну політику, яка записує коректний набір даних, але не корисний.

Розширені (бакети, апаратне забезпечення, реальні політики)

• Обліковий запис Hugging Face і токен із дозволом на запис, а також CLI hf для створення бакетів і синхронізації наборів даних: pip install -U "huggingface-hub>=1.6.0,<2.0.0", потім hf auth login.
• Для роботи з апаратним забезпеченням: пара follower і leader SO-101 або будь-який інший робот, підтримуваний LeRobot, із файлами калібрування в ~/.cache/huggingface/lerobot/calibration/.
• Для локального виведення vision-language-action (VLA): графічний процесор NVIDIA. Для масштабного навчання — кластер графічних процесорів, що читає дані з Hub.
• Для виконання етапу навчання: uv pip install "lerobot[training]". Для запису й потокового читання це не потрібно. Якщо пропустити встановлення, trainer.train() поверне результат із помилкою замість контрольної точки. У посібнику з усунення несправностей наведено цю помилку та встановлення, яке її виправляє.

Крок 1 — Запис демонстрації в бакет

Протягом дня ви записуєте нові епізоди, кожен із яких є безперервною послідовністю кадрів із камер і телеметрії стану та дій суглобів. LeRobot записує це як невеликий набір великих файлів, які збільшуються в міру запису. Якщо передавати їх у версійований репозиторій набору даних, кожне доповнення стає комітом, а кожна редакція зберігається. Для збору даних потрібне протилежне: місце, куди можна записувати байти та перезаписувати їх на місці. Це і є Storage Bucket, який розташований у вашому робочому просторі Hugging Face і використовує наявні дозволи. Не потрібно налаштовувати ролі керування ідентифікацією та доступом (IAM), правила спільного використання ресурсів між джерелами (CORS) або підтримувати окремий сервіс завантаження.

Ваш агент записує LeRobotDataset у тому самому форматі, який LeRobot використовує на апаратному забезпеченні. Запишіть епізод, а потім синхронізуйте готовий набір даних із бакетом. У запиті вказано імітаційну політику — замінник, що створює дії суглобів без навченої моделі, — щоб ви могли виконати весь цикл ще до появи контрольної точки:

from strands import Agent
from strands_robots import Robot, sync_dataset_to_bucket

sim = Robot("so100")                 
agent = Agent(tools=[sim])

agent(
    "Create a world with the so100 robot, add a red cube and a front camera, "
    "start recording (repo_id='local/cube_pick', root='/tmp/cube_pick', fps=30, "
    "overwrite=True, task='pick up the red cube'), run the mock policy for "
    "60 steps, then stop recording."
)

sync_dataset_to_bucket("/tmp/cube_pick", "my-org/robot-fave")

Синхронізація записує дані в hf://buckets/{bucket}/{run_id}, де run_id за замовчуванням відповідає назві каталогу набору даних. Потокове читання на кроці 3 також вказує запуск: перші два сегменти ідентифікатора — це бакет, а все після них — шлях усередині нього.

sync_dataset_to_bucket(root, bucket, run_id=...) перевіряє набір даних і синхронізує його через CLI hf, незалежно від життєвого циклу запису. Та сама можливість доступна через DatasetRecorder.sync_to_bucket(bucket, run_id=...), якщо ви безпосередньо керуєте відкритим записувачем, а stop_recording(bucket=...) виконує синхронізацію в момент зупинки активного запису. Бакет є робочим рівнем, у який ви записуєте протягом дня; для версійованого опублікованого артефакту, як і раніше, викликайте push_to_hub(). Обидва варіанти зберігають той самий формат.

Епізод структурно завершений, але дії є заповнювачами, тому це не ті навчальні дані, які ви хотіли б використовувати. Для справжнього захоплення об’єктів замініть політику на реальну за допомогою create_policy("<hf_repo>"); запит, формат і синхронізація з бакетом залишаються незмінними.

Запис на апаратному забезпеченні

Для запису на фізичному SO-101 CLI запису LeRobot виконує підготовку пари leader-follower:

lerobot-record \
  --robot.type=so101_follower --robot.id=my_follower \
  --teleop.type=so101_leader  --teleop.id=my_leader \
  --dataset.repo_id=my_user/cube_picking \
  --dataset.single_task='Pick up the red cube'

Набір даних зберігається на диску в тому самому форматі, що й симуляційний запис, тому той самий виклик синхронізації передає його до бакета: sync_dataset_to_bucket("./recordings", "my-org/robot-fave", run_id="run-021") (або CLI-команда hf sync ./recordings hf://buckets/my-org/robot-fave/run-021, яку вона обгортає). Збір даних додає записи в одне місце, а версійовані репозиторії отримують лише ті версії, які ви вирішите опублікувати.

Крок 2 — Зберігання з дедуплікацією на рівні байтів

Тепер, коли набір даних опинився в бакеті, постає питання, скільки коштуватиме наступна синхронізація. Якщо спрямувати дві стаціонарні камери на маніпулятор, який протягом восьми годин очищує один і той самий стіл, більшість записаного — це вже наявні пікселі: те саме освітлення, те саме шасі, те саме тло в тисячах епізодів. У версійованому репозиторії ситуація ще гірша, оскільки зміна одного кадру у відеошарді на кілька гігабайтів призводить до повторного завантаження всього файлу.

Бакети працюють на основі Xet, який дедуплікує завантаження на рівні байтів за допомогою поділу на фрагменти, визначеного вмістом. Межі фрагментів залежать від вмісту, тому вставлення кількох байтів змінює лише фрагмент, у який вони потрапили, замість зміщення всіх наступних меж. За власними вимірюваннями Hugging Face (HF Storage), поділ на фрагменти, визначений вмістом, приблизно вчетверо зменшує обсяг переданих даних для кожного завантаження по всьому Hub, а в тарифах Enterprise оплата здійснюється за дедуплікований обсяг. Їхні тести бакетів показують, як це працює для одного файлу. Починаючи із завантаження розміром 500 МБ, повторне завантаження після зміни 1% байтів передало 5,5 МБ, після зміни 5% — 27,5 МБ, а після зміни 10% — 55 МБ. Без дедуплікації на рівні фрагментів перезапис об’єкта означає повторне надсилання всіх його байтів незалежно від того, чи змінилися вони.

Обсяг заощаджень залежить від структури файлів, а записувач Strands Robots використовує структуру LeRobot. Епізоди потрапляють у шарди Parquet (data/chunk-000/file-000.parquet) і MP4-шарди для кожної камери (videos/observation.images.front/chunk-000/file-000.mp4), переходячи до нового файлу лише після заповнення поточного; стандартні обмеження LeRobot становлять 100 МБ для Parquet із даними та 200 МБ для відео MP4. Тому синхронізація після дня запису завантажує нові кінцеві шарди та один частково заповнений шард, що збільшився, а не весь набір даних. Коли ви наступного дня знову синхронізуєте той самий бакет, Xet виконає дедуплікацію.

Рисунок 2. Синхронізація завантажує лише те, що змінилося. Під час першої синхронізації нового набору даних завантажується кожен фрагмент; після запису додаткових епізодів поділ Xet на фрагменти, визначений вмістом, означає, що наступна синхронізація завантажує лише нові фрагменти та пропускає ті, які вже зберігаються.

Крок 3 — Навчання потоково з Hub

Для навчання потрібно спрямувати графічні процесори на набір даних. Якщо спочатку завантажити його, графічні процесори простоюватимуть, доки не завершиться копіювання сотень гігабайтів. Потокове читання безпосередньо з Hub працює тут завдяки структурі шардів із кроку 2: одна партія перетворюється на кілька читань діапазонів байтів у великих шардах, а не на тисячі малих запитів. StreamingLeRobotDataset від LeRobot перетворює це на ітеративний об’єкт torch, готовий до використання, а Strands Robots надає до нього доступ через stream_dataset():

Рисунок 3. Потокове читання замість завантаження. Шлях завантаження спочатку копіює весь набір даних на локальний диск, тому графічний процесор очікує; stream_dataset() зчитує партії безпосередньо з бакета, не використовуючи локальний диск, тому графічний процесор навчається вже з першої партії.

reader = sim.stream_dataset("my-org/robot-fave/cube_pick", repo_type="bucket",
    shuffle=False, max_num_shards=1, buffer_size=1,  
)

print(reader.num_episodes, reader.num_frames, reader.fps)
for frame in reader:
    frame["observation.images.front"]   
    frame["observation.state"]           
    frame["action"]
    break

На локальний диск потрапляє лише невелика папка meta/ зі схемою, статистикою та індексом епізодів. Кадри з камер декодуються з віддалених MP4-шардів під час ітерації; стан і дії надходять із шард Parquet. Цикл зчитує по одному кадру, що зручно для перевірки епізоду. Для навчання передайте читач до DataLoader і перебирайте партії. Потоковий набір даних перемішує дані всередині через обмежений буфер-резервуар, тому декодування відео розпаралелюється між робочими процесами, а сам крок навчання є звичайним кроком PyTorch:

for batch in reader.dataloader(batch_size=64, num_workers=4):
    loss, _ = policy(batch)   
    loss.backward()

Якщо ви не хочете писати цикл самостійно, власний тренер LeRobot читає дані через той самий рушій, тому набір даних, зібраний агентом, можна навчати без жодного нового рядка коду. Бакет передається через той самий іменований аргумент, який використовує внутрішньопроцесний читач:

lerobot-train --policy.type=act \
  --dataset.repo_id=my-org/robot-fave/cube_pick \
  --dataset.repo_type=bucket \
  --dataset.streaming=true \
  --num_workers=4

Бакети доступні лише для потокового читання, тому --dataset.repo_type=bucket вимагає --dataset.streaming=true, а конфігурація в іншому разі відхиляє таке поєднання. Використовуйте stream_dataset(), коли хочете розмістити цикл у власному процесі: перевірити епізод, відтворити його в симуляції або передати до власного циклу оцінювання. Для потокового читання лише пропріоцептивних даних параметр drop_videos=True повністю пропускає декодування відео, завдяки чому це працює на периферійному пристрої без пакета torchcodec. У посібнику із запису та наборів даних описано цей аргумент, а також карту delta_timestamps, яку він потребує.

Назви провайдерів є спільними для запуску й навчання політики. create_trainer("lerobot_local") повертає Trainer, який працює подібно до create_policy(), а TrainSpec описує запуск; цикл запису, навчання й розгортання після цього замикається в кількох рядках:

import os
os.environ["STRANDS_TRUST_REMOTE_CODE"] = "1"   

from strands_robots import create_policy
from strands_robots.training import TrainSpec, create_trainer

trainer = create_trainer("lerobot_local", device="cuda")
spec = TrainSpec(dataset_root="/tmp/cube_pick", output_dir="/tmp/cube_pick_ft",
                 base_model="", steps=500, extra={"policy_type": "act"})
result = trainer.train(spec)                    
policy = create_policy(result.checkpoint_dir)   

На одному NVIDIA L4 (g6.4xlarge) 500 кроків оптимізатора ACT (51,6 млн параметрів, ефективний розмір партії 8) для епізоду зі 120 кадрів завершилися за 133 секунди та записали контрольну точку, яку create_policy() завантажує через ту саму точку входу, що використовується для запуску будь-якої іншої політики. Час навчання залежить від розміру набору даних, розміру партії та кількості кроків, тому сприймайте це як одну виміряну конфігурацію, а не як бенчмарк. Провайдери "groot" і "cosmos3" використовують той самий життєвий цикл TrainSpec і Trainer, тому навколишній цикл не змінюється; кожен спочатку перевіряє власні обов’язкові поля, тож для запуску GR00T потрібні base_model і тег embodiment, а для Cosmos 3 — base_model і рецепт SFT. Викличте trainer.validate(spec) перед train(), і він поверне точний список того, чого бракує конкретному бекенду.

Попереднє прогрівання Hugging Face кешує дані бакета в периферійних розташуваннях поблизу хмари та регіону, де працюють ваші завдання, тому кластер читає дані локально, а завантажувач даних випереджає графічний процесор. У власних тестах бакетів Hugging Face зафіксувала для теплого читання через мережу доставки контенту (CDN) близько 1 086 МБ/с для корисного навантаження 10 ГБ проти 780 МБ/с у холодному режимі та приблизно 1 124 МБ/с у теплому режимі для 100 ГБ; вимірювання проводилися на m5dn.24xlarge у us-east-1. Повне порівняння зі звичайним об’єктним сховищем — як для завантаження, так і для вивантаження — наведено на цій панелі. Вибір розташування цих даних є налаштуванням Storage Regions у тарифах Team і Enterprise; станом на момент написання доступні США та ЄС, а регіони Азійсько-Тихоокеанського регіону та Ради співробітництва арабських держав Перської затоки (GCC) оголошені як майбутні. У тарифах поза цими планами репозиторії зберігаються у США.

У macOS команда import strands_robots самостійно додає ffmpeg із Homebrew до шляху завантажувача, тому torchcodec декодує потокове відео без додаткового налаштування.

Крок 4 — Розгортання політики та повернення даних у цикл

На цьому етапі ви берете щойно навчену контрольну точку, запускаєте її на фізичному роботі та записуєте за її допомогою наступну серію демонстрацій. Це той самий код агента з першої публікації, у якому змінено один іменований аргумент на mode="real":

robot = Robot("so100", mode="real", port="/dev/ttyACM0",
              cameras={"front": {"type": "opencv", "index_or_path": "/dev/video0", "fps": 30}})
agent = Agent(tools=[robot])
agent("Pick up the red cube.")

Контрольна точка працює на фізичному маніпуляторі, а демонстрації, які він записує, зберігаються на диску в тому самому форматі LeRobot, з якого ви почали, і готові до синхронізації назад у бакет для наступного запуску навчання.

Якщо ваші дані вже зберігаються в Amazon Simple Storage Service (Amazon S3), форматні операції з цієї публікації не змінюються. LeRobotDataset — це каталог шард Parquet і MP4, тому в Amazon S3 він зберігається так само, як і будь-де, а етапи запису, навчання й розгортання працюють із цим форматом незалежно від місця його зберігання. Бакет додає маршрут, нативний для Hub: sync_dataset_to_bucket і stream_dataset(repo_type="bucket") безпосередньо працюють із hf://, тому ви отримуєте синхронізацію та потокове читання без підключення окремого сховища. Обидва шляхи виконують той самий цикл: Amazon S3, якщо ваші дані вже там, або бакет, якщо ви хочете синхронізацію й потокове читання без попереднього виділення сховища.

Запустіть цикл знову завтра — і ви записуватимете дані в цей бакет, синхронізуватимете лише змінені байти та передаватимете їх потоково на графічні процесори, не очікуючи завершення завантаження. Дані ніколи не залишають формат LeRobot і ніколи не залишають Hub.

Спробуйте за допомогою прикладної програми

Повний приклад Strands Robots доступний на GitHub у репозиторії strands-labs/robots, файл examples/notebooks/05_streaming_data_loop.ipynb. Він покроково проводить через увесь цикл у комірках: запис, візуалізацію, синхронізацію з бакетом, потокове читання назад, навчання та завантаження контрольної точки. Кожна комірка працює в симуляції з імітаційною політикою, тому не потрібні ні графічний процесор, ні Docker, ні облікові дані Hugging Face.

git clone https://github.com/strands-labs/robots.git
cd robots
uv pip install -U "strands-robots[sim-mujoco,lerobot]>=0.5.1"
jupyter notebook examples/notebooks/05_streaming_data_loop.ipynb

Запускайте комірки зверху вниз. Записаний набір даних зберігається в /tmp/nb5_dataset. Щоб синхронізувати його з бакетом, установіть BUCKET = "my-org/robot-fave" у першій комірці (після hf auth login); сусідній параметр RUN_ID задає назву папки всередині бакета, а ноутбук зчитує дані потоково з f"{BUCKET}/{RUN_ID}". Щоб навчати модель на графічному процесорі, збільште steps до 500 і встановіть device="cuda". Версія цього самого циклу під керуванням агента доступна за адресою examples/06_agent_collect_and_stream.py.

Міркування щодо безпеки

Наведені тут фрагменти коду — це «hello world» циклу даних Strands Robots. Після запуску з реальними даними змінюються п’ять речей.

• Ін’єкція в запит. Передавання агенту ненадійних даних може призвести до ін’єкції в запит, коли ненадійний контекст сприймається як інструкції LLM. Ці агенти керують роботами, а тепер також записують дані до спільного сховища та читають їх із нього, тому це важливий ризик, за яким потрібно стежити. Передавайте агенту лише дані з надійних джерел. Якщо не всім вхідним даним можна довіряти, обмежте доступні агенту інструменти, щоб він не міг виконувати критично важливі для безпеки дії або перезаписувати вміст бакета.

• Навчальні дані є межею довіри. Агент, який може записувати дані до бакета збору, також може записувати епізоди, на яких згодом навчатиметься політика, що керує фізичним маніпулятором. Розділіть облікові дані для запису даних збору та для читання навчальним завданням, синхронізуйте кожен запуск під власним run_id, щоб епізод можна було пов’язати із запуском, який його створив, і видалити окремо, а версійований репозиторій набору даних вважайте перевіреним артефактом, оскільки бакет не зберігає редакцій для аудиту.

• Облікові дані та область дії бакета. sync_dataset_to_bucket(...), stop_recording(bucket=...) і sync_to_bucket завантажують дані через CLI hf, використовуючи токен із hf auth login. Використовуйте токен, обмежений конкретним простором імен, у який ви записуєте, надавайте перевагу --private для бакетів зі збірними даними та тримайте бакет окремо від версійованого репозиторію набору даних, який ви передаєте через push_to_hub і яким ділитеся.

• Перезапис на місці не зберігає редакцій. Бакет перезаписується на місці й не зберігає редакцій, що робить його робочим рівнем, але також означає, що повторне використання run_id замінює вже збережений там запуск. Передавайте явний run_id для кожного запуску збору, як у sync_dataset_to_bucket("./recordings", "my-org/robot-fave", run_id="run-021"). Для всього, до чого потрібно мати можливість повернутися, використовуйте push_to_hub() у версійований репозиторій набору даних, де зберігається кожна редакція.

• Використовуйте лише надійні організації Hugging Face. Локальний шлях виведення завантажує моделі Hugging Face з trust_remote_code=True. Установіть STRANDS_TRUST_REMOTE_CODE=1, щоб погодитися на це, і завантажуйте контрольні точки лише від організацій, яким довіряєте. Під час завантаження попередньо навчених ваг із Hub (наприклад, через pretrained_name_or_path) переконайтеся, що організація є надійною. Ваги моделі можуть містити довільний код (контрольні точки на основі pickle). За можливості надавайте перевагу контрольним точкам у форматі safetensors.

Очищення

Після виконання циклу залишаються бакет, набори даних у /tmp і контрольна точка на диску. Вміст бакета враховується у вашому обсязі зберігання, тому видаліть те, що більше не потрібно:

hf buckets rm my-org/robot-fave/cube_pick/ --recursive --dry-run  # lists, removes nothing
hf buckets rm my-org/robot-fave/cube_pick/ --recursive            # --yes skips the prompt
hf buckets delete my-org/robot-fave                               # takes everything in it
rm -rf /tmp/cube_pick /tmp/cube_pick_ft /tmp/nb5_dataset /tmp/nb5_ft

Зупиніть усі процеси навчання, які ще працюють на екземплярі з графічним процесором, а потім зупиніть сам екземпляр. Якщо ви запускали ноутбук, підставте його RUN_ID (за замовчуванням nb5_demo) замість cube_pick. Усе, що ви опублікували через push_to_hub(), перебуває у версійованому репозиторії й не змінюється.

Що робити далі

У документації Strands Robots детально описано каталог роботів, симуляцію, провайдерів політик, запис і mesh. У посібнику із запису та наборів даних повністю описано API DatasetRecorder, sync_dataset_to_bucket / sync_to_bucket і stream_dataset.

Якщо ви збираєте дані з кількох роботів, надайте кожному власний run_id, і вони зможуть паралельно записувати в один бакет. Mesh для кількох роботів розподіляє одного агента між цими роботами, тож той самий цикл перетворюється на флот, який протягом дня збирає дані у спільне сховище. Потоковий читач зчитує один запуск за раз. У посібнику із запису та наборів даних описано, як навчати модель на кількох таких запусках.

Якщо вам потрібна політика більша за ACT, життєвий цикл TrainSpec і Trainer із кроку 3 охоплює GR00T і Cosmos 3 через власні назви провайдерів, тому донавчання VLA на щойно зчитаному потоково наборі даних виконується тими самими викликами, але з іншим рядком провайдера та базовою моделлю. Результати запускаються інакше, оскільки контрольна точка VLA розгортається на апаратному забезпеченні, а не в симуляторі, у якому ви навчали модель. Для масштабнішої симуляції, що генерує ці дані, бекенди Newton (sim-newton) та Isaac Sim (isaac) працюють через ту саму фабрику Robot(), тому код агента не змінюється під час масштабування.

Потокове читання бакетів потрапило до LeRobot завдяки внескам команд Strands Robots і LeRobot безпосередньо в сам LeRobot, тому набори даних, які збирає ваш агент, доступні для читання кожному інструменту цієї екосистеми. Це працює в обох напрямках: читач із кроку 3 відкриває будь-які набори даних LeRobot, уже опубліковані на Hub, тож агент може відтворювати й оцінювати наявні демонстрації, перш ніж записати власну.

Внески вітаються за ліцензією Apache 2.0. Якщо ви створите щось із цим циклом, відкрийте issue і розкажіть, що спрацювало, а що ні.

Ресурси

Strands Robots

• SDK, AgentTools і фабрика Robot(): github.com/strands-labs/robots, Apache 2.0
• Документація: strands-labs.github.io/robots
• Посібник із запису та наборів даних: strands-labs.github.io/robots/recording
• Ноутбук для цієї публікації: examples/notebooks/05_streaming_data_loop.ipynb<