Customer Onboarding, Delivery & Productization

The other chapters in Part 10 build the machine. This one turns it into a product someone can buy. The orchestration plane, tenant isolation, provisioning automation, health telemetry, fault-tolerance loop and training frameworks are all internal plumbing until you wrap them in a consumption model, an API, an SLA, a billing meter and an onboarding path. Productization draws a clean line between what the operator owns and what the customer owns, then prices the responsibility on each side. Draw it in the wrong place and you either give away margin you should have kept or carry risk you should have transferred.

The chapter starts with the value-stack ladder from bare-metal to serverless, and how each rung moves the boundary. Multi-tenancy and isolation comes next, as a joint security, noisy-neighbor and billing decision. Then the control plane, API and provisioning surface that makes the product self-serve. We separate facility availability, usable capacity and managed useful output, and identify which SLA the operator controls and the customer buys. The billing and capacity spectrum runs from spot to take-or-pay. Last come onboarding, time-to-first-job and offboarding/portability: the metrics that decide conversion, and the exit story that decides trust. The rung changes the work you operate; the actual contract, isolation boundary and measured cost determine margin and liability.

The same physical GPUs can be sold at four altitudes, and the altitude you pick drives every other commercial decision in this chapter. At the bottom is bare-metal: a dedicated, single-tenant node (or a whole cluster) with raw hardware access, an OS image and a network fabric, and almost nothing else. Your margin on raw capacity is thin and you carry no software risk. The customer owns goodput, drivers, schedulers and uptime above the metal. One rung up is GPUaaS, the virtualized or containerized IaaS tier: VMs or Kubernetes with the GPU passed through, multi-tenant fabric, managed networking and storage, and a self-serve API. Higher still is managed. The operator runs the orchestration plane for the customer (managed Slurm, managed Kubernetes, validated training stacks, active health checks, automatic node draining) and prices that operational labor. At the top is serverless. The customer never sees a node: they send a request or a function, the platform scales GPUs up from zero and back down, and the meter runs in milliseconds.

Each step up the ladder trades margin for responsibility. Each rung adds operator-owned software and operator-carried risk, and each adds a price you can charge for it. On list price, a serverless second of the same H100 costs more than the matching slice of a bare-metal hour. Depending on how bursty the workload is, the premium the customer actually pays per useful hour can end up larger or smaller than that list-price premium. The premium is not arbitrage: it pays the operator for absorbing the scheduling, idle-time, cold-start and goodput risk that the bare-metal customer would otherwise carry. The question is which risks you want to own and charge for, and which you want to push to the customer at a lower price. → multi-tenancy mechanics in Chapter 10.3; provisioning automation in Chapter 10.5.

The moment you sell anything above dedicated bare-metal, you must decide how tenants share hardware. The isolation model you pick is at once a security boundary, a noisy-neighbor boundary and a billing-granularity boundary, and the three pull in different directions. The taxonomy runs from hard to soft. Physical / bare-metal isolation gives each tenant a whole node or cluster. It is the strongest boundary and the coarsest billing unit (you cannot sell a fraction of a node), with no on-node noisy-neighbor risk. Shared storage, the fabric and the control plane still contend, so a dedicated node is a compute-exclusivity claim, not a contention-free one. VM-level isolation with GPU passthrough multiplexes tenants per host behind a hypervisor. The boundary is strong, but the east-west fabric and shared storage become the contended surface. Fractional isolation lets you sell a slice of a single GPU at fine billing granularity when workloads cannot saturate a device. It comes in two forms: NVIDIA MIG (hardware-partitioned) and time-slicing/MPS (software-shared). Continuous request batching and multi-adapter serving on full GPUs offer another utilization path, while frontier models can consume whole multi-GPU domains. Choose fractional isolation when the finer billing unit outweighs its weaker security and noisy-neighbor boundary.

Fractional sharing is a billing enabler and a security liability at the same time. MIG partitions are hardware-enforced and the strongest of the sub-GPU options. Time-slicing and MPS are not robust confidentiality boundaries, and peer-reviewed covert and side channels cross both MPS and MIG boundaries (a covert channel through the shared TLB, CCS 2023; L2 cache interference between MIG instances, USENIX Security 2026). Real vGPU CVEs, such as the 2025 NVIDIA vGPU advisories, show that partitioning alone is not a security boundary you can sell to an adversarial multi-tenant workload. If your tenants are mutually untrusting (a public neocloud), you owe them bare-metal or VM isolation or hardware-attested confidential computing, and you give up the finest billing granularity. Attestation proves the configured stack, not the hall. TEE.fail (2025) used a memory-bus interposer to pass NVIDIA GPU attestation with the workload running outside the TEE, and Intel and AMD put physical attacks out of scope. Physical custody of the server therefore stays inside the tenant’s trust case (→ Chapter 11.5). If your tenants are one organization (an internal platform), fractional sharing is the right efficiency lever and the security objection mostly evaporates.

On rack-scale systems such as GB200 and GB300 NVL72, the sellable unit is often the NVLink domain rather than the node. By default NVIDIA configures the rack’s 72 GPUs as a single NVLink partition, so every tenant placed on that rack shares one scale-up domain. To sell a sub-rack slice, the operator splits the domain into partitions built from compute trays, using NVIDIA’s NMX NVLink management software; GPUs in different partitions cannot open NVLink connections to each other. NVIDIA’s own documentation is explicit that the scale-out network and storage sit outside the partition boundary and need isolation of their own. Physically, every partition still draws on the same NVSwitch trays, power and cooling in the rack. A rack-level SLA rule (below) has to be restated per partition once one rack serves several tenants. → isolation engineering and its failure modes: Chapter 10.3; protecting models and weights in use: Chapter 11.8; NVLink domain discovery and scheduling: Chapter 10.2.

Productization means putting an API in front of the cluster so a customer can self-serve the lifecycle (request capacity, provision an environment, run a job, observe it, tear it down) without a human in the loop. The control plane behind that API is the difference between a colo full of GPUs and a cloud. Below the API sit the bring-up automation from Chapter 10.5 (Redfish/IPMI, PXE, image pipelines, infrastructure-as-code), the scheduler from Chapter 10.1 (Slurm or Kubernetes, with fair-share, quota and preemption), and the telemetry from Chapter 10.6, which feeds the meter and the health dashboard. The product decision is how much of that surface you expose. A bare-metal vendor exposes node lifecycle. A managed vendor exposes a job-and-cluster abstraction and hides the nodes. A serverless vendor exposes only a function or an inference endpoint.

Get the control plane wrong and you pay in operational labor that should have been software. Every manual step between 'customer clicks provision' and 'job is running' leaks margin and adds to TTFJ. The market’s maturity benchmark, SemiAnalysis’s ClusterMAX rating, tests exactly this: version 3.0 (September 2026) rates providers across ten criteria categories, and orchestration, lifecycle automation and monitoring are among the things it tests hands-on. A neocloud that brings up nodes by hand cannot hit a serverless cold-start budget or a managed-Slurm SLA, and it cannot scale sales without scaling its NOC headcount in step. The control plane is where productization either compounds (software that serves the next 1,000 customers at near-zero marginal cost) or fails to (a services business whose headcount grows with revenue).

Marketplaces add a sales channel above the control plane. NVIDIA’s DGX Cloud Lepton, announced in May 2025, lets developers buy GPU capacity from participating NVIDIA cloud partners, on demand or long term, through one NVIDIA interface. Listing there brings demand a smaller operator could not reach alone. The cost is control: the marketplace shapes the workflow the developer sees, and the vendor that supplies your GPUs now also stands between you and your customer.

Facility availability is the easy SLA to write: a monthly powered-and-reachable commitment, familiar because the market still quotes the retired Tier availability percentages that Uptime Institute itself disavows (Chapter 12.1). The SLA the customer actually values is goodput: useful work delivered within the agreed quality and service limits or, as a time fraction, the share of contracted wall-clock GPU-time that moved the customer’s job forward. For a training tenant, a node that is 'available' but flapping, throttling or failing NCCL all-reduce is worthless. What they bought was effective training time, measured against the job account in Chapter 14.1. The guide’s stipulated 90%-versus-96% pair is for sensitivity tests; your own measured goodput sets the contract baseline. The gap between those two SLA shapes is the gap between selling capacity and selling outcomes.

The trade is direct: the SLA shape you choose dictates which failures you pay for and how much you must invest to avoid them. Commit only to facility availability and redundant power and cooling meet your obligation. The customer eats the goodput loss from a bad GPU or a fabric brownout, and you compete on price. Commit to goodput and you must build the whole fault-tolerance loop (active health checks, fast node draining, automatic restart-from-checkpoint, burn-in and acceptance testing), because every percentage point of badput is now a credit you owe. For one large-LLM pretraining scenario on 5,184 GB300 GPUs, SemiAnalysis’s April 2026 cluster-cost model puts the goodput expense (the extra rental time or lost output that failures and recovery cost) at about 6–21%, depending on the provider tier and the fault-tolerance method it assumes. The engineering that shrinks it is optional spend for a capacity vendor and mandatory for a goodput vendor. The credit schedule is where this gets priced: tiered service credits (for example 10% of the affected charges below 99.9%, escalating with the miss) must be calibrated against your actual goodput distribution, or the credits from one bad month can exceed the margin the contract earns that month.

Rack-scale systems need a rack-level failure rule. For GB300 NVL72, the pattern SemiAnalysis sees most often in its own advisory work is a per-node SLA in which the rack as a whole is treated as down when at least 3 of the 18 compute nodes in it fail together (ClusterMAX 3.0, September 2026). SemiAnalysis also proposes standard SLA terms: downtime measured from both sides, exclusions for upgrades, security patches and physical maintenance, and buyer rights to terminate after sustained downtime or a missed acceptance date. → contract depth in Chapter 12.4; goodput-vs-availability engineering in Chapter 12.2; the fault-tolerance loop in Chapter 10.7.

The billing model is where the consumption decision becomes cash. It spans a spectrum from pure spot to take-or-pay that mirrors the value-stack ladder in a second dimension. On-demand bills per second or per hour at the highest unit rate with no commitment: the customer pays for optionality and you carry the utilization risk of an unfilled fleet. Spot / preemptible sells interruptible capacity at a steep discount to drain idle inventory (Google documents a 60–91% discount to on-demand on most machine types and GPUs, and smaller ones on its A3 H100 machines). The customer carries the interruption risk. Checkpoint-tolerant training and batch absorb it directly. Online inference can absorb it only as a supplemental tier, backed by standard or capacity-reserved headroom, rapid ejection, and an admission and fallback policy. A term/price commitment commits the customer to months or years of spend for a discount; it does not by itself guarantee capacity. A capacity reservation makes the separate capacity promise: holding hardware for a tenant ('is it mine?') is a different promise from committing to pay for it ('have I agreed the spend?'), and mature platforms expose them as distinct objects. At the far end, take-or-pay obligates the customer to pay for a contracted block whether or not they use it. It converts merchant utilization risk into contracted revenue and underwrites the debt capacity behind the build.

The on-demand / spot / committed-price / take-or-pay split is a risk-transfer dial, and where you set it determines your debt capacity and whether you survive a downturn. A fleet sold entirely on-demand is maximally flexible for customers and maximally exposed for you: fewer sold GPU-hours or a lower realized rental price cut contribution while fixed operating cash and scheduled debt service stay due. Compare the capacity commitment using Chapter 1.8’s matched cash-flow case, then stress merchant receipts against the debt schedule in Chapter 2.5’s DSCR case. A fleet anchored by take-or-pay has transferred that utilization risk to tenants, which is why lenders price GPU-backed debt against contracted backlog rather than merchant hope. Take-or-pay carries its own exposure, concentration: a backlog that lives in two or three anchor tenants converts utilization risk into counterparty risk, and one non-renewal can strand a campus.

Two 2026 developments extend the dial past the tenant. On NYMEX, CME and Silicon Data have applied to list H100 and B200 rental-index futures, settled in cash. Their 2026-10-05 target slipped after the CFTC extended the review period to 9 November 2026. As of mid-October 2026, neither contract was trading. If one lists, it would be the first US-regulated futures contract on the GPU rental price (the $/GPU-hr this chapter models). Thinner products already trade: offshore perpetuals, and event contracts on GPU rental prices at a CFTC-regulated exchange. Until a deep regulated market exists, the practical hedge is the terms of the customer or offtake contract, not an exchange product. The second development is that SemiAnalysis describes an NVIDIA neocloud rental backstop, a multi-year minimum-revenue guarantee on GPU capacity with upside shared above the floor. It puts the chip vendor itself into the offtake column that lenders underwrite. A backlog that includes the vendor of the collateral is leverage and concentration at once (→ the circular-financing analysis in Chapter 2.5).

The metering substrate underneath all of this is itself a competitive axis: per-second granularity, per-token billing for inference, transparent egress and no surprise fees. ClusterMAX counts pricing in its overall provider ratings, and hidden egress fees and rounding games are a fast way to lose a buyer’s trust. → the firm-level unit economics of this revenue (metered $/token and $/GPU-hr to margin) are worked in Chapter 1.8.

Time-to-first-job (TTFJ) is the conversion metric of the whole business: the wall-clock time from 'customer signs up' to 'customer's first useful GPU job is running'. On a bare-metal rung, TTFJ is dominated by node provisioning, image deployment, driver and NCCL setup, and acceptance burn-in. A manual operator measures it in days and an automated one in hours, and that gap is pure product quality. On a serverless rung, keep the nested measures separate. End-to-end TTFJ still starts at signup/entitlement/configuration and ends when the first useful job is running. Image or model cold start starts when an eligible request needs an unready worker and ends when that worker is ready. Request TTFT starts at the inference request and ends at the first token, with the warm or cold state recorded. Published seconds-to-token or cold-start figures describe those narrower populations; they do not replace onboarding TTFJ.

Onboarding automation is the marginal-cost structure of the product. Each manual onboarding step caps how many customers one engineer can land, so growth moves at the speed of hiring. The fix is the same automation that backs the control plane: IaC-driven provisioning, self-serve quota and RBAC, pre-validated stacks, and acceptance tests that run without a human. Then the 1,000th customer onboards as cheaply as the first.

Vendor tooling now covers parts of this path. NVIDIA released or extended open-source components for onboarding in October 2026: a Cluster API provider that deploys bare-metal nodes and onboards tenants, a Cluster Readiness Engine (open-sourced in September 2026, v0.7.0 announced at OCP in October 2026) that runs workload simulations against a cluster before training starts and reports failing nodes without cordoning or modifying them, a Rack Management Service, and a Config Manager, which is still a developer preview and not for production. Before building on any of them, weigh their maturity, their dependence on NVIDIA hardware, and who owns rack-level maintenance windows. → provisioning in Chapter 10.5; acceptance in Chapter 10.6.

The productization lifecycle that follows TTFJ is the long tail: usage growth, expansion to reserved or committed capacity, support tiers, and the metering that bills it all. It never starts if TTFJ is bad, which is why TTFJ is the first thing a sophisticated buyer tests with a trial workload before committing budget.

The decision most operators underweight, and the best buyers check first, is offboarding and portability. A customer weighing a multi-year, take-or-pay GPU commitment is implicitly asking 'how hard is it to leave?', because the answer prices their lock-in risk into the deal. Portability has three parts. Data egress: can I bulk-export my datasets and checkpoints without a punitive egress bill or a multi-week throughput bottleneck? Stack portability: is my orchestration standard (vanilla Slurm or Kubernetes, OCI containers) or a proprietary control plane that traps my workflows? Commitment exit: does my reserved or take-or-pay block have real termination economics or a secondary market, or am I locked to a depreciating asset for the full term? The conclusion is counterintuitive: a credible, low-friction exit story is a sales asset, not a risk. An operator who builds on open standards and clean egress wins the cautious enterprise buyer, because the absence of lock-in lowers the buyer's perceived risk of signing. A secondary market for reserved blocks (an emerging structure for reserved-capacity trading) can offer a transfer route only where the contract permits assignment and an eligible buyer exists. Verify the exported checkpoint and manifest by restoring them under the agreed format, then close access, retention and deletion under Chapters 11.9 and 10.10. A GPU resale market does not establish customer portability.

Everything in this chapter resolves into a single revenue line that Chapter 1.8 turns into a return. The value-stack rung helps define your unit, the isolation model constrains how it is shared, the SLA shape sets your reliability spend and credit exposure, the capacity model sets how much revenue is contracted versus merchant, and TTFJ affects conversion. Together they determine metered revenue per token and per GPU-hour. Net of the cost stack from Part 5 through Part 9 and the depreciation debate from Chapter 1.8, that revenue contributes to the margin the service earns. Keep paid standby, support, retries and credits in the same period as revenue. Read this chapter as the revenue-side complement to 1.8's cost-side analysis: 1.8 asks whether the asset earns its cost of capital, and this chapter decides how the revenue behind that question gets priced, packaged, metered and collected. The recurring warning from 1.8 applies in full here: underwrite metered revenue with explicit price and demand sensitivities over the contract term, because a historical inference-price series does not prescribe this service’s annual decline. → inference serving efficiency, the governor of $/token, is engineered in Chapter 10.11; data-handling obligations that ride alongside the commercial contract are Chapter 10.10.