Choosing an inference provider when location is a requirement

There is a healthy market of OpenAI-compatible inference providers, and for most teams the honest advice is to use one of them. They are cheap, fast and well documented, and switching between them is a base URL and a key.

This post is about the case where that advice stops applying: when the question is not what a token costs but where it was computed, and in what currency you are billed for it.

What the aggregators optimise for

An aggregator's value is reach. It fronts many providers, routes each request to whichever has capacity at a good price, and gives you one API and one bill for all of them. The location of the machine is deliberately not part of the interface, because the design assumes it does not matter to you.

When it does matter, that abstraction is the problem rather than the feature. You cannot select for a property the API does not model, and you cannot evidence it afterwards.

The questions to ask any provider

• Which country served this specific request, and can I see that per request rather than in a policy document?
• What is retained after the response, and for how long?
• What currency am I billed in, and who carries the exchange-rate movement between estimate and invoice?
• Can one key be capped, scoped to specific models and expired, and are those enforced by the gateway or by convention?

Where P/9 is different, and where it is not

P/9 is an OpenAI-compatible gateway like the others, and moving to it is the same base-URL change. The differences are narrow and specific. Requests to the PK NPU-native pool are served on Huawei Ascend hardware P/9 operates inside Pakistan. Billing is in rupees from prepaid credits, so there is no conversion between the estimate and the invoice. The request log records what served each call, and the gateway stores no prompts or completions.

Where it is not different is worth saying plainly. For a team with no residency requirement, billing in dollars without friction, and no interest in which country a token was generated in, a global aggregator with a larger catalogue is a reasonable choice, and we would rather you picked the right tool than the local one.

You do not have to choose once

Because every one of these providers speaks the same API shape, the decision is reversible and can be made per workload. Route the traffic that carries personal data to a pool inside the country, leave the rest wherever it is cheapest, and keep the model id in configuration so the split is a deploy rather than a rewrite.

That is usually the correct answer for a real product: not one provider for everything, but a rule about which data may leave.