OpenShift AI LLM workloads, priced on the accelerator footprint.

OpenShift AI is the productised release of the Red Hat platform for machine learning, model serving, and large language model workloads on OpenShift, evolving from the earlier Red Hat OpenShift Data Science release line and integrating contributions from the open source upstream community. The product runs as a set of operators on an OpenShift cluster and provisions the Jupyter notebook workbenches, the model training pipelines, the model serving endpoints, and the supporting GPU operator that exposes accelerator hardware to the cluster scheduler1. The platform itself runs on regular worker nodes; the workloads that produce the licensing footprint run on the accelerator capable subset.

The pricing reading in 2026 is that OpenShift AI accrues against the worker cores on accelerator capable nodes that participate in the AI workload pool2. A cluster of forty worker nodes that runs OpenShift AI on six GPU equipped nodes reads the OpenShift AI line on those six nodes; the remaining thirty four nodes carry only the standard OpenShift platform line. The accelerator hardware itself, the NVIDIA H100 or A100 or the equivalent, is not licensed by Red Hat; the Red Hat line covers the platform that orchestrates the accelerator workload.

The cluster that hosts OpenShift AI does not need to be exclusively AI dedicated. The accelerator capable nodes can sit inside the same OpenShift cluster as a steady state application fleet, with taints and tolerations directing the AI workloads to the GPU pool and the application workloads to the CPU pool. The licensing footprint reads on the AI pool; the rest of the cluster reads on the platform line on its own.

LLM workloads on OpenShift AI fall into three operational shapes that have very different cost economics but read against the same Red Hat subscription footprint. The training workload runs continuously across a large accelerator pool for the duration of the training run, saturating the GPU hardware and producing the bulk of the cloud or facilities cost. The fine tuning workload runs intermittently on a smaller accelerator pool against an already trained base model and produces a moderate intermittent compute load. The inference workload runs steady state on a model serving pool that responds to incoming requests, with accelerator utilisation that varies by query rate and model size.

The Red Hat subscription line treats the three shapes identically. The contract reads on the accelerator capable node count and the cores on those nodes; it does not read on which workload is running, on the GPU saturation, or on the inference query rate. A buyer who runs a one off training run on a borrowed cluster for two weeks and then tears it down still carries the OpenShift AI entitlement on the nodes that were enrolled in the AI pool during that period.

The renewal arithmetic therefore turns on the persistent footprint rather than the workload calendar. A platform team that pools accelerators inside a long lived AI cluster reads a stable subscription line. A platform team that spins up ephemeral training clusters and tears them down reads a more complex subscription line that may include marketplace consumption, capacity reservations, or hourly subscription mechanics depending on the cloud posture3.

OpenShift AI is sold as a standalone subscription on top of OpenShift Container Platform, or it can be activated as part of the broader OpenShift portfolio on certain bundle compositions. The standalone posture is the most common at the time of writing because the AI pool tends to sit on dedicated GPU clusters that do not need the broader OpenShift Plus security and governance stack. The bundle posture becomes interesting where the AI cluster shares cores with the same governance fleet that ACS and ACM secure.

The reading at signature should produce an accelerator inventory that names each node in the AI pool, the accelerator hardware on the node, the worker cores on the node, and the operational expectation for the node across the contract term. The inventory is the contract record that the audit reads against. A buyer who signs against a six node AI pool and grows it to fourteen nodes across the term reads a true up at the next renewal that captures the mid term growth at full list price. A disciplined renewal negotiation in the ninety days before signature produces the accelerator forecast that the contract scope needs.

The inventory should also capture the cloud versus on premises split. A buyer who runs a portion of the AI fleet on cloud accelerator instances and a portion on owned facilities reads two different sub lines on the subscription. The cloud portion may flow through marketplace consumption mechanics on AWS, Azure, GCP, or IBM Cloud. The on premises portion flows through the conventional Red Hat subscription line. Both portions accrue against the same underlying OpenShift AI entitlement count.

Three counting traps produce most of the exposure observed across OpenShift AI engagements in the trailing twelve months.

The first trap is the GPU node enrolled in the AI pool but operationally idle. A platform team provisions a fourteen node accelerator pool for a planned LLM training run and then the project slips by six months. The fourteen nodes sit in the AI pool through the slip; the audit reads the AI line on all fourteen even though the operational utilisation across the period is near zero. The mitigation at signature is a scope that defines the AI pool as the nodes under active workload assignment rather than nodes that carry the GPU operator.

The second trap is the fine tuning workload that bleeds into a general purpose cluster. A buyer who runs steady state inference on a dedicated AI cluster discovers that a research team has been running fine tuning jobs on the general application cluster by attaching GPU nodes to that cluster as an experiment. The application cluster now has an AI pool of its own and the AI line reads across both clusters. The mitigation is a quarterly review of GPU attachment across the OpenShift estate, with a named pool boundary in the contract record.

The third trap is the marketplace consumption that the on premises team did not expect. The data science group consumed OpenShift AI on a cloud marketplace deployment for an exploratory project; the consumption flowed through the cloud bill at full list rates. The catch up reading at the next renewal often surfaces fifteen to thirty percent of the AI line carried on unstructured marketplace consumption that could have flowed through the master agreement at concession bands.

OpenShift AI is read on the accelerator capable worker cores that participate in the AI workload pool. The reading at signature should reflect the pool boundary, the cloud versus on premises split, the marketplace versus master agreement attribution, and the operational expectation of the pool across the term. The buyer who signs against a pool defined by active workload assignment pays a line that scales with the operational reality. The buyer who signs against a pool defined by GPU operator presence pays for idle accelerators sitting in the contract scope.

The discipline at signature sets four protections that hold across the term. The AI pool boundary is defined as active workload assignment rather than hardware presence. The cloud and on premises portions are enumerated separately in the contract record. The marketplace channel and the master agreement channel are mapped to the same accelerator inventory so consumption flows through the favourable channel. A quarterly accelerator inventory reconciliation captures node level workload state and pool membership so the audit notice arrives against a record the buyer can produce on demand.

For the broader cross product reading, see the OpenShift practice hub, the ACM pricing read for governance across AI and non AI clusters, the ACS read for security on the accelerator fleet, the GPU entitlement read for the node by node counting mechanics, and the RHEL for SAP HANA read where similar accelerator and certified hardware mechanics appear at the database tier. For the engagement protocol, see contact.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.