キャッシュトークン

ローカライゼーションエンジンがテキストを翻訳する際、LLM に送るプロンプトには、毎回同じ部分と、リクエストごとに変わる部分があります。プロンプトキャッシュを使うと、エンジンはその固定部分を毎回あらためて処理するのではなく再利用できます。再利用されたトークンは使用量に cache tokens として表示され、通常の入力トークンよりはるかに低いコストで扱われます。

翻訳プロンプトの仕組み#

エンジンがモデルに送る各リクエストは、複数のレイヤーを重ねて組み立てられます。同じエンジンとロケールのすべてのリクエストで共通する固定レイヤーもあれば、リクエストごとに変わる動的なレイヤーもあります。

固定レイヤーは、プロンプト先頭の連続したプレフィックスを構成します。エンジンはそのプレフィックスの終端を cache breakpoint としてマークします。ここまでの部分はキャッシュして再利用でき、それ以降の部分 — リクエストごとの用語集、例、入力テキスト — は毎回新しく送信されます。

キャッシュ済み入力のほうが安い理由#

特定のエンジンとロケールに対する最初のリクエストでは、固定プレフィックスがプロバイダのキャッシュに 書き込まれます。その後、このプレフィックスを再利用する各リクエストでは、最初から再処理する代わりにキャッシュから 読み出されます。プロバイダはこのキャッシュ読み出しを通常の入力トークン単価の一部で課金するため、変わらないプロンプトの大半を、毎回フル価格で再課金されずに済ませられます。

キャッシュは短時間だけ保持され、エンジンではなくモデルプロバイダによって管理されます。つまり恩恵が最も大きいのは、同じエンジンとロケールで短時間に多くの翻訳を行うケースです。プレフィックスがまだ温まっている間にリクエストが到着すれば、キャッシュからそのまま読み出されます。

ruleset や brand voice を編集するとプレフィックスが変わるため、次のリクエストでは新しいプレフィックスが作成されます。どちらも組織で管理・共有されているため、1回の編集で、それらを適用しているすべてのエンジンのプレフィックスが無効になります。

得られるメリット#

• コスト削減 — 固定プレフィックスは最初に一度だけフル価格で支払われ、その後の繰り返しリクエストでは、毎回割安なキャッシュ読み出し料金が適用されます。
• 応答時間の短縮 — キャッシュされたトークンは再処理が不要なため、ウォーム状態のリクエストはより速く返ってきます。
• 設定不要 — キャッシュはデフォルトで有効になっており、エンジン設定で何かをオンにする必要はありません。

この効果は、同じエンジンとロケールに対して継続的にトラフィックが流れるほど大きくなります。まさに本番のローカライゼーションパイプラインのように、同じ設定で次々とリクエストを処理するケースにぴったりです。

使用量で cache tokens を確認する#

各翻訳レスポンスには、cache tokens と新規入力を分けた使用量の内訳が含まれます。

{
  "usage": {
    "inputTokens": 1200,
    "outputTokens": 800,
    "cacheReadTokens": 950,
    "cacheWriteTokens": 0
  }
}

エンジンとロケールに対する最初のリクエストでは、通常、正の cacheWriteTokens（プレフィックスが書き込まれている状態）と、cacheReadTokens が 0 で表示されます。キャッシュがまだ温まっている間の後続リクエストでは、これが反転し、cacheReadTokens が増え、cacheWriteTokens は 0 まで下がります。エンジン全体のトークン使用量は、Reports でまとめて確認できます。

次のステップ#