はじめに
ロボットのように、カメラで周りを見ながら動くAI（いわゆるPhysical AI）が増えてきました。こうした機器に「いま何が写っているか」を判断させるには、画像を扱えるVLM（Vision Language Model）が使えます。
ただ、クラウドのVLMをAPIで呼ぶ構成だと、以下のような課題があります。
- レイテンシー：画像を送信して結果を受け取るまでに時間がかかり、ネットワークの状態によっても変動する
- トークンコスト：画像は多くの入力トークンを消費するため、カメラ映像を継続的に処理すると利用料金が積み上がる
- 通信への依存：ネットワークが不安定な現場や、オフライン環境では使えない
- プライバシー：カメラ映像を外部のサーバーに送信する必要がある
それなら小さなVLMをデバイスの上で動かせばいいのでは、ということで、Liquid AIのLFM2.5-VLをRaspberry Pi 5のCPUだけで動かし、画像をどこまで理解できるか、どのくらいの速さで動くかを測ってみました。比較のため、Qwen3-VLも同じ環境で動かしています。
この記事の内容は次のとおりです。
- LFM2.5-VLとは何か
- Raspberry Pi 5で実行する方法
- 450M / 1.6B / 3Bの性能比較
- Qwen3-VLとの速度・メモリ・回答品質の比較
LFM2.5-VLとは？
LFM（Liquid Foundation Models） はLiquid AIが開発している基盤モデルのシリーズで、デバイス上で動かすことを前提に、モデルサイズと実行効率を重視して作られています。
製品に組み込む場合、メモリが少ない、GPUがない、消費電力を抑えたい、といった制約がつきものです。そういう環境では、精度だけでなく、速度やメモリ使用量、消費電力も含めてモデルを選ぶ必要があります。
LFM2.5-VLは、このLFM2.5シリーズのうち画像も入力できるVLMです。今回は450M・1.6B・3Bの3サイズを試しました。
実行環境：Raspberry Pi 5
| 項目 | 構成 |
|---|---|
| デバイス | Raspberry Pi 5 |
| RAM | 8GB |
| 推論 | ARM CPU |
| 冷却 | 外付けファン |
| 推論エンジン | llama.cpp |
| モデル形式 | GGUF |
| 量子化 | Q4_K_M（モデル本体） |
AIアクセラレータは使っていません。普通のRaspberry Pi 5のCPUでどこまで動くかを見ていきます。
llama.cppを使う理由
llama.cpp はC/C++で書かれた軽量なLLM推論エンジンで、ARM CPUでも動きます。VLMにも対応していて、今回はモデル本体のGGUFとmmprojの2ファイルを読み込ませて使います。
記事中に出てくる用語をまとめておきます。
| 用語 | 説明 |
|---|---|
| GGUF | モデルの重みやメタデータを格納する形式 |
| Q4_K_M | モデルをおおむね4bitに量子化する方式 |
| mmproj | 画像エンコーダと、画像の特徴を言語モデルの入力に変換するプロジェクタをまとめたファイル |
| llama-mtmd-cli | 画像とテキストを入力できるCLI |
| llama-server | API経由で推論を実行できるサーバー |
実際に動かしてみる
1. llama.cppをビルド
必要なパッケージを入れます。
sudo apt update
sudo apt install -y \
git cmake build-essential libcurl4-openssl-dev
llama.cppを取ってきてビルドします。今回使うのは llama-server と llama-mtmd-cli だけなので、この2つだけをビルドしています。
mkdir -p ~/lfm && cd ~/lfm
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j4 \
--target llama-server llama-mtmd-cli
2. LFM2.5-VLをダウンロード
まずは一番小さい450Mから試します。
mkdir -p ~/lfm/models
cd ~/lfm/models
B=https://huggingface.co/LiquidAI/LFM2.5-VL-450M-GGUF/resolve/main
curl -fL -O \
$B/LFM2.5-VL-450M-Q4_K_M.gguf
curl -fL -O \
$B/mmproj-LFM2.5-VL-450m-F16.gguf
モデル本体はQ4_K_M、mmprojはF16です。1.6Bと3Bも Liquid AIのHugging Face から取得できます。
3. 画像を読み込ませる
COCOデータセットの猫の画像を使います。
画像をダウンロードして、
mkdir -p ~/lfm/images
cd ~/lfm
curl -fL \
-o images/coco_cats.jpg \
http://images.cocodataset.org/val2017/000000039769.jpg
VLMを実行します。
./llama.cpp/build/bin/llama-mtmd-cli \
-m models/LFM2.5-VL-450M-Q4_K_M.gguf \
--mmproj models/mmproj-LFM2.5-VL-450m-F16.gguf \
--image images/coco_cats.jpg \
-p "Describe this image in detail." \
-t 4 -n 128 --temp 0
450Mという小さなモデルでも、2匹の猫に加えて毛布やリモコンまで拾って説明してくれました。ラベルを1つ返すだけの画像分類と違い、写っているものや状況を文章で説明してくれるのがVLMのいいところです。
ただ、写っているものが分かることと、細かい文字まで読めることは別の話です。そこで、モデルのサイズを変えて比べてみました。
LFM2.5-VLの性能を比較してみた
450M・1.6B・3Bの3モデルを比較しました。llama-server を立てて、/v1/chat/completions に画像付きのリクエストを送って測っています。条件は次のとおりです。
| 項目 | 設定 |
|---|---|
| 画像 | 猫（640×480）、新聞（640×488） |
| プロンプト | Describe this image in detail. |
| 最大出力 | 128 tokens |
| temperature | 0 |
| 測定 | 各設定3回の中央値 |
TTFT（Time To First Token）はリクエストを送ってから最初のトークンが返ってくるまでの時間、tokens/sは回答の生成速度です。
結果：450Mが圧倒的に軽い
| モデル | mmproj | TTFT | tokens/s | モデル読込 | 最大メモリ |
|---|---|---|---|---|---|
| VL-450M Q4_K_M | F16 | 3.5 秒 | 40.1 | 5.6 秒 | 801 MB |
| VL-450M Q4_K_M | Q8_0 | 3.5 秒 | 43.8 | 3.0 秒 | 716 MB |
| VL-1.6B Q4_K_M | F16 | 13.7 秒 | 15.0 | 18.5 秒 | 2,408 MB |
| VL-1.6B Q4_K_M | Q8_0 | 14.3 秒 | 13.6 | 8.6 秒 | 2,150 MB |
| VL-3B Q4_K_M | Q8_0 | 17.9 秒 | 6.6 | 12.2 秒 | 4,014 MB |
450MはGPUなしでも40 tokens/s前後出ていて、メモリも800MB程度に収まりました。1.6Bと3Bはそのぶん遅く、メモリも多く使いますが、次に見るように細かい部分の理解では差が出ます。
画像の理解力にはどれくらい差がある？
速さだけでは使えるかどうか分からないので、新聞画像に書かれた日付を読めるかも試しました。
正しい日付は「Monday, July 21, 1969」です。
| モデル | 回答した日付 | 判定 |
|---|---|---|
| LFM 450M | July 28, 1967 | 誤り |
| LFM 1.6B | Monday, July 21, 1969 | 正しい |
| LFM 3B | Monday, July 21, 1969 | 正しい |
450Mは画像全体の説明はできるものの、日付は読み間違えました。細かい文字になると、1.6B以上との差がはっきり出ます。
猫の画像の説明にも違いがありました。
- 450M：猫の姿勢やリモコンに触れる
- 1.6B：簡潔な1文で説明
- 3B：猫の毛色の違いまで詳しく説明
同じ Describe this image in detail. でも、説明の量はモデルによってかなり違います。1.6Bより450Mのほうが細かく説明していたので、大きいモデルほど詳しく答えるとは限らないようです。
もっとも、画像2枚とプロンプト1つで試しただけなので、OCRの精度や画像理解力について一般的なことは言えません。
Qwen3-VLとも比較してみた
LFMだけを測っても、それが速いのか遅いのか判断がつかないので、よく使われているQwen3-VLの2Bと4Bでも同じように測りました。モデル本体はQ4_K_M、mmprojはQ8_0に揃えています（LFMもmmprojをQ8_0にして測り直したので、前の表とは数値が少し違います）。
入力トークン数はLFMが約252、Qwenが約316と違いますし、パラメータ数も揃っていません。モデルのアーキテクチャを公平に比べたものではなく、「Raspberry Pi 5で実際に動かしたらこうだった」という比較として見てください。
推論速度とメモリ
| モデル | TTFT | tokens/s | 読込 | 最大メモリ |
|---|---|---|---|---|
| LFM 450M | 3.5秒 | 43.8 | 3.0秒 | 716MB |
| LFM 1.6B | 14.3秒 | 13.6 | 8.6秒 | 2,150MB |
| Qwen3-VL 2B | 17.2秒 | 8.7 | 12.7秒 | 3,335MB |
| LFM 3B | 17.9秒 | 6.6 | 12.2秒 | 4,014MB |
| Qwen3-VL 4B | 26.0秒 | 4.1 | 50.2秒 | 5,911MB |
LFM 450MとQwen3-VL 2Bを比べると、TTFTは約4.9倍速く、生成速度は約5.0倍、最大メモリは約79%少ない結果でした。
とはいえ、450Mと2Bではパラメータ数が4倍以上違うので、これだけでLFMのアーキテクチャのほうが優れているとは言えませんが、それでも限られたハードウェアで画像を扱いたいなら、450Mクラスのモデルも十分候補になると思います。
回答品質も比較
新聞の日付を読めたかどうかの結果です。
| モデル | 結果 |
|---|---|
| LFM 450M | 誤り |
| LFM 1.6B | 正しい |
| LFM 3B | 正しい |
| Qwen3-VL 2B | 誤り |
| Qwen3-VL 4B | 正しい |
日付を正しく読めたのは、LFM 1.6B・3BとQwen3-VL 4Bでした。画像全体の説明では、Qwen3-VLの2B・4Bが比較的長めの説明を返し、猫の毛色の違いにも触れていました。
小さいモデルは速くて軽い代わりに、細かい理解が必要なタスクでは大きいモデルに分がある、という分かりやすいトレードオフです。エッジでモデルを選ぶときは、どこで折り合いをつけるかがポイントになりそうです。
Raspberry Piで動かすなら冷却にも注意
もう一つ気をつけたいのが発熱です。ヒートシンクだけで動かしてみたところ、450Mを1回動かしただけでCPU温度が89°Cまで上がり、クロックが2.4GHzから約2.1GHzに落ちてしまいました。
外付けファンを付けて、450Mで5分間・60回の連続推論を回した結果が次のグラフです。
| 項目 | 結果 |
|---|---|
| 連続実行 | 5分間・60回 |
| 最高温度 | 74.9°C |
| CPUクロック | 2.4GHz維持 |
| 推論速度 | 目立った低下なし |
ファンを付ければ、今回の条件ではクロックも速度も落ちませんでした。スマートカメラのように常に動かす用途なら、単発のベンチマークだけでなく、連続で動かしたときの温度や速度も確認しておいたほうがよさそうです。
まとめ
Raspberry Pi 5のCPUだけでLFM2.5-VLを動かし、Qwen3-VLとも比べてみました。
- 450Mでも、猫2匹や毛布、リモコンなど、画像に写っている複数のものを説明できた
- GPUなしで約40 tokens/s出た
- 新聞の日付のような細かい文字は、1.6B以上でないと読めなかった
すべてのタスクに一番大きいモデルを使う必要はなく、必要な精度と動かす環境に合わせて選べばいい、というのが今回の感想です。デバイスの上で処理できれば、カメラ映像をクラウドに送るときのレイテンシーやトークンコストを気にしなくて済みます。
今回はCPUだけで動かしましたが、NPUなどのアクセラレータを使った場合にどうなるかも見ていきたいと思います。LFM2.5-VLはHugging Faceで公開されているので、興味があれば試してみてください。