litert-community/TwinLiteNet-LiteRT

TwinLiteNet — Drivable-area + lane segmentation (LiteRT GPU)

On-device drivable-area and lane-line segmentation running fully on the LiteRT CompiledModel GPU delegate (no CPU fallback). TwinLiteNet (2023) is an ultra-light ESPNet-based network with two segmentation heads — the ADAS perception building block "where can I drive" + "where are the lanes". Only 3.1 MB, ~44 ms/frame on a Pixel 8a.

• Architecture: ESPNet-C encoder + two seg decoders — pure CNN.
• Weights: chequanghuy/TwinLiteNet (BDD100K) · MIT.
• Size: 3.1 MB.

Drivable area (green) + lane lines (red) on a dashcam highway frame. Source: Wikimedia Commons (Public Domain).

I/O

• Input: [1, 3, 360, 640] NCHW, RGB, x/255.
• Outputs: two [1, 2, 360, 640] logit maps — drivable_area and lane_line. Take argmax over the class dim (2) → binary masks.

GPU conversion

TwinLiteNet is a pure CNN. It converts fully GPU-compatible (270/270 nodes on the delegate, 1 partition; device corr 0.99997 / 0.99998 on the two heads, ~44 ms) with one patch: the ConvTranspose2d upsamplers → ZeroStuffConvT2d (nearest-upsample

• stride zero-stuff mask + flipped conv; the Mali delegate rejects TRANSPOSE_CONV). Exact. CPU-exact vs PyTorch (corr 1.0).

Minimal usage

Kotlin (Android, LiteRT CompiledModel GPU)

val options = CompiledModel.Options(Accelerator.GPU)
val model = CompiledModel.create(context.assets, "twinlite.tflite", options, null)
val inBufs = model.createInputBuffers()
val outBufs = model.createOutputBuffers()   // [0] = drivable area, [1] = lane line

inBufs[0].writeFloat(inputNCHW)             // [1,3,360,640] RGB, x/255
model.run(inBufs, outBufs)
val da = outBufs[0].readFloat()             // [2*360*640]; argmax over the 2 classes -> drivable mask
val ll = outBufs[1].readFloat()             // [2*360*640]; argmax -> lane mask
// per pixel p: class = if (da[p] > da[360*640 + p]) 0 else 1

Python (LiteRT / ai-edge-litert)

import numpy as np
from ai_edge_litert.interpreter import Interpreter

it = Interpreter(model_path="twinlite.tflite"); it.allocate_tensors()
inp, out = it.get_input_details(), it.get_output_details()
it.set_tensor(inp[0]["index"], x)           # [1,3,360,640] float32, RGB, x/255
it.invoke()
outs = sorted(out, key=lambda o: o["index"])
da = it.get_tensor(outs[0]["index"])[0].argmax(0)   # [360,640] drivable-area mask
ll = it.get_tensor(outs[1]["index"])[0].argmax(0)   # [360,640] lane mask

Conversion

Converted with litert-torch (build_twinlite.py): loads the MIT BDD100K weights, swaps ConvTranspose2d → ZeroStuffConvT2d, and exports the two-head graph.

Performance

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	270 / 270	~44 ms
TFLite benchmark_model (TfLiteGpuDelegateV2)	GPU (OpenCL)	270 / 270	127.4 ms
TFLite benchmark_model	CPU (XNNPACK, 4 threads)	—	697.5 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, AOT)

Measured on a physical Samsung Galaxy S26 (Snapdragon 8 Elite Gen 5 / SM8850, Hexagon v81) over adb, using LiteRT CompiledModel from a purpose-built harness — 5 warm-up runs then 50 timed runs, one accelerator per process.

Compute unit	Inference (median / min)	First load	Start thermal headroom
NPU (Hexagon, AOT context)	13.86 ms / 13.57 ms	121 ms	0.66
GPU (Adreno)	13.56 ms / 10.57 ms	1387 ms	0.66

Inference is a tie here — the GPU is ahead by 2%, which is inside the run-to-run spread. Where the NPU wins outright is startup: an AOT-compiled context loads in 121 ms against 1387 ms for the GPU, which builds its shaders on every launch. That is 11x, and in a sweep of 20 models from this zoo the NPU loaded faster than the GPU on every single one. Pick the NPU when cold start matters, and treat the two as equivalent for sustained throughput on this model.

The file is fp16 and needs no int8 quantization to reach the NPU — the AOT compile places all 270 operations there with no fallback.

On the measurement conditions. Thermal headroom is reported as measured, where 1.0 is the throttling threshold; the value is disclosed rather than held to a threshold. Both rows were taken at the same headroom and compare directly. Figures taken at a different headroom will differ — in our tests the same measurement moved 13.5% across a headroom change of 0.05, while device thermal status still read NONE. Each accelerator ran in its own process, because LiteRT's Environment is shared within a process and the first model load fixes the dispatch options for every later one.

License

MIT (TwinLiteNet / chequanghuy). Trained on BDD100K.