[UTC+3]

What Is a Large Foundation Model

August 19, 2026 · 6 minBasicsIn plain words

Why this matters

  • Understanding what the money buys during a rollout: training the model, or using it
  • Telling apart the tasks a ready-made model with an instruction can handle from those that need fine-tuning
  • Asking a contractor the question "which model is under the hood, and what does one operation cost"

What is a large foundation model in plain terms

Software used to be written from scratch for every task. Passport recognition was one project, mail sorting another, contract search a third. Each came with its own data collection, its own labelling and its own six-month timeline.

A foundation model works like the foundation of a building. It is trained once on an enormous body of text, code and images, and different floors are then built on top of it: sorting incoming requests, drafting documents, answering customers. The foundation is not rebuilt for each floor.

"Large" refers to scale: hundreds of billions of adjustable values inside, and years' worth of human writing on the way in. Hence the key property — the model works on tasks it was never specifically taught.

How it works

  1. The model is trained on general data. Text, code and images from open sources. This stage is handled by the vendor, who also bears its cost.
  2. The model is distributed through an interface or as weights. The first route is a call to the vendor's cloud at a rate per volume. The second is open weights installed on the company's own hardware.
  3. The task is set in writing. Instead of programming, an instruction is written: what to read, what to extract, in what format to return it. The same model covers different processes this way.
  4. Company knowledge is supplied separately. The model does not know internal rules and price lists. The relevant fragments are located by search and passed in along with the question.
  5. Fine-tuning comes last. It pays off only where instruction and search cannot hold the answer format steady.

The order of the steps matters more than any single one of them. Step 5 without steps 3 and 4 is the most common way to spend budget on something a written instruction would have solved.

Step 1
Instruction
The task is described in writing. Tested on 30–50 real cases within a couple of days
Step 2
Document search
Rules and price lists are supplied alongside the question, and the model answers from them
Step 3
Fine-tuning
Added where a stable format or narrow terminology is required
Step 4
Measurement
The share of correct answers and the unit cost per operation are calculated on the same sample
The order of connecting a model to a process

An example from practice

The figures below are calculated benchmarks for a company of this profile, not a report on a specific rollout. Each one comes with its measurement method so it can be repeated on other data.

A wholesale company processes incoming orders from retail outlets: email, messengers, attached files. The task is a single one — pull out item codes, quantities and the delivery address, then create the order. Around 3,000 orders a month, with 6–8 minutes of a manager's time spent on each.

A dedicated program for this kind of processing would take months to write: every outlet has its own format. A foundation model covers the task with a page-and-a-half instruction plus an item-code reference supplied through search.

The measurement is set up as follows. Take 200 orders from the previous month, run them through the model, and check them against what the managers entered by hand. Count the share of orders where every field matched, and the unit cost of one processing run from the inference bill. The same measurement is repeated after a month of operation — the figure before and after shows what the process delivered, not what the demo promised.

3,000
orders a month in the worked example
6–8 min
manual processing of a single order
200
orders in the sample used to measure field accuracy
Source: calculated benchmark; measurement method described in the text

What the business gets out of it

  • The first version is measured in weeks. There is nothing to train: the model is already trained, and what gets configured is the written instruction and the document feed. Process readiness can be checked with a checklist.
  • One model covers several processes. Order processing, draft correspondence and knowledge-base search all run on the same foundation. The second process costs less than the first — the integrations and rules are already in place.
  • Costs become a calculable figure. The unit cost per operation multiplied by volume gives an annual budget before launch.
  • Vendors can be swapped. The instructions and documents stay; the model underneath them changes. That limits dependence on any single vendor.

Under what conditions it pays off

It pays off where the volume of operations is steady and the result is verifiable. Three conditions set the threshold.

The first is throughput. From several hundred similar operations a month. Below that, saved hours do not turn into money: headcount stays the same, while the setup work is just as large.

The second is measurability. The process has a figure from before launch: minutes per operation, error rate, cost per hour. Without one, there is nothing to compare the post-launch effect against.

The third is a settled answer to where the freed-up hours will go. New orders, another area of work, dropping a contractor at peak season. Hours that are not assigned anywhere never make it into the financial report.

When a simpler solution is enough

Some tasks are cheaper to handle without a model. A strictly formalised process with a fixed document format is a job for ordinary integration: the rules are written once and cost less to run.

One-off operations do not warrant a rollout either. Ten contracts a month will be read by a person faster than an answer-quality check can be configured.

What remains for the model is where it is stronger: mixed formats, free text, tasks without rigid rules. There, extracting the rules from people's heads and writing them down takes months, while an instruction takes a day.

What is worth checking

First: ask the contractor for the specific model and where it runs — the vendor's cloud or an in-house perimeter. Both the price and the destination of company data depend on it. The label "foundation model" in a proposal does not determine the price.

Second: ask to see a measurement on the company's own documents, not on demo material. A share of correct answers on someone else's sample says nothing about this process, and the spread between samples runs into tens of percentage points.

Third: fix the quality threshold before launch. What share of incorrect results is acceptable, who reviews the rest, what happens when the model fails. The threshold is set by the business, and everything else is calculated from it.

Frequently asked questions

What is a large foundation model in plain terms?

It is an AI model trained once on a vast body of text, code and images, then applied to many different tasks. The same model sorts incoming mail, drafts contracts and answers customers. A separate model for each task is unnecessary — the task is set by a written instruction. "Large" here refers to the scale of training and the number of parameters, not to the size of the company.

How does a foundation model differ from a language model?

A language model works with text. "Foundation model" is the broader term: it also covers models that read images, audio and tables. Most of the models businesses have heard of are both language models and foundation models. When choosing a vendor, the class name matters less than the list of supported data types and the price per operation.

Does it need to be trained for a specific company?

For most tasks, no. The first step is to guide the model with an instruction and supply the relevant documents through search. Fine-tuning costs more and pays off only where a stable answer format or narrow terminology is required that an instruction cannot pin down. The order of testing: instruction, then document search, then fine-tuning.

What does it cost to use?

Payment goes either per volume of text processed at the vendor's rate, or for hardware when the model runs in-house. The unit cost of a single operation can be calculated before launch: the size of the request and the answer multiplied by the rate. The monthly bill follows from multiplying by the number of operations. On the same task, vendors can differ by several times over, so comparisons should be run on the company's own texts.

Can such a model be deployed inside the company?

Yes, if the model has open weights. It is then installed on the company's own hardware and the data never leaves the perimeter. The nature of the cost changes: instead of a bill for volume, there is the price of GPUs and their upkeep. This option suits organisations whose rules forbid sending data outside, and whose volume of operations is high enough to keep the hardware busy.