mlboydaisuke/SSDLite320-MobileNetV3-ExecuTorch

ssdlite320_mobilenetv3 — ExecuTorch

• Source: torchvision ssdlite320_mobilenet_v3_large COCO_V1
• License: BSD-3-Clause
• Input: [[1, 3, 320, 320]] — RGB 0-1, 320x320 (torchvision SSDLite norm baked in model)
• Output: 12 raw heads: (cls [1,A91,H,W], box [1,A4,H,W]) x 6 levels, H=W in {20,10,5,3,2,1}

Variants

All variants take and return fp32 tensors — swap the .pte file, keep your app code.

build	file	size (MB)	parity vs fp32 eager (worst corr)	Mac median (ms)*
fp32	ssdlite320_mobilenetv3_xnnpack_fp32.pte	13.8	1.000000	5.1
Core ML (fp16, iOS)	ssdlite320_mobilenetv3_coreml_all.pte	7.5	0.999658	0.9

The Core ML build is the same graph lowered to Apple's Neural Engine instead of XNNPACK, which is CPU-only. Measured on an iPhone 17 Pro across seven models, it runs 3.5x to 13.9x faster (median 12x) at roughly half the file size — for example Depth-Anything-V2-Small at 500.8 ms against 42.7 ms, and MODNet at 81.7 ms against 5.9 ms. It computes in fp16 and is iOS-only; the XNNPACK files stay the portable option and are what runs on Android.

*Mac arm64, single process, median of 10 — a reference point for relative cost only, not a device number (torch eager fp32 on the same machine: 115.3 ms).

Checked in the task's own units

The graph stops at the raw heads, so the numbers that decide have to be taken after the anchor decode and NMS this card tells callers to run — using torchvision's own anchor_generator and postprocess_detections, not a hand-rolled substitute.

An earlier version of this section counted "firing detections", 26,988 of 27,004 across 10 images. Those were raw anchors above a floor, not objects: 27,004 of them for ten photographs that contain perhaps twenty things. Counting anchors measures the background agreeing with itself.

Measured properly — 71 detections over 32 photographs of people and animals, held out from the street images the int8 build was calibrated on, at a score threshold of 0.30:

build	added	dropped	relabelled	worst matched IoU	worst score shift
fp32	0	0	0	1.000	0.0000
Core ML	1	0	0	0.984	0.0732

Core ML's single disagreement sits within its own score error of the threshold — a detection the cut is ambivalent about, which a photograph shifted by a pixel moves in eager too. Every object it keeps is in the same place: worst matched IoU 0.984.

Withdrawn: int8 (2026-08-27)

ssdlite320_mobilenetv3_xnnpack_int8.pte was published and has been withdrawn. Measured the same way it adds 19 detections, drops 5 and relabels 1 — 25 changes to a 71-detection answer, better than a third of it — and the boxes it does keep fall to IoU 0.673. Its worst score shift is 0.4132, larger than the 0.30 threshold itself.

Its correlation was already the warning: 0.968820, the lowest on this shelf's detection models, and it shipped anyway because the number that was supposed to catch it counted anchors instead of objects.

At 3.9 MB against fp32's 13.8 it was much the smallest build. The Core ML build is 7.5 MB and, on this host, the fastest of the three.

Builds that did not earn a slot

• fp16 is not shipped: it comes out at 100% of the fp32 file (13.8 MB vs 13.8 MB), so it buys nothing. XNNPACK serializes convolution weights as fp32 no matter what dtype the graph carries, so on a conv-heavy model fp16 saves no disk and only adds cast operations. Quantization, not fp16, is the reduction that can shrink a graph like this.

Verification (executorch 1.4.0, torch 2.13.0)

Parity is measured against the fp32 eager model on real image input; corr is the correlation over all elements of each output tensor.

output	shape	max_abs_diff	corr
0	[1, 546, 20, 20]	3.052e-05	1.000000
1	[1, 24, 20, 20]	3.767e-05	1.000000
2	[1, 546, 10, 10]	2.956e-05	1.000000
3	[1, 24, 10, 10]	8.464e-06	1.000000
4	[1, 546, 5, 5]	1.717e-05	1.000000
5	[1, 24, 5, 5]	9.477e-06	1.000000
6	[1, 546, 3, 3]	1.717e-05	1.000000
7	[1, 24, 3, 3]	9.421e-06	1.000000
8	[1, 546, 2, 2]	2.050e-05	1.000000
9	[1, 24, 2, 2]	3.457e-06	1.000000
10	[1, 546, 1, 1]	1.001e-05	1.000000
11	[1, 24, 1, 1]	9.418e-06	1.000000

XNNPACK delegate coverage (fp32): 94.8% (289/305 ops); ops left on the portable kernels: dim_order_ops._to_dim_order_copy.default x16

Conversion

torch.export -> to_edge_transform_and_lower(partitioner) -> .pte (conversion scripts: executorch-models)