Modelle auf SAP AI Core trainieren und bereitstellen

Zwei Workflows, ein AI-API-Vokabular

SAP AI Core betreibt zwei getrennte Arten von Arbeit mit eigenen Modellen auf derselben Kubernetes-Basis. Training und Batch-Pipelines laufen als Argo Workflows, eine Open-Source-Workflow-Engine, container-nativ, implementiert als Kubernetes Custom Resource Definition (CRD). Modell-Serving läuft über KServe, mit der CRD InferenceService serving.kserve.io/v1beta1. Beide werden für die AI API gleich verpackt: als executables — wiederverwendbare, in Ihrem Git-Repository gespeicherte und versionierte Templates mit Platzhaltern für Eingabeartefakte (Datensätze oder Modelle) und Parameter (eigene Schlüssel-Wert-Paare), die es erlauben, ein Template in unterschiedlichen Konfigurationen laufen zu lassen. Diese Seite ist der praktische Bauplan für diese Verpackung; „SAP AI Core“ ist diese Seite des Mandanten, der sie hostet, und „SAP AI Core: Resource Groups, Szenarien und Executables“ behandelt Resource Groups, Szenarien und Executables als eigenes Vokabular.

Warum es zählt

• Ein Berater, der nur den Generative AI Hub kennt, kann einen Kunden bei einem eigenen Betrugserkennungs- oder Nachfrageprognosemodell nicht unterstützen — dieser Verkehr läuft über den hier beschriebenen Trainings-/Serving-Pfad, nicht über die Orchestrierung.
• Die Trennung „Templates sind geteilt, Laufzeitobjekte sind isoliert“ erklärt eine ganze Klasse von Deployment-Fehlern, bei denen ein in einer Resource Group gebautes Template stillschweigend in jeder anderen funktioniert, sein laufendes Deployment jedoch nicht.
• Der grobe Fortschritt auf Pod-Ebene und die Obergrenze von 730 Stunden für die Grundgebühr sind genau die Art Detail, die zu einer falschen Incident-Eskalation oder einer falschen Kostenprognose führt, wenn man das rohe API-Verhalten nie gesehen hat.

Kernpunkte

• Training = Argo-`WorkflowTemplate`; Serving = KServe-`InferenceService`, verpackt als Serving-Template. Beide werden für die AI API als `executables` verpackt.
• Die Erkennung stützt sich auf Annotationen (`scenarios.ai.sap.com/name`, `executables.ai.sap.com/name`, `artifacts.ai.sap.com/<name>.kind`) und Labels (`scenarios.ai.sap.com/id`, `ai.sap.com/version`, `ai.sap.com/instanceType`).
• Nur ein Ausgabeartefakt mit `globalName` wird zur registrierten finalen Ausgabe des Workflows.
• Trainingslauf starten mit `POST $AI_API_URL/v2/lm/executions`; Fortschritt ist auf N/100 normiert und auf Pod-Ebene grob, sofern keine `ARGO_PROGRESS_FILE` implementiert ist.
• Trainingszeitpläne fügen Start-/End-Zeitstempel im RFC3339-Format hinzu; Status ist bis zum Ablauf `ACTIVE`, danach `INACTIVE`.
• KServe legt `STORAGE_URI` als Umgebungsvariable für den Modell-Download und `/mnt/models` als Mount-Pfad fest.
• Executables, Szenarien und Docker-Registry-Secrets gelten mandantenweit; Resource Groups isolieren nur Konfigurationen, Ausführungen, Deployments und Artefakte.
• Die Abrechnung eigener Modelle (Rechenleistung + Speicher + stündliche Grundgebühr, gedeckelt auf 730 h/Monat) ist getrennt von der tokenbasierten Abrechnung des Generative AI Hub. Grenze: 50 Workflow-Templates und 50 Serving-Templates pro Mandant.

Begriffe auf dieser Seite

Executable

Ein wiederverwendbares, in Git gespeichertes Template (Workflow oder Serving) mit Platzhaltern für Eingabeartefakte und Parameter, registriert unter einem Szenario.

Szenario

Eine benannte Gruppierung zusammengehöriger Executables, auffindbar über GET .../v2/lm/scenarios.

Konfiguration

Ein Executable, gebunden an konkrete Eingabeartefakte und Parameterwerte, bereit zur Ausführung.

Ausführung

Ein Lauf einer Konfiguration — ein Trainings- oder Batch-Job, laufend oder abgeschlossen.

Deployment

Ein laufender Inferenz-Endpunkt, erzeugt durch Ausführen einer Serving-Template-Konfiguration.

globalName

Das Label am Ausgabeartefakt eines Workflows, das es als finales Ausgabeartefakt des Executables registriert.

InferenceService

Die KServe-Custom-Resource, die das Spec eines Serving-Templates umschließt, um einen Modellserver zu definieren.

Quellen

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)