Entraîner et servir des modèles sur SAP AI Core
À jour au 2026-09-25
Qu'est-ce que Entraîner et servir des modèles sur SAP AI Core ?
SAP AI Core exécute les modèles personnalisés, non génératifs, sous forme de deux types d'exécutables stockés dans git : les modèles de workflow (Argo Workflows) qui entraînent, et les modèles de service (KServe InferenceService) qui déploient. Les deux s'inscrivent dans le même vocabulaire scénario → exécutable → configuration → exécution/déploiement, mais les exécutables, scénarios et secrets de registre Docker sont partagés à l'échelle du tenant — les groupes de ressources n'isolent que les objets d'exécution construits à partir d'eux.
Deux workflows, un seul vocabulaire d'AI API
SAP AI Core (C026) exécute deux familles distinctes de travaux sur modèles personnalisés sur le même socle Kubernetes. L'entraînement et les pipelines par lots s'exécutent comme des Argo Workflows, un moteur de workflow open source, natif conteneur, implémenté comme une Custom Resource Definition (CRD) Kubernetes. Le service de modèle se déploie via KServe, avec la CRD InferenceService serving.kserve.io/v1beta1. Les deux sont empaquetés de la même façon pour l'AI API : en executables — des modèles réutilisables stockés et versionnés dans votre dépôt git, avec des emplacements réservés pour les artefacts d'entrée (jeux de données ou modèles) et des paramètres (paires clé-valeur personnalisées) qui permettent à un même modèle de s'exécuter dans différentes configurations. Cette fiche est le guide pratique de construction de cet empaquetage ; C026 est la carte du tenant qui l'héberge, et C363 couvre les groupes de ressources, scénarios et exécutables comme vocabulaire à part entière.
Pourquoi c'est important
- Un consultant qui ne connaît que le generative AI hub ne peut pas accompagner un client sur son propre modèle de détection de fraude ou de prévision de la demande — ce trafic passe par le chemin entraînement/service décrit ici, pas par l'orchestration.
- La distinction « les modèles sont partagés, les objets d'exécution sont isolés » explique toute une classe d'échecs de déploiement où un modèle construit dans un groupe de ressources fonctionne silencieusement dans tous les autres, alors que son déploiement en cours d'exécution, lui, non.
- La progression grossière au niveau du pod et le plafond de 730 heures de coût de base sont le genre de détail qui se transforme en escalade d'incident erronée ou en prévision de coût fausse si on n'a jamais observé le comportement brut de l'API.
Points clés
- Entraînement = `WorkflowTemplate` Argo ; service = `InferenceService` KServe enveloppée en modèle de service. Les deux sont empaquetés en `executables` pour l'AI API.
- La découverte repose sur des annotations (`scenarios.ai.sap.com/name`, `executables.ai.sap.com/name`, `artifacts.ai.sap.com/<name>.kind`) et des labels (`scenarios.ai.sap.com/id`, `ai.sap.com/version`, `ai.sap.com/instanceType`).
- Seul un artefact de sortie portant un `globalName` devient la sortie finale enregistrée du workflow.
- Démarrer un entraînement avec `POST $AI_API_URL/v2/lm/executions` ; la progression est normalisée sur N/100 et grossière au niveau du pod sans `ARGO_PROGRESS_FILE`.
- Les planifications d'entraînement ajoutent des horodatages de début/fin RFC3339 ; le statut est `ACTIVE` jusqu'à expiration, puis `INACTIVE`.
- KServe fige `STORAGE_URI` comme variable d'environnement de téléchargement du modèle et `/mnt/models` comme chemin de montage.
- Exécutables, scénarios et secrets de registre Docker sont à l'échelle du tenant ; les groupes de ressources n'isolent que configurations, exécutions, déploiements et artefacts.
- La facturation des modèles personnalisés (calcul + stockage + coût de base horaire, plafonné à 730 h/mois) est distincte de la facturation au jeton du generative AI hub (C128, C333). Limite : 50 modèles de workflow et 50 modèles de service par tenant.
Termes employés sur cette page
- Exécutable
- Un modèle réutilisable, stocké dans git (workflow ou service), avec des emplacements réservés pour artefacts d'entrée et paramètres, enregistré sous un scénario.
- Scénario
- Un regroupement nommé d'exécutables apparentés, découvrable via GET .../v2/lm/scenarios.
- Configuration
- Un exécutable lié à des artefacts d'entrée et des valeurs de paramètres concrets, prêt à s'exécuter.
- Exécution
- Un lancement d'une configuration — une tâche d'entraînement ou par lots en cours ou terminée.
- Déploiement
- Un point de terminaison d'inférence en cours d'exécution, créé en exécutant une configuration de modèle de service.
- globalName
- Le label sur l'artefact de sortie d'un workflow qui le fait s'enregistrer comme artefact de sortie final de l'exécutable.
- InferenceService
- La ressource personnalisée KServe que le spec d'un modèle de service enveloppe pour définir un serveur de modèle.
Sources
- SAP AI Core docs (SAP-docs GitHub, Sep 2026) — Workflow Templates (Argo WorkflowTemplate, annotations, generic template YAML)
- SAP AI Core docs — Serving Templates (KServe mapping, generic serving template YAML, 50-template limit)
- SAP AI Core docs — Start Training (POST /v2/lm/executions, N/100 progress, ARGO_PROGRESS_FILE)
- SAP AI Core docs — Training Schedules (RFC3339 start/end, ACTIVE/INACTIVE)
- SAP AI Core docs — List Executables (executable definition, GET /v2/lm/scenarios)
- SAP AI Core docs — KServe Spec serving.kserve.io/v1beta1 (InferenceService, PredictorSpec)
- SAP AI Core docs — Resource Groups (tenant-wide scenarios/executables/Docker secrets vs resource-group scope)
- SAP AI Core docs — Metering and Pricing for SAP AI Core (baseline hourly charge, 730 h/month cap)
Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · les pièges courants et leur correctif · l'aide-mémoire · les blocs de code · les chiffres à citer.