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

is skilled on huge datasets and may carry out a variety of duties. Many basis fashions right now 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 various kinds of enter and output information. Whereas massive language fashions similar to ChatGPT are skilled on textual content information, basis fashions may be skilled on different types of information (e.g., photographs, audio, and video).

Not too long ago, some corporations with massive troves of tabular information have begun investing in tabular basis fashions. These corporations 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 usually needed to be skilled per use case. For big corporations with a number of AI use circumstances, 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 circumstances without delay 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 skilled on massive units of historic information spanning a number of enterprise domains. On this article, SAP’s foray into tabular basis fashions will function a concrete case research 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 talk about strategic methods ahead for tabular basis fashions at enterprise distributors like SAP.

Relational Pretrained Transformers

The Journey to RPT at SAP

SAP is without doubt one of the world’s main suppliers of enterprise useful resource planning (ERP) software program, serving to companies successfully handle crucial 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 fundamental forms of AI fashions to prospects: fashions optimized to be used with SAP’s ABAP language and S/4HANA database expertise (e.g., see hana-ml), and slender AI fashions hosted on SAP’s Enterprise Expertise Platform. Because the introduction of ChatGPT, SAP has been creating its personal suite of conversational, generative AI choices below the Joule model title (e.g., Joule for Consultants, Joule for Builders). The AI fashions underlying the Joule merchandise are skilled on SAP-specific information to ship extra related AI responses in use circumstances involving data retrieval and code era. SAP allows integrations with third-party suppliers of pretrained fashions similar to OpenAI and Anthropic through 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 skilled by itself huge trove of domain-specific ERP information.

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) information. 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 information, TabPFN can — maybe surprisingly — outperform different fashions in use circumstances involving comparatively small tables with lower than 10k rows of consultant information 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), during which a number of examples of easy methods to carry out new duties are supplied as a part of the immediate for the muse mannequin. Determine 1, from a follow-up Nature article by Hollmann et al. (2025), reveals 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 information, nonetheless, is that such information doesn’t adequately seize the semantically significant values present in actual datasets (e.g., from column names, categorical information, and free textual content). ConTextTab addresses this subject by coaching the transformer on real-world datasets and utilizing semantic embeddings for categorical and textual information, 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 (an even 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 offered for non‑productive analysis and testing in a playground setting — we’ll check out this mannequin under.

Arms-On Demo

Preliminary Setup

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

{
    "access_token": ""
}

Check Dataset

Create a CSV file referred to as sales_data_test.csv with the information proven in Desk 1 under. This toy dataset may also be obtained from the SAP-RPT-1 playground setting 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 information to incorporate the next forms of rows:

• At the least two context rows containing the whole information for a given document, which can be utilized as examples for ICL.
• At the least 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.

Developing 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 information desk represented as an inventory of dictionary objects.
• The worth of index_column needs to be the title of the index column of the enter information desk; this might be used as a row identifier within the mannequin response.

The code snippet under reveals easy methods 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="data")  # Convert to record 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": "Cellular 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": "software/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.put up(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 information format or a validation error. Test that the payload parts (together with the context and question rows) are constructed appropriately.
• Unauthorized (401): Brought on by an invalid or lacking API token. Make sure 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 you must wait earlier than sending one other request to the API. Fee limiting ensures that the playground setting just isn’t 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 below excessive load. This error additionally contains the Retry-After header.
• Inner Server Error (500): This may increasingly happen as a result of another server issues on SAP aspect (e.g., teething points throughout the months after product launch). Contact buyer assist.

Reformatting the Prediction Response

On the time of writing, when utilizing the SAP-RPT-1 playground API with the check gross sales information, the response object appears 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 usually focused on 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., information imputation and auto-completion). We will write a helper perform 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"]

    # Exchange 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 crammed 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 prospects can begin with a complicated AI mannequin that’s pretrained on large-scale, business-relevant information, somewhat than having to coach a mannequin from scratch. On the early levels of product discovery and growth, prospects can iterate over prototypes of AI use circumstances extra effectively and cheaply by leveraging the pretrained mannequin instantly with zero- or few-shot studying. As an illustration, working with SAP-RPT-1 fashions may be so simple as passing a number of rows of information in a well-known, tabular format to the AI API and receiving a response with predictions in an ordinary format (e.g., JSON) that may simply be built-in into the remainder of the prototype workflow.

The mix of a pretrained mannequin and ICL can dramatically decrease the barrier to make use of case experimentation. Providing small and enormous industrial fashions lets prospects 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 totally different mannequin sizes additionally offers prospects hands-on insights into the associated trade-offs (e.g., between predictive accuracy, latency, and value, as mentioned in this article), enhancing AI literacy. Equally, providing open-source mannequin variations will help educate prospects, foster engagement by the developer neighborhood, and construct belief within the mannequin supplier.

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

Actually, the ICL paradigm might very nicely find yourself being (ab)used to work just like the coaching step in conventional supervised machine studying, by loading massive 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 information), prospects might find yourself loading and sending the identical massive (coaching) dataset within the mannequin context for a number of inference calls. Good logic (e.g., context information compression, downsampling, caching, and many others.) might have to be applied by the service provisioning the mannequin and/or the consuming functions to stop redundant, high-latency, environmentally unsustainable, and probably insecure on-line information transfers (particularly for high-frequency, real-time use circumstances).

Finally, with out additional innovation, paradigms like ICL might 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 growth and upkeep prices — or enhance the enterprise worth — of AI use circumstances.

Strategic Methods Ahead

Advertising narratives for basis fashions encourage us to think about a future during 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 attraction and craving for common fashions in not distinctive to AI. In physics, for instance, the hunt for the “concept of every little thing” seeks to unify the elemental forces (gravity, electromagnetism, and the sturdy and weak nuclear forces) right into a single, cohesive framework. But such an all-encompassing concept stays elusive; totally different scales (e.g., cosmic vs. quantum) require totally different fashions, gravity seems to withstand integration with quantum mechanics, and we find yourself with partial unifications (e.g., quantum chromodynamics and electroweak concept). And so it could be for basis fashions in AI. Certainly, throughout the SAP-RPT-1 product launch, SAP launched not one however three mannequin variants (massive, small, and open-source). These variants spanned at the least two conceptual dimensions: mannequin measurement (massive vs. small) and transparency (closed vs. open-source).

So, trying to the long run, the fascinating query just isn’t 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 might be skilled to study customer-specific patterns (guaranteeing that predictions make sense in a given buyer’s enterprise context) and never run the chance of leaking delicate data throughout prospects (the mannequin for buyer A is not going to have seen the information used to coach the mannequin for buyer B, and thus can’t be simply hacked to disclose delicate information patterns of B).

Lastly, distributors like SAP may 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 information), edge-deployed fashions could also be better-suited to sure use case wants (e.g., device-specific tuning; regulatory necessities round dealing with delicate information in healthcare; enabling real-time determination 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 research of relational pretrained transformers within the context of tabular basis fashions. Trying via the prism of SAP’s launch of its RPT fashions, it turns into clear {that a} future during which one mannequin guidelines all of them is much from preordained. At the least 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 totally 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 power to the collective complete. Knowledge-rich corporations similar to 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.