A Procurement Handoff Checklist for the Team Running the GPUs

A signed order or provisioned tenant is not an operational handoff. The receiving team needs authority, evidence, and named responsibilities for the service it will run. Start with one accountable operational owner and one procurement owner. Record the effective handoff time, the support boundary, the acceptance state, and any unresolved exceptions. If nobody can say who may approve a quota increase or open a provider escalation, ownership has not transferred.

Hold the handoff against the exact purchased unit. A description such as eight GPUs is insufficient. Capture provider and region, tenancy model, node and accelerator counts, accelerator partitioning if used, CPU, host memory, local and persistent storage, network interfaces, image or operating system, driver and runtime versions, reservation dates, and replacement terms. Link immutable order and configuration identifiers rather than copying fragments from chat.

Build a line-by-line comparison between the order, provider control plane, operating system, and scheduler. Differences can be legitimate, but they must be explained. Record accelerator model and count per node, device identifiers, link topology where relevant, usable storage, network addresses, and labels or taints that influence placement. Do not include secrets in the checklist; reference the approved secret store and access procedure.

For Kubernetes environments, confirm that GPU resources appear on the intended nodes and that a constrained test workload can request them. NVIDIA's GPU Operator 25.3 documentation describes an operator-managed stack that includes the driver, container toolkit, device plugin, and Node Feature Discovery. Whether or not that operator is used, the handoff should identify who owns each equivalent layer and its upgrade policy. If ClusterBid helped match capacity to the measured requirement, retain the selected configuration and sourcing record with this inventory.

List human groups and service identities by function: platform administration, workload submission, read-only observability, billing, and emergency response. Give the receiving team a way to inspect who has each role. Kubernetes recommends assigning minimal rights, preferring namespace-scoped RoleBindings where possible, avoiding wildcard permissions, and reserving cluster-admin for cases that actually require it. Those principles make a better acceptance test than a shared administrator credential.

Test access from the perspective of each role. A workload operator should be able to submit, inspect, and stop an approved job without reading unrelated secrets or changing cluster-wide policy. A billing reader should see usage and invoices without controlling workloads. Record the test identity, time, expected action, actual result, and ticket for any exception. Set a date to remove temporary supplier or implementation access.

Transfer every constraint that can stop work: provider account quota, regional quota, Kubernetes namespace quota, scheduler partition, project allowance, storage limit, API rate limit, and budget alert. State both the configured value and the current consumption. Kubernetes ResourceQuota can limit aggregate namespace requests, including extended resources such as requests.nvidia.com/gpu. That control is distinct from whether physical GPUs are free at a particular moment.

Run a boundary test rather than merely reading configuration. Submit one allowed request, one request that should exceed quota, and one queued request when capacity is occupied. Confirm the error or pending reason is intelligible and that the documented approver can change the quota. Also state the priority and preemption policy. An operator cannot manage an incident if a production workload's right to displace a research job exists only as an unwritten convention.

A receipt should identify the node set, image digest, model or diagnostic artifact, command or job specification, start and end time, and raw output location. Include basic device discovery, container access, a representative single-node run, and any multi-node communication or storage test promised in the purchase criteria. Preserve failed results and the remediation ticket. A screenshot of a green dashboard is not enough to reproduce the condition.

Use a measurable acceptance rule. For example: all purchased accelerators must be schedulable; the representative job must complete three consecutive runs; each run must meet the pre-agreed correctness check; and throughput must remain within 5 percent of the accepted reference after normalizing for the documented workload. This is an illustrative rule, not a universal benchmark. The parties should set thresholds before the test and record any known variance.

Consider an illustrative eight-GPU deployment across two nodes. Inventory reconciliation finds eight devices, but the production namespace quota permits only six. The workload role can submit jobs but cannot read pod logs, and the billing role has not been assigned. Three acceptance runs complete, with normalized throughput differences of 0 percent, 3 percent, and 4 percent from the agreed reference. Hardware and performance pass the illustrative 5 percent rule, while quota, logging access, and billing access remain open.

The handoff decision is conditional rather than vaguely complete. Operations can accept technical custody after the quota is raised to eight and the workload role passes its log-reading test. Financial ownership remains with procurement until the billing role is proven. The decision log names owners and due dates for both gaps. This prevents a successful compute test from hiding an inability to operate or allocate the service.

Record the legal account name, billing account identifier, cost center, invoice recipient, usage-export location, dispute window, and the person authorized to question a charge. Keep contract documents in their controlled system and link them. Operations should know which usage tags or project identifiers it must preserve so finance can reconcile consumption with the purchased allocation.

The incident card should contain the provider support portal, entitlement or severity rules, internal on-call route, status page, maintenance notification channel, and the evidence required for escalation. Include node and cluster identifiers, timestamps with timezone, workload ID, relevant logs, and recent changes. Avoid copying credentials into the card. Define who may stop workloads, drain a node, approve failover spend, and communicate user impact.

Use a simple exit rule: every required row is Pass, Accepted Exception, or Not Applicable; every exception has an owner and due date; and an operator who did not implement the environment can complete the access, quota, test, billing, and incident drills from the linked material. If any critical action still depends on an unnamed person or private message history, the handoff remains open.

A checklist cannot prove future reliability, provider responsiveness, or workload fitness beyond the tests performed. It also goes stale after configuration changes. Assign a review trigger for driver upgrades, tenancy changes, quota changes, renewal, or ownership turnover. The handoff then becomes the first operational baseline rather than a ceremonial final meeting.

Role Based Access Control Good Practices

Resource Quotas

Installing the NVIDIA GPU Operator version 25.3.0

Rubin R100 GPU Procurement Guide 2026: What AI Teams Should Buy Now vs Wait For

AI Audio and Speech Model Deployment: Whisper, ElevenLabs, Bark GPU Inference