MMDeployとは？v1.3.1で更新が止まった現状と動かすためのバージョン固定

MMDeployは、OpenMMLabで学習したモデルをONNXやTensorRTへ変換し、C/C++実装のInference SDKで推論まで行うためのツールチェーンです。ただし2026年9月時点で、最終リリースはv1.3.1（2023年12月25日）、mainブランチの最終コミットは2024年9月30日で止まっています。この状態のライブラリを現行のPython・PyTorchへそのまま入れると、エラーにならないまま2022年のパッケージが入ったり、SDKのランタイムだけ入らなかったりします。この記事では、PyPIの配布情報と公式リポジトリの依存条件を確認して分かったインストール時の制約と、そこから逆算した検証候補の組み合わせを整理します。

まとめ

• MMDeployの最終リリースはv1.3.1（2023-12-25）。mainへの最終コミットは2024-09-30で、アーカイブはされていないがopen issueが414件残っている（2026年9月18日時点・GitHubの検索APIで実測）。
• macOSでpip install mmdeployを実行すると、v1.3.1ではなく2022年2月公開の0.2.0が警告なしで入る。v1.3.1はmanylinux2014_x86_64とwin_amd64のホイールしか配布していないため。
• Python 3.12以降ではmmdeploy-runtimeが「from versions: none」で入らない。ホイールはcp36からcp311まで。
• 検証環境の候補は、mmdet 3.3.0が要求するmmcv<2.2.0から逆算したPython 3.10か3.11・PyTorch 2.1・CUDA 11.8または12.1・mmcv 2.1.0・NumPy 1系。cpu・cu118・cu121のいずれも、torch2.2以降のインデックスにmmcv 2.1.0のホイールは1件も無い。
• 新規案件でOpenMMLab資産を持たないなら、PyTorchのONNXエクスポートとONNX Runtime・TensorRTを直接組む方が保守面で有利。

更新が止まった位置：最終リリースv1.3.1と2024年9月の最終コミット

GitHub APIで取得したopen-mmlab/mmdeployの状態は、最終リリースがv1.3.1（2023-12-25公開）、mainブランチの最終コミットが2024-09-30（コミット3f8604bd、author日時とcommitter日時がいずれも2024-09-30T02:32:03Z）です。リポジトリはarchived: falseのままで、スター3,138、オープンなissueが414件、オープンなプルリクエストが39件あります（いずれも2026年9月18日時点）。

アーカイブされていない以上「開発中」と読みたくなりますが、1年11か月コミットが無く、issueが414件積み上がっている状態を保守中とは扱えません。判断材料になるのは上流の足並みです。主要パッケージの最新安定版の公開日は下表のとおりで、mmdeploy・mmdet・mmcvは2023年末から2024年春に集中しています。ただし安定版の間隔だけで開発停止とは断定できず、mmengineには2026年7月13日公開の0.11.0rc3というプレリリースがあります。

比較対象として、同じ用途で使われるonnxruntimeは1.30.0が2026年9月10日に公開され、PyTorchは2.14.0が2026年9月2日に公開されています。MMDeployが前提にしている世代とは2年以上の開きがあります。

pip installの結果が環境で変わる：配布状況が生む3つの落とし穴

MMDeployのインストールで時間を落とす原因は、コマンドが失敗することではなく、失敗しないまま別のものが入ることです。以下はmacOS（x86_64・Python 3.9.6）の仮想環境と、Linux向けターゲットを指定したpip downloadで、配布ホイールの取得可否と依存解決の結果を確認したものです。モデル変換やSDK推論までを通したものではありません。

macOSでの配布制約と旧版0.2.0の選択

macOS・Python 3.9.6の仮想環境でpip download mmdeploy --no-depsを実行すると、解決されるのは1.3.1ではなく0.2.0です。

$ pip download mmdeploy --no-deps -d ./dl1
Collecting mmdeploy
  Downloading mmdeploy-0.2.0-py2.py3-none-any.whl.metadata (9.0 kB)
Saved ./dl1/mmdeploy-0.2.0-py2.py3-none-any.whl
Successfully downloaded mmdeploy

0.2.0は2022年2月15日公開で、OpenMMLab 2.0系に対応する前の0.x系です。1.3.1が配布しているファイルはmmdeploy-1.3.1-py3-none-manylinux2014_x86_64.whlとmmdeploy-1.3.1-py3-none-win_amd64.whlの2つだけで、macOS向けのホイールもソース配布も無いため、pipは互換のある最も新しい版として0.2.0まで遡ります。警告は出ません。バージョンを指定せずに入れた場合、mmdeploy.apisのインポートが通らない、READMEどおりのconfigが存在しないといった症状が出ますが、原因はコードではなく入った版です。

Python 3.12以降向けSDKランタイムホイールの未配布

推論を担うmmdeploy-runtimeは、cp36からcp311までのホイールしか公開されていません。Linux向けにターゲットを固定して確認すると、Python 3.11では取得でき、3.12と3.13では候補がゼロになります。

$ pip download mmdeploy-runtime --no-deps --only-binary=:all: \
    --platform manylinux2014_x86_64 --python-version 3.11 -d ./r311
Saved ./r311/mmdeploy_runtime-1.3.1-cp311-none-manylinux2014_x86_64.whl

$ pip download mmdeploy-runtime --no-deps --only-binary=:all: \
    --platform manylinux2014_x86_64 --python-version 3.13 -d ./r313
ERROR: Could not find a version that satisfies the requirement mmdeploy-runtime (from versions: none)

紛らわしいのは、同じ条件でも本体のmmdeploy（変換ツール側）はPython 3.13でも取得できる点です。タグがpy3-noneのため、ホイールのタグだけではPython 3.13が除外されないからです。ただし取得できることは変換が動くことを意味せず、PyTorchやmmcvを含めた動作確認は別途必要です。SDKを使う前提なら、ランタイムの配布があるPython 3.10か3.11を選んでください。

protobufの上限制約とonnx 1.17.0の選択

mmdeploy 1.3.1のメタデータはonnx>=1.13.0とprotobuf<=3.20.2を同時に要求します。onnxは1.18.0以降がprotobuf>=4.25.1を要求するため、この2つを並べるとpipは新しいonnxを捨てていきます。Linux・Python 3.11をターゲットに指定した実行では、1.19.0、1.18.0と試したうえで1.17.0に着地しました。

Downloading onnx-1.19.0-cp311-...whl.metadata
Downloading onnx-1.18.0-cp311-...whl.metadata
Downloading onnx-1.17.0-cp311-...whl.metadata
Would install numpy-2.2.6 onnx-1.17.0 protobuf-3.20.2

protobuf本体は7.36.2まで出ているので、MMDeployを入れた環境は3.20.2に固定されます。gRPCや他のML系ライブラリと同居させると、ここが衝突点になります。MMDeployは専用の仮想環境かコンテナに隔離してください。ONNX形式そのものの位置づけはONNXとは？モデル変換・推論の仕組みと使い方で整理しています。

検証候補の組み合わせ：mmdet 3.3.0から逆算したバージョン固定

上限を決めているのはMMDeploy本体ではなく、変換対象のコードベース側です。mmdetection v3.3.0のmmdet/__init__.pyには次のアサーションが入っています。

mmcv_minimum_version = '2.0.0rc4'
mmcv_maximum_version = '2.2.0'
assert (mmcv_version >= digit_version(mmcv_minimum_version)
        and mmcv_version < digit_version(mmcv_maximum_version))

上限が<2.2.0で、mmcvの最新リリースがちょうど2.2.0です。つまり最新のmmcvを入れるとimportの時点で落ちるので、実質2.1.0を選ぶことになります。次にdownload.openmmlab.comのホイール配布インデックスを引くと、mmcv 2.1.0のビルド済みホイールはcpuのtorch1.11から2.1、cu116のtorch1.12と1.13、cu117のtorch1.13と2.0、cu118のtorch2.0と2.1、cu121のtorch2.1に置かれています。PyTorch 1.13やCUDA 11.7の組み合わせも選べる一方、cpu・cu118・cu121のいずれもtorch2.2以降のインデックスには2.1.0のホイールが1件もありません。ここがPyTorch側の上限になります。

CUDA 12.4以降のディレクトリが無い点は、GPU選定に直接響きます。新しい世代のNVIDIA GPUで必要になるCUDAランタイムに対しては、mmcvをソースからビルドするしかありません。ビルドできる開発者がチームにいるかどうかが、MMDeployを採用してよいかの分かれ目になります。

conda create -n mmdeploy python=3.10 -y
conda activate mmdeploy
pip install torch==2.1.0 torchvision==0.16.0 --index-url https://download.pytorch.org/whl/cu121
pip install "numpy<2"
pip install -U openmim
mim install "mmcv==2.1.0"
mim install "mmdet==3.3.0"
pip install mmdeploy==1.3.1 mmdeploy-runtime-gpu==1.3.1

NumPyの上限も必要です。torch 2.1.0とnumpy 2.0.2を同じ環境に入れてテンソルをnumpy()へ渡すと、Failed to initialize NumPy: _ARRAY_API not foundという警告のあとRuntimeError: Numpy is not availableで停止します（macOS・Python 3.9.6で確認）。torch 2.1系のホイールはNumPy 1系に対してビルドされているためで、NumPyは1系に固定してください。最終行のmmdeploy-runtime-gpuはCUDA・TensorRT向けのランタイムです。CPUのONNX Runtimeだけで推論する場合はmmdeploy-runtimeを選びます。

Model ConverterとInference SDKの分担、dump-infoオプションの必要性

MMDeployは2つの部品でできています。Model Converterが学習済みのPyTorchモデルをONNX・TensorRT・ncnn等へ変換し、Inference SDKが前処理・推論・後処理をまとめてC/C++で実行します。この2つは別物で、変換しただけではSDKからは読めません。

変換にはMMDeploy v1.3.1のリポジトリに含まれるtools/deploy.pyを使います。以下は、同リポジトリをクローンして作業ディレクトリとし、隣に配置したMMDetection v3.3.0のソースと対象モデルのチェックポイント、さらにCUDAのバージョンに合わせたTensorRTとcuDNNを導入済みである場合の例です。位置引数は4つで、デプロイconfig、モデルconfig、チェックポイント、変換時に通すテスト画像の順です。

python tools/deploy.py \
    configs/mmdet/detection/detection_tensorrt_dynamic-320x320-1344x1344.py \
    ../mmdetection/configs/yolo/yolov3_d53_8xb8-320-273e_coco.py \
    checkpoints/yolov3.pth \
    demo/resources/det.jpg \
    --work-dir work_dir/trt/yolov3 \
    --device cuda:0 \
    --dump-info

ここで重要なのが--dump-infoです。MMDeploy公式のモデル変換ドキュメントはこのオプションを「Whether to output information for SDK」と説明しており、deploy.pyの実装でもargs.dump_infoが真のときだけexport2SDKが呼ばれます。付け忘れるとバックエンドのモデルファイルは出ますが、SDKが読むメタ情報が出力されないため、Python APIやC++ APIからロードする段で失敗します。変換をやり直すことになるので、SDK利用が前提なら常に付けてください。--deviceの既定値はcpuで、TensorRTへ変換する場合はcuda:0の形式で明示する必要があります。

デプロイconfigの命名規則：dynamic-800×1344が見つからない理由

MMDeployで最初につまずくのはconfigの選択です。configs/配下にはデプロイ設定の.pyが並び、コードベース（mmdet、mmseg、mmocr、mmpose、mmrotate、mmpretrain、mmagic、mmaction、mmdet3d）ごとにタスク別のフォルダが切られています。ファイル名は「タスク＋バックエンド（＋精度）＋静的または動的＋入力形状」で構成されます。

ここで混乱しやすいのが、動的入力のときの形状の書き方がバックエンドで違う点です。mmdetのinstance-segフォルダを例にすると、instance-seg_openvino_dynamic-800x1344.pyとinstance-seg_pplnn_dynamic-800x1344.pyは存在しますが、TensorRT版にinstance-seg_tensorrt_dynamic-800x1344.pyはありません。リポジトリ全体を走査しても、TensorRTかつdynamic-800x1344という名前のファイルは0件です。

理由はconfigの中身にあります。TensorRTの動的入力は最小・最適・最大の3つの形状でプロファイルを組む必要があるため、ファイル名にも下限と上限が入ります。

# instance-seg_tensorrt_dynamic-320x320-1344x1344.py
backend_config = dict(
    common_config=dict(max_workspace_size=1 << 30),
    model_inputs=[
        dict(input_shapes=dict(input=dict(
            min_shape=[1, 3, 320, 320],
            opt_shape=[1, 3, 800, 1344],
            max_shape=[1, 3, 1344, 1344])))])

一方OpenVINO版が持つのはopt_shapesの1点だけなので、名前も1つの形状で済みます。探しているのが800×1344の動的TensorRTモデルなら、正しいファイルはinstance-seg_tensorrt_dynamic-320x320-1344x1344.pyです。opt_shapeが800×1344になっており、その形状に最適化されたエンジンが出力されます。固定形状でよければinstance-seg_tensorrt_static-800x1344.pyを使います。ファイル名でgrepして見つからないときは、綴りではなく命名規則そのものを疑ってください。

公式ベンチマークの読み方：T4のResNetでのINT8とFP16の差0.05ms

バックエンド選定で「TensorRTはONNX Runtimeの3倍速い」「INT8にすればさらに2倍」といった数字が出回りますが、MMDeploy公式のレイテンシ表はそれを裏づけていません。列はTensorRT・PPLNN・ncnn・Ascendの4つで、ONNX Runtimeのレイテンシ列自体が存在しません。

ResNet（入力224×224）をNVIDIA Tesla T4で測った公式値は、fp32が2.97ms、fp16が1.26ms、int8が1.21msです。fp32からfp16への短縮は2.4倍ある一方、int8とfp16の差は0.05msです。INT8を選ぶかどうかは、この0.05msが遅延要件に効くのか、キャリブレーションの作業量と自分の検証データでの精度変化が許容範囲かを確かめて判断します。別のGPUやモデルでは比率が変わります。

加えて測定環境そのものが古く、公式ドキュメントはUbuntu 18.04、CUDA 11.3、TensorRT 7.2.3.4、ncnn 20211208という2021年時点の構成を明記しています。現行のGPUとTensorRTでは比率が変わるため、この表は傾向の参考に留め、採用判断の前に自分の構成で測り直してください。推論基盤としての構成の選び方はモデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準にまとめています。

2026年にMMDeployを採用してよい条件と、避けるべき条件

採用の判断軸は2つです。既存のOpenMMLab資産を再利用して浮く工数と、依存関係を2024年の構成に固定したまま保守する負担、どちらが大きいかで決めます。

採用してよいのは、すでにMMDetectionやMMSegmentationで学習した重みが手元にあり、実行環境をLinux x86_64かWindowsに限定でき、Python 3.10または3.11とPyTorch 2.1で固定したまま運用できる場合です。この条件は検証の出発点になりますが、変換の成功を保証するものではありません。対象モデルとバックエンドの対応表を確認し、変換後の精度とSDK推論まで検証できた場合に、OpenMMLab独自の前処理・後処理をそのまま再利用できます。さらにDockerイメージでユーザー空間の依存関係を固定してください。ただしGPUコンテナもホストのNVIDIAドライバを共有するため、ドライバ更新時はCUDAとの互換性と推論結果を確認し直す必要があります。

避けるべきなのは次の場合です。第一に、新規にモデルを選ぶ段階でOpenMMLabの学習資産が無いとき。上流のmmdetection自体が2024年1月のv3.3.0で止まっており、新しいモデルは入ってきません。第二に、CUDA 12.4以降が必要なGPUを使うとき。mmcvのビルド済みホイールが無く、ソースビルドの保守を自分で抱えることになります。第三に、Python 3.12以降やmacOS、ARM環境が要件に含まれるとき。SDKランタイムの配布が無いため、前提から外れます。

これらに当てはまる場合は、PyTorchのONNXエクスポートでONNXを出し、ONNX RuntimeやTensorRTのAPIを直接呼ぶ構成の方が、長期的な保守コストは低くなります。前処理と後処理は自分で書くことになりますが、依存が2年前で固定されないという利点がそれを上回ります。エッジ側のハードウェアから決める場合はNVIDIA Jetsonとは？Orin・Thorの違いと選定基準、本番投入の工程設計はモデルデプロイとは？本番へ出す6工程と段階公開・切り戻しの判断基準が参考になります。

よくある質問

MMDeployのGitHubリポジトリはどこですか？

https://github.com/open-mmlab/mmdeployです。既定ブランチはmainで、公式READMEは0.x系のmasterについて今後非推奨にすると書いています（逐語では will be deprecated）。ドキュメントはmmdeploy.readthedocs.ioにあり、2026年9月時点で表示されるのはv1.3.1のものです。

mmcvはどのバージョンを入れればよいですか？

mmdet 3.3.0と組み合わせるなら2.1.0です。mmcvの最新は2.2.0ですが、mmdet 3.3.0がmmcv<2.2.0をアサートするため、2.2.0を入れるとimport時にエラーで停止します。インストールはmim install "mmcv==2.1.0"のようにopenmimを使い、PyTorch 2.1・CUDA 11.8か12.1の環境に合わせてください。PyTorch 1.13・CUDA 11.7向けなどのホイールも用意されていますが、ソースコンパイルが必要かどうかはOS・Python・PyTorch・CUDAの組み合わせごとに公式の配布インデックスで確認してください。

MMDeployでPyTorchモデルをONNXへ変換するにはどうしますか？

tools/deploy.pyにONNX Runtime向けのデプロイconfig（例：configs/mmdet/detection/detection_onnxruntime_dynamic.py）、モデルconfig、チェックポイント、テスト画像を渡します。SDKから読む予定があるなら--dump-infoを必ず付けてください。変換後のONNXはNetron等で入出力の形状を確認してから、バックエンドへ渡すと切り分けが楽になります。

Inference SDKとModel Converterの違いは何ですか？

Model Converterは変換ツールで、PyTorchモデルをONNXやTensorRTエンジンなどのバックエンド形式に書き出します。Inference SDKはC/C++実装の実行側で、画像の前処理、推論、後処理のパイプラインをまとめて持ち、Python・C++・C#・Javaから呼べます。Pythonから使う場合のパッケージ名はmmdeploy-runtimeで、変換ツール側のmmdeployとは別配布です。

MMOCRやMMSegのモデルも変換できますか？

できます。公式ドキュメントが対応コードベースとして挙げているのはMMPretrain、MMDetection、MMSegmentation、MMOCR、MMagicで、READMEにはMMPose、MMDet3D、MMRotate、MMAction2も列挙されています。configs/配下にコードベース別のフォルダがあり、そこからタスクとバックエンドに合うconfigを選びます。ただし各コードベース側のバージョン上限も併せて確認が必要で、MMDeploy 1.x系はいずれもOpenMMLab 2.0世代の1.x系・3.x系と組み合わせる前提です。

関連記事

• ONNXとは？モデル変換・推論の仕組みと使い方を初心者向けに解説
• モデルデプロイとは？本番へ出す6工程と段階公開・切り戻しの判断基準を解説【2026年版】
• モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】
• NVIDIA Jetsonとは？Orin・Thorの違いと選定基準・量産判断を実装視点で解説【2026年版】