| --- |
| license: apache-2.0 |
| tags: |
| - executorch |
| - xnnpack |
| - pte |
| - on-device |
| - keypoint-detection |
| - pose-estimation |
| --- |
| # RTMW-m (whole-body pose, 133 keypoints) — ExecuTorch |
|
|
| `rtmw_m_xnnpack_fp32.pte` (129.1 MB) |
|
|
| - **Source**: [mmpose](https://github.com/open-mmlab/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](https://huggingface.co/mlboydaisuke/YOLOX-s-ExecuTorch). |
|
|
| ## 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: |
|
|
| | build | mean apart | over 2 px | over 10 px | worst | |
| |---|---|---|---|---| |
| | **XNNPACK fp32** | **0.001 px** | 0 | 0 | 0.5 px | |
| | XNNPACK fp16 | 0.414 px | 4 | 2 | 123 px | |
| | Core ML | 1.199 px | 54 | 4 | 124.5 px | |
|
|
| 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 |
| |
| ```bash |
| 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](https://github.com/john-rocky/executorch-models)) |
|
|
