A benchmark is only meaningful when the exact model file and runtime state are known. These five screens show the path from repository metadata to a locally activated model. Planning estimates are shown before the run; measured evidence is recorded later. Interactive gallery: https://lizard-llm.qendryx.com/benchmarks.html Inspect repository and compatibility metadata [image: Screenshot%202026-07-22%20213514.png] Lizard shows the model family, author, supported quantizations and whether the file can run on the native engine before anything is downloaded. Choose the exact quantized file [image: Screenshot%202026-07-22%20213538.png] The selected Q4_K_M file has explicit download size, estimated RAM and planning speed. Those estimates are not relabeled as measurements later. Download identity remains visible [image: Screenshot%202026-07-22%20213551.png] The repository and exact GGUF filename remain on screen while the file downloads, so the later provider rows can be traced back to their intended weights. Cold is different from warm [image: Screenshot%202026-07-22%20213620.png] The chat identifies that the model is cold and offers an explicit wake action. Benchmark load and inference timings preserve the same distinction. Activate the model for local inference [image: Screenshot%202026-07-22%20213650.png] The activated model becomes available to the CLI, chat and local API. The screen names Lizard Native and Caterpillar as the two on-device engines. Question for you: Which model and quantization did Lizard recommend for your machine, and did the measured result match the planning estimate?

These four captures show why the dashboard keeps provider rows and analysis separate. The same machine can produce a different winner in a different run, and a composite recommendation is never allowed to erase the underlying values. Interactive gallery: https://lizard-llm.qendryx.com/benchmarks.html Five rows, five completed measurements [image: Screenshot%202026-07-22%20213232.png] Ollama records 8.56 tok/s, stock llama.cpp Q4 7.85, and Lizard Native Q4 5.61 in this run. Load, warm-up and memory evidence stay visible beside throughput. A second run changes the order [image: Screenshot%202026-07-22%20213249.png] In this separate 10/10 run, llama.cpp Q4 reaches 6.23 tok/s, Lizard Native Q4 5.28, and Ollama 4.53. The result belongs to this model, machine and run—not a universal ranking. Leaderboard plus metric-specific winners [image: Screenshot%202026-07-22%20213314.png] Ollama leads the composite score, Lizard Native Q4 takes best native decode and parity among the compared rows, and llama.cpp Q4 leads wall time and end-to-end tokens per second. Recommendations stay attached to source evidence [image: Screenshot%202026-07-22%20213327.png] Scores, badges, execution lanes and raw provider values remain on the same screen. The recommendation annotates the run; it does not replace it. Question for you: On your hardware, which decision should come first: shortest wall time, steady decode speed, peak memory, or answer parity?

If you run the same benchmark twice and get different answers, nothing is broken. The usual causes, roughly in order: Heat. Laptops especially will slow themselves down after sustained load. A second run often lands lower than the first purely for this reason. Other software. A browser with many tabs, or anything using the GPU, competes for exactly the resource that limits generation speed. Cold vs warm model. The first run after loading includes work that later runs skip. This is why comparisons should be run alternating — A, B, A, B — rather than all of A then all of B. Otherwise you're partly measuring how warm the machine got. If your numbers swing by more than about 20% with nothing else running, that's worth posting about.

A running thread for real results. Any hardware is interesting, especially modest machines — most published AI benchmarks assume an expensive GPU. Handy format: CPU: GPU (or none): RAM: Model + quant: Engine: lizard-native / caterpillar Tokens/sec: Which check: readiness / full benchmark Two things that make results comparable: Note whether anything heavy was running (browser, game, video call) — it moves the numbers a lot. If you ran it more than once, post the range rather than your best single figure. Machines heat up, and second runs often differ from first ones.

The benchmark runs your model on your hardware and reports what happened. A few principles it sticks to: Measured means measured. Every number is labelled — Measured, Estimated, Mixed, Partial. If a run didn't finish, you get Incomplete, not a filled-in guess. Nothing is invented. There are no synthetic values anywhere. A missing number shows as —. Derived numbers inherit the weakest input. Measured speed divided by an estimated memory figure is labelled Mixed, never Measured. Free readiness check vs. full benchmark: the readiness check in setup is free and always available — it tells you tokens/sec for your model on this machine. The full suite (Lizard vs Ollama vs llama.cpp across Q1–Q9) is the credit-based one. Full explanation: https://lizard-llm.qendryx.com/benchmarks.html When posting results, your CPU/GPU and model + quantization make them useful to everyone else.