Llmspeed measured: the speed estimate for local LLMs and our numbers on the R9700 and RTX 5090

On October 17 a Show HN on Hacker News reached 322 points and 86 comments. The page behind it, Llmspeed, claims to show how fast 15 popular models run on 30 graphics cards, Macs and CPUs, including the wait until the first token appears; a chat window replays each answer at the simulated speed. Behind the page stands an open-source project under the MIT license that a single developer has been building since late August. Two of the listed cards sit in our own lab, and on October 16 we ran them against each other: the Radeon AI PRO R9700 with 32 GB and the RTX 5090 with 32 GB. This post puts the estimates of the page against our measurement and sorts out what you can use from it.

What the page shows

For each card, Llmspeed lists every model in the best quantization that fits into memory, together with generation speed, time to first token, and a fit status: fits, partially offloaded, or will not run. On top of that there is a race mode that runs two setups side by side. The supported backends are CUDA, Metal, ROCm, Vulkan and CPU.

Under the numbers sits a calculation model that the author documents openly in the README. Generation speed is bound by memory bandwidth, because every output token reads the active weights once; for Mixture-of-Experts models only the active parameters count. Prompt prefilling runs over compute, both with an efficiency factor per backend and a slowdown as the context grows. The memory check weighs weights plus KV cache plus overhead against 93 percent of video memory on discrete cards and against roughly 75 percent of shared memory on Macs. Anything beyond that counts as unable to run or as partial offload.

The trust labels inside the data file

Every number carries a label: measured, derived or projected. The generated data file of the project from October 17 (388 KB of JSON, recounted by hand on October 19) shows the proportions: of 2079 combinations of card and model, 81 come from real measurements, 675 are derived from similar setups, and 1323 stand at unable to run. Computed cells are the rule here, measured ones the exception.

The measuring standard is the llama.cpp own llama-bench: 512 prompt tokens, 128 output tokens. Short prompt, short answer, no speculative decoding. Anyone who compares a derived cell against a long agent session is comparing two different tests.

Take the R9700 with Qwen 3.8 27B in Q4_K_M: Llmspeed shows 25 tokens per second. The data cell itself is labeled derived, its band reaches from 12.3 to 37.0, and the 25 is the middle. For the RTX 5090 the page shows 46, with a band from 22.3 to 70.6. Reading the band belongs to these numbers, because the author writes himself that driver, engine version, flash attention, power limit and thermals move real values by 10 to 30 percent.

Two cards, the same file: estimate against measurement

Our comparison run of October 16, 2026 fed both cards the same file: the dense Qwen3.8-27B as IQ4_XS with 17.03 GB, llama.cpp with -ngl 99 -fa on, 262,144 context, one sequence, MTP acceptance on, measured while idle. The R9700 reached 41 to 45 tokens per second there (MTP depth 3), the RTX 5090 reached 120 to 146 (MTP depth 4). The conditions of the estimate are different in every detail: short prompts instead of a 262k context, Q4_K_M instead of IQ4_XS, and no speculative decoding at all. That difference is exactly what explains the gap between estimate and measurement. Draft acceptance alone doubles our single stream; we worked that through on the production lane on October 18, from 104 to 217 tokens per second.

Tokens per second. Estimate: llmspeed.dev, data from October 17, 2026, derived cell, middle of the band. Measurement: our own protocols from October 16, 2026, midpoints of 41 to 45 and 120 to 146, each with MTP acceptance on. Different test conditions, details in the text. (Quelle: senn-tech, own measurement 16 Oct 2026; llmspeed.dev dataset 17 Oct 2026)

Informative is the distance between the two cards, which both sources claim for the same buying question. Llmspeed says the RTX 5090 runs at 1.8x of the R9700. Our measurement with an identical file and an identical engine says 3.1x. Two caveats stay inside our own number: the 41 to 45 hold for our ROCm configuration, third parties measure this card about a third faster on the Vulkan backend, and our two Vulkan attempts ended with a crashing driver. Even with these uncertainties the direction stays: the gap is larger than the estimate shows, and the derived cell of the AMD card is exactly the number someone without an own measurement ends up trusting.

Will not run is a fit rule, not a verdict from physics

The row for Qwen3.8-Flash-Next (125 billion parameters, Mixture-of-Experts architecture) stands on the R9700 as well as on the RTX 5090 at Will not run in every quantization. We run that model in production on four RTX 5090 with tensor parallelism, NVFP4 KV cache included, and on October 18 we described the rebuild of the lane. Llmspeed deliberately models single devices; the README names multi-card setups as not simulated.

The fit test itself was checked independently in the project issue tracker on October 17: a user put a 46.6 GB model (80B A3B, Q4_K_M) onto a 16 GB card that the page lists as unable to run and reached 80.7 tokens per second with a 10.5 GB expert cache (issue 1, a community measurement with protocols). The criticism targets the partial offload, which the calculation model runs over system-RAM bandwidth instead of over an expert cache. The pattern of voices from the Hacker News discussion fits that: several users report Flash-Next running on 16 GB cards because the large embedding matrices can be offloaded to an SSD. Will not run at Llmspeed therefore means: not in the standard configuration on this one device. Anyone planning MoE models with an expert cache or multi-card operation should not read these rows as a disqualifier.

What else the community reports

The points of criticism from Hacker News and the open issues are modest and reasonable: no multi-card setups (an own feature request from October 17), no speculative decoding, no long context, no parallel users. One user with an M2 Ultra reports that his machine runs almost twice as fast as the estimate the page shows for the M3 Ultra with 512 GB; that is a single-user report, not a check by us. The author replies to nearly every comment and pushed new measurements on October 18. State of October 19: 108 stars, two open issues, one maintainer, dataset last generated on October 17. After seven weeks of building by one person this is a quiet, documented construction site. Numbers with the label derived or projected carry that label openly, and they stand and fall with the evidence the community contributes.

Before buying, measure instead of only estimating

Our recommendation after this comparison: Llmspeed serves the shortlist and conversations about local AI well, because it tells scale, first-token latency and the memory question in one minute, and the race view makes buying decisions graspable. Building a purchase on it stays shaky as long as the concrete cell is derived and your own setup (drafting, context length, number of cards, backend) is not represented in it. These are the three steps we would take before our own order:

Run the same llama-bench protocol on the candidate card that the project uses as its standard: llama-bench -m model.gguf -p 512 -n 128.
Run one real agent session in the planned context range, because prefill, KV cache and drafting work together there and change the picture.
Compare offers per delivered token instead of per card. We show how that works in our price-per-token comparison, in what an AI model really costs and, for Macs and the DGX Spark, in this comparison.