-
title: "1.7Bで「9B級」は本当か：LFM3-1.7Bを公式の数値で読み解く"
emoji: "🧪"
type: "tech"
topics: ["llm", "ai", "ローカルllm", "lfm3", "liquidai"]
published: true
TL;DR
- Liquid AIが2026年10月27日に公開したLFM3ファミリーの中核が、1.73BパラメータのテキストモデルLFM3-1.7Bである（※1、※2）。
- 公式の比較表では、平均スコアが49.37で、Qwen3.5 9Bの47.24を上回る。ツール利用（BFCL V4）やWebArena-Verifiedでは大きく先行する（※2）。
- 一方で、知識系（GPQA Diamond）と128Kの長文検索（RULER 128K）では、Qwen3.5 4B・9Bに明確に負けている。「全部9B級」ではなく、「エージェント用途に絞れば9B級に近い」というのが公式数値の読み方である。
- 本稿の数値はすべてLiquid AIの自社公表値であり、筆者は第三者の再現を確認できていない。モデルの実行も行っていないため、動作は未検証である。
- 向いているのは、端末やCPU環境で動かすツール呼び出し・指示追従の小型エージェント。複雑な多段推論やコーディングを任せたい場合は、公式も非推奨としている。
1. なぜ今これを読むのか
2026年11月4日時点で、Hugging FaceのトレンドモデルのダイジェストにLFM3-1.7Bが入っている。いいね数は1,418、月間ダウンロード数は47,817である（※3）。同じ日のダイジェストでは、Qwen3.8-27Bが19,093いいね、DeepSeek-V4.1-Flash-1017が4,873いいねと、より大きな数字が並んでいる。1.7Bクラスのモデルとしては目立つ位置にあるが、「爆発的」と呼ぶほどの数字ではない。
注目したい理由は、数字の大きさよりも設計の方向にある。公式ブログは、LFM3を「約2Bクラスで、テキスト・視覚・音声・オムニ・意思決定モデルが同じ土台（LFM3-1.7B-Base）を共有するファミリー」と説明している（※2）。つまり、1つの小さな骨格を使い回して複数のモダリティに広げる設計だ。ローカルで動かす小型モデルを、エージェントの「手足」として使う流れの中で、この設計がどこまで通用するかを確認しておきたかった。
なお、公式ページにはLFM3-1.7Bの公開日がモデルカード上で明記されていない。ブログ記事の日付（2026年10月27日）をリリース日として扱う（※2）。
2. 仕組み：3種類の層を混ぜた24層
2.1 層の構成
公式ブログとモデルカードによれば、LFM3-1.7Bは24層で、内訳は次のとおりである（※1、※2）。
| 層の種類 | 層数 | 補足 |
|---|---|---|
| gated short convolution（ゲート付き短い畳み込み） | 13 | カーネル幅7（LFM2では3） |
| sliding-window attention | 5 | 窓は256トークン |
| global attention | 6 | 全トークンを見る通常のattention |
図1：層数の内訳。層の並び順は公式ページから確認できていないため、図では種類ごとにまとめて示した
このうち、畳み込み層は近傍のトークンだけを見る。sliding-window attentionも256トークンの範囲に限られる。全体を見渡すglobal attentionは6層だけである。長い文脈でKVキャッシュ（過去トークンの中間表現の保存領域）が膨らむのは、主にglobal attentionの層なので、この構成はメモリを節約する方向に働く。公式は、128Kコンテキスト時のKVキャッシュが1.6GBで、Qwen3.5-4Bの4.3GB、MiniCPM5-2Bの5.6GBより小さいと述べている（※2）。
図2：128Kコンテキスト時のKVキャッシュ。公式ブログの公表値
2.2 そのほかの設計
公式ブログは、次の要素も挙げている（※2）。
- head-wise gated attention：各attentionヘッドの出力にシグモイドのゲートをかける。量子化に悪影響を与える活性化の外れ値を抑える狙いがあると説明されている。
- partial RoPE：global attentionでは、各ヘッドの高周波側の半分にだけ回転位置埋め込みをかける。
- sandwich norm：各ブロックの入力側と出力側の両方で正規化する。
- 語彙は128K。事前学習は22Tトークン、さらに256Kまでコンテキストを延ばす中間学習が3.5Tトークン。
これらが性能にどの程度寄与しているかは、アブレーション（要素を1つずつ外した比較）が示されていないため、筆者には判断できない。構成要素の列挙は、設計意図の説明として読むのが安全である。
3. 公式ベンチマークを読む
3.1 比較表（抜粋）
以下は、モデルカードの比較表から、用途の違いが出やすい行を抜き出したものである（※1、※2）。すべてLiquid AIの自社公表値で、実行条件の詳細（プロンプトや試行回数）は、筆者は確認していない。
| ベンチマーク | LFM3 1.7B | LFM2.5 2.6B | MiniCPM5 2B | Gemma 4 E4B | Qwen3.5 4B | Qwen3.5 9B |
|---|---|---|---|---|---|---|
| BFCL V4（ツール利用） | 71.39 | 55.89 | 62.65 | 48.25 | 55.12 | 62.83 |
| WebArena-Verified | 38.42 | 3.02 | 9.11 | 17.06 | 21.92 | 28.94 |
| AutomationBench | 41.29 | 0.94 | 4.71 | 1.92 | 8.67 | 15.10 |
| MCP-Atlas | 32.57 | 16.45 | 26.38 | 6.19 | 41.37 | 42.67 |
| SWE-bench Verified (OpenCode) | 43.40 | 18.00 | 34.80 | 0.50 | 41.20 | 51.20 |
| LiveCodeBench v6 | 73.46 | 60.57 | 70.52 | 71.00 | 61.99 | 69.86 |
| IFEval | 96.66 | 95.39 | 87.83 | 90.02 | 92.52 | 92.08 |
| GPQA Diamond | 63.37 | 57.78 | 65.15 | 57.88 | 75.76 | 80.40 |
| RULER 128K | 65.56 | 1.15 | 37.96 | 18.82 | 84.63 | 87.11 |
| 平均（表全体） | 49.37 | 31.55 | 39.19 | 31.74 | 39.27 | 47.24 |
図3：5つのベンチマークの抜粋。LFM3が橙、Qwen3.5が青系
3.2 読み取れること
まず、LFM3-1.7Bが強いのは、ツール利用、Web操作、指示追従の行である。BFCL V4では71.39で、Qwen3.5 9Bの62.83を上回る。WebArena-Verifiedは38.42対28.94、AutomationBenchは41.29対15.10と、差が大きい。IFEvalは96.66で、表の中で最高である。公式ブログも、BFCLとToolSandboxで先行し、WebArena-VerifiedとAutomationBenchではQwen3.5-9Bを上回ると述べている（※2）。
次に、知識と長文検索では負けている。GPQA Diamondは63.37で、Qwen3.5 4Bの75.76、9Bの80.40に届かない。RULER 128Kも65.56で、Qwen3.5 4Bの84.63、9Bの87.11より大幅に低い。MCP-Atlasも、Qwen3.5 4B・9Bの方が高い（41.37、42.67対32.57）。
そして、コーディングは中間である。LiveCodeBench v6では73.46で最高だが、SWE-bench Verified (OpenCode)は9Bの51.20に届かない。公式のモデルカードも、小さなモデルであることを理由に、agentic codingや複雑な多段推論には勧めないと書いている（※1）。
3.3 平均値の注意点
平均で49.37対47.24と、1.7BがQwen3.5 9Bを上回るのは確かに目を引く。ただし、この平均は、表に載せた行の選び方に左右される。表にはエージェント系・ツール系の行が多く含まれており、LFM3が得意な領域の比重が大きい。知識・長文系の行を増やせば、順位は入れ替わる可能性がある。平均はあくまで「この表のこの行の組み合わせでの平均」であり、モデルの総合力を示すとは言い切れない。
また、AA-Omniscience（非ハルシネーション率）の行では、LFM3が92.93と極めて高い一方、正答率は7.07と低い。これは、「わからないときに答えない」傾向が強いことを示唆する。ハルシネーションが少ない点は長所だが、知識を引き出す用途では、答えが返ってこない場面が多いとも読める。この解釈は筆者の推測で、公式は断定していない。
4. 使いどころの整理
4.1 向いている場面
公式がモデルカードで挙げる用途は、ローカルのエージェントとツール呼び出し、構造化出力、ドメイン特化のファインチューニング、スマートフォンやノートPCでのエッジ展開である。4ビット量子化で約1GBに収まるとされる（※1）。数字の裏付けとして、公式ブログは、llama.cpp（Q4_0、32Kコンテキスト）で3種類のデバイスにおいて、比較対象の次点モデルより1.8〜2.8倍速くデコードできると述べている（※2）。ただし、これも自社測定で、どのデバイスかの詳細は筆者は確認していない。
実務に置き換えると、次のような用途が候補になる。
- 社内の端末内で動く、定型的なツール呼び出し（カレンダー操作、ファイル検索、社内APIの呼び出し）
- JSONなどの構造化出力を安定して返してほしい前処理・振り分け
- 小型モデルをベースに、自社データで追加学習する用途（公式はTRLによるSFT、DPO、GRPO、CPTを挙げている）
4.2 まだ待った方がよい場面
- 知識の正確さが問われる質問応答。公式も、知識を使う作業は検索（RAG）と組み合わせるよう勧めている。
- 長い文書からの情報検索。RULER 128Kの結果を見る限り、Qwen3.5系が優位である。
- 大きなコードベースを相手にした自律的なコーディング。
- ライセンス確認が済んでいない商用利用。ライセンスは「LFM Open License v1.0」で、Apache-2.0やMITではない（※1）。筆者はライセンス本文を確認できていない（取得に失敗した）ため、利用条件は必ず原文で確認してほしい。
5. 他のモデルとの位置づけ
ファミリー全体を、公式ブログから整理する（※2）。
| モデル | 種類 | 備考 |
|---|---|---|
| LFM3-1.7B-Base | 事前学習ベース | カスタマイズ用 |
| LFM3-1.7B | テキスト | 256Kコンテキスト |
| LFM3-VL-2B | 視覚＋言語 | 動画入力と推論に対応 |
| LFM3-Audio-2B | 音声入出力 | 18言語 |
| LFM3-Omni-2B | 視覚・音声・言語 | 1モデルに統合 |
| d1-2B / d1-Omni-2B | 意思決定 | テキスト・画像（Omniは音声も） |
配布はHugging Face、実行環境はllama.cpp、MLX、vLLM、SGLang、Ollama、LM Studio、Unslothなどに対応すると記されている。ハードウェアも、Apple、AMD、NVIDIA、Qualcomm、Intel、Armなど広い。ただし、これらの対応状況は公式の記載であり、筆者が確認したわけではない。
比較の観点では、同じ小型帯のGemma 4 E4Bは、ツール利用（BFCL V4で48.25）やコーディング（SWE-bench Verified (OpenCode)で0.50）で今回の表では苦戦している。これは、同じ条件で比べられたかどうかを筆者が確認できていないため、モデルの優劣というより「この公式表ではこうなっている」という扱いにとどめたい。
6. 試し方（未検証）
筆者は今回、モデルの実行を行っていない。そのため、以下はモデルカードの記述をそのまま紹介するものであり、動作は未検証である。実行する場合は、環境（Pythonとtransformersの版）を各自で確認してほしい。
from transformers import pipeline
generator = pipeline(
"text-generation",
model="LiquidAI/LFM3-1.7B",
trust_remote_code=True,
)
messages = [{"role": "user", "content": "What is C. elegans?"}]
output = generator(
messages,
do_sample=True,
temperature=0.1,
top_k=50,
repetition_penalty=1.1,
max_new_tokens=2048,
)
print(output[0]["generated_text"][-1]["content"])
上記はモデルカードのクイックスタートである（※1）。trust_remote_code=Trueはモデルのリポジトリにあるコードを実行する設定なので、信頼できる提供元かどうかを確認したうえで使う。サンプリングの推奨値は、一般用途でtemperature=0.1、top_k=50、repetition_penalty=1.1。数学・STEM用途ではtemperature=1.0、top_p=0.95、top_k=20とされている。
llama.cpp向けには、GGUF版（LiquidAI/LFM3-1.7B-GGUF）が案内されている。ツール呼び出しを使うときは、現行のチャットテンプレートを持つGGUFを使うか、--chat-template-fileで読み込む、という注意書きがある（※1）。
7. 筆者の評価
7.1 評価できる点
- 「小さいモデルで全部やる」ではなく、ツール利用と指示追従に寄せた設計と、その範囲で強い数値を出している。
- 知識系・長文系で負けている結果も、公式の表にそのまま載せている。
- KVキャッシュの小ささなど、エッジ環境での実用に関わる数字を前面に出している。
- 1つの骨格をテキスト・視覚・音声に広げるファミリー設計は、小型エージェントを組む側にとって扱いやすそうに見える。
7.2 懸念される点
- すべての数値が自社公表で、第三者による再現が見当たらない。実行条件（プロンプト、試行回数、ツールの実装）が結果に影響しやすいエージェント系のベンチマークでは、特に注意が必要である。
- 平均値は、表に載せた行の選び方に影響される。
- モデルカードの
enable_thinking=Falseは、推論を要する課題で挙動が不安定になることがあると記されている。 -
trust_remote_code=Trueが必要な点は、運用ポリシーによっては導入のハードルになる。 - ライセンスは独自（LFM Open License v1.0）で、条件の確認が必要である。
7.3 結論
LFM3-1.7Bは、「9B級の万能モデル」ではなく、「ツール呼び出しと指示追従に強い小型エージェント用モデル」として読むのが妥当だと考える。この前提なら、端末内での自動化やプライバシーに配慮した前処理など、実用的な候補になる。一方で、本稿の数値は自社公表の範囲にとどまる。導入を検討するなら、自分のツールセットとプロンプトで小さな評価セットを作り、Qwen3.5 4Bなどと並べて確かめるのが確実である。
まとめ
LFM3-1.7Bは、24層の中に畳み込み・窓付きattention・全域attentionを混ぜ、KVキャッシュを小さく抑えながら、ツール利用や指示追従で公式表の上位に入ったモデルである。知識と長文検索は弱く、コーディングも中程度である。数値は自社公表で、筆者はモデルを実行していない。用途を絞り、自分の環境で評価してから採用を決めたい。
※本記事の記載内容は筆者個人の見解であり、所属する会社や組織の立場や方針とは一切関係ありません。
筆者情報
【Tomcat-zhou】｜AI/AX/AIセキュリティ専門家
AI戦略洞察、AI駆動開発の方法論設計と現場で回る仕組みづくりをしています。
noteで戦略洞察 / Zenn・Qiitaで技術・方法論を書いています。
AIセキュリティ・AIコンサル・AIエージェント開発・AI活用・AI駆動開発教育、AI人材育成サービスを一体で提供。
X: @ZY20240528
LinkedIn: Tomcat-zhou
Facebook: zhou yi
note: Tomcat-zhou
Zenn: Tomcat-zhou
参考資料
- LiquidAI/LFM3-1.7B（Hugging Faceモデルカード）
- LFM3（Liquid AI公式ブログ）
- Hugging Face Trending Models 2026-11-04（news-radar）
タグ
AI LLM ローカルLLM LFM3 LiquidAI エージェント 小型モデル