Real-ESRGAN General x4v3 — LiteRT (CompiledModel GPU)
Real-ESRGAN x4 — 128px input vs bicubic vs on-device x4 output (LiteRT GPU)
Real-ESRGAN realesr-general-x4v3 (SRVGGNetCompact, ~1.2M params, BSD-3-Clause) re-authored to a
GPU-native LiteRT .tflite via the official litert_torch path. ×4 real-world super-resolution.
FP16, 3.5 MB, input 128×128 → output 512×512 (NHWC, RGB, 0–1).
Verified on a Pixel 8a: the whole graph runs on the GPU delegate (full LITERT_CL residency,
211/211 nodes, 1 partition) in ~1 ms, and the GPU output matches the CPU/PyTorch reference
(corr ≈ 0.995).
Why this is GPU-clean
A pure CNN, but the stock conversion isn't GPU-clean: PReLU lowers to GREATER+SELECT+MUL
and PixelShuffle lowers to a >4-D reshape — both GPU-rejected. Here:
PReLU → relu(x) − a·relu(−x) (per-channel a): exact, only RELU/MUL/SUB.
PixelShuffle(4) → a one-hot ConvTranspose(stride 4) → ZeroStuffConvT (zero-stuff nearest +
Conv2d): exact, no TRANSPOSE_CONV, no >4-D tensors.
Result: zero GATHER/SELECT/TopK/Cast, no >4-D tensors — full GPU residency. Re-authored vs
original: corr 1.000000.
I/O
Input[1, 128, 128, 3] NHWC, RGB, 0–1 float (no mean/std). Tile larger images into
128×128 patches.
Output[1, 3, 512, 512]NCHW, RGB, 0–1 (clamp to [0,1]). ×4 upscale — note the
input is NHWC but the output tensor is NCHW.
Minimal usage
Android (Kotlin, CompiledModel GPU)
kotlin
1val model = CompiledModel.create(context.assets,"realesr_general_x4v3.tflite",2 CompiledModel.Options(Accelerator.GPU),null)3val inputs = model.createInputBuffers()4val outputs = model.createOutputBuffers()5inputs[0].writeFloat(nhwc)// [1,128,128,3] RGB in [0,1], NHWC6model.run(inputs, outputs)7val up = outputs[0].readFloat()// [1,3,512,512] NCHW in [0,1] (x4)
realesr-general-x4v3 was trained by the Real-ESRGAN authors on public super-resolution datasets
(DIV2K / Flickr2K / OST and a synthetic high-order degradation pipeline). The model upscales image
pixels only — no faces, identities, or other personal attributes are detected, recognized, or
output. No additional or private data was used; weights are the official release, only the op graph
was re-authored for GPU.
Measured on a Pixel 8a (Tensor G3, Android 16) with the standard TFLite benchmark_model 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
211 / 211
~1 ms
TFLite benchmark_model (TfLiteGpuDelegateV2)
GPU (OpenCL)
210 / 210
40.4 ms
TFLite benchmark_model
CPU (XNNPACK, 4 threads)
—
532.1 ms
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.
Snapdragon NPU (Hexagon)
This file runs on the Qualcomm Hexagon NPU as published — no conversion and no
pre-compiled artifact. LiteRT compiles it on the device and caches the result.
Measured on a physical Samsung Galaxy S26 (Snapdragon 8 Elite Gen 5 / SM8850,
Hexagon v81) with LiteRT CompiledModel 2.2.0 — 5 warm-up runs then 50 timed runs, one
accelerator per process, every row taken at device thermal status NONE.
Compute unit
Inference (median / min)
Load
Start headroom
NPU (Hexagon) — first launch
10.12 ms / 10.04 ms
2906 ms
0.58
NPU (Hexagon) — cached
10.26 ms / 10.07 ms
102 ms
0.59
GPU (Adreno)
14.07 ms / 13.59 ms
407 ms
0.59
The NPU is 1.4x faster on inference here (10.26 ms against 14.07 ms). The first launch pays once for on-device compilation; every launch after that
loads in 102 ms against 407 ms for the GPU (4.0x), because the GPU rebuilds its
shaders each time. The file is fp16 and needs no int8 quantization to reach the NPU.
Running it on the NPU
Put these in jniLibs/arm64-v8a/. None of them are distributed from this repository —
the first two come from Google, the rest from Qualcomm's own SDK:
Qualcomm QAIRT — the same zip ships fetch_qualcomm_library.sh, which downloads the SDK and copies them for you
Pick the runtime matching the device's Hexagon version: SM8550 → v73, SM8650 → v75,
SM8750 → v79, SM8850 → v81.
kotlin
1val env = Environment.create(2 context,3mapOf(4 Environment.Option.DispatchLibraryDir to context.applicationInfo.nativeLibraryDir,5// Required for on-device compilation. Without it the model silently runs on CPU.6 Environment.Option.CompilerPluginLibraryDir to context.applicationInfo.nativeLibraryDir,7),8)9val options = CompiledModel.Options(Accelerator.NPU).apply{10 qualcommOptions = CompiledModel.QualcommOptions(11 htpPerformanceMode = CompiledModel.QualcommOptions.HtpPerformanceMode.BURST
12)13}14val model = CompiledModel.create(context.assets,"realesrgan.tflite", options, env)
Build settings: useLegacyPackaging = true under packaging { jniLibs { … } }, so the
DSP can open the skel from a real path, and Kotlin 2.3+ for LiteRT 2.2.0's metadata.
Every NPU failure here is silent. There is no error when the NPU is unavailable —
you get a plausible CPU number instead. Confirm from logcat which delegate took the
graph: Replacing 1 out of 1 node(s) with delegate (DispatchDelegate) is the NPU,
while ... (TfLiteXNNPackDelegate) is the CPU. A missing library is reported only as
a W-level dlopen failed line under a generic No compiler plugin found summary.
On the conditions. Thermal headroom is reported as measured, where 1.0 is the
throttling threshold. All rows were taken at a comparable headroom and compare directly;
figures taken at a different headroom will differ. Each accelerator ran in its own
process, because LiteRT's Environment is shared within one and the first model load
fixes the options for every later one.
Raspberry Pi 5 (CPU)
Measured on a Raspberry Pi 5 Model B Rev 1.1 (8 GB, Raspberry Pi OS 64-bit) with the LiteRT benchmark_model tool from litert-cli-nightly 0.2.0.dev20260805: CPU inference (XNNPACK, 4 threads), 3 invocations per file of 10 warm-up plus 50 timed runs (the tool caps a phase at 150 s, so very slow graphs run fewer — the Runs column is the actual timed total). The latency is the median across invocations; the spread is the min–max over all timed runs. No thermal throttling occurred during these runs (vcgencmd get_throttled stayed 0x0).
