Este documento descreve o esquema de controle de versão operacional do TensorFlow Lite. O versionamento 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 antiga do TensorFlow Lite deve lidar com um novo arquivo de modelo produzido pela nova versão do conversor, desde que nenhum novo recurso seja usado.
- Detecção de incompatibilidade de encaminhamento: se uma implementação antiga do TensorFlow Lite ler um novo modelo que contém uma nova versão de uma operação sem suporte, ela deverá relatar o erro.
Exemplo: Adicionando dilatação em convolução em profundidade
O restante deste documento explica o controle de versão operacional no TFLite, mostrando como adicionar parâmetros de dilatação à operação de convolução em profundidade.
O conhecimento de dilatação não é necessário para entender este documento. Observe que:
- 2 novos parâmetros inteiros serão adicionados:
dilation_width_factoredilation_height_factor. - Os kernels de convolução de profundidade antigos que não suportam dilatação são equivalentes a definir os fatores de dilatação como 1.
Alterar esquema do 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 de profundidade se parece com isso:
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 do kernel
No TensorFlow Lite, a implementação do kernel é desacoplada da definição do 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 de profundidade original é o seguinte:
typedef struct {
TfLitePadding padding;
int stride_width;
int stride_height;
int depth_multiplier;
TfLiteFusedActivation activation;
} TfLiteDepthwiseConvParams;
Assim como no 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;
Por favor, 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.
Alterar 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 os fatores de dilatação estão ausentes, ela usará 1 como o valor padrão e o novo kernel funcionará de forma consistente com o kernel antigo.
Alterar registro do kernel
O MutableOpResolver (definido em lite/mutable_op_resolver.h ) fornece algumas funções para registrar kernels operacionais. 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);
As operações internas são registradas em lite/kernels/register.cc . Neste exemplo, implementamos um novo kernel operacional que pode lidar com DepthwiseConv2D versão 1 e 2, então 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 a versão operacional do 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:
- Preencha version=1 quando os fatores de dilatação forem todos 1.
- Preencha version=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;
Atualizar o mapa de versão do operador
A última etapa é adicionar as informações da nova versão ao mapa de versão do operador. Essa etapa é necessária porque precisamos gerar a versão de tempo de execução mínima exigida do modelo com base nesse 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 a back-ends de hardware. Na função Prepare do delegado, verifique se a versão é compatível com 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, ®istration));
if (registration->version > kMaxVersion) {
// Reject the node if the version isn't supported.
}
Isso é necessário mesmo que a delegação dê suporte apenas a operações de versão 1, para que a delegação possa detectar incompatibilidade ao obter uma operação de versão superior.