タイトルカードには「LFM3の紹介」、サブタイトルには「6つの2Bモデル、1つのバックボーン」、3つのチップには「256Kコンテキスト」「6チェックポイント」「4ビットで1 GB」と表示されている。
Guides & Insights

LFM3の紹介:6つの2Bモデル、1つのバックボーン、そしてコンテキストではない256トークンのウィンドウ

著者

Rowan Sterling

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

Liquid AIのLFM3ファミリーは、2026年10月27日、単一のフラッグシップモデルではなく、6つの2Bクラスのチェックポイントとして登場した。テキスト向けのLFM3-1.7B、視覚向けのLFM3-VL-2B、音声向けのLFM3-Audio-2B、あらゆる入力を同時に扱うLFM3-Omni-2B、そして2つの意思決定モデルd1-2Bとd1-omni-2Bである。6つすべては、Liquidが同時に公開した単一の事前学習済みバックボーンLFM3-1.7B-Baseから派生している。同社が掲げる枠組みは「特化型知能」であり、小型の汎用モデルを出荷して誤った軸で競争することを意図的に拒否する姿勢の表れだ。

発表から1日も経たないうちに、技術文書にあったある数値がすでに誤読されていた。LFM3のアーキテクチャには、256トークンのウィンドウを持つスライディングウィンドウアテンション層が記載されている。これは各層のアテンションの形状であり、モデルのコンテキスト長ではない。テキストモデルは256Kトークンのコンテキストを扱う。層の表をざっと読み、Liquidが256トークンのメモリを持つ2026年のモデルをリリースしたと結論づけた読者は、頭の中に誤ったモデル像を抱いている。この記事のほかのどの内容も理解できるようになる前に、まずそれを訂正しておく価値がある。

トライハイブリッドアーキテクチャとは実際何なのか

LFM3は、LFM2の双方向ミックスを、24層の本体に積み重ねた3種類の層で置き換える。13層はゲート付き短畳み込み、5層は256トークン窓のスライディングウィンドウアテンション、6層は完全なグローバルアテンションである。畳み込みカーネルは3から7に広がる。さらに3つの小さな変更が伴う。各アテンションヘッドの出力を独立にスケーリングするシグモイドゲート、グローバル層において各ヘッドの最高周波数側の半分のみを回転させる部分回転埋め込み、そして各ブロックの入力と出力の両方を条件付けるサンドイッチ正規化である。

狙いは、短い畳み込みが局所構造の大半を低コストで担い、スパースアテンションが中距離を処理し、ごく一部のグローバルアテンションが256Kウィンドウ全体をつなぎ合わせるという点にある。だからこそKVキャッシュは実用上意味のあるレベルまで小さく抑えられる——Liquidによると、128Kトークン分のフルキャッシュは1.6GBで、同じ測定条件ではQwen3.5-4Bが4.3GB、MiniCPM5-2Bが5.6GBだ。テキストモデル自体は4ビット精度で約1GBに収まる。

トレーニングは4段階で実施された。22兆トークンの事前トレーニング、エージェントのトレースとツール呼び出しを多く含み、コンテキストを256Kまで拡張した3.5兆トークンの中間トレーニング段階、1.75兆トークンでの教師ありファインチューニング、そして6名の専門家教師からのマルチドメインのオンポリシー蒸留と組み合わせた混合強化学習である。語彙は128Kトークンで、LFM2.5-8B-A1Bと共有され、前身より非ラテン文字を効率的にトークン化できるよう構築されている。

6つのモデルと、それぞれのコンテキストの行き先

Liquidは、これらが階層ではなく兄弟関係にあると明言している。それぞれが同じバックボーンを採用し、異なる出力形状に向けてポストトレーニングされている。

Screenshot of Liquid AI's blog post 'Introducing LFM3: Every Modality for Specialized Intelligence', dated OCT 27, 2026, showing its opening paragraphs: that LFM3 brings text, vision, audio, omni and decision models onto one shared backbone, that the first release covers the 2B parameter range, that it was built on a new hybrid architecture and 22T tokens of pre-training, and that the base and post-trained models are open-weight on Hugging Face, the Liquid Playground and the Liquid AI API.

• LFM3-1.7B — 高密度テキストおよびエージェントモデル、1.73Bパラメータ、256Kコンテキスト、ネイティブなツール呼び出しと構造化出力。

• LFM3-VL-2B — 視覚言語モデル、19億パラメータ、LiquidがSigLIP2の計算量の約3分の1で済むと述べる独自の視覚エンコーダを搭載。

• LFM3-Audio-2B — 独自のエンコーダーとLiquidCodecを使用した、ASR、TTS、音声翻訳、音声理解。

• LFM3-Omni-2B — Liquid初のオムニモデル:テキスト、画像、動画、音声を入力として受け取り、テキストまたは音声を出力します。

• d1-2B — 視覚ブランチから構築された意思決定モデルで、自由形式の文章ではなく、較正された確率を用いて構造化された質問に単一のフォワードパスで答えます。

• d1-omni-2B — omniブランチ上の同じ意思決定インターフェースです。

コンテキストウィンドウは一律ではなく、これは多くのローンチ報道が落とした詳細だ。Liquidがウィンドウを公開しているのはテキストモデルとベースモデル——256K、入力と出力を合算——だけで、他の4つについてはいずれも公開していない。発表もモデルドキュメントも、LFM3-VL-2B、LFM3-Audio-2B、LFM3-Omni-2B、および2つの決定モデルのいずれについてもコンテキスト長を明記していない。サードパーティの記事はビジョンモデルについて128K、オムニモデルについて32Kを流布しており、これらの数字は正しい可能性が高いが、10月28日時点でLiquid自身のページには載っていない。長い文書を読み、さらにスクリーンショットも見るエージェントを計画しているなら、現時点ではオムニモデルのコンテキストをファーストパーティのドキュメントからまったく見積もることができない。これは、どこかから得た情報で補ったブログから埋めるのではなく、指摘する価値のある欠落だ。

Screenshot of the Hugging Face model card for LiquidAI/LFM3-1.7B showing 1.73B parameters, 24 layers made of 13 gated short convolutions, 5 sliding-window attention and 6 global attention, 256K token context, a 128,000-token vocabulary, 16 listed languages, the LFM Open License v1.0, about 1 GB of memory at 4-bit precision, 6,311 downloads in the last month, and the card's own note that the model is not recommended for agentic coding or complex multi-step reasoning due to its small size.

ベンチマーク表を、正直に読み解く

以下に示す性能数値はすべてLiquid自身によるもので、Liquid自身のハーネス上で計測されたものであり、第三者による再現は一切行われていません。2026年10月28日時点で、Artificial AnalysisにLFM3の項目は存在しません。Intelligence Indexもなく、中立的な第三者による速度やレイテンシの測定もありません。この点が通常以上に重要となるのは、今回のローンチが依拠している比較が同一ハーネス内での比較であり、そのハーネスがチューニングの対象としたモデルに有利に働くからです。

LFM3-1.7BはLiquidの27ベンチマーク平均で49.37を記録する。同社自身のLFM2.5-2.6Bは同じセットで31.55を記録しており、「パラメータが35%少ない」という主張はここから来ている。興味深い行は平均ではない:

• ツール使用 — BFCL V4 71.39、ToolSandbox 80.36、τ³-bench 68.01、MCP-Atlas 32.57。

• エージェント型ウェブ — WebArena-Verified 38.42、AutomationBench 41.29、BrowseComp-Plus 37.00、LiveClaw 45.60。

• エージェント型コーディング — SWE-bench Verified 43.40、SWE-bench Multilingual 23.00、Terminal-Bench 2.1 は 12.92。

• 指示追従 — IFEval 96.66、IFStruct 93.72、IFBench 73.03、Multi-IF 89.10。

• 知識 — GPQA Diamond 63.37、HLE はツールなしで 7.17、ツールありで 13.90。

• ロングコンテキスト — RULER 128K 65.56、AA-LCR 52.83。

全体の合計ではなく形として読めば、このプロファイルは一貫している。指示遵守は非常に強力で、単一ターンのツール呼び出しもまずまずだが、多数の連続ステップを要するタスクでは急激に落ち込む。Terminal-Bench 2.1 の {{1}}12.92{{/1}} と SWE-bench Multilingual の {{2}}23.00{{/2}} は、自律型コーディングエージェントを構築する土台となる数字ではない。Liquid はこれを隠していない — モデルカードはユーザーを複雑な推論や多段階コーディングから遠ざける方向に導いており、これはローンチ日にベンダーが出す位置づけとしては異例に直接的だ。

効率性に関する主張は、この売り込みのもう半分だ。Q4_0および32Kコンテキストでは、Liquidによると、LFM3-1.7Bは3台のテストデバイスすべてで最速のモデルであり、次点の候補より1.8~2.8倍高速で、しかもメモリフットプリントは最小だった。単一のNVIDIA B300上で、SGLangをBF16で用いた場合、同時リクエスト1,024件で1日あたり36億トークンを処理した。同社はまた、負荷試験のデモンストレーションとして、Enronのメールアーカイブ上で30万を超えるLFM3-1.7Bエージェントを並列実行した。これらはベンダーによる数値であり、監査を受けていないが、静かに水増しするのは難しい種類の数値だ。

Single-column scoreboard for LFM3-1.7B with six rows: parameters 1.73B dense, context 256K tokens, BFCL V4 71.39, SWE-bench Verified 43.40, AA Intelligence Index none yet, and licence LFM Open v1.0. The footer reads 'All figures vendor-reported by Liquid AI; no independent evaluation as of 28 Oct 2026.'

ライセンスと運用にかかる費用

モデルの重みはHugging Face上でBF16、FP8、NVFP4、GGUF、MLX、ONNXの各ビルドとして公開されており、vLLM、SGLang、Transformers、llama.cpp、MLX、ONNX Runtime、Ollama、LM Studioで初日からサポートされています。ライセンスはLFM Open License v1.0で、年間収益1,000万ドル未満ならロイヤルティフリーの商用利用が可能ですが、それを超える場合は別途契約が必要です。LFM3がある企業にとって無料かどうかを決めるのは、パラメータ数ではなく、この閾値です。

Liquidはホスト型APIも提供しているが、そこでの公開情報はローンチ時の印象より乏しい。ドキュメントにはモデルIDと入力+出力合計256Kの上限が記載されているが、料金表はない。第三者による報道では、LFM3-1.7Bのホスト型料金は入力100万トークンあたり約0.08ドル、出力100万トークンあたり約0.20ドルで、vision、audio、omni、decisionの各バリアントはより高価とされている。Liquidはこれらの数値を自社ページで公開していないため、確認済みではなく報道ベースの情報として扱うべきだ。これに対しセルフホスティングにはトークン単価が一切なく、コストはマシンそのものであり、4ビットならそのマシンはスマートフォンでもよい。

OrcaRouterが適している場面 — 適していない場面

LFM3はOrcaRouterのカタログにはなく、そうでないふりをするつもりもありません。これは自分で実行するか、Liquid自身のAPIを通じて呼び出すオープンウェイトのソフトウェアです。このルーターが役立つのは、その周辺のレイヤーです。1.7Bの専門モデルがパイプライン内で唯一のモデルであることはほとんどなく、ツール呼び出し、分類、抽出を担当し、判断を要するターンはより大きなモデルが担当します。OrcaRouterはそれらのホスト型モデルを0%のマークアップで1つのキーの背後に配置します — プロバイダーの定価がそのまま渡されます — そのため、LFM3からフロンティアモデルへのエスカレーション経路は、第二の契約ではなくルーティングルールになります。自動フェイルオーバーが最も重要なのは、まさにLFM3が対象とするワークロードです。そこでは単一の小型モデルが、リクエストとエラーの間に立つ唯一の存在だからです。

ルーティングDSLの方がより興味深い適合です。スペシャリストとジェネラリストを1回の呼び出しで組み合わせる——LFM3的なタスクは小型モデルにルーティングし、それ以外はすべてホスト型モデルに流す——これはまさにこのファミリーが想定して作られたデプロイパターンです。Liquidの主張の核心は、2Bモデルが狭いタスクにおいてフロンティアモデルを桁違いの低コストで上回るという点にあります。ルーターは、パイプライン全体をそれに賭けることなく、その節約を実現する方法です。

何を観るべきか

未解決の問いは、LFM3が主張どおりに優れているかどうかではない。Liquidが作成していないハーネスでもその主張が生き残るかどうかだ。このファミリーのエージェント性能の数値をまず再検証すべきだ。WebArena-Verifiedの38.42とAutomationBenchの41.29は、1.7Bモデルがこれまでに達成してきた水準をはるかに上回っており、エージェント系ベンチマークはプロンプトのスキャフォールディングとリトライポリシーに最も敏感だからだ。Liquidの表と数ポイント以内に収まる独立実行結果が出れば、LFM3はオンデバイスのツール呼び出しにおける既定の選択肢になるだろう。10ポイント低い結果なら、LFM3は優れた指示追従モデルではあるが、エージェント性能の話が誇張されている、ということになる。

その実行が存在するまでは、正直に要約すればこうだ。LFM3は、よく設計され、異例なほど率直な小規模モデルファミリーであり、真に新しいレイヤー構成、実際のメモリ上の優位性、扱いやすいライセンス閾値での重み公開を備えている一方、主要ベンチマークのいずれについても独立した検証はない。アーキテクチャ表にある256トークンウィンドウは、コンテキスト長ではない。ローンチのその他の内容は、誰かがそうでないと証明するまでは額面どおりに受け取る価値があり、ユーザーの前に出す前に自分で測定する価値がある。