Four engagements. No percentage of savings, ever.

Three numbers, produced live on the call:

• Amortized GPU spend for the last full month, per resource.
• What share of it carries no owner tag.
• How many provisioned GPUs have zero pods requesting nvidia.com/gpu.

That third number needs no new instrumentation. If kubectl describe node shows 0 of 8 GPUs allocated, utilization is zero by definition and no telemetry can argue with it.

The snapshot needs no credentials of any kind. Your own engineer runs the collection script and sends back the one JSON file it writes by a link from your own file share, so nothing is granted to anyone outside your team. It is a plain shell script that reads node and pod data with kubectl and installs nothing, and it is published here to read before anyone runs it, next to the RBAC it needs. The file is plain JSON, so you can read every line before sending it, and on request we sign a mutual NDA first. An IAM role, an access key, a console login or a kubeconfig is declined if offered.

Hard scope limit: three numbers and a conversation. No document, no recommendations, no remediation. If you want any of that, it is Tier 2. This is not a trial that expands; it is forty-five minutes that tells us both whether the rest is worth doing.

• Amortized cost per GPU resource, per team, per namespace.
• Ranked recoverable spend, each line carrying a dollar figure and a confidence rating.
• Evidence gaps stated explicitly: what cannot be claimed yet and exactly which data would close each one.
• The order of work, ranked by recoverable dollars per unit of disruption.

If you have no GPU telemetry today, the report includes the instrumentation plan to get it, specified to the exporter version and the scrape config.

How the cluster side is collected

Not with one reading. Your own scheduler, cron on a machine you control or a scheduled job on your CI runner, runs the same published collection script every 15 minutes for a week, or through the whole month if you would rather collect that long. One scheduler, writing into one folder, against one cluster. The script only reads: three kubectl get commands. The access is read-only when the identity it runs as holds nothing more than the RBAC grant published beside it: list on nodes and pods, and get on the kube-system namespace. That file binds the grant to a service account it creates; if your runner reaches the cluster as an identity of its own, you bind the same read-only role to that identity instead. Which identity, and the credential behind it, are your call and yours to hold; we never see either. Nothing is installed in your cluster and nothing runs there: no agent, no pod, no CronJob. The one change is RBAC objects that run nothing, which you apply and remove yourself: the three in that file (a service account, a read-only cluster role and its binding), or that role bound to your runner's own identity, plus whatever token you issue if you use the service account. On EKS, have the runner sign in with its own AWS role through an access entry: a token from kubectl create token there lasts at most 24 hours, whatever duration is requested. We have run that sign-in path once on EKS, in October 2026; it has not yet run unattended on a schedule for a full week. The files carry your node and pod names, every node and pod label, and the scheduler's messages, so they stay with you until the NDA is signed. Then you send them by a link from your own file share: the collector writes JSON files, and a download link made in your own AWS account opens one file at a time. A gap in the runs is not filled in; it costs the hours it missed.

The confidence framework

Every finding is marked, and the marking is enforced in the tooling rather than promised in a footnote.

Proven is a state a finding reaches, not a property of your bill. The size of that column is set by how much of the period the evidence covers, which is a thing we control and tell you about rather than a thing your bill decides. A finding counts as proven only for the hours the collector actually watched, so a single reading converts none of it, a week converts about a quarter of a 30-day month (168 of 720 hours), and a full month converts nearly all of it. On the specimen's cluster that is $14,101 a month proven at seven days against $60,432 at a full month, from the same export. Ask what coverage your engagement had, and the answer will be in the report.

Unproven dollars are excluded from the recoverable total. That exclusion lives in code because under client pressure discipline is the thing that bends. The competing document quotes one confident figure that does not survive its first contact with a skeptical staff engineer. Ours is lower, and it is built to hold up in the room.

Excluded: any change to your infrastructure. This tier produces a document. Nothing is changed beyond the read-only RBAC grant you apply and remove. Also excluded, deliberately, so that a week is a week: stakeholder interviews, per-model custom attribution, and a remediation plan built with your team.

If one week is not enough

One week fits up to two payer or linked accounts, one cluster, and a CUR 2.0 export that is already running; beyond that, we say so before you sign. Some environments need the excluded work. Stakeholder interviews, per-model attribution and a full remediation sequence make this a two-week report at $15,000 to $25,000, set by the four inputs below. It is offered on request, and most environments do not need it.

Typical specs, each one applied by your team:

• GPU telemetry: which DCGM exporter fields to turn on, how Prometheus scrapes them, and per-workload attribution that survives a pod restart.
• Request sizes set against measured p95 plus headroom, not against what someone guessed at deployment.
• A time-slicing or MIG partitioning plan for workloads genuinely small enough to share a card.
• Bin-packing and autoscaler settings that let scale-in actually happen instead of being blocked by one unevictable pod.
• After every change window, a check of each change against the next bill.
• A commitment sizing plan for Savings Plans and reservations, set against usage after the changes rather than before.

Plus a spot migration plan for interruption-tolerant training, and idle reclamation policies with owner notification so nothing disappears without a human being told.

Not offered: hands-on implementation of any kind. We do not apply changes in your systems, edit model or training code, refactor applications, migrate between clouds, or touch production traffic routing.

Without a named owner on your side who can apply the changes, the Sprint stops at the spec, and we say so before you sign.

Right-sizing that runs once at deployment is not right-sizing. Workloads change, traffic shifts, and a configuration that was accurate six months ago almost certainly is not now.

• Quarterly attribution report and drift analysis against the same baseline.
• Alerting on new unowned GPU spend and on allocation without utilization.
• Commitment review: Savings Plans, reservations, capacity blocks.
• A standing engineering channel and a quarterly review with your leadership.

Quarterly rather than monthly is deliberate. It matches how fast the underlying problem actually drifts, and at roughly 8 to 10 percent of a qualified client's annual GPU spend it stays defensible against savings already delivered.

Excluded: on-call, incident response, anything carrying a response-time commitment. This is advisory with artifacts, not managed services.

The diagnostic is $3,500 whatever your environment turns out to look like. There is no range to land in and no repricing afterwards. If the work will not fit in a week, we say so before you sign.

Four inputs decide where the two-week report sits in its range, and the same four shape a sprint. All are established on the qualifying call:

• Linked accounts. One payer with one account is not six accounts with inconsistent tagging.
• Billing readiness. Whether a CUR 2.0 export at hourly granularity with resource IDs already exists, or has to be stood up and backfilled.
• Cluster count. Each additional cluster is another allocation join and another set of provider IDs to reconcile.
• Telemetry. Whether any GPU profiling metrics are running today, or whether the instrument has to be built before it can be read.

A single account with billing already exported and telemetry running sits at the bottom of the band. Six accounts, three clusters and no telemetry sits at the top. You will know which before you sign anything.

Terms

• Fixed fee. The $3,500 diagnostic is invoiced in full at kickoff. Due on receipt; work starts when it's paid. Engagements of $15,000 and up, other than Cost Watch, are invoiced 50 percent at kickoff and 50 percent on delivery. Cost Watch is invoiced quarterly in advance. It has a two-quarter minimum, and notice may be given during the minimum. Notice given in the first quarter still leaves the second quarter invoiced; after that, notice given at least 30 days before a quarter ends stops the next quarter's invoice. A prepaid quarter runs to its end.
• Mutual NDA signed before you send files for a paid engagement; for the free Snapshot, on request.
• No credentials at any tier. You run the exports (CUR 2.0 and the collector) and send the files, so there is no access to revoke at the end.
• You send each billing file as a download link you create in your own AWS account. The link opens that one file and nothing else, for whoever holds it, until it expires: at most 12 hours if you make it in the S3 console, up to 7 days from the AWS CLI, and sooner if it is signed with temporary credentials. We download it the day it arrives. A link from your own file share works too. The collector's output is a JSON file; send it by a file-share link. We never ask for credentials or bucket access.
• Your data stays yours. Your files are deleted within 30 days of close-out. We keep only the deliverable, stripped of account identifiers, the signed contracts and a dated record of the engagement.