Оптимизация моделей для мобильных: TFLite, квантизация, делегаты

Конвертация модели в TFLite: что ломается на выходе

Конвертация модели в TFLite — это не «сохранить в другом формате», а пересборка графа под мобильный инференс. Часть операторов не имеет эквивалента в рантайме, и вместо внятной ошибки вы получаете либо падение на конкретной модели устройства, либо тихую подмену ускоренного пути на медленный запасной.

Неподдерживаемые операции проявляются по-разному: конвертер сообщает о них прямо или выдаёт предупреждение и собирает модель, которая считается, но неверно. Кастомные слои, динамические размеры входов, операции над разреженными структурами приходится переписывать под поддерживаемый набор.

Отдельная история — квантизация. Целочисленное представление весов сжимает модель и ускоряет вывод, но без репрезентативного набора калибровки точность падает неравномерно: средняя метрика держится, а на редких классах деградация кратная. Падение точности поэтому ищут не по общей цифре, а по срезам данных.

Расхождение результатов на устройстве добавляют делегаты: аппаратные ускорители меняют порядок вычислений и округление, и вывод перестаёт совпадать с эталоном. Нужны тесты на паритет по каждому выходу и явные допуски, а не проверка одного демонстрационного примера.

Снаружи это выглядит как рост времени отклика у части пользователей и падения на конкретных устройствах: ускоренный путь откатывается на процессор, включается троттлинг, не хватает памяти. Дальше разбираем, как каждый из этих классов сбоев закрывается на этапе конвертации.

Что даёт оптимизация под конкретное устройство

Модель, обученная на серверных ускорителях, на телефоне ведёт себя иначе: отклик измеряется секундами, артефакт не влезает в разумный размер приложения, часть операций на бюджетных устройствах падает в отказ. Конвертация модели в TensorFlow Lite переводит граф в формат, исполняемый на устройстве, а оптимизация под конкретную платформу делает его пригодным для работы.

Квантизация в 8-битные целые — основной рычаг: веса и активации калибруются на реальных примерах, полноточными остаются только слои, где просадка качества заметна метрике. Объём занимаемой памяти сокращается в 3–4 раза, а прирост скорости выше на слабых процессорах — там, где он и нужен. Опубликованные сообществом замеры дают тот же порядок величин: артефакт — с сотен до десятков мегабайт, отклик — с секунд до десятых долей.

Выполнение слоёв на графическом или нейронном блоке ускоряет прогон, но одна неподдерживаемая операция возвращает участок графа на центральный процессор — отклик начинает прыгать. Поэтому состав операций проверяют заранее, а запасной путь тестируют на каждом целевом семействе устройств.

Вся обработка идёт локально: нет запросов к серверу, нет отказов из-за канала связи, данные не покидают устройство. Для медицины, финансов и промышленных сценариев это снимает большую часть вопросов о персональных данных.

Долю отказов считаем по слабому парку, а не по флагману: бюджетные модели, нагрев, нехватка памяти. До оптимизации неуспешные прогоны там доходят до 10–15%, после — единицы процентов при том же качестве ответа.

Сравнение режимов: квантизация, делегаты, сжатие

Режимы оптимизации не заменяют друг друга: квантизация меняет формат весов и активаций, делегаты перекладывают счёт на ускоритель устройства, усечение весов убирает избыточные связи в самой сети. Комбинировать их можно и часто нужно, но порядок важен — сначала усечение с дообучением, затем квантизация, а делегат выбирается на этапе сборки под конкретный парк устройств.

Ниже — варианты, между которыми реально выбирают при конвертации модели в TFLite, с ограничениями каждого.

Выбор подтверждаем замерами на целевом парке: время вывода, доля операторов на ускорителе и качество на отложенной выборке.

Порядок работ: аудит, схема, настройка, проверка

Порядок этапов не случаен: каждый следующий шаг опирается на замеры предыдущего. Если сразу включить квантизацию, не зафиксировав базовую линию, потеря точности обнаружится уже в продакшене — на устройствах пользователей, а не на стенде. Поэтому начинаем с аудита, а заканчиваем передачей, чтобы любое изменение можно было проверить и откатить.

1. Аудит текущего состояния. Разбираем архитектуру модели, входные и выходные тензоры, находим узкие места — предобработку кадров, постобработку, сам вывод. Фиксируем базовые метрики на целевом устройстве: время вывода, потребление памяти, поведение под длительной нагрузкой.
2. Схема конвейера сборки. Определяем, откуда берутся веса, как воспроизводится экспорт, где хранятся артефакты и их версии. После этого конвертация модели в TFLite становится повторяемой командой, а не ручной операцией на ноутбуке разработчика.
3. Настройка режима оптимизации. Подбираем тип квантизации — от весовой до полной целочисленной — и делегаты под конкретные ускорители. Выбор обосновываем замером: где выигрыш по скорости перекрывает потерю точности, а где нет.
4. Сборка и правки. Прогоняем модель через конвертер, заменяем несовместимые операторы, настраиваем параметры представления. Контролируем два числа: размер артефакта и качество на валидационной выборке.
5. Проверка на устройствах. Тестируем на реальном парке — разные поколения чипов, объём памяти, версии системы. Смотрим худший случай, а не средний: холодный старт, нагрев, нехватка памяти.
6. Передача работ. Отдаём настроенный конвейер, регламент выпуска новой версии, скрипты замеров и отчёт с числами до и после. Команда заказчика дальше повторяет цикл самостоятельно.

Артефакты проекта: конфигурации, схемы, регламенты

Мы передаём проект так, чтобы его можно было собрать и проверить без нас: воспроизводимая конвертация модели в TFLite — это не один скрипт, а набор файлов, по которым любой инженер получит тот же артефакт. Ниже — что именно остаётся у заказчика в репозитории и в документации.

• Конфигурации сборки — параметры конвертации (входные формы, тип квантизации, перечень операций с откатом на резервную реализацию) вынесены в файлы, а не хранятся в голове инженера.
• Схема конвейера: где обучаются веса, где выполняется конвертация, где прогоняются проверки на реальном устройстве и в какой момент артефакт публикуется.
• Правила версионирования — связка версии датасета, весов и сконвертированного артефакта, чтобы откат на любую предыдущую сборку был однозначным.
• Регламент проверок: тесты на расхождение выходов до и после квантизации, время вывода и потребление памяти на эталонном наборе устройств.
• Матрица ускорителей — какие задействованы, на каких моделях устройств и версиях системы проверены и как ведёт себя модель при их отсутствии.
• Документация: как собрать артефакт с нуля, как откатиться на прошлую версию и какие ограничения есть у текущей конфигурации.
• Отчёт сравнения — таблица по точности и времени вывода до и после сжатия на фиксированном наборе входных данных.

Кейс: как сократили размер модели и убрали задержки

Заказчик пришёл с моделью распознавания, которая уверенно работала на флагманских телефонах и разваливалась на остальном парке. Артефакт не помещался в бюджет памяти, часть операций уходила на медленный путь вычислений, и отклик на слабых аппаратах растягивался. Замеры до старта: у 9% устройств обработка кадра не укладывалась в отведённое окно, у 4% приложение падало на инициализации.

Что сделали

Собрали стенд из устройств разных поколений и зафиксировали базовые метрики по каждому — без этого оптимизация превращается в угадывание. Модель пересобрали в формат TensorFlow Lite с квантизацией, откалиброванной на реальных данных заказчика, а не на синтетике: веса привели к целочисленному виду, а участки, чувствительные к точности, оставили без изменений. Под каждый класс чипсетов подобрали аппаратный ускоритель, часть операторов вынесли в предобработку, тяжёлые ветви графа разделили на два прохода с промежуточным кэшем.

Что стало

Размер артефакта уменьшился вчетверо, время отклика на слабых устройствах — втрое. Доля аппаратов, не укладывающихся в окно обработки, упала с 9% до 0,6%, а падения на инициализации исчезли как класс отказов. Точность после сжатия просела в пределах одного процента — это подтверждает прогон на отложенной выборке перед каждым релизом.

Проверка идёт на парке из нескольких десятков моделей устройств: если новая сборка деградирует по задержке или памяти, она не доходит до публикации.

Чем делегат отличается от квантизации и что выбрать

Делегат и квантизация решают разные задачи, и путаница между ними приводит к тому, что ускорение ищут не там, где оно есть. Делегат — это способ исполнения: часть графа операций уходит с центрального процессора на графический ускоритель или нейромодуль устройства. Квантизация — это способ представления: веса и активации хранятся в целочисленном формате вместо плавающего, за счёт чего артефакт весит в разы меньше, а арифметика считается быстрее.

Отсюда и порядок применения. Квантизация выполняется на этапе конвертации модели в TFLite — это свойство готового файла, зафиксированное до сборки приложения. Делегат подключается на этапе запуска, в инициализации интерпретатора, и на содержимое файла не влияет. Поэтому сначала определяется целевая точность и формат весов, а уже потом подбирается исполнитель под этот формат.

Сочетаются они далеко не всегда автоматически. Не каждый делегат поддерживает весь набор целочисленных операций: неподдержанные узлы возвращаются на центральный процессор, граф рвётся на фрагменты, и пересылка промежуточных тензоров между ускорителем и процессором съедает выигрыш. Признак проблемы — ускорение меньше ожидаемого и рост энергопотребления на длинных сессиях.

Критерий выбора прост. Если ограничение — размер приложения и объём памяти, начинаем с квантизации. Если модель укладывается в память, но не держит задержку, пробуем делегат. Если на устройстве есть нейромодуль и нужна минимальная задержка, ставятся оба режима — но с контролем доли операций, реально ушедших на ускоритель, и расхождения выходов с эталонным результатом.

Сомнения по точности, размеру и совместимости

Инженерные сомнения вокруг конвертации модели в TensorFlow Lite почти всегда одни и те же: насколько просядет точность после квантизации, что делать с операциями, которых нет в рантайме, и как обновлять сеть, не выпуская новую сборку приложения. Ниже — прямые ответы по каждому пункту.

Что делать с неподдерживаемыми операциями?

Три пути: заменить узел на поддерживаемый аналог, собрать кастомный оператор или оставить сегмент на резервном исполнителе. Выбор — по тому, сколько времени вывода добавляет обход и насколько стабильно он работает на разных чипсетах.

Можно ли обновлять модель без выпуска приложения?

Да, если сеть и интерфейс разведены: веса лежат отдельным артефактом, приложение подтягивает актуальную версию и откатывается на предыдущую при деградации метрик. Новая сборка нужна только при смене структуры входов-выходов.

Как проверяете совместимость устройств?

Собираем матрицу целевых устройств и прогоняем сборку на каждом: разные чипсеты, ускорение через графический или нейронный блок, откат на резервный путь. Старт и поведение под нагрузкой показывают расхождения между устройствами лучше среднего замера.

Обсудим задачу: что нужно для старта работ

Чтобы оценка опиралась на факты, а не на предположения, нам достаточно нескольких вводных. Чем точнее описан сценарий, тем быстрее мы назовём этапы, сроки и риски.

• Постановка задачи — где работает модель: на устройстве пользователя или с обращением к серверу, кто пользователь и какой ответ считается верным.
• Исходные данные — что приходит на вход: кадры с камеры, изображения, аудио или текст. Достаточно 10-20 примеров реальных данных, включая сложные случаи.
• Текущий конвейер — на чём обучена модель, в каком формате сохранена, были ли попытки конвертации в TFLite и на каком шаге они останавливались.
• Список устройств — модели телефонов, ветки операционных систем, доля слабых аппаратов в аудитории: от этого зависят квантизация и делегаты.
• Метрики качества — что нельзя потерять: точность, полнота, задержка ответа, расход батареи. Замеры на текущей версии заметно ускоряют работу.
• Ограничения проекта — допустимый размер приложения, доступная память, требования к приватности, необходимость работы без сети.
• Сроки этапов — привязанные даты: запуск, показ заказчику, сезонный пик. Они задают порядок работ.

По этим вводным мы готовим оценку и план: разбивку по этапам, состав работ, точки проверки результата и риски. Опишите задачу в свободной форме — вернёмся с оценкой и планом, а недостающие данные вынесем отдельным этапом.