Делегаты графического процессора для LiteRT

Использование графических процессоров (GPU) для запуска моделей машинного обучения (ML) может значительно повысить производительность вашей модели и удобство работы с приложениями с поддержкой ML. LiteRT позволяет использовать графические процессоры и другие специализированные процессоры с помощью аппаратного драйвера, называемого делегатами . Включение использования графических процессоров в приложениях LiteRT ML может дать следующие преимущества:

  • Скорость . Графические процессоры созданы для высокой пропускной способности при выполнении массово-параллельных рабочих нагрузок. Такая конструкция делает их хорошо подходящими для глубоких нейронных сетей, которые состоят из огромного количества операторов, каждый из которых работает с входными тензорами, которые могут обрабатываться параллельно, что обычно приводит к меньшей задержке. В лучшем случае запуск вашей модели на графическом процессоре может работать достаточно быстро, чтобы обеспечить работу приложений реального времени, что ранее было невозможно.
  • Энергоэффективность . Графические процессоры выполняют вычисления машинного обучения очень эффективно и оптимизированно, обычно потребляя меньше энергии и выделяя меньше тепла, чем та же задача, выполняемая на процессорах.

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

Поддержка операций машинного обучения на графическом процессоре

Существуют некоторые ограничения на то, какие операции TensorFlow ML или ops могут быть ускорены делегатом графического процессора LiteRT. Делегат поддерживает следующие операции с 16-битной и 32-битной точностью с плавающей запятой:

  • ADD
  • AVERAGE_POOL_2D
  • CONCATENATION
  • CONV_2D
  • DEPTHWISE_CONV_2D v1-2
  • EXP
  • FULLY_CONNECTED
  • LOGICAL_AND
  • LOGISTIC
  • LSTM v2 (Basic LSTM only)
  • MAX_POOL_2D
  • MAXIMUM
  • MINIMUM
  • MUL
  • PAD
  • PRELU
  • RELU
  • RELU6
  • RESHAPE
  • RESIZE_BILINEAR v1-3
  • SOFTMAX
  • STRIDED_SLICE
  • SUB
  • TRANSPOSE_CONV

По умолчанию все операции поддерживаются только в версии 1. Включение поддержки квантования включает соответствующие версии, например ADD v2.

Устранение неполадок поддержки графического процессора

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

WARNING: op code #42 cannot be handled by this delegate.

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

Примеры моделей

Следующие примеры моделей созданы для использования преимуществ ускорения графического процессора с помощью LiteRT и предоставляются для справки и тестирования:

Оптимизация для графических процессоров

Следующие методы могут помочь вам повысить производительность при запуске моделей на оборудовании графического процессора с использованием делегата графического процессора LiteRT:

  • Операции изменения формы . Некоторые операции, которые выполняются быстро на процессоре, могут иметь высокие затраты на графический процессор на мобильных устройствах. Операции изменения формы особенно дороги в выполнении, включая BATCH_TO_SPACE , SPACE_TO_BATCH , SPACE_TO_DEPTH и т. д. Вам следует внимательно изучить использование операций изменения формы и принять во внимание, что они могли применяться только для изучения данных или для ранних итераций вашей модели. Их удаление может значительно улучшить производительность.

  • Каналы данных изображения . На графическом процессоре тензорные данные разбиваются на 4 канала, поэтому вычисление тензора формы [B,H,W,5] выполняется примерно так же, как и тензора формы [B,H,W,8] , но значительно хуже, чем [B,H,W,4] . Если используемое вами оборудование камеры поддерживает кадры изображения в формате RGBA, подача этого 4-канального входа происходит значительно быстрее, поскольку позволяет избежать копирования памяти из 3-канального RGB в 4-канальный RGBX.

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

Расширенная поддержка графического процессора

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

Использование квантованных моделей

В этом разделе объясняется, как делегат графического процессора ускоряет 8-битные квантованные модели, включая следующие:

Чтобы оптимизировать производительность, используйте модели, которые имеют как входные, так и выходные тензоры с плавающей запятой.

Как это работает?

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

  • Тензоры констант (такие как веса/смещения) один раз деквантуются в память графического процессора. Эта операция происходит, когда делегат включен для LiteRT.

  • Входные и выходные данные программы графического процессора, если они 8-битные, подвергаются деквантованию и квантованию (соответственно) для каждого вывода. Эта операция выполняется на ЦП с использованием оптимизированных ядер LiteRT.

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

Информацию о включении этой функции с помощью делегата графического процессора см. в следующем:

Сокращение времени инициализации за счет сериализации

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

С++ 

    TfLiteGpuDelegateOptionsV2 options = TfLiteGpuDelegateOptionsV2Default();
    options.experimental_flags |= TFLITE_GPU_EXPERIMENTAL_FLAGS_ENABLE_SERIALIZATION;
    options.serialization_dir = kTmpDir;
    options.model_token = kModelToken;

    auto* delegate = TfLiteGpuDelegateV2Create(options);
    if (interpreter->ModifyGraphWithDelegate(delegate) != kTfLiteOk) return false;

Ява 

    GpuDelegate delegate = new GpuDelegate(
      new GpuDelegate.Options().setSerializationParams(
        /* serializationDir= */ serializationDir,
        /* modelToken= */ modelToken));

    Interpreter.Options options = (new Interpreter.Options()).addDelegate(delegate);

При использовании функции сериализации убедитесь, что ваш код соответствует следующим правилам реализации:

  • Сохраните данные сериализации в каталоге, недоступном для других приложений. На устройствах Android используйте getCodeCacheDir() , который указывает на местоположение, частное для текущего приложения.
  • Токен модели должен быть уникальным для устройства конкретной модели. Вы можете вычислить токен модели, создав отпечаток пальца на основе данных модели с помощью таких библиотек, как farmhash::Fingerprint64 .