Comment utiliser des conteneurs custom dans SageMaker pour l'inference avec LightGBM (guide pas a pas)

Quand on travaille avec des modeles de machine learning en production, on se concentre souvent sur le fait de servir des predictions en temps reel. Mais que se passe-t-il quand on doit traiter de gros volumes de donnees de facon offline ? Dans ces cas-la, on utilise l’inference en batch.

Dans le cloud AWS, le service concu pour ce type d’operations est SageMaker Batch Transform, une solution qui permet d’appliquer des modeles sur des datasets entiers, sans avoir besoin de monter un endpoint d’inference.

Or, Amazon SageMaker supporte nativement plusieurs frameworks comme XGBoost, TensorFlow ou PyTorch, mais des modeles comme LightGBM (un modele assez courant dans la discipline) ne figurent pas parmi les conteneurs preconstruits d’AWS. C’est pourquoi, si on veut l’utiliser pour de l’inference batch, il faut construire notre propre conteneur.

Expliquer la methode pour y arriver est l’objectif de ce tutoriel. Dans ce guide pas a pas, on va montrer comment :

• Preparer un code local pour predire avec un modele LightGBM.
• L’empaqueter dans une image Docker compatible avec SageMaker.
• Pousser cette image sur Amazon ECR et utiliser Batch Transform pour executer l’inference sur des fichiers stockes dans S3.

Le tout sans magie, avec des explications claires pour que vous puissiez l’adapter a vos propres projets.

Qu’est-ce qu’AWS SageMaker AI ?

Amazon SageMaker est une plateforme integrale de machine learning (ML) sur AWS qui simplifie et accelere le workflow pour les data scientists et les professionnels MLOps. Elle abstrait la complexite de l’infrastructure, permettant de se concentrer sur le deploiement d’operations IA plutot que sur la gestion des ressources.

Elle couvre chaque etape du cycle de vie d’un modele de machine learning, de la preparation des donnees avec integration aux services AWS comme S3 et Glue, jusqu’a l’entrainement flexible et scalable avec des frameworks populaires (TensorFlow, PyTorch, etc.) sur des instances CPU/GPU gerees automatiquement. Elle offre l’entrainement distribue, l’optimisation des hyperparametres et la gestion d’experiences.

Elle facilite le deploiement en production avec du hosting en temps reel pour la faible latence et du traitement batch pour les gros datasets. De plus, elle fournit un monitoring continu pour detecter des problemes comme la derive des donnees et la degradation des performances.

SageMaker inclut des outils integres comme des notebooks bases sur Jupyter et SageMaker Pipelines pour automatiser et orchestrer les workflows, ameliorant la productivite.

Qu’est-ce que SageMaker Batch Transform et en quoi ca differe de l’inference en temps reel ?

Quand on met un modele en production, il y a deux facons principales de servir des predictions : l’inference en temps reel ou l’inference batch.

• L’inference en temps reel implique d’exposer le modele via un endpoint HTTPS (comme une API). Chaque fois qu’une requete arrive, SageMaker traite les donnees et renvoie une prediction instantanee. Cette approche est ideale pour les applications interactives, comme les systemes de recommandation ou la detection de fraude en temps reel, ou la latence est critique.

• D’un autre cote, SageMaker Batch Transform est concu pour les scenarios ou on n’a pas besoin de reponses immediates, mais d’appliquer le modele a de gros volumes de donnees de facon massive et offline. Au lieu d’envoyer des enregistrements un par un, Batch Transform prend des fichiers entiers depuis S3 (par exemple, un CSV avec des milliers ou millions de lignes), execute les predictions en parallele et stocke les resultats egalement dans S3. Pas besoin de laisser un endpoint actif ni de se soucier de la disponibilite du modele.

En resumant tout ca dans un tableau simple :

Caracteristique	Inference en Temps Reel	Batch Transform
Latence	Faible	Elevee (traitement par lots)
Couts	Continus (endpoint actif)	A l’usage (selon le job execute)
Ideal pour	APIs, applications en live	Jobs periodiques ou massifs
Input/Output	JSON par requete	Fichiers dans S3

Au boulot !

C’est un tutoriel un peu plus intermediaire, mais pas de panique, on ne va pas vous lacher en route. On va aussi vous laisser quelques liens au cas ou il y aurait des sujets a revoir.

Tout le code necessaire pour suivre le tutoriel se trouve dans le repo par ici.

Prerequis

Avant de plonger dans ce tutoriel, il est preferable d’avoir :

• Des connaissances en Python et AWS. Des connaissances sur les environnements virtuels Python.
• Des connaissances de base en execution de scripts Bash.
• Des connaissances de base en Machine Learning, notamment en classification avec des modeles d’ensemble d’arbres de decision.
• Des connaissances de base en Docker : on va creer une image personnalisee pour executer notre modele.

Ressources necessaires

• Un compte AWS avec les permissions pour utiliser SageMaker et ECR (il peut y avoir un cout associe de 1 ou 2 USD, principalement pour les images Docker stockees dans AWS ECR)
• Installation locale de Docker
• Installation locale de Python
• Installation locale de Poetry
• Installation locale de aws cli
• Installation locale de VSCode (optionnel)

Environnement Python

On installe les dependances dans un environnement Poetry. En ouvrant un terminal dans le repertoire de travail qu’on va utiliser pour ce tutoriel, on utilise les commandes :

poetry init
poetry add numpy lightgbm scikit-learn pandas kagglehub

Pour travailler avec des jupyter notebooks dans VSCode, il faudra aussi installer le package ipykernel. VSCode proposera de le faire la premiere fois qu’on lancera le notebook.

Une autre option est de prendre le project.toml du depot, le coller dans notre repertoire de travail, et executer poetry install dans le shell. Ca creera l’environnement avec les dependances necessaires automatiquement.

Preparation du dataset

• On choisit le dataset. Dans notre cas, fraud detection dataset. On peut le telecharger en installant kagglehub dans notre environnement Python local.

• C’est un dataset pour un probleme de classification, ou il s’agit de predire, a partir de features issues d’une PCA, plus une variable temporelle et le montant de transaction, si la transaction etait frauduleuse ou non.

• On telecharge le dataset localement, on s’assure de separer les features du target et a partir de la, on fait le split train et test, et on sauvegarde les deux datasets en format csv.

• Tout cela est realise dans le notebook dataset/prepare_data.ipynb.

Etape 1 : Code local pour l’inference avec LightGBM

1.1 Entrainer le modele

Le point de depart est un notebook qui fait le training et le testing (sagemaker-batch-transform-tutorial/local_code/01_train_and_test.ipynb). Ce notebook charge simplement le dataset, fait le split en train data et test data, entraine le modele et sauvegarde le modele entraine.

Mais on a besoin de le separer en deux parties : le script d’entrainement et celui de test. De cette facon, on sauvegarde le modele a part, et on peut commencer a parametrer les chemins des datasets et du modele.

Le script d’entrainement charge les donnees d’entrainement, separe les features et le target du modele, definit et entraine le modele, et sauvegarde localement le modele entraine dans un fichier pickle dans le dossier specifie.

Le script de test charge les donnees de test, separe les features et le target du modele, charge le modele deja entraine, effectue les predictions et affiche la precision du modele.

Les scripts locaux sont la base fonctionnelle (rapide a iterer et deboguer). A l’Etape 2, on va les adapter pour qu’ils prennent les donnees/modele depuis S3 et tournent dans un conteneur Docker compatible avec SageMaker, pour passer de “test local” a des jobs reproductibles (Training/Batch Transform) sans reecrire la logique. Voyons comment :

Etape 2 : Creer un conteneur Docker pour l’inference avec LightGBM

Dans cette section, on prend les scripts developpes precedemment, on les parametrise pour qu’ils prennent les chemins des fichiers depuis S3, et on construit les dockerfile et les scripts qui seront les entrypoints pour train et test.

On a la structure de dossiers suivante :

• On cree des dossiers pour train, test et models. Le dossier “dataset” restera plus haut.
• Il faut uploader les fichiers CSV utilises pour l’entrainement et le test vers S3. Il faut creer un bucket et remplacer le nom la ou c’est necessaire : tout au long du tutoriel vous le verrez comme <bucket-propio>. A l’interieur, un dossier datasets, et des dossiers train_data et test_data, ou on uploade les fichiers csv generes.
• La structure doit ressembler a : s3://<bucket-propio>/datasets/train_data/train.csv

2.1 Construire l’image

Depuis le repertoire containers, on execute la commande pour construire l’image, selon les instructions du Dockerfile (c’est tres standard, rien d’inhabituel).

docker build -t lightgbm-train ./train

Pour l’executer, on prepare un script shell qui charge les access keys AWS et passe en parametres les adresses S3 necessaires pour obtenir les donnees et sauvegarder le modele.

Maintenant vient la partie amusante. Ce script est concu pour s’executer a l’interieur d’un conteneur dans SageMaker : il prend les donnees d’entrainement depuis S3, entraine le modele LightGBM et uploade le resultat de nouveau vers S3. C’est ni plus ni moins la base pour pouvoir l’integrer dans un SageMaker Training Job reproductible.

Pour lancer l’entrainement, on execute simplement le script shell d’entrainement :

$./train.sh

2.2. Executer l’inference

Pour lancer le conteneur d’inference, on prepare un script shell qui charge les access keys AWS configurees localement, et passe en parametre l’adresse S3 necessaire pour obtenir le modele.

Avec ca en place, on peut build l’image avec :

docker build -t lightgbm-test ./test

Et que contient le script de test ?

Ce qu’il fait :

• Telecharge le dataset de test et le modele entraine depuis S3.
• Charge les deux en memoire.
• Execute les predictions avec predict_proba() de LightGBM.
• Affiche les probabilites de la classe positive.

Etape 3 : Pousser les images vers ECR et executer dans SageMaker

En resume, dans cette section on verra :

• Comment construire des conteneurs pour entrainer notre modele avec un SageMaker Training Job,
• Comment l’enregistrer dans le SageMaker Model Registry,
• Comment l’utiliser pour faire de l’inference en Batch sur des donnees dans S3.

Pour les Jobs d’entrainement et d’inference, on fera de petits ajustements sur nos conteneurs, et pour declencher les jobs et enregistrer les modeles, on utilisera des fonctions Lambda. Mais d’abord on doit etre authentifie avec notre compte AWS et avoir l’AWS CLI installe et configure.

De facon graphique, les etapes a realiser pour developper l’entrainement avec un SageMaker Training Job et l’inference avec un SageMaker Batch Transform Job sont decrites dans les figures suivantes :

3.1. Login a ECR et creation des repos

La premiere etape est de creer le repo, ce qu’on ne fait qu’une seule fois. Ici aussi il faudra remplacer certains caracteres et IDs par ceux de votre compte :

aws ecr create-repository --repository-name lightgbm-testing-container

Conservez l’URI renvoye par la commande, qu’on va appeler <repo-uri> a partir de maintenant. Ca devrait ressembler a :

`<id-de-nuestra-cuenta>`.dkr.ecr.us-east-2.amazonaws.com/lightgbm-testing-container

Maintenant on se connecte avec Docker :

aws ecr get-login-password | docker login --username AWS --password-stdin `<id-de-nuestra-cuenta>`.dkr.ecr.`<region>`.amazonaws.com

3.2. Build & Push

On se place dans le dossier containers_sagemaker/ et depuis la on execute :

docker build -t lightgbm-test-sm ./test

Avec ca fait, on tag et on push l’image :

docker tag lightgbm-test-sm:latest <repo-uri>
docker push <repo-uri>

3.3. Heberger les donnees

Enfin, il faut deposer les donnees dans un bucket S3, idealement dans un chemin de ce style :

s3://<bucket-propio>/datasets/train_data/train.csv

3.4. Fonction Lambda : Training Job

Maintenant on va utiliser une Lambda pour declencher le job d’entrainement.

Important : il faut avoir un role IAM avec la capacite d’acceder et d’executer sur S3 et SageMaker. Pour l’exemple, on en a cree un appele free-tier-sagemaker-full-access-role avec les politiques AmazonS3FullAccess et SagemakerFullAccess.

Maintenant il faut creer la Lambda lgbm_sm_launch_training_job. Cette Lambda a une layer SageMaker (voici un article de chez nous ou on explique aussi comment les utiliser, au cas ou), donc il faut installer les requirements localement et creer un package qui sera uploade avec la fonction. Comme le package pese plus de 50 Mo a la creation, il faut l’uploader dans un emplacement S3 et le charger dans le service Lambda depuis S3.

Un detail important du requirements.txt de cette Lambda : on a besoin de la version sagemaker==2.215, sinon on obtiendra l’erreur : “No module named ‘rpds.rpds’”. Ce genre d’erreurs et avertissements est tres courant quand on installe des packages de differentes sources.

Remarquez comment on installe les dependances : le -t package/ a la fin fait en sorte qu’au lieu d’installer les bibliotheques dans l’environnement global ou virtuel (site-packages), elles sont installees dans le dossier local package/. C’est courant dans des projets comme celui-ci, ou on a besoin d’empaqueter les dependances avec notre code (comme c’est souvent necessaire dans une Lambda).

Pour que la fonction puisse utiliser les dependances empaquetees, il faut les associer comme Lambda Layer. Ca se fait depuis la console AWS Lambda, dans l’onglet Layers, en creant une nouvelle layer et en y uploadant le fichier lambda_package.zip (ou en indiquant l’emplacement dans S3).

Une fois creee, la layer est disponible et on peut l’attacher a notre fonction lgbm_sm_launch_training_job depuis la meme console ou via AWS CLI. De cette facon, la Lambda aura acces aux bibliotheques necessaires (dans ce cas, sagemaker==2.215) sans depasser la limite de taille du deployment package.

Un autre detail important est de faire correspondre la version de Python de la Lambda locale avec la version de Python definie a la creation de la Lambda dans la console (UI) d’AWS.

Apres l’execution reussie de la Lambda, on pourra voir que un SageMaker Training Job a ete declenche, et une fois termine, notre modele fraichement entraine sera stocke dans le repertoire specifie dans la Lambda (dans notre cas, s3://<bucket-propio>/models_sm/).

3.5. Fonction Lambda pour enregistrer le modele

Ici on cherche a enregistrer le modele dans le SageMaker Model Registry, pour lier l’image Docker hebergee dans ECR avec l’ARN du modele entraine via le SageMaker Training Job. Ainsi, par la suite, en invoquant l’image, le modele deja specifie sera utilise.

Le point central est l’appel a create_model pour enregistrer un nouveau SageMaker Model, en liant :

• Le conteneur d’inference (image Docker dans ECR).
• L’artefact entraine (modele dans S3).
• Le role IAM qui autorise l’execution.

Avec ca, le modele est enregistre dans SageMaker et disponible pour etre utilise dans des endpoints ou des Batch Transform Jobs.

3.6. Fonction Lambda pour lancer le Batch Transform Job

Dans ce cas, on va creer un transformer qui recevra comme parametre principal le nom du modele tel qu’il a ete enregistre dans le SageMaker Model Registry a l’etape precedente. Notez qu’on ne fait reference a aucune autre donnee ou emplacement du modele entraine : tout sera obtenu depuis le Registry de SageMaker.

Le Batch Transform Job sera cree en utilisant la methode transform() du Transformer. Cette methode permet de specifier quelles colonnes du dataset d’entree seront envoyees au modele pour l’inference, et comment sera compose le fichier de predictions : on peut choisir de livrer uniquement les predictions, ou d’incorporer aussi les features utilisees pour l’inference, et la colonne d’ID qui identifie chaque enregistrement d’entree (si elle existe).

Apres le job, les resultats seront dans notre bucket S3. Si on le souhaite, en suivant la nomenclature du bucket utilise, on peut les telecharger avec :

aws s3 cp s3://<bucket-propio>/predictions/test.csv.out .

En conclusion…

On a cree une solution personnalisee et scalable pour faire de l’inference batch avec des modeles LightGBM dans SageMaker. Cette architecture permet de reutiliser des modeles entraines et de maintenir des pipelines reproductibles dans un environnement MLOps professionnel.

Dans les prochains volets, on pourra voir des operations complementaires a l’inference elle-meme, necessaires pour obtenir un modele productif robuste.

Des questions ou des suggestions ? Vous pouvez écrire à fernando@deployr.ai ou laisser un commentaire sur le blog.

---

References supplementaires :

1. Fraud detection dataset
2. Batch transform for inference with Amazon SageMaker AI
3. Exemple : Customer Churn Prediction with XGBoost
4. Batch Transform Input and Output Filters
5. Tabular classification with Amazon SageMaker LightGBM and CatBoost algorithm
6. SageMaker Batch Transform – Emily Webber from AWS
7. Conteneurs pour Batch transform et pour inference
8. Amazon – Adapt your own inference container
9. SageMaker – Bring your own container