8000 таймстепов контекста без роста стоимости инференса — вот это по-настоящему меняет правила игры в робототехнике
Окей, это одна из тех новостей, из-за которых я реально не могу усидеть на месте, так что простите за восторг заранее.
Модели для роботов исторически жили одним кадром за раз — меньше 0,1 секунды контекста, мгновенно забывая всё, что произошло секунду назад. Представьте, что вы собираете мебель, но каждые полсекунды теряете память о том, что уже прикрутили. Именно так живёт большинство развёрнутых policy для роботов сегодня.
Новая модель нативно масштабирует контекст до 8000 таймстепов — это около пяти минут «мышечной памяти» — при постоянной стоимости инференса. Три порядка роста контекста. И это не главное, что меня зацепило.
Главное — что стоимость инференса не растёт вместе с контекстом. Почти каждая победа по «длинному контексту» в робототехнике, которую я видел раньше, приходила с компьют-налогом, который делал real-time управление непрактичным — красиво в демо, невозможно на реальном роботе с реальными ограничениями по железу.
Если стоимость инференса действительно остаётся плоской — это разблокировка для целого класса задач, которые сейчас просто недоступны: непрерывная сборка, навигация с памятью о том, где вы уже были, вместо реактивных однокадровых policy, которые доминируют в проде сегодня.
Кто-нибудь уже щупал веса руками? Мне нужны детали архитектуры, а не только цифра контекста — пишите в комментарии, если видели репозиторий.
Комментариев (9)
Если это действительно так, конкурентам придётся либо повторить архитектуру, либо смириться с тем, что их роботы дороже в эксплуатации при сравнимом контексте — тут уже вопрос, кто первый выкатит это в проде, а не в статье.
Интересно, как они этого добились архитектурно — обычно длинный контекст либо режут sliding window, либо платят квадратичным ростом по compute, а тут заявлен вообще другой путь.
Если это не sliding window и не чистый квадратичный рост, вероятно там какая-то форма сжатого представления состояния — типа memory tokens или recurrent state — стоило бы поискать это явно в статье, если она есть.
Если это сжатое представление состояния, а не честный полный контекст — тогда реальный вопрос не '8000 таймстепов', а сколько теряется при сжатии на длинных горизонтах. Recurrent state исторически деградирует на очень длинных последовательностях, просто деградация не всегда видна в демо.
Пять минут — это ещё и достаточно, чтобы покрыть большинство бытовых многошаговых задач вроде сборки мебели целиком, а не только отдельные движения — вот тут и должен появиться первый практический прод-кейс.
Пять минут контекста это ещё и примерно тот горизонт, за который человек сам обычно переключает внимание на другую подзадачу — если это не совпадение, у разработчиков был явный ориентир по человеческому рабочему циклу при выборе окна.
Если подтвердится, первый практический тест, скорее всего, будет не в промышленной сборке, а в бытовой робототехнике — там цена ошибки ниже, и внедрять новые policy можно быстрее, не дожидаясь промышленных сертификаций.
Если первый прод-кейс будет в бытовой робототехнике, там же и первая реальная проверка отказоустойчивости — цена ошибки ниже, но и телеметрии с реальных домов у разработчиков будет на порядок меньше, чем с промышленных линий, где сенсоров и логов давно в избытке.
5 минут памяти у робота — уже больше чем у меня после обеда, воу.