Ce document décrit le schéma de gestion des versions des opérations de LiteRT. La gestion des versions des opérations permet aux développeurs d'ajouter de nouvelles fonctionnalités et de nouveaux paramètres aux opérations existantes. De plus, il garantit les points suivants:
- Rétrocompatibilité: la nouvelle implémentation de LiteRT doit gérer un ancien fichier de modèle.
- Compatibilité ascendante: l'ancienne implémentation de LiteRT doit gérer un nouveau fichier de modèle produit par la nouvelle version du convertisseur, à condition qu'aucune nouvelle fonctionnalité ne soit utilisée.
- Détection de la non-compatibilité avant: si une ancienne implémentation LiteRT lit un nouveau modèle contenant une nouvelle version d'une opération non prise en charge, elle doit signaler l'erreur.
Exemple: Ajouter une dilatation à la convolution en profondeur
Le reste de ce document explique la gestion des versions des opérations dans TFLite en montrant comment ajouter des paramètres de dilatation à l'opération de convolution en profondeur.
La connaissance de la dilatation n'est pas requise pour comprendre ce document. Remarques :
- Deux nouveaux paramètres entiers seront ajoutés:
dilation_width_factoretdilation_height_factor. - Les anciens noyaux de convolution en profondeur qui ne sont pas compatibles avec la dilatation sont équivalents à la définition des facteurs de dilatation sur 1.
Modifier le schéma FlatBuffer
Pour ajouter des paramètres à une opération, modifiez la table des options dans lite/schema/schema.fbs.
Par exemple, le tableau des options de la convolution en profondeur se présente comme suit:
table DepthwiseConv2DOptions {
padding:Padding;
stride_w:int;
stride_h:int;
depth_multiplier:int;
fused_activation_function:ActivationFunctionType;
}
Lorsque vous ajoutez des paramètres:
- Ajoutez des commentaires indiquant les paramètres compatibles avec chaque version.
- Lorsque la nouvelle implémentation obtient les valeurs par défaut des paramètres nouvellement ajoutés, elle doit fonctionner exactement de la même manière que l'ancienne implémentation.
Le tableau ressemblera à ceci une fois les nouveaux paramètres ajoutés:
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;
}
Le fichier lite/schema/schema_generated.h doit être généré à nouveau pour le nouveau schéma.
Modifier les structures C et l'implémentation du noyau
Dans LiteRT, l'implémentation du noyau est dissociée de la définition FlatBuffer. Les noyaux lisent le paramètre à partir des structures C définies dans lite/c/builtin_op_data.h.
Le paramètre de convolution en profondeur d'origine est le suivant:
typedef struct {
TfLitePadding padding;
int stride_width;
int stride_height;
int depth_multiplier;
TfLiteFusedActivation activation;
} TfLiteDepthwiseConvParams;
Comme pour le schéma FlatBuffer, ajoutez des commentaires indiquant les paramètres compatibles à partir de quelle version. Le résultat est visible ci-dessous:
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;
Veuillez également modifier l'implémentation du noyau pour lire les nouveaux paramètres ajoutés à partir des structures C. Les détails sont ici omis.
Modifier le code de lecture FlatBuffer
La logique de lecture de FlatBuffer et de génération de la structure C se trouve dans lite/core/api/flatbuffer_conversions.cc.
Mettez à jour le fichier pour gérer les nouveaux paramètres, comme indiqué ci-dessous:
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;
}
Il n'est pas nécessaire de vérifier la version de l'opération ici. Lorsque la nouvelle implémentation lit un ancien fichier de modèle dans lequel les facteurs de dilatation sont manquants, elle utilise 1 comme valeur par défaut, et le nouveau noyau fonctionne de manière cohérente avec l'ancien noyau.
Modifier l'enregistrement du noyau
MutableOpResolver (défini dans lite/mutable_op_resolver.h) fournit quelques fonctions pour enregistrer des noyaux d'opération. Les versions minimale et maximale sont définies sur 1 par défaut:
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);
Les opérations intégrées sont enregistrées dans lite/kernels/register.cc. Dans cet exemple, nous avons implémenté un nouveau kernel d'opérations capable de gérer les versions 1 et 2 de DepthwiseConv2D. Nous devons donc modifier cette ligne:
AddBuiltin(BuiltinOperator_DEPTHWISE_CONV_2D, Register_DEPTHWISE_CONV_2D());
par :
AddBuiltin(BuiltinOperator_DEPTHWISE_CONV_2D, Register_DEPTHWISE_CONV_2D(),
/* min_version = */ 1,
/* max_version = */ 2);
Modifier la version d'opération TFLite
L'étape suivante consiste à faire remplir par TFLite la version minimale requise pour exécuter l'opération. Dans cet exemple, cela signifie:
- Renseignez la version=1 lorsque les facteurs de dilatation sont tous égaux à 1.
- Renseignez version=2 dans les autres cas.
Modifiez la fonction GetBuiltinOperatorVersion pour l'opérateur dans lite/tools/versioning/op_version.cc en ajoutant la nouvelle version au cas 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;
Mettre à jour la carte des versions de l'opérateur
La dernière étape consiste à ajouter les informations sur la nouvelle version dans la carte des versions de l'opérateur. Cette étape est nécessaire, car nous devons générer la version d'exécution minimale requise du modèle en fonction de ce mappage de versions.
Pour ce faire, vous devez ajouter une entrée de carte dans lite/tools/versioning/runtime_version.cc.
Dans cet exemple, vous devez ajouter l'entrée suivante dans op_version_map:
{ {BuiltinOperator_DEPTHWISE_CONV_2D, 2}, %CURRENT_RUNTIME_VERSION%}
où %CURRENT_RUNTIME_VERSION% correspond à la version d'exécution actuelle définie dans release_version.h.
Implémentation de la délégation
LiteRT fournit une API de délégation qui permet de déléguer des opérations aux backends matériels. Dans la fonction Prepare du délégué, vérifiez si la version est compatible avec chaque nœud du code de délégation.
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.
}
Cela est obligatoire, même si la délégation n'est compatible qu'avec les opérations de la version 1, afin que la délégation puisse détecter l'incompatibilité lors de l'obtention d'une opération de version supérieure.