How the finder estimates work

In short: The finder works out, from the specifications that makers publish, which open AI models fit in a laptop's memory and roughly how fast they write. It does not need us to buy and test each laptop. Every row says Estimated from specs, and laptop pages add Reported by others benchmarks where people have published them. A row says Measured only when we ran the model on that laptop ourselves. Our scorecards stay measured-only. See how we test.

What is estimated#

For each laptop, each memory size and each model, we give you:

• Fit. Does the model fit in the memory it can use?
• Memory needed. How much memory the model wants, in GB.
• Writing speed. A range, in tokens per second. A token is a small piece of a word.
• A speed band. Fast, Moderate or Slow, or Unclear when the range is too wide to say.

These words are not the verdicts on our scorecards. They come from specifications, not from a test.

What is not estimated#

• Reading speed. How fast a model reads your prompt is not estimated in this version. We say so on each page.
• Quality. Quality belongs to the model, not to the laptop. We show a quality score only for models we have measured. Otherwise the table says "not measured yet". We never invent one.
• Heat, battery and noise. We do not estimate these.
• Long documents on the laptop pages. The laptop pages assume a context of 16,384 tokens, the same setting as our tests. The "My laptop is not listed" panel lets you choose a use case that changes it (see below).

The memory rule#

Memory the model can use. This depends on the kind of graphics:

• Unified memory (Apple silicon). The graphics chip may use only part of the memory. Apple does not publish one fixed share for this. Our default is 0.70 of the memory. It is a number we chose, and a Mac owner can change the real limit.
• A graphics card with its own memory. We use the size of that video memory.
• Integrated graphics. We use the system memory minus 4 GB that we keep for the operating system.

Memory the model needs. We take the size of the model file for the Q4_K_M version on Ollama. We add 5% for loading overhead. We add the memory for the context, called the KV cache, which we work out from the model's published design on Hugging Face. We then add 1 GB for the runtime.

The fit label:

• Fits. The model needs at most 0.90 of the usable memory.
• Tight. It needs more than that, but still fits.
• Partial offload (slow). Only for a graphics card. The model does not fit in video memory, but it fits when part of it runs from system memory. This is much slower.
• Won't fit. It does not fit even then.

The speed rule#

Writing a token means reading the model's weights from memory. So the speed depends mostly on the memory bandwidth, which is how many GB per second the memory can move. Apple lists the bandwidth for each of its chips. Other makers list it for their graphics cards.

1. We find how many GB of weights the laptop reads for each token. For an ordinary model this is the whole file. For a "mixture of experts" model, only a few parts work at a time, so we use the file size times the active share of the parameters.
2. The middle estimate is the bandwidth times the efficiency, divided by that number of GB. A real laptop never reaches the full bandwidth. The default efficiency is 0.50 for ordinary (dense) models and 0.30 for mixture-of-experts models, which do extra work for each token.
3. For Apple chips (unified memory) we then scale the middle estimate by the chip's bandwidth: 1.25 below 150 GB/s, 1.15 from 150 to 300, 1.00 from 300 to 600 and 0.70 from 600 up. People who ran the standard llama.cpp test and published the results show that bigger chips reach a smaller share of their bandwidth. We worked these numbers out from 31 of those results (a small 7-billion-parameter model, Q4_0) and fixed the middle tier at 1.00 because our one measurement, on an M1 Max, sits there. The scale is a derived figure, not a measurement, and it does not apply to graphics cards.
4. The range runs from 0.7 times the middle estimate to 1.3 times it.
5. If part of the model runs from system memory, we multiply the speed by 0.15.

The band comes from the whole range. Fast means even the low end reaches 10 tokens per second. Moderate means the whole range sits between 5 and 10. Slow means even the high end is below 5. Unclear means the range crosses one of those lines, and we say which bands are possible. These limits are the same as the writing-speed limits in our test rules.

If we do not have a bandwidth for a laptop, we show the fit only and say that speed is not known. Some makers state the memory type and speed but not the GB per second. For those chips and laptops we work out a peak figure ourselves: 128 bits (two 64-bit channels) times the data rate, divided by 8, at the fastest LPDDR5X rate the maker lists. Where the maker states a wider memory bus, we use that width instead (the mini PCs page uses 256 bits for the AMD Ryzen AI Max+ 395). The same arithmetic gives Qualcomm's own published figures. These rows say "Derived" in the data, and the panel warns that the speed may be optimistic, because many laptops run slower memory. We leave a figure empty when the maker gives neither the speed nor the bus width, as for NVIDIA's RTX 30 and 40 laptop graphics.

Some models write out their reasoning first. They take longer to finish a job than the speed alone suggests. We mark them "thinks first".

The matcher: use case, quantization and the next step#

The panel "My laptop is not listed" on the finder adds three things. They use the same memory and speed rules as above. They are estimates too.

• Use case. The use case sets how much context we assume, and so how much memory the KV cache takes. Chat and writing assume 16,384 tokens. Coding help assumes 32,768 tokens. Reading documents assumes 65,536 tokens. A model with a shorter limit of its own is held to that limit, and the row says so. We have no quality data by use case, so the use case changes the memory and nothing else. Image models are not in the finder yet, so choosing Images shows nothing rather than a guess.
• Suggested quantization. A quantization is a way of shrinking a model file. Q4_K_M is the standard size we use everywhere. Q8_0 is larger and keeps more of the model's quality. We suggest Q8_0 when Ollama lists a Q8_0 file for that model and it fits comfortably; otherwise Q4_K_M. The Q8_0 file sizes come from the Ollama tags pages, which round them to two figures. A bigger file is read for every token, so the speed shown is for the suggested quantization and is lower for Q8_0. We assumed the same efficiency for both, which we have not measured.
• The smallest step up. We try common memory sizes in order and report the first one that lets more models fit comfortably, and which models those are. For a graphics card we name the next larger card in our data, because laptop graphics memory cannot be upgraded. It is the smallest step, not the cheapest: the finder shows no prices. Many laptops have soldered memory, so read it as what to look for in your next machine.

If you choose an operating system, we add one line on how Ollama uses your chip's graphics, with a link to Ollama's hardware page. Where that page says nothing about your chip, we say that we have no verified note.

Error bars and honest limits#

The defaults are our first guesses, set from spot measurements. The range of 0.7 to 1.3 is not a measured error bar yet. We replace a default with a fitted value only after we have at least 3 measured pairs of that kind of model. Until then the page How close are our estimates? says "not enough measurements yet".

All of our own calibration so far comes from one machine: a MacBook Pro with an M1 Max. We took the two default efficiencies from spot measurements of two models on it: one dense model and one mixture-of-experts model. For other Apple chips we use the bandwidth scale above, which comes from speeds that others published, not from our tests. Other makers may differ, so we keep the ranges wide. Read the speed ranges as a rough guide, not a promise. The calibration page always shows the current pairs and errors.

Other limits:

• Specifications can differ. Makers sell several versions of one laptop. We list the version named in the row and link its source.
• Software changes. A new version of the runtime can make a model faster or slower.
• Memory settings. A different context size, or other programs running, changes how much memory is free.
• No prices. The finder shows no prices.

Reuse the data#

The finder data is free to reuse under CC BY 4.0. Download finder.json and credit Hardwarerig. Each laptop and model row lists its source links.