One Model to Rule Them All? SAP-RPT-1 and the Future of Tabular Foundation Models

is trained on vast datasets and can perform a wide range of tasks. Many foundation models today are based on some variant of the transformer architecture pioneered by the likes of Google and OpenAI. Despite being resource-intensive to train, transformer-based models can achieve high predictive performance at scale, exhibit emergent capabilities for performing tasks without explicit training, and can work with different types of input and output data. While large language models such as ChatGPT are trained on text data, foundation models may also be trained on other forms of data (e.g., images, audio, and video).

Recently, some companies with large troves of tabular data have begun investing in tabular foundation models. These companies are making a strategic bet that the large upfront expenditure needed to build tabular foundation models will yield significant future returns, from increased predictive performance and productivity to unlocking new revenue streams. In the past, a separate tabular model typically had to be trained per use case. For large companies with several AI use cases, the “one model per use case” paradigm tended to incur significant costs across the model lifecycle. By contrast, one foundation model could potentially serve many use cases at once thanks to the model’s emergent properties of generalization. Having “one model to rule them all” — a lion king among models, if you will — seems instinctively appealing and could offer a number of practical advantages.

SAP is one company that has recently created some buzz by releasing its own suite of Relational Pretrained Transformer (RPT) models — foundation models that can be trained on large sets of historical data spanning several business domains. In this article, SAP’s foray into tabular foundation models will serve as a concrete case study to help us better understand the practical implications of providing and using such models. After situating the RPT models within their historical context, we will go over their technical architecture, walk through a hands-on demonstration in Python, evaluate the pros and cons, and discuss strategic ways forward for tabular foundation models at enterprise vendors like SAP.

Relational Pretrained Transformers

The Journey to RPT at SAP

SAP is one of the world’s leading providers of enterprise resource planning (ERP) software, helping businesses effectively manage critical workflows in areas ranging from sales and finance to human resources and logistics. SAP has been investing in AI for several years, and until recently offered two main types of AI models to customers: models optimized for use with SAP’s ABAP language and S/4HANA database technology (e.g., see hana-ml), and narrow AI models hosted on SAP’s Business Technology Platform. Since the advent of ChatGPT, SAP has been developing its own suite of conversational, generative AI offerings under the Joule brand name (e.g., Joule for Consultants, Joule for Developers). The AI models underlying the Joule products are trained on SAP-specific data to deliver more relevant AI responses in use cases involving knowledge retrieval and code generation. SAP enables integrations with third-party providers of pretrained models such as OpenAI and Anthropic via the Generative AI hub, and now, with the release of the SAP-RPT-1 model suite, SAP has created tabular foundation models that can be trained on its own vast trove of domain-specific ERP data.

Watch the keynote segment from 30:16 to 34:46 to see the official launch of SAP-RPT-1 at SAP TechEd 2025:

Under the Hood: Technical Architecture of SAP-RPT-1

As the name suggests, the relational pretrained transformer (RPT) adapts the architecture of classical transformers for handling tabular (or relational) data. The initial SAP-RPT-1 models implement the ConTextTab architecture described by Spinaci et al. (2025), which in turn builds on the architecture of TabPFN, proposed by Hollmann et al. (2022).

TabPFN is a transformer model pretrained on synthetically generated tables that encapsulates several possible causal relationships between cells in individual table columns. By relying on only synthetic data, TabPFN can — perhaps surprisingly — outperform other models in use cases involving relatively small tables with less than 10k rows of representative data that may have missing values and outliers. TabPFN can generalize to a variety of classification tasks at inference time without the need for further hyperparameter optimization or fine-tuning; this is achievable through in-context learning (ICL), in which one or more examples of how to perform new tasks are provided as part of the prompt for the foundation model. Figure 1, from a follow-up Nature article by Hollmann et al. (2025), shows the workflow of (a) the pre-training and usage, and (b) the high-level architecture of TabPFN.

One drawback of training the TabPFN model using only synthetic data, however, is that such data does not adequately capture the semantically meaningful values found in real datasets (e.g., from column names, categorical data, and free text). ConTextTab addresses this issue by training the transformer on real-world datasets and using semantic embeddings for categorical and textual data, including column names. Figure 2, from the NeurIPS article by Spinaci et al. (2025), illustrates the high-level architecture of ConTextTab.

The initial SAP-RPT-1 suite consists of three models: sap-rpt-1-small (a lightweight commercial model for fast inference and prototyping), sap-rpt-1-large (a bigger commercial model that can achieve a higher predictive performance), and sap-rpt-1-oss (a lightweight open-source version available on HuggingFace and GitHub). The models can theoretically be used for a variety of classification and regression tasks using few-shot in-context learning. At the time of writing, a free limited version of SAP-RPT-1 is available for non‑productive evaluation and testing in a playground environment — we will try out this model below.

Hands-On Demo

Initial Setup

To get access to the free test version of SAP-RPT-1, go to this link and sign in. At the bottom of the documentation, you should see your personal API token — copy this into a file called access_token.json for later use as follows:

{
    "access_token": ""
}

Test Dataset

Create a CSV file called sales_data_test.csv with the data shown in Table 1 below. This toy dataset can also be obtained from the SAP-RPT-1 playground environment once you have signed in.

The task is to predict values in the SALESGROUP column (indicated by the [PREDICT] placeholders) using values from the remaining columns. SAP-RPT-1 operationalizes few-shot ICL by requiring the input data to include the following types of rows:

• At least two context rows containing the complete data for a given record, which can be used as examples for ICL.
• At least one query row containing [PREDICT] placeholders.

Although SAP-RPT-1 can theoretically be used for multi-target prediction, we will use it for single-target classification with the sales dataset.

Constructing and Posting the Prediction Request

The prediction endpoint of the SAP-RPT-1 model expects the request payload to be formatted as follows:

• Specify two top-level keys, rows and index_column.
• The value of rows should be the rows of the input data table represented as a list of dictionary objects.
• The value of index_column should be the name of the index column of the input data table; this will be used as a row identifier in the model response.

The code snippet below shows how to create the request payload as required from sales_data_test.csv:

import pandas as pd
import json
import requests

df = pd.read_csv("sales_data_test.csv")  # Load CSV file

rows = df.to_dict(orient="records")  # Convert to list of dicts

index_column = "id"

payload = {
    "rows": rows,
    "index_column": index_column
}

The resulting payload should look like this:

{
  "rows": [
    {
      "PRODUCT": "Laptop",
      "PRICE": 999.99,
      "CUSTOMER": "Acme Corp",
      "COUNTRY": "USA",
      "id": "35",
      "SALESGROUP": "[PREDICT]"
    },
    {
      "PRODUCT": "Office chair",
      "PRICE": 142.99,
      "CUSTOMER": "Moebel Biehl",
      "COUNTRY": "Germany",
      "id": "571",
      "SALESGROUP": "[PREDICT]"
    },
    {
      "PRODUCT": "Desktop Computer",
      "PRICE": 750.5,
      "CUSTOMER": "Global Tech",
      "COUNTRY": "Canada",
      "id": "42",
      "SALESGROUP": "Enterprise Solutions"
    },
    {
      "PRODUCT": "Macbook",
      "PRICE": 750.5,
      "CUSTOMER": "Global Tech",
      "COUNTRY": "Canada",
      "id": "99",
      "SALESGROUP": "Enterprise Solutions"
    },
    {
      "PRODUCT": "Smartphone",
      "PRICE": 499.99,
      "CUSTOMER": "Mobile World",
      "COUNTRY": "UK",
      "id": "43",
      "SALESGROUP": "Consumer Electronics"
    },
    {
      "PRODUCT": "Office Chair",
      "PRICE": 150.8,
      "CUSTOMER": "Furniture Ltd",
      "COUNTRY": "Germany",
      "id": "44",
      "SALESGROUP": "Office Furniture"
    },
    {
      "PRODUCT": "Server Rack",
      "PRICE": 1200,
      "CUSTOMER": "Data Dynamics",
      "COUNTRY": "Australia",
      "id": "104",
      "SALESGROUP": "Data Infrastructure"
    },
    {
      "PRODUCT": "Wireless Router",
      "PRICE": 89.99,
      "CUSTOMER": "Tech Forward",
      "COUNTRY": "India",
      "id": "204",
      "SALESGROUP": "Networking Devices"
    }
  ],
  "index_column": "id"
}

Next, we can create a dictionary to define the HTTP request headers as follows:

import json

# Load the token
with open("access_token.json", "r") as token_file:
    token_data = json.load(token_file)
    AUTH_TOKEN = token_data["access_token"]

# Define HTTP request headers
headers = {
    "Content-Type": "application/json",
    "Authorization": f"Bearer {AUTH_TOKEN}"
}

Finally, we can send the POST request and (if successful) obtain the predictions in the response:

import requests

url = "https://rpt.cloud.sap/api/predict"

response = requests.post(url, json=payload, headers=headers)

print(response.json())

If your request does not succeed, here are some common reasons and their error codes:

• Bad Request (error code 400): Caused by an invalid data format or a validation error. Check that the payload components (including the context and query rows) are constructed correctly.
• Unauthorized (401): Caused by an invalid or missing API token. Ensure that your token stored in access_token.json matches the one generated for you in the SAP-RPT-1 playground.
• Too Many Requests (429): Occurs if the rate limit is exceeded or the API service is temporarily unavailable. This error includes a Retry-After header that indicates how long you should wait before sending another request to the API. Rate limiting ensures that the playground environment is not abused and can also be used in the commercial model APIs to implement tiered pricing plans.
• Service Unavailable (503): Occurs if the API server is under high load. This error also includes the Retry-After header.
• Internal Server Error (500): This may occur due to some other server problems on SAP side (e.g., teething issues during the months after product launch). Contact customer support.

Reformatting the Prediction Response

At the time of writing, when using the SAP-RPT-1 playground API with the test sales data, the response object looks something like this:

{
  "prediction": {
    "id": "...",
    "metadata": {
      "num_columns": 5,
      "num_predict_rows": 2,
      "num_predict_tokens": 2,
      "num_rows": 6
    },
    "predictions": [
      {
        "SALESGROUP": [
          {
            "confidence": null,
            "prediction": "Enterprise Solutions"
          }
        ],
        "id": 35
      },
      {
        "SALESGROUP": [
          {
            "confidence": null,
            "prediction": "Office Furniture"
          }
        ],
        "id": 571
      }
    ]
  },
  "delay": 302.7692240476608,
  "aiApiRequestPayload": {
    "prediction_config": {
      "target_columns": [
        {
          "name": "SALESGROUP",
          "placeholder_value": "[PREDICT]",
          "task_type": "classification"
        }
      ]
    },
    "rows": [ ... ],
    "index_column": "id",
    "data_schema": {
      "PRODUCT": {
        "dtype": "category"
      },
      "PRICE": {
        "dtype": "number"
      },
      "CUSTOMER": {
        "dtype": "category"
      },
      "COUNTRY": {
        "dtype": "category"
      },
      "id": {
        "dtype": "number"
      },
      "SALESGROUP": {
        "dtype": "category"
      }
    }
  },
  "aiApiResponsePayload": {
    "id": "84072280-e47e-430e-91e6-008066f1a6d3",
    "metadata": {
      "num_columns": 5,
      "num_predict_rows": 2,
      "num_predict_tokens": 2,
      "num_rows": 6
    },
    "predictions": [ ... ]
  }
}

What we are typically interested in are the values of the prediction key (i.e., the predictions and their confidence scores for the target fields) and the delay key (showing the request processing time). Note that the commercial models would return non-null confidence scores as required. Furthermore, it may be convenient to replace the [PREDICT] placeholders with the predicted values for certain downstream tasks (e.g., data imputation and auto-completion). We can write a helper function to merge the predictions from the API response back into the original payload so that it works for arbitrary target and index columns as follows:

def merge_predictions(payload, response_json):

    # Extract index column name
    index_column = payload["index_column"]

    # Extract target column(s) from the request payload config
    target_columns = [
        col["name"]
        for col in response_json["aiApiRequestPayload"]["prediction_config"]["target_columns"]
    ]

    # Build a prediction map keyed by index_column
    prediction_map = {}
    for pred in response_json["prediction"]["predictions"]:
        idx_value = pred[index_column]
        prediction_map[idx_value] = {}
        for target in target_columns:
            prediction_map[idx_value][target] = pred[target][0]["prediction"]

    # Replace placeholders in payload rows
    completed_rows = []
    for row in payload["rows"]:
        idx_value = row[index_column]
        for target in target_columns:
            if str(row[target]).strip().upper() == "[PREDICT]":
                row[target] = prediction_map.get(idx_value, {}).get(target, row[target])
        completed_rows.append(row)

    return {
        "rows": completed_rows,
        "index_column": index_column
    }

Example usage:

response_json = response.json()

if "error" in response_json:
    # Example of handling a rate limit error
    print(f"API error: {response_json['error']}. Retry after {response_json.get('retryAfter')} seconds.")
else:
    completed_payload = merge_predictions(payload, response_json)
    print(json.dumps(completed_payload, indent=2))

This should reformat the payload with the predicted values filled in:

{
  "rows": [
    {
      "PRODUCT": "Laptop",
      "PRICE": 999.99,
      "CUSTOMER": "Acme Corp",
      "COUNTRY": "USA",
      "id": 35,
      "SALESGROUP": "Enterprise Solutions"
    },
    {
      "PRODUCT": "Office chair",
      "PRICE": 142.99,
      "CUSTOMER": "Moebel Biehl",
      "COUNTRY": "Germany",
      "id": 571,
      "SALESGROUP": "Office Furniture"
    },
    ...
  ],
  "index_column": "id"
}

Pros and Cons

Some key benefits of ICL-based tabular foundation models derive from the fact that customers can start with a sophisticated AI model that is pretrained on large-scale, business-relevant data, rather than having to train a model from scratch. At the early stages of product discovery and development, customers can iterate over prototypes of AI use cases more efficiently and cheaply by leveraging the pretrained model directly with zero- or few-shot learning. For instance, working with SAP-RPT-1 models can be as simple as passing a few rows of data in a familiar, tabular format to the AI API and receiving a response with predictions in a standard format (e.g., JSON) that can easily be integrated into the rest of the prototype workflow.

The combination of a pretrained model and ICL can dramatically lower the barrier to use case experimentation. Offering small and large commercial models lets customers defer costs by opting for the small version during early prototyping and switching to the large version for use in production as needed. Working with different model sizes also gives customers hands-on insights into the related trade-offs (e.g., between predictive accuracy, latency, and cost, as discussed in this article), improving AI literacy. Similarly, offering open-source model versions can help educate customers, foster engagement by the developer community, and build trust in the model provider.

Yet, the very product features lauded above may entail potential downsides that could cancel out the benefits. To effectively use ICL-based inference pipelines in production, customers may still end up investing significantly in areas such as feature engineering, prompt design, retrieval-augmented generation, and model fine-tuning. Given the bespoke requirements of many use cases (especially in ERP), customers are unlikely to use the models with zero- or few-shot learning.

In fact, the ICL paradigm may very well end up being (ab)used to work like the training step in traditional supervised machine learning, by loading large training datasets into the model context for each inference call. If multiple calls are made for the same high-usage AI scenario (e.g., predicting sales conversions based on historical transaction data), customers may end up loading and sending the same large (training) dataset in the model context for several inference calls. Smart logic (e.g., context data compression, downsampling, caching, etc.) may need to be implemented by the service provisioning the model and/or the consuming applications to prevent redundant, high-latency, environmentally unsustainable, and potentially insecure online data transfers (especially for high-frequency, real-time use cases).

Ultimately, without further innovation, paradigms like ICL may simply shift the costs from one “bucket” to another (e.g., from “model training overhead” to “prompt engineering overhead” or “inference latency”) and not substantially reduce overall product development and maintenance costs — or boost the business value — of AI use cases.

Strategic Ways Forward

Marketing narratives for foundation models encourage us to imagine a future in which a large portfolio of use-case-specific models is replaced by a much smaller set of generally-applicable “super models,” or even “one model to rule them all.” Of course, the instinctive appeal and yearning for universal models in not unique to AI. In physics, for example, the quest for the “theory of everything” seeks to unify the fundamental forces (gravity, electromagnetism, and the strong and weak nuclear forces) into a single, cohesive framework. Yet such an all-encompassing theory remains elusive; different scales (e.g., cosmic vs. quantum) require different models, gravity appears to resist integration with quantum mechanics, and we end up with partial unifications (e.g., quantum chromodynamics and electroweak theory). And so it may be for foundation models in AI. Indeed, during the SAP-RPT-1 product launch, SAP introduced not one but three model variants (large, small, and open-source). These variants spanned at least two conceptual dimensions: model size (large vs. small) and transparency (closed vs. open-source).

So, looking to the future, the interesting question is not whether model specialization will occur, but how quickly, across which conceptual dimensions, and to what practical effect. For an ERP vendor like SAP, for instance, it could make sense to offer specialized foundation models for a tractable set of key business processes (e.g., “source to pay,” “design to operate,” “lead to cash,” and “recruit to retire”). The models could further be broken down by industry or customer segment to improve prediction quality. Even providing one specialized model per customer would be a significant improvement over the status quo; each model could be trained to learn customer-specific patterns (ensuring that predictions make sense in a given customer’s business context) and not run the risk of leaking sensitive information across customers (the model for customer A will not have seen the data used to train the model for customer B, and thus cannot be easily hacked to reveal sensitive data patterns of B).

Finally, vendors like SAP may also differentiate between models that are hosted centrally and those that are deployed on edge devices. While centrally hosted models have several advantages (e.g., scalability, ease of updating, access to broader training data), edge-deployed models may be better-suited to certain use case needs (e.g., device-specific tuning; regulatory requirements around handling sensitive data in healthcare; enabling real-time decision making in manufacturing, IoT, and autonomous vehicles; working in locations with patchy Internet connectivity).

The Wrap

In this article we have covered the theory and a practical case study of relational pretrained transformers in the context of tabular foundation models. Looking through the prism of SAP’s launch of its RPT models, it becomes clear that a future in which one model rules them all is far from preordained. At least based on current evidence, we are more likely to see the emergence of several specialized foundation models that reflect the intersection of various different conceptual dimensions (e.g., size, domain, openness) — less a lion king among models, and more a hive of bees, each contributing its unique strength to the collective whole. Data-rich companies such as SAP have several strategic options open to them in their quest to harness the power of tabular foundation models for building a forward-looking ecosystem of AI tools that can evolve with business needs and technological progress.