Tensor G5 Took the Whole Graph. Android Still Said No.

Portable Local AI's first Pixel 10 Pro Fold TPU qualification run selected 175 of 175 operations, hit an EdgeTPU access denial, fell back to CPU, and was rejected by our own attestation gate.

Last week's work was about Snapdragon, Qwen, and how far we could push a matched mobile inference comparison. This is not that story again. This week we moved to a Google Pixel 10 Pro Fold with Tensor G5 and asked a narrower question: can an ordinary Android application prove that a model actually ran outside the CPU?

We did not get a TPU benchmark. We got a better first result: a complete, reproducible failure chain that our application refused to mislabel as acceleration.

What we built

Portable Local AI is the research and product umbrella. The Android integration uses TensorFold, an independently maintained upstream engine, through our Ch0mpaa Android fork. TensorFold is not owned by Portable Local AI, and no upstream or vendor endorsement is implied.

The branch is still named qualcomm-android because the mobile work started on Snapdragon. This Pixel probe is a separate Google Tensor path, committed at 55e58769.

View full-resolution evidence ↗

Supporting device evidence from the TensorFold-based Android integration. TensorFold is maintained independently upstream; this screenshot is not Portable Local AI product branding and is not the article's hero image.

The probe uses LiteRT 2.3.0 and Google's Tensor runtime package against the official MediaPipe selfie_multiclass.tflite segmentation model. The file is pinned to 16,371,837 bytes and SHA-256 c6748b1253a99067ef71f7e26ca71096cd449baefa8f101900ea23016507e0e0.

The qualification path has three independent checks:

1. A separate CPU CompiledModel produces the reference output.
2. A second CompiledModel requests the NPU path through the Google Tensor provider.
3. A native call to LiteRtCompiledModelIsNonCpuFullyAccelerated decides whether that second model is allowed to carry an accelerator label.

If the model is missing, its digest changes, compatibility fails, a native handle is unavailable, the output diverges, or LiteRT does not attest full non-CPU acceleration, the probe remains unavailable. TensorFold language-model serving stays on CPU.

What the Pixel actually did

The physical run used a stock Pixel 10 Pro Fold with Tensor G5 and Android 17.

LiteRT loaded the Google Tensor compiler adapter. The compiler inspected the segmentation graph and selected all 175 operations into one partition. That proves the compiler considered the full graph selectable. It does not prove those operations executed on the TPU.

The next boundary made that distinction clear. During compilation, vendor.google.edgetpu_app_service rejected the calling package, dev.tensorfold.mobile, because the package was not on the EdgeTPU allowlist or its signature did not match. The client returned error 16:

Current application should not be allowed to access EdgeTPU.

LiteRT reported that zero compiler plugins were applied successfully, initialized the original flatbuffer, and used the XNNPACK CPU delegate. The model remained runnable, but it was not a TPU model.

That is where the Portable Local AI gate mattered. The native non-CPU-full check rejected the compiled model, the app displayed the TPU probe as not admitted, and the serving tier remained qualified-portable-cpu.

No TPU timing was recorded. No CPU timing was relabeled. No speedup graphic was produced.

Why the refusal matters

A fallback is good product behavior when a user only needs an answer. It is bad benchmark behavior when a project claims an accelerator result.

View full-resolution evidence ↗

Condensed from the physical release-APK log. LiteRT selected the graph, the EdgeTPU package and signature gate denied compilation, XNNPACK initialized the original model, and Portable Local AI rejected the fallback.

An initialization call succeeding does not prove the selected accelerator executed the model. A delegate loading does not prove every operation landed there. Even a model returning plausible output does not identify the hardware that produced it.

Our rule is intentionally stricter: the accelerated label requires an independent backend attestation and output parity against a separate CPU oracle. The Pixel run failed before the parity stage because the accelerator attestation was already false.

That failure is the result. Publishing anything faster would have been easier and wrong.

What this does not prove

• No operation from this probe ran on the Tensor G5 TPU.
• No TPU latency, throughput, energy, memory, thermal, quality, or parity result exists yet.
• The probe is a vision model, not a language model.
• TensorFold EXL3 and LLM serving remain on the qualified portable CPU path on this Pixel.
• Selecting 175 of 175 operations is compiler-planning evidence, not execution evidence.
• This result is not comparable to last week's Snapdragon/Qwen measurements.

View full-resolution evidence ↗

The four actors in order: LiteRT compiler, EdgeTPU service, LiteRT CPU fallback, and the Portable Local AI attestation gate. The final serving state remained qualified-portable-cpu.

Receipts

Google documents the Tensor SDK Beta and supported Tensor SoCs in its Google Tensor with LiteRT guide. The broader deployment model and NPU packaging path are documented in the LiteRT NPU guide.

What happens next

We submitted the Google Tensor SDK Beta access request. Approval is pending. We are not publishing the associated cloud project identifier, account details, signing material, or private SDK links.

The next valid run needs the final Android package identity and production signing certificate admitted by Google, plus the Beta AOT compiler artifact. Then we rerun the same fail-closed qualification against a supported Tensor G5 artifact. Only a successful non-CPU-full attestation and CPU-oracle parity result unlock performance measurements.

Until then, the honest status is simple: Pixel CPU inference works locally. The Tensor G5 compiler path is reachable. TPU execution is not yet admitted.

We did not qualify the TPU this week. We qualified the check that stops us from pretending we did.