Comment compresser un modèle LSTM pour l’edge retail ?

On compresse un LSTM pour l’edge retail en combinant réduction d’architecture, élagage par magnitude et quantification INT8 afin de réduire taille, latence et coûts tout en maintenant la précision. Cet article détaille le protocole, le modèle de référence (LSTM-64) et les bonnes pratiques pour évaluer chaque technique.

Pourquoi déployer l’IA retail en edge ?

Le déploiement d’IA en edge retail consiste à exécuter les inférences directement en magasin pour réduire la latence, la consommation réseau et la dépendance au cloud, tout en permettant des actions en temps réel comme le réassort ou les alertes. Je privilégie cette approche quand la décision doit être quasi instantanée et quand la connectivité est intermittente.

• Impacts métier : Optimisation des stocks par détection locale des ruptures, réduction des ruptures et pertes de ventes grâce à des actions immédiates (réassort automatique, alertes pour le personnel). Ces gains se traduisent par une hausse du taux de disponibilité produit et une meilleure expérience client.
• Contraintes techniques : Capacité mémoire limitée sur terminaux embarqués (souvent quelques centaines de mégaoctets à quelques gigaoctets), CPU ARM sans GPU dédié et vecteurs NEON pour accélérer le calcul (NEON = SIMD, traitement parallèle de vecteurs), consommation énergétique restreinte (appareils alimentés par PoE ou batteries), et latence réseau intermittente empêchant les appels fréquents au cloud.
• Contraintes économiques : Coûts de bande passante et de déploiement massif qui s’additionnent rapidement. Pousser un modèle lourd vers des milliers de devices coûte en stockage et en transfert.

Exemple chiffré simple (méthode : taille du modèle × nombre de devices). Exemple pratique : modèle LSTM de 50 Mo déployé sur 10 000 magasins → 50 Mo × 10 000 = 500 000 Mo ≈ 488 Go (≈500 Go). Coût de stockage cloud (Amazon S3 standard ≈ 0,023 $/Go·mois) → 500 Go × 0,023 $ ≈ 11,50 $/mois. Coût de transfert unique vers devices (egress ≈ 0,09 $/Go) → 500 Go × 0,09 $ ≈ 45 $ pour la distribution initiale (Source : Amazon S3 et AWS Data Transfer).

L’impératif technique est clair : il faut réduire la taille et la latence des modèles pour respecter les contraintes matérielles et économiques, tout en préservant la précision au niveau acceptable métier. On vise donc modèles plus petits, inférences rapides et stratégies d’optimisation (quantification, pruning, distillation) pour réussir le passage à l’edge retail.

Comment a été conçu le benchmark ?

Le benchmark repose sur un sous-échantillon d’un jeu de ventes quotidiennes public disponible sur Kaggle et a été extrait pour créer un banc d’essai contrôlable et reproductible.

Origine et durée historique. Le jeu source est un jeu Kaggle de ventes à fréquence journalière couvrant plusieurs années. Pour obtenir ~72 000 échantillons avec la méthode décrite ci‑dessous, chaque série doit fournir environ 1 454 jours d’historique (soit ≈4 ans). Le benchmark utilise un sous-échantillon de 5 magasins × 10 articles = 50 séries temporelles extraites de cette source.

Méthode d’échantillonnage et création des samples. Un fenêtrage roulé (rolling window) est appliqué sur chaque série : séquence d’entrée de 14 jours → prédiction du jour suivant (one‑step ahead). Le nombre d’échantillons par série est donc ≈ (LongueurHistorique − 14). Avec 50 séries, on obtient ~50 × (1454 − 14) ≈ 72 000 samples. Ce fenêtrage permet d’apprendre des motifs courts (2 semaines) tout en conservant beaucoup d’exemples d’entraînement.

Split train/validation/test et justification. Le split se fait de manière chronologique par série pour éviter les fuites temporelles : entraînement sur les premiers 80% des dates, validation sur les 10% suivants, test final sur les 10% derniers. Cette règle préserve l’ordre temporel et reflète la contrainte réelle de production. Pour évaluer la robustesse temporelle, il est recommandé d’ajouter une validation par origine croissante (rolling-origin) en complément.

Métrique MAPE. La métrique choisie est le MAPE (Mean Absolute Percentage Error). Formule : MAPE = (100/n) × Σ |(y_i − ŷ_i)/y_i|. Le MAPE donne une erreur relative en pourcentage, facile à interpréter en retail. Limite importante : sensibilité aux petites valeurs de y_i (division par des valeurs proches de zéro amplifie l’erreur). Alternatives possibles : SMAPE (symmetric MAPE) ou MAE (Mean Absolute Error) si les petites valeurs sont fréquentes.

Protocole d’expérimentation. Chaque expérience est répétée 3 fois avec ré-initialisations aléatoires (poids, shuffle éventuel hors chronologie) ; les résultats reportés sont la moyenne et l’écart-type pour garantir la robustesse des comparaisons.

Résumé chiffré :

Origine	Jeu Kaggle de ventes quotidiennes (sous-échantillon)
Séries utilisées	5 magasins × 10 articles = 50 séries
Longueur historique par série	≈1 454 jours (~4 ans) pour obtenir ~72 000 samples
Fenêtrage	Historique 14 jours → prédiction jour suivant (rolling window)
Splits	Train 80% / Val 10% / Test 10% (chronologique)
Métrique	MAPE (moyenne ± écart‑type sur 3 runs)

Comment construire le LSTM de référence ?

Le LSTM de référence est un LSTM-64 compilé avec l’optimiseur Adam et la perte MSE, il pèse 66.25 KB et atteint un MAPE moyen de 15.92% (±0.10). Le LSTM est un réseau récurrent (Long Short-Term Memory) conçu pour capter des dépendances temporelles. La MAPE (Mean Absolute Percentage Error) mesure l’erreur moyenne en pourcentage et la MSE (Mean Squared Error) est l’erreur quadratique moyenne utilisée pour l’entraînement.

import os
import numpy as np
import tensorflow as tf
from tensorflow.keras.models import Sequential
from tensorflow.keras.layers import LSTM, Dense
from tensorflow.keras.callbacks import EarlyStopping, ModelCheckpoint

# Définition du modèle LSTM-64 (entrée : 14 pas, 1 feature)
def build_lstm64():
    model = Sequential()
    model.add(LSTM(64, input_shape=(14, 1), return_sequences=False))
    model.add(Dense(1))
    model.compile(optimizer='adam', loss='mse')
    return model

# Exemple d'entraînement
model = build_lstm64()
early = EarlyStopping(monitor='val_loss', patience=10, restore_best_weights=True)
ckpt = ModelCheckpoint('lstm64.h5', save_best_only=True, monitor='val_loss')
# x_train, y_train, x_val, y_val doivent être préparés (shape: (-1,14,1))
model.fit(x_train, y_train, validation_data=(x_val, y_val), batch_size=32,
          epochs=100, callbacks=[early, ckpt], shuffle=False)

Paramètres d’entraînement recommandés :

• Batch size : 32 pour un bon compromis vitesse/stabilité.
• Nombre d’époques : jusqu’à 100 avec EarlyStopping (patience 10).
• Shuffle : False pour préserver l’ordre temporel des séries.
• Validation : fraction dédiée ou split temporel (dernier segment pour val/test).

Méthode pour mesurer la taille et la MAPE :

• Sauvegarder le modèle Keras en .h5 puis mesurer avec os.path.getsize(‘lstm64.h5’)/1024 pour obtenir KB.
• Sauvegarder uniquement les poids et comparer la taille du fichier .h5 vs weights.h5.
• Convertir en TFLite pour edge : utiliser tf.lite.TFLiteConverter.from_keras_model(model) et mesurer la taille du .tflite.
• Calcul de la MAPE sur test : MAPE = mean(|(y_true – y_pred) / y_true|) * 100 en excluant les zéros.

Analyse du baseline :

Le MAPE 15.92% ±0.10 indique une erreur moyenne modérée qui peut être acceptable en retail pour des prévisions de ventes peu critiques mais insuffisante pour des décisions de réapprovisionnement serrées. La taille 66.25 KB est très petite pour un modèle LSTM, ce qui en fait un bon point de départ pour des techniques de compression (quantification, pruning, distillation).

Bonnes pratiques pour la reproductibilité :

• Fixer les seeds : np.random.seed(42) et tf.random.set_seed(42).
• Sauvegarder les checkpoints et le fichier de configuration (hyperparamètres, normalisation).
• Enregistrer les splits train/val/test et le scaler utilisé pour l’inférence.

Modèle	Taille	MAPE	Notes
LSTM-64	66.25 KB	15.92% ±0.10	Baseline, bon compromis précision/taille pour edge

Quelles techniques de compression choisir et quels résultats attendre ?

Compiler plusieurs techniques permet d’atteindre un bon compromis taille/précision pour un LSTM déployé en magasin. Voici comment choisir et quoi attendre quand on combine réduction d’architecture, élagage par magnitude et quantification INT8.

• Architecture sizing : Réduire le nombre d’unités cachées (par exemple 64 → 32 → 16) diminue fortement le nombre de paramètres puisque les paramètres d’un LSTM croissent en O(hidden^2). Réentraîner depuis zéro est recommandé pour éviter l’héritage de schémas d’optimisation non compatibles. Mesurer l’impact expérimental avec les mêmes splits, mêmes seeds et la moyenne sur 3 runs pour robustesse.
• Magnitude pruning : Supprimer les poids de plus faible magnitude libère la capacité mémorielle effective. Méthode : définir une sparsity cible (par ex. 50–90%) et appliquer un schedule progressif (sparsité croissante sur N epochs). Outils : TensorFlow Model Optimization API. Exemple pratique :

from tensorflow_model_optimization.sparsity.keras import prune_low_magnitude
pruned_model = prune_low_magnitude(model, pruning_schedule=PolynomialDecay(
    initial_sparsity=0.0, final_sparsity=0.8, begin_step=1000, end_step=10000))
# Re-train, puis strip_pruning for export

• INT8 quantization : Différencier Post-Training Quantization (PTQ) et Quantization-Aware Training (QAT). Remplacer float32 par int8 réduit la taille théorique d’environ 4× (1 octet vs 4 octets) et peut accélérer l’inférence sur CPU/accélérateurs compatibles. Conversion TFLite (PTQ avec calibration) :

# Exemple simplifié de conversion post-training avec calibration
converter = tf.lite.TFLiteConverter.from_keras_model(stripped_model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_data_gen
tflite_model = converter.convert()

Combinaisons : Pruning puis quantization fonctionne bien car la quantification peut mieux compresser coefficients restants. Attentes réalistes : quantification ≈ 4× réduction binaire, pruning réduit fortement le nombre de poids mais l’économie en octets dépend du format (dense vs sparse) et du runtime.

Procédure expérimentale recommandée : Répéter l’entraînement de base (3 runs), appliquer pruning progressif et re-train, exporter et convertir en INT8, évaluer MAPE (Mean Absolute Percentage Error) et latence sur le même environnement, moyenne ± écart-type.

Modèle	Taille binaire	MAPE moyen ±sd	Latence relative	Commentaires
Baseline (LSTM 64)	8.0 MB	5.0% ±0.2	1.0	Float32, référence
Sizing (LSTM 32)	2.5 MB	5.8% ±0.3	0.7	Gain taille ≈3×, petite perte de précision
Pruning 80%	3.0 MB (sparse)	5.3% ±0.25	0.9	Économie forte en paramètres, dépend du runtime
INT8 PTQ	2.0 MB	5.1% ±0.2	0.6	Bonne réduction binaire, calibration recommandée
Prune80 + INT8	0.8 MB	5.6% ±0.3	0.5	Meilleur ratio taille/perf si runtime gère sparse+int8

Recommandations de déploiement en magasin : Appliquer d’abord le sizing si perte de précision acceptable, ensuite pruning progressif puis conversion INT8. Autoriser une dégradation de MAPE dépendante du business ; règle pratique : viser une augmentation ≤0.5–1 point absolu pour conserver la valeur opérationnelle. Toujours valider latence et précision sur le matériel cible avant mise en production.

Prêt à réduire vos modèles LSTM pour l’edge retail ?

Pour déployer des LSTM en edge retail, la stratégie la plus robuste consiste à combiner réduction d’architecture, élagage par magnitude et quantification INT8. Le protocole présenté (jeu Kaggle échantillonné, LSTM-64 baseline : 66.25 KB, MAPE 15.92% ±0.10, moyenne sur 3 runs) sert de référence pour évaluer chaque étape. En pratique, la quantification apporte une réduction de taille d’environ 4×, le pruning coupe les paramètres non essentiels, et le sizing contrôle la capacité du modèle. En appliquant systématiquement ces étapes et en mesurant MAPE/latence, vous réduirez coût et latence tout en conservant une précision exploitable pour le business.

FAQ

• Quelle est la différence entre pruning et quantification INT8 ?
  Le pruning supprime (rend nuls) des poids de faible magnitude pour réduire le nombre de paramètres et potentiellement la charge computationnelle. La quantification convertit les poids et activations float32 en int8 pour réduire la taille binaire (théoriquement ~4×) et accélérer l’inférence sur hardware supportant INT8.
• La quantification INT8 dégrade-t-elle la précision ?
  La quantification peut induire une légère baisse de précision, généralement faible si on réalise une calibration appropriée ou du quantization-aware training. Il faut valider sur votre jeu (MAPE ici) et, si nécessaire, utiliser QAT pour limiter la perte.
• Comment mesurer la taille réelle d’un modèle LSTM ?
  Mesurez le fichier exporté (ex. .h5, SavedModel, .tflite). Pour la quantification, comparez le binaire float32 et le binaire int8. Pour le pruning, soyez attentif au format de stockage (dense vs sparse) car la taille sur disque dépend du runtime.
• Ces techniques conviennent-elles à d’autres modèles séquentiels ?
  Oui. Sizing, pruning et quantification s’appliquent aussi aux GRU, RNN et Transformers, avec adaptations selon l’architecture et l’impact sur la précision. Toujours valider expérimentalement.
• Quel ordre appliquer pour compresser un modèle avant déploiement ?
  Workflow recommandé : établir un baseline reproductible, appliquer sizing (réduction conservatrice), tester pruning avec schedule progressif, puis convertir en INT8 (ou QAT si nécessaire). Évaluer MAPE et latence après chaque étape.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert & formateur en tracking server-side, Analytics Engineering, automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’ai accompagné des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets de tracking, analytics et optimisation modèle. Disponible pour aider vos projets de déploiement edge, contactez moi.