Entraîner et servir des modèles sur SAP AI Core

Deux workflows, un seul vocabulaire d'AI API

SAP AI Core 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 page est le guide pratique de construction de cet empaquetage ; « SAP AI Core » est la carte du tenant qui l'héberge, et « SAP AI Core : resource groups, scenarios et executables » 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. 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

1. SAP AI Core docs (SAP-docs GitHub, Sep 2026) — Workflow Templates (Argo WorkflowTemplate, annotations, generic template YAML)
2. SAP AI Core docs — Serving Templates (KServe mapping, generic serving template YAML, 50-template limit)
3. SAP AI Core docs — Start Training (POST /v2/lm/executions, N/100 progress, ARGO_PROGRESS_FILE)
4. SAP AI Core docs — Training Schedules (RFC3339 start/end, ACTIVE/INACTIVE)
5. SAP AI Core docs — List Executables (executable definition, GET /v2/lm/scenarios)
6. SAP AI Core docs — KServe Spec serving.kserve.io/v1beta1 (InferenceService, PredictorSpec)
7. SAP AI Core docs — Resource Groups (tenant-wide scenarios/executables/Docker secrets vs resource-group scope)
8. SAP AI Core docs — Metering and Pricing for SAP AI Core (baseline hourly charge, 730 h/month cap)
9. GitHub SAP-docs — Choose an instance (instance types vs. resource plans, SAP-authored mirror)
10. GitHub SAP-docs — Register your Docker registry secret (SAP-authored mirror)
11. GitHub SAP-docs — Template synchronization / GitOps CI-CD for AI Core executables (SAP-authored mirror)
12. Argo Workflows — official documentation (WorkflowTemplate CRD, the open-source primary source SAP builds on)
13. Argo Workflows — Timeouts walk-through (activeDeadlineSeconds, open-source primary source)
14. SAP Support Launchpad — SAP Note 3660109, available SAP AI Core instance types
15. SAP TechEd 2026 (Berlin & virtual, 27–29 Oct 2026) — session DA105: Enriching AI models with SAP AI Core in SAP Business Data Cloud
16. SAP — What's New for SAP AI Core (SAP-RPT-TS and SAP-RPT-Decisions, 22 Oct 2026)