Домашний робот стоит у полки, рядом лежит роутер с погасшим индикатором. Сеть пропала, а рука всё равно тянется к предмету. Такую сцену пока рано считать документальным отчётом об испытаниях — это иллюстрация принципа. Смысл локального ИИ в том, что часть реакции робота может происходить рядом с датчиками и моторами, не дожидаясь ответа из далёкого центра. Вопрос в том, что именно Google переносит в машину, а что по-прежнему остаётся в облаке.
Сразу оговорюсь: речь не о роботе, который стал полностью независимым. Речь о слое, который отвечает за быстрое действие. Google DeepMind называет свою локальную модель Gemini Robotics On-Device 2 наиболее эффективной vision-language-action-моделью, оптимизированной для работы непосредственно на роботизированном устройстве. Но это не отменяет ни обучение, ни сложное планирование, ни облачную инфраструктуру целиком.
Почему роботу мешает сетевая задержка
Для человека короткая пауза в разговоре почти незаметна. Для робота, который берёт чашку, вставляет деталь или поправляет предмет на полке, такая задержка может быть разницей между точным движением и промахом. Физическое действие состоит из множества мелких коррекций: чуть повернуть кисть, ослабить усилие, остановиться перед препятствием. Если каждая такая поправка должна слетать на сервер и возвращаться обратно, робот начинает работать с задержкой, которая для механики ощущается как неуклюжесть.
Google прямо указывает, что многие роботы должны работать без сетевой задержки или без интернет-соединения. Именно под это ограничение и создавалась Gemini Robotics On-Device 2. Облако удобно для тяжёлых вычислений, обучения и многошаговых рассуждений, но непрерывное управление моторами — плохая задача для сети. Здесь важнее не «умность» модели в общем смысле, а скорость реакции на конкретную сцену перед камерой.
На мой взгляд, это самая понятная часть истории. Она объясняет, почему локальный ИИ вообще понадобился: не ради красивого слова «автономность», а потому что робот с задержкой хуже справляется с обычными физическими задачами. Если человеку перед каждым движением приходилось бы ждать ответа из другого города, простая задача с чашкой превратилась бы в испытание.
Что такое Gemini Robotics On-Device 2
Это отдельная облегчённая vision-language-action-модель, а не просто «Gemini, которого поставили в робота». На вход она получает изображения, текстовую инструкцию и проприоцепцию — числовые данные о состоянии частей робота. На выходе у неё не текстовый ответ, а числовые действия для управления механикой. Именно поэтому такие модели называют VLA: зрение, язык и действие здесь связаны в один контур.
Разница с чат-ботом здесь принципиальная. Чат-бот может красиво объяснить, как взять предмет, но не двинет рукой. Локальная VLA-модель смотрит на сцену, понимает задачу и превращает её в команды для моторов. Это уже не разговор об интеллекте в чистом виде, а инженерная работа на стыке восприятия и движения.
При этом важно не смешивать компоненты. Gemini Robotics 2 — более мощная VLA-модель для управления разными типами роботов. Gemini Robotics ER 2 отвечает за embodied reasoning: понимание физической сцены и многошаговое планирование. Gemini Robotics On-Device 2 — облегчённый вариант VLA-модели для локального запуска. Это разные части системы, и подмена одной другой меняет смысл всей истории.
И ещё одна оговорка. На момент публикации материалов Google модель доступна ограниченной группе доверенных тестировщиков. Это не массовый продукт, который можно поставить на домашнего робота и забыть. Перед нами инженерная платформа, которую проверяют в контролируемых условиях.
Что остаётся в облаке
Локальный вывод не равен локальному обучению. В карточке модели указано, что её обучали с использованием TPU, а сама модель предназначена для локального вывода, а не для полного автономного обучения на роботе. Проще говоря, робот может быстрее действовать на месте, но это не значит, что он сам себя переучивает между задачами.
Адаптация к новым платформам тоже не выглядит как волшебство. Google заявляет, что Gemini Robotics On-Device 2 может адаптироваться к новым роботизированным платформам менее чем на 200 примерах, а на странице модели говорится о возможности адаптации за несколько часов обучения. Это сильное заявление, но оно не означает, что новый робот сразу получает универсальные навыки после установки модели. Нужны данные, конструкция, сенсоры и приводы, которые вообще позволяют выполнить задачу.
С планированием — та же история. Сложное многошаговое рассуждение и часть функций могут оставаться за пределами устройства. Локальная модель снижает зависимость от сети для части задач управления, но не превращает робота в полностью офлайн-систему. Если отключить интернет, никто не гарантирует, что сохранятся все функции, удалённое управление, обновления и обучение.
С приватностью всё не так однозначно. Локальная обработка может уменьшить передачу сенсорных данных в облако и снизить зависимость от облачной обработки. Но в материалах Google нет универсальной гарантии, что все данные конкретной роботизированной системы никогда не покидают устройство. Это инженерная возможность, а не обещание полной конфиденциальности.
На чём Google это проверяла
В 2025 году Google сообщала, что более ранняя On-Device-модель первоначально обучалась на роботах ALOHA, а затем адаптировалась к двурукому роботу Franka FR3 и гуманоидному Apollo от Apptronik. В тестах демонстрировались складывание одежды, сборочные операции и работа с ранее не встречавшимися объектами. Все эти демонстрации относятся к более ранней версии, а не к Gemini Robotics On-Device 2.
Среди задач встречаются расстёгивание сумки, работа с Ziplock-пакетом, точный захват и вставка деталей. В таких сценах важны зрение, координация и точность, а не универсальное понимание мира. Лабораторный стол с аккуратно разложенными предметами — не то же самое, что захламлённая прихожая, где роботу нужно обойти кота, рюкзак и внезапно переставленный стул. Поэтому демонстрации стоит читать как проверку подхода, а не как обещание бытового продукта.
Цифры без магии
В опубликованном Google сравнении более ранняя On-Device-модель показывала показатели обобщения примерно от 0,52 до 0,74 по трём группам тестов. Облачная Gemini Robotics была выше — примерно от 0,60 до 0,75, тогда как предыдущее лучшее локальное решение показывало около 0,11–0,36. Это сравнение относится к ранней версии, а не к Gemini Robotics On-Device 2. Здесь важны обе части: локальный вариант заметно превзошёл прежние локальные решения, но всё ещё уступал облачному. Это не поражение и не триумф, а обмен скорости на часть возможностей.
Для SO101 в карточке модели указано улучшение успеха примерно с 6,7% до 53,3%, а для Dexmate — с 24,4% до 75,6% по мере увеличения времени адаптации. Эти цифры относятся к конкретному протоколу и конкретным платформам. Их нельзя читать как «надёжность робота вообще»: слишком многое зависит от задачи, конструкции и того, сколько времени ему дали на адаптацию.
Отдельно стоит пример из презентации Gemini Robotics 2: для Apollo с руками Inspire приводится средний результат 76,3% в задаче pick up from shelf. Это уже другая модель, не On-Device 2, и другой контекст. Упоминать его полезно, чтобы показать общий уровень лабораторных результатов Google, но смешивать с локальной моделью нельзя.
Где здесь реальная польза
Склады, производство и опасные среды — первый очевидный адрес. Там потеря связи или задержка могут быть критичны, а робот работает не в идеальном офисе с мощным Wi-Fi. Подвалы, стройки, удалённые площадки и цеха с плотной металлической конструкцией — места, где локальная обработка части задач выглядит не модной фишкой, а практической необходимостью.
Второй аргумент — приватность. Если изображения и сенсорные данные не нужно постоянно гонять через облако, система может меньше зависеть от внешней инфраструктуры. Но, повторюсь, это возможность, а не автоматическая гарантия. Третий аргумент — стоимость связи и устойчивость к перебоям. Роботу, который выполняет повторяющуюся операцию, не обязательно каждый раз спрашивать далёкий сервер, как ему двигать кистью.
По-моему, самое интересное здесь даже не в отдельных процентах, а в направлении. Google переносит в машину не весь интеллект, а тот его слой, который отвечает за быстрое действие. Это похоже на то, как человек не обдумывает каждое движение пальцев, а уже потом объясняет, что именно сделал. Локальная модель — это такая же попытка разгрузить «рефлексы» робота от далёкой сети.
Если хочется не читать про десяток отдельных нейросервисов, а попробовать их самому, удобнее использовать сервис, где собрано много нейроинструментов в одном месте. Для таких задач есть Syntx AI: https://syntx.ai/welcome/0NIuivsM. Это не заменяет инженерную проверку робота, но даёт общее представление о том, какие инструменты сейчас доступны.
Чего в этой истории пока нет
Нет массового домашнего робота, который после отключения роутера гарантированно делает всё по дому. Нет полного офлайн-обучения на устройстве. Нет универсального управления любым роботом: адаптация зависит от конструкции, сенсоров, приводов и числа степеней свободы. Нет и гарантии приватности по умолчанию — локальная обработка лишь может уменьшить передачу данных.
Сама формулировка «ИИ без облака» звучит сильнее, чем реальность. Точнее было бы сказать «часть ИИ без облака» или «быстрая реакция без обязательного обращения к сети». Google действительно делает шаг в эту сторону, но оставляет за скобками обучение, сложное планирование и инфраструктуру. Робот не остался без интернета насовсем; он получил возможность не ждать интернет там, где нужно действовать быстро.
Вернусь к сцене с погасшим роутером. Её смысл не в том, что робот стал независимым, а в том, что часть его реакции перестала ждать далёкий сервер. Для физического действия это уже много: меньше задержки, меньше зависимости от канала связи, меньше необходимости отправлять каждый кадр в облако. Но пока это инженерная база и тесты на конкретных платформах, а не бытовая революция. На мой взгляд, именно в такой формулировке история и остаётся честной: Google переносит в машину слой быстрого действия, а не всего робота целиком.
