大規模モデル API のトークンと課金：概算、読み方、予算と計算例

トークンとは何か、および課金の計算方法

トークンはモデルがテキストを処理する最小単位であり、文字でも単語でもなく、それらの間の「断片」です。これを水道メーターの目盛りと想像してください：使用量が増えるほど、目盛りは速く動きます。課金は2つの部分に分かれます。

出力単価が入力の4倍である点に注意してください。そのため、モデルに「無駄話を減らさせる」方が、あなたに「コンテキストを送らない」よりも節約になることが多いですが、会話シーンでは入力履歴が膨張するため、両方を管理する必要があります。課金方法はサブスクリプションではなく前払い残高で行われ、残高は期限切れになりません。新規アカウントには $0.50 の無料トライラルクレジットが用意されており、7日間の有効期限があります。

混同しやすい点として、出力トークンはモデルが実際に生成した数であり、あなたが設定した max_tokens ではありません。max_tokens は単なる上限であり、モデルが200文字で回答を完了した場合、その200文字に対応するトークン数でのみ課金されます。しかし、予算予測を行う際は、最悪のケースに備えて上限で計算し、予期せぬ長い出力に備える必要があります。

事前概算：中文と英文のそれぞれの概算方法

リクエストを送信する前では概算しかできません。以下はすべて近似値であり、コンテンツによって変動します：

見積もりを正しく使うには「桁数の判断」をすることです：この文章はトークンが約1万個か10万個か、100,000のコンテキストウィンドウを超えるかどうか、1回の呼び出しで数銭かかるか。正確に知るにはusageを読み取ります。良い習慣として、各ビジネスシナリオで数十回のサンプル実行を行い、usageの平均値を統計して、経験値に代えます。

見積もりと実測を組み合わせる例を挙げます。2000字程度の中国語顧客フィードバックを処理すると仮定します。1文字あたり1.3トークンで概算すると、1件あたり約2600トークン、指示に200トークン加えて入力は約2800トークンになります。まず30件を実行してusageを読み取り平均を求めます。実測平均が2500だった場合、係数を約1.15に修正します。その後、バッチ全体の予算は修正後の係数で計算し、誤差は大幅に小さくなります。この実測値は手法を示すための仮定であり、あなたのデータには独自の数値があります。

usage の読み方：本当の「メーター読み」

成功したレスポンスには常に usage が含まれ、prompt_tokens、completion_tokens、total_tokens の3項目が含まれます。ストリーミングレスポンスでは追加パラメータは不要で、最後に自動的に usage を含むデータチャンクが追加されます。以下のコードは両方の読み方を示し、読み取り値をドルに換算します：

复制import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])
PRICE_IN, PRICE_OUT = 0.25, 1.00     # 美元 / 百万 token

def cost(u):
    return (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1_000_000

# 非流式：usage 在响应对象上
r = client.chat.completions.create(
    model="uncensored", max_tokens=200,
    messages=[{"role": "user", "content": "用三句话解释什么是通货膨胀。"}],
)
print(r.usage.prompt_tokens, r.usage.completion_tokens, f"${cost(r.usage):.6f}")

# 流式：最后一个数据块带 usage，其余块的 usage 为空
usage_last = None
stream = client.chat.completions.create(
    model="uncensored", max_tokens=200, stream=True,
    messages=[{"role": "user", "content": "再用三句话解释什么是通货紧缩。"}],
)
for chunk in stream:
    if chunk.usage:
        usage_last = chunk.usage
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()
if usage_last:
    print(usage_last.prompt_tokens, usage_last.completion_tokens, f"${cost(usage_last):.6f}")

ストリーミング時は留意が必要です：usage が含まれるのは最後のチャンクだけで、それ以前のチャンクでは空です。そのため、if chunk.usage で判断するだけで十分です。読み取り値をログやデータベースに記録し、月末の請求書確認、異常の調査、ユーザー単位の費用計算に役立ててください。

さらに推奨される習慣として、各ビジネス機能にタグを付け、記録時に一緒に記録することです。例えば「要約」「カスタマーサポート」「翻訳」などをそれぞれ記録し、月末に請求書を確認することで、どの機能が最も費用がかかっているかが分かり、プロンプトの最適化、履歴の切り捨て、または max_tokens の引き下げが必要かどうかを判断できます。タグがなく合計数しかない場合、最適化のしようがありません。

3つの計算例（仮定条件は明記済み）

計算例1：カスタマーサポートのQ&A

仮定：1回のリクエストで入力800トークン（systemプロンプトとナレッジフラグメントを含む）、出力200トークン。1日10,000回。

1回あたりの費用：入力 800 × 0.25 ÷ 1,000,000 = $0.0002、出力 200 × 1.00 ÷ 1,000,000 = $0.0002、合計 $0.0004。1日 $4.00、30日で $120。この速度で計算すると、$0.50の試用クレジットは約1,250回の呼び出しに耐えられます。

計算例2：長文の要約

仮定：1記事あたりの入力20,000トークン、要約出力600トークン。合計500記事。

1記事あたり：入力 20,000 × 0.25 ÷ 1,000,000 = $0.005、出力 600 × 1.00 ÷ 1,000,000 = $0.0006、合計 $0.0056。500記事で合計 $2.80。長い入力と短い出力のタスクは非常に安価であることがわかります。

計算例3：マルチターンチャットと履歴の切り捨て

仮定：system 100トークン。1ターンあたりユーザー入力60トークン、応答150トークン。1つの会話で20ターン。

全履歴方式の入力は、20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3,200 + 39,900 = 43,100です。切り捨て方式の最初の3ラウンドはそれぞれ160、370、580で、第4から第20ラウンドはラウンドごとに790、合計14,540です。費用は約半分異なります。ラウンド数が増えるほど差が広がるのは、全履歴方式の入力がラウンド数の二乗に比例して増加するためです。

これらの3つの例から、コストは主に「リクエスト数 × 1回あたりの入出力量」で決まり、1回あたりの入力量では、履歴と付随資料が最も調整の余地がある部分であるという経験則が導けます。カスタマーサポートでは知識フラグメントの長さを短くし、チャットでは履歴を切り捨て、要約ではバッチ処理で並列実行する—all同じ理屈です：不要なトークンに無駄な料金を払わないことです。強調すべきは、これら3つの計算例の数字はすべて上記の仮定に基づくものであり、実際のデータはusageを基準にすることです。

逆算の例を見てみましょう：月間予算が$30の場合、20ターンのチャットが月間いくつ持つかを知りたいとします。計算例3の「直近3ターンのみ」パターンでは、1会話あたり約$0.0066なので、$30 ÷ 0.0066 で約4,545会話。同じ予算で全履歴パターンを使うと、1会話あたり$0.0138で約2,174会話しか持たず、これが履歴切り捨ての実際の差です。

予算管理：プログラムにゲートを設置する

見積もりは予測に過ぎず、ゲートこそが保険です。以下はドルベースの日間予算クラスです：リクエスト前に「最悪の場合」で予測（出力はmax_tokensを最大に設定）、リクエスト後に実際のusageで精算します。

复制class Budget:
    """按美元计的日预算。超出时拒绝新请求。"""
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def check(self, est_prompt_tokens, max_tokens):
        # 最坏情况：输出用满 max_tokens
        worst = (est_prompt_tokens * 0.25 + max_tokens * 1.00) / 1_000_000
        if self.spent + worst > self.limit:
            raise RuntimeError(f"预算不足：已用 ${self.spent:.4f}，本次最坏 ${worst:.4f}，上限 ${self.limit}")

    def record(self, usage):
        self.spent += (usage.prompt_tokens * 0.25 + usage.completion_tokens * 1.00) / 1_000_000

budget = Budget(daily_usd=5.0)
budget.check(est_prompt_tokens=1200, max_tokens=500)   # 请求前
# ……发请求……
# budget.record(response.usage)                        # 请求后

プログラム内のゲートに加え、3つの設定レベルの手段があります：

1. max_tokensはタスクに合わせて設定し、一律で最大にしない。デフォルトは2048、最大は32,000。
2. 会話履歴に長さの上限を設定する。チャットボットの構築の手法を参照。
3. アカウントには計画使用分のみチャージし、使い切ったら補充する。プリペイドモードは元々ハードな上限となる。

単価と残高のルールは価格ページに従い、APIの詳細はパラメータ解説を参照。

最後にチェックリストにまとめます：事前には、見積もり、max_tokensの設定、履歴長さの確認。事中には、ストリーミング出力時に最後のブロックのusageに注意。事後には、精算と機能ごとの分類、予算との比較。この3ステップで、帳簿は明確になります。