What you will be able to do

  • Update each engine using its own update route.
  • Decide when a new model is worth switching to.
  • Recognize when hardware, not software, is the limit.

Engines move fast

llama.cpp publishes builds several times a day; build b11687 was released on 16 October 2026. [source] Its package-manager installs track releases automatically: winget on Windows and Homebrew on Mac are both updated with new releases. [source] Ollama and LM Studio prompt for updates in their apps. Update every month or two, and whenever a newly released model needs it: new model architectures often require a newer engine.

Before updating, note your current version and benchmark result (lesson 9.9). After updating, run the same benchmark. If something got worse, roll back.

Swapping models on evidence

New open-weight models appear every few weeks. Do not switch on release-day excitement. Keep a short test set of three to five tasks from your own (non-confidential or fictional) work, with answers you know. When a candidate model appears:

  1. Check its model card for size, active parameters, context length, and licence.
  2. Run the fit calculation from lesson 9.2.
  3. Run your test set on the old and new models with the same settings.
  4. Switch only if the new one is better on your tasks, and keep the old file until it has proved itself.

When to upgrade hardware

When to change what
UPDATE THE ENGINE

Every month or two, and whenever a new model you want needs it. Cheap and usually safe.

SWAP THE MODEL

When a newer model of the same size tests better on your own sample tasks. Keep the old file until the new one has earned its place.

UPGRADE HARDWARE

Only when the model you need does not fit, or measured speed is too slow for daily use. Memory first, then bandwidth.

Upgrade on evidence from your own tests, not on release-day excitement.

Upgrade only for one of two reasons. It does not fit: the model you need, plus the KV cache for your typical document, is larger than your memory. More memory is the fix: a card with more VRAM, or a unified-memory machine with a bigger pool. It is too slow: measured writing speed is too low for daily use. More bandwidth is the fix. If speed is only poor on long documents, the reading phase (prefill) is the bottleneck and a faster processor or graphics compute helps more than bandwidth.

Keeping a record

Write down, in one place: the machine, the engine and version, the model file and its source, the settings, the benchmark result, and the offline test date. That record is what lets a colleague repeat your setup and what lets you show, if asked, how client material was handled.

Self-check

  1. How do winget and Homebrew installs of llama.cpp stay current?
  2. What do you run before and after an engine update?
  3. Name the two reasons to upgrade hardware, and the fix for each.
  4. Why keep the old model file after switching?
Check your understanding
  1. Their packages are updated automatically with new llama.cpp releases.
  2. The same benchmark, to compare results.
  3. It does not fit: more memory. It is too slow: more bandwidth.
  4. So you can switch back if the new model proves worse on real work.