Gemma 4 26B ローカル vs API：2GBのセットアップ、速度、コスト

TL;DR

TurboFieldfare は、共有コンポーネントと 4K の KV キャッシュをメモリに常駐させつつ、ルーティングされたエキスパートを SSD からストリーミングすることで、実行時メモリ約 2GB でテキスト専用の Gemma 4 26B を動作させたと報告している。これは Apple Silicon 向けの特殊な低メモリ構成であり、Gemma 4 26B の普遍的な最小要件ではない。

Gemma 4 26B A4B は総計 25.2B パラメータの Mixture-of-Experts（MoE）モデルで、トークンあたり約 3.8B パラメータがアクティブになる。Google は Gemini API を通じて、モデル ID gemma-4-26b-a4b-it でホスト提供も行っている。

TurboFieldfare は、共有モデルコア、KV キャッシュ、直近で使用したエキスパートのみをメモリに保持して常駐メモリを削減する。その他のルーティング対象エキスパートは、各トークン生成時に SSD から読み込む。

報告された 2GB の結果には以下の制限がある。

• 4K の KV キャッシュを使用しており、モデル本来の 256K コンテキストウィンドウは使用していない。
• ローカルのモデルインストールには約 14.3GB の SSD ストレージが必要。
• パフォーマンスは SSD 速度、キャッシュ挙動、Apple Silicon のハードウェアに依存。
• 現時点のランタイムはテキスト推論のみをサポート。

ローカル実行はオフライン利用、オンデバイスのプライバシー、ハードウェア制御を目的としている。Google のホスト API はテキストと画像入力、マネージドなインフラ、容易なスケーリングを提供する。

本ガイドは 2GB 構成を説明したうえで、メモリ、速度、コンテキスト、プライバシー、プロダクション対応、総コストの観点でローカル推論と Google の API を比較する。

Gemma 4 26B API vs Local at a Glance

公式の Gemma 4 モデルカード によれば、26B A4B 変種は 128 のルーティングエキスパートを持ち、トークンあたり 8 のルーティングエキスパートをアクティブ化し、共有エキスパートを 1 つ含む。

Quick Background on Gemma 4 26B A4B

Gemma 4（~2026 年 4 月に Google DeepMind から Apache 2.0 で公開）には、密モデル（E2B、E4B、12B、31B）と、この Mixture-of-Experts（MoE）変種がある。総計約 25.2B パラメータだが、トークンあたりアクティブなのは約 3.8B（A4B）。各トークンを少数のエキスパート（通常は 128 中 8 + 共有 1）へルーティングする。これにより、31B 級の品質に近い性能を、実質 4B クラスの計算コストで達成し、256K のコンテキストウィンドウとマルチモーダル（テキスト + 画像）をサポートする。

重要な区別点: すべての約 26B パラメータは、ルーティングのために「利用可能」である必要がある。通常のランタイム（Ollama、llama.cpp、LM Studio、vLLM など）は、量子化済み重みの全体を RAM/VRAM にロードする。

What Does the 2GB Local Gemma 4 Claim Mean?

2GB の結果は、Apple Silicon 向けに Gemma 4 26B A4B 専用で構築された独立プロジェクトの Swift/Metal ランタイム TurboFieldfare によるもの。

TurboFieldfare はローカルのモデルインストール全体をユニファイドメモリに保持しない。1.35GB の共有モデルコアと FP16 の KV キャッシュをメモリに置き、必要なルーティングエキスパートをトークン生成ごとに SSD からストリーミングする。

同プロジェクトは以下のリファレンス構成を報告している。

これらは Google の公式ベンチマークではなくコミュニティのランタイム測定値である。プロンプト長、生成長、SSD 性能、エキスパートキャッシュ挙動、ハードウェア構成などが結果に影響する。

正確な要約は次のとおり。

TurboFieldfare は、量子化済みのテキスト専用 Gemma 4 26B A4B 構成を、ルーティングエキスパートを SSD からストリーミングすることで、重みと 4K KV キャッシュを合わせて約 2GB のメモリで実行している。

次のように要約すべきではない。

Gemma 4 26B は 2GB の RAM だけでよい。

この短い主張は、14.3GB のストレージ要件、限定的なコンテキスト設定、SSD 依存、量子化方式、macOS や他アプリが必要とするメモリを見落としている。

What Standard Local Inference Actually Requires

Google は従来型の Gemma 4 26B A4B 推論における概算メモリ要件を以下のとおり公開している。

これらの数値にはモデル読み込み時の 20% 程度のオーバーヘッドが含まれる。推論フレームワーク自身のメモリや KV キャッシュは含まれない。

最新の公式推定値は、Google の Gemma 4 モデル概要とメモリ表 を参照。

How Does 2GB Compare with Standard Memory Requirements?

TurboFieldfare が常駐メモリを大きく下げられるのは、量子化モデル全体を常駐させないためである。具体的には次を組み合わせている。

1. 4 ビットのモデル重み
2. 有界なインメモリのエキスパートキャッシュ
3. ルーティングエキスパートの SSD バックドストリーミング
4. 公開構成では 4K の KV キャッシュ
5. Swift と Metal によるカスタム推論カーネル

これは、従来の完全常駐デプロイとは異なるトレードオフをもたらす。

完全常駐の Q4 モデルはメモリを大きく要するが、ストレージからエキスパートデータを繰り返し読み込む必要がない。TurboFieldfare はメモリ圧を下げる一方で、SSD 帯域、キャッシュヒット、コンテキスト長、ハードウェア世代に性能がより依存する。

これはモデルが MoE だからこそ成立する。密モデルでは各フォワードパスで全重みが関与するため、この手法は有効ではない。これはアーキテクチャの特性を利用したエンジニアリング上の工夫であり、モデルサイズが本質的に小さくなったわけではない。低 RAM の Mac でバッチ/非同期作業には実用的だが、最も遅いハードウェアでのリアルタイムチャットには向かない。現状では Mac/Apple Silicon 限定かつモデル特化である。

Can the 2GB Configuration Use the Full 256K Context Window?

公式の Gemma 4 26B A4B モデルは最大 256K トークンのコンテキストウィンドウをサポートする。しかし約 2GB の TurboFieldfare 構成は 4K の KV キャッシュを使用する。

これは別の指標である。

• 公式のモデル能力: 最大 256K トークン
• 公開されたローカルメモリ結果: 4K の KV キャッシュ
• 実用的なローカルコンテキスト: 利用可能メモリ、ランタイム設定、プロンプト長、許容レイテンシで決まる

KV キャッシュは、プロンプトと生成レスポンスが長くなるほどメモリ使用が増える。ローカル構成を 32K、128K、256K 方面へ拡張するほどメモリ使用は増え、プレフィル時間や生成速度にも影響し得る。

長文ドキュメント分析を評価するチームは、2GB の結果がモデルのフルコンテキストにそのまま当てはまると仮定せず、実際の目標コンテキストでテストすべきである。

How Fast Is Gemma 4 26B on Apple Silicon?

TurboFieldfare は 2 つのリファレンス・デコード速度を報告している。

• 8GB M2 MacBook Air: 5.1–6.3 トークン/秒
• 24GB M5 Pro: 31–35 トークン/秒

これらはローカル推論がハードウェアに強く依存することを示す。普遍的な性能保証として扱うべきではない。

Estimate Maximum Monthly Output

最大月間出力トークン数 = デコードトークン/秒 × 60 × 60 × 24 × 30

報告されたデコード速度を用いると:

これらはデコードのみの理論値である。実アプリケーションではさらに以下に時間を要する。

• プロンプトのプレフィル
• リクエストのキューイング
• モデルの読み込みと再起動
• 失敗や拒否された応答
• OS の活動
• 監視と保守
• 計画済みおよび計画外のダウンタイム

例えば、4 百万トークンの出力を 5.1 トークン/秒で生成するには、連続デコードで約 9.1 日を要する。2,000 万トークンの出力には約 45.4 日を要し、1 台の M2 で 30 日の月内にこなすのは不可能となる。

したがって現実的なローカルコストモデルは、固定ハードウェアコストだけでなくスループット能力も考慮する必要がある。

Is There an Official Gemma 4 26B API?

Yes.

Google は Gemini API を通じて Gemma 4 26B へのホストアクセスを提供している。公式モデル ID は次のとおり。

gemma-4-26b-a4b-it

このホストエンドポイントは、テキスト生成、画像理解、システム指示、設定可能な思考モード、関数呼び出し、マルチターン会話をサポートする。これは、重みのダウンロードや推論サーバーの運用なしにモデルを評価する最速の方法である。

最新の実装例は、Gemma on the Gemini API ドキュメントに記載されている。

Call Gemma 4 26B with Python

Google の Gen AI SDK をインストール:

pip install -U google-genai

Gemini API キーを環境に設定してからリクエストを送る:

from google import genai

client = genai.Client()

response = client.models.generate_content(
    model="gemma-4-26b-a4b-it",
    contents="Explain mixture-of-experts routing in simple terms.",
)

print(response.text)

この例は基本的な API アクセスを確認するものであり、プロダクションのクォータ、レイテンシ、長コンテキスト性能、またはアプリケーションのデータ取り扱い要件を検証するものではない。

How Much Does the Gemma 4 26B API Cost?

Google は現在、Gemma 4 の入力、出力、コンテキストキャッシュを Gemini API のフリーティアとして掲載している。有料の Gemma 4 ティアは現時点で未掲載。

フリーティアにおけるデータ通知: フリーティア経由で送信されたコンテンツは、Google 製品の改善に使用される可能性がある。機密情報、規制対象データ、顧客所有データは、該当するデータ利用・保持条件をチームで確認するまで送信しないこと。

価格に関する注意: フリーティアアクセスは、恒久的なプロダクション価格コミットメントとして扱うべきではない。可用性、クォータ、データ条件、有料ティアの選択肢は変更され得る。

プロダクション判断前に、公式の Gemini API 料金ページを確認すること。

現在の価格は次のような特異な比較を生む。

• 公式 API はフリーティアの範囲内では直接のトークン費用がかからない場合がある。
• ローカル推論にはプロバイダへのトークン料金はないが、ハードウェア、電力、ストレージ、保守、エンジニアリング工数がかかる。
• サードパーティのホスト提供者は、キャパシティ、価格、保持ポリシー、商用条件が異なる場合がある。

Gemma 4 26B そのものについては、Google の公式 Gemma on the Gemini API ドキュメントを参照し、Gemini API 料金ページで最新の制限を確認すること。

CometAPI では現時点で Gemma 4 26B は利用可能モデルとして掲載されていない。ホストされた Gemini の代替を評価したいチームは、Gemini 3.6 Flash、Gemini 3 Flash など、CometAPI の Google モデルカタログで現在掲載されているモデルを確認できる。

Is Local Gemma 4 Cheaper Than the API?

現行の価格では、Gemma 4 がフリーティアで利用可能なため、直接的な金銭コストの観点では公式の Gemini API の方が安価な可能性がある。

ただし、トークン単価は意思決定の一部に過ぎない。

Example Local Hardware Cost

例えば、チームが $1,200 の Apple Silicon マシンを購入し、24 ヶ月で償却するとする。

月次ハードウェア償却 $1,200 ÷ 24 ヶ月 = 月 $50

このマシンが月 400 万出力トークンを生成できた場合:

100 万出力トークンあたりのハードウェア償却 $50 ÷ 4 = $12.50 / 1M 出力トークン

この計算自体は正しいが、完全な総コスト見積もりではない。以下を除外している。

• 電力
• SSD の摩耗と交換
• セットアップとエンジニアリング工数
• 監視と保守
• 失敗生成とリトライ
• 人手による確認
• 予備キャパシティ
• ダウンタイムとフェイルオーバー
• マシンを推論に使用する機会費用

また、このハードウェアが所定の運用ウィンドウ内で目標トークン量を生成できることを前提としている。

Compare Cost per Accepted Task

より有用なローカルコストの式は次のとおり。

受理タスクあたりのローカルコスト = ハードウェア償却

• 電力
• ストレージと保守
• エンジニアリング工数
• 失敗生成とリトライ
• 人手による確認 ÷ 受理タスク数

有料のホストサービスでは:

受理タスクあたりのホストコスト = 入力トークン課金

• 出力トークン課金
• キャッシュ、ツール、リクエスト課金
• リトライ
• 人手による確認 ÷ 受理タスク数

最も低い公称トークン価格が、常に最も低いアプリケーションコストを意味するとは限らない。応答が遅い、構造化出力が無効、リトライ率が高い等の経路は、受理結果あたりのコストが高くなり得る。

Can the Local OpenAI-Compatible Server Be Used in Production?

TurboFieldfare には以下で待ち受ける実験的な OpenAI 互換サーバーが含まれている。

http://127.0.0.1:8080/v1

Chat Completions、ストリーミング、関数定義、プロンプトプレフィックスの再利用をサポートする。しかし、リモート認証や TLS を提供しないため、サーバーはループバックインターフェース上に留めるべきとされている。

既定ではローカル開発用エンドポイントとして扱うべきである。

プロダクション配備では、以下を備えた追加のサービング層が必要となる。

• 認証と認可
• ホスト外に出るトラフィックのための TLS
• リクエストと出力サイズの制限
• キューイングと同時実行制御
• プロセス監督と自動再起動
• モデルの稼働確認
• メモリプレッシャーの監視
• SSD とエキスパートキャッシュのメトリクス
• レイテンシとスループットの監視
• プライバシー配慮のロギング
• 過負荷対策
• ローカル障害時のフォールバック経路

ローカルサーバーはモデル生成のツール呼び出しを返すことがあるが、アプリケーション側で各アクションを検査・承認・実行する必要がある。モデルにツールを直接実行させるべきではない。

Gemma 4 26B については、Google の Gemini API が公式のホスト経路である。アプリケーションが他のホストモデルも併用する場合、CometAPI クイックスタートは、対応モデルを OpenAI 互換インターフェースで接続する方法を示している。これは別のホストフォールバックを提供し得るが、ライブカタログにモデルが表示されない限り Gemma 4 の CometAPI 経路として提示すべきではない。

Gemma 4 26B Deployment Decision

API (hosted, Gemini API, others)

• 価格の目安は $0.07 / 1M 入力、$0.30–0.34 / 1M 出力（プロバイダにより変動/やや高い場合あり）。
• ハードウェア/セットアップコストがゼロ、高速・高スループット、スケール容易、マルチモーダルとフル機能が利用可能。

• 継続的なトークン課金、データが手元を離れる、レート制限/クォータ、レイテンシのばらつきの可能性。

Standard local

• 一度きりのハードウェア + 電力コスト。プライバシーとオフライン機能。
• 十分な RAM/VRAM（通常 18–32+ GB 可用）を要するか、低速化やスワップを受け入れる。

• フルコントロールでセットアップ後はトークン課金なし。ただし量子化、サービング、アップデート、ハードウェア管理が必要。

TurboFieldfare-style local

• 通常は動かせないマシン（8 GB Mac でも）で 26B MoE のフル機能を動かせる。
• プライバシー/オフライン + 限界費用ほぼゼロだが、十分な GPU や良好な API と比べると遅い。現状は Mac のみでテキスト中心、専用ランタイムを要する。

Use a Hybrid Route When:

• プライベートなワークロードをローカルに留めたい。
• パブリック/バーストトラフィックにホスト容量が必要。
• アプリケーションにフェイルオーバーが必要。
• タスクにより適したモデルが異なる。
• 統一 API で経路比較を行いたい。

A simple decision path is:

Must the workload remain offline or on-device?
├── Yes → Test the local Apple Silicon runtime
└── No
    ├── Need image input or fast setup? → Start with the Gemini API
    ├── Need paid capacity or an SLA? → Evaluate hosted providers
    └── Need privacy plus burst capacity? → Use a hybrid route

Official API vs Local vs Third-Party Hosting

サードパーティ経路を選ぶ前に、対象モデルが実際に利用可能かを必ず確認すること。Gemma 4 26B は、他プロバイダが同一モデル ID を明示的に掲載していない限り、Google の公式 Gemini API を通じてアクセスすべきである。他のホスト Gemini モデルについては、CometAPI の Google モデルカタログで現時点の対応状況を確認し、CometAPI ドキュメントで OpenAI 互換エンドポイント経由の呼び出し方法を参照できる。

ハイブリッド配備は、長期的に最も実用的な設計になり得る。プライベート/オフラインのテキストタスクはローカル推論、迅速なマルチモーダル評価は公式エンドポイント、プロダクションのキャパシティやフェイルオーバーにはホスト経路を使い分ける。

How to Evaluate Gemma 4 26B API vs Local

同一ワークロードをすべての配備経路で実行する。

実践的な評価セットの例:

1. コーディング、抽出、変換タスクを 10 件
2. 客観的な答えを持つ推論タスクを 5 件
3. 異なるコンテキスト長での長コンテキストタスクを 5 件
4. 画像対応の経路では画像理解タスクを 5 件
5. クライアント側承認つきの関数呼び出しタスクを 5 件
6. 厳密な JSON 検証を要する構造化出力タスクを 5 件

記録する項目:

• 最初のトークンまでの時間
• 完了までの総時間
• プロンプトのプレフィル時間
• デコードのトークン/秒
• ローカルのピークメモリ
• SSD 読み込みバイト数
• キュー待ち時間
• 同時実行の挙動
• コンテキスト長
• 構造化出力の有効性
• ツール呼び出しの有効性
• 受理タスク率
• 人手での修正時間
• 失敗とリトライ率
• ローカルの運用コスト
• ホストのトークンやリクエスト課金

同一のプロンプトテンプレート、出力上限、温度、受理基準を用いること。

短いローカルのテキスト要求と長いホストのマルチモーダル要求を比較し、それを直接的なモデルベンチマークとして提示してはならない。

FAQ

Is There an Official Gemma 4 26B API?

Yes. Google は Gemini API を通じて、モデル ID gemma-4-26b-a4b-it の Gemma 4 26B を提供している。テキスト生成、画像入力、システム指示、設定可能な思考モード、関数呼び出し、マルチターン会話をサポートする。

Is the Gemma 4 26B API Free?

Google は現在、Gemma 4 の入力、出力、コンテキストキャッシュを Gemini API のフリーティアとして掲載している。有料の Gemma 4 ティアは現時点で未掲載。フリーティアのコンテンツは Google 製品の改善に利用され得るため、機密情報を送信する前に該当条件を確認すること。

Can Gemma 4 26B Really Run in 2GB of RAM?

TurboFieldfare は、重みと 4K KV キャッシュで約 2GB と報告している。セットアップ全体では 8GB の Apple Silicon Mac、約 14.3GB のストレージ、SSD バックドのエキスパートストリーミングが依然として必要である。

Does the 2GB Configuration Support 256K Context?

モデルは最大 256K トークンをサポートするが、公開された 2GB のローカル結果は 4K の KV キャッシュを用いている。より長いローカルコンテキストには、追加メモリと性能検証が必要。

Is Local Gemma 4 Cheaper Than a Hosted API?

保有ハードウェアで継続的なテキストワークロードを回すなら安価になり得るが、スループット、稼働率、電力、保守、リトライ、出力品質に依存する。公式 API が現状フリーティアで利用可能なため、ローカル配備が自動的に最安とは限らない。

Final Recommendation

TurboFieldfare の約 2GB 構成は、Gemma 4 26B の普遍的なメモリ要件ではなく、Apple Silicon 向けの特殊な配備手法である。KV キャッシュを抑え、ルーティングエキスパートを常駐させず SSD からストリーミングすることで成立している。

多くのユーザーにとって実用的な選択肢は次のとおり。

1. コストとプライバシーが許せば、利便性と速度で API を使う。
2. 24 GB+ のメモリがあれば標準的なローカル量子化版を動かす。
3. 制約のある Apple Silicon ハードウェアで 26B MoE の品質を狙うなら TurboFieldfare（または将来の類似エンジン）を使う。

プロダクションのワークロードでは、同一のプロンプト、コンテキスト長、出力上限、受理チェックで両経路を比較する。最終判断は、品質、レイテンシ、プライバシー、達成可能なスループット、受理タスクあたりの総コストに基づくべきであり、2GB という見出しだけで決めるべきではない。