We started with one narrow question: can TensorFold beat llama.cpp on the same class of phone without turning the comparison into marketing math?

On the OnePlus CPH2655 reference pair, the answer is yes. The implementation details still matter.

THE CONTROLLED RESULT

Both lanes used the immutable TensorFold community-v2 prompts, temperature 0, a 256-token output budget, one excluded warm-up, and five measured repetitions. Every measured request completed.

community-v2 | Phone B: TensorFold | Phone A: llama.cpp Code delivery | 17.88 tok/s | 11.95 tok/s Chat delivery | 13.27 tok/s | 12.00 tok/s Code TTFT | 0.045 s | 0.170 s Chat TTFT | 0.043 s | 0.182 s Completion | 5/5 | 5/5

TensorFold was 49.64% faster on code delivery and 10.64% faster on chat delivery in this fixed comparison.

TensorFold receipt: 9d0fd1cb-b8c3-471f-8922-a5f6f2bfa9e1 llama.cpp control: 340b721f-eb31-4095-ba61-86565c5edac4

Benchmark visual: https://raw.githubusercontent.com/Ch0mpaa/TensorFold/qualcomm-android/docs/images/tensorfold-qualcomm-benchmark.png

These are local Android receipts. They remain unranked until the community receiver accepts Android and Qualcomm manifest facts.

THE PART WE REFUSED TO FAKE

The fastest engineering path uses Qualcomm HTP through FastRPC. Ordinary Android apps do not receive direct write access to /dev/fastrpc-cdsp on the reference firmware. We will not pretend every Play-installed APK can use that path.

The product has two explicit lanes:

  1. Qualcomm HTP engineering runtime, which produced the comparison above.
  2. Rootless public Android app, which uses an exact portable CPU runtime under an ordinary app UID.

Vulkan initialized and ran quickly on Adreno 830, but it generated different retained tokens. TensorFold disables that path instead of serving plausible but incorrect text.

THE ANDROID APP

TensorFold Mobile now runs entirely on the phone:

  • No Mac, Python, Termux, root, shell, or separately started server.
  • Hash-pinned Hugging Face model catalog.
  • Resumable HTTPS downloads into app-private storage.
  • Content-bound caches and warm restart.
  • Local multi-turn chat.
  • On-phone diagnostic benchmarking.
  • Random 256-bit bearer authentication on every loopback route.
  • Parent-death ownership, explicit cancellation, and no orphaned model process.
  • 43 C thermal admission guard.
  • 16 KiB-compatible arm64 ELF load segments.
  • Bounded PwnHarness handoff without unrestricted Android automation.

App screenshot: https://raw.githubusercontent.com/Ch0mpaa/TensorFold/qualcomm-android/docs/images/tensorfold-oneplus-sm8750.png

Architecture visual: https://raw.githubusercontent.com/Ch0mpaa/TensorFold/qualcomm-android/docs/images/tensorfold-qualcomm-architecture.png

Final qualification APK SHA-256: 9b639364cef8764ba15288e84d9d935f2ce4a93a0726cbf8da5055e61690dc05

The public 2B CPU quick workload produced 16.10 tok/s for code and 15.69 tok/s for chat. Those diagnostic numbers are not mixed with the 4B HTP versus llama.cpp community-v2 result.

REPRODUCE AND INSPECT

Qualcomm Android branch: https://github.com/Ch0mpaa/TensorFold/tree/qualcomm-android

Android app documentation: https://github.com/Ch0mpaa/TensorFold/blob/qualcomm-android/docs/android-app.md

Qualcomm engineering notes: https://github.com/Ch0mpaa/TensorFold/blob/qualcomm-android/docs/qualcomm-android.md

WHAT IS NEXT

The next Qualcomm target is Qwen3.5-35B-A3B in packed EXL3 form. It has about 35B total parameters and about 3B active per token. TensorFold has completed the first full packed forward pass on Phone B. It is not supported yet.

Before release, it must pass ExLlamaV3 token parity, memory, thermal, lifecycle, quality, and speed gates. After that, we connect it to the bounded offsec harness. PwnHarness keeps control of scope, approvals, evidence, and STOP. TensorFold remains the local inference engine.

Bigger model first. Bounded offsec harness second. Pixel TPU work starts only after the Qualcomm path is qualified.

Fast is useful. Fast and wrong is not.