What a model is

The idea in one line: A model is a function whose behaviour is set by numbers learned from examples, and a foundation model is one you train once and then reuse for many tasks without training it again.

Every cost in this course comes from two moments in a model’s life: the one time you train it, and the thousands or millions of times you use it. Get the balance between those two wrong and you pay for it on every call.

The change that matters most in recent years is not that models got 10% better. It is that a new task stopped needing a new model. TabPFN, a model for tables, takes a new dataset as input and answers in one pass: “in 2.8 s, TabPFN outperforms an ensemble of the strongest baselines tuned for 4 h” on datasets of up to 10,000 rows (Hollmann et al., Nature, 2025-01-08). TypeSafe AI’s Jev serves every customer with “the same weights” and no per-customer training (TypeSafe docs: Models, read 2026-10-28). When adding a task goes from “a training project” to “a new input”, its cost falls by orders of magnitude. That is the 10x idea behind the whole course, and this lesson gives you the words to see it.

A function is a rule that turns an input into an output. You already write them. A shell script that reads a spec file and prints “needs rebuild” or “fine” is a function. So is rpm -q.

A model is a function whose rule was not written by hand. It was learned from examples of inputs paired with the right outputs.

Fedora already runs one. rpmeta predicts how long an RPM build will take from the package, its version, the OS release, the architecture, the CPU and the RAM of the builder. Nobody wrote that rule. It was learned from a dataset of 705,766 Copr build records, using two standard tree-based methods, LightGBM and XGBoost (HF: fedora-copr/rpmeta, read 2026-10-28). No accuracy figure is published for it.

  input                    the function                 output

  package, version,    +----------------------+
  release, arch,  ---->| model                |---->  42 minutes
  CPU, RAM             | rule learned from    |
                       | 705,766 past builds  |
                       +----------------------+

Notice what rpmeta returns: one number, not a paragraph. Keep that in mind. Most of this course is about models that return a typed answer (a number, a choice, a yes or no) and a probability, rather than text.

Here is the smallest useful model. It guesses a build’s time from the size of its source code:

minutes = w × size_mb + b

w and b are its parameters: numbers inside the model that set its behaviour. Think of each as a dial. Turn w up and big packages get longer predicted times. Turn b up and every prediction shifts up by the same amount. The formula stays the same; the dials make it this model rather than another.

Now some made-up data to practise on, three builds:

Set the dials to w = 1, b = 0. The model predicts 1, 2 and 4 minutes. The real times are 3, 5 and 9, so the errors are 2, 3 and 5.

A loss is one number that says how wrong the model is on a set of examples. A common one is the mean squared error: square each error, then average. Here that is (4 + 9 + 25) / 3 = 12.67.

Now try w = 2, b = 1. The predictions are 3, 5 and 9. Every error is 0, so the loss is 0.

Training is the search for dial settings that make the loss small. With two dials you can guess. Real models have millions or billions of dials, so you need a method. The standard one is gradient descent: for every dial, work out whether nudging it up or down lowers the loss, nudge every dial a little in its downhill direction, and repeat. One round of nudging is one training step.

Here is one step on our toy model, which you can run:

# One gradient-descent step on the toy build-time model (made-up data).
sizes = [1, 2, 4]          # source size in MB
times = [3, 5, 9]          # real build minutes
w, b, lr = 1.0, 0.0, 0.05  # two dials and a step size

def loss(w, b):
    return sum((w * x + b - y) ** 2 for x, y in zip(sizes, times)) / 3

print(round(loss(w, b), 2))            # 12.67
# Slope of the loss for each dial: which way is downhill?
gw = 2 / 3 * sum((w * x + b - y) * x for x, y in zip(sizes, times))
gb = 2 / 3 * sum((w * x + b - y) for x, y in zip(sizes, times))
w, b = w - lr * gw, b - lr * gb        # nudge both dials downhill
print(round(w, 2), round(b, 2), round(loss(w, b), 2))  # 1.93 0.33 0.68

One step moved the dials from (1, 0) to (1.93, 0.33), and the loss fell from 12.67 to 0.68. A few more steps land near (2, 1).

That is all training ever is, at any scale: a loss, and many small nudges to many dials. What changes is the count. The original Transformer of 2017 had about 65 million parameters (Vaswani et al., 2017-06-12, Table 3). Google’s TimesFM-3 forecaster has 330 million (Google Research, 2026-08-31). GPT-3 has 175 billion (Brown et al., 2020-05-28).

Training is when the dials move. Inference is when they are frozen and you simply run the function on a new input. Training happens once (or a few times). Inference happens on every call, for as long as the model is in service.

Their costs have a simple rule of thumb. A FLOP is one arithmetic operation, such as a multiply or an add. For a transformer (the model family most of this course uses; see transformers in plain words) with N parameters:

inference ≈ 2 × N FLOPs per token read
training  ≈ 6 × N FLOPs per token trained on

A token is a chunk of text, often a word piece. The rule comes from Kaplan et al.’s scaling-law paper (Kaplan et al., 2020-01-23, Table 1). Training costs about three times as much per token because each step runs the model forward and then works out every dial’s nudge backward.

Worked example, from the course’s research notes:

• A 150-million-parameter model reading a 1,000-token input costs 2 × 1.5e8 × 1,000 = 3e11 FLOPs per call.
• Training that model on 1.5 billion tokens costs 6 × 1.5e8 × 1.5e9 = 1.35e18 FLOPs. That is an estimate of 1.5 to 4 hours on one rented H100 GPU, or about $3 to $15, with H100s renting for $1.99 to $4.29 an hour on Runpod and Lambda as of October 2026 (IntuitionLabs, updated 2026-10-11). The hours figure is an estimate built on an assumed GPU speed, not a measurement.
• A million calls at 1,000 tokens each cost 3e11 × 1e6 = 3e17 FLOPs.

So after about four or five million calls, inference has used as much compute as the whole training run, and it keeps going. For a model in production, inference is where the lifetime cost sits. That is why “orders of magnitude less inference compute”, in the quote that started this course, is the bar that matters.

Back to the toy data. Imagine a “model” that is just a lookup table: package a takes 3 minutes, b takes 5, c takes 9. Its loss on those three builds is 0. Now a new package d arrives with 3 MB of source. The table has no answer. The two-dial model, minutes = 2 × size + 1, says 7 minutes.

Generalization is doing well on inputs the model never saw in training. It is the only score that matters, because nobody needs a model to tell them what they already know.

Overfitting is the opposite: fitting the training examples, noise and all, so tightly that the model does worse on new ones. A model with many more dials than examples can memorize instead of learning.

How you measure generalization:

1. Hold out a test set. Keep some labelled examples away from training and score the model only on those.
2. Split by time when the world changes. Train on the past, test on what came after. A model of build failures trained and tested on the same week can look brilliant and then fail on the next compiler bump. The research notes give a simple expert test for any vendor: ask for results on data created after the model’s training cut-off, or on your own data.
3. Watch for leakage. Leakage is test data, or something very like it, sneaking into training, which inflates scores. It is common. The GIFT-Eval forecasting benchmark flags Chronos, Chronos-Bolt, TimesFM 1 and 2, TTM-R2 and Lag-Llama as having seen test data (GIFT-Eval results, updated 2026-10-23). GPT-4 was shown to have seen parts of the AG News, WNLI and XSum test sets (Golchin & Surdeanu, ICLR 2024).

The classic recipe is one model per task: gather a dataset for “how long will this build take”, train, deploy; gather another for “will this build fail”, train, deploy. rpmeta is that kind of model, and for one well-defined task with 705,766 labelled rows, it is a sensible choice.

A foundation model flips this. The term comes from a 2021 Stanford report, which describes models “trained on broad data at scale” that “are adaptable to a wide range of downstream tasks” (Bommasani et al., 2021-08-16). You pay for one big training run, then reuse the result.

Classic: one model per task

  task A data --> train --> model A
  task B data --> train --> model B
  task C data --> train --> model C

Foundation model: train once, adapt cheaply

  broad data --> train once --> one model
                                 ^   ^   ^
                   task A input -+   |   |
                   task B input -----+   |
                   task C input ---------+

How “adapt” got cheaper, step by step:

The three ways to adapt a model (pre-train, fine-tune, put examples in the input) get their own lesson: three ways to teach a model.

The same Stanford report carries a warning worth remembering: “the defects of the foundation model are inherited by all the adapted models downstream”. Reuse spreads mistakes as efficiently as it spreads skill.

As of October 2026:

• Tables. On the live TabArena leaderboard (2026-10-27), the top 12 entries are eight train-once, answer-from-context models plus four combined systems. The best tuned and ensembled gradient-boosted tree, the long-standing default for tables, sits about 600 Elo points below the leader (TabArena). On that scale a 400-point gap means roughly 10-to-1 odds that the higher-rated method wins on a given dataset. The current leader, NVIDIA’s Kumo-Tabular, was pre-trained only on synthetic tables (NVIDIA, 2026-09-29).
• Time series. TimesFM-3 topped Google’s own rankings at launch, which is a vendor claim. Six weeks later it ranked 6th among single models on GIFT-Eval, by the research notes’ recomputation of the board. Leaderboard positions in this field last about six weeks.
• Typed decisions. Within about four weeks of Jev’s launch on 2026-09-15, a community leaderboard, the Jev Decision Index 0.4, ranked 208 decision models.

What is still open:

• Do foundation models beat a well-tuned simple model on your data? Often not in time series. A statistical ensemble beat Chronos-T5-Large by 10% on 50,000 forecasting-competition series (Nixtla experiment, undated). Always run the baseline.
• Is zero-shot really zero-shot? Leakage makes many headline scores uncertain. Synthetic-only pre-training, as in TabPFN and Kumo-Tabular, is one answer, though a synthetic recipe can still be tuned, over many tries, towards a benchmark.
• How fast do models shrink? One study finds the parameters needed for a given quality halve about every three months (Xiao et al., 2024-12-05). If that holds, any edge built only on “our model is smaller” decays on that clock.

• On the Opportunities and Risks of Foundation Models (Bommasani et al., 2021): where the term comes from, and the “defects are inherited” warning.
• Scaling Laws for Neural Language Models (Kaplan et al., 2020): Table 1 is the source of the 2N and 6N rules of thumb.
• Accurate predictions on small data with a tabular foundation model (Hollmann et al., Nature, 2025): the clearest case of “train once, answer from context”.
• TimesFM-3 announcement (Google Research, 2026): the forecasting example from the course’s opening quote.
• fedora-copr/rpmeta dataset: a real, small, typed model already inside a distro build system.