LFM3は小さなAIで何を変える？畳み込みと注意機構を組み合わせる設計｜2026年10月28日版
Liquid AIが10月27日に公開したLFM3は、文章、画像、音声を扱うAIを、用途に合わせて端末へ組み込むためのモデル群だ。中心となるのは、短い範囲の処理と広い文脈の参照を分担させる設計。すべての層で同じ計算を繰り返さず、小型モデルで業務に必要な処理を担わせる。
注目したいのは、会話モデルだけでなく、問い合わせの振り分けなどに使う判断モデルも同じ基盤から用意した点だ。「文章を書く」「見て答える」「分類する」を、必要なモデルに分けて実装する方向が見える。以下は日本時間2026年10月28日時点で確認できた公式資料に基づく。
- 基盤は、畳み込み・局所的な注意機構・全体を見る注意機構の3種類を組み合わせる。
- 画像や音声を扱うモデルもあるが、入力上限や実行条件はモデルごとに異なる。
- 分類や抽出には、文章を順番に生成しない専用の判断モデルを選べる。
LFM3の核心は、近くを見る計算と遠くを見る計算の分担
LFM3の基盤は、3種類の処理を混ぜた「tri-hybrid」構成だ。
公式発表によると、24層の内訳は次の通り。短い範囲を扱う層を多く配置し、全体を参照する層を絞っている。
- 13層の短い畳み込み：近接する要素を処理する。
- 5層のスライディングウィンドウ注意機構：256トークンの範囲を参照する。
- 6層のグローバル注意機構：広い文脈の関係を扱う。
文章では、直前の語句が重要な場面もあれば、離れた箇所の指示を参照する場面もある。この構成は、その距離に応じた処理を組み合わせるものだ。さらに、注意機構の出力を調節するゲートなどを加えている。Liquid AIの技術解説
ここから読み取れるのは、小型化をパラメータ削減だけで進めていないことだ。どの層に、どの範囲を見せるか。その配分も端末向けAIの設計対象になっている。
テキスト版の「約1GB」と長文入力は分けて考える
テキスト版LFM3-1.7Bは、約17億パラメータのモデルだ。公式モデルカードは、4ビット精度で約1GBと説明し、日本語を含む16言語を掲載している。入力と出力を合わせたコンテキスト上限は256Kトークンだ。
ただし、モデルの小ささと、長文処理時の実メモリ量は別の確認項目になる。アプリへ組み込む際には、会話履歴や実行環境も含めて測定したい。
用途にも線引きがある。公式はツール呼び出しや構造化出力を想定する一方、複雑な多段階推論やエージェントによるコーディングには推奨していない。LFM3-1.7Bモデルカード
日本の開発現場で試すなら、まずは入力と期待する出力を絞った処理が候補になる。たとえば、社内文書から所定の項目を取り出す処理だ。自由度の高い作業を丸ごと任せる前に、項目の欠落や形式違反を数えられる単位へ切り分けると評価しやすい。
Omni版は画像と音声を一緒に受け取る
LFM3-Omni-2Bは、画像、動画、音声、テキストを入力し、テキストや音声で返すモデルだ。構造としては、画像用・音声用のエンコーダーが入力を処理し、共通の言語モデルへ接続する。出力側には音声へ変換する仕組みも持つ。
写真について声で質問する、といった入出力を一つのモデルで扱える。ただし、テキスト版の仕様をそのまま当てはめてはいけない。
- 総パラメータ数は約21.7億。
- コンテキスト上限は入力・出力合計32Kトークン。
- 動画は毎秒2フレームでサンプリングする。
- テキストと音声の対応言語には日本語が含まれる。
これらはOmni版のモデルカードに記載された条件だ。
毎秒2フレームという仕様は、動画を使うアプリでは特に重要になる。短時間の動きを扱うなら、必要な瞬間が入力へ残るかを確かめる必要がある。日本語対応についても、現場の用語や雑音を含む音声で実用精度を確認する工程は残る。
分類だけなら、文章を生成しないd1という選択肢
同じモデル群のd1-2Bは、会話とは異なる仕事を担う。
テキスト、画像、動画と、名前を付けた複数の質問を渡すと、1回の順伝播で型付きの回答と確率を返す。回答文をトークンごとに生成する方式ではない。分類に加え、文書からの値の抽出や画像内の位置特定にも対応する。d1-2Bモデルカード
たとえば問い合わせ処理なら、「返金の依頼か」「配送担当へ回すべきか」を同じ入力から判定する設計が考えられる。後続システムが必要とするのが分類結果なら、自然文の回答を生成してから読み解く工程を減らせる。
一方、出力の確率は、そのまま業務上の正しさの保証にはならない。自社データで誤判定を調べ、人へ戻す基準を決める必要がある。公式資料も、入力が約64Kトークンを超えると回答の信頼性が下がると説明している。
導入判断では、モデル名より処理の単位を決める
LFM3の実務上の意味は、用途に応じて小型モデルを選ぶ余地が広がることにある。導入側では、まず次の3点を決めたい。
- 何を返すか：説明文、音声、分類結果のどれが必要か。
- どの入力で測るか：日本語の実文書、実際の画像、雑音を含む録音などを用意する。
- 失敗をどう扱うか：判断を保留する条件と、人へ引き継ぐ経路を設ける。
画像も音声も扱えるモデルがあっても、すべての処理にそれを使う必要はない。問い合わせの振り分け、文書の項目抽出、音声での案内では、必要な出力も検証方法も変わる。
継続ウォッチ
次に確かめたいのは、実機と業務データを使った結果だ。
- 日本語の専門用語や表記揺れで、抽出・分類の精度がどう変わるか。
- 長い入力や画像・音声を加えた際、待ち時間とメモリ使用量がどこまで増えるか。
- d1の確率を使って、人による確認件数と誤判定をどの程度両立できるか。
最初の検証では、一つの処理に絞り、成功率と待ち時間、最大メモリ量を同時に記録する。その数字が、端末へ載せるか、別の実行環境へ回すかを決める材料になる。