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

README.md

@@ -88,6 +88,20 @@ Result: banned ops NONE, all tensors ≤4D, tflite-vs-torch corr **1.0**, device
 Center-crop to 3:4, resize to 192×256, ImageNet 0-255 normalize (mean [123.675, 116.28, 103.53], std
 [58.395, 57.12, 57.375]), NCHW planar. Top-down — expects one roughly-centered person.
 
+## 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 |
+|---|---|---|---|
+| LiteRT `CompiledModel` (`LITERT_CL`) | GPU | 256 / 256 | ~4 ms |
+| TFLite `benchmark_model` (`TfLiteGpuDelegateV2`) | GPU (OpenCL) | 256 / 256 | 15.8 ms |
+| TFLite `benchmark_model` | CPU (XNNPACK, 4 threads) | — | XNNPACK declined the graph |
+
+**The two GPU rows are different runtimes, not a contradiction.** The `LITERT_CL` figure is the one recorded when this model shipped, taken through LiteRT's own `CompiledModel` accelerator — the path the Kotlin sample app and the LiteRT API use. The `TfLiteGpuDelegateV2` figure is the classic TFLite OpenCL delegate, measured with a tool anyone can download and re-run. They agree on how much of the graph the GPU takes; they disagree on speed, and the classic delegate is the slower of the two here. Read the `TfLiteGpuDelegateV2` row as a reproducible floor, not as this model's speed on LiteRT.
+
+XNNPACK declines these fp16 graphs — it reports `failed to delegate DEPTHWISE_CONV_2D` and then fails to allocate tensors — so there is no usable CPU number. Disabling XNNPACK falls back to reference kernels, which measured about 20× slower than the GPU on models of this size and would not represent CPU inference anyone would ship.
+
 ## License
 
 [Apache-2.0](https://github.com/open-mmlab/mmpose/blob/main/LICENSE). Upstream: