Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Модели, которые превращают изображения и команды в действия робота, удалось ускорить без изменения их архитектуры и расписания шумоподавления. Liang Su, David Chen, Jason Li, Kevin Guo и Teresa Lv представили FLASHRT-PAI; в нерецензированном препринте все числа получены самими авторами, а при одинаковой 16-битной точности система работает в 1,3–3,7 раза быстрее официальных скомпилированных вариантов.
Для разработки это переносит главную работу с отдельных вычислительных ядер на устройство всего конвейера: какие данные хранить между решениями, какие этапы объединять и когда запускать следующую операцию.
Быстрое ядро не устраняет ожидание между ядрами
Вычислительное ядро — короткая программа, которую GPU запускает как отдельную задачу. Модель управления роботом выполняет тысячи таких задач последовательно: умножает матрицы, нормализует значения, добавляет остаточные связи, меняет расположение данных и преобразует точность.
При пакете из одного запроса многие операции работают недолго. Поэтому заметную часть задержки создают не сами вычисления, а их запуск, запись промежуточного результата в память и последующее чтение. Даже быстрое умножение матриц не помогает, если перед ним GPU ждёт данные, а после него выгружает результат для следующей короткой операции.
Обычный компилятор графов объединяет известные последовательности операций и повторно запускает подготовленный граф. Но он рассматривает отдельный вызов модели и не знает прикладных правил: как долго действует команда роботу, когда меняется изображение с камеры и какие значения можно сохранить для следующего решения.
Это особенно заметно в моделях физического ИИ. Текстовая команда может оставаться прежней весь эпизод, наблюдение меняется при каждом решении, а этап шумоподавления повторяется несколько раз внутри одного решения. Если весь граф запускать одинаково, модель снова вычисляет значения, которые ещё не устарели.
Объединение операций дополняет повторное использование состояния
FLASHRT-PAI объединяет соседние операции глубже, чем стандартная компиляция. Например, нормализация, остаточная связь и преобразование точности могут выполняться внутри производителя данных, без отдельной записи промежуточного тензора. В одном слое декодера π0.5 такой подход сократил путь с 20 вычислительных ядер до 12.
Границы, которые нельзя убрать, система старается перекрыть. Следующее ядро может заранее загрузить веса и выполнить подготовительную работу, пока предыдущее ещё считает результат. Ждать приходится только в точке, где эти данные действительно потребуются.
Третий механизм отвечает за работу между решениями. Исполнительный контракт описывает этапы конвейера, их зависимости, частоту обновления входов и владельцев буферов. По нему система решает, нужно ли заново обрабатывать команду и наблюдение или достаточно повторить только этап генерации действия.
В π0.5 сохранение неизменных значений сократило задержку одного решения с 37,05 до 21,61 мс. Для состояния заданы правила обновления, поэтому ускорение не сводится к бесконтрольному кэшированию: при смене команды или кадра соответствующие области пересчитываются.
Состояние также можно сохранить, восстановить или разветвить копированием выделенных областей памяти GPU. Это подходит для нескольких продолжений одной сцены, отката симуляции или параллельной проверки вариантов действия без повторной подготовки общего контекста.
Новые проекты стоит проектировать вокруг жизненного цикла данных
Работа меняет планы команд, если модель выполняется с фиксированными формами, пакетом из одного запроса и многократно использует одну команду или историю. В таком случае границы этапов, срок жизни буферов и частота обновления входов стоит задавать вместе с архитектурой контура управления, а не оставлять на этап поздней оптимизации.
Для существующего проекта FLASHRT-PAI предлагает выборочную замену участков PyTorch. Перед включением система сравнивает результат с эталонной реализацией и проверяет задержку полного вызова. Если замена меняет выход или не ускоряет весь путь, приложение сохраняет прежний вариант.
Однако подключение нового сочетания модели и оборудования не происходит автоматически. Инженерам всё равно нужно выбрать этапы, форматы данных, точность, правила жизни буферов и места безопасного перекрытия запусков, а затем проверить поведение всей модели. Дополнительные преобразования и синхронизация на границе с приложением способны поглотить выигрыш отдельного ядра.
Проверка охватывает четыре политики на Jetson AGX Thor и шесть на RTX 5090. Поведение в замкнутом контуре оценивали для π0.5 и LingBot-VA в симуляции LIBERO; измерения относятся к прогретому выполнению на GPU семейства Blackwell, а не к полной задержке от датчика до привода физического робота.
Практический вывод — не отказываться от компиляторов, а дополнить их уровнем, который понимает состояние приложения. FLASHRT-PAI уже распространяется как открытый исходный код и через Hugging Face Kernel Hub, а необязательные ядра для π0.5 вошли в LeRobot. Для команды это подтверждает реализуемость подхода, но не отменяет отдельной настройки под собственную модель, GPU и контур управления.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
