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
The question for today
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.
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.
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.
Work it through
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.
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.
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.
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.
Resource ceilings screen feasibility, while measured complete requests establish the workload’s observed behavior.
The living notebook
Explore the model
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.
- Attainable ceiling
- 640 GFLOP/s
- Ridge intensity
- 12.5 FLOP/byte
- Ceiling regime
- Memory-bound ceiling
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.
Pause & reason
Check your understanding
Your turn
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.
Keep the idea
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.