Comment compresser un LSTM pour le retail ?

Compresser un LSTM pour le retail edge se fait via réduction d’architecture, élagage par magnitude et quantification INT8 pour réduire taille et latence tout en maintenant une précision utile. Je présente protocole, résultats clés et choix pratiques pour déployer en magasin.

Pourquoi compresser un LSTM pour le retail ?

Compresser un LSTM est souvent indispensable pour des déploiements en magasin où la latence, la mémoire et le coût par inference dictent l’architecture technique et économique.

Les contraintes typiques du retail edge incluent une mémoire flash/ROM limitée (nombreux appareils embarqués disposent de quelques centaines de kilo-octets à quelques méga-octets), une RAM restreinte qui limite la taille des tenseurs en runtime, une latence réseau intermittente rendant nécessaire l’inférence offline, et une consommation énergétique contrainte pour des appareils alimentés en batterie ou pour réduire la facture électrique.

Les techniques de compression sont bien documentées et efficaces pour ces cas d’usage ; voir par exemple la « TensorFlow Lite documentation » pour la quantification et le déploiement edge, et Han et al., « Deep Compression », 2016, qui montre des gains massifs (jusqu’à ~35× sur certains modèles) en combinant pruning, quantization et encodage sans perte significative d’exactitude.

Impact direct sur le business :

• Réduction du coût par prédiction : Moins de poids et moins de calculs réduisent le temps machine et le coût cloud lorsque l’inférence est centralisée ou synchronisée.
• Capacité à inférer sur des milliers de SKU : Un modèle compressé permet de stocker plusieurs modèles ou variantes par point de vente sans multiplier l’infrastructure matérielle.
• Fonctionnement offline et réduction des coûts cloud : Des modèles petits et optimisés permettent une prise de décision locale, évitent les allers-retours réseau et diminuent la dépendance au cloud.

Cas concret de référence :

Modèle de base LSTM-64 (taille 66,25 KB). Un modèle inférieur à 100 KB facilite un déploiement massif en retail car il tient dans la plupart des mémoires flash embarquées, réduit le coût de distribution OTA (over-the-air) et permet d’instancier plusieurs modèles par appareil pour gérer SKU, promotions ou saisons.

Contrainte	Conséquence	Objectif de compression
Mémoire flash/ROM limitée	Impossible de stocker des modèles volumineux ou multiples	Réduire
RAM limitée	OOM (out-of-memory) à l’inférence	Réduire paramètres et taille des tenseurs
Latence réseau intermittente	Dépendance au cloud non fiable	Permettre inference locale fiable

• Prioriser d’abord la quantification (p.ex. int8) pour gains immédiats en taille et latence, comme recommandé dans la TensorFlow Lite documentation.
• Appliquer ensuite le pruning structurel et la distillation pour conserver la précision tout en réduisant paramètres, en s’inspirant de Han et al., « Deep Compression », 2016.
• Mesurer coût par prédiction réel (CPU cycles, énergie, latence) pour décider entre inference locale vs cloud et dimensionner l’effort de compression.

Comment j’ai configuré le benchmark ?

J’ai configuré un benchmark reproductible sur le jeu Kaggle « Store Item Demand Forecasting » en échantillonnant 50 séries (5 magasins × 10 articles), soit environ 72 000 fenêtres d’entraînement pour une tâche de prédiction next-day avec fenêtre historique de 14 jours.

• Dataset et échantillonnage : Sélection manuelle de 5 stores × 10 items pour limiter la charge expérimentale tout en gardant de la variabilité. Données : ventes quotidiennes historiques issues de Kaggle (Store Item Demand Forecasting).
• Prétraitement : Application de log1p(y) pour réduire l’asymétrie des ventes, puis MinMax scaling par série pour préserver la dynamique locale. Gestion des zéros : Conservation des zéros (demande réelle = 0) après log1p. J’ai marqué les jours fériés comme une feature binaire si disponible, car les événements externes influencent fortement la demande.
• Fenêtrage (sliding windows) : Génération de séquences de longueur 14 pour prédire le pas suivant (next-day). Split temporel par série : Train 70%, Validation 15%, Test 15% (séquences finales réservées au test pour éviter fuite temporelle).

Logique de windowing (pseudocode) :

def windowing(series, window=14):
    X, y = [], []
    for i in range(len(series) - window):
        X.append(series[i:i+window])    # shape (window,)
        y.append(series[i+window])      # scalar target
    return np.array(X, dtype=np.float32), np.array(y, dtype=np.float32)

Modèle baseline et hyperparamètres :

• Architecture : LSTM séquentiel 64 unités, Dropout 0.2, Dense(1) sortie (taille fichier ~66,25 KB).
• Performance rapportée : MAPE moyen 15,92% (écart-type ±0,10%) sur 3 runs.
• Entraînement : Optimiseur Adam lr=1e-3, Batch size=64, Epochs=50, EarlyStopping(patience=5, restore_best_weights=True).

Exemples TensorFlow/Keras (shapes et dtype expliqués dans les commentaires) :

# Génération des séquences (X shape: [N,14], y shape: [N], dtype=float32)
X, y = windowing(series_array, window=14)
X = X.reshape(-1, 14, 1)  # ajouter dimension feature, dtype float32

# Construction et compilation du modèle baseline
from tensorflow.keras import layers, models, optimizers, callbacks
model = models.Sequential([
    layers.Input(shape=(14,1)),
    layers.LSTM(64),
    layers.Dropout(0.2),
    layers.Dense(1)
])
model.compile(optimizer=optimizers.Adam(1e-3), loss='mean_absolute_percentage_error', metrics=['mean_absolute_percentage_error'])

# Boucle d'entraînement avec EarlyStopping et sauvegarde du meilleur modèle
es = callbacks.EarlyStopping(patience=5, restore_best_weights=True, monitor='val_loss')
mc = callbacks.ModelCheckpoint('best_lstm.h5', save_best_only=True, monitor='val_loss')
history = model.fit(X_train, y_train, validation_data=(X_val,y_val), batch_size=64, epochs=50, callbacks=[es, mc])

Dataset	Kaggle Store Item Demand Forecasting
Nombre de séries	50 (5 magasins × 10 articles)
Fenêtre	14 jours (next-day)
Métrique	MAPE
Baseline taille	≈66,25 KB
Baseline MAPE	15,92% ±0,10% (moyenne sur 3 runs)

Comment réduire la capacité du réseau ?

Réduire le nombre d’unités LSTM est la méthode la plus simple pour compresser un modèle: diminuer h (par exemple 64 → 32 → 16) réduit fortement le nombre de paramètres et le coût de calcul, mais augmente le risque de sous-ajustement (biais).

Principe d’architecture sizing: La couche LSTM a un terme en h^2 (liaisons récurrentes) qui domine le coût. Pour une entrée univariée et une couche LSTM seule, le nombre de paramètres ≈ 4·h^2 + 9·h + 1. Ce qui signifie qu’une division par deux de h réduit les paramètres d’environ 4× en pratique. Limites: Perte de capacité pour capter dynamiques complexes, sensibilité au bruit et aux saisonnalités non linéaires. Quand privilégier: Si la contrainte mémoire/latence est forte, si les patterns sont simples ou si on peut compenser par plus de données ou features.

• Protocole expérimental (explicite et reproductible):
• Utiliser les mêmes données, mêmes splits temporels (walk-forward si séries), et mêmes seeds (numpy + tensorflow).
• Faire 3 runs indépendants et rapporter la moyenne et l’écart-type.
• Conserver la même stratégie d’early stopping (monitor=’val_loss’, patience=10, restore_best_weights=True) et la même régularisation (ex: Dropout 0.2) pour toutes les tailles.
• Préférer validation croisée temporelle (rolling forecast) plutôt qu’un simple shuffle pour séries temporelles.

Exemples Keras (coller tels quels dans le code) :

model = Sequential([LSTM(64, input_shape=(14,1)), Dropout(0.2), Dense(1)])
model = Sequential([LSTM(32, input_shape=(14,1)), Dropout(0.2), Dense(1)])
model = Sequential([LSTM(16, input_shape=(14,1)), Dropout(0.2), Dense(1)])
compile(optimizer='adam', loss='mse', metrics=['mean_absolute_percentage_error'])

Critères de choix et trade-offs: Estimer la taille binaire via params·4 bytes ou sauvegarder model.save(‘model.h5’) et mesurer la taille fichier. Définir une perte de MAPE (Mean Absolute Percentage Error) acceptable pour le business — MAPE = mean(|(y_true−y_pred)/y_true|)·100, attention aux zéros. Réentraîner chaque configuration et appliquer la validation temporelle; choisir la plus petite configuration dont le MAPE reste dans le seuil métier.

Méthode simple pour décider du nombre d’unités: Avancer par facteur 2 (64 → 32 → 16), monitorer MAPE et taille; s’arrêter quand la MAPE dépasse la tolérance métier ou quand gains mémoire sont négligeables.

Unités	Taille binaire (KB)	MAPE moyen	Notes d’usage
64	≈66.3 KB (estimation: 16 961 params ·4B)	À mesurer (voir protocole)	Baseline; meilleure capacité pour dynamiques complexes
32	≈17.1 KB (estimation: 4 385 params ·4B)	À mesurer (voir protocole)	Bon compromis mémoire/précision dans beaucoup de cas
16	≈4.6 KB (estimation: 1 169 params ·4B)	À mesurer (voir protocole)	Très petit; risque de sous-ajustement si séries complexes

Comment utiliser le pruning et l’INT8 ?

Voici comment combiner pruning et INT8 pour un LSTM destiné au retail afin de réduire taille et latence tout en contrôlant la perte de précision.

Magnitude pruning. Elagage des poids de faible magnitude pour obtenir de la sparsité dans le réseau. Plusieurs approches existent : global (on compare tous les poids et on élimine les plus petits) ou layer-wise (on fixe une sparsité par couche). Exemples de cibles de sparsité courantes : 50%–90% selon la tolérance à la dégradation. Les schedules (par ex. gradual pruning) augmentent la sparsité progressivement pendant l’entraînement pour stabiliser l’accuracy. Référence historique : Han et al., Deep Compression (2016).

Implications pratiques. La sparsité non structurée (poids individuels nuls) donne une forte réduction de paramètres mais exige des bibliothèques/format sparsifiés pour un vrai speed‑up sur CPU/ARM. La sparsité structurée (filtre/canal entier) est plus compatible avec les accélérations matérielles mais peut coûter plus en précision. Mesurer le speed‑up réel sur votre cible est indispensable.

Exemple TensorFlow Model Optimization (magnitude pruning).

import tensorflow_model_optimization as tfmot
from tensorflow_model_optimization.sparsity.keras import prune_low_magnitude, PolynomialDecay
pruning_params = {
  'pruning_schedule': PolynomialDecay(
      initial_sparsity=0.0,
      final_sparsity=0.8,  # Exemple 80% au final
      begin_step=0,
      end_step=10000)
}
model_pruned = prune_low_magnitude(model, **pruning_params)
model_pruned.compile(...)
# Callbacks pour mettre à jour le pruning et sauver les summaries
callbacks = [
  tfmot.sparsity.keras.UpdatePruningStep(),
  tfmot.sparsity.keras.PruningSummaries(log_dir='/tmp/prune')
]
model_pruned.fit(train_ds, epochs=5, callbacks=callbacks)
# Export final sans wrappers
model_for_export = tfmot.sparsity.keras.strip_pruning(model_pruned)

Quantification INT8. Trois modes principaux : post‑training dynamic range quantization (simple, réduit taille ~4x), full integer post‑training quantization (quantifie poids et activations, nécessite representative_dataset pour calibrer les échelles) et quantization‑aware training (QAT) qui simule la quantification pendant l’entraînement pour limiter la perte d’accuracy. Source : TensorFlow Lite docs (réduction de taille ≈4x pour INT8).

Conversion Keras → TFLite INT8 (flux).

converter = tf.lite.TFLiteConverter.from_keras_model(model_for_export)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
# Pour full integer, fournir une fonction representative_dataset
converter.representative_dataset = representative_data_gen
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8
tflite_model = converter.convert()

QAT. Annoter le modèle puis appliquer quantize_apply, réentraîner quelques epochs (faible lr) pour récupérer la précision, puis convertir en TFLite. Exemple avec tfmot.quantization.keras.quantize_annotate_model et tfmot.quantization.keras.quantize_apply.

Ordre des opérations et recommandations. Pruner avant quantification est généralement conseillé : pruning réduit le modèle, puis la quantification compresse/accélère. Combinaison pruning+quantization donne des réductions importantes (voir Deep Compression pour contexte). Tester : (1) PTQ INT8 rapide, (2) pruning non structuré + PTQ, (3) pruning structuré + PTQ, (4) prune puis QAT si précision chute.

Technique	Bénéfices attendus	Risques / limites	Recommandation
Pruning non structuré	Fortes réductions de paramètres (50–90%)	Peu de speed‑up sans support sparse, complexité d’export	Tester pour taille; valider speed‑up sur cible
Pruning structuré	Réduction compatible hardware, vrai speed‑up	Plus d’impact sur précision	Prioriser si cible CPU/ARM sans sparse libs
Post‑training INT8	Taille ≈4x moindre, latence souvent améliorée	Perte de précision possible sans calibration	Commencer par PTQ avec dataset représentatif
Quantization‑Aware Training (QAT)	Meilleure précision après quantification	Coût d’entraînement supplémentaire	Utiliser si PTQ trop dégrade l’accuracy

Comment choisir et déployer en magasin ?

Je commence par définir l’objectif : réduire la taille, la latence ou la complexité d’intégration en fonction des contraintes magasin (mémoire, CPU, accélérateur).

Critères de choix. Je choisis la technique selon l’objectif principal : taille (pruning, quantization), latence (quantization int8 + accélérateurs), simplicité (format natif du device).

• Précision de l’objectif : Définir un SLA de latence et une limite mémoire (ex : 50 Mo RAM, latence ≤ 100 ms).
• Contrainte hardware : Vérifier CPU (ARM Cortex-A53), présence d’Edge TPU/NNAPI ou GPU; Edge TPU nécessite int8 et ops supportés (voir docs Coral).
• Coûts opérationnels : Estimer volume d’inférences/jour pour calculer coût CPU/accélérateur et consommation électrique.
• Fréquence de mise à jour : Si mises à jour fréquentes, privilégier flux OTA simple et formats répandus (TFLite, ONNX).

Processus de validation. Je valide sur hardware représentatif avant déploiement.

• Profiler inference : Mesurer latence p90/p99, mémoire live, consommation énergétique avec outils locaux (perf, top) ou trace TFLite.
• Tests A/B : Comparer version compressée vs baseline sur métriques business (MAPE = Mean Absolute Percentage Error).
• Offline vs online : Valider offline sur dataset historique puis lancer pilote en magasin pour tests online.
• Rollback et sécurité : Préparer image signée et procédure de rollback; chiffrer OTA et vérifier intégrité.

Outils et formats recommandés. Pour mobile/edge utiliser TensorFlow Lite (TFLite). Pour devices supportant ONNX utiliser ONNX Runtime. Pour accélération hardware, envisager EdgeTPU (Coral) mais rester strict sur int8 et ops supportés. Les quantifications 8‑bit réduisent souvent la taille ~4× et améliorent la latence 2–3× (voir documentation TensorFlow Lite).

Pipeline CI/CD pour edge. Automatiser conversion (strip pruning metadata + conversion TFLite), exécuter tests unitaires et tests sur device farm, signer artefacts et déployer OTA. Intégrer monitoring de drift et calibration (erreur de calibration, dérive MAPE). Agréger logs côté serveur pour analyses.

Monitoring et maintenance. Planifier réentraînement (ex : mensuel ou déclenché si MAPE > 5%). Définir triggers automatiques, stratégie de rollback instantanée et stocker features essentielles dans un feature store simplifié pour réentraînement rapide.

Checklist avant déploiement en magasin :

• Tests de latence et mémoire validés sur hardware représentatif.
• Dégradation de précision mesurée et acceptable (delta MAPE chiffré).
• Artefact signé et procédure OTA testée.
• Plan de rollback documenté et testé.
• Monitoring en production (drift, erreurs de calibration) activé.
• Plan de réentraînement et triggers configurés.

Contrainte principale	Technique recommandée
Mémoire limitée	Pruning + Quantization int8 → TFLite (taille réduite ≈ 4×)
Latence critique	Quantization int8 + EdgeTPU / ONNX Runtime optimisé
Facilité d’intégration	ONNX Runtime si multi‑plateforme, sinon TFLite pour Android/iOS/embedded

Prêt à déployer un LSTM compressé en magasin ?

En combinant réduction d’architecture, pruning et quantification INT8 on obtient des modèles LSTM adaptés aux contraintes du retail edge : plus petits, moins chers à exécuter et souvent plus rapides, tout en gardant une précision opérationnelle. Le bon choix dépend de votre contrainte prioritaire (taille, latence, simplicité d’intégration). Tester sur matériel représentatif, automatiser la conversion et monitorer en production sont les étapes qui garantissent un déploiement fiable et rentable. Bénéfice pour vous : des prédictions locales plus rapides, moins coûteuses et exploitables à l’échelle des magasins.

FAQ

• Quel gain de taille puis-je attendre en moyenne ?
  Cela dépend des techniques : la quantification INT8 réduit typiquement la taille d’un modèle d’environ 4x; le pruning peut ajouter des réductions complémentaires selon la sparsité et le format de stockage. Des combinaisons pruning+quantization peuvent atteindre des réductions très importantes (exemples documentés en littérature).
• La quantification INT8 dégrade-t-elle la précision ?
  La quantification post-training peut causer une légère dégradation; la quantization-aware training (QAT) réduit cet impact et offre des résultats proches du modèle float. Il faut toujours valider sur vos séries pour mesurer l’effet réel sur la MAPE.
• Le pruning améliore-t-il toujours la latence sur CPU?
  Pas systématiquement. Le pruning non structuré réduit le nombre de poids mais nécessite un support sparse pour obtenir des gains réels en inférence. Le pruning structuré (ex : suppression de neurones ou filtres entiers) est plus susceptible d’améliorer la latence sur CPU/ARM.
• Faut-il réentraîner après compression ?
  Oui : pour pruning on réentraîne souvent (fine-tuning) pour retrouver de la précision. Pour QAT, on entraîne avec la quantification simulée. Même après post-training quantization, une validation sur données réelles est indispensable.
• Comment tester un modèle compressé sur le hardware cible ?
  Automatisez un workflow de conversion (ex : Keras → TFLite), déployez sur device farm ou sur un device représentatif, mesurez latence, mémoire live et consommation, et comparez la MAPE sur un échantillon réel. Intégrez ces tests dans votre CI/CD avant déploiement massif.

 

 

A propos de l’auteur

Franck Scandolera — expert & formateur en tracking server-side, analytics engineering, automatisation No/Low Code (n8n) et intégration IA en entreprise. Responsable de l’agence webAnalyste et de l’organisme de formation Formations Analytics. J’ai accompagné des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football et Texdecor sur sujets analytics et déploiement ML. Dispo pour aider votre entreprise => contactez moi.