HSEmotion-B0-LiteRT

Measured on device (edge-compat): Raspberry Pi 5 · LiteRT 2.2.0.dev20260804 · CPU/XNNPACK, 4 threads · 24.8 ms p50 (2026-08-31); browser · Chromium 151 on M4 Max · LiteRT.js 2.5.3 · WebGPU · 2.56 ms p50 · output matches CPU (2026-08-11). Record: https://github.com/john-rocky/edge-compat/blob/main/cards/hsemotion-b0/CARD.md

HSEmotion (EfficientNet-B0) — facial emotion recognition on LiteRT GPU

Recognize the 8 AffectNet emotions — anger, contempt, disgust, fear, happiness, neutral, sadness, surprise — from a cropped face, with the whole network running on the LiteRT CompiledModel GPU delegate (no CPU fallback). HSEmotion (EmotiEffLib, Apache-2.0) is an EfficientNet-B0 fine-tuned on AffectNet.

• Architecture: EfficientNet-B0 (tf_efficientnet_b0), 224×224, 8-way head.
• Weights: av-savchenko/face-emotion-recognition enet_b0_8_best_afew.pt · Apache-2.0.
• Size: 8 MB (fp16).

Detected face + emotion distribution on a Pixel 8a; the classifier runs on the GPU.

I/O

• Input: [1, 3, 224, 224] NCHW, RGB, ImageNet-normalized (a cropped face).
• Output: [1, 8] logits, index order: anger, contempt, disgust, fear, happiness, neutral, sadness, surprise.

GPU conversion

Two hurdles, both fixed in build_hsemotion.py:

1. Old-timm pickle. The released weights are a pickled model built with an old timm whose forward is broken under current timm (missing conv_s2d). The state dict is lifted into a fresh timm tf_efficientnet_b0 (num_classes=8, remapping classifier.0.* → classifier.*), which has a working forward — 358/360 tensors match by name and shape, the rest is the remapped classifier.
2. fp16 SqueezeExcite mean → NaN. ⭐The SE block's global mean x.mean((2,3)) over the 112×112 stem map is a single fp16 reduction whose partial sum overflows 65504 → the GPU delegate emits an all-NaN output (it computes the reduction in fp16 even for an fp32 graph; desktop fp16 CPU is exact). Replaced by a hierarchical mean — repeated avg_pool2d over equal-size tiling windows (≤ 49 elements each) — mathematically identical but fp16-safe.

Pixel 8a: 342/342 nodes on the GPU delegate, 1 partition, ~2 ms/inference (fp16). Device fp16 top-1 matches desktop fp32 (logits corr 0.99997); desktop fp16 CPU corr vs PyTorch is 1.0.

Minimal usage

Kotlin (Android, LiteRT CompiledModel GPU)

val model = CompiledModel.create(context.assets, "hsemotion_b0_fp16.tflite",
    CompiledModel.Options(Accelerator.GPU), null)
val inputs = model.createInputBuffers()
val outputs = model.createOutputBuffers()

inputs[0].writeFloat(faceNchw)     // [1,3,224,224] cropped face, ImageNet-normalized
model.run(inputs, outputs)
val logits = outputs[0].readFloat()   // [8] -> softmax + argmax

Python (LiteRT CompiledModel API)

import numpy as np
from ai_edge_litert.compiled_model import CompiledModel

model = CompiledModel.from_file("hsemotion_b0_fp16.tflite")
inputs = model.create_input_buffers(0)
outputs = model.create_output_buffers(0)
inputs[0].write(np.ascontiguousarray(face, np.float32))   # [1,3,224,224]
model.run_by_index(0, inputs, outputs)
logits = outputs[0].read(8, np.float32)                   # argmax -> emotion

The model expects a tightly cropped face (use any face detector; the Android sample uses the built-in android.media.FaceDetector).

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.

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.

XNNPACK declines these fp16 graphs — it reports failed to delegate DEPTHWISE_CONV_2D and then fails to allocate tensors — so there is no usable CPU number. Disabling XNNPACK falls back to reference kernels, which measured about 20× slower than the GPU on models of this size and would not represent CPU inference anyone would ship.

Snapdragon NPU (Hexagon)

The NPU is 2.02x faster than the GPU (0.823 ms against 1.67 ms) and loads 5.86x faster (108 ms against 634 ms).

Measured on a Samsung Galaxy S26 (Snapdragon 8 Elite Gen 5 / SM8850, Hexagon v81, Android 16), LiteRT CompiledModel 2.2.0, one accelerator per process, 5 warm-up runs then N=50 timed runs, median reported. Every run held thermal status NONE throughout. Headroom 0.69-0.70, where 1.0 is the throttling threshold.

The NPU rows here ran artifacts compiled ahead of time for SM8850 with QAIRT 2.47.0; the GPU rows ran the published files as they are. LiteRT can also compile for the NPU on the device at first load, which is what lets you ship the published file unchanged — that path and the ten runtime libraries it needs are in the NPU recipe, and we did not measure it here. GPU wiring is in the GPU recipe.

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).

License

Apache-2.0 (HSEmotion / EmotiEffLib). Converted with litert-torch.