Home / Engines / Compute Fit

Does the compute hold this load — and where does the number come from?

One platform in, one answer out. The load you describe is checked against the throughput the benchmark database actually resolves for that model, variant, precision, runtime and input size — the pessimistic edge of the matching rows, with their ids, their evidence class and their source lines shown, or the estimator's fallback with its tier chain printed when nothing matched. Latency is reported in tiers that are never blurred: only a latency a publisher measured can pass a target, because the reciprocal of throughput is a lower bound that can prove a miss but never a fit. No platform is recommended here; the ladder says what else would run on the same silicon.

01 · Describe the configuration

Platform & model
Platform
Loading platform catalog…
Model family
Variant
Precision
Power mode
The load
Load from
Cameras
A frame-rate target
Cameras
1
4
8
16
32
Detect rate
1 fps
5 fps
10 fps
15 fps
30 fps
Frames with motion
20 %
50 %
80 %
All (worst case)
Latency target
Not stated
15 ms
33 ms
100 ms
500 ms
Advanced
Runtime
Model input
320
416
640
1024
Batch size
1
2
4
8
Headroom to keep
None
10 %
20 %
40 %
Loading the platform catalog…

03 · How this works

One resolver, and the pessimistic edge of it

The load you need is the target frame rate, or cameras times detect rate times the share of frames with motion — the sizing expression Frigate publishes for its own detectors. What the hardware gives is resolved once, through the normalised benchmark database: every row matching the model family, variant, precision, runtime and batch you asked for, narrowed to your batch size when rows exist there. The lowest of those rows is used, not the median and not the best figure anyone published, then scaled by the multi-stream efficiency curve and by a power-mode calibration when one exists. The whole range is printed beside it so you can see how far the published figures disagree.

When no row matches, the estimator's benchmark hierarchy is consulted and its tier chain is printed — which tiers were tried, which produced the number, and by what method. That figure is class D, a warning says it is modelled, and if the platform has no benchmark row of any kind the result says so outright. Nothing is presented as a measurement that was not measured.

Latency is the honest part

Of the rows in this database that report a latency, all but sixteen report a number within two per cent of 1000 divided by the frame rate on the same row: the latency was computed from the throughput, not observed. That is now flagged on every row at the point the database is built, so nothing downstream can present a reciprocal as a measurement. The check therefore has three tiers and never blurs them. A measured latency — one a named publisher observed and published — behaves normally and can pass. A stated latency is an independent figure whose only source is our own corpus; it is class D and returns REQUIRES VALIDATION at best. The reciprocal of throughput is class D too, and because it assumes a single frame in flight with no queueing or copy, it is a lower bound: it can prove a miss but never a fit. Every p99 in the database is a modelled multiplier over the p50 and is shown as context, never as the check.

UNKNOWN is never fatal and never free

A batch size nobody measured, a precision with no row, a platform outside the corpus — these come back UNKNOWN. That never fails the configuration and never passes it free: it caps the verdict at NEEDS VALIDATION until somebody measures it. A precision or runtime the silicon cannot run is different: that is UNSUPPORTED, it makes the verdict NO FIT, and no throughput is resolved for it at all, because a number about a configuration that cannot exist is a number about nothing.

Full rules, the tier definitions and what invalidates a result: methodology. Related: Benchmark Explorer is the database this reads; Benchmark Reality Check says what a published figure assumed; Camera Stream Capacity adds decode and memory to the picture; Hardware Match answers which platform when that is the question.

04 · FAQ

Why is the latency almost never a PASS?
Because almost no measured latency exists. Of the benchmark rows that report a latency, all but sixteen computed it as 1000 divided by the frame rate on the same row — a reciprocal of throughput, not an observation. A reciprocal is a lower bound on real latency: it assumes one frame in flight and no queueing, preprocessing or copy, so it can prove that a configuration misses a target but it can never prove that one meets it. Only a latency a named publisher measured and published can return PASS here; everything else returns FAIL when it already exceeds the target and REQUIRES VALIDATION otherwise.
Why does this not tell me which platform to buy?
Because that is a different question with a different engine. Compute Fit answers for the one platform you name, so its answer is checkable against that platform's own benchmark rows. Hardware Match ranks the whole catalog when the question is which platform. What Compute Fit does answer is what else would run on the hardware you already have: the ladder lists every model, variant and precision with a benchmark row for that silicon, with the throughput each would give and whether it holds your load.
Why is the available throughput the lowest number in the range rather than the median?
Because a capacity plan built on the best figure anyone published is a sales figure. Published benchmarks vary by batch size, thermal state, software version and how the harness measured; the pessimistic edge of the matching rows is the number most likely to survive contact with a real deployment. The full range — minimum, median and maximum — is shown beside it so you can see how wide the disagreement is.
What happens when there is no benchmark row for my configuration?
The estimator hierarchy is consulted and its tier chain is printed: which tiers were tried, which one produced the number, and by what method — a precision ratio, a cross-platform scaling, or the theoretical TOPS ceiling. The figure is labelled class D, a warning says it is modelled rather than measured, and if the platform has no benchmark row of any kind the result says that too. Nothing is presented as a measurement that was not measured.
Why is batch 8 UNKNOWN when batch 1 is fine?
Because batching changes throughput in ways this database cannot predict. Only fourteen rows in the entire corpus were measured above batch 1, all of them on Hailo silicon. Rather than scale a batch-1 figure by a made-up factor, a batch with no matching row returns UNKNOWN, which never fails the configuration and never passes it free: it caps the verdict at NEEDS VALIDATION until somebody measures it.