PAN 2 vs LFM2.5-2.6B-Base：ファインチューニングすることを前提とした2種類のチェックポイント

LFM2.5-2.6B-Base について最初に気づくのは、「Base」という言葉だ。Liquid AI の26.9億パラメータのチェックポイントは、対話するためのモデルではない。そこからポストトレーニング済みの LFM2.5-2.6B 各バリアントが作られる、事前学習済みの土台であり、他の人々が自分たちのものを作れるように公開されている。PAN 2 は同じ種類の対象を30倍の規模にしたものだ。MBZUAI の Institute of Foundation Models による290億パラメータの拡散トランスフォーマーで、Apache-2.0 の下、学習設定とともにリポジトリで公開されており、単に消費されるのではなく適応されることを想定している。並べてみると馬鹿げて見える——一方はノート PC で動かせる言語モデル、もう一方は B300 を4台要求する動画ワールドモデルだ。しかしどちらもライセンスが付いたベース成果物であり、実際の仕事がチェックポイントを取って、それが学習していないことをさせることである人にとって、興味深い比較は能力などではまったくない。各々が作業のために何を与えてくれるのか、そしてそれが何なのかを突き止める間、その物体を保持するのにどれだけコストがかかるのか、だ。

ライセンスから始めましょう。それが唯一の決定的な違いだからです。

PAN 2自体のコードと重みはApache-2.0です。サードパーティ製の部分——テキストエンコーダーとしてのQwen3.5-9B、VAEとしてのWan 2.2、Diffusers——はそれぞれ独自の条件の下で使用され、MBZUAIによって再配布されることはありません。これらは作者からダウンロードします。これはクリーンで退屈な、企業法務に優しい取り決めであり、レビュープロセスを備えた企業がそもそもPAN 2を採用できる主な理由です。

LFM2.5-2.6B-Base は LFM1.0 ライセンスの下でリリースされており、Hugging Face はこれをその他として、SPDX 識別子ではなく LICENSE ファイルへのリンク付きで記録しています。これは批判ではありません — Liquid のライセンスは売上高のしきい値まで商用利用を許可しており、これはオープンウェイトのリリースとして一般的で妥当な形です — しかし、Apache-2.0 とは形が異なり、その違いはファインチューニング後に気づくような些細なことではありません。法務チームに事前承認済みライセンスのリストがある場合、この2つのモデルのうち一方はそのリストに載っており、もう一方については話し合いが必要です。

その非対称性はパラメータ数の大小とは逆方向に働いていて、よく噛みしめる価値がある。小さなモデルの方にはしがらみがあり、巨大な方こそ誰にも許可を求めずに出荷できるのだ。

ベースチェックポイントが実際に提供してくれるもの

LFM2.5-2.6B-Baseはハイブリッドアーキテクチャです。30層のうち22層が二重ゲート付きショートコンボリューションブロック、8層がグループ化クエリ注意です。この組み合わせこそがLFM系の狙いそのものであり、長い系列長では畳み込みブロックが低コストで、注意ブロックが想起を担うため、26.9億パラメータで131,072トークンのコンテキストを扱える理由でもあります。学習は128,000トークンの語彙で34兆トークンに達し、アラビア語、日本語、韓国語、タイ語、ベトナム語を含む16言語をカバーしています。

それが持っていないのは、何らかのポストトレーニングだ。インストラクションチューニングも、名に値するチャットテンプレートも、安全性アラインメントもない。ベースモデルは次のトークンを予測するだけで、それがすべてなので、インストラクションフォローイングのベンチマークで評価するには不適切であり、LoRAがあなたのドメインでどれだけ速く収束するかを評価するには適切だ。Liquidはポストトレーニング済みの兄弟モデルを別途公開しており、その兄弟モデルのGGUFビルドとONNXビルドが存在することこそが、意図を最も明確に示す表明だ。このファミリーは、自分が所有するデバイス上で動かすためのものだ。

PAN 2 はかなり多くの足場を用意してくれる一方、1 つの特定の点では自由度が低くなります。リポジトリには、事前学習用と教師ありファインチューニング用の両方の学習設定——config/pretrain_29B_720p.yaml と config/sft_29B_720p.yaml——が同梱されており、ドキュメントでは、それらのデータパスを自分のラテントに向けるよう指示されています。つまり、ファインチューニングの道は存在します。しかし、それが期待するデータはテキストではありません。特定の構造化キャプション形式で注釈付けされた動画ラテントです。すなわち、出来事は順序どおりに、行動は行為者に紐付けられ、カメラモーションが記され、テキストエンコーダの 1,536 トークンという予算内に収まっている必要があります。PAN 2 を自分のドメインでファインチューニングしたいなら、最初のプロジェクトは学習実行ではありません。自分の映像をその形式に変換するデータパイプラインです。そしてリポジトリが提供するのはバリデータであり、アノテータではありません。

• ファインチューニングに必要な計算資源 — LFM2.5-2.6B-Base：単一GPU、ワークステーション上のLoRAで、数週間ではなく数時間。PAN 2：オプティマイザ状態を含める前のBF16で67.37 GBのトランスフォーマーに加え、15.87 GBの凍結エンコーダーとVAEを、動画潜在変数上で扱う。マルチノード構成であり、しかもレシピは誰も公開していない。

• 用意が必要なデータ — LFM2.5-2.6B-Base：テキスト（タスクで使用する任意の形式）。PAN 2：動画に加えて、リポジトリのスキーマに沿った構造化された世界状態キャプション。

• 出力として得られるもの — LFM2.5-2.6B-Base：テキスト生成器。そしてポストトレーニング後は、アシスタントまたはエージェントポリシー。PAN 2：最大20秒、704×1248、24 fpsの動画で、ある行動の結果を示す。

• ライセンス — LFM2.5-2.6B-Base: LFM1.0、その他、読んでください。PAN 2: 自身の重みには Apache-2.0。

両者がほぼ肩を並べる唯一のベンチマークでは

実際に重なりはあり、しかも興味深いことに、その重なりはごく小さいものです。OpenBMBのMiniCPM5-2Bモデルカードでは、LFM2.5-2.6Bを自社の2Bモデルやその他の複数モデルと比較するベンチマークが掲載されており、そのうちの1行は長コンテキストです。AA-LCRでは、OpenBMBはLFM2.5-2.6Bを5.3、MiniCPM5-2Bを59.0と報告しています。NoLiMaでは0.7対68.1。LongBench v2では30.3対43.7です。

これらは競合他社が報告した数値であり、競合他社のハーネス上で得られたもので、それを公開しているモデルカードにはこの比較において明らかな利害関係がある。しかし、最も難しい長文コンテキストの2つのプローブにおける差の大きさは、ハーネスの選択では説明しきれない類のものであり、「131,072トークンのコンテキスト」を能力の主張として読むことに対する有用な修正材料になる。コンテキストウィンドウは容量であり、長い文脈での想起は振る舞いである。Base チェックポイントは前者を備えているが、第三者の証拠によれば後者はあまり備えていない。まさにそのため、想定される用途はファインチューニングであり、そのまま使える長文書アシスタントではないのだ。

PAN 2にはそれに相当するクロスチェックが存在しない。MBZUAIの外でベンチマークを実施した者はいないし、存在する数値はモデルカードに書かれたものだけだ。これはLFM2.5-2.6B-Baseよりも証拠として弱い立場にあり、しかも実行コストは百倍高い——独立した評価は採用の後に続き、採用はそもそもそれを動かせるかどうかに左右される、ということを思い知らされる。

各チェックポイントを保持するコスト

LFM2.5-2.6B-Baseは約27億パラメータです。BF16では重みは余裕をもって6GB未満に収まり、事後学習済みの兄弟モデルのGGUFビルドならそれをはるかに下回ります。スタックの他の部分と同じマシン上に常駐させ、一晩でファインチューニングし、そこにあることさえ忘れられます。

PAN 2は60ファイルで86.17 GBあり、重要なのは総量ではなくその形です。Transformerは67.37 GBで、すべての推論ワーカーが完全なコピーを保持します。リポジトリ自身の推論スクリプトはGPUごとに1ワーカーを実行し、各ワーカーがN個おきにプロンプトを処理します。その経路にはテンソル並列シャーディングがないためです。vLLMのレシピはシャーディングを使う選択肢で、その要点は、4台のB300上で2ランクにまたがるclassifier-free-guidance並列と2ランクにまたがるUlyssesシーケンス並列を用い、704×1248の動画13秒分を約119秒で生成するというものです。デフォルトはH200 8台です。各ステップでガイダンスを行う50ステップのサンプラーでは、クリップあたり100回のフォワードパスが必要であり、これがレシピ内のあらゆる構成選択の背景にある計算です。

つまり、正直なコスト比較は「6 GB 対 86 GB」ではない。「推論1回あたりの限界費用ゼロ 対 出力2分につきマルチGPUノード1台」だ。ファインチューニング済みの2.6Bモデルがクエリに答えるコストは、測定できないほど小さい。ファインチューニング済みのPAN 2で20秒のクリップをレンダリングするには、GPUノードを3分間使う。しかも、ファインチューニングがうまくいったか分かるまでに、それを何百回も実行することになる。

ルーターがこれらのいずれかに接する箇所

どちらのモデルも、ルーティングレイヤーが提供できるものではありません。LFM2.5-2.6B-Base はベースチェックポイントであり、ルーティング先として価値のあるホスト型エンドポイントはありません——ダウンロードするファイルです。PAN 2 には、MBZUAI からも他の誰からも、ホスト型エンドポイントは一切ありません。あなたの計画にどちらかが含まれるなら、その計画には GPU が含まれます。

そもそもルーティングに触れる理由は、ベースモデルを単独でデプロイする人はほとんどいないからです。ファインチューニングした LFM2.5 は、汎用推論モデルも必要とするアプリケーションの一構成要素であり、PAN 2 シミュレーションは、最初の段階で言語モデルが構造化キャプションを書くパイプラインの一工程です。その周辺レイヤーこそ、200 以上ものモデル向けの単一 API が価値を持つ場所です：チューニング済みチェックポイントは自社ハードウェアに保持し、汎用的な呼び出しはプロバイダーの定価で OrcaRouter 経由でルーティングし、0% のマークアップをそのまま通して、プロバイダーが不調な時間帯には自動フェイルオーバーを得られます。特に PAN 2 パイプラインでは、キャプション段階が伸縮自在な部分です — レポートは Claude Opus 5.5、GPT-6 Astra、Kimi K3、Qwen3.8-Flash を計画全体の完了率で順位付けしており、Qwen3.8-Flash は OrcaRouter 上にあるため、4 つのモデルをプロビジョニングしなくても、どのプランナーが実際に自分のプランを完了するかを試せます。

OrcaRouter が行わないのは、どちらのチェックポイントもホストすることです。そうでないと言うのは、機能のように聞こえてバグのように振る舞う種類の主張になるでしょう。

ベースモデルという枠組みが隠しているもの

どちらのリリースも、厳密な意味では未完成だ。LFM2.5-2.6B-Base は設計上、指示チューニングが施されていない。PAN 2 には制限事項のセクションがあり、そこにはシミュレーションされた計画の約3分の2に、実行されないステップが少なくとも1つ含まれると書かれている。どちらも製品ではない。違いは、「未完成」がそれぞれのケースで何を意味するかにある。

LFM2.5-2.6B-Base において、unfinished はベンダーがすでに下流まで完了させているパイプラインの一工程です — ポストトレーニング済みモデルは存在し、量子化ビルドも存在し、ベースチェックポイントは分岐したい人々のために公開されています。このギャップは意図的であり、文書化されています。

PAN 2 にとって、未完成とはリリース全体の状態そのものです。重みは公開され、フレームワーク対応は11月10日に実装され、それについて公に語られた唯一のことは、同日午後にラボ自身のXアカウントに投稿された2段落のポストだけです。その制限は下流のユーザーに渡される設計上の選択ではなく、チームが公に名指ししている未解決の問題です。PAN 2 をファインチューニングするなら、重みとともにこれらの問題も引き継ぐことになります。

それが本当の比較であり、両モデルは代替品ではないため、これは2つのモデル間の推奨には帰着しません。これはあなたのプロジェクトに関する問いに帰着します。実績が確認されたコンポーネントを改変して使っているのか、それとも障害モードがまだ測定されている研究用の成果物の上に構築しているのか。LFM2.5-2.6B-Base は前者です。PAN 2 は後者であり、Apache-2.0 ライセンスが、後者が選択肢にすらなり得る唯一の理由です。