mllm 2.0.0：在手機與 Jetson 上跑多模態 LLM 的 C++ 推論引擎
Fast Multimodal LLM on Mobile Devices
秒懂
- 它是什麼？
- mllm 把 PyTorch 與 SafeTensors 權重轉成自家格式，再交給 Arm CPU、OpenCL GPU、QNN NPU 或 Ascend NPU 執行。它的價值在於行動端部署路徑完整，代價是版本切換與硬體後端耦合度高。
- 適合誰用？
- 如果你的目標是把 Qwen3 或 Qwen3-VL 這類模型放進 Android 手機或 Jetson Orin，而且願意接受 mllm 自家的模型格式與後端綁定，mllm 2.0.0 是目前少數把轉換、量化、NPU 執行串成一條線的 C++ 引擎。若你只需要在伺服器 GPU 上跑 llama.cpp 或 vLLM，或團隊無法投入人力追蹤 V1 到 V2 的 API 變動，這個專案不適合你。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 7 天前。
- 用什麼語言寫的？
- 主要是 C++（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
mllm 要解的是行動端推論的整合問題，不是模型本身的問題
在手機上跑多模態模型，麻煩的從來不是模型權重，而是權重從哪裡來、用什麼精度放進記憶體、最後由哪個硬體單元執行。這三件事分別屬於 PyTorch 生態、量化工具鏈與 NPU 廠商的編譯器，彼此之間的介面沒有標準。mllm 的定位就是補上這段：README 把它描述為連接上方最佳化演算法（投機解碼、剪枝、量化）與下方 AI 編譯器或執行環境（CANN、CUDA、MLIR）的中間層，並以 mllm-convertor 直接吃 PyTorch 與 SafeTensors checkpoint，量化轉換成 mllm 格式後交由 mllm Runtime 載入執行。
目標讀者是需要在 Arm CPU、Hexagon NPU、Ascend NPU 之間做選擇，又不想為每個後端各寫一套推論程式碼的工程團隊。專案以 C++ 撰寫，MIT 授權，同時提供 SDK 與 CLI 推論工具。如果你的部署目標是雲端 GPU 上的批次推論，這套設計的前置成本沒有對應回報。
從 checkpoint 到執行的三段流程：轉換、量化、Runtime
依 README 的 workflow 圖示，資料流是單向的：社群框架的 checkpoint 進入 mllm-convertor，經過量化與格式轉換產生 mllm 格式檔案，再由 mllm Runtime 載入。這代表模型不會以原始 PyTorch 格式在裝置上執行，中間多了一層需要維護的產物。好處是 Runtime 端只需要認識一種格式，壞處是每次上游模型結構變動，轉換器就得跟著改。
支援表把後端切成 CPU、Hexagon NPU INT8、Ascend NPU 三欄，同一份模型在不同欄位的可用性差異很大。以表中可見的項目為例，Qwen3-0.6B 在 CPU 標示為 w4a8，同時有 Ascend 的 W8A8 版本；Qwen3-1.7B 的 CPU 版本是 w4a8-i8mm-kai，Hexagon NPU 欄位指向一個 W4A16-SM8650 的 QNN AOT 模型。也就是說，能不能用某個後端，取決於有沒有人先把對應量化版本轉出來並放上模型倉庫，而不是引擎本身的能力宣告。這一點在評估時常被忽略。
Android 端不走 JNI，改用 Golang 寫的 In-App Server
README 明確指出 Android 實作已重構成裝置內的 Client-Server 架構，與傳統 JNI 整合不同：UI 與重型推論計算之間隔了一層以 Golang 撰寫的 In-App Server，打包為 mllm_server.aar。這個選擇的實際效果是把推論生命週期從 Android 應用程式的執行緒模型中抽離，UI 不會被推論阻塞，串流輸出也比較好處理。2025 年 11 月的更新提到透過這個架構在 Android 上啟用 Qwen3 與 DeepSeek-OCR 的串流。
代價是應用程式裡多了一個 Go runtime 與一個本機服務層，APK 體積與啟動流程都會受影響，除錯時也要同時看 Java 與 Go 兩側。對單純做一次推論、不需要串流的場景，這層架構帶來的複雜度高於收益。
Jetson Orin 上的量化路徑與 pymllm 的定位
pymllm 是這份材料中另一個需要分清的元件。README 說它在 Jetson Orin 上支援 Qwen3、Qwen3-VL 與 Qwen3.5 的 BF16 服務，以及 W4A16 與 W8A8 量化服務。兩條量化路徑的實作不同：W4A16 使用 AWQ compressed tensors 搭配 Marlin GEMM，W8A8 使用 Triton 的 per-token activation quantization 搭配 CUTLASS INT8 GEMM。
專案公布的數字是在 input_len=2048、output_len=128 的條件下，Qwen3-VL-2B W8A8 在 AGX Orin 32GB 上達到最高 3.12 倍 prefill 加速，prefill 吞吐約 12243 tok/s，decode 吞吐則與 llama.cpp 大致接近，依模型、裝置與量化方式互有勝負。多模態 prefill 的表格顯示 AGX Orin 32GB 上 Qwen3-VL-2B 的 FP16 為 4875.75、W4A16 為 4700.28、W8A8 為 6443.59。這些是專案自行量測的結果，測試條件寫得清楚，但沒有第三方複現紀錄。值得注意的是 W4A16 在 2B 模型上低於 FP16，量化並非單向增益。
V1 退役與 V2 的 API 斷層是採用時最大的隱形成本
2025 年 8 月的公告說 V1 支援即將結束，V1 在退役前會整合 GPT-OSS，之後轉向 V2。V2 的變動不是修補：改為更 Pythonic 的模型撰寫方式與 eager execution、加入編譯支援以便整合 NPU、支援多模型平行執行。這意味著既有以 V1 寫成的模型定義在 V2 上不能直接沿用，需要重寫。
對於已經在 V1 上出貨的團隊，這是一次實質的遷移工程，而不是升級版本號。反過來說，新專案從 2.0.0 開始就沒有這個包袱。評估時應該先確認你要用的模型定義寫在 V1 還是 V2 分支上，README 的支援表已明確標示為 mllm v2，但歷史公告與範例散落在兩個時期。
授權是 MIT，條款寬鬆，對商業整合相對友善。這不是法律意見，實際條款仍應以倉庫中的 LICENSE 檔案為準；另外要注意的是，模型權重本身來自 Qwen 等上游專案，那些權重的授權與 MIT 無關，需另外確認。
什麼情況下不該選 mllm
最明顯的排除條件是硬體不在支援清單上。README 列出的加速後端是 Arm CPU、OpenCL GPU、QNN NPU（Hexagon）與 Ascend NPU，桌面 x86 或非 Qualcomm 的行動 GPU 不在其中。若你的目標裝置是這之外的平台，mllm 的 Runtime 對你沒有用處。
第二個排除條件是團隊沒有能力維護轉換鏈。mllm 的模型可用性取決於對應量化版本是否已產生，QNN 路徑還涉及 AOT 全圖執行這類需要預先編譯的流程，README 為此另開了一份 quick start 與技術報告。這是一條需要專門人力的部署管線，不是安裝一個套件就能跑。
替代方案方面，llama.cpp 走的是另一條路：它以 GGUF 作為單一格式，把量化與執行都收在同一個生態裡，社群模型覆蓋廣，桌面與伺服器場景成熟。差別在於 llama.cpp 對 NPU 的整合不是主線，多模態與行動端 NPU 的支援深度不如 mllm 針對 QNN 與 Ascend 所做的工作。反過來說，如果你不需要 NPU，llama.cpp 的格式與工具鏈更單純，模型取得也更容易。專案自己在 Jetson 的比較中也是以 llama.cpp 為基準，這說明兩者在同一場景下確實重疊。
採用前該驗證的具體項目
先確認模型。在 README 的 v2 支援表中找到你要的模型，然後看它在你目標硬體那一欄是否有連結。表格中許多格子是空的，空白的意義是沒有現成的轉換產物，不代表引擎做不到，但代表你要自己做。
再確認轉換。mllm-convertor 是整條鏈的入口，它對 PyTorch 與 SafeTensors 的支援程度決定了你能不能用自己的 checkpoint。材料中沒有列出轉換器的完整參數與支援清單，這部分需要直接讀 examples 目錄下的範例。
最後確認執行路徑。走 QNN 的話要先讀 AOT 全圖執行的 quick start，因為那牽涉預先編譯；走 Android 的話要接受 In-App Server 架構帶來的 Go 依賴。這三項都對上之後，mllm 才是一條可用的部署路徑。
編輯結論
如果你的目標是把 Qwen3 或 Qwen3-VL 這類模型放進 Android 手機或 Jetson Orin，而且願意接受 mllm 自家的模型格式與後端綁定，mllm 2.0.0 是目前少數把轉換、量化、NPU 執行串成一條線的 C++ 引擎。若你只需要在伺服器 GPU 上跑 llama.cpp 或 vLLM，或團隊無法投入人力追蹤 V1 到 V2 的 API 變動，這個專案不適合你。動手前先確認三件事：你要的模型是否出現在 v2 支援表對應的後端欄位、QNN 路徑是否需要 AOT 全圖編譯、以及 mllm-convertor 對你手上 checkpoint 的支援程度。這三項任一落空，整條部署鏈就不成立。
社群筆記