- Llama.cpp が libmtmd を通じてマルチモーダル入力（ビジョンを含む）に対応
- llama-mtmd-cli または llama-server を通じた OpenAI 互換の
/chat/completions API
- Gemma 3、SmolVLM、Pixtral、Qwen 2/2.5、Mistral Small、InternVL などの モデル でマルチモーダル機能をすぐに利用可能
- 事前量子化済みモデルを提供（大半は QK_K_M 量子化を標準で含む）
- マルチモーダルプロジェクタはデフォルトで GPU にオフロードされ、必要に応じて無効化設定も可能
- 一部のモデルでは 大きなコンテキストウィンドウ（例: -c 8192）が必要
概要
- Llama.cpp は libmtmd を用いて新たにマルチモーダル入力機能をサポート
- ユーザーは画像などのテキスト以外の入力も処理できるようになり、ビジョンモデル の活用範囲が広がる
- この機能はすでに Gemma 3、SmolVLM、Pixtral、Qwen 2 VL、Qwen 2.5 VL、Mistral Small、InternVL など主要モデルと互換性がある
マルチモーダル入力の有効化方法
- 主な実行方法は 2 つ案内されている。1 つ目は -hf オプションの利用（対応モデルが必要）、2 つ目は -m と --mmproj オプションを組み合わせて、テキストモデルとマルチモーダルプロジェクタモデルをそれぞれ指定する方法
- -hf オプション を使う場合、マルチモーダル機能を無効にしたいときは --no-mmproj を追加し、カスタムの mmproj ファイル を使う場合は --mmproj local_file.gguf オプションを使う
- GPU オフロード がデフォルトで、これを望まない場合は --no-mmproj-offload オプションで無効化できる
コマンド例
- コマンドラインでは llama-mtmd-cli、サーバーでは llama-server を利用する形
- ローカルファイルを使う場合は --mmproj で直接ファイルを指定する
- GPU オフロードを無効化するには --no-mmproj-offload オプションを追加して使う
すぐに使えるマルチモーダルモデル一覧
- Q4_K_M 量子化を基本とする、さまざまな準備済みモデルが案内されている
- 対応モデル例:
- Gemma 3: 4b、12b、27b バージョン
- SmolVLM 系列: 256M、500M、2.2B など
- Pixtral 12B
- Qwen 2 VL: 2B、7B、および Qwen 2.5 VL: 3B、7B、32B、72B
- Mistral Small 3.1 24B（IQ2_M 量子化）
- InternVL 2.5 および 3 世代: さまざまなパラメータサイズに対応
参考事項
- 利用時は (tool_name) の箇所に、使いたい実行バイナリ名を入力する（例: llama-mtmd-cli または llama-server）
- 一部のマルチモーダルモデルでは 大きなコンテキストウィンドウサイズ の指定が必要になる場合がある（例: -c 8192 のようなオプションを利用）
1件のコメント
Hacker News の意見
MBP M1 64GB で ggml-org/gemma-3-4b-it-GGUF を使い、プロンプト処理速度は 25t/s、トークン生成速度は 63t/s ほど出た。
画像全体の処理時間は、画像サイズに関係なく約 15 秒。
小さな 4B モデルでも、すでにかなり良い出力を見せており、さまざまな画像をうまく説明する。
再現方法は、llama.cpp をクローンしてビルドし、モデルと mmproj ファイルをダウンロードしてサーバーを起動し、その後 Web インターフェースに接続すること。
-hfオプションなしで使う場合は、マルチモーダル対応エラーを避けるために--mmprojスイッチを必ず付ける必要がある。公式の ggml-org/gemma-3-4b-it-GGUF quant を使っている。
danielhanchen が提供する unsloth quant のほうが速いと期待している。
どの画像に対しても同じ答えが出る。
「この画像にはさまざまなポーズの複数の人物が写っており…」といった感じ。
実際の画像にはまったくそんな内容がないので、どこからデバッグすべきか見当もつかない。
自分も同じ結果がずっと出ている。
M1 で 7b モデルを使うなら、プロンプト処理はほぼ 10 倍速いはずだという投稿を見た。
もしかしてエンコーダーが最適化されていないのではと思っている。
実際にプロンプトで生成したサンプル画像があるなら見せてもらえる？
試す前に一度見てみたい。
その数値は 4/8 ビット quant 基準なのか、それとも完全な fp16 基準なのか気になる。
llama.cpp はソースから直接コンパイルする必要がある。
llama-mtmd-cliプログラムを入手できる。自分は vision 対応の quant を作ってある。
unsloth/gemma-3-4b-it-GGUF:Q4_K_XLなどのコマンドで実行できる。チャット中に
/image image.pngで画像をアップロードして会話できる。今では Metal バックエンドでは
-ngl -1を使わなくてもよい。CUDA ではまだ必要。
-1はすべての GPU レイヤーを GPU にオフロードする意味。参考になれば、ドキュメントの unsloth.ai ページを更新したので、すぐに
llama-mtmd-cliの使い方を確認してほしい。Mistral Small にも使える。
Homebrew で llama.cpp をインストールすると、
llama-mtmd-cliも含まれている。コマンドを実行するだけですぐ使える。
実際には
-ngl 99のほうが安定していて、-ngl -1は動くかどうかが環境次第なことがある。ngl という文字を見るだけで腹が立ってくる気がする。
これまで見つけた中でいちばん有用なドキュメント。
どう動くのか理解するのにとても役立った。
https://github.com/ggml-org/llama.cpp/…
huggingface/tokenizersのように、テキスト Transformer のツール群が分離されているのと似ている。SmolVLM シリーズもサポートしている。
小さなサイズのおかげで応答が非常に速い。
リアルタイムの家庭用ビデオ監視システムに最適。
これで趣味プロジェクトとして試してみるつもり。
簡単なコマンド例も具体的に残してくれている。
サーバーに mtmd 機能を追加してくれてありがとう。
自分もコミットを待ちながらずっと追っていた。
git のコミットノートを見るたびに貢献内容が見えて、いつも感心している。
llama.cpp 全体でも本当にお疲れさま。
ただ、これだけ高速な応答だと品質がどうなのか気になる。
2.2B より小さいモデルでも、文脈のある文章をきちんと出せるの？
Gemma3 4b を使って、最近の旅行写真の多くにキーワードと説明を生成するのに使った。
基本的な OCR もできるので、文字入りの写真を要約してくれるし、文脈の手がかりからどこで撮ったかもうまく推測してくれる。
自前ホストできるものとしては素晴らしい。
面白そう。
画像リストをループしてそれぞれにプロンプトを実行し、結果をメタデータや sqlite などに保存する構成で使っているのか気になる。
gemma 4b がこういう作業に十分実用的なのか気になる。
自分はもっと大きいバージョンしか使ったことがなく、4b では足りないと思っていた。
一般ユーザー目線で何が変わったのか気になる。
数か月前にも llama.cpp で画像説明などはできたはずだが、何が変わったのだろう。
llama.cpp はさまざまなプラットフォーム向けにコンパイル済みリリースを提供している。
今回はそこに vision 機能が新たに入った。
macOS では
llama-b5332-bin-macos-arm64.zipをダウンロードして展開し、sudo xattrコマンドで実行を許可した後、llama-mtmd-cliでターミナルインターフェースを使える。あるいは
localhost:8080の Web サーバーを起動することもできる（UI、API を含む）。詳しい利用記録は個人ブログにまとめてある。
brew でインストールする場合は
--HEADオプションで常に最新状態からビルドできる。数時間以内に brew パッケージ版も更新されるはずなので、簡単にアップグレードできるだろう。
convert_hf_to_gguf.py --mmprojのおかげで、どんな vision モデルでも quant 作成がずっと簡単になった。llama-serverで vision がサポートされるのはとても素晴らしい。ずっと待っていた機能だ。
これで
-nglは自動的に最大値が設定されるようになった。自分で
-ngl 99を指定する必要はない。ただし Metal 環境だけの話で、CUDA などでは依然として明示する必要がある。
gemma3 のマルチモーダルモデルを ollama 経由で使うのと比べて、llama.cpp を使うのはどうなのか気になる。
Apple Silicon Mac での利点や使用感があれば知りたい。
1 つ目は、llama.cpp のサポートは ggml エコシステム内で横断的に統合されているため、ollama より高速に動くよう最適化しやすいこと。
たとえば pixtral/mistral small 3.1 では、Ollama より少ないメモリで動く 2D-RoPE の工夫がある。
近いうちに flash attention も追加される予定で、そうなれば vision エンコーダーはより高速かつ少ないメモリで動作するようになる。
2 つ目は、llama.cpp のほうが ollama より対応モデルが多いこと。
ollama は pixtral も smolvlm もサポートしていない。
UI 開発に vision を組み込むツールがあるのか気になる。
例として、フロントエンドの TS/React 趣味プロジェクトで、ローカル/クラウド LLM を VSCode につないで使っているが、vision 対応モデルでも結局スクリーンショットを撮って貼り付ける必要がある。
この部分全体を自動化したり、キーボードショートカットでスクリーンショットを撮って自動でチャットに貼り付けるだけのシンプルな拡張でもあれば、かなり時間を節約できそう。
ngl という略語は本当に紛らわしい。
Mac でできるだけ速く動かすためにいろいろなコツや調整が出てくるのが面白い。
こうした速度改善で、より多くの人が自宅で vision 機能を試すようになるのだろうか。
llama.cpp は、10 年物の自分の PC と M1 Mac の両方でとてもよく動いている。