What Is a Foundation Model, and Why Companies Save Money on It

Why this matters

• Understand what the money in an AI rollout actually buys: training a model, or configuring a ready-made one
• Tell apart the work the model vendor has already done from the work required for a specific job
• Ask the vendor the right question: which model is under the hood, and why that one

What is a foundation model in plain language

A factory-built engine goes into different vehicles. The same motor powers a van and a sedan: what changes is the body, the suspension, the gearbox. Nobody designs an engine from scratch for a new van — the engine is bought and the mounts are adapted.

A foundation model works the same way. It was trained on an enormous body of text, code and images, with no industry or task attached. What settled inside are the general patterns of language: how a document is structured, how a question gets phrased, what follows what.

Then a body goes onto that engine. One model yields customer support, invoice processing, search across internal policies, a sales assistant. The term's second name — base model — appears in documentation more often than the English "foundation model".

How it works

1. A body of data is assembled. Text, code, images — unlabelled and not split up by task. Labelling is expensive, so the model is taught to predict missing pieces of the data itself.
2. Training happens once and lasts. This is the costliest part: thousands of graphics cards, months of electricity bills, a budget in the hundreds of millions of dollars. The model vendor pays for it, not the client company.
3. Testing runs across a wide set of tasks. The same model answers questions, writes code, processes documents. Versatility is precisely the measurable result of training.
4. Configuration for the job begins. This is where the client's work starts. A prompt gets written, in-house documents are supplied, and where needed the model is fine-tuned on an in-house sample.
5. It goes into the process and the money gets counted. Every request costs money: payment goes to tokens or to in-house hardware. From there the unit cost per operation is calculated.

A separate note on swapping the engine. Models are refreshed every few months, and moving to a new version rarely breaks the whole system — the engine changes, the surrounding rig stays. That is the main budget advantage of this architecture.

An example from practice

A parts distributor processes roughly 4,000 incoming orders a month. Orders arrive by email in free form: part numbers mixed in with questions about delivery dates and payment. The job is to pull out the part numbers, identify the type of enquiry, and open a deal.

The first option discussed was the familiar one: train an in-house model for this email format. The estimate covered labelling 20,000 examples plus a development team — a year-long path at a price that never pays back at any volume of orders.

The second option is a ready-made foundation model plus a description of the format in the prompt. A first working version comes together in 4–6 weeks. Labelling is needed not for training but for testing: 300 emails labelled by hand, to measure the share of correct extractions.

The figures above are planning benchmarks for a company of this profile, not a report on a specific rollout. The measurement method is simple: the share of orders where every part number was pulled out correctly, calculated on the same sample of 300 emails before launch and after a month in operation.

What the business gets out of it

• The expensive part is already paid for. Training cost the vendor hundreds of millions of dollars; access to the result costs roubles per operation. The rough order of magnitude for a given process can be estimated with the budget calculator.
• Time to a first version is measured in weeks. An in-house model for the job means months of labelling. Configuring a ready-made one takes weeks — and those weeks already show whether the economics add up.
• One model covers several processes. Support, document processing and knowledge base search all run on the same engine. The second job costs less to connect than the first: the surrounding rig is already in place.
• Vendors can be swapped. If the system is built around clearly defined inputs and outputs, replacing the model means a measurement on an in-house sample and a switchover, not a new project.

When it can be skipped

Some jobs are handled more cheaply by ordinary means. Checking a total on an invoice, reconciling two spreadsheets, routing email by keyword — here, previous-generation machine learning or a plain integration gives a more accurate answer at a fraction of the cost.

A foundation model starts to win where the input has no rigid format: free text, varied document templates, a customer speaking naturally. The rule is simple: where the job can be described by a table of rules, write the rules.

What to check

First: every model comes with its own terms on data. Some vendors process requests outside the country; some offer deployment on in-house hardware. This gets settled before the model is chosen, not after the pilot goes live.

Second: versatility is not the same as accuracy on a specific job. A model that leads on general benchmarks may lose to a simpler one at processing industry documents. That is verified by measurement on 100–300 in-house documents, not by the tables in a sales deck.

Third: ask the vendor to name the specific model, its version and the reason for choosing it. If the answer comes back as "a neural network" with no name and no version, there is nothing to compare the proposal against — and the cost per request differs by a factor of tens between models.