Редакция Comrad404
Microsoft Research 23 сентября 2026 года представила исследование инфраструктуры инференса для физического ИИ. Команда сравнила выполнение робототехнических моделей на бортовых ускорителях, периферийных серверах и облачных GPU. По результатам испытаний, перенос части вычислений за пределы робота в некоторых сценариях улучшал скорость реакции и качество выполнения задач, одновременно снижая расход энергии на борту.
Работа охватывает мобильную робототехнику, где одной системе приходится строить карту пространства, планировать маршрут, распознавать препятствия и управлять манипуляторами. В качестве характерного сценария исследователи использовали составную команду: найти мусор на кухне, подобрать его и отнести в контейнер.
Результаты и заявления о преимуществах опубликованы самой Microsoft Research, поэтому их пока следует рассматривать как данные разработчика, а не как независимо воспроизведённый тест. Подробности исследования доступны в материале Microsoft Research.
Бортовые GPU стали ограничением для крупных моделей
Большинство современных робототехнических систем выполняют критическую часть инференса непосредственно на роботе. Такая архитектура уменьшает зависимость от сети, но заставляет разработчиков учитывать массу ускорителя, его стоимость, энергопотребление, охлаждение и доступный объём памяти.
Microsoft проверила, как эти ограничения влияют на три группы задач: семантическое картирование и планирование, навигацию, а также управление манипуляторами. Для сравнения использовались бортовые, периферийные и облачные конфигурации, включая системы с NVIDIA Jetson Thor и GPU класса A100.
По данным исследователей, отдельные компактные ускорители не смогли разместить в памяти весь программный стек мобильной манипуляции. На GPU с достаточным объёмом памяти картирование и планирование в некоторых конфигурациях выполнялись до 383% медленнее, чем на A100. Это особенно заметно в меняющейся среде, где робот должен регулярно обновлять карту и корректировать маршрут.
При использовании менее производительных ускорителей показатель своевременного обнаружения препятствий в навигационных тестах снижался на 30%. Модели класса VLA, связывающие визуальное восприятие, язык и действия, замедлялись не столь резко, однако зафиксированного отставания оказалось достаточно, чтобы точность в испытаниях упала на 50%.
Эти числа нельзя автоматически переносить на любой робот или модель. Результат зависит от архитектуры нейросети, разрешения и частоты сенсорных потоков, используемого ускорителя, программного стека и характера задачи.
Экономия батареи сопровождается зависимостью от сети
Во второй части эксперимента исследователи заменили бортовой GPU на Raspberry Pi 5, оставив компактной плате сбор и передачу данных, а инференс перенесли на внешний ускоритель. Microsoft сообщает, что такой подход увеличивал продолжительность автономной работы на несколько часов.
Для конфигураций с крупными бортовыми GPU, включая Jetson Thor, авторы указывают прирост времени работы от батареи до 160% после выноса вычислений. Формулировка описывает верхнюю границу в испытанных конфигурациях, а не гарантированный результат для всех платформ.
Экономия достигается не бесплатно. Роботу всё равно нужно получать данные от камер и других сенсоров, подготавливать их к передаче и принимать результаты модели. Архитектура становится чувствительной к четырём параметрам:
— полной задержке от получения сенсорного сигнала до выполнения команды;
— пропускной способности и стабильности соединения;
— доступности внешнего GPU;
— поведению системы при потере связи.
Для построения карты или долгосрочного планирования кратковременная задержка может оказаться допустимой. Для управления движением и предотвращения столкновений последствия сетевого сбоя существенно серьёзнее. Поэтому исследование не означает, что всю логику робота следует переносить в облако. Контуры экстренной остановки, базовое управление и безопасное завершение действия по-прежнему разумно оставлять локально.
Physical AI Toolchain распределяет вычисления между роботом, edge и облаком
Одновременно Microsoft расширила Physical AI Toolchain — открытый набор инструментов для разработки и эксплуатации систем физического ИИ. Компания называет новую функцию первым отраслевым решением такого рода для выноса робототехнического инференса.
Инструментарий использует Kubernetes как единый слой управления вычислительными задачами. Модель или другой компонент можно упаковать в контейнер и разместить на доступном GPU: непосредственно на роботе, на локальном периферийном сервере либо в облачной инфраструктуре.
Задача такого слоя — не просто отправить запрос на удалённый сервер, а управлять размещением и переносом компонентов робототехнического стека по заданным правилам. Microsoft также заявляет об интеграции с симуляторами, платформой ROS 2 и проектом LeRobot.
В опубликованной версии приведены примеры для учебного манипулятора SO-101 и промышленной руки UR10e. В одной из демонстраций модель Rho от Microsoft управляет действиями Mobile Aloha, а её инференс выполняется на внешнем Jetson Thor.
Хотя Microsoft описывает Physical AI Toolchain как готовую к производственному использованию систему, публикация не заменяет проверку на конкретном оборудовании. Из представленных материалов нельзя сделать вывод, что автоматическое распределение нагрузки одинаково эффективно для всех моделей и сетевых условий.
Что разработчикам стоит проверить до переноса инференса
Главный практический результат исследования — возможность рассматривать вычислительную инфраструктуру робота как распределённую систему, а не как один встроенный компьютер. Такой подход может позволить установить на мобильную платформу более лёгкий контроллер, а дорогие GPU разделить между несколькими роботами.
Перед выбором архитектуры команде потребуется измерить задержку всей цепочки, а не только время работы модели. В тест следует включить получение кадра, предварительную обработку, передачу данных, очередь на внешнем GPU, инференс, обратную передачу результата и выполнение команды.
Отдельно стоит проверить систему при ухудшении связи: росте задержки, потере пакетов, переключении между точками доступа и полной недоступности сервера. Робот должен сохранять безопасное состояние без ответа удалённой модели.
Для камер и других сенсоров необходимо оценить реальный объём трафика после кодирования. Сжатие снижает требования к каналу, но может ухудшить качество входных данных или увеличить нагрузку на бортовой процессор. Если сенсорные данные покидают локальную сеть, к технической оценке добавляются требования к шифрованию, аутентификации, хранению и разграничению доступа.
Наконец, экономию на бортовом GPU нужно сравнивать с полной стоимостью внешней инфраструктуры. Локальный сервер требует закупки и обслуживания, облачный инференс создаёт постоянные расходы, а резервирование увеличивает бюджет обоих вариантов.
Исследование Microsoft показывает перспективность выноса ресурсоёмких моделей, но не устанавливает универсальную архитектуру для физического ИИ. Практическая проверка должна сопоставить как минимум три режима — полностью локальный, периферийный и облачный — на одной модели, одинаковом наборе задач и в условиях нестабильной сети.