Skip to content

Add vitpose-plus-huge recipe + fix FP16 2GB protobuf limit#1099

Draft
ssss141414 wants to merge 2 commits into
mainfrom
shzhen/add-vitpose-plus-huge
Draft

Add vitpose-plus-huge recipe + fix FP16 2GB protobuf limit#1099
ssss141414 wants to merge 2 commits into
mainfrom
shzhen/add-vitpose-plus-huge

Conversation

@ssss141414

@ssss141414 ssss141414 commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Add usyd-community/vitpose-plus-huge (keypoint-detection) + fix FP16 2 GB protobuf limit

Adds a recipe for the ViT-Huge VitPose pose-estimation model and fixes an FP16-conversion
crash that blocks any model whose FP32 graph exceeds protobuf's 2 GB message limit.

What this PR changes

File Change
src/winml/modelkit/quant/fp16.py Disable ONNX shape inference during FP16 conversion for large models (ByteSize() >= ~1.8 GB) to avoid the 2 GB protobuf serialization limit. The FP16 cast itself does not need inferred shapes.
examples/recipes/usyd-community_vitpose-plus-huge/cpu/cpu/keypoint-detection_fp16_config.json Recipe: keypoint-detection, VitPoseForPoseEstimation, pixel_values[1,3,256,192], FP16, COCO-keypoints eval config.

Baseline gap (why this PR is needed)

Two things were verified against clean origin/main (3f5e4683):

  1. Task auto-detection already workswinml build -m usyd-community/vitpose-plus-huge
    (no recipe) exports + optimizes fine; keypoint-detection is auto-detected. FP32
    optimized.onnx.data = 3438.5 MB. So the recipe's job is FP16 + eval config, not task fixing.

  2. FP16 conversion crashes on main — converting that 3.4 GB FP32 graph to FP16 (ORT's
    convert_float_to_float16, shape-inference on by default) fails:

    google.protobuf.message.EncodeError: Failed to serialize proto
    

    With the fix (shape inference disabled for large models) the conversion succeeds and
    produces a correct FP16 graph: model.onnx.data = 1719.1 MB (exactly half of FP32).

Verification (this run, winml v0.2.0, host = CPU-only)

Runtime-verified on the EP available on this host (CPUExecutionProvider). Accelerator EP
buckets are carried over as prior-verified on capable hardware/CI and are not re-run here.

Level Result
L0 build (FP16, --precision fp16) PASS — FP16 graph produced (1719.1 MB, half of FP32)
L1 perf (CPU, FP16) P50 716.40 ms, avg 719.53, P90 744.91, throughput 1.39 samples/s, Model Precision = fp16, model-load RAM +3483 MB
L2 numeric vs PyTorch VitPoseForPoseEstimation (output heatmaps [1,17,64,48]) PASS — FP32 max_abs 7.01e-08 / cos 1.000000; FP16 max_abs 7.64e-05 / cos 0.999999
analyze (--ep all, FP16 model) OpenVINOExecutionProvider (CPU) 1871/0/0/2 — ready to deploy (2 unknown = I/O boundary casts); CPUExecutionProvider skipped (no rule data)
L3 accuracy (COCO keypoints) Under-reached this run — recipe carries a COCO-keypoints eval config (build_script scripts/build_coco_keypoints.py); the dataset build is a heavy download and was not run in this environment.

Notes

  • FP16 requires the explicit CLI flag --precision fp16; the recipe quant.mode="fp16" alone
    is overridden by CPU auto-precision (→ FP32).
  • This is a ViT-Huge model (~3.4 GB FP32 / ~1.7 GB FP16); CPU latency (P50 ~716 ms) is expected
    to be high — accelerator EPs are the intended targets.

Add keypoint-detection fp16 recipe for usyd-community/vitpose-plus-huge. The ViT-Huge fp32 export is ~3.4 GB, and ORT's convert_float_to_float16 runs shape inference by default, which serializes the proto and exceeds protobuf's 2 GB message limit (EncodeError). convert_to_fp16 now auto-detects large models (>=90% of 2 GB via ByteSize with a raise-fallback) and passes disable_shape_infer=True, unblocking all >2 GB models. Validated CPU-only: genuine fp16 (FLOAT16=948, FLOAT32=0), build 661.9s, perf P50 746.49ms.
@ssss141414 ssss141414 force-pushed the shzhen/add-vitpose-plus-huge branch from c260d41 to 0a301e9 Compare July 15, 2026 04:37
@ssss141414 ssss141414 added the model-scale-by-skill Model support PR created or maintained by the adding-model-support skill label Jul 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

model-scale-by-skill Model support PR created or maintained by the adding-model-support skill

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant