---

name: conversion description: "Convert OpenMMLab/PyTorch models with MMDeploy, including IR export, deploy.py workflows, ONNX partitioning, calibration, quantization, and work-dir artifact interpretation." disable-model-invocation: true metadata: disco-role: operating license: Apache 2.0

MMDeploy conversion sub-skill

Use this sub-skill when a user needs to convert an OpenMMLab/PyTorch model with MMDeploy: selecting the deploy config, model config, checkpoint, sample input, work directory, target device, IR type, partition policy, calibration source, quantization mode, and interpreting generated artifacts.

Route by task

• For an end-to-end CLI conversion, start with references/workflows.md and the bundled scripts/deploy.py.
• For direct Python API calls, signatures, and backend/PyTorch visualization routing, use references/api-reference.md.
• For deploy config authoring or diagnosing shape/precision/codebase fields, use references/configuration.md.
• For failed conversions, missing marks, calibration issues, backend handoff errors, or CLI/API misuse, use references/troubleshooting.md.

Owned responsibilities

• Choose and validate deploy_cfg, model_cfg, checkpoint, input image/data, --work-dir, --device, --test-img, and SDK metadata dump options.
• Run the deployment pipeline that exports ONNX or TorchScript IR, partitions ONNX by marks, creates calibration HDF5 data, converts IR files to backend files, and renders comparison outputs when possible.
• Explain --dump-info, --show, --quant, --quant-image-dir, and --calib-dataset-cfg behavior.
• Explain work-dir artifacts such as end2end.onnx, TorchScript files, backend engine files, partitioned ONNX files, calib_data.h5, deploy.json, pipeline.json, detail.json, output_<backend>.jpg, and output_pytorch.jpg.

Boundaries and handoffs

• Backend installation, custom backend build steps, shared-library/plugin setup, and hardware readiness belong to the backend guidance, not this sub-skill. This sub-skill identifies the backend requirement and the failing handoff point.
• SDK runtime inference and packaged demo usage belong to SDK guidance. This sub-skill only explains how --dump-info writes SDK metadata during conversion.
• Rewriter implementation belongs to extensibility guidance. This sub-skill covers only partition marks, partition_config, and extract_model inputs/outputs.
• Validation, benchmarking, regression suites, and accuracy evaluation belong to validation guidance after conversion artifacts exist.

Operating guardrails

1. Require explicit user-supplied paths for the deployment config, upstream model config, checkpoint, representative conversion input, and work directory.
2. Confirm that the target OpenMMLab codebase is importable before blaming MMDeploy conversion logic.
3. Match device to backend: TensorRT needs a CUDA device such as cuda:0; OpenVINO is CPU-oriented; other backends have their own device/runtime requirements.
4. Use a fresh work directory for each conversion attempt to avoid stale IR/backend files being mistaken for current outputs.
5. Do not treat a successful IR export as proof that backend conversion or SDK runtime is usable; inspect backend files and hand off backend/runtime failures to the appropriate sub-skill.