Customer Onboarding, Delivery & Productization

Every chapter in Part 10 builds the machine; this is the chapter that turns the machine into a product someone can buy. The orchestration plane, the multi-tenancy isolation, the provisioning automation, the health telemetry, the fault-tolerance loop, the training frameworks — all of it is internal plumbing until it is wrapped in a consumption model, an API, an SLA, a billing meter, and an onboarding path. Productization is the act of drawing a clean line between what the operator owns and what the customer owns, and then pricing the responsibility on each side of that line. Draw the line in the wrong place and you either give away margin you should have kept or carry risk you should have transferred.

We lay out the value-stack ladder from bare-metal to serverless and show how each rung moves the boundary; we work the multi-tenancy and isolation fork as a joint security/noisy-neighbor/billing decision; we build the control plane, API, and provisioning surface that makes the product self-serve; we separate facility availability, usable capacity and managed useful output, then identify which SLA the operator controls and the customer buys; we map the billing and capacity spectrum from spot to take-or-pay; and we close on 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 very different altitudes, and picking the altitude is the commercial decision everything else in this chapter follows from. At the bottom is bare-metal: you hand the customer a dedicated, single-tenant node (or a whole cluster) with raw access to the hardware, an OS image, and a network fabric — and almost nothing else. You keep a thin margin on raw capacity, you carry no software risk, and 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, 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 the operational labor. At the top is serverless: the customer never sees a node at all; 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 is a systematic trade of margin for responsibility. Each rung adds operator-owned software and operator-carried risk, and each rung adds price you can charge for it. A bare-metal hour and a serverless second of the same H100 can differ by an order of magnitude in effective $/GPU-hr, and the difference is not arbitrage — it is the operator absorbing scheduling, idle-time, cold-start, and goodput risk that the bare-metal customer would otherwise carry themselves. 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 have to decide how tenants share hardware — and the isolation model you pick is simultaneously a security boundary, a noisy-neighbor boundary, and a billing-granularity boundary. These three pull in different directions, which is why the decision is harder than it looks. The taxonomy runs from hard to soft. Physical / bare-metal isolation gives each tenant a whole node or cluster — the strongest boundary, the coarsest billing unit (you cannot sell a fraction of a node), and 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 — NVIDIA MIG (hardware-partitioned) or time-slicing/MPS (software-shared) — lets you sell a slice of a single GPU and expose fine billing granularity when workloads cannot saturate a device. Continuous request batching and multi-adapter serving on full GPUs provide 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, but time-slicing and MPS are not robust confidentiality boundaries — documented covert and side channels bypass MPS/MIG isolation, and real vGPU CVEs (e.g. the 2025 NVIDIA vGPU advisories) have shown that partitioning is not, by itself, a security boundary you can sell to an adversarial multi-tenant workload. So if your tenants are mutually untrusting (a public neocloud), you owe them either bare-metal/VM isolation or hardware-attested confidential computing, and you give up the finest billing granularity. If your tenants are one organization (an internal platform), fractional sharing is the right efficiency lever and the security objection mostly evaporates. → the full isolation engineering and its failure modes are Chapter 10.3; model/weight-in-use protection is Chapter 11.8.

Productization is, concretely, the act of 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 that backs that API is the difference between a colo full of GPUs and a cloud. Below the API sits 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 feeding 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.

The consequence of getting the control plane wrong is measured in operational labor that should have been software. Every manual step between 'customer clicks provision' and 'job is running' is a margin leak and a TTFJ penalty; the maturity benchmark in the market (SemiAnalysis ClusterMAX) scores providers in part on exactly this — orchestration, lifecycle automation, and observability are explicit rated dimensions. A neocloud that bring-ups nodes by hand cannot hit a serverless cold-start budget or a managed-Slurm SLA, and it cannot scale its sales without scaling its NOC headcount linearly. The control plane is where the 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).

The easy SLA to write is facility availability — a monthly powered-and-reachable commitment — because the retired Tier availability table Uptime disavows remains familiar in the market (Chapter 12.1). The SLA the customer actually values is goodput — the fraction of contracted GPU-time that produced useful work. 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 named job account in Chapter 14.1. The guide’s stipulated 90%-versus-96% pair tests sensitivity; site measurements set 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 your obligation is met by redundant power and cooling; 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. The April 2026 ClusterMAX model’s ~6–21% goodput expense includes assumed recovery and fault-tolerance overhead; 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 (e.g. 10% of the affected charges below 99.9%, escalating with the miss) must be calibrated against your actual goodput distribution, or a single bad month of badput erases a quarter of margin. → goodput-vs-availability engineering in Chapter 12.2; the contract mechanics in Chapter 12.4; the fault-tolerance loop in Chapter 10.7.

The billing model is where the consumption decision becomes cash, and 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 (60–91% off on-demand at Google's documented band) to drain idle inventory; the customer carries the interruption risk, which checkpoint-tolerant training and batch absorb directly and online inference can absorb only as a supplemental tier backed by standard or capacity-reserved headroom, rapid ejection, and admission/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 — the structure that converts merchant utilization risk into contracted revenue, and the one that 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 your survival of 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 reduce contribution while fixed operating cash and scheduled debt service remain 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 exactly why lenders price GPU-backed debt against contracted backlog rather than merchant hope. Two 2026 developments extend the dial past the tenant: CME and Silicon Data list cash-settled H100 and B200 rental-index futures (target 2026-10-05, pending regulatory review) — the first exchange-traded hedge on the $/GPU-hr this chapter prices in — and SemiAnalysis describes an NVIDIA neocloud rental backstop (a multi-year minimum-revenue guarantee on GPU capacity, upside shared above the floor), which 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). Take-or-pay carries its own exposure, concentration: a backlog that is take-or-pay but lives in two or three anchor tenants converts utilization risk into counterparty risk, and one non-renewal can strand a campus. The metering substrate underneath all of this — per-second granularity, per-token billing for inference, transparent egress, no surprise fees — is itself a competitive axis; ClusterMAX scores pricing transparency as a rated dimension precisely because hidden egress and rounding games erode trust. → the firm-level unit economics of this revenue (metered $/token and $/GPU-hr → margin) are worked in Chapter 1.8.

Time-to-first-job (TTFJ) is the conversion metric of the entire business: the wall-clock 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/NCCL setup, and acceptance burn-in; a manual operator measures this in days, an automated one in hours, and the gap is pure product quality. On a serverless rung, keep the nested endpoints 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 warm/cold state declared. Published seconds-to-token or cold-start figures belong to 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, which caps growth at the speed of hiring. The fix is the same automation that backs the control plane — IaC-driven provisioning, self-serve quota/RBAC, pre-validated stacks, and acceptance tests that run without a human — so that the 1,000th customer onboards as cheaply as the first. The productization lifecycle that follows TTFJ is the long tail: usage growth, expansion to reserved/committed capacity, support tiers, and the metering that bills it all. But the lifecycle never starts if TTFJ is bad, which is why it is the first thing a sophisticated buyer tests with a trial workload before committing budget.

And then there is the decision most operators underweight and the best buyers check first: offboarding and portability. A customer evaluating 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. The portability story 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/Kubernetes, OCI containers — or a proprietary control plane that traps my workflows?), and commitment exit (does my reserved/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. The operator who builds on open standards and clean egress wins the cautious enterprise buyer precisely because the lack of lock-in lowers the buyer's perceived risk of signing — and 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 its sharing boundary; the SLA shape sets your reliability spend and your credit exposure; the capacity model sets how much of your revenue is contracted versus merchant; and TTFJ affects conversion. Together they determine metered revenue per token and per GPU-hour, which — net of the cost stack from Part 5 through Part 9 and the depreciation debate from Chapter 1.8 — contributes to the margin the service earns; keep paid standby, support, retries and credits in the same period as revenue. The clean way to read this chapter is as the revenue-side complement to 1.8's cost-side analysis: 1.8 asks whether the asset earns its cost of capital; this chapter decides how the revenue that feeds that question actually gets priced, packaged, metered, and collected. The recurring warning from 1.8 applies in full here: underwrite the metered revenue with explicit price and demand sensitivities over the contract term; 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.