RTMW-m-WholeBody-ExecuTorch

RTMW-m (whole-body pose, 133 keypoints) — ExecuTorch

rtmw_m_xnnpack_fp32.pte (129.1 MB)

• Source: mmpose RTMW, rtmw-dw-l-m_simcc-cocktail14_270e-256x192 (the m-size distilled build)
• License: Apache-2.0
• Input: [1, 3, 256, 192], a crop around one person, ImageNet-normalised
• Output: two SimCC maps, [1, 133, 384] and [1, 133, 512] — the x and y bins for each keypoint at a split ratio of 2.0

Body, feet, face and both hands in one pass. The shelf's four RTMPose variants each cover one of those; this covers all of them, which is the whole reason to carry a model this size next to a 21.9 MB body-only one.

Top-down: it expects a box around a person, not a scene. Pair it with a detector — the shelf has YOLOX-s.

Verification (Mac arm64, 2026-08-23)

XNNPACK fp32: 17.0 ms against 178.9 ms eager, worst corr 1.000000, 129.1 MB.

Correlation is measured on random input, so the check that matters here is decoded coordinates on real person crops — 133 keypoints across five crops, 665 measurements, against eager on the same tensor:

fp32 is exact on four of the five crops; the one difference is half a pixel, which is a single SimCC bin.

A worst of 123 px on a 192-wide crop looks alarming and is worth reading with the count beside it: for fp16 that is 4 of 665 keypoints, and those four had the lowest peak activations in eager's own output (median summed peak 0.39). SimCC picks a bin by argmax, so a keypoint the model is unsure about flips to a distant bin under any numeric change. Core ML moves 54 of 665, which is a different matter.

Not shipped, and why

• fp16: 127.9 MB against 129.1, and 54.2 ms against 17.0 — three times slower for no size gain. The keypoint agreement above is good; there is simply nothing to buy.
• Core ML: worst corr 0.920, below the 0.995 gate, and 54 of 665 keypoints move.
• int8: does not export. PT2E quantization fails with ValueError: getitem_6 is not an aten adaptive_avg_pool2d operator — the quantizer's pattern match against CSPNeXt's channel attention, reached through the PAFPN's tuple output. The RTMPose variants on this shelf have no int8 either, though those failed on quality rather than at export.

Conversion

CONVERT_REPOS=<dir containing mmpose> python convert/export_rtmw.py fp32
CONVERT_REPOS=<dir containing mmpose> python convert/check_rtmw.py

RTMW is not another entry in export_rtmpose.py's variant table: RTMPose feeds the backbone's last stage straight to the head, RTMW puts a CSPNeXtPAFPN neck in between and uses RTMWHead. The widths and sizes are read off mmpose's own rtmw-m_8xb1024-270e_cocktail14-256x192.py, and a strict load_state_dict is what proves they match the checkpoint. mmpose needs mmengine and mmcv-lite; xtcocotools, mmdet and mmcv._ext are imported at module scope and never called on this path, so they are stubbed.

Feed it contiguous tensors. ExecuTorch reads a tensor in memory order rather than by its strides, and a crop built with np.transpose is not contiguous. Random input is, which is why the correlation gate cannot see the difference.

(conversion scripts: executorch-models)