How to choose an AI inference provider

When people buy a used car, most follow the same order without thinking. Where is it? What is its history? What will it really cost? Could I sell it again? Skip a step and the surprise comes later, usually at a worse moment.

Choosing an AI inference provider works the same way. Inference is the work of answering requests with a trained model, every time someone uses it. (We cover the basics in What is AI inference? Explained without the jargon.) This piece is a short checklist, in the order a buyer tends to meet each question: location, records, pricing terms and exit.

Start with location

The first question is where your requests will be processed. Not where the company is based, and not where your data is stored. Those can be three different places. (We look at this in Data processing location: stored here, processed there.)

Location matters for two reasons. Distance affects how long an answer takes to come back. And some data comes with rules about where it may be handled.

Ask:

1. Where, exactly, will my requests run?
2. Can I restrict processing to a country or region I choose?
3. If a site is busy or down, where does my work go instead?
4. How will you show me where it ran?

Listen carefully to the last answer. Location is usually attested, which means the provider states it and records it. That is useful, but it is still a statement you are trusting, so ask what it rests on.

Nothing here is legal advice. Your own adviser should tell you what your rules require. (For a short primer, see Data residency for AI inference, in one page.)

Then ask about records

Once you know where work is meant to run, ask how you will know it did. A useful record answers three things: what was agreed, where the work was placed, and what was delivered.

Many buyers only meet this question after something goes wrong. A disputed bill, an audit, or a customer asking where their data went. It is much easier to ask before you sign. (We describe one approach in AI audit trail: a receipt for AI work.)

Granularity. Are records kept per request, per hour or per month?

Access. Can you export them yourself, or do you have to ask someone?

Retention. How long are they kept, and who else can see them?

Read the pricing terms, not just the price

The headline price is usually the first number a buyer compares. It is rarely the whole story. The same task can be priced in quite different ways. (We compare the layers behind a quote in AI inference cost: why one task gets different prices.)

Start with the unit. Per token, per request, per machine hour and a reserved block of capacity all behave differently as your use grows. A unit that looks cheap at low volume can look very different at peak.

Then ask what is not on the quote. Data transfer, storage, support levels and minimum commitments can all change the real cost. (See Hidden costs of AI capacity that aren't on the quote.)

Finally, ask for the date. A price without a date cannot be compared fairly or checked later. (We explain why in LLM API pricing: why we publish dated prices.) For dated, public price and speed data across models, Starfield's Model Watch is one place to start.

Plan the exit before you enter

The last question is the one buyers most often skip: how would I leave? Asking it is not pessimism. It keeps the other answers honest, because a provider you cannot leave has less reason to keep its terms fair.

1. Can I move my workloads elsewhere without rewriting them?
2. Can I take my records with me, in a format I can read?
3. What notice and fees apply if I reduce or end my commitment?
4. Is any part of the setup tied to tools only this provider offers?

If the answers are vague, write them down and ask again in writing. Clear exit terms can be a good sign about the rest of the contract.

Putting the order together

Each step narrows the next. Location rules some providers out, records rule out others, and pricing and exit terms show what you are really committing to. A short written comparison, one column per provider and one row per question, is often enough. Leave a cell blank rather than guess. For the wider buying questions, see How to buy AI compute: eight questions to ask.

What we are building

Starfield deploys standardized compute close to power, connectivity and demand, and we're building one programmable network to connect it for AI inference. Workloads are designed to be placed by policy, on latency, data residency, model and load, and every workload is designed to generate an auditable record of commitment, placement and delivery.

If you are comparing inference providers, use Request capacity below.