Fibo 2.0 vs LFM2.5 2.6B Base：テキストの27億パラメータか、それとも画像の81億パラメータか

サイズの差は誰もが最初に気づく点であり、この比較で最も役に立たない点でもある。Briaが2026年10月20日にリリースしたFibo 2.0は8,127,342,213個のパラメータを持ち、画像を返す。Liquid AIが2026年8月1日にリリースしたLFM2.5 2.6B Baseは26.9億個のパラメータを持ち、テキストを返す——しかも完成されたテキストではなく、指示チューニングを一切施していない事前学習済みベースチェックポイントの、生の続き生成挙動を返す。どちらが優れているかを問うのは、カメラと辞書のどちらが優れているかを問うようなものだ。答えのある問いはもっと狭く、より実用的だ。それぞれが自らの領域における、信頼に足る最小のオープンな選択肢であり、各領域の下限がどこにあるかを知れば、自分の制約が実際にどちらを除外するのかが分かる。どちらのモデルカードにも、このようなチェックポイントが不適切にデプロイされたときに何が起こるかは記録されておらず、記録されたインシデントはOrcaRouter AIインシデントアーカイブに目録化されており、各項目には独自の情報源、重大度、信頼度グレード、異議ありフラグが付いている。

床、両方向とも

どちらのモデルも、同じ構造的な理由で興味深い——それぞれがその役割にとって成立するぎりぎりの下限付近にあり——そして、それだけが両者を比較できる唯一の軸である。

• パラメータ — Fibo 2.0 は BF16 で 8,127,342,213、LFM2.5 2.6B Base は 26.9 億。重みではおよそ 3 対 1 の比率で、メモリでもほぼ同じ比率です。

• 出力 — Fibo 2.0 は画像を返します。LFM2.5 2.6B Base はテキストトークンのみを返し、それ以外は何も返しません。

• 動作環境 — Fibo 2.0 には、50ステップ（Turbo バリアントでは4ステップ）の44ブロック拡散トランスフォーマーを実行できる十分なVRAMを備えたGPUが必要です。LFM2.5 2.6B Base は GGUF、ONNX、MLX 形式で提供され、スマートフォン、ノートパソコン、シングルボードコンピュータ上で動作するように作られています。

• チューニング状態 — Fibo 2.0 Dev は classifier-free guidance を備えた非蒸留のベースモデルで、ファインチューニング向けに文書化されています。LFM2.5 2.6B Base は事前学習のみのモデルで、誰かがチューニングを施すまで指示追従の挙動はありません。

• ライセンス — Fibo 2.0 は非商業利用については CC BY-NC 4.0 であり、商業利用は契約に基づきます。LFM2.5 2.6B Base は LFM 1.0 ライセンスの下にあり、同ライセンスの条項に従って商業利用が許可されています。

• スコア — Fibo 2.0はAA-Image-Editing v2.1で1,087.05 Eloを記録し、オープンウェイト中1位。LFM2.5 2.6B Baseは推定Intelligence Index 8.39、GPQA 55.8%、Terminal-Bench 2.1で4.5%、HLE 6.2%を記録しています。

これら2つのスコア行は、比較として同じ文の中に置くことはできない。一方はレンダリング画像に対する群衆選好スコアであり、もう一方はテキストベンチマークの複合スコアである。両者を誠実に用いる唯一の方法は、それぞれのモデルが何を目的としたものかを特徴づけることだ。

ベースチェックポイントとは実際には何なのか。その名前が誤解を招くからだ

LFM2.5 2.6B Base における「Base」は、「標準」を控えめに言い換えたものではない。これは、そのモデルが34兆トークンによる次トークン予測のみで学習されており、それ以外は何もしていないことを意味する——指示チューニングも、チャットテンプレートも、拒否応答も、質問が質問であるという認識もない。「Summarise this email:」と与えれば、事前学習データが示唆するスタイルでその文字列を続ける。返ってくるのは要約ではなく、メールスレッドの続きであることもある。

それゆえ、優れた出発点ではあるが、製品としては不出来だ。Liquid AI はファインチューニングを前提とする人々向けにこれを提供しており、アーキテクチャもその用途に合わせて選ばれている。30層、22のダブルゲート付きショート畳み込みと8つのグループ化クエリアテンション層、128K語彙、131,072トークンのコンテキスト、そして事前学習における16言語のカバレッジだ。畳み込みを多用したスタックのおかげでスマートフォンに収まる — アテンションのコストはコンテキストとともに増えるが、畳み込みは増えない。これが設計思想の核心だ。

• アーキテクチャ — 30層：22のダブルゲート付きショート畳み込みブロックと8つのGQAブロック、語彙数128K。

• トレーニング — 34兆トークン、16言語、事前学習のみ。

• コンテキスト — 131,072トークン。これは、畳み込みスタックが低コストで扱えるように設計された数です。

• フォーマット — GGUF、ONNX、MLX に対応しているため、llama.cpp、ONNX Runtime、Apple silicon はいずれも第一級のターゲットです。

• それがしないこと — 調整するまでは、指示に従うこと、会話をすること、テキストの続き以外のものを生成すること。

Fibo 2.0のDevチェックポイントとの比較は、一見したよりも近い。Fibo 2.0 Devもまたベースであり、非蒸留で、classifier-free guidanceを5.0で用いる50ステップ、Briaがファインチューニング用に明示的に指すチェックポイントだ。両プロジェクトとも、実用的な製品と並べて、あるいはその代わりに、チューニング対象を提供している。違いは、Fibo 2.0 Edit Turboが同じ重みの実用版として存在し、ガイダンスなしの4ステップに蒸留されているのに対し、LFM2.5 2.6Bはまったく実用になる前にチューニングしなければならない点だ。

ライセンスと「オープン」の実際のコスト

両モデルともダウンロード可能です。しかし、それらを使って何ができるかは大きく異なり、しかもその違いはサイズに関する通常の直感を覆す方向にあります。商用利用できるのは、小さいほうのモデルなのです。

• Fibo 2.0 — 非商業利用にはCC BY-NC 4.0ライセンスが適用されます。商業利用にはBriaとの別途契約が必要です。Hugging Faceのリポジトリは、企業情報と利用目的を記入するフォームによるゲート付きアクセスとなっています。

• LFM2.5 2.6B Base — LFM 1.0ライセンス。独自の条件の下で商用展開を許可します。利用ごとの個別交渉は不要ですが、条件はApache-2.0ではなく、想定するのではなく実際に読む価値があります。

• Briaの条件がそうなっている理由 — 学習コーパスは同社が資金を払ってライセンス取得した約10億枚の画像だ。無料のモデル重みがあれば、誰もがそのコーパス上でBria自身のAPIを安値で脅かせるようになり、コーパスが買い取った資産をただで手放すことになる。

• 実用上の分かれ目——社内の研究パイプラインなら、明日にでも両方を使える。出荷する製品は、LFM2.5 2.6B Base を明日にでもデバイスに組み込めるが、Fibo 2.0 は署名なしでは出荷できない。

これはBriaをけなすものではない。これは二つの問題のコスト構造だ。Liquid AIはテキストで訓練したが、その大半はライセンスが無料だ。Briaは写真で訓練したが、そのいずれも無料ではない。ライセンス条件は入力データに連動するのであって、モデルの品質に連動するのではない。そして、連動すべきなのはまさにそこだ。

両者が交わる場所：レンダリングする前に説明するオンデバイスアシスタント

これら2つのモデルが同じシステムに属するアーキテクチャが1つあり、それがこの記事を切り捨てではなく比較にしている理由です。Fibo 2.0の条件付け経路は、構造化されたJSONキャプション——VGL、BriaのVisual GenAI Language——を受け取ります。これには被写体、構図、照明、カメラ、スタイル、画像内テキストの名前付きフィールドがあります。写真を撮影するデバイス上に収まる2.6Bのテキストモデルは、ラウンドトリップなしでそのJSONをローカルに書き出せるまさにそのようなものです。

できるかどうかは、すべきかどうかとは別の問題だ。推定インデックス8.39、GPQA 55.8%、HLE 6.2%の事前学習済みベースモデルは、タスク固有のファインチューニングなしに、写真からスキーマに適合するJSONを確実に出力することはないだろう。そして、VGLコーパスでそれをファインチューニングするのは、明確に定義された小規模モデル向けの作業だ。これが、中間で落としどころを見つける議論の正直な版である。LFM2.5 2.6B Baseは、ファインチューニング済みのキャプション作成モデルにとってはもっともらしい基盤だが、既製品ではない。

• 2.6Bモデルがもたらすもの — 写真が撮影されるその場で動作し、重みは3GB未満、ネットワーク不要、呼び出しごとのコストもかかりません。

• まず必要なのは — VGL形式の例による教師ありファインチューニング、および有効な出力を保証するための制約付きデコーディングまたはJSON文法です。

• レンダラーがもたらすもの — それでもGPUは必要です。オンデバイス側が記述し、サーバー側が描画します。これが現在機能する唯一の分担です。

・このアイデアが崩れる点 — キャプションを良質にしなければならないなら、12Bクラスのマルチモーダルモデルのほうが、2.6Bのテキスト専用モデルよりも元画像をよく読み取れる。なぜなら2.6Bは写真をまったく見られないからだ。

その最後の点こそが、ほとんどの実際の設計を決着させる。LFM2.5 2.6B Base はテキスト入力・テキスト出力だ。書かれた指示から VGL キャプションを書くことはできるが、自分が説明している画像を見ることはできない。この2つを組み合わせる人は、自分が実際にどちらの仕事を買っているのかを明確にすべきだ。

それぞれを取得する

Fibo 2.0は、BriaのAPIから1画像あたり0.032ドルで、Briaのホスト型作成ツールから、ComfyUIノード経由で、あるいはHugging Face上のゲート付きウェイトとして提供されています。LFM2.5 2.6B Baseは、Hugging FaceからGGUF、ONNX、MLX形式で提供され、ベースリリースにはゲートがありません。どちらもOrcaRouterのカタログにはなく、どちらの主張も弱める必要はありません。Fibo 2.0は画像エンドポイントであり、Liquidの2.6Bベースはダウンロード可能なチェックポイントであり、ルーターはどちらもうまく扱えません。

ルーターが実際に提供するのは、モデルの周辺にあるすべてです。OrcaRouter は1つのキーで200以上のモデルを横断して利用でき、プロバイダーの定価を0%のマークアップでそのまま適用することで、テキスト側のベンダー価格変更は発生した当日に反映されます。VGL キャプションライター向けのファインチューニングパイプラインを構築しているなら、合成トレーニングペアを生成するモデルとそれらを評価するモデルの両方を、その1つのキーの背後に置け、反復中も自動フェイルオーバーを利用でき、ルーティング DSL を使えば1回の呼び出しで複数のモデルにまたがるベンチマークを展開できます。レンダラーは Bria のままです。チューニングループこそ、ルーティングが真価を発揮する場です。

決定、それは率直に述べられたもの

制約が「モデルをどこで動かすか」にあるなら、LFM2.5 2.6B Base は Fibo 2.0 と競合しているわけではない。両者のうち、そもそもデバイス上で動くのはこちらだけであり、その 8.39 という推定インデックスは、その代わりに意図的に選び取っている上限値だ。制約が「出力そのもの」にあるなら、Fibo 2.0 は両者のうち出力を生み出す唯一のモデルであり、オープンウェイトの中で 1,087 Elo というのは、ダウンロード可能な画像編集における現時点の最高水準だ。誰もこれらのモデルの間で選んでいるわけではない。選んでいるのは配備先と成果物との間であり、それらは同じ週のニュースにたまたま一緒に現れた、別種の意思決定なのだ。

唯一本当に共通する問いはライセンスであり、それは商用ビルドの両方の部分で同じように解決する。2.6Bベースはその条件の下で使用でき、8BレンダラーにはBriaの合意が必要であり、小さい方のモデルの方がより自由であるというのは、エンジニアリングではなく学習データに関する事実である。製品はパラメータ数ではなく、その点を中心に計画せよ。