Bring your own Hugging Face Transformers in SAP AI Foundation

[Marla-Schweiki]

🌟Introduction

At SAP TechEd 2025, I demonstrated how to operationalize Hugging Face Transformer models in SAP AI Foundation using the Bring Your Own Model (BYOM) approach.

The goal was to show how I can move beyond consuming pre-hosted APIs and instead own the full model lifecycle – from training to serving inside SAP BTP.

My showcase focused on blocked invoice classification in SAP S/4HANA, a common process bottleneck.

Using BYOM, I trained and deployed a custom NLP model that predicts why an invoice was blocked, helping finance teams accelerate processing and reduce manual work.

🔍Why BYOM Matters

BYOM enables organizations and developers to:

• Train, deploy, and govern their own models rather than relying on third-party APIs.
• Maintain full control of data, model weights, and compliance.
• Reuse open-source innovation (such as Hugging Face Transformers) within the secure boundaries of SAP BTP.
• Adapt models continuously to evolving business data without vendor lock-in.

This approach contrasts with SAP’s Generative AI Hub, where models are pre-hosted by SAP or partners and accessed via API only.

With BYOM, I define the model architecture, container image, and YAML-based orchestration.

SAP AI Core executes these workflows securely, while AI Launchpad provides lifecycle management, logging, and governance.

🧠 Use Case: Blocked Invoice Classification

Invoices in SAP S/4HANA can be blocked for reasons such as mismatched quantities, missing purchase orders, or pricing errors.

To automate this review, I fine-tuned a DeBERTa-v3-base model from Hugging Face on labeled invoice text.

Label map:

Label Category

0	Price Variance
1	Quantity Mismatch
2	Missing PO Reference
3	Three-Way Match Failure
4	Supplier Issues

⚙️BYOM Architecture in SAP AI Foundation

The BYOM setup in SAP AI Core uses modular components that I can fully customize and version-control.

This architecture allows me to deploy, retrain, and scale models independently while maintaining full ownership of data and artifacts.

🧩 End-to-End BYOM Flow

Below is a visual representation of the Bring Your Own Model workflow that connects all components:

This diagram illustrates how:

• The GitHub repository stores YAML templates (training-template.yaml, serving-template.yaml) and runtime configurations that sync with AI Core.
• AI Core executes deployments using Docker images stored in the Docker Registry.
• The KServe InferenceService (FastAPI) runs inside AI Core and is consumed by CAP or Fiori applications.
• SAP AI Launchpad provides a single interface for monitoring, versioning, and managing deployments.

🧭 Preparing SAP AI Core for BYOM

Before deploying the model, I performed several key setup steps to prepare SAP AI Core and AI Launchpad for BYOM:

1. Create AI Core and AI Launchpad Instances – provisioned both services on SAP BTP for orchestration and lifecycle management.
2. Create a Resource Group – isolated compute and storage resources for this project.
3. Set Up Docker Registry Connection – linked my private registry and created a secret (docker-registry-secret).
4. Onboard the GitHub Repository – connected the repo to AI Core so YAML templates stay in sync with AI Launchpad.
5. Register Datasets and Model Artifacts – uploaded CSVs and defined output artifact paths.
6. Create API Client – generated credentials for pipeline execution.
7. Validate Configuration – ran a quick smoke test to confirm all mounts, secrets, and permissions were functional.

This one-time configuration ensures a seamless transition between local development and enterprise-grade orchestration in AI Core.

🧩 Training Pipeline (Bring Your Own Training Logic)

I created a training template (training-template.yaml) that runs my PyTorch script inside AI Core:

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: invoice-classifier-training
spec:
  arguments:
    parameters:
      - name: trainImage
        value: "docker.io/itsmarlo/invoice-train:latest"
      - name: baseModel
        value: "microsoft/deberta-v3-base"
      - name: numLabels
        value: "5"

The workflow fine-tunes the model, evaluates it, and stores the trained weights as an artifact.

All training logic, hyperparameters, and dependencies are defined by me, illustrating the “bring your own” principle in action.

Training dependencies (requirements-train.txt)

torch==2.3.1
transformers>=4.42.0
datasets>=2.20.0
scikit-learn>=1.4.2
pandas>=2.2.2

🧠 Serving Pipeline (Bring Your Own Inference Service)

The serving template (serving-template.yaml) deploys the model as a REST API using a lightweight FastAPI application:

apiVersion: ai.sap.com/v1alpha1
kind: ServingTemplate
metadata:
  name: invoice-classifier-serving
spec:
  parameters:
    - name: image
      default: "docker.io/itsmarlo/invoice-serve:latest"
    - name: port
      default: 8080

Serving stack (requirements-serve.txt)

fastapi>=0.111.0
uvicorn[standard]>=0.30.0
torch==2.3.1
transformers>=4.42.0
pydantic>=2.7.0

AI Core hosts this container as a KServe inference service that scales automatically and can be consumed securely by any SAP application.

🧾 Testing the BYOM Deployment

I validated the deployed endpoint directly from AI Launchpad and Postman:

curl -X POST "https://<aicore-endpoint>/v1/invocations" \\
  -H "Content-Type: application/json" \\
  -d '{"text":"Invoice blocked due to mismatch between PO and invoice quantity"}'

Response:

{
 "predicted_label": "Quantity Mismatch",
 "confidence": 0.94
}

🧩 Integration into SAP Applications

I integrated the inference endpoint with:

• SAP Cloud Integration (CPI) for data exchange
• SAP CAP services calling the AI Core endpoint
• Fiori Elements UI showing predictions in blocked-invoice apps

This completes the BYOM loop – training in AI Core, serving through KServe, and consuming predictions in SAP S/4HANA.

💡Key Insights from Building a BYOM Scenario

• Validate locally first: Most deployment issues come from path or dependency errors.
• Keep Docker architecture consistent: Always build for linux/amd64.
• Version everything: YAMLs, images, and datasets must align.
• Secure storage early: Validate S3 credentials and IAM roles.
• Test endpoints before integration: Simple Postman tests save time.

Each step underlines the strength of BYOM: complete visibility and control of the AI lifecycle.

📈Results

Metric Value

Base model	DeBERTa-v3-base
Training time	≈ 10 min (3 epochs, batch 16)
Model size	≈ 250 MB
Validation accuracy	≈ 90 %
Inference latency	< 200 ms (CPU)

🔭Next Steps

I plan to enhance the BYOM pipeline by:

• Adding a metrics logging stage to AI Launchpad
• Automating retraining with updated datasets
• Integrating model explainability (SHAP, LIME)
• Monitoring inference performance in real time

🧪 Try It Yourself

You can explore the full setup, including all YAML templates, Dockerfiles, and sample datasets, in my public GitHub repository:

👉GitHub – teched25-BYOM-classifier

Clone the repo, adjust the dataset paths, and deploy your own BYOM workflow on SAP AI Core.

The repository includes:

• Training and serving templates for AI Core
• Dockerfiles for both training and serving containers
• Python scripts for model fine-tuning and inference
• Example datasets and label maps

This example is a starting point for deploying your own Hugging Face models in SAP AI Foundation with full lifecycle control.

⚠️Challenges and How I Overcame Them

Challenge Resolution

Image pull failures due to architecture mismatch (ARM vs. x86)	Rebuilt Docker images specifically for linux/amd64, ensuring compatibility with AI Core runtimes.
Path mismatches and missing dependencies	Validated Docker builds locally before pushing to Docker Hub; used absolute paths for mounted datasets in YAML templates.
Dataset access issues (S3 permissions)	Adjusted IAM policy and verified bucket configuration early in the setup.
Versioning conflicts between Docker images and YAML definitions	Implemented strict version tagging across all artifacts to maintain reproducibility.
Debugging failed executions	Used AI Launchpad logs extensively and added print statements in Python scripts to trace errors.

Each challenge reinforced the value of BYOM having full transparency and ownership made it easier to troubleshoot, iterate, and optimize the overall AI lifecycle.

🙌Conclusion

This project demonstrates how Bring Your Own Model (BYOM) empowers developers to run open-source models like Hugging Face Transformers within SAP AI Foundation under full enterprise governance.

By defining my own Docker images, YAML pipelines, and inference logic, I combined open innovation with SAP’s orchestration and compliance framework.

The result is an end-to-end, production-ready AI service for SAP S/4HANA that remains explainable, auditable, and reusable across use cases.

Follow me on SAP Community for more insights on BYOM, Hugging Face integration, and AI Core automation.🤗