計測と決済
トークン数はどこから来て、どう相互検証され、売り手がそれを捏造できないのはなぜか。
課金の根拠になる数字は、上流プロバイダーが報告した使用量です。以下の仕組みはすべて、その数字がそのまま決済に届くことを保証するために存在します。
3 つの情報源
| 情報源 | 用途 |
|---|---|
上流応答から取り出したプロバイダー自身の usage | 価格の根拠。 これが事実です。 |
| ゲートウェイ側の出力トークン推定 | 相互検証と上限 |
| ゲートウェイ側のプロンプトトークン推定 | 相互検証と上限 |
推定はヒューリスティックです——文字クラスによる重み付けであって、ベンダーのトークナイザーではありません。桁違いの異常値を捕まえるためのものなので、許容幅は意図的に広く取ってあります。
相互検証
報告値と推定値を、入力側と出力側それぞれで比較します。25% を超える乖離は売り手の信用スコアに記録されます。金額は変わりません。
キャッシュ読み取りは入力側に数えるため、キャッシュヒットの多いセッションが乖離と誤判定されることはありません。
上限
こちらは金額を変えます。
- 出力は承認された予算で頭打ち。 すべての配信には署名付きの予算が付いており、売り手がそれを超える出力分を請求することはできません。
- プロンプトはゲートウェイ推定の 3 倍で頭打ち(または推定値 + 1,000 トークンの大きい方)。超えた場合は 4 種すべてを比例縮小するので、トークン種別間の比率は保たれます。
小さなリクエストに 900 万トークンを報告した売り手は上限値で決済され、記録にリスクイベントが残ります。
決済
リクエストごとに 1 つのデータベーストランザクション。
- 凍結分を確定する
事前に凍結した額を確定し、差額を利用可能残高へ戻します。
- 実在する額で頭打ちにする
請求額が「凍結 + 利用可能」を超えることはありません。残高がマイナスになることはありません。
- 資金を動かす
あなたから引き落とし、売り手の未払いに価格から 8% を引いた額を加え、手数料はプラットフォーム口座へ。
- 元帳に書く
複式簿記 3 行。合計はゼロでなければなりません。
- タスクを閉じる
トークン数・金額・手数料・レイテンシをリクエストに書き込み、一意キー付きの決済行が二重課金を不可能にします。
トランザクションが失敗した場合はバックオフ付きで再試行されます——盲目的な再実行ではありません。一意キーがあるため、繰り返しは二度目の課金ではなく何もしない操作になります。
自分で突き合わせる
売買双方がローカルに記録を持ち、どちらもサーバーの記録と比較できます。トークン数は一致するはずです。食い違った場合、決済に使われたのはサーバー側の数字です——ローカルの記録は監査用であり、課金には関与しません。
クライアントと Web サイトの 履歴 は同じデータです。