Contribute
Bindwidth is a frontend with no server and no telemetry. The maths is open. What it gets wrong — or gets right — lives in the catalogues: models, hardware, and benchmarks that people have actually run.
Why this matters
Organisations buy machines against the wrong constraint when the numbers underneath are guessed. Optimistic decode efficiency makes a configuration look cheap until someone tries to run it. A KV figure copied from a blog post quietly doubles the node count.
The calculator cannot invent measured truth. It can only surface the best data it has — and label how trustworthy each figure is. A pull request that adds one honest run is worth more than a dozen opinions about the UI.
You do not need to touch the application
Adding a model, a machine, or a benchmark means editing one JSON file under
data/. The interface loads those files at startup. If you can open a
pull request, you can improve the tool for everyone who sizes against it.
data/models.json— architecture profiles that drive memory and speeddata/hardware.json— owned nodes and rental optionsdata/benchmarks.json— historical measured runs (not used in maths until reviewed)
The ground rule
A number without its configuration cannot be reproduced.
Every entry carries a confidence field. It appears in the exported
report. Six months from now, knowing which figures were measured and which were
derived will matter more than the figures themselves.
| Level | Use it when |
|---|---|
measured | You ran it, on a pinned build, and can show the counters |
published | There is a public recipe someone else can follow |
community | Someone reported it and it has not been verified |
list-price | Straight from the vendor’s price page |
aggregator | From a price tracker, not the vendor |
estimated | Derived from bandwidth and memory arithmetic |
derived / kv-derived | Back-derived from another measurement; include the derivation and range |
template | A starting point, expected to be replaced |
Never promote a level without evidence. Downgrading is always allowed.
What belongs in a good submission
- The exact engine build (a commit hash, not “latest”)
- Flags, concurrency, and whether traffic was synthetic or realistic
- Failure modes — a run that documents what broke is more useful than a happy path alone
- Open contradictions left visible, not quietly averaged away — or split into separate catalogue rows when the configurations differ (e.g. NVFP4 KV vs FP8 KV)
First-party measured runs
The catalogue can accept your own hardware soaks via the existing benchmark issue
template. Prefer first-party when you operated the box: pinned build, full flags,
concurrency and context, soak duration, and failure modes (even “none observed”).
Reviewed values move into profiles.json only after that review — the
calculator never invents a measured number.
Open a
benchmark issue
or edit data/benchmarks.json directly with confidence measured.
Full field-by-field guidance lives in CONTRIBUTING.md on GitHub.
Reporting a modelling error
If the arithmetic itself is wrong, open an issue with the inputs, what the tool produced, and what you believe it should produce. Errors in the model matter more than errors in the data: a formula pointing at the wrong cell still returns a number, and it looks fine until someone checks.