Why isn't AI model response time enough to measure smart-glasses latency?
The wearer also waits for input detection, transport, queueing and display delivery. Model response time covers only one part of that path. Making the model faster may have little visible effect if another stage consumes most of the delay.
Time the gaps around the model
Record when the request starts, when processing begins, when useful output is ready and when it appears on the glasses. Use a valid measurement method across devices rather than subtracting unrelated clocks. Those boundaries show whether time is spent generating the answer or waiting to move it.
In a hypothetical two-second response, the model might account for half a second and the rest for capture, waiting and delivery. Reducing that half-second helps, but investigating the other one and a half seconds offers more room for improvement. These are illustrative values, not E1O benchmark results.
A worked two-second timeline
These invented stage durations show why a fast model can still sit inside a slow experience. The stages are sequential for this example; a real system may overlap some of them.
| Stage | Duration |
|---|---|
| Finalize captured input | 300 ms |
| Transport and queue before processing | 700 ms |
| Model processing | 500 ms |
| Return, delivery and visible rendering | 500 ms |
| Total from defined start to visible result | 2,000 ms |