【geek-terminalニュース】3B級オンデバイス画面理解VLM「LFM2.5-VL-3B」の最新情報

【事象の全貌と背景】

今回の主役は、Liquid AIが公開した軽量視覚言語モデル「LFM2.5-VL-3B」です。公式情報では、LFM2.5ファミリーのマルチモーダル派生モデルであり、テキストと画像の両方を処理できる3.1B規模のVLMとして位置づけられています。ポイントは、単なる画像説明モデルではなく、画面/UI理解、文書/OCR、チャート読解、自然言語クエリに基づくグラウンディング、複数画像入力をまたぐ推論、そしてテキストのみ・画像テキスト混在状況での関数呼び出しまでを統合していることです。

これがギークに刺さる理由は明確です。ここ数年のGUI自動化やComputer Use系エージェントは、スクリーンショットを巨大クラウドVLMへ投げ、画面内のボタンやフォームを読ませ、座標を返させ、ブラウザやOS操作へ接続する流れで進化してきました。しかし、この方式はレイテンシ、APIコスト、プライバシー、オフライン耐性、社内端末への導入制約というボトルネックを抱えます。そこへ3B級で画面を読み、座標を返し、ツール呼び出しの判断まで担えるモデルが来ると、GUI自動化の知覚部分をローカル側へ剥がせる可能性が出てきます。クラウドの巨大モデルに毎フレーム視覚入力を投げるのではなく、端末上の小型VLMが画面状態を読む。これは地味に見えて、エージェント実装のアーキテクチャを変える話です。

【技術的ディープダイブ】

公式モデルカードによると、LFM2.5-VL-3BはLFM2.5-2.6B言語モデルをバックボーンにし、SigLIP2 NaFlexビジョンエンコーダを組み合わせています。公式ブログでは、SigLIP2 400M NaFlexビジョンエンコーダとLFM2.5-2.6Bテキストモデルと同じ事前学習済みバックボーンを利用し、約34Tトークンで事前学習され、従来より4倍多いビジョンデータを使ったと説明されています。ビジョンデータには、キュレーション済みおよび合成の画像キャプション、OCR、グラウンディング、指示追従データセットが含まれます。

画面理解VLMとして重要なのは、出力が「画像に何が写っているか」だけで終わらない点です。公式情報では、異なるデバイス上のデジタル画面の理解、自然言語クエリに基づくグラウンディングと物体検出、複数画像推論、関数呼び出し能力が主要改善点として挙げられています。さらにモデルカードではOCRのレイアウト注釈形式も説明されており、各領域をラベル、バウンディングボックス、内容で表す設計になっています。つまり、単なる文字起こしではなく、画面や文書内の領域構造を含めて返せるモデルです。

配布形態も重要です。公式モデルカードでは、ネイティブ形式のLFM2.5-VL-3Bに加え、CPU推論と低メモリ利用向けのGGUF量子化版、クラウド・エッジ・モバイルでハードウェアアクセラレーション推論を可能にするONNX量子化版が示されています。ONNX版ではTransformers.js v4.0以降を使い、WebGPU上でブラウザ実行できる利用例も示されています。Developers Digestは、M5 Max上で約3GBメモリ、228 tokens/sでデコード、ScreenSpot-v2平均80.7、ToolSandbox 59.5と報じています。ただしこの数値は公式裏付けとして提示された情報ではなく、外部記事ベースの報告として扱うべきです。

【コミュニティの生々しい熱量と議論】

Redditでは、r/artificialに「LiquidAI LFM2.5-VL-3B: a 3.1B local VLM that beats…」という趣旨の投稿が立ち、ローカルVLMとして既存モデルを上回るという観点で話題化しています。ただし、今回渡された検索結果2には、Reddit、Hacker News、lobste.rs、LessWrongの実際のコメント本文や個別発言の引用は含まれていません。そのため、ここで具体的なユーザー発言、賛否の比率、実測報告、過激なハック例を事実として捏造することはできません。

それでも、コミュニティが反応しやすい論点はかなりはっきりしています。第一に、3B級で画面理解とグラウンディングが動くなら、ローカルGUIエージェントの部品として使えるのか、という期待です。たとえばブラウザ操作、RPA、アクセシビリティ補助、社内業務アプリの自動入力、ゲームUI解析、デスクトップ操作ログの構造化などで、画面をクラウドに送らず端末内で解釈できる価値は大きい。第二に、ベンチマークが良くても実UIでどこまで安定するのか、という疑念です。UIは小さい文字、ポップアップ、スクロール、重なったモーダル、無限に似たアイコン、ローカライズ文字列、ダークモードなど、ベンチマークより厄介な入力が多い。第三に、座標グラウンディングと関数呼び出しを同じ小型モデルに任せる場合、クリックミスや危険操作をどうガードするのかという安全設計の問題があります。

つまり、熱量の中心は「小さいのに賢い」ではなく、「これでスクリーンショット常時クラウド送信をやめられるのか」です。公式にはオンデバイス配備向けの小型VLMとして、画面理解、文書理解、グラウンディング、ツール呼び出しを統合していることが確認できます。一方で、実運用での失敗率、長時間エージェントループでの安定性、日本語UIや業務アプリへの適応、クリック前確認の設計については、現時点で提供情報だけから断定できません。

【今後の展望とエコシステムへの影響】

LFM2.5-VL-3Bが示している方向性は、GUI自動化の「目」をローカル部品化する流れです。これまでComputer Use系の実装では、巨大VLMがスクリーンショットを理解し、次の操作を推論し、座標やアクションを返す構成が多く採られてきました。しかし、小型VLMが端末内で画面構造、OCR、座標、オブジェクト候補を高速に返せるなら、クラウドLLMは高レベルな計画や複雑な判断だけに集中できます。画面認識はローカル、長期計画はクラウド、危険操作はポリシーエンジン、実行はOSレベルのアクションランナー、という分業が現実味を帯びます。

オワコン化しそうなのは、単純なスクリーンショット送信型の重いGUI解析パイプラインです。すべてを巨大モデルAPIに丸投げする方式は、コストとレイテンシとプライバシーの面で不利になりやすい。逆に伸びるのは、GGUFやONNX、WebGPU、Transformers.jsのようなローカル推論経路、そして画面座標とツール呼び出しを安全に接続するミドルウェアです。LFM2.5-VL-3BのONNX版がブラウザ実行例を持つことは、Webアプリ内でVLMを直接走らせる未来にもつながります。

もちろん、3B級モデルだけで完全自律エージェントが完成するわけではありません。公式にも小型モデルは用途を絞ったファインチューニングで性能を最大化する方向が示されており、安全上重要な意思決定には慎重さが必要です。それでも、画面理解、OCR、グラウンディング、ツール呼び出しが同じ小型VLMに収束してきた意味は大きい。これは単なる新モデル紹介ではなく、ローカルLLM勢がついに「文字を読む」だけでなく「画面を見て操作の足場を作る」段階へ進んだニュースです。