One whole architecture, composed and re-decided nowhere
Describe the deployment and the pipeline that runs on it. Hardware Match picks the platform, the node count and the per-node camera split, and its answer is copied here without change — no second ranking pass, no confidence re-pick, no mutation of the alternatives. Model Match picks a model for each stage on that platform, or Compute Fit checks the one you pinned. Camera Stream Capacity, the thermal, carrier, JetPack, PSU and PoE engines supply the node-level constraints, each stamped with the engine that asserted it. Where two stages share one accelerator the engine sums their utilizations — an assumption with no measurement behind it anywhere in this corpus, so it is class E and it caps the verdict at NEEDS VALIDATION.
01 · Describe the deployment
Cameras & streams
Cameras
4
8
16
32
48
Resolution
720p
1080p
1440p
4K
Frame rate
10 fps
15 fps
25 fps
30 fps
Detect rate
Same as frame rate
1 fps
5 fps
10 fps
Codec
H.264
H.265
Precision
INT8
FP16
FP32
Recording
Continuous
On motion
Not recorded
Retention
7 days
14 days
30 days
90 days
Scenario & what to optimise
Use case
Security / NVR
Retail analytics
Industrial inspection
Traffic
Environment
Indoor, controlled
Indoor, warm
Outdoor
Optimise for
Loading the catalog…
Model preference
Node cap
The pipeline
One stage runs one model. Add a second and the two share one accelerator on every node — a composition this engine reports as class E, because no measurement of concurrent models exists in this corpus.
Stages
Constraints
Power ceiling
None
60 W
150 W
400 W
Cooling
Fan allowed
Fanless
Node power
DC supply
PoE
Advanced
Check a specific platform
Enclosure
Not stated
Open frame
Vented
Vented + fan
Sealed, fanless
Outdoor, sealed
Ambient ceiling
Not stated
25 °C
40 °C
55 °C
Budget
Latency target
Loading the catalog…
03 · How this works
Composition, not a new opinion
This engine owns exactly one judgement, and it is the one it labels loudest: how to put two model stages on one accelerator. Everything else belongs to an engine that already answers it. Hardware Match decides the platform, the node count and the per-node camera split, and that answer is copied verbatim — there is no second ranking pass here, no re-pick on confidence, and the alternatives are its ranked list, in its order, carrying its own role labels. Model Match decides the model for each stage on that platform; a stage whose model you pinned goes to Compute Fit instead. The node-level constraints come from Camera Stream Capacity, the Thermal Feasibility Checker, Carrier Finder, the Jetson Configuration Checker, Jetson Power & PSU, Frigate Fit and Drive Endurance, each stamped with the engine that asserted it, so any number on the page can be traced back to the engine responsible for it and reproduced by running that engine directly.
The pipeline sum is class E, and it caps the verdict
When two stages share one accelerator, their utilizations are summed and their memory is added on the shared memory budget. Nothing measures that. The multi-stream scaling curve in this repository models N streams of one model, and the only multi-model source on record recommends separate containers with CUDA stream priority rather than MPS and budgets about three per cent container overhead — a recommendation, not a throughput measurement, so it is cited and never turned into a number. A class E sum can prove a miss but it can never confirm a fit, which is why every multi-stage architecture is capped at NEEDS VALIDATION and each stage is also reported on its own. The measurement protocol is what closes that gap.
What is still legacy, and labelled as such
Network bandwidth, storage size, system power and every bill-of-materials line except the compute module still come from the legacy engines. None of those figures carries a source record, so they ship labelled class E line by line rather than dropped or quietly promoted. Sourced cost is Deployment Cost & TCO’s job and replaces them there. The hardware cost and power on the architecture itself are Hardware Match’s and carry its class.
Full rules, the class E sharing assumption in detail and what invalidates a result: methodology.
04 · FAQ
Why is a two-stage pipeline never a clean FIT?
Because nothing in this corpus measures two models sharing one accelerator. The multi-stream scaling curve models N streams of one model; the stage vocabulary in the research corpus is decode, preprocess, infer, postprocess of a single model. So when two stages share a node the engine does the only defensible thing — it sums their utilizations and adds their memory on the shared budget — and labels that sum class E. A class E sum cannot confirm a fit, so any multi-stage architecture is capped at NEEDS VALIDATION with a link to the measurement protocol. Measure it on the hardware before you commit.
Can this engine pick a different platform from Hardware Match?
No. The platform, the node count, the per-node camera assignment, the hardware cost and the hardware power are Hardware Match’s answer, copied without change. There is no second ranking pass here, no confidence re-pick and no mutation of the alternatives — they are Hardware Match’s ranked list in its order, carrying its own role labels. If the composed pipeline does not fit on the platform it picked, that is reported as it is rather than triggering a re-rank: reduce the fan-out, pin a smaller model, raise the node cap or pin a platform.
Why are the whole-system cost and power labelled class E?
Because network bandwidth, storage size, system power and every bill-of-materials line except the compute module still come from the legacy engines, and none of those four figures carries a source record. They ship labelled class E, line by line, rather than being quietly dropped or quietly promoted. Sourced cost is Deployment Cost & TCO’s job and replaces them there. The hardware cost and hardware power on the architecture itself are Hardware Match’s and carry their own class.
What does the rate field on a pipeline stage mean?
It depends on what the stage runs on. A stage that runs on frames takes an explicit frames-per-second figure; leave it blank and the stage inherits the detect rate from the workload. A stage that runs on an earlier stage’s output takes a fan-out — how many detections each frame produces, which is what that stage is then asked to process. The fan-out has no measurement behind it: it is a class E assumption about your scenes, it defaults to one per frame, and it multiplies straight into the required throughput, so it is worth stating deliberately.
How do I check one specific platform rather than the whole catalog?
Pin it. The “check a specific platform” control restricts the candidate set to the platform you name and changes no other rule — the same engines run, the same constraints are asserted, the same evidence classes apply. If the pinned platform cannot hold the workload at the node cap, the result says so rather than substituting a platform you did not ask about.