SAP AI Core — Modelltraining und Serving für eigene Modelle
Stand 2026-09-25
Die Trainings- und Serving-Fähigkeit von SAP AI Core ist sprachagnostisch und unabhängig vom Generative AI Hub: jedes ML-Framework, containerisiert, als Argo-Workflows-Execution ausgeführt, mit Output-Artifacts, die über ein KServe-gestütztes Deployment serviert werden. Dieses Modul folgt SAPs eigenem Service Guide, um den Trainings-Workflow Schritt für Schritt durchzugehen (Instanz, Template, Scenario, Configuration, Execution, Logs), das obligatorische default-Object-Store-Secret, ohne das keine Trainings-Pipeline eine Ausgabe schreiben kann, die drei Muster, ein Modell auf den Tenant zu bringen (von null trainieren, feinabstimmen oder fortsetzen, ein vortrainiertes Artifact verpacken), das KServe-InferenceService-Spec eines Serving Templates mit seinen Skalierungsparametern, und die Effizienzfunktionen, die einen dauerhaft verfügbaren Endpunkt bezahlbar halten. Es schließt mit Artifact-Signaturen und Training Schedules für auditierbares, automatisiertes Nachtraining sowie einem Triage-Leitfaden, der die drei häufigsten Fehlerbilder ihrem jeweiligen Wurzelobjekt zuordnet. Drei Übungen und eine Selbsttest bedingen den Übergang zu M364.
Was Sie lernen
- Erklären, warum Training auf SAP AI Core eine Argo-basierte Workflow-Execution ist, kein verwalteter „Trainieren“-Knopf, und was ein sprachagnostischer Trainingsvertrag von einem Data-Science-Team verlangt
- Einen Trainings-Workflow von Anfang bis Ende durchgehen — Instanz wählen, Template definieren, Scenarios auflisten, Configurations anlegen, Training starten, Logs abrufen — und das Objekt benennen, das jeder Schritt erzeugt
- Zwischen Training von null, Feinabstimmung oder Fortsetzen eines importierten Modells und dem Verpacken eines bereits trainierten Modells nur zum Servieren wählen, für einen genannten Kundenbedarf
- Das KServe-InferenceService-Spec eines Serving Templates konfigurieren — Predictor, STORAGE_URI, minReplicas, maxReplicas, containerConcurrency — für ein reales Traffic-Muster
- Artifact-Signaturen und Training Schedules nutzen, um wiederholte Trainingsläufe auditierbar und automatisiertes Nachtraining sicher zu machen
- Die drei häufigsten Training-und-Serving-Fehlerbilder allein aus dem Symptom diagnostizieren: fehlender globalName, fehlendes default-Object-Store-Secret, defekte Registry- oder Artifact-Referenz
Für wen dieses Modul gedacht ist. M362 hat Ihnen das Objektmodell von SAP AI Core und seine Resource-Group-Grenzen vermittelt. Dieses Modul setzt beides für genau den Fall ein, für den dieses Modell gebaut wurde: ein Kunde, dessen Bedarf nicht "ein LLM über die Orchestration aufrufen" lautet, sondern "unser eigenes Modell auf unseren eigenen Daten trainieren und als Produktivendpunkt bereitstellen" — ein Betrugsscore, eine Lieferrisiko-Vorhersage, eine Nachfrageprognose oder ein feinabgestimmtes Modell, das kein Hyperscaler-Katalog abdeckt. Das ist die eigene Trainings- und Serving-Fähigkeit von SAP AI Core, sprachunabhängig und unabhängig vom Generative AI Hub — und hier hört ein Data-Science-Hintergrund auf, optional zu sein.
1. Training ist eine Workflow-Execution, kein Knopf
Es gibt keinen "Trainieren"-Knopf in SAP AI Core. Training ist eine Execution — eine Instanz eines nicht deploybaren Executables, ausgeführt über die in M362 behandelte Argo-Workflows-Engine. SAP ist eindeutig: AI Core ist "sprachagnostisch für Modelltraining-Code" — Sie schreiben Ihr Trainingsskript in der Sprache und dem Framework Ihrer Wahl, containerisieren es, und lassen AI Core den Lauf orchestrieren; die Plattform erzwingt weder scikit-learn noch PyTorch noch eine andere Bibliothek. Was AI Core vorgibt, ist der Workflow-Vertrag um Ihren Code herum:
Voraussetzungen
- M362 (SAP AI Core — Resource Groups, Scenarios, Executables) — dieses Modul baut direkt auf dessen Objektmodell auf
- Praktisches Wissen zu mindestens einem ML-Framework (scikit-learn, PyTorch oder ähnlich) und Sicherheit im Schreiben eines Dockerfiles
- Optional für die praktische Arbeit: ein SAP-AI-Core-Trial-Tenant mit registriertem Git-Repository und Docker-Registry-Secret
Lernergebnisse
- Eine vollständige Trainings-zu-Serving-Pipeline für ein individuelles Modell auf SAP AI Core aufbauen, vom Workflow Template bis zum produktiven Inferenz-Endpunkt
- Das richtige Onboarding-Muster (von null trainieren, feinabstimmen, nur servieren) für ein genanntes Kundenmodell wählen und begründen
- Die Skalierungsparameter eines Deployments gegen ein festgelegtes Traffic-Profil dimensionieren und den Kosten-/Latenz-Kompromiss verteidigen
- Ein defektes Trainings- oder Serving-Setup allein aus dem Symptom auf sein Wurzelobjekt (Artifact, Secret, Registry, Kontingent) zurückführen
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.