Sai Ram

AI workload cost assessment

Five working days to measure one AI workload's cost per successful task and compare the agreed options against your quality, latency and cost targets.

Who it is for

Teams with an AI feature or agent in production, or close to launch, whose AI costs are growing or who need a cost estimate before launch. It works best when the workload has real traffic and one person owns the decision.

What you get

• A cost baseline: an estimate of what one successful task costs today, worked out from your bills and an agreed sample of real requests, counting retries, failed attempts, tool calls, idle capacity and the effort to run it where they apply.
• A quality baseline on your own tasks. You receive the evaluation code, scoring rules and instructions to rerun it on the agreed task sample.
• Your options measured on the same tasks against the same targets: tune what you have (routing, caching, prompt size, a smaller managed model), run your own model, or a mix.
• A recommendation and, where the evidence supports one, the volume or price at which it would change. It may be to keep your current setup.
• If your own model or a mix comes out ahead: a capacity and reliability plan covering replicas, failover and scaling, keeping what was measured in testing apart from what is projected for production.
• A written report, the cost model with the sources and assumptions behind each figure, and a walkthrough with your team.

The sample results dashboard shows what the evidence looks like, built from my own benchmark runs.

How the five days run

• Before day one: we agree what counts as a successful task, which options to test, and which costs to include. The five working days start once usable data, scoring rules and test access are ready.
• Day 1: cost and quality baseline.
• Days 2 and 3: the alternatives, measured on your tasks.
• Day 4: capacity, failure and cost-at-volume checks on the leading option.
• Day 5: written recommendation and walkthrough.

What I need from you

• Usage and billing exports for the workload, ideally the last 30 days.
• A few hundred representative requests with the answers you would accept, redacted as you see fit.
• Your latency and quality targets, or the person who can set them.
• If we test running your own model, GPU time in your cloud account, or in mine passed through at cost.

Billing exports and redacted traces are enough to start. Tests run in an agreed environment. Before you send anything, we agree how data is transferred, where it is processed, who can see it, what it may be used for, and whether any cloud or model provider handles it, including that provider's retention and training settings.

I delete what you sent me, and working files that contain it, within 30 days of delivering the report, or within 30 days of a cancellation. If the work hasn't started 30 days after the data arrives, I delete it then and you can send it again when we're ready. We can agree a shorter window before you send anything, you can ask for earlier deletion at any time, and I confirm in writing what was deleted and whether any copy remains.

Who does the work

Me, Sai Ram. I have spent 15+ years in infrastructure and platform engineering, hold CKA and CKS, and contribute to KEDA, the Kubernetes autoscaler. The method is public in my inference cost benchmark. I'm based in Chennai, India, and work remotely.