Versões do operador TensorFlow Lite

Este documento descreve o esquema de controle de versão operacional do TensorFlow Lite. O controle de versão de operações permite que os desenvolvedores adicionem novas funcionalidades e parâmetros às operações existentes. Além disso, garante o seguinte:

  • Compatibilidade com versões anteriores: a nova implementação do TensorFlow Lite deve lidar com um arquivo de modelo antigo.
  • Compatibilidade futura: a implementação do TensorFlow Lite antiga deve lidar com um novo arquivo de modelo produzido pela nova versão do conversor, desde que nenhum recurso novo seja usado
  • Avançar detecção de incompatibilidade: se uma implementação antiga do TensorFlow Lite lê um novo modelo que contém uma nova versão de uma operação que não é compatível, ela deve relatar o erro.

Exemplo: Adicionando dilatação na convolução em profundidade

O restante deste documento explica o controle de versão operacional em TFLite, mostrando como adicionar parâmetros de dilatação à operação de convolução em profundidade.

Não é necessário conhecimento de dilatação para entender este documento. Observe que:

  • 2 novos parâmetros inteiros serão adicionados: dilation_width_factor e dilation_height_factor .
  • Os núcleos de convolução de profundidade antigos que não suportam a dilatação são equivalentes a definir os fatores de dilatação para 1.

Alterar o esquema FlatBuffer

Para adicionar novos parâmetros em um op, altere a tabela de opções em lite/schema/schema.fbs .

Por exemplo, a tabela de opções de convolução em profundidade tem a seguinte aparência:

table DepthwiseConv2DOptions {
  padding:Padding;
  stride_w:int;
  stride_h:int;
  depth_multiplier:int;
  fused_activation_function:ActivationFunctionType;
}

Ao adicionar novos parâmetros:

  • Adicione comentários indicando quais parâmetros são suportados por qual versão.
  • Quando a nova implementação obtém os valores padrão para os parâmetros recém-adicionados, ela deve funcionar exatamente da mesma forma que a implementação antiga.

A tabela ficará assim depois que os novos parâmetros forem adicionados:

table DepthwiseConv2DOptions {
  // Parameters for DepthwiseConv version 1 or above.
  padding:Padding;
  stride_w:int;
  stride_h:int;
  depth_multiplier:int;
  fused_activation_function:ActivationFunctionType;
  // Parameters for DepthwiseConv version 2 or above.
  dilation_w_factor:int = 1;
  dilation_h_factor:int = 1;
}

O arquivo lite/schema/schema_generated.h deve ser gerado novamente para o novo esquema.

Alterar estruturas C e implementação de kernel

No TensorFlow Lite, a implementação do kernel é desacoplada da definição FlatBuffer. Os kernels lêem o parâmetro das estruturas C definidas em lite/c/builtin_op_data.h .

O parâmetro de convolução em profundidade original é o seguinte:

typedef struct {
  TfLitePadding padding;
  int stride_width;
  int stride_height;
  int depth_multiplier;
  TfLiteFusedActivation activation;
} TfLiteDepthwiseConvParams;

Tal como acontece com o esquema FlatBuffer, adicione comentários indicando quais parâmetros são suportados a partir de qual versão. O resultado é visto abaixo:

typedef struct {
  // Parameters for DepthwiseConv version 1 or above.
  TfLitePadding padding;
  int stride_width;
  int stride_height;
  int depth_multiplier;
  TfLiteFusedActivation activation;
  // Parameters for DepthwiseConv version 2 or above.
  int dilation_width_factor;
  int dilation_height_factor;
} TfLiteDepthwiseConvParams;

Altere também a implementação do kernel para ler os parâmetros recém-adicionados das estruturas C. Os detalhes são omitidos aqui.

Altere o código de leitura do FlatBuffer

A lógica para ler FlatBuffer e produzir a estrutura C está em lite/core/api/flatbuffer_conversions.cc .

Atualize o arquivo para lidar com os novos parâmetros, conforme mostrado abaixo:

TfLiteStatus ParseDepthwiseConv2D(const Operator* op,
                                  ErrorReporter* error_reporter,
                                  BuiltinDataAllocator* allocator,
                                  void** builtin_data) {
  CheckParsePointerParams(op, error_reporter, allocator, builtin_data);

  SafeBuiltinDataAllocator safe_allocator(allocator);

  std::unique_ptr<TfLiteDepthwiseConvParams,
                  SafeBuiltinDataAllocator::BuiltinDataDeleter>
      params = safe_allocator.Allocate<TfLiteDepthwiseConvParams>();
  TF_LITE_ENSURE(error_reporter, params != nullptr);

  const DepthwiseConv2DOptions* schema_params =
      op->builtin_options_as_DepthwiseConv2DOptions();

  if (schema_params != nullptr) {
    params->padding = ConvertPadding(schema_params->padding());
    params->stride_width = schema_params->stride_w();
    params->stride_height = schema_params->stride_h();
    params->depth_multiplier = schema_params->depth_multiplier();
    params->activation =
        ConvertActivation(schema_params->fused_activation_function());

    params->dilation_width_factor = schema_params->dilation_w_factor();
    params->dilation_height_factor = schema_params->dilation_h_factor();
  }

  *builtin_data = params.release();
  return kTfLiteOk;
}

Não é necessário verificar a versão op aqui. Quando a nova implementação lê um arquivo de modelo antigo onde faltam fatores de dilatação, ela usará 1 como o valor padrão e o novo kernel funcionará de forma consistente com o kernel antigo.

Alterar o registro do kernel

O MutableOpResolver (definido em lite/mutable_op_resolver.h ) fornece algumas funções para registrar kernels op. A versão mínima e máxima são 1 por padrão:

void AddBuiltin(tflite::BuiltinOperator op, TfLiteRegistration* registration,
                int min_version = 1, int max_version = 1);
void AddCustom(const char* name, TfLiteRegistration* registration,
               int min_version = 1, int max_version = 1);

Os ops integrados são registrados em lite/kernels/register.cc . Neste exemplo, implementamos um novo kernel op que pode lidar com DepthwiseConv2D versão 1 e 2, portanto, precisamos alterar esta linha:

AddBuiltin(BuiltinOperator_DEPTHWISE_CONV_2D, Register_DEPTHWISE_CONV_2D());

para:

AddBuiltin(BuiltinOperator_DEPTHWISE_CONV_2D, Register_DEPTHWISE_CONV_2D(),
             /* min_version = */ 1,
             /* max_version = */ 2);

Alterar versão op TFLite

A próxima etapa é fazer com que o TFLite preencha a versão mínima necessária para executar a operação. Neste exemplo, significa:

  • Preencher versão = 1 quando os fatores de dilatação forem todos 1.
  • Preencher versão = 2 caso contrário.

Modifique a função GetBuiltinOperatorVersion para o operador em lite/tools/versioning/op_version.cc adicionando a nova versão ao caso de DepthwiseConv2D :

case BuiltinOperator_DEPTHWISE_CONV_2D:
  auto depthwise_conv_params =
      reinterpret_cast<TfLiteDepthwiseConvParams*>(op_sig.builtin_data);
  TFLITE_DCHECK(depthwise_conv_params != nullptr);
  if (depthwise_conv_params->dilation_width_factor != 1 ||
       depthwise_conv_params->dilation_height_factor != 1) {
    return 2;
  }
  return 1;

Atualize o mapa da versão do operador

A última etapa é adicionar as informações da nova versão ao mapa da versão do operador. Esta etapa é necessária porque precisamos gerar a versão de tempo de execução mínima exigida do modelo com base neste mapa de versão.

Para fazer isso, você precisa adicionar uma nova entrada de mapa em lite/tools/versioning/runtime_version.cc .

Neste exemplo, você precisa adicionar a seguinte entrada em op_version_map :

{ {BuiltinOperator_DEPTHWISE_CONV_2D, 2}, %CURRENT_RUNTIME_VERSION%}

onde %CURRENT_RUNTIME_VERSION% corresponde à versão de tempo de execução atual definida em tensorflow / core / public / version.h .

Implementação de delegação

O TensorFlow Lite fornece uma API de delegação que permite delegar operações para back-ends de hardware. Na função Prepare do delegado, verifique se a versão é suportada para cada nó no código de Delegação.

const int kMaxVersion = 1;
TfLiteNode* node;
TfLiteRegistration* registration = nullptr;
TF_LITE_ENSURE_STATUS(context->GetNodeAndRegistration(context, node_index, &node, &registration));

if (registration->version > kMaxVersion) {
  // Reject the node if the version isn't supported.
}

Isso é necessário mesmo se a delegação for compatível apenas com operações da versão 1, para que a delegação possa detectar incompatibilidade ao obter uma versão de operação superior