llmfit 1.0 — the release where the numbers became verifiable

[AlexsJones]

The community around llmfit constantly challenges us toward excellence — and rightly disconfirms, critiques, and asks for more. You told us the tok/s estimates weren't accurate enough, and you were right. llmfit 1.0 is the culmination of a lot of work to improve that — and we're calling it 1.0 because this is the release where every number llmfit shows you became verifiable.

Until now, llmfit's speed estimates came from a pure physics-based memory-bandwidth model with fixed assumptions baked in. Starting with 1.0, that model is grounded in runtime sampling and real measured data:

1. Your machine is now sampled, not assumed

llmfit measures your system's effective RAM bandwidth at startup with a short multithreaded sampling sweep (~100 ms), replacing a hardcoded 50 GB/s DDR4 assumption. On modern DDR5/LPDDR5X systems this roughly doubles the accuracy of offload estimates — especially for Mixture-of-Experts architectures, where expert streaming over system RAM is the bottleneck. llmfit system shows you the measured number:

Total RAM: 30.82 GB
Available RAM: 18.57 GB
RAM Bandwidth: ~105 GB/s (measured)

2. Real user data beats formulas

If your GPU matches community benchmark data (RTX 3090/4090/5090, A100, Apple M-series, …), the fit table now shows measured tok/s marked with ✓ — real runs from real users on your hardware (localmaxxing.com), not an estimate.

3. Every estimate now ships its inputs

llmfit info prints the Estimate Basis — the exact bandwidth, efficiency factor, and context assumptions behind the number — plus commands to verify it on your own machine (llmfit bench, or a llama-bench recipe that measures the same quantity the estimate models). No more unexplainable numbers (#292). And when we don't recognize your GPU, we now say so plainly instead of printing a confident guess.

4. Estimates are audited against reality, weekly

CI replays community-measured benchmark runs through the estimator every week; current calibration is median estimated/measured 0.87, and any change that drifts past 2× systematic bias fails the build.

---

What 1.0 means

Going 1.0 is a commitment, not just a number: the --json output schema, exit codes, and environment variables that your scripts and agents depend on are now stable interfaces — breaking them is a major-version event from here on.

Credit where it's due: @RhoMancer's calibration work in #450/#464, @Magolor's #449 report, @kursad-k's #88, and the #292 thread drove this.

Two asks:

• If llmfit tells you your GPU isn't in the bandwidth table, open an issue with the model name — that's one lookup-table entry between you and better estimates.
• If you want your hardware to show measured ✓ numbers, submit a run to localmaxxing.com — every submission makes the numbers more honest for everyone.

---

Get it: llmfit v1.0.0 — binaries for macOS, Linux, and Windows

What's next: we want the measured ✓ data to come from you, with full provenance — the proposal is llmfit bench --all --share, which turns your benchmark run into a pull request under your own GitHub handle. No upload API, no telemetry; every data point a public, auditable commit. The RFC with open design questions is up in #710 — input very welcome.

[RhoMancer]

So happy to have contributed to this! Looking forward to see what you've cooked up!