Card: correct the GPU node counts — the previous figures added the XNNPACK fallback partition to the GPU delegate partition

README.md

@@ -87,12 +87,12 @@ Measured on a **Pixel 8a** (Tensor G3, Android 16) with the standard TFLite [`be
 
 | Runtime | Backend | Graph on GPU | Latency |
 |---|---|---|---|
-| TFLite `benchmark_model` (`TfLiteGpuDelegateV2`) | GPU (OpenCL) | 3157 / 6425 | 9277.4 ms |
+| TFLite `benchmark_model` (`TfLiteGpuDelegateV2`) | GPU (OpenCL) | 108 / 3266 | 9277.4 ms |
 | TFLite `benchmark_model` | CPU (XNNPACK, 4 threads) | — | 4066.1 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 (4066.1 ms on CPU against 9277.4 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 (3157 of 6425); the remainder runs on the CPU and the split costs a per-partition round trip.
+Note that the GPU does not take the whole graph here (108 / 3266); the remainder runs on the CPU and the split costs a per-partition round trip.