advanced27 min studyLesson 961 in Engineering

Edge device resource and latency profiles

Build an end-to-end latency and memory budget for a named device configuration rather than inferring deployment feasibility from peak arithmetic rates.

On this page

What you’ll understand

  • Distinguish flash capacity, working RAM, bandwidth and sustained compute.
  • Separate kernel lower bounds from measured end-to-end latency.
  • Construct a resource profile with explicit workload and measurement conditions.

A model that fits in a downloadable file may still exceed a device’s working memory or miss its response deadline. Edge deployment begins with a resource profile of the complete application: sensor input, preprocessing, model execution, output handling, and concurrent system work. Name the device revision, runtime build, accelerator, power mode, and operating conditions. A peak compute number describes one ceiling; it does not establish usable inference quality or sustained response time.

Separate storage from live execution resources

Flash or persistent storage holds model files and application code; RAM holds active tensors, interpreter metadata, stacks, input buffers, and kernel workspace. Some platforms access constants directly from mapped storage, while others copy or transform them into RAM or accelerator memory. Do not count a compressed model file as the working-memory requirement. Measure initialization and steady execution separately because unpacking, compilation, or weight repacking can create a larger startup peak than a single warm inference.

Include the rest of the application in the budget. Camera buffers, audio capture, radio activity, UI rendering, and operating-system services compete with inference for memory, bandwidth, and scheduling time. A microcontroller without virtual memory and a mobile application managed by an operating system need different failure handling. Report what was reserved and what was merely observed free during one run. A successful allocation in a quiet laboratory is not a guarantee that the deployed workload always has the same resources.

Tresponse=Tqueue+Tcapture+Tpre+Ttransfer+Tinfer+TpostT_{\mathrm{response}}=T_{\mathrm{queue}}+T_{\mathrm{capture}}+T_{\mathrm{pre}}+T_{\mathrm{transfer}}+T_{\mathrm{infer}}+T_{\mathrm{post}}
This additive accounting assumes a single request follows these nonoverlapping stages; all terms use the same time unit. Overlapped pipelines require a dependency-based latency trace rather than summing work that runs simultaneously. State whether capture starts a new observation or reads an already available frame.↔ Scroll wide equations horizontally.

Use hardware ceilings as bounds, then measure

Compute work and transferred bytes provide useful feasibility checks. Under a declared arithmetic convention, divide operations by a compute ceiling and bytes by an applicable bandwidth ceiling. With ideal overlap, the larger duration is a lower bound, not the sum; dependencies, cache misses, launch overhead, and contention can increase actual latency. Specify whether a multiply-add counts as one or two operations. Comparing a model’s MAC count with a device’s FLOP rate without that convention creates a factor-of-two error before measurement begins.

Operational intensity relates arithmetic work to bytes moved at a specified memory boundary. It can differ between external memory, shared cache, and accelerator-local storage. A nominal bandwidth and a peak arithmetic rate need not be simultaneously attainable for the chosen kernel. Profile representative inputs and tensor layouts, including preprocessing and transfers. Keep cold start, first invocation, warm isolated inference, and continuous operation distinct; their bottlenecks and memory footprints can differ enough to require separate acceptance criteria.

Tkernel≥max⁡ ⁣(FPmax⁡,DB),I=FDT_{\mathrm{kernel}}\ge\max\!\left(\frac{F}{P_{\max}},\frac{D}{B}\right),\qquad I=\frac{F}{D}
Assume positive applicable ceilings P_max in FLOP/s and B in bytes/s, work F in FLOP, and transferred data D>0 in bytes at the named boundary. Ideal compute-transfer overlap gives this lower bound. It omits software overhead and contention and does not predict measured device performance.↔ Scroll wide equations horizontally.

Define a reproducible sustained workload

State arrival rate, batch size, input shapes, concurrency, quality targets, and deadline policy alongside the device settings. Record battery state, ambient temperature, enclosure, and whether charging or radios are active. Measure latency distributions and missed deadlines over a useful duration rather than reporting only the fastest run. The MLPerf Tiny and Mobile papers motivate joint quality and performance evaluation, but a product’s sensor pipeline and duty cycle can require additional measurements beyond a benchmark’s defined workload.

The roofline instrument is a synthetic ceiling illustration. Reset, set intensity I to 2 and bandwidth B to 80, predict performance ceiling 160 GFLOP/s, then Step. Compare a fresh Reset with both I at 8 and B at 80 before Step: 640 GFLOP/s. Its compute roof is fixed at 1,000 GFLOP/s. These numbers do not describe an edge processor or estimate application latency; they show how a declared boundary and arithmetic intensity affect one idealized bound.

A compute bound and an actual request budget

A hypothetical edge kernel performs 120 million FLOP and transfers 24 decimal MB. Use ceilings of 5 GFLOP/s and 2 GB/s. Separately, measured nonoverlapping stages take 5 ms preprocessing, 2 ms transfer, 30 ms inference, and 3 ms postprocessing; input is already available. The request period and deadline are 50 ms.

  1. Compute duration is at least 120 million / 5 billion = 24 ms. Memory duration is at least 24 million / 2 billion = 12 ms, giving an ideal-overlap kernel lower bound of 24 ms.

  2. The measured response without queueing is 5 + 2 + 30 + 3 = 40 ms. The 30 ms measured inference need not equal its 24 ms lower bound.

  3. The sequential workload consumes 40/50 = 0.8 of each period and leaves 10 ms of nominal deadline margin. Bursts, contention, capture delay, or thermal changes can consume that margin and still require tests.

The result

Resource ceilings screen feasibility, while measured complete requests establish the workload’s observed behavior.

Explore the model

Interactive lab

Interactive lab · roofline

A synthetic bound before device measurement

Reset, set I = 2 and B = 80, predict the 160 GFLOP/s ceiling, then Step. Compare a fresh Reset with both I = 8 and B = 80 before Step: 640 GFLOP/s. The fixed compute roof is 1,000 GFLOP/s; this is not a device profile, measured edge throughput, or complete latency model.

A synthetic bound before device measurementSynthetic roofline ceiling min(1000, B·I), in GFLOP/s, with B in decimal GB/s and I in FLOP/byte. Playback traces the roof without changing the selected kernel. This upper-bound model is not a measured throughput prediction, hardware comparison or price model. Current readings: Attainable ceiling: 640 GFLOP/s; Ridge intensity: 12.5 FLOP/byte; Ceiling regime: Memory-bound ceiling. All parameters are adjustable with the labeled controls below.Hypothetical roofline upper bound: 640 GFLOP per second at operational intensity 8 FLOP per byte and bandwidth 80 gigabytes per second.0.1110641101001000Operational intensity · FLOP/byte · log scaleCeiling · GFLOP/s · log scalePeak: 1000
Attainable ceiling / kernelBandwidth roof / traceCompute ceiling
Attainable ceiling
640 GFLOP/s
Ridge intensity
12.5 FLOP/byte
Ceiling regime
Memory-bound ceiling
t = 0 s

Synthetic roofline ceiling min(1000, B·I), in GFLOP/s, with B in decimal GB/s and I in FLOP/byte. Playback traces the roof without changing the selected kernel. This upper-bound model is not a measured throughput prediction, hardware comparison or price model. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.

Look forA hardware ceiling and an observed application latency are different quantities.

Check your understanding

A model file is 2 MB and a device advertises 4 MB of RAM. What is the supported deployment conclusion?

Try it yourself

A hypothetical kernel needs 80 million FLOP and 16 MB at ceilings 4 GFLOP/s and 1 GB/s. Measured preprocessing, inference, and postprocessing are 4, 28, and 3 ms with no overlap or queueing. Compare the lower bound and measured response with a 40 ms deadline.

Take a moment to make a prediction or work it out on paper. Open a hint when you need one.

Give me a hint

Use decimal prefixes and take the larger ideal compute or transfer duration; measured stages form a separate sum.

Compare with the solution

The compute bound is 20 ms and transfer bound is 16 ms, so ideal kernel time is at least 20 ms. The measured complete response is 4 + 28 + 3 = 35 ms, leaving 5 ms against the stated deadline under these conditions. That observation is consistent with the lower bound and does not establish a sustained or tail-latency guarantee without repeated representative measurements.

Take it with you

  • Budget persistent storage and live execution memory separately.
  • Compute and bandwidth ceilings give bounds rather than application measurements.
  • A reproducible device profile includes workload, quality, timing and operating conditions.

Read further

Original sources and deeper explanations to follow at your own pace.

Optional progress, saved in this browser when available. Revisit any lesson at any time.

Lesson not marked complete.