Delegados da LiteRT

Os delegados permitem a aceleração de hardware de modelos LiteRT: usando aceleradores no dispositivo, como a GPU e o processador de sinal digital (DSP).

Por padrão, a LiteRT utiliza kernels de CPU otimizados para o ARM Neon (link em inglês) conjunto de instruções. No entanto, a CPU é um processador multifuncional que não é é necessariamente otimizada para a aritmética pesada, normalmente encontrada em machine learning Modelos de aprendizado (por exemplo, o cálculo matricial envolvida em convolução e densa camadas).

Por outro lado, a maioria dos celulares modernos contém chips que são melhores em e lidando com essas operações pesadas. Como usá-los em operações de rede neural oferece grandes benefícios em termos de latência e eficiência energética. Por exemplo: As GPUs podem fornecer uma velocidade de até 5x acelerar em latência.

Cada um deles tem APIs associadas que permitem cálculos personalizados, como OpenCL ou OpenGL ES para GPU de dispositivos móveis. Normalmente, você teria escrever códigos personalizados para executar uma rede neural por meio dessas interfaces. As coisas ficam ainda mais complicadas quando você considera que cada acelerador tem seus próprios prós e contras e não pode executar todas as operações em uma rede neural. TensorFlow A API Delegate do Lite resolve esse problema agindo como uma ponte entre o TFLite e essas APIs de nível inferior.

ambiente de execução com delegados

Como escolher um delegado

A LiteRT oferece suporte a vários delegados, cada um otimizado para algumas plataformas e tipos específicos de modelos. Normalmente, haverá vários delegados aplicáveis ao seu caso de uso, dependendo de dois critérios principais: a plataforma (Android ou iOS?) que você segmenta e o tipo de modelo; (ponto flutuante ou quantizado?) que você está tentando acelerar.

Delegados por plataforma

Multiplataforma (Android e iOS)

  • Delegado de GPU: pode ser usado no Android e no iOS. Ela é otimizado para executar modelos flutuantes de 32 e 16 bits nos quais uma GPU disponíveis. Ele também oferece suporte a modelos quantizados de 8 bits e fornece GPU e desempenho no mesmo nível do que as versões flutuantes. Para mais detalhes sobre a GPU delegado, consulte LiteRT na GPU (em inglês).

iOS

  • Delegado do Core ML para iPhones e iPads mais recentes: para iPhones e iPads mais recentes. iPads em que o Neural Engine estiver disponível, use o delegado do Core ML para acelera a inferência para modelos de ponto flutuante de 32 ou 16 bits. Neural Engine está disponível em dispositivos móveis Apple com SoC A12 ou superior. Para um informações gerais do delegado do Core ML e das instruções detalhadas, consulte Delegado do LiteRT Core ML (em inglês).

Delegados por tipo de modelo

Cada acelerador é projetado com uma certa largura de bits de dados em mente. Se você fornece um modelo de ponto flutuante a um delegado que aceita apenas dados quantizados de 8 bits operações, ele rejeita todas as operações e o modelo é executado inteiramente e a CPU. Para evitar surpresas como essa, a tabela abaixo mostra uma visão geral dos delegar suporte com base no tipo de modelo:

Tipo de modelo GPU CoreML
Ponto flutuante (32 bits) Sim Sim
Quantização float16 pós-treinamento Sim Sim
Quantização de intervalo dinâmico pós-treinamento Sim Não
Quantização de números inteiros pós-treinamento Sim Não
Treinamento com reconhecimento de quantização Sim Não

Validando o desempenho

As informações nesta seção servem como uma orientação básica para a lista reduzida dos delegados que poderiam melhorar seu aplicativo. No entanto, é importante observar que cada delegado tenha um conjunto predefinido de operações que ele suporta, e pode têm desempenhos diferentes dependendo do modelo e do dispositivo. Portanto, é comum é recomendável fazer comparações para avaliar a utilidade de um delegado para suas necessidades. Isso também ajuda a justificar o aumento do tamanho binário associado ao anexando um delegado ao ambiente de execução LiteRT.

A LiteRT tem ferramentas extensivas de avaliação de desempenho e precisão que pode capacitar os desenvolvedores para que se sintam confiantes ao usar delegados em seus aplicativos. Essas ferramentas serão abordadas na próxima seção.

Ferramentas para avaliação

Latência e consumo de memória

A ferramenta de comparação da LiteRT pode ser usada com parâmetros adequados para estimar o desempenho do modelo, incluindo média de inferência latência, sobrecarga de inicialização, consumo de memória etc. Essa ferramenta oferece suporte várias sinalizações para descobrir a melhor configuração de delegado para seu modelo. Para instância, --gpu_backend=gl pode ser especificado com --use_gpu para medir a GPU com o OpenGL. A lista completa de parâmetros delegados compatíveis está definidos nos detalhes Documentação.

Confira um exemplo de execução para um modelo quantizado com GPU via adb:

adb shell /data/local/tmp/benchmark_model \
  --graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
  --use_gpu=true

Você pode fazer o download da versão pré-criada desta ferramenta para Android, ARM de 64 bits arquitetura aqui (mais detalhes).

Precisão e correção

Geralmente, os delegados realizam cálculos com uma precisão diferente da precisão da CPU. parceiros. Como resultado, há uma compensação (geralmente pequena) de precisão associadas à utilização de um delegado para aceleração de hardware. Observe que este nem sempre é verdadeira; por exemplo, já que a GPU usa a precisão de ponto flutuante para executar modelos quantizados, pode haver uma leve melhoria de precisão (por exemplo, menos de 1% de melhoria no top 5 na classificação de imagens ILSVRC).

A LiteRT tem dois tipos de ferramentas para medir a precisão de um delegado comporta-se em um determinado modelo: Task-based e Task-Agnostic. Todas as ferramentas descritas nesta seção são compatíveis com os requisitos de delegação parâmetros usada pela ferramenta de comparação da seção anterior. Observe que o as subseções abaixo se concentram na avaliação do delegado (Será que o delegado realiza as igual à CPU?) em vez de avaliar (o modelo em si é bom para os ?).

Avaliação baseada em tarefas

A LiteRT tem ferramentas para avaliar a correção em duas tarefas baseadas em imagem:

Binários pré-criados dessas ferramentas (arquitetura Android ARM de 64 bits), junto com documentação pode ser encontrada aqui:

O exemplo abaixo demonstra a classificação de imagens avaliação com GPU no Pixel 4:

adb shell /data/local/tmp/run_eval \
  --model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
  --ground_truth_images_path=/data/local/tmp/ilsvrc_images \
  --ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
  --model_output_labels=/data/local/tmp/model_output_labels.txt \
  --output_file_path=/data/local/tmp/accuracy_output.txt \
  --num_images=0 # Run on all images. \
  --use_gpu=true

O resultado esperado é uma lista de métricas Top-K de 1 a 10:

Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333

Avaliação independente de tarefa

Para tarefas em que não há uma ferramenta de avaliação estabelecida no dispositivo ou se você estão testando modelos personalizados, a LiteRT tem o link Inferência diferença ferramenta. (Binário de arquitetura binária ARM Android de 64 bits) aqui)

A diferença de inferência compara a execução do LiteRT (em termos de latência e desvio do valor de saída) em duas configurações:

  • Inferência de CPU com linha de execução única
  • Inferência definida pelo usuário, definida por estes parâmetros

Para isso, a ferramenta gera dados gaussianos aleatórios e os transmite por duas Intérpretes do TFLite: um executando kernels de CPU de thread único, e o outro parametrizado pelos argumentos do usuário.

Ele mede a latência de ambos, bem como a diferença absoluta entre o tensores de saída de cada intérprete, por elemento.

Para um modelo com um único tensor de saída, a saída pode ter a seguinte aparência:

Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06

Isso significa que, para o tensor de saída no índice 0, os elementos de a saída da CPU diferente da saída do delegado por uma média de 1.96e-05.

A interpretação desses números requer um conhecimento mais profundo do modelo e o que cada tensor de saída significa. Se for uma regressão simples que determina algum tipo de pontuação ou incorporação, a diferença deve ser baixa (caso contrário, é um com o delegado). No entanto, saídas como a "classe de detecção" um de Os modelos SSD são um pouco mais difíceis de interpretar. Por exemplo, ele pode mostrar usando essa ferramenta, mas isso pode não significar algo realmente errado com o delegado: considere duas classes (falsas): "TV (ID: 10)", "Monitor (ID:20)" - Se um delegado está um pouco fora da verdade e mostra monitor em vez de TV, a diferença de saída desse tensor pode ser algo tão alto quanto 20-10 = 10.