
LFM3-1.7B vs Gemma 4 26B A4B:安価なトークンを得るための2つのレシピ、そしてスマートフォンに収まるのは片方だけ
- OrcaNEWOrcaCyber: GLM 5.3 Flash Abliterated2026-10-2779 tok/s
- OrcaNEWOrcaCyber: Qwen3.8 Flash Next Abliterated2026-10-26$0.80 / $1.60 100万トークンあたり · 283 tok/s
- OrcaNEWOrcaCyber: MiMo V2.6 Flash Abliterated2026-10-26$0.80 / $1.60 100万トークンあたり · 82 tok/s
- MoonshotNEWMoonshotAI: Kimi K3.1 Pro2026-10-2455知能
- OrcaNEWOrcaCyber: DeepSeek V4.1 Flash Abliterated2026-10-23$0.80 / $1.60 100万トークンあたり · 119 tok/s
- minimaxNEWMiniMax: M3.1 Flash2026-10-1943知能
- OrcaNEWOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 100万トークンあたり · 44 tok/s
- deepseekNEWDeepSeek: DeepSeek V4.1 Flash 10172026-10-1745知能
- DeepSeekNEWDeepSeek: DeepSeek V4.1 Flash2026-10-1740知能
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 100万トークンあたり · 113 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2952知能
- anthropicAnthropic: Claude Sonnet 5.52026-09-2856知能
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 100万トークンあたり · 701 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238知能
- OpenAIOpenAI: GPT-6 Sol2026-09-2248知能
- AnthropicAnthropic: Claude Opus 5.52026-09-2258知能
- xiaomiXiaomi: MiMo-V2.6-Flash2026-09-2138知能
- xiaomiXiaomi: MiMo-V2.6-Pro2026-09-2146知能
- xAIGrok 4.72026-09-2146知能
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 100万トークンあたり · 160 tok/s
表面上、この2つのモデルは同じ問題に対して同じアプローチを取っています。LFM3-1.7BはLiquid AIが2026年10月27日に発表し、Gemma 4 26B A4BはGoogle DeepMindが2026年4月2日にリリースしました。どちらも1つの問いに答えるために存在します。つまり、能力の高いモデルを小さなメモリ予算にどう収めるかという問いです。両者は正反対の答えを出しています。Liquidはモデルを小さくしました。Googleはモデルを大規模なまま保ち、トークンごとにその一部のコストだけを支払います。重みは無料なので、請求額は最も安価で有能なホストが請求する金額になります。当社はプロバイダーの定価を0%のマークアップでそのまま提供しています。
この違いは、デプロイのコストを見積もるまではアーキテクチャの豆知識のように聞こえるが、その時点ではそれが唯一重要なことになる。Gemma 4 26B A4Bはトークンあたり38億のパラメータを活性化するが、それでも252億のパラメータをどこかに保持しなければならない。LFM3-1.7Bは17.3億のパラメータすべてを活性化し、ちょうどその数だけを保存する。一方は計算コストが安い。もう一方は所有。
安価なトークンのための2つのレシピ
Gemma 4 26B A4Bは専門家混合(MoE)モデルです。128のルーティングされる専門家に加えて1つの共有専門家があり、30層で、トークンあたりおよそ8つの専門家が発火します。これにより、25.2Bの密モデルに相当する知識容量を持ちながら、演算コストは4Bに近いものになります。Google自身の説明では、稠密なGemma 4 31BのMMLU-Proスコアの約97%に、およそ12%のFLOPsで到達するとされています。
LFM3-1.7Bは別の道を選んでいます。完全に密なモデルで、すべてのパラメータがすべてのトークンで動作し、節約はスパース性ではなく再設計されたアーキテクチャから生まれます。Liquidのトライハイブリッドスタックは24層で、13のゲート付きショート畳み込み、5つのスライディングウィンドウアテンション層、6つのフルアテンション層で構成されています。系列モデリングの大部分は安価な畳み込みが担い、フルアテンションは6回しか登場しません。こうして1.73Bモデルは、KVキャッシュがマシンを圧迫することなく、262,144トークンのコンテキストと128,000トークンの語彙を扱えます。
• 総パラメータ数 — LFM3-1.7Bは1.73B、Gemma 4 26B A4Bは25.2B。
• トークンあたりのアクティブ — 1.73B 対 約3.8B。両者が同じ土俵にあるのはこの行だけです。
• 4ビット時のメモリ — 約1 GB 対 約18 GB。この行がデプロイを左右する。
• コンテキスト — 両方とも262,144トークンで、今回も文字どおりの引き分けです。
• モダリティ — テキストのみ、およびテキストと画像入力に対応し、ネイティブな関数呼び出しと設定可能な思考モードを備えています。
• ライセンス — LFM Open License v1.0、年間収益1,000万ドル未満は無料。Gemma 4 26B A4Bはしきい値なしのApache 2.0です。
なぜ3.8Bアクティブが3.8Bのメモリを意味するわけではないのか
これは mixture-of-experts の仕様表を読むときの最もよくある誤解なので、はっきり言っておく価値がある。アクティブパラメータが左右するのは計算量であり、おおまかには速度だ。ダウンロードするファイルのサイズや確保するVRAMの量を左右するものではない。Gemma 4 26B A4B は、エキスパート間のルーティングを行うために252億個のパラメータすべてを常駐させる必要があり、4ビットでは約18GBになる。24GBのカード1枚で動かすことはでき、GoogleはFP8およびNVFP4のビルドを提供してそれを実用的にしているが、スマートフォンに載せることはできない。
LFM3-1.7Bは4ビットで約1GB — Liquidの製品カードには、スマートフォンやラップトップに収まると書かれており、そのサイズならこの主張はマーケティングではなく信憑性がある。また、128Kトークンで1.6GBのKVキャッシュを保持する。これは、同時に保持できる長文コンテキストのリクエスト数を実際に左右する数値だ。
実用上の帰結はこうだ。26B-A4Bのデプロイは推論サーバーに関する判断であり、1.7Bのデプロイはアプリケーションの出荷に関する判断である。これらは異なるチームと異なるコスト構造を持つ別々のプロジェクトであり、両者の隔たりを埋めるベンチマークは存在しない。

各ベンダーが公開した内容と、そこから読み取れること
GoogleはGemma 4 26B A4Bについて広範な表を公開した:MMLU-Proで82.6、GPQA Diamondで82.3、ツールなしのAIME 2026で88.3、LiveCodeBench v6で77.1、Codeforces Eloは1718、MMMU-Proで73.8、128K・8ニードルでのMRCR v2で44.1。すべてベンダー報告であり、独立に再現されたものはない。第三者による追跡では、そのLMArena Eloは1438近辺とされる。
LiquidはLFM3-1.7B向けに、より限定された表を公開しており、その内容はエージェント的な作業に寄っています。BFCL V4で71.39、ToolSandboxで80.36、τ³-benchで68.01、LiveClawで45.60、WebArena-Verifiedで38.42です。また、IFEvalで96.66、IFBenchで73.03、GPQA Diamondで63.37、LiveCodeBench v6で73.46、128KでのRULERで65.56も報告しています。LiquidはLFM3-1.7BについてMMLU-Proの数値を公開しておらず、その欠落はゼロを意味するものではなく、単に測定されていないだけです。
LiveCodeBench v6とGPQA Diamondだけがきれいに重なる。Gemma 4 26B A4Bは両方で勝利し、その差はそれぞれ3.6ポイントと18.9ポイントだ。Liquidのスイートがエージェント系に移る領域では、比較できるGemmaの数値はない——Googleはτ²-benchを68.2と報告しており、τ²はτ³ではない。だからそこに68.01を並べるのは、慎重な比較の装いをした捏造の比較になる。
1.7Bが会話の中でどこにとどまるか
LiveCodeBenchの3.6ポイント差は、14対1というパラメータ比から予測されるよりも小さい。その理由はアーキテクチャにある。競技プログラミングは、パターンを保持し、正しい関数を出力する能力を評価する——これは生の容量よりも、クリーンな学習シグナルから恩恵を受けるスキルだ。もしコーディング問題だけが仕事なら、26Bが勝ち、このセクションは短く済んだだろう。
LFM3-1.7Bが実際に存在感を保っているのは、262,144トークンのコンテキストと1 GBのフットプリントの組み合わせだ。大きな文書を保持し、それを読んでいるデバイス上で実行できるモデルは、同じ文書をサーバー上で保持できるモデルとは別の製品である。Liquidは128KでRULERの65.56を報告している。これは目覚ましい長文コンテキストのスコアではない——Gemma 4 26B A4Bは同じベンチマークファミリーで81.4を報告している——が、それでも1ギガバイトでオンデバイスにおいて実際に測定されている。
また、指示追従に関してもこの小型モデルは見劣りしない。{{1}}IFEval で 96.66{{/1}}、{{2}}IFBench で 73.03{{/2}} というのはこのサイズクラスとしては強い数値であり、いずれもベンダー報告値だ。ツール呼び出しや構造化出力のワークロードでは、それは {{3}}GPQA Diamond{{/3}} よりも、重要となる指標に近い。

ルーティング層が実際に変えるもの
Gemma 4 26B A4B は OrcaRouter のカタログに掲載されています — 1 つの API キーで、200 を超える他のモデルと並んでこれにアクセスできます。プロバイダーの定価は 0% のマークアップでそのまま適用されるため、ベンダーの価格変更は再価格設定サイクルを待たずに当日反映されます。これはここでは通常以上に重要です。なぜなら、このモデルの経済性は完全にプロバイダー価格にかかっているからです。重みは無料なので、請求額は有能な最安ホストが請求する額次第であり、その数字は変動します。
自動フェイルオーバーはもう一方の半分だ。256Kコンテキストを持つ26BのMixture-of-Expertsモデルは、ピーク時に容量の壁にぶつかるまさにそういう種類のワークロードであり、複数プロバイダーにまたがるルーティングは、1台のホストの不調な午後があなたのサービス停止にならないことを意味する。LFM3-1.7Bにはこうしたものは一切不要だ。なぜなら、あなたが管理するハードウェア上で動作し、フェイルオーバー元となるプロバイダーが存在しないからだ。これはLFM3-1.7Bの賛成材料でも反対材料でもない — もう一方のレシピを選んだ結果にすぎない。
私たちの役割を率直に言えば、私たちは大規模なスパースモデルをルーティングしますが、小規模なデンスモデルは提供しておらず、両者のどちらを選ぶかはルーターがあなたに代わって決められることではありません。
一度で決定する
デプロイ対象のメモリが20 GB未満の場合——スマートフォン、ラップトップ、Jetson、AI PCなど——Gemma 4 26B A4Bは候補にならず、比較はそこで終了です。LFM3-1.7Bを採用し、Liquid自身が指摘する知識ギャップを中心に検索を計画し、その数値が真に競争力を持つツール呼び出しと構造化抽出に使用してください。
GPUから配信していて、ワークロードが知識集約型、マルチモーダル、あるいは82.3のGPQA Diamondや82.6のMMLU-Proクラスの推論を必要とするものであれば、Gemma 4 26B A4Bのほうが優れたモデルであり、その18 GBが参入コストとなります。Apache 2.0はライセンスに関する議論を完全に不要にするため、大規模組織にとってはそれはベンチマークの数ポイントよりも価値があります。
両方に提供する製品——難しいクエリをサーバーにエスカレーションするオンデバイスアシスタント——を作っているなら、両者はまったく競合ではありません。それらは1つのアーキテクチャの2つの階層であり、興味深いエンジニアリング上の問いは、どのモデルが表で勝つかではなく、エスカレーションの境界線をどこに引くかです。

未解決の問いは能力ではない。それはGoogle有利で決着済みだ。問いは、1GBモデルと256Kコンテキストが、ほとんどのオンデバイス製品が実際に必要とする狭いエージェント向けタスクに十分適しているかどうかである。Liquid自身のモデルカードは、これが推論モデルではないと異例なほど率直に認めている。その率直さはLiveCodeBenchの差よりも価値がある。なぜなら、ワークロードのどちらの半分をどこへ送るべきかを教えてくれるからだ。
