トークン種別ごとの課金の仕組み

ガイド · 2026-09-06

入力、キャッシュ読み取り、キャッシュ書き込み、出力をなぜ別々の単価で数えるのか、四つのモデルが種別ごとに何クレジットを課金するのか、キャッシュ読み取りが入力の十分の一である理由、そして実際のリクエストを最後の一クレジットまで計算した例をまとめています。自分の請求書と突き合わせられる計算です。

ここに送られるリクエストはすべてクレジットで課金されますが、クレジットの数はトークンの数ではありません。トークンは四つの種別に分けて計測しています — キャッシュされていない入力、キャッシュ読み取り、キャッシュ書き込み、出力 — 提供にかかる手間がそれぞれ違うからです。単一の混ぜた単価にしてしまえば、ある利用者の安いワークロードを、別の利用者の高いワークロードの値段で請求することになります。この記事では、その種別ごとの計算を、私たち自身が公示している数字のうえで省略せずに示し、最後に実際のリクエストを一件、分解してみせます。

なぜ種別ごとに値段を分けるのか

モデルが初めて読むトークン、キャッシュされたプレフィックスから読み戻すトークン、そのキャッシュへ書き込むトークン、そしてモデルが生成するトークン。この四つは、必要な仕事の量がそれぞれ違います。高いのは生成です。出力トークンは一歩ずつ作られるもので、どのモデルでも自分自身の入力よりはるかに高い単価が付きます。安いのはキャッシュ読み取りです。その裏側の計算は前のリクエストで済んでいて、支払いも済んでいるからです。キャッシュ書き込みは上流では一切コストがかからず、それでもここでは各モデル自身の入力単価で公示しています。これはマージンですが、隠すのではなく、目に見えるところに置くほうを選んでいます。

トークンあたり一律の単価は、宣伝するには簡単で、買う側にとっては悪い買い物です。キャッシュに当たるワークロードからは取りすぎ、長い回答を生成するワークロードからは取り足りず、そして — ここがいちばん大事なのですが — 請求書を何かと突き合わせて確かめる手立てが、誰にも残りません。この最後の一点が、私たちが自分の計測に課している試験です。どの課金も、その隣にある台帳の行に保存された価格から再現できなければなりません。二つの価格を混ぜた単価は、それを仕組みとして不可能にします — 混ぜた値はどの列にも現れず、記録のどこからも計算し直せなくなるからです。ですから、ここでは何も混ぜていません。どの種別も、その種別に対して公示した単価で計測し、公示した単価がそのまま課金される単価です。

種別ごとに、トークン一つの値段

トークンあたりのクレジット数を、モデルと種別ごとに。このサイトの他のあらゆる価格と同じカタログから直接引いています。

solの入力トークン一つが一クレジットです。表全体はこの基準点に対して書かれていて、残りのすべてのセルは、その基準点に対する自分自身の比率です。行を横に読めば一つのモデルの四つの値段が分かり、入力の列を縦に読めば、性能にいくら払うことになるのかが分かります。表のどの数字も、宣伝のために丸めた数字ではありません — これらは計測がそのまま適用する係数で、ポータルはリクエストごとに、この係数に照らして明細を出します。

キャッシュ読み取りは10分の1

キャッシュされたプレフィックスから読み戻したトークンは、そのモデル自身の入力単価の10分の1で課金されます。上の表のキャッシュ読み取りの列が、モデルごとに入力の列を10で割ったものになっているのは、そのためです。この割引は、月をならした平均としてではなく、ポータルのリクエストごとに独立した一行として出ます。毎ターン同じ長いシステムプロンプトを送り直すエージェントなら、その節約が届くところをリクエストごとに眺めて、確かめられるはずです。

実際のリクエストを計算してみる

下の計算はastraでの一件です。キャッシュに何もない状態でプロンプトが303トークン、回答が14トークン。ここで使っている単価は、これを書いた日のastraのものです — 生きているのは上の表のほうで、二つが食い違ったときは表が正です。

POST /v1/chat/completions          model: astra

  種別     tokens         単価     credits
  input       303  x       2.5   =     757.5
  output       14  x      12.5   =     175.0
                                     -------
  charged                              932.5  ->  933

最後の行について、二つ。合計は種別ごとにではなく、最後に一度だけ切り上げます。種別ごとに丸めれば四回丸めることになり、その丸めの分まで請求してしまうからです。そして加算は、台帳の行そのものに保存された価格に対して、正確な整数演算で行います。ですから、計測が実際に課金した数と、行が課金したと書いている数の間に、浮動小数点のずれは生じません — あの行は手で計算し直せます。それが監査できるということです。

請求の前に予約が果たす役割

リクエストが上流へ出る前に、計測はあなたのクォータに見積もりを予約し、後で精算に使う価格を書き留めます。同時に押し寄せた複数のリクエストが、最後の同じクレジットを二度使ってしまわないのは、これがあるからです。ポータルの残高はリクエストが終わったときではなく、始まったときに動きます。ですから、いま見えている数字は、他のどのリクエストにも重ねて使えない数字です。

回答が返ってくると、予約は、プロバイダーが実際に報告した使用量に対して、予約を取った時点で記録した価格で精算されます — リクエストの途中で単価が変わっても、すでに走っているリクエストの値段が付け替わることはありません。精算が、その元になった予約を上回ることはありません。実際の費用が予約した額を超えたリクエストは、黙ってクォータをさらに削るのではなく、精算を拒否して照合待ちとして記録します。予約のうち使われなかった分は、そのまますぐに戻ります。

次に見るなら

同じ係数を、ショートとロング両方のコンテキストで、各モデルが何に向いているかと並べて置いてあるのがモデルです。プランがいくらで、クレジットとは何かはプランと料金にあります。base URLと、そのままコピーして送れるリクエストはクイックスタートにあります。

本記事は機械翻訳です。ネイティブによる確認は未了で、英語版が正本です。