mllm を Android に載せる前に読む、V1 と V2 の断層と QNN バックエンドの実際

mllm が埋めようとしている溝はどこにあるか

モバイルでマルチモーダルモデルを動かすとき、障害は推論カーネルそのものより前後段に散らばる。量子化やプルーニングといった最適化の成果を、CANN や CUDA、MLIR といったコンパイラ／ランタイム層へ渡す橋渡しが用意されていないと、最適化をかけても端末上では素の重みと同じ速度になる。mllm はこの橋渡しを自分の役割だと README で明言している。対象読者は、スマートフォンや Jetson のようなエッジ機器で Qwen3 系や MiniCPM5-2B を動かし、テキストだけでなく画像入力も扱いたい開発者だ。クラウド推論のコストや遅延を避けたい、あるいは通信できない環境で動かしたいという動機が前提にある。

変換、量子化、実行の3段で見るデータフロー

README のワークフロー図が示す流れは単純だ。PyTorch や SafeTensors のチェックポイントを mllm-convertor が読み、量子化して mllm 形式へ変換し、mllm Runtime がそれをロードして実行する。つまり推論時に重み形式を解釈するのではなく、事前変換を前提にした設計である。量子化の方式はバックエンドごとに分かれており、CPU 向けには w4a8 や w4a32kai といった形式のモデルが ModelScope 上で配布されている。Hexagon NPU 向けには Qwen3-1.7B の W4A16-SM8650 が QNN AOT 形式で用意され、Ascend 向けには Qwen3-0.6B の W8A8 がある。バックエンドごとに別の量子化成果物が必要になる点は、変換パイプラインを一つに統一できないという制約でもある。

Android で JNI を捨てて Go サーバを同居させた理由

Android 実装は Client-Server 構成へ作り替えられ、UI と推論計算を分離している。従来の JNI 統合と異なり、Golang で書かれた mllm_server.aar という In-App Server 層をアプリ内に持つ。README はこの設計の目的を、UI を重い推論計算から切り離すことだと説明している。2025 年 11 月の更新では、この構成で Qwen3 と DeepSeek-OCR のストリーミングを Android 上で安定動作させたと告知されている。アプリのプロセス内にサーバを立てる以上、メモリ使用量とプロセス寿命の管理はアプリ側の責務になる。ここは README が踏み込んでいない部分で、実運用では自分で確かめるしかない。

Jetson Orin の pymllm が示す数値と、その読み方

pymllm は Jetson Orin 上で Qwen3、Qwen3-VL、Qwen3.5 を BF16、W4A16、W8A8 で提供する。W4A16 は AWQ の compressed-tensors と Marlin GEMM を、W8A8 は Triton による per-token 活性量子化と CUTLASS INT8 GEMM を使うと README は述べている。input_len=2048、output_len=128 の条件で、Qwen3-VL-2B の W8A8 は AGX Orin 32GB で最大 3.12 倍の prefill 高速化、約 12243 tok/s の prefill スループットに達すると記載されている。一方 decode は llama.cpp と概ね同等で、モデル、デバイス、量子化によって小さい勝ち負けがあると正直に書かれている。マルチモーダル prefill の表では、AGX Orin 32GB の Qwen3-VL-2B が FP16 で 4875.75、W8A8 で 6443.59、Orin NX 16GB では FP16 2438.27 に対し W8A8 3200.40 という平均 TPS が並ぶ。これらの数値はあくまで README が提示した条件付きのもので、自分のモデルと入力長にそのまま当てはまる保証はない。

V1 の終了告知という避けられない制約

2025 年 8 月 28 日の告知で、V1 のサポート終了が予告されている。終了前に GPT-OSS が V1 へ取り込まれ、その後 V2 へ移行するという順序だ。V2 は Python らしい eager execution によるモデル記述、NPU 統合を容易にするコンパイル対応、複数モデルの並列実行、より整理された実装を含むとされている。これは裏返せば、V1 向けに書いたモデル定義や変換済み資産が、いずれ保守されなくなるということである。V2 は 2025 年 11 月にリリースされ、2026 年 2 月に 2.0.0 が出ている。V1 資産をそのまま使い続けたいチームにとって、この断層は採用を見送る十分な理由になる。

QNN AOT と Ascend 対応が意味するもの

2026 年 2 月 3 日、QNN バックエンドでグラフ全体を NPU 上で実行する AOT サポートが告知された。AOT である以上、モデルは端末へ配る前にコンパイル済みである必要があり、配布済みの W4A16-SM8650 のような成果物をそのまま使うか、自分でコンパイルするかの二択になる。2026 年 5 月 2 日には Ascend NPU バックエンドが追加され、ATB によるグラフ実行と Qwen3 の W8A8 推論が動くとされている。対応表を見ると、CPU は Qwen3-0.6B から Qwen3-4B まで w4a8 が揃うのに対し、Hexagon NPU の欄は Qwen3-1.7B の一行しか埋まっていない。NPU を使いたいなら、選べるモデルは CPU 経路より明確に狭い。

llama.cpp と何が違うのか

llama.cpp は GGUF 形式の重みを読み、CPU と一部 GPU を対象に推論する。量子化は k-quant 系を中心に推論時まで形式を保つ。mllm は逆に、mllm-convertor による事前変換を前提とし、その出力形式がバックエンドごとに分かれる。Jetson Orin の比較でも、mllm 側の主張は prefill の高速化に集中しており、decode は llama.cpp とほぼ同じだと README 自身が認めている。つまり mllm を選ぶ理由は decode 速度ではなく、QNN や Ascend といった NPU へ到達できる経路を持っていること、そして画像入力を含むマルチモーダル経路が用意されていることにある。NPU を使わず CPU だけで動かすなら、変換の手間を考えると llama.cpp の方が素直な選択になる。

MIT ライセンスと保守コストの見積もり

ライセンスは MIT で、商用利用を含めて制約が少ない。ただしこれは mllm 本体の話であり、変換元のモデル重みにはそれぞれ別のライセンスがかかる。Qwen3 系や MiniCPM5-2B を配布物に同梱する場合は、モデル側の条件を別途確認する必要がある。保守の観点では、V1 から V2 への移行が実質的な作り直しに近い。V2 はモデル記述の方法自体を変えるため、追従にはモデル定義の書き直しが発生する。バックエンドごとに量子化形式が異なることも、対応デバイスを増やすたびに変換と検証の作業が増えることを意味する。

編集部の結論

採用すべきなのは、Qualcomm Hexagon NPU か Ascend NPU を積んだ端末で、マルチモーダル推論を自前のアプリに組み込みたいチームだ。逆に、サーバ側 GPU で完結する構成や、既存の llama.cpp ベースのパイプラインを安定運用しているチームが今すぐ移る理由は薄い。V2 は 2025 年 11 月にリリースされ、V1 のサポート終了が告知されているため、最初に確認すべきは自分の対象モデルが V2 の対応表に載っているか、そして QNN バックエンドを使うならモデルが AOT コンパイル済みで配布されているかである。mllm-convertor で自前の PyTorch チェックポイントを変換する経路を選ぶなら、変換後の量子化形式が端末のバックエンドと一致するかを先に確かめておかないと、動かせるモデルが配布済みのものに限られる。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. UbiquitousLearning/mllm on GitHub