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

is educated on huge datasets and may carry out a variety of duties. Many basis fashions in the present day are based mostly on some variant of the transformer structure pioneered by the likes of Google and OpenAI. Regardless of being resource-intensive to coach, transformer-based fashions can obtain excessive predictive efficiency at scale, exhibit emergent capabilities for performing duties with out express coaching, and may work with several types of enter and output knowledge. Whereas giant language fashions reminiscent of ChatGPT are educated on textual content knowledge, basis fashions can also be educated on different types of knowledge (e.g., pictures, audio, and video).

Just lately, some firms with giant troves of tabular knowledge have begun investing in tabular basis fashions. These firms are making a strategic wager that the big upfront expenditure wanted to construct tabular basis fashions will yield important future returns, from elevated predictive efficiency and productiveness to unlocking new income streams. Up to now, a separate tabular mannequin sometimes needed to be educated per use case. For giant firms with a number of AI use instances, the “one mannequin per use case” paradigm tended to incur important prices throughout the mannequin lifecycle. Against this, one basis mannequin might probably serve many use instances directly because of the mannequin’s emergent properties of generalization. Having “one mannequin to rule all of them” — a lion king amongst fashions, if you’ll — appears instinctively interesting and will supply a variety of sensible benefits.

SAP is one firm that has lately created some buzz by releasing its personal suite of Relational Pretrained Transformer (RPT) fashions — basis fashions that may be educated on giant units of historic knowledge spanning a number of enterprise domains. On this article, SAP’s foray into tabular basis fashions will function a concrete case examine to assist us higher perceive the sensible implications of offering and utilizing such fashions. After situating the RPT fashions inside their historic context, we’ll go over their technical structure, stroll via a hands-on demonstration in Python, consider the professionals and cons, and focus on strategic methods ahead for tabular basis fashions at enterprise distributors like SAP.

Relational Pretrained Transformers

The Journey to RPT at SAP

SAP is among the world’s main suppliers of enterprise useful resource planning (ERP) software program, serving to companies successfully handle important workflows in areas starting from gross sales and finance to human assets and logistics. SAP has been investing in AI for a number of years, and till lately supplied two principal varieties of AI fashions to clients: fashions optimized to be used with SAP’s ABAP language and S/4HANA database know-how (e.g., see hana-ml), and slender AI fashions hosted on SAP’s Enterprise Expertise Platform. For the reason that creation of ChatGPT, SAP has been creating its personal suite of conversational, generative AI choices beneath the Joule model title (e.g., Joule for Consultants, Joule for Builders). The AI fashions underlying the Joule merchandise are educated on SAP-specific knowledge to ship extra related AI responses in use instances involving data retrieval and code technology. SAP permits integrations with third-party suppliers of pretrained fashions reminiscent of OpenAI and Anthropic by way of the Generative AI hub, and now, with the discharge of the SAP-RPT-1 mannequin suite, SAP has created tabular basis fashions that may be educated by itself huge trove of domain-specific ERP knowledge.

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

Beneath the Hood: Technical Structure of SAP-RPT-1

Because the title suggests, the relational pretrained transformer (RPT) adapts the structure of classical transformers for dealing with tabular (or relational) knowledge. The preliminary SAP-RPT-1 fashions implement the ConTextTab structure described by Spinaci et al. (2025), which in flip builds on the structure of TabPFN, proposed by Hollmann et al. (2022).

TabPFN is a transformer mannequin pretrained on synthetically generated tables that encapsulates a number of potential causal relationships between cells in particular person desk columns. By counting on solely artificial knowledge, TabPFN can — maybe surprisingly — outperform different fashions in use instances involving comparatively small tables with lower than 10k rows of consultant knowledge that will have lacking values and outliers. TabPFN can generalize to quite a lot of classification duties at inference time with out the necessity for additional hyperparameter optimization or fine-tuning; that is achievable via in-context studying (ICL), through which a number of examples of how one can carry out new duties are supplied as a part of the immediate for the inspiration mannequin. Determine 1, from a follow-up Nature article by Hollmann et al. (2025), exhibits the workflow of (a) the pre-training and utilization, and (b) the high-level structure of TabPFN.

One downside of coaching the TabPFN mannequin utilizing solely artificial knowledge, nevertheless, is that such knowledge doesn’t adequately seize the semantically significant values present in actual datasets (e.g., from column names, categorical knowledge, and free textual content). ConTextTab addresses this situation by coaching the transformer on real-world datasets and utilizing semantic embeddings for categorical and textual knowledge, together with column names. Determine 2, from the NeurIPS article by Spinaci et al. (2025), illustrates the high-level structure of ConTextTab.

The preliminary SAP-RPT-1 suite consists of three fashions: sap-rpt-1-small (a light-weight industrial mannequin for quick inference and prototyping), sap-rpt-1-large (a much bigger industrial mannequin that may obtain the next predictive efficiency), and sap-rpt-1-oss (a light-weight open-source model out there on HuggingFace and GitHub). The fashions can theoretically be used for quite a lot of classification and regression duties utilizing few-shot in-context studying. On the time of writing, a free restricted model of SAP-RPT-1 is out there for non‑productive analysis and testing in a playground surroundings — we’ll check out this mannequin beneath.

Fingers-On Demo

Preliminary Setup

To get entry to the free check model of SAP-RPT-1, go to this hyperlink and sign up. On the backside of the documentation, it is best to see your private API token — copy this right into a file known as access_token.json for later use as follows:

{
    "access_token": "<TOKEN>"
}

Check Dataset

Create a CSV file known as sales_data_test.csv with the info proven in Desk 1 beneath. This toy dataset may also be obtained from the SAP-RPT-1 playground surroundings upon getting signed in.

The duty is to foretell values within the SALESGROUP column (indicated by the [PREDICT] placeholders) utilizing values from the remaining columns. SAP-RPT-1 operationalizes few-shot ICL by requiring the enter knowledge to incorporate the next varieties of rows:

• No less than two context rows containing the whole knowledge for a given report, which can be utilized as examples for ICL.
• No less than one question row containing [PREDICT] placeholders.

Though SAP-RPT-1 can theoretically be used for multi-target prediction, we’ll use it for single-target classification with the gross sales dataset.

Setting up and Posting the Prediction Request

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

• Specify two top-level keys, rows and index_column.
• The worth of rows needs to be the rows of the enter knowledge desk represented as a listing of dictionary objects.
• The worth of index_column needs to be the title of the index column of the enter knowledge desk; this might be used as a row identifier within the mannequin response.

The code snippet beneath exhibits how one can 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="data")  # Convert to checklist of dicts

index_column = "id"

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

The ensuing payload ought to appear to be this:

{
  "rows": [
    {
      "PRODUCT": "Laptop",
      "PRICE": 999.99,
      "CUSTOMER": "Acme Corp",
      "COUNTRY": "USA",
      "id": "35",
      "SALESGROUP": "[PREDICT]"
    },
    {
      "PRODUCT": "Workplace chair",
      "PRICE": 142.99,
      "CUSTOMER": "Moebel Biehl",
      "COUNTRY": "Germany",
      "id": "571",
      "SALESGROUP": "[PREDICT]"
    },
    {
      "PRODUCT": "Desktop Laptop",
      "PRICE": 750.5,
      "CUSTOMER": "World Tech",
      "COUNTRY": "Canada",
      "id": "42",
      "SALESGROUP": "Enterprise Options"
    },
    {
      "PRODUCT": "Macbook",
      "PRICE": 750.5,
      "CUSTOMER": "World Tech",
      "COUNTRY": "Canada",
      "id": "99",
      "SALESGROUP": "Enterprise Options"
    },
    {
      "PRODUCT": "Smartphone",
      "PRICE": 499.99,
      "CUSTOMER": "Cell World",
      "COUNTRY": "UK",
      "id": "43",
      "SALESGROUP": "Client Electronics"
    },
    {
      "PRODUCT": "Workplace Chair",
      "PRICE": 150.8,
      "CUSTOMER": "Furnishings Ltd",
      "COUNTRY": "Germany",
      "id": "44",
      "SALESGROUP": "Workplace Furnishings"
    },
    {
      "PRODUCT": "Server Rack",
      "PRICE": 1200,
      "CUSTOMER": "Knowledge Dynamics",
      "COUNTRY": "Australia",
      "id": "104",
      "SALESGROUP": "Knowledge Infrastructure"
    },
    {
      "PRODUCT": "Wi-fi Router",
      "PRICE": 89.99,
      "CUSTOMER": "Tech Ahead",
      "COUNTRY": "India",
      "id": "204",
      "SALESGROUP": "Networking Units"
    }
  ],
  "index_column": "id"
}

Subsequent, we will create a dictionary to outline 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"]

# Outline HTTP request headers
headers = {
    "Content material-Sort": "utility/json",
    "Authorization": f"Bearer {AUTH_TOKEN}"
}

Lastly, we will ship the POST request and (if profitable) get hold of the predictions within the response:

import requests

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

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

print(response.json())

In case your request doesn’t succeed, listed here are some frequent causes and their error codes:

• Dangerous Request (error code 400): Brought on by an invalid knowledge format or a validation error. Verify that the payload parts (together with the context and question rows) are constructed accurately.
• Unauthorized (401): Brought on by an invalid or lacking API token. Be certain that your token saved in access_token.json matches the one generated for you within the SAP-RPT-1 playground.
• Too Many Requests (429): Happens if the speed restrict is exceeded or the API service is briefly unavailable. This error features a Retry-After header that signifies how lengthy it is best to wait earlier than sending one other request to the API. Price limiting ensures that the playground surroundings shouldn’t be abused and may also be used within the industrial mannequin APIs to implement tiered pricing plans.
• Service Unavailable (503): Happens if the API server is beneath excessive load. This error additionally contains the Retry-After header.
• Inside Server Error (500): This may increasingly happen as a result of another server issues on SAP aspect (e.g., teething points through the months after product launch). Contact buyer help.

Reformatting the Prediction Response

On the time of writing, when utilizing the SAP-RPT-1 playground API with the check gross sales knowledge, the response object seems to be one thing 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": "class"
      },
      "PRICE": {
        "dtype": "quantity"
      },
      "CUSTOMER": {
        "dtype": "class"
      },
      "COUNTRY": {
        "dtype": "class"
      },
      "id": {
        "dtype": "quantity"
      },
      "SALESGROUP": {
        "dtype": "class"
      }
    }
  },
  "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’re sometimes desirous about are the values of the prediction key (i.e., the predictions and their confidence scores for the goal fields) and the delay key (displaying the request processing time). Observe that the industrial fashions would return non-null confidence scores as required. Moreover, it could be handy to interchange the [PREDICT] placeholders with the anticipated values for sure downstream duties (e.g., knowledge imputation and auto-completion). We are able to write a helper operate to merge the predictions from the API response again into the unique payload in order that it really works for arbitrary goal and index columns as follows:

def merge_predictions(payload, response_json):

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

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

    # Construct 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 goal in target_columns:
            prediction_map[idx_value][target] = pred[target][0]["prediction"]

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

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

Instance utilization:

response_json = response.json()

if "error" in response_json:
    # Instance of dealing with a charge restrict 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 could reformat the payload with the anticipated values stuffed 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"
}

Professionals and Cons

Some key advantages of ICL-based tabular basis fashions derive from the truth that clients can begin with a complicated AI mannequin that’s pretrained on large-scale, business-relevant knowledge, reasonably than having to coach a mannequin from scratch. On the early levels of product discovery and improvement, clients can iterate over prototypes of AI use instances extra effectively and cheaply by leveraging the pretrained mannequin straight with zero- or few-shot studying. As an example, working with SAP-RPT-1 fashions will be so simple as passing just a few rows of information in a well-known, tabular format to the AI API and receiving a response with predictions in a typical format (e.g., JSON) that may simply be built-in into the remainder of the prototype workflow.

The mixture of a pretrained mannequin and ICL can dramatically decrease the barrier to make use of case experimentation. Providing small and huge industrial fashions lets clients defer prices by choosing the small model throughout early prototyping and switching to the big model to be used in manufacturing as wanted. Working with completely different mannequin sizes additionally offers clients hands-on insights into the associated trade-offs (e.g., between predictive accuracy, latency, and value, as mentioned in this article), bettering AI literacy. Equally, providing open-source mannequin variations can assist educate clients, foster engagement by the developer neighborhood, and construct belief within the mannequin supplier.

But, the very product options lauded above could entail potential downsides that might cancel out the advantages. To successfully use ICL-based inference pipelines in manufacturing, clients should find yourself investing considerably in areas reminiscent of function engineering, immediate design, retrieval-augmented technology, and mannequin fine-tuning. Given the bespoke necessities of many use instances (particularly in ERP), clients are unlikely to make use of the fashions with zero- or few-shot studying.

In truth, the ICL paradigm could very properly find yourself being (ab)used to work just like the coaching step in conventional supervised machine studying, by loading giant coaching datasets into the mannequin context for every inference name. If a number of calls are made for a similar high-usage AI situation (e.g., predicting gross sales conversions based mostly on historic transaction knowledge), clients could find yourself loading and sending the identical giant (coaching) dataset within the mannequin context for a number of inference calls. Sensible logic (e.g., context knowledge compression, downsampling, caching, and so on.) could have to be applied by the service provisioning the mannequin and/or the consuming purposes to forestall redundant, high-latency, environmentally unsustainable, and probably insecure on-line knowledge transfers (particularly for high-frequency, real-time use instances).

In the end, with out additional innovation, paradigms like ICL could merely shift the prices from one “bucket” to a different (e.g., from “mannequin coaching overhead” to “immediate engineering overhead” or “inference latency”) and never considerably scale back general product improvement and upkeep prices — or increase the enterprise worth — of AI use instances.

Strategic Methods Ahead

Advertising narratives for basis fashions encourage us to think about a future through which a big portfolio of use-case-specific fashions is changed by a a lot smaller set of generally-applicable “tremendous fashions,” and even “one mannequin to rule all of them.” In fact, the instinctive enchantment and craving for common fashions in not distinctive to AI. In physics, for instance, the search for the “principle of the whole lot” seeks to unify the elemental forces (gravity, electromagnetism, and the robust and weak nuclear forces) right into a single, cohesive framework. But such an all-encompassing principle stays elusive; completely different scales (e.g., cosmic vs. quantum) require completely different fashions, gravity seems to withstand integration with quantum mechanics, and we find yourself with partial unifications (e.g., quantum chromodynamics and electroweak principle). And so it could be for basis fashions in AI. Certainly, through the SAP-RPT-1 product launch, SAP launched not one however three mannequin variants (giant, small, and open-source). These variants spanned at the least two conceptual dimensions: mannequin measurement (giant vs. small) and transparency (closed vs. open-source).

So, trying to the longer term, the fascinating query shouldn’t be whether or not mannequin specialization will happen, however how rapidly, throughout which conceptual dimensions, and to what sensible impact. For an ERP vendor like SAP, as an example, it might make sense to supply specialised basis fashions for a tractable set of key enterprise processes (e.g., “supply to pay,” “design to function,” “result in money,” and “recruit to retire”). The fashions might additional be damaged down by business or buyer section to enhance prediction high quality. Even offering one specialised mannequin per buyer can be a major enchancment over the established order; every mannequin may very well be educated to be taught customer-specific patterns (guaranteeing that predictions make sense in a given buyer’s enterprise context) and never run the danger of leaking delicate info throughout clients (the mannequin for buyer A won’t have seen the info used to coach the mannequin for buyer B, and thus can’t be simply hacked to disclose delicate knowledge patterns of B).

Lastly, distributors like SAP can also differentiate between fashions which can be hosted centrally and people which can be deployed on edge units. Whereas centrally hosted fashions have a number of benefits (e.g., scalability, ease of updating, entry to broader coaching knowledge), edge-deployed fashions could also be better-suited to sure use case wants (e.g., device-specific tuning; regulatory necessities round dealing with delicate knowledge in healthcare; enabling real-time choice making in manufacturing, IoT, and autonomous autos; working in places with patchy Web connectivity).

The Wrap

On this article we now have lined the speculation and a sensible case examine of relational pretrained transformers within the context of tabular basis fashions. Wanting via the prism of SAP’s launch of its RPT fashions, it turns into clear {that a} future through which one mannequin guidelines all of them is way from preordained. No less than based mostly on present proof, we usually tend to see the emergence of a number of specialised basis fashions that mirror the intersection of varied completely different conceptual dimensions (e.g., measurement, area, openness) — much less a lion king amongst fashions, and extra a hive of bees, every contributing its distinctive energy to the collective complete. Knowledge-rich firms reminiscent of SAP have a number of strategic choices open to them of their quest to harness the facility of tabular basis fashions for constructing a forward-looking ecosystem of AI instruments that may evolve with enterprise wants and technological progress.