What is AI inference? Explained without the jargon
Every time you ask a chatbot a question, a model does a small piece of work and hands you an answer. That piece of work has a name, and it is now the main way most people meet AI.
The name is inference. It sounds technical, and in the industry it gets used as if everyone already knows it. This page explains it for everyone else: what it is, why it matters more each month, and why it needs its own kind of capacity.
Two jobs: learning and answering
An AI model has two very different lives.
The first is training. A team feeds a model huge amounts of text, images or code, and the model slowly adjusts itself until it gets good at predicting what comes next. Training happens once, or a few times, for each version of a model. It takes weeks, runs on a large cluster of machines working together, and ends with a finished model.
The second life is inference. This is the model at work. Someone sends it a request, the model reads the request, does its calculation, and sends back an answer. Then it does that again for the next person, and the next, all day and all night.
A useful comparison is a chef. Training is culinary school: long, expensive, done once. Inference is cooking dinner: every evening, for every guest, for as long as the restaurant is open.
Term
Inference
The model at work: it reads a request, does its calculation and sends back an answer, then does that again for the next person.
What happens inside one request
When you type a question, here is roughly what happens.
Your words travel over the internet to a data center somewhere. There, they are split into small pieces called tokens. A token is a word or part of a word. The model reads the tokens, runs them through its calculations on specialised chips, and produces new tokens one at a time. Those tokens become the answer you read, and they travel back to your screen.
Each step costs something. The chips draw electricity. The machines need cooling. The data has to cross networks. For one question, the cost is tiny. Multiply it by every question from every user of every AI product, and it adds up to a real, growing load on power grids.
One request, inside
- Your words travelYour question crosses the internet to a data center.
- TokensThe text is split into small pieces called tokens.
- CalculationThe model runs the tokens through its calculations on chips.
- New tokensIt produces new tokens one at a time.
- The answer returnsThose tokens become the answer and travel back to your screen.
Why inference is now the main event
For the first years of the current AI wave, most attention went to training. Headlines were about who built a bigger model and how much it cost to teach.
That is changing. Once a model is trained, the work never stops. A popular model can answer questions for millions of people, every hour, for as long as it stays in use. Companies are building AI into search, email, support desks, design tools, cars, cameras and factory lines. Each of those features is an inference request, repeated again and again.
So the share of computing that goes to answering keeps growing. Training is a project. Inference is a utility.
Why it needs its own kind of capacity
Because inference is a different job, it has different needs.
It runs all the time. Training can be scheduled. Inference follows people: it peaks when they are awake and working, and it never fully stops. Capacity built for occasional, huge projects is not a natural fit for a steady, everyday load.
It is sensitive to distance. A training run does not care where it happens, as long as the machines sit close to each other. An answer has to reach a person or a machine. For a chatbot, a short wait is fine. For a robot, a video system or a hospital monitor, the wait is the product.
It depends on where data is allowed to go. Inference often touches private data: a customer conversation, a patient record, a company's documents. Some of that data has rules about which country it can be processed in.
It comes in many sizes. Some requests need a very large model. Many do not. A support bot answering questions about a return policy needs a different setup from a research lab testing its newest system.
Put together, inference wants capacity that is steady, close to the people using it, aware of where data must stay, and sized to the job.
Three questions to ask about any AI feature
If you are deciding how to run an AI feature in your own product, these questions help.
- Is this training or inference? If you are using a model someone else built, you are almost certainly buying inference.
- Who or what is waiting for the answer? A person reading a summary can wait a moment. A machine making a decision may not.
- What data does the model see? If it touches customer or company data, find out where that data is processed, not only where it is stored.
The answers tell you more about the capacity you need than any spec sheet. To see how a system could place each request, read a control tower for AI work. For the vocabulary, see the AI infrastructure glossary.
What we're building
At Starfield, we work on the inference side of AI. We're building standardized compute close to power, connectivity and demand, connected through one programmable network. It is designed to place workloads by policy, on latency, data residency, model and load, and designed so every workload can generate an auditable record of commitment, placement and delivery.
The short version: training built the models. Inference is how the world uses them, and it deserves capacity designed for that job.
If you run AI features that answer people every day, talk to us. A good place to start is Starfield Fabric.
Related
Starfield Fabric · AI infrastructure glossary: cloud, edge and in between · AI workload scheduling: a control tower for AI work