Des expériences comparables
Paramètres, métriques et artefacts de chaque run, reliés au job ou au notebook qui les a produits. Vous comparez, vous retenez.
← Vue d’ensemble
Machine learning
Du premier entraînement au modèle servi
Chaque entraînement laisse sa trace : paramètres, métriques, artefacts et code. La version retenue entre au registre, puis devient un point d’accès REST derrière votre SSO, dont la dérive est surveillée. Vos data scientists gardent leur client MLflow.
Capacités clés
Tout le cycle de vie d’un modèle
Un registre de modèles versionné
Chaque version garde son origine : l’expérience, le code et les données d’entraînement. Les étapes de validation se lisent au même endroit.
Compatible avec le client MLflow
Vos scripts existants enregistrent leurs runs et leurs modèles dans graal sans changer une ligne, par l’API MLflow.
Le serving REST
Une version du registre devient un point d’accès REST, sur le nombre de répliques voulu, derrière votre SSO ou un jeton de service.
Le suivi de la dérive
Un échantillon des requêtes est conservé, puis comparé aux données d’entraînement par un job planifié. Une dérive déclenche une alerte.
Des GPU à la demande
Entraînement et inférence sur les GPU de votre cluster, réservés run par run et bornés par les quotas du projet.
Comment ça marche
Du notebook au point d’accès
Étape 01
Entraîner
Dans un notebook ou un job, votre code trace ses runs dans une expérience, par le client MLflow.
Étape 02
Enregistrer
Vous promouvez le meilleur run au registre. La mise en production peut exiger la validation d’un second responsable.
Étape 03
Servir et surveiller
La version devient un point d’accès REST ; la dérive est mesurée à intervalle régulier et vous alerte.
Un modèle servi est un run qui ne s’arrête pas
Un point d’accès est un déploiement que graal gère comme le reste : ses conteneurs tournent sans privilèges, ses règles réseau sont posées avant eux, et chaque appel passe par un contrôle d’authentification. Le modèle est chargé depuis le registre au démarrage : ce qui est servi est exactement la version enregistrée.
Le règlement européen sur l’intelligence artificielle, (UE) 2024/1689, exige que les systèmes d’IA à haut risque permettent l’enregistrement automatique des événements tout au long de leur cycle de vie (article 12). graal vous aide à tracer et à documenter : runs, versions, données d’entraînement et déploiements.
Standards et intégrations
Des interfaces que vous connaissez
- MLflow
- Python
- XGBoost
- PyTorch
- REST
- MLServer
- GPU
Gouvernance
Chaque modèle a un responsable
- Droits par projet sur les expériences, le registre et les points d’accès
- Chaque version et chaque déploiement sont attribués à une personne ou à un agent
- Les points d’accès n’acceptent que des appels authentifiés
Questions fréquentes
Faut-il changer nos scripts MLflow ?
Non. Vous pointez le client MLflow vers graal ; vos appels de suivi et d’enregistrement de modèles fonctionnent tels quels.
Où sont stockés les modèles ?
Dans votre stockage compatible S3, avec leurs artefacts. Rien ne sort de votre infrastructure.
Qui peut appeler un modèle servi ?
Les personnes et les applications autorisées sur le projet, par votre SSO ou par un jeton de service révocable.
Suivez un modèle jusqu’à la production
Une expérience, une version au registre, un point d’accès : en démonstration sur le scénario énergie.