トークンのコスト:モデルの価格設定の仕組み

APIを通じてモデルを使うとき、課金はリクエスト単位でも単語単位でもありません。トークン単位です。トークンはモデルが実際に読み書きする単位であり、モデルの請求でのほぼすべての驚きは、それが何で、どれに支払うのかを理解していないことから来ます。良い知らせは、価格設定モデルは、その形が見えれば単純で、ひと握りの習慣がコストを予測可能に保つことです。悪い知らせは、請求を駆動する部分が、画面に見えるテキストの中ではしばしば見えないことです。

この記事は、トークンが何か、なぜ入力と出力が異なる価格なのか、隠れたトークンがどこに潜むのか、そして何を費やすかをどう見積もり制御するかを、どのプロバイダーやモデルを使おうと変わらない原則で説明します。

トークンとは実際に何か

トークンはテキストの塊で、おおよそ一単語ですが、正確にはそうではありません。モデルは文字も完全な単語も読まず、テキストをその中間のどこかに位置する片に分けます。よくある短い単語は単一のトークンかもしれませんし、より長い、あるいは一般的でない単語は2、3に分かれるかもしれません。空白、句読点、整形も数に入ります。人々が使う大まかな目安は、トークンは平均して単語より少し短いというものですが、正確に知る唯一の方法は、モデルのトークナイザーに数えさせることです。

重要な帰結は、トークン数が長さに関するあなたの直感ときれいに対応しないことです。密度の高い、技術的な、あるいは英語以外のテキストは、平易な英語の散文より単語あたり多くのトークンを使いえます。句読点と記号を持つコードは、トークンが重くなりえます。だから「私のテキストはどれくらい長いか」は間違った問いです。「私のテキストは何トークンか」が、請求が気にする問いであり、その二つは思う以上に乖離しうるのです。

入力トークンと出力トークンは異なる価格

モデルとのすべてのやり取りには二つのトークンストリームがあり、それらはほぼ常に異なる額がかかります。入力トークンは、あなたが送るすべて、すなわちプロンプト、指示、含めた文書や例です。出力トークンは、モデルが返して生成するすべてです。プロバイダーはこの二つを別々に価格設定し、出力トークンはたいてい二つのうち高いほうです。

その理由は、生成がどう機能するかに根ざしています。入力を読むのは一回のパスです。モデルはそれをすべて取り込み、処理します。出力を生成するのは一度に一トークンずつ起き、各ステップが、それまでに生成されたすべてに依存する新たな計算です。その一歩ずつの生成こそが高価な部分であり、それが、生成された出力が、応答の元になった入力より高い価格を帯びる理由です。これを知ると最適化の仕方が変わります。長い出力は、長い入力よりも請求への大きなレバーであることがしばしばです。

請求を駆動する隠れたトークン

最もよくある請求の驚きは、あなたが一度も明示的に打たなかったトークンから来ます。三つの源が際立ちます。

第一に、再送するシステム指示とコンテキスト。 会話では、モデルはターン間で記憶を持ちません。だから連続性を保つために、アプリケーションは毎回のリクエストで、先行する会話と常設の指示を再送します。その履歴のコストは、各ターンで再び支払われます。長い会話は、伸びるにつれてメッセージあたり高価になります。新しいメッセージごとに、記録全体を入力として引きずるからです。

第二に、取得または添付したコンテンツ。 モデルに作業のための文書を与えると、それらのトークンの一つ残らずが、あなたが支払う入力です。大きな文書をプロンプトに詰め込む機能は、ユーザーの短い問いが示唆するより、呼び出しあたり静かにはるかに高くつきえます。

第三に、モデル自身の中間的な作業。 一部のモデルは最終的な答えの前に内部的な推論を生成し、その中間テキストは、ユーザーに表示されないときでさえ、たいてい課金される生成された出力です。短い目に見える答えが、はるかに大量の、支払い済みの生成の上に乗っていることがあるのです。

なぜコンテキストウィンドウがコストにとって重要か

すべてのモデルには、一度に考慮できるテキストの最大量、すなわちコンテキストウィンドウがあります。大きなコンテキストウィンドウを、何でも投げ込める無料の余地として扱いたくなりますが、ウィンドウは容量であって、予算ではありません。その中に置くすべてのトークンに、依然として支払うのです。大きなウィンドウを縁まで満たすことは、毎回の呼び出しで大きな入力に支払うことを意味します。

ウィンドウは固い上限を課します。入力プラス出力はそれを超えられません。しかし実践的な規律は、最大値よりはるかに少なく使うことです。タスクを成し遂げるために送るトークンが少ないほど、各呼び出しは安くなり、しばしばより速く返ります。大きなウィンドウは、たまの大仕事のための便利さであって、日常の仕事で無駄遣いする許可証ではありません。

支出を見積もり、制御する

出荷する前にコストを予測できます。算数は素直です。呼び出しあたりの典型的な入力トークンと出力トークンを見積もり、それぞれにその価格を掛け、期待する呼び出し数を掛けます。これを構築前に封筒の裏で行うことが、高価な設計を、まだ変えるのが安いうちに捕まえます。

走らせ始めてから支出を制御するには、いくつかの習慣がほとんどの仕事をします。送るものを刈り込む。必要のない会話履歴を落とし、長いコンテキストを逐語で再送する代わりに要約し、重要な文書だけを含めます。タスクが許すなら出力の長さに上限を設けます。出力はより高価なストリームだからです。日常の仕事には小さく安いモデルに手を伸ばし、高価なものは本当に必要とする呼び出しのために取っておきます。そして見積もりを信じるのではなく実際の利用を測りましょう。現実のトラフィックでの実際のトークン数こそが、請求を支払う唯一の数値だからです。

手早い直感の実例

サポートアシスタントを想像してください。ユーザーが一行の問いを打ちます。ごく小さな入力です。しかしあなたのシステムは、1ページの常設指示、会話の直近の数ターン、そして取得した3つのヘルプ記事も送ります。ユーザーの目に見える言葉は丸め誤差です。本当の入力は、指示、履歴、記事であり、毎ターン繰り返されます。それからアシスタントが丁寧な数段落の返信を書けば、その出力は、すべての入力を合わせたより高くつくかもしれません。呼び出しをこう見ること、すなわちコストの大半がユーザーの決して見ない場所にあること、これが洞察のすべてです。目に見える問いを最適化しても何も節約しません。目に見えないコンテキストと出力の長さを刈り込むことこそ、お金のある場所なのです。

まとめ

単語でもリクエストでもなく、トークンこそが支払うものです。そして請求を駆動するトークンは、たいてい目に見えないもの、すなわち再送される会話履歴、添付文書、常設指示、そしてモデル自身の中間生成です。入力と出力は別々に価格設定され、出力がたいてい高くつきます。大きなコンテキストウィンドウは、満たすために支払う容量であって、無料の余地ではありません。構築前に単純な算数で見積もり、送るものを刈り込み生成するものに上限を設け、実際の利用を測りましょう。トークンの価格設定は、自分が何を送っているかを正確に知る人に報い、知らない人を罰するのです。