Modelle auf SAP AI Core trainieren und bereitstellen
Stand 2026-09-25
Was ist Modelle auf SAP AI Core trainieren und bereitstellen?
SAP AI Core betreibt eigene, nicht-generative Modelle als zwei Arten von in Git gespeicherten Executables: Workflow-Templates (Argo Workflows), die trainieren, und Serving-Templates (KServe InferenceService), die bereitstellen. Beide fügen sich in dasselbe Vokabular Szenario → Executable → Konfiguration → Ausführung/Deployment ein, doch Executables, Szenarien und Docker-Registry-Secrets werden mandantenweit geteilt — Resource Groups isolieren nur die daraus gebauten Laufzeitobjekte.
Zwei Workflows, ein AI-API-Vokabular
SAP AI Core (C026) 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 Karte ist der praktische Bauplan für diese Verpackung; C026 ist die Karte des Mandanten, der sie hostet, und C363 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 (C128, C333). 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
- 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)
Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Codeblöcke · die zitierfähigen Kennzahlen.