How to buy AI compute: eight questions to ask
Most AI capacity is sold with a price per unit and a promise. The price is easy to compare. The promise is where buyers get caught out.
If you're buying AI capacity for your business, here are the things worth asking any provider, us included, before you sign. Each one comes with the reason it matters and what a good answer looks like.
You can use the list as it is in a request for proposal, or keep it next to you on a sales call. None of it needs technical knowledge. The answers will tell you a lot about a provider, and the way they answer will tell you even more: a provider who is clear before you sign is usually clear afterwards too.
1. Where will my work actually run?
Ask for named locations. You want to know the country, ideally the city, and whether that can change without telling you.
Why it matters: location decides how long answers take to reach your users and which rules apply to your data.
A good answer: a clear list of where your requests can run, and a way to restrict them to the places you choose.
2. Can I choose, and can I prove it?
Choosing a location is one thing. Being able to show an auditor, a customer or your own board where the work ran is another.
Why it matters: "we process data in the EU" is a sentence. A record that shows each workload's placement is evidence.
A good answer: a record per workload, or per batch, that shows what was committed, where it ran and what was delivered.
3. What exactly am I paying for?
AI prices come in different units: per request, per token, per hour of a machine, or a reserved block of capacity. Ask the provider to put their offer in the unit you will actually use, and to show what's included.
Why it matters: two prices that look similar can describe very different things. One may include networking and storage; another may charge for each separately.
A good answer: a price in your unit, a list of what's extra, and the date the price was set.
4. What happens when demand spikes?
Ask what happens if you suddenly need twice as much, or if everyone else does.
Why it matters: in a busy market, capacity that was available last week may not be there today. Some providers queue requests, some throttle them, some charge more.
A good answer: a plain explanation of how capacity is reserved, how you're told if it runs short, and where your work goes if one site is full.
5. What happens when a site goes down?
Every site has problems sooner or later: power, cooling, network, hardware. Ask what your users will notice.
Why it matters: a single location means a single point of failure. Capacity spread over several sites can move work elsewhere.
A good answer: where the work fails over to, whether that respects your location rules, and how you'll find out.
6. Which models can I run?
Some providers offer one family of models; others let you bring your own, including open models.
Why it matters: the model you need today may not be the one you need next year. Being locked to one supplier's models limits your options on cost and quality.
A good answer: a list of supported models, a way to run open models, and how quickly new ones are added.
7. What's kept, and for how long?
Ask what happens to your prompts, files and outputs after a request: are they stored, logged, used for training, or deleted?
Why it matters: your customers will ask you the same question.
A good answer: a short written policy, the default retention, and a setting you control.
8. How do I leave?
This is the question buyers forget. Ask what it takes to move your work elsewhere: notice periods, data export, minimum terms and any fees.
Why it matters: the right time to agree exit terms is before you need them.
A good answer: clear notice periods, your data returned in a usable format, and no surprise charges for leaving.
A one-page checklist
Before you sign, make sure you have answers to these, in writing:
- Where can my work run, and can I restrict it?
- What record will I get of placement and delivery?
- What unit am I paying in, what's extra, and what date is the price from?
- How is capacity reserved, and what happens when it's short?
- Where does work go if a site fails?
- Which models are supported, including open ones?
- What's kept, for how long, and who can see it?
- How do I leave, and what does it cost?
If a provider can't answer one of these clearly, that's information too.
Eight questions, in five groups
- Location and proofWhere work can run, and a record of where it did.Questions 1 and 2
- Price unitThe unit you pay in, what is extra, and the price date.Question 3
- Spikes and outagesHow capacity is reserved, and where work goes if a site fails.Questions 4 and 5
- Models and dataWhich models run, and what is kept and for how long.Questions 6 and 7
- ExitNotice periods, data export, minimum terms and any fees.Question 8
Why we publish this
We'd rather buyers asked hard questions, because the questions point to how AI capacity should work. We're building Starfield Fabric to deploy standardized compute close to power, connectivity and demand, and to connect it through one programmable network for AI inference. It is designed to place workloads by policy, on latency, data residency, model and load, and every workload can generate an auditable record of commitment, placement and delivery.
We're designing it so these answers come with the service.
Site owners can read what hosting AI capacity involves, and installers and operators can see where partners fit.
If you're planning AI capacity and want to talk it through, use Request capacity below.
Related
Starfield Fabric · Host a data center? What hosting AI capacity involves · Edge data center partners: where each one fits