本記事では、Gemini を API で利用する際のコストを節約するための手法をまとめています。主には Vertex AI からの利用を想定していますが、多くは Google AI Studio などでも使える手法です。
背景
Gemini をはじめ多くの LLM は、入出力の Token 数に応じた従量課金モデルとなっているため、特に大規模に利用している場合はコストが気になることが多いと思います。
Gemini にはコンテキストキャッシュ保存 という機能など、コストを削減する手法は幾つかありますが、あまり体系的 / 網羅的に整理されているコンテンツがなかったので、今日時点の機能をベースに、自分が知っている手法をまとめていきます。
コストの考え方
従量課金モデルの場合、基本的には以下の数式が成り立つので、量か単価、このどちらかを減らすしかありません。
Gemini API 費用 = 入出力の Token 量 x Token あたりの単価
なお、入出力で Token 単価が異なることを鑑みると、Gemini API 費用 = (入力 Token 量 x 入力単価) + (出力 Token 量 x 出力単価) のように表現したほうが厳密かもしれないですが、いずれにせよ、"量か単価を減らす"というアプローチは変わらないので、上記のように一旦表現しました。
また、ものによっては例えば"サブスクを利用することで、IDE 呼ぶコード生成の API Call の料金をカバーする" などの考えもあるとは思いますが、ここではあくまで従量課金をベースとした Gemini API 費用に着目していきます。
入出力の Token 数 をコントロールする
入力 Token 数のコントロール
入力量の事前確認
countTokens API を利用することで、入力 Token 数を事前確認できます。
例えば、Cloud Storage などの外部のデータソースから動画を取得して Request を生成しているケースなど、気づかぬうちに入力トークンが膨大になっている可能性がある場合は、投げる前に一度確認するステップをいれておくと安心です。
なお、Vertex AI Studio など GUI から操作をしている場合は、GUI 上に入力トークンが表示されますが、それを API で行っていることになります。
メディアの解像度を指定する
Gemini 3 以降であれば、メディアの解像度 (media_resolution) を指定することができます。
例えば費用とレイテンシが最優先で、メディアの詳細な解像度がそれほど重要でないケースには、この設定を低く (MEDIA_RESOLUTION_LOW) することで、入力トークン数の節約をすることができます。
これを指定しない場合のデフォルト値を見てみると、意外と高めに設定されていることもポイントです。
Tuning を利用
例えば毎回プロンプトに回答のサンプルを大量に投入している場合などは、Tuning を利用することで、毎回の入力プロンプトを軽くすることができます。場合によっては推論のレイテンシも下がるという副次的な効果も得られます。
ただし、Tuning 自体にもコストはかかるので、プロンプト量や呼び出し回数を元に見極めは必要です。
(非公式) フォーマットの変更
例えば、プロンプトの中で構造化データを扱う場合、JSON ではなく CSV で扱うと、トークン数が削減できることはご想像いただけるかと思います(キーが毎回登場しなくなるため)。ただし、このような方式でトークン数を減らすことは、情報量を減らしていることにも繋がるので、精度とコストのトレードオフの見極めは必要です。
こちらの記事では、フォーマットに合わせた精度と Token 数の関係が調査されており、例えば Markdown-Table などを使うとコストと精度のバランスが上手くとれるのではないか、というような調査結果もあがっています。
出力 Token のコントロール
maxOutputTokens の指定
maxOutputTokens を指定することで、出力の長さを指定することができます。出力は基本的に入力よりも単価が高いので、出力についてもしっかりコントロールしておくことが重要です。
思考の制御
Gemini 2.5 以降のほとんどのモデルでは思考 (Thinking) が利用できるのですが、思考の過程で生成された出力には、出力の単価で料金が発生します。そのため、意図せず思考を利用している場合は注意が必要です。
Gemini 3 以降は Thinking Level, Gemini 2.5 以前は Thinking Budget を使ってこの思考の深さをコントロールすることができます。精度とコスト/応答速度のバランスを見ながら、これらの値を調整することが重要です。
なお Gemini 3 では Thinking Level / Thinking budget の両方を利用できますが、前者が推奨で、両方指定してしまうとエラーになるのでご注意ください。
Token あたりの単価をコントロールする
適切なモデルの選択
Gemini は各バージョンで複数のモデルを提供していることが多く、例えば Gemini 2.5 であれば Pro / Flash / Flash-light を提供しています。名前の通り、最も高性能かつ単価が高いのが Pro で、順に性能は少し下げつつも単価が安くなっていきます。
この単価の差は大きく、Gemini 2.5 の入力の場合だと、Pro に対して Flash は 76% off, 92% off になります(キャッシュなし、20 万入力トークン以下の場合)。
そのため、やりたいタスクに対して適切なモデルを選択することは、コスト最適化においても重要になります。
キャッシュを利用する
Vertex AI の Gemini の料金表を見てみると、"キャッシュ入力トークン" という列があります。この"キャッシュ"が利用できると、大幅に入力の単価を下げることができます。例えば Gemini 3 Pro の場合、入力トークンに対する単価が 90% offになります。
キャッシュには 2 種類あるので、それぞれ説明していきます。
※ なおここでのキャッシュは、通常のアプリケーションのキャッシュとは違って、レスポンス速度を高める文脈では役に立ちません。あくまでコストを下げるための機能です。
暗黙的キャッシュ
暗黙的キャッシュ (Implicit Caching) はその名の通り、特に利用者側が意識をしなくても活用されている機能です。
例えば類似したリクエストを短い期間の間に繰り返し行っている場合、この暗黙的キャッシュが裏でヒットし、キャッシュ利用の料金が入力に対して適用されています。
このキャッシュ ヒットの可能性を高めるには、以下が今日時点のドキュメントに記載されています。
- 大規模で一般的なコンテンツは、プロンプトの先頭に配置します。
- 類似した接頭辞を含むリクエストを短時間で送信しようとする
なおモデルごとに、キャッシュが保存/利用される最小トークン数が決まっていることには注意が必要です。キャッシュが活用できているかどうかは、レスポンスオブジェクトの usage_metadata から確認することもできます。
明示的なキャッシュ
明示的なキャッシュ (Explicit Caching) は、暗黙的キャッシュのようにある種の運任せ(Google にキャッシュするコンテンツは任せる) の類のものではなく、明示的にキャッシュしたい内容を事前に保存し、それを明示的に指定して利用するための機能です。
ただし、キャッシュに保存した場合は保存量に応じてストレージ料金がかかるので、呼び出し回数や入力量に応じた見極めが必要です。
ドキュメントにもユースケース例がありますが、例えば長時間の動画ファイルを繰り返し分析するケースなどに適しています。
API の呼び方を変える
Gemini を呼び出す際、ユースケースに合わせて複数の呼び出し方を選択できます。通常の呼び出し方に加え、現時点で提供されている 2 つの手法を解説します。
バッチ推論
バッチ推論を使うと、例えば Gemini 3 では入出力のトークン単価を 50% off にできます。
バッチ推論は非同期処理を前提としており、目標処理時間は 24 時間です。即時レスポンスが必要のない分析用途などで、コストを下げながら活用したい場合などで有効です。
ただし、上で紹介した明示的なキャッシュ保存とは併用ができないなどの制約には注意が必要です。
なお、コストからは逸れますが、1 回のバッチで数十万件のリクエストができるなど、レート制限が通常よりも高いこともバッチ推論を利用するメリットです。
Provisioned Throughput
Provisioned Throughput は、事前に Generative AI Scale Unit（GSU）という処理能力を購入しておく料金モデルです。利用に応じた従量課金ではなく、この購入した GSU に対して、入出力のトークンがバーンダウン(消費)される仕組みをとります。誤解を恐れずいうと、BigQuery の Reservations と似たような考え方です。
また、現時点で Preview ですが、コンテキストキャッシュと組み合わせることができ、バーンダウンの量を削減することもできます。
ただし、基本的にはある程度の利用があるケースでの活用が想定されており、1 GSU を年契約する場合は月額 $2,000 がミニマム構成となります。ミニマムが安くないのでコスト削減と紐づけづらいかもしれないですが、常にアクセスがあるケースなどではトータルコストを安く抑えられる可能性もあります。
なお、Provisioned Throughput はコスト削減の観点だけではなく、スループットの保証、コストのコントロール(従量課金を避けたいケースなど)、リージョンの固定などの目的でも活用される機能です。
まとめと宣伝
Gemini を API で利用する場合に、コストを削減するための手法について紹介しました。
#X でも Google Cloud の発信を行っているので、是非フォローお願いします！ (x.com/ShoheyOkada)
Discussion