India-hosted inference

Where does inference happen?

India-hosted inference means the computation that turns a model request into a response runs on infrastructure located in India. The important question is where the particular request is processed. A model's name, its developer or the billing currency does not by itself establish the location of that computation.

For a builder, hosting location is one part of a data-flow decision. A customer may ask for inference in India as a procurement requirement or as part of its own data policy. That requirement needs to be translated into an architecture choice and checked against the service used by the application.

What else is in the data flow?

An AI workflow often includes more than the model server. Your application may use document storage, a retrieval index, application logs, monitoring services and backups. Hosting inference in one location does not describe where all those other components process or retain information. Review them separately before making a statement about the complete system.

Write down what leaves the application in a model request. Include user messages, retrieved passages, image files and tool results. Then record which systems receive them and which systems keep a copy. This inventory is more useful than a broad geographic label because it gives reviewers specific processing steps to examine.

How do I choose a route?

Choose the model and its serving route together. If a workload requires inference in India, verify the selected route rather than assuming another route for the same model has identical hosting. Recheck that choice when configuration changes or when someone introduces a different model into the application.

IndicStack labels model hosting as India-hosted or Global. India-hosted models run on GPUs in India; Global models run outside India on partner infrastructure. Qwen3.8 27B is available with India-hosted inference. Dedicated GPU deployments in India are also available on request.

Ask for the data-flow overview and the information needed by your security reviewer. Keep hosting, retention and training questions separate: each describes a different part of how a service handles requests. A clear answer to one question should not be used as a substitute for the others.

Related terms