LFM3-1.7B-Base と LFM2.5-2.6B-Base：パラメータ数はより少なく、トークン数はより少なく、コンテキストはより長く

算術は逆方向に進む。 LFM3-1.7B-Baseは2026年10月26日に公開され、LFM2.5-2.6B-Baseより36%小さい。後者はLiquid AIが2026年8月4日にリリースしたもので、パラメータ数は17.3億対26.9億だ。学習トークン数も少ない。22兆対約34兆である。業界が事前学習済みモデルの順位付けに通常使うこの2つの数値からすれば、新しいチェックポイントの方が劣っているはずだ。Liquidの主張は逆であり、少なくともその上に構築された事後学習済みモデルについてはそうだ。そして、微調整する土台を選ぶ人にとって興味深い問いは、それらの違いのうちどれが実在し、どれがベンチマークスイートで語られた物語なのかである。 比較を実行するには、2つ目の契約ではなく計算資源がかかるべきだ。 0%マークアップ OrcaRouterはプロバイダーの定価を0%のマークアップでそのまま通す。

これは1つのファミリー内での比較なので、異例なほどクリーンです。同じベンダー、同じライセンスファミリー、同じ128,000トークンの語彙、同じ隠れサイズ2,048、同じベース対ベースの役割です。2つのチェックポイントは、アーキテクチャ、データ量、コンテキスト長、そしてトランクに組み込まれた事後学習の量において異なります。それ以外のほぼすべては一定に保たれています。

差分を、次元ごとに

• パラメータ — LFM3-1.7B-Baseでは1.73B、LFM2.5-2.6B-Baseでは2.69B。35.7%の削減であり、Liquidのローンチ投稿にある「パラメータが35%少ない」という記述はここに由来する。

• レイヤー — 24対30。新しいモデルはより狭いだけでなく、より浅くなっています。

• レイヤー構成 — LFM3では、ゲート付きショート畳み込み13個、スライディングウィンドウアテンションブロック5個、フルアテンションブロック6個。LFM2.5では、畳み込み22個とフルアテンションブロック8個で、スライディングウィンドウ層はありません。

• アテンション — LFM3ではクエリヘッドが16、キーバリューヘッドが4で、LFM2.5ではそれぞれ32と8です。どちらもヘッド次元128、隠れ層サイズ2,048を維持します。

• フィードフォワード幅 — LFM3では7,680、LFM2.5では10,752。パラメータ削減の大部分はここにあります。

• 畳み込みキャッシュ — LFM3では7つ、LFM2.5では3つに加え、256トークンのスライディングウィンドウが追加されています。

• コンテキスト — 128,000に対して262,144トークン。より新しいチェックポイントではこれが2倍になります。

• 事前学習トークン — 22兆に対し約34兆で、より新しい学習実行の最後の3.5兆は、エージェント軌跡やツール呼び出しを含む厳選された中間学習データに充てられています。

• Artifacts — LFM3-1.7B-Base は BF16 の safetensors のみ、3.46 GB での提供です。LFM2.5-2.6B-Base は Safetensors に加えて GGUF、ONNX、MLX ビルドで提供され、量子化すれば 2.5 GB 未満で動作し、Transformers、vLLM、SGLang、llama.cpp、MLX でサポートされています。

パラメータはどこへ行ったのか

削減は均等に配分されているわけではなく、ファインチューニングのコストを見積もる人にとっては重要です。埋め込みは両モデルで重みが共有されており、語彙は128,000トークンで同一なので、埋め込み行列は変わりません。隠れサイズは2,048で変わりません。節約は3つの箇所から生じています。層が6つ少なく、アテンションヘッド数が半分で、フィードフォワードブロックが約29%狭いことです。

フィードフォワードブロックを狭めることは、トランスフォーマーを縮小する最も安価な方法です。なぜなら、そのブロックが各レイヤーのパラメータの大部分を占めているからです。アテンションヘッドを半分に減らすと、重みだけでなくキーバリューキャッシュも削減されるため、コンテキストを倍にしたモデルでも4ビットで約1 GBに収まると説明できます。その代償は容量です。より狭いMLPは事実的関連を保存する余地が少なく、ヘッド数が少ないとモデルが利用できる独立したアテンションパターンも減ります。Liquidの主張は、より良いデータとより良いレイヤー構成がそれを十分に補うというものです。その主張は検証可能であり、公開時点では社外の誰もそれを検証していません。

コンテキストの取得元

コンテキストを128Kから256Kへ倍増させつつアテンションのコストを倍にしないには、グローバルにアテンションしないことが必要だ。LFM3のスタックは、24層のうち5層を256トークンのスライディングウィンドウに、13層を畳み込みに割り当て、全シーケンスを見る層を6層だけにすることでそれを実現している。この設定ではさらに、グローバルアテンション層に部分ロータリー係数0.5を持たせ、各ヘッド次元の半分にロータリー埋め込みを適用し、それらの層のロータリーシータを100万に、スライディング層では1万にしている。

Liquidのローンチ記事は、これによって何が得られるかについて具体的な数字を1つ挙げている。128Kトークン時点で、テキストモデルのKVキャッシュは1.6 GBだ。LFM2.5-2.6B-Baseについては、同等の数値は公開されていない。したがってこの比較は正確なものではなく方向性を示すものであり、新しいアーキテクチャはより少ないメモリでより長いコンテキストを保持できるよう設計されており、ベンダー自身の数値が唯一利用可能な測定値である。

トークン数が少ないことが興味深い主張である理由

34兆トークンから22兆トークンへの削減は、データレベルでの事前学習計算量の35%削減であり、ほとんどのモデル世代とは逆方向です。通例は、より多くのデータ、より多くのパラメータ、より優れたモデルという話です。Liquidの話はその両方がより少なく、新しいアーキテクチャと、科学論文、リポジトリレベルのコード、数学、より幅広い知識源を追加するデータミックスを備えています。

3.5兆トークンの中間訓練ステージは、このチェックポイントを単純な事前訓練と区別する部分です。そこでは厳選されたより高品質なデータが使われ、エージェント軌跡とツール呼び出しの割合がより大きくなっており、コンテキストウィンドウが拡張されるのもこの段階です。この段階は、ベースモデルがチャットテンプレートを備えている理由でもあります。中間訓練データは、思考トレースの有無にかかわらず、会話としてフォーマットされていました。

これらのいずれも外部から検証することはできない。トークン数は自己申告であり、データの混合比率は公開されておらず、どの変更がどの改善を生んだかを示すアブレーションも存在しない。この主張はもっともらしい——過去2年間、データ品質は生のデータ量を繰り返し上回ってきた——が、もっともらしいことは測定されたことを意味しない。

拠点間比較で決着できること

仕様、コスト、互換性については判断できますし、このページはそれを示しています。品質については判断できません。どちらのチェックポイントにも公開ベンチマークがないからです。LiquidはLFM2.5-2.6B-Baseについて評価を公開しておらず、LFM3-1.7B-Baseについても公開していません。両方のカードは、このチェックポイントを大規模なファインチューニング向けに推奨し、チャットについては読者を別の場所へ案内しています。

このファミリーにおける唯一の品質根拠は、ポストトレーニング済みのペアだ。Liquidは、LFM3-1.7Bが自社スイートで平均49.37、LFM2.5-2.6Bが31.55だと報告しており、新しいモデルはパラメータ数が35%少ない。これは大きな差だが、ベンダーが選んだスイートで測定されたベンダー公表の数値であり、ポストトレーニングだけでなくトランクも異なる2モデルを比較したものだ。これはLFM3のレシピがより優れたinstructモデルを生み出す証拠ではある。しかし、ベースチェックポイントがより良い出発点である証拠にはならない。なぜなら、その上に施されたポストトレーニングだけで差のすべてを説明できる可能性があるからだ。

LFM2.5を利用中の方向けの移行メモ

2つのチェックポイントは語彙サイズ、隠れ層サイズ、トークナイザファミリーを共有しているため、移行は実際よりも簡単に見えます。しかし、モデリングコードは共有していません。LFM2.5はLfm2ForCausalLMとして、LFM3はLfm3ForCausalLMとして、どちらもtrust_remote_code=Trueを指定したカスタムコード経由で読み込まれます。片方向けに書かれたトレーニングスクリプトは、モデルクラスを変更しなければもう片方を読み込めず、チャットテンプレートも思考トレースの扱いが異なります。

運用上のより大きな違いはパッケージングです。LFM2.5-2.6B-Base には GGUF、ONNX、MLX のビルドがあり、llama.cpp、vLLM、SGLang、Transformers、MLX で動作します。LFM3-1.7B-Base は単一の BF16 safetensors ファイルとして提供されます。量子化版およびクロスプラットフォーム向けビルドは、ベースチェックポイントではなく、事後学習済みの LFM3-1.7B 向けに存在します。パイプラインが GGUF アーティファクトに依存している場合は、自分で変換し、その結果を検証することになります。

ファインチューニングのサポートが、その対抗軸となっています。LFM3-1.7B-Base は、教師ありファインチューニングと継続事前学習のための TRL ノートブックをリンクしており、ドキュメントではそこから先の道筋も扱っています。より小さいチェックポイント、256K コンテキスト、エージェント向けの中間学習は、いずれも、それらのノートブックが示すようなドメイン適応まさにそのものを狙っています。

どのトランクから始めますか

LFM3-1.7B-Base から始めてください新規のファインチューニングを始め、タスクが長いコンテキストの恩恵を受け、Transformers で BF16 を扱える、または自分で重みを変換できるなら、

LFM2.5-2.6B-Base を使い続けるべきなのはすでに動作しているパイプラインがある場合、GGUF または ONNX のアーティファクトに依存している場合、あるいは1年分のコミュニティツールの蓄積を持つチェックポイントが必要な場合です。新しいモデルは登場からまだ3日しか経っていません。その instruct 兄弟モデルには量子化ビルドがあり、vLLM、SGLang、llama.cpp、Ollama、LM Studio、MLX、ONNX Runtime で初日からサポートされていますが、base チェックポイントにはそれがなく、この差こそが早く採用する実質的なコストです。

確信が持てないなら、マーケティング資料を読むのではなく、実験を実行してください。自分のデータの小さな一部を取り、同じ継続事前学習レシピを両方のトランクに対して同じステップ数だけ実行し、開始前に作ったホールドアウトセットで評価します。それは数GPU時間で済み、どのベンダーの表でも答えられない問いに答えてくれます。2つのファインチューニングができたら、両方を1つのエンドポイントの背後に置きます。OrcaRouterのルーティングDSLはそれらの間でトラフィックを分割できます、自動フェイルオーバーにより、悪い実験が悪い本番日になることはありません。プラットフォームはプロバイダーの定価を0%のマークアップでそのまま適用するため、テスト実行のコストはコンピューティングのコストであり、2つ目の契約ではありません。

注目の数字

これを決着させる主張は、別の平均値ではない。それは、同一のファインチューニング手順を経た LFM3-1.7B-Base と LFM2.5-2.6B-Base を比較する、Liquid または第三者によって公開されたベースモデル評価——どのベースモデル評価でもよい——である。それが存在するまで、世代間の差分はアーキテクチャと設定に記録されており、トークン数においてはもっともらしく、重要なところでは未証明である。新しいチェックポイントはより小さく、より長いコンテキストを持ち、トレーニング向けによりよくパッケージ化されている。それがより優れているかどうかは、リポジトリが答えていない問いである。