Model-in-the-Loop Engineering · Capstone brief
ENG-07 · Edge vs. cloud latency
For the same model task on edge vs. cloud paths the teacher approves, what is end-to-end latency — and does it fit inside the control-loop deadline for your named decision?
The question
For the same model task on edge vs. cloud paths the teacher approves, what is end-to-end latency — and does it fit inside the control-loop deadline for your named decision?
System / materials
Teacher sets network conditions (school LAN, throttled link, or logged timestamps from two deployment configs). Same input tensor / feature vector both paths.
Expected failure modes
Measuring inference only, ignoring network. Comparing unlike hardware fairly.
Done looks like
Latency breakdown table (capture → infer → actuate) and a written pass/fail against a teacher-set deadline in milliseconds.
Five C's
CT: deadline from physics, not from SLAs on a slide. CR: fair hardware comparison. CO: peer checks timestamps. CM: table an IT/OT bridge person reads. CZ: who is at risk if the loop is late.
Mentor role
Embedded or cloud engineer reviews measurement plan at Checkpoint 1 and deadline argument at Checkpoint 2. School-supervised.
Rubric calibration
R1: one decision, one deadline. R2: raw timestamps archived. R3: edge and cloud both measured. R4: actuation delay included. R5: pass/fail explicit. R6: refuses cloud for safety-critical without backup.
Two ways this goes wrong
(a) GPU bench only, no end-to-end. (b) Deadline invented after seeing results.
Credit lane fit
Lane A immediately. No verified credit claim.