SubQ Snap 1.1 対 LFM2.5 2.6B Base：その判断を買うか、チェックポイントから構築するか

の比較で最も重要な単語はSubQ Snap 1.1 と LFM2.5 2.6B Base最後の単語です。Base は事前学習済みという意味です。つまり Liquid AI が、約34兆トークンの学習を終えた後、教師ありファインチューニング、蒸留、強化学習によって言語モデルを指示に従うものに変える前の段階で、そのチェックポイントを公開したということです。質問には答えません。ラベルを選ぶこともありません。サポートチケットの振り分けを頼むと、学習したテキストのスタイルでプロンプトを続けます。これはバグではなく、ベースチェックポイントの目的そのものです。

SubQ Snap 1.1は、対照的に、完成品です。Subquadraticの意思決定モデルで、2026年10月22日にリリースされ、最大384Kトークンのテキストと画像、さらに固定の回答セットを受け取り、較正済みの選択肢を返します。両者を代替案であるかのように直接対決させるのはカテゴリーエラーであり、しかもそれは有益なエラーです。なぜなら、そのエラーは、自らが管理するハードウェア上で動作する分類を求めるチームが直面する判断そのものだからです。問いは「どちらのモデルが優れているか」ではありません。「その判断を買うのか、それとも出発点から自分で作るのか」です。

Liquid AIが実際に出荷したもの

LFM2.5-2.6B Baseは、ポストトレーニング済みの兄弟モデルであるLFM2.5-2.6Bとともに2026年8月4日に登場しました。2億3000万パラメータから24BのMixture-of-Expertsまでを展開するファミリーの一員です。アーキテクチャはLiquidのLFM2設計で、30層のうち22層が二重ゲート付き短畳み込みブロック、8層がGrouped-Query Attention層で、語彙数は128,000トークン、中間学習の拡張フェーズで128Kコンテキストウィンドウが追加されています。26.9億パラメータで約2.5ギガバイトに収まり、Apple M5 Maxでは毎秒約220トークン、Ryzen AI Max+では約113トークン、スマートフォンでは約30トークンで動作します。

instruct版の兄弟モデルにこそ、興味深い数値がある。ポストトレーニングがどれほどの価値を持つかを測る指標として読む価値がある。LiquidはAIME25を51.87、LiveCodeBench v6を59.41、IFBenchを59.17、Multi-IFを80.07、BFCLv4を56.88、ToolSandboxを77.83と報告している。いずれもベンダー報告で、すべてポストトレーニング済みモデル上の数値だ。ベースチェックポイントには比較可能な指示追従スコアがない。指示に従えないからだ。チェックポイントと、質問を投げかけられるモデルとの間のこの差は、4つのポストトレーニング段階からなる。2回の教師ありファインチューニング、ドメインごとの教師特化、マルチドメインのオンポリシー蒸留、そして実際のハーネス内でのエージェント型強化学習だ。

Liquidはまた、このモデルが何に向いていないかも率直に述べている。エージェント型コーディングと、知識集約型の作業だ。これはほとんどのラボが公表するより正直なポジショニングステートメントであり、額面通りに受け取る価値がある。

仕様を並べて比較

• 概要 — LFM2.5 2.6B Base は指示チューニングされていない事前学習済みチェックポイントであり、SubQ Snap 1.1 は固定回答APIを備えたホスト型意思決定モデルです。

• コンテキスト — LFM2.5 2.6B Base は 128K トークン、Snap 1.1 は 384K トークン。

• 入力 — LFM2.5 2.6B Base はテキストのみ、Snap 1.1 はテキストと画像。

• 出力 — LFM2.5 2.6B Base の場合は自由形式のトークン生成、またはその上に学習させる任意のヘッド。Snap 1.1 の場合は確率付きの選択肢またはスコア。

• 価格 — LFM2.5 2.6B Base はセルフホスト専用で、トークンごとの課金なし。Snap 1.1 は入力100万トークンあたり0.04ドル、出力は無料。

• ライセンス — {{1}}LFM Open License v1.0、収益しきい値付きで商用利用可{{/1}}、Liquidモデル向け。Snapにはウェイトが一切ありません。

• フットプリント — LFM2.5 2.6B Base は約2.5 GBでスマートフォン上で実行可能、Snap 1.1 はネットワーク呼び出しが必要。

チェックポイントと分類器の間のギャップ

LFM2.5 2.6B Base を、Snap 1.1 が実現していることを行うものに変えるには、5つの要素が必要で、そのうちモデルは1つだけです。

ラベル付きデータが必要だ。狭いルーティングタスクなら、クラスごとに数千例が妥当な出発点であり、クラスが不均衡だったり境界が微妙だったりするなら、かなり多くの例が必要になる。学習実行も必要だ。指示を一度も見たことのないベースチェックポイントの上に分類ヘッドまたはLoRAアダプタを載せるので、ファインチューニングはタスク適応と指示追従の両方を同時に行うことになる。キャリブレーションも必要だ。softmaxスコアはキャリブレーションされた確率ではなく、未キャリブレーションのスコアで設定したルーティングしきい値は推測で決めたしきい値にすぎないからだ。トラフィックの変化に伴ってモデルはドリフトするので、自分で保守する評価ハーネスも必要だ。そしてサービング基盤も必要だ——llama.cpp、MLX、vLLM、ONNXはいずれもこのアーキテクチャをサポートしている。

そうしたものは何一つ珍しいことではない。どれも、何をしているか分かっている人による数週間の作業であり、タスクが変わるたびに繰り返される。誠実な比較は、100万トークンあたり0.04ドル対無料ではない。100万トークンあたり0.04ドル対4〜8週間のエンジニアリング、さらにモデルを所有し続けるコストなのだ。

ライセンスはApacheではありません

LiquidはLFM2.5をLFM Open License v1.0の下で提供しています。商用利用は認められていますが、年間収益が1,000万ドルを超える組織には別途商用ライセンスが必要です。これはGraniteのApache 2.0やGemmaのApache 2.0とは実質的に異なる条件であり、プロトタイプが動いた後に法務部門が遅れて発見する類の条項です。閾値を下回るスタートアップであれば、現時点ではコストはかかりませんが、将来コストが生じる可能性があります。閾値を超える場合は、GPUの価格を見積もる前にライセンスの価格を見積もってください。

ベースチェックポイントが完全に勝利する場面

エアギャップ環境への導入は最も有力な用途であり、それは僅差ではない。ネットワーク経路のない電話、ノートPC、コンテナ上で動作する2.5ギガバイトのモデルは、現場アプリケーション、機密環境、顧客に出荷されるデバイスにとって唯一の選択肢である。Snap 1.1はそのいずれにも入り込めない。APIであり、ローカルで動作するバージョンは存在しない。

ボリュームの経済性は2つ目のケースだが、効いてくるには実際のボリュームが必要だ。月200万件の意思決定があり、それぞれに20,000トークンのコンテキストが付く場合——入力トークンは400億——Snap 1.1のコストは月1,600ドル、年換算で2万ドル弱となる。そのトラフィックを、すでに所有しているハードウェア上で単一のファインチューニング済み2.6Bモデルが処理するなら、限界費用はゼロだ。損益分岐点は、年間のAPI請求額がファインチューニングのエンジニアリング費用とハードウェア費用を上回るあたりにあるが、ほとんどのチームにとってそれは1か月先ではなく1〜2年先だ。

完全な制御が3つ目です。自分のラベルで学習させたモデルは、学習させたことだけを実行し、それ以外は行いません。Snap 1.1は汎用意思決定モデルで、Artificial Analysis Decision Index v1.0における精度は20%です。そのインデックススコア65は主に、答えられない事項について回答を控えることによるもので、報告されている非ハルシネーション率は86%です。あなたのドメインでファインチューニングした2.6Bモデルは、あなたのタスクでその精度をしばしば上回り、そうするように学習させない限り決して回答を控えません。

Snap 1.1 が完全に優位に立つ点

最初の判定までの時間は分単位で測られ、スプリント単位ではない。収集すべき学習データも、適合させるべきヘッドも、描くべきキャリブレーション曲線もない。文書と選択肢リストを送れば、確率が返ってくる。そしてその確率こそが成果物だ。

長いコンテキストは2つ目の違いであり、それは偶発的なものではなくアーキテクチャに由来するものである。Snapは、トークンあたりの計算量を一定に保ったまま、単一のフォワードパスで384Kトークンを処理する。LFM2.5 2.6B Baseは128Kのウィンドウを持ち、26億パラメータのモデルとして、その実効的な検索範囲は公称値よりもかなり短くなるだろう——Liquid自身の兄弟モデルはAA-Omniscienceスコア−29.50を報告しており、これは小規模モデルがどれだけ「知っているか」を測る指標であって、どれだけうまく「読めるか」を測るものではないが、期待の基準にはなる。

第三に、Snapの出力はすでに必要なものそのものです。パーサーもスキーマも、不正な形式の回答に対するリトライ処理も不要です。

じゃあ、どれ？

長い文書に対するルーティングや分類の判断で、データをネットワーク外に出せ、この四半期にその機能を必要とするなら、Snap 1.1 を購入すべきです。自前で構築する道は現実的ですが、ほとんどのチームにとって初年度に安くなるわけではなく、ベースチェックポイントはそのための最も難しい出発点です。通常は事後学習済みの LFM2.5-2.6B から始めてそこからファインチューニングするのであって、Base から始めるのではありません。

Base checkpoint は、ネットワークが届かない場所にモデルを置く必要がある場合、または重みを恒久的に所有し、それだけの価値があると判断できるエンジニアリング能力がある場合に選んでください。その場合は、トレーニングの実行だけでなく、ライセンスの問題にも予算を確保してください。

どちらも OrcaRouter のカタログにはなく、今後も加わりません。LFM2.5 2.6B Base はローカルチェックポイントであり、Snap 1.1 は console.subq.ai の Subquadratic API を通じてのみ提供されます。どちらかを軸に構築したパイプラインで OrcaRouter が担うのは、意思決定をアクションに変える層です——1つのキーで200以上の生成モデル、プロバイダーの定価を0%のマークアップでそのまま反映、そして自動フェイルオーバーにより、一時的に利用できないモデルにルーティング呼び出しが到達しても、リクエストの取りこぼしにならないようにします。意思決定レイヤーと執筆レイヤーは障害モードが異なります。同じ依存関係に置かないほうがよいでしょう。

注目に値するのは、どちらかのモデルのベンチマーク行ではない。それは、数千件のドメイン例で微調整した26億パラメータのチェックポイントが、チームが実際に抱える一つのタスクで専用設計の意思決定モデルに匹敵できるかどうかだ。狭く、十分にラベル付けされた分類では、答えは歴史的にイエスであり、それが、ここでの購入か内製かという問いが修辞ではなく真に開かれている理由である。