Ollama上のLFM3-1.7B：コマンド1つと、二つに分かれる成績表

執筆時点で、lfm3 の Ollama ページは公開されてから約1時間が経ち、45件のダウンロードを記録していた。これが現時点での一般利用のすべてだ。その背後にあるモデル、LiquidAI/LFM3-1.7Bは、1日前の2026年10月27日に、LFM3-1.7B-Baseバックボーンから構築された LFM3 ファミリーのテキスト担当として、Liquid AI が同じバッチでリリースしたビジョン、オーディオ、オムニ、および2つの意思決定モデルと並んで発表された。10月28日に変わったのはモデルではない。提供方法だ。ollama run lfm3 は、ローンチ当日のルートだった LFM3 互換の llama.cpp ビルドを探し回る手間を置き換える。

変更履歴の一行よりも価値がある理由は、ベンチマーク表だ。LFM3-1.7B は小型モデルクラスで最も偏ったスコアボードの一つを記録している。ブラウザ自動化、ツール呼び出し、指示追従では、自身の5倍超のサイズを持つモデルである Qwen3.5-9B を上回り、一般知識と長コンテキスト検索では二桁差でそれに負けている。その表の数値はすべて Liquid AI 自身によるものだ。まだ独立に再現されたものは一つもない。

10月28日に実際に何が変わったのですか？

Ollamaはlfm3用のタグを5つ掲載しており、どれも同じ1時間以内に付けられ、すべて256Kコンテキスト行とテキストのみの入力を備えている。デフォルトは、ほとんどの人がプルするものだ。

• lfm3:latest と lfm3:1.7b — 1.7 GB。デフォルトの Q4 クラスのアーティファクトで、どちらの名前でも同じダイジェストです

• lfm3:1.7b-mlx-bf16 — 3.5 GB、Appleシリコン向けフル精度MLX

• lfm3:1.7b-mxfp8 — 2.1 GB、8ビットMLX

• lfm3:1.7b-nvfp4 — 1.7 GB、そしてこれは注意深く読むべきものです

その最後のタグはダイジェスト 2012d88e202f を持っています — :latest の背後にある同一の成果物です。Ollama 経由で lfm3:1.7b-nvfp4 をプルしても NVFP4 チェックポイントは取得できません。本物は Hugging Face 上の別リポジトリにあり、ローカルでのプルではなく GPU サービング向けに公開されています。そのタグがプレースホルダーなのか公開上のミスなのかは、Ollama のページには記載されていません。ダイジェストは確認可能で、それらは同一です。ノートPCで FP4 のメモリ節約を当てにしていたなら、重要なのはまさにその点です。

Ollamaのページ自体はコミュニティによるアップロードではありません。Liquid AIのモデルカードは、llama.cppやLM Studioと並んでOllamaをサポート対象のGGUFエンジンの一つとして明記しているため、これは第三者のビルドではなく、ベンダー指定の経路が遅れて登場したものです。ページ上のモデルカードの文章はLiquid自身によるものです：「LFM3-1.7Bは、ローカルエージェントや特化型アプリケーション向けのトライハイブリッドモデルです。」

適合するかどうかを決める観点から見たアーキテクチャ

LFM3-1.7Bは24層にわたり1.73Bのパラメータを持ち、そのうちフルアテンションを行うのは6層だけです。13層はカーネルサイズ7のゲート付きショート畳み込みで、前世代の3から増えています。5層は256トークンのウィンドウを持つスライディングウィンドウアテンションです。長いプロンプト内のほとんどのトークンはグローバルアテンション行列にまったく到達せず、メモリ面の話はここから生まれています。

Liquidは128KトークンのKVキャッシュを1.6 GBに収めています。同じ数値はQwen3.5-4Bでは4.3 GB、MiniCPM5-2Bでは5.6 GBです。4Bモデルには不可能なハードウェア上で1.7Bモデルが長いコンテキストを保持できるのは、パラメータ数ではなく、この差があるからです。ほかにも覚えておく価値のある数値が2つあります。22Tの事前学習トークンと、エージェントのトレースやツール呼び出しに重点を置いた最終3.5Tトークンの中間学習ステージです。この最後のステージこそが、次の2つのセクションで扱うすべてを最も明確に説明するものです。

モデルカードには、16言語、LFM2.5-8B-A1Bと共有の128K語彙、そしてデフォルトで有効になる思考機能も記載されています。Ollamaはそれを隠しフラグではなく機能タグとして表示します。256Kコンテキストは設定上は実在しますが、カードが公開しているKV数値は128K時のみです。フル256Kではキャッシュがウィンドウに比例して増えるため、その範囲の上限はラップトップ向けではなくデータセンター向けの設定と考えるべきです。

スコアが高いところ

このパターンは、世界について何かを知っていることよりも、ツールを使って何かを行うことを評価するあらゆるタスクで一貫している。これらはベンダーが報告した数値であり、比較対象はLiquid AIが選んだものである。

• WebArena-Verified — LFM3-1.7B は 38.42、LFM2.5-2.6B は 3.02、Qwen3.5-9B は 28.94

• AutomationBench — 41.29（LFM2.5-2.6Bは0.94、Qwen3.5-9Bは15.10）

• BFCL V4 ツール呼び出し — 71.39（同じ2モデルは55.89と62.83）

• IFBench — 73.03（Qwen3.5-9B は 48.84）

• IFEval — 96.66、Liquidの表で最高値

• LiveCodeBench v6 — 73.46、Qwen3.5-9Bの69.86を上回る

最も興味深い行は、最も大きい行ではない。AA-Omniscienceは、モデルが推測するのではなく回答を控えるかどうかで一部採点されるベンチマークであり、LFM3-1.7Bは非ハルシネーションで92.93を記録しているのに対し、Qwen3.5-9Bは52.59だ。同じセットでのその精度は7.07である。合わせて読むと、これら2つの数値は、主に「自分は知らない」と言うモデルを表している——それは、行動を起こそうとしているエージェントでは過小評価されがちな特性であり、質問に答えることを期待されるアシスタントでは悪い特性だ。

負ける場面では、ときにひどく負ける

同じ表を、逆の方向から読んだもの。

• GPQA Diamond — 63.37。Qwen3.5-9Bは80.40、それを上回る2BモデルMiniCPM5-2Bは65.15。

• Humanity's Last Exam、ツールなし — 7.17、Qwen3.5-9Bは16.41

• RULER 128K — 65.56（Qwen3.5-4B は 84.63、Qwen3.5-9B は 87.11）

• AA-LCR 長文脈推論 — 52.83（Qwen3.5-9B は 62.00）

• MCP-Atlas — 32.57（Qwen3.5-4B は 41.37、Qwen3.5-9B は 42.67）

• SWE-bench Verified — 43.40（Qwen3.5-9Bは51.20）

• Terminal-Bench 2.1 — 12.92、Qwen3.5-9Bの17.98に対して

RULERの行には独立した一文を割く価値がある。主要スペックが256Kウィンドウのモデルは、自身の比較表の中で最も弱い長文脈検索モデルであり、その4分の1を謳うモデルに負けている。長いウィンドウと、その中から何かを見つける能力は別のスキルであり、LFM3-1.7Bは前者を手に入れて後者を手に入れていない。大規模なリポジトリや長い契約書に向けようと考えているなら、スペックシートを信じる前にあの行をテストすべきだ。

MCP-AtlasとSWE-benchのペアは、異なる位相で語られる同じ教訓だ。LFM3-1.7Bは、明確な契約を持つ単一ツールの駆動が得意だ。エージェントフレームワークが実際に構築される対象である多段階・マルチツールの作業では後れを取っており、その作業にコードベースが何をするかの知識が必要になると、さらに後れを取る。

これらの数字が何であり、何でないか

上記のすべての数値は、Liquid AI自身の評価実行に由来し、発表と同時に公開されたものです。その手法は発表内容には含まれていません。テストごとのハーネス設定も、何回の試行を平均したかの記述も、比較対象モデルをLiquidが実行したのか各モデル自身のカードから引用したのかを示す情報もありません。単一の所有者による27行の表は、測定ではなく主張です。

10月28日時点では、Artificial AnalysisにLFM3-1.7Bの項目が存在しないため、ベンダー公表値と突き合わせる第三者指標もありません。これは変わるでしょうし、変わった際に最も情報量の多い比較はエージェント的行の行であり、そこではベンダーのマージンが最も広く、したがってセカンドオピニオンが最も必要とされています。

一方で、逆向きに作用する、評価に値する細部がひとつある。Liquidは、Q4_0量子化によって犠牲になる精度を取り戻すために、量子化を意識した蒸留チェックポイントを特別に訓練し、それを別個のGGUFファイルとして提供している。人々が実際に実行する精度で小型モデルの数値を公開するのは、ほとんどのベンダーが行う以上のことであり、事後的な量子化よりも4ビットの数値を少しだけ信頼できるものにする。

実行すること、そして重要な設定

ワンライナーは ollama run lfm3 で、16GBマシンなら1.7GBのデフォルトが適切な出発点だ。このページには、モデルを既存のエージェントハーネスに接続する4つのワンラインランチャーも掲載されている——ollama launch claude --model lfm3、そしてOpenCode、Hermes Agent、OpenClawについても同じパターンだ。これがこのページで最も有用な点である。つまり、クライアントを書かずに、すでに運用しているエージェントループへモデルを投入できるのであり、これは大半のローカルモデル導入がクリアするよりも低いハードルなのだ。

カードには2つのサンプリングプロファイルが記載されており、これらは入れ替え可能ではありません。チャット、ツール使用、エージェント、コーディングには temperature 0.1、top_k 50、repetition penalty 1.1。数学と科学には temperature 1.0、top_p 0.95、top_k 20 を使用します。数学の問題でエージェント用プロファイルを実行することが、このモデルを実際よりも悪く見せる最も一般的な方法です。

Ollama を経由せずに GGUF を直接取得する場合、ファイルサイズは使い勝手よく整理されています。QAD Q4_0 チェックポイントは 1.05 GB で、1.1 GB の Q4_K_M よりわずかに小さく、量子化に耐えるようトレーニングされたものです。Q6_K は 1.43 GB、Q8_0 は余裕があれば 1.85 GB です。BF16 は 3.47 GB で、このサイズではほとんど価値がありません。

ライセンスはLFM Open License v1.0です。実質的にはApache 2.0で、追加点が一つあります。年間収益が1,000万ドル未満の商用利用は無償で、それ以上になると有償ライセンスが必要です。このしきい値は企業グループ全体で合算され、ファインチューンにも引き継がれるため、名前を変更した派生物でも逃れることはできません。非営利団体と研究用途のユーザーは、収益に関係なく免除されます。この境界線に近い場合は、この要約を含め、要約ではなくライセンス本文を読んでください。

分割プロファイルが、そのデプロイ方法にとって何を意味するか

指示追従とツール契約に強く、パラメトリック知識と長いコンテキストの検索に弱く、ノートPCで動かせるほど安価なモデルは、汎用アシスタントではない。それはエグゼキュータだ。それに適したアーキテクチャはローカルループである——モデルがどのツールを呼ぶかを決め、引数を整形し、スキーマに従う——一方で、知識集約的で真に長いコンテキストを要するステップは、より大きな何かに任せる。

この分割は、ルーターが真価を発揮するケースであり、OrcaRouter がここで何をカバーし、何をカバーしないのかを正確に述べておく価値があります。LFM3-1.7B はオープンウェイトで、お客様自身のハードウェア上で動作します。当社のカタログには掲載されておらず、本稿の内容は同モデル向けの API 提案ではありません。当社が提供するのは分割のもう半分です。つまり、200以上のホスト型モデルにまたがる1つのキーをエスカレーションの段階に提供し、プロバイダー定価への0%の上乗せ、プロバイダーの品質低下時には自動フェイルオーバー、複数のモデルを1回の呼び出しに組み合わせるルーティング DSL を備えています。実用的に言えば、ローカルモデルはループのデフォルトのままで、実際の知識を必要とする呼び出しは、2つ目の SDK と2つ目の契約ではなく、1つのエンドポイントを通じて送信されます。

モデルをデプロイするのではなく評価している段階なら、フェイルオーバーはそれが持ちこたえるかどうかを確かめるより安上がりな方法です。トラフィックの一部をそのモデルにルーティングし、フォールバックは設定したままにして、Liquid AIの表ではなく自社のタスクで比較しましょう。

ローンチが残す疑問点

Ollama のビルドは Hugging Face の GGUF と同じものですか？

正確には違います。Ollamaのデフォルト1.7 GBはQ4クラスで、量子化対応チェックポイントではなく汎用GGUFに一致します。量子化対応チェックポイントはHugging Face上の別個の1.05 GBファイルで、Q4_0の精度を取り戻すために学習されています。nvfp4タグは:latestと同じダイジェストに解決されるため、名前にもかかわらずNVFP4ビルドではありません。タスクにとって量子化品質が重要なら、QADファイルを取得してllama.cppで直接実行してください。

ラップトップは256Kウィンドウ全体を使用できますか？

まれです。Liquid が公表している 1.6 GB というキャッシュ値は 128K 向けであり、キャッシュメモリはウィンドウに比例して増えるため、フル 256K では、重みとランタイムを考慮する前の段階でおよそその倍が必要になります。16 GB のマシンでは、32K～64K の範囲の実用コンテキストが現実的な上限です。より大きなウィンドウは、ラップトップの能力というより、サーバー配備向けの余裕の主張として読むのが妥当です。

なぜエージェントのスコアとナレッジのスコアはこんなにも食い違うのですか？

なぜなら、それらは別々のものを測っており、学習実行は一方を優先したからだ。最終の3.5Tトークン中間トレーニング段階ではエージェント的トレースとツール呼び出しが重視され、その後ポストトレーニングで1.75Tトークンの教師あり微調整と、ツール使用および構造化出力にわたる強化学習が追加された。パラメトリック知識は1.7Bモデルが最も保存する余地の少ないものであり、AA-Omniscienceの内訳——正確性7.07対非ハルシネーション92.93——は、推測するよりも断るように訓練されたことを示唆している。それは設計上の選択であり、エージェントにとって正しい選択だ。

評決

LFM3-1.7Bは、このパラメータ規模のクラスで、エージェント型ベンチマークの行が脚注ではなく、ダウンロードする理由そのものになっている最初のモデルです。ツールを確実に呼び出し、スキーマに従い、答えをでっち上げるのではなく回答を控える必要があるローカルエージェントを構築しているなら、今ではコマンド1つで導入でき、そのプロファイルは用途に合っています。物事を知っており、長い文書から正確に情報を取得し、多段階のエンジニアリングタスクを遂行できるモデルが必要なら、表は明白に別のモデルを探すべきだと示しています — そして256Kという仕様は、その表の中で最も信頼できない行です。

注目すべき数字は49.37の平均ではない。独立した実行がエージェント性能の優位幅を再現するかどうかだ。なぜなら、そこは1.7Bモデルが9Bモデルを上回ると主張している行であり、ベンダー自身のハーネスが最も都合よく脚色できる余地がある行だからだ。