6月29日、SitePointが「Prompt Compression and Cache Tuning: Cut Your LLM API Costs by 60%」と題した記事を公開した。LLM APIのコスト問題は「トークン経済」の問題だ。OpenAI・Anthropic・Google GeminiはいずれもAPIをトークン単位で課金しており、多くの本番システムは必要以上のトークンを消費している。その結果、請求額が本来の2〜3倍に膨らむことも珍しくない。本記事では、プロンプト圧縮・セマンティックキャッシュ・CoT剪定・出力長制約の4技術を組み合わせることで、APIコストを最大60%削減できる実践的手法が詳しく紹介されている。
まず知るべき:出力トークンのほうがはるかに高い
コスト最適化の優先順位を決めるうえで、各プロバイダーの価格構造の把握が欠かせない。
| モデル | 入力(/100万トークン) | 出力(/100万トークン) | 比率 |
|---|---|---|---|
| GPT-4o | $2.50 | $10.00 | 4x |
| Claude 3.5 Sonnet | $3.00 | $15.00 | 5x |
| Gemini 1.5 Flash | $0.075 | $0.30 | 4x |
出力トークンは入力の2〜5倍のコストがかかる。つまり、出力トークンを1つ削減するほうが、入力トークンを削減するよりコスト効率が高い。この非対称性が最適化の方針を決める。
なお、各プロバイダーはキャッシュ割引も提供している。OpenAIのプロンプトキャッシュは入力トークンを50%引き、AnthropicのPrompt Cachingはキャッシュ読み出し時に90%引き(ただしキャッシュ書き込みは25%増)、Google GeminiのContext Cachingは標準入力レートの**約25%**でキャッシュ済みコンテンツを処理する。
技術1:プロンプト圧縮(最大のコスト削減源)
プロンプトの無駄は4つのカテゴリに集中している。
- システムプロンプトの肥大化:曖昧な言い回しや過剰な例示が含まれ、プロンプト長が2倍になっていることも多い
- 会話ターンをまたいだ同一コンテキストの繰り返し送信
- 出力長の未制御:アプリケーション側で即座に捨てる説明文や前置きを生成し続ける
- 本番環境でのChain-of-Thought(CoT)推論の放置:開発時には有用だが、デプロイ後は不要なトークンを大量消費する
手動圧縮で即効果が出る3つの戦略
- ヘッジ表現・丁寧語の排除:「Please kindly ensure that you carefully consider」→「Ensure」
- 複数文の指示を構造化フォーマットへ集約:JSONスキーマを文章で説明する代わりに、スキーマそのものを渡す
- コンテキストの参照化:同じ情報をシステムプロンプトとユーザーメッセージの両方に書かない。1か所で定義してラベルで参照する
LLMLinguaによるプログラマティック圧縮
より踏み込んだ圧縮には、Microsoft ResearchのLLMLinguaが使える。小さな言語モデルを使ってトークンレベルのPerplexity(困惑度)を評価し、情報量の少ないトークンを自動的に除去する手法だ。
pip install openai "llmlingua>=0.2.2" numpy
from llmlingua import PromptCompressor
compressor = PromptCompressor(
model_name="microsoft/llmlingua-2-bert-base-multilingual-cased-meetingbank",
use_llmlingua2=True
)
compressed = compressor.compress_prompt(
original_prompt,
rate=0.4,
force_tokens=["JSON", "entities", "name", "type", "sentiment"]
)
rate=0.4を指定すると、元の約500トークンのプロンプトを約200トークンまで圧縮できる。force_tokensで重要なキーワードを保護することで、出力フォーマット要件を維持したまま圧縮できる。
注意:初回実行時にHugging Faceからモデルチェックポイント(約500MB)をダウンロードする。また、使用されているチェックポイントは会議録(MeetingBankデータセット)向けに最適化されたものであるため、自分のドメインで品質を検証してから本番投入すること。
品質の劣化も当然ありうる。エンティティ抽出や分類のような出力が狭く定義されたタスクは積極的な圧縮に向いているが、オープンエンドな推論では過圧縮が品質低下を招く。評価セットに対するF1スコアやヒューマンスコアが2〜3%以上下がれば圧縮しすぎのサインだ。
技術2:セマンティックキャッシング(同義クエリへのAPI呼び出しをゼロにする)
セマンティックキャッシングは、意味的に近いクエリに対してAPI呼び出し自体をスキップする手法だ。「今日の天気は?」と「本日の天候を教えて」は文字列として異なるが、意味は同じであるため、同じキャッシュ済み回答を返せる。
埋め込みモデルでクエリをベクトル化し、コサイン類似度が閾値(例:0.95)を超えた場合にキャッシュから返す実装が基本となる。コードで示すと以下のようなイメージだ。
import numpy as np
def cosine_similarity(a, b):
return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))
def get_cached_or_call(query, cache, embedder, threshold=0.95):
query_vec = embedder.embed(query)
for cached_query, cached_response, cached_vec in cache:
if cosine_similarity(query_vec, cached_vec) >= threshold:
return cached_response # API呼び出しをスキップ
response = call_llm_api(query)
cache.append((query, response, query_vec))
return response
閾値の設定はトレードオフになる。高すぎると誤ったキャッシュヒットが発生し、低すぎると意味的に同一のクエリでもキャッシュが使われない。頻繁に同種の質問が来るFAQシステムやカスタマーサポート用途で特に有効であり、キャッシュヒット率が高いユースケースほど削減効果は大きい。
技術3:Chain-of-Thought剪定
CoT推論(「まず〜を考えると、次に〜となり…」という思考ステップ)は開発・デバッグ時に有用だが、本番環境では最終回答だけが必要なことがほとんどだ。システムプロンプトに「Return only the final answer without reasoning steps」と明示するだけでトークン消費を大幅に削減できる。
system_prompt = """
You are a sentiment analysis assistant.
Return only the final answer without reasoning steps.
Output format: {"sentiment": "positive"|"negative"|"neutral", "confidence": 0.0-1.0}
"""
CoTを有効にしたままにすることは、出力トークンのコストが最大5倍かかる状況で不要な出費を続けることを意味する。モデルによって効果の度合いは異なるが、分類・抽出など出力が定型化されているタスクでは特に削減幅が大きい。推論ステップが品質に直結するタスク(複雑な数学・コード生成など)では、CoTを残したまま他の手法で補うほうが賢明だ。
技術4:出力長の制約
max_completion_tokens(OpenAI)またはmax_tokens(Anthropic・Gemini)でハード上限を設け、さらにJSON Schemaで構造化出力を強制することで、モデルが不要な前置きや解説を生成するのを防げる。
response = client.chat.completions.create(
model="gpt-4o",
messages=messages,
max_completion_tokens=150, # ハード上限
response_format={
"type": "json_schema",
"json_schema": {
"name": "sentiment_result",
"schema": {
"type": "object",
"properties": {
"sentiment": {"type": "string", "enum": ["positive", "negative", "neutral"]},
"confidence": {"type": "number"}
},
"required": ["sentiment", "confidence"],
"additionalProperties": False
}
}
}
)
構造化出力の強制は「フォーマットの説明文」「解説の前置き」といったトークンを根本的に排除する。OpenAIの構造化出力ドキュメントやAnthropicのtool useを活用することで、APIレベルでの保証が得られる。
4技術組み合わせ時のコスト比較
記事では5つのモデルに対して最適化前後のコスト比較が掲載されている。4技術をすべて組み合わせた場合、最大60%のコスト削減を達成できるとされているが、削減幅はユースケース・モデル選択・トラフィックパターンによって変わる。
最初に手をつけるべきは
記事は実装の優先順位を明確にしている。
- まず全APIコールにトークンロギングを仕込んでコストのベースラインを把握する
- システムプロンプトの手動圧縮(コストゼロ・即効果)
max_completion_tokensの設定(1行で実装可能)- セマンティックキャッシング(インフラ追加が必要だが効果大)
- プロバイダーネイティブのプロンプトキャッシング活用(OpenAI・Anthropic・Gemini)
- LLMLinguaによる自動圧縮(最もインパクトが大きいが実装コストも高い)
コードサンプルはPython(OpenAI SDK)とNode.js(OpenAI・Anthropic SDK)の両方で提供されており、トークン数のbefore/afterが実測値で示されている。
詳細はPrompt Compression and Cache Tuning: Cut Your LLM API Costs by 60%を参照していただきたい。