Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
EdgeCraft научилась превращать описание задачи и набор данных в готовый пакет модели для заданного периферийного устройства. В препринте, который не проходил рецензирование и приводит замеры самих авторов, система нашла вариант под заданные ограничения в 45 из 50 публичных задач. Такой подход переносит LLM из роли генератора кода в конвейер, где окончательное решение принимают по физическим замерам.
Систему разработала команда The Chinese University of Hong Kong и Peking University. Она предлагает рассматривать сборку периферийных моделей как сервис: на вход поступают задача, данные, целевое устройство, бюджет поиска и целевые уровни сервиса (SLO) по качеству, задержке и энергии.
Поиск идёт от измеренного нарушения к следующей версии
Обычный агент может написать корректную программу, которая не соберётся для нужной среды выполнения или не запустится на устройстве. Даже рабочая модель может превысить допустимую задержку либо расход энергии. Поэтому EdgeCraft разделяет предложение и принятие решения: LLM придумывает варианты, а результаты проверок определяют, какие из них можно развивать или отбросить.
Система хранит поиск в виде дерева. Каждый узел содержит программу модели, историю её происхождения и результаты проверок. Вместо общего запроса «сделай лучше» LLM получает конкретные разрывы: например, качество уже достаточно, но задержка выше порога, или модель укладывается в энергобюджет, однако уступает по точности.
Эти разрывы направляют следующую правку. Система может заменить представление данных, семейство модели, схему обучения, способ экспорта или среду выполнения. Она сохраняет альтернативные ветви, поэтому не обязана последовательно переписывать один вариант и терять ранее найденные компромиссы.
Если подходящего результата нет в пределах бюджета, EdgeCraft возвращает лучший проверенный вариант и показывает, какие требования тот нарушает. Это не гарантирует глобально лучшую архитектуру, но даёт воспроизводимый результат для реально изученной части пространства.
Дешёвые проверки направляют поиск, полная проверка принимает модель
Обучать, экспортировать и запускать на устройстве каждый вариант слишком дорого. EdgeCraft сначала применяет статические проверки, затем выполняет сокращённые замеры и только после этого запускает полное обучение и проверку на целевом оборудовании.
Ранние результаты служат подсказками, а не доказательством пригодности. Приближённый замер может повысить приоритет ветви, но система принимает итоговый пакет только после полного запуска, функциональной проверки и измерения физических характеристик. Если быстрая проверка не даёт уверенного ответа, кандидат переходит на полный этап.
Подтверждённые сбои система превращает в правила, привязанные к сочетанию устройства и среды выполнения. Следующие задания могут сразу отсеять вариант с уже воспроизведённой несовместимостью, не занимая оборудование повторным запуском. Обучение в облаке и проверки на устройствах идут параллельно, а рабочие пространства разных запросов остаются изолированными.
На публичном наборе EdgeCraft превысила качество выбранного для каждой задачи варианта Reference в 40 случаях. По сравнению с агентными подходами система нашла пригодные пакеты для в 2,4 раза большего числа задач, а многоуровневая проверка сократила затраченное на верификацию время на 25,7%, не изменив выбранную модель и её качество.
Проверка охватывала шесть типов данных, несколько устройств и сред выполнения. Отдельно авторы использовали собственный набор SEN с данными носимых датчиков и запускали итоговые модели на Raspberry Pi 5. Такой масштаб показывает переносимость конвейера между классами задач, но не доказывает, что он одинаково работает на любом микроконтроллере или закрытом ускорителе.
Что меняется в планах команд
EdgeCraft не отменяет выбор оборудования и постановку требований. Команде всё равно нужно определить метрику качества, допустимую задержку, энергобюджет и целевую платформу. Сбор данных, разметка и формулировка самой задачи также остаются за пределами конвейера.
Работа меняет архитектуру внутренней платформы для edge ML. Если команда планировала дать LLM доступ к репозиторию и ждать готовый код, стоит добавить отдельный контур проверок: сборку под нужную среду, запуск на физическом устройстве, функциональные тесты и измерение задержки и энергии. История проверенных несовместимостей при этом становится общим активом платформы, а не журналом одного эксперимента.
Сильнее всего подход подходит задачам, где можно менять представление данных, компактную архитектуру и среду выполнения без критической потери качества. Когда результат зависит от крупной специализированной модели, жёсткие физические ограничения быстро сужают пространство решений. В эксперименте при порогах на уровне одной десятой от исходных пригодными остались примерно половина задач.
Поэтому EdgeCraft пока разумнее воспринимать не как замену инженера, а как схему автоматизации: LLM исследует открытое пространство программ, измерения ограничивают её свободу, а полный тест на устройстве служит условием выпуска. Для собственной реализации важнее именно это разделение полномочий, а не конкретный агент или модель.
Источники
Иллюстрация: рисунок из статьи «EdgeCraft: Automated Model Crafting for Edge IoT», Genglin Wang, Kaiwei Liu, Liekang Zeng и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
