MediaPipe Pose Landmarker Models: Lite vs Full vs Heavy

If you have already decided on MediaPipe over the alternatives — that decision lives at MediaPipe vs MoveNet, and the wider field at pose estimation models compared — one choice remains: which of the three model files to load. pose_landmarker_lite, pose_landmarker_full, and pose_landmarker_heavy share one output format and one API surface, so this is a swappable, low-regret decision. What differs is the size-speed-accuracy trade, and that is the whole of this page.

Where the .task files come from, and what the URL means#

The three variants are distributed as .task bundles from Google's public mediapipe-models storage bucket. These are the official download URLs — they appear verbatim in Google's own sample code (the download_models.sh script in the google-ai-edge/mediapipe-samples repository):

https://storage.googleapis.com/mediapipe-models/pose_landmarker/pose_landmarker_lite/float16/latest/pose_landmarker_lite.task
https://storage.googleapis.com/mediapipe-models/pose_landmarker/pose_landmarker_full/float16/latest/pose_landmarker_full.task
https://storage.googleapis.com/mediapipe-models/pose_landmarker/pose_landmarker_heavy/float16/latest/pose_landmarker_heavy.task

Reading the path as a pattern — pose_landmarker/<variant>/<precision>/<version>/<variant>.task — three segments matter:

• The variant segment (pose_landmarker_lite / _full / _heavy) picks the model. It appears twice: as a directory and as the filename.
• float16 names the numeric precision of the bundled weights — half-precision. It is the build Google's own sample scripts download; we have not verified whether other precision builds are published, so check the current MediaPipe docs before assuming one exists.
• /latest/ occupies the version slot. It is a pointer, not a frozen artifact. When we checked all three URLs on 2026-08-02, they returned HTTP 200 and the served files carried Last-Modified dates from late April 2023 — so latest has been stable for years, but nothing guarantees it stays that way. In our judgement you should download once, pin the file, and serve it from your own storage rather than hotlinking latest from a production app: a silent model swap under a fixed URL is exactly the kind of change that shifts landmark behavior without a code change on your side.

One naming note that trips people up: the .task format belongs to the current MediaPipe Tasks API. The older "MediaPipe Pose" solution was superseded on May 10, 2023, per MediaPipe's own docs — which is why pre-2023 tutorials never mention .task files. If a guide you are following loads models a different way, it is teaching the legacy API.

Bundle size is not model size#

Google's model card lists the models at 3 MB (lite), 6 MB (full), and 26 MB (heavy). The .task files you actually download are larger — roughly 5.5, 9.0, and 29.2 MiB as served when we checked. The pipeline MediaPipe describes is a two-step detector-plus-landmarker design, so the bundle packages more than the landmark model alone; we have not verified the exact bundle contents. For download-size budgeting, use the served .task figures, not the card's numbers.

What actually differs: lite vs full vs heavy#

The authoritative positioning is Google's own BlazePose GHUM 3D model card (dated April 16, 2021), which frames the family as "Optimized for on-device, real-time fitness applications" and publishes per-variant speeds on a Pixel 3: lite at roughly 44 FPS on CPU (XNNPack) and 49 FPS on GPU, full at roughly 18 and 40 FPS, heavy at roughly 4 and 19 FPS. The same card reports accuracy as PDJ (equivalent to PCK@0.2) averaged across its geographical evaluation sets: 87.0% for lite, 91.8% for full, 94.2% for heavy.

MediaPipe's legacy docs add a fitness-specific quality table (17 COCO keypoints, single person 2–4 m from the camera): on yoga footage, PCK@0.2 of 96.4 for heavy, 95.5 for full, 90.2 for lite; on HIIT, 97.5 / 95.7 / 93.5. Their latency table for Pixel 3 with TFLite GPU puts lite at 20 ms, full at 25 ms, heavy at 53 ms.

Two things to take from those numbers, and one thing not to. Take the ordering — heavy is consistently more accurate, lite is consistently faster, and the gap between full and heavy in accuracy is smaller than the gap in cost. Take the shape of the trade — lite-to-full buys a meaningful accuracy jump at a tolerable speed cost, while full-to-heavy buys a smaller jump at a steep one. Do not take the absolute figures as predictions for your app: they were measured on a 2021-era Pixel 3 under Google's own conditions. Run your candidate variants through your own harness — see test pose detection accuracy — on your lowest-end target device before committing.

What every variant shares#

The variant changes none of the following, which is why swapping is cheap:

• 33 landmarks — the 17 COCO keypoints plus additional face, hand, and foot points (eye inner/center/outer, ears, mouth corners, knuckles, heels, foot index). Every variant outputs the same topology.
• Per-landmark values of x, y, z plus visibility and presence scores. The model card is explicit that z "is not metric but up to scale" — treat depth as an estimated, lower-confidence axis.
• Two coordinate spaces: normalized image-space landmarks, and world landmarks in meters with the origin at the midpoint between the hips.
• An optional segmentation mask with per-pixel values from 0.0 to 1.0.
• Single-person tracking. The model card states it "Tracks only one person on scene if multiple present", and lists multiple people, subjects further than about 14 feet / 4 meters, and a hidden head as out of scope. Whether the current Tasks API adds a multi-pose option is not something we have verified — check the live docs, and if multi-person is a hard requirement, start from pose estimation models compared instead of this family.
• Apache-2.0 licensing, for both the MediaPipe framework and the BlazePose GHUM models per the model card — no copyleft or non-commercial strings on any variant.

Because the output contract is identical, the variant is effectively a configuration value: the same landmark indices, the same downstream angle math, the same smoothing. What changes when you swap is timing — a slower model shifts your frame budget, so re-test frame dropping and filter tuning after a swap even though the code compiles unchanged.

Which variant for which job#

Our recommendation pattern, hedged the way it deserves:

• Live rep counting — start with lite. Rep detection rides on landmark trajectories, which survive moderate accuracy loss, and the model card's own positioning puts lite as the only variant near real-time on a modest CPU. Move up to full only if your accuracy testing shows lite missing the joints your counter depends on.
• Form feedback and joint angles — start with full. Angle work punishes landmark error harder than rep counting does, and full's accuracy sits much closer to heavy than to lite in both the model card and the fitness quality table. Reserve heavy for cases that tolerate its cost: post-session analysis of recorded video, or devices you have verified can carry it live.
• Multi-person scenes — none of the three; this family is single-person by design. See the model comparison linked above for options.
• Unsure — ship full behind a config flag and A/B lite on your low-end device tier. The swap costs you a file, not a rewrite.

All of this is positioning, not measurement. The only speed and accuracy numbers that matter are the ones from your camera, your exercises, and your worst supported phone.

Before you ship#

Pin the model file instead of hotlinking /latest/, budget downloads against the served bundle sizes rather than the card's model sizes, and verify your chosen variant on real hardware. When you are ready to wire the model into a live camera feed, the camera pose tracking guide covers the pipeline, and AI workout tracking on the web walks through the browser path specifically — this page's job was only the choice.