Card: add a measured Performance table (Pixel 8a, benchmark_model GPU+CPU), naming the runtime for each row

README.md

@@ -123,6 +123,21 @@ accumulation) is in the sample app's `ActionRecognizer.kt`.
 Re-authored and converted with **litert-torch**. See the sample app and build script:
 `build_movinet.py` + `stream_model.py`.
 
+## Performance
+
+Measured on a **Pixel 8a** (Tensor G3, Android 16) with the standard TFLite [`benchmark_model`](https://ai.google.dev/edge/litert/models/measurement) tool — 10 warm-up runs then 50 timed runs, reported as the tool's mean.
+
+| Runtime | Backend | Graph on GPU | Latency |
+|---|---|---|---|
+| TFLite `benchmark_model` (`TfLiteGpuDelegateV2`) | GPU (OpenCL) | 440 / 840 | 53.0 ms |
+| TFLite `benchmark_model` | CPU (XNNPACK, 4 threads) | — | 9.8 ms |
+
+**Any on-device figure recorded when this model shipped came from a different runtime.** It was taken through LiteRT's own `CompiledModel` accelerator (logcat reports it as `LITERT_CL`), which is the path the Kotlin sample app and the LiteRT API use, and it appears elsewhere on this card. The rows above are the classic TFLite OpenCL delegate, measured with a tool anyone can download and re-run. The two are not comparable, so read the rows above as a reproducible floor rather than as this model's speed on LiteRT.
+
+On this delegate the CPU is the faster choice for (9.8 ms on CPU against 53.0 ms on GPU) — worth knowing before you reach for the GPU on a mid-range phone.
+
+Note that the GPU does not take the whole graph here (440 of 840); the remainder runs on the CPU and the split costs a per-partition round trip.
+
 ## License
 
 Apache-2.0 (MoViNet / Atze00/MoViNet-pytorch). Kinetics-600 label taxonomy from the