利益:
- トークンの概念、入出力トークンの区別、トークン化について説明します。
- トークン数と単価からリクエストのコストや月々の作業量を計算できる
- モデルの選択とプロンプトの長さがコストに与える影響を比較できます
LLM API の経済性を理解していなければ、大規模なソリューションを構築することはできません。デモは 1 回実行されます。重要なのは、月に数千件の通話が行われたときに請求額がいくらになるかを予測できることです。この単元では、トークンとは何か、入力と出力の価格が異なる理由、リクエストのコストの計算方法、毎月のワークロードの予算の立て方など、お金の側面を設定します。この情報を使用すると、後続のユニットでの最適化手法 (キャッシュ、モデル選択、バッチ) の効果を測定できます。
トークンとは何ですか?
トークンは、モデルがテキストを処理する最小単位です。単語は必ずしもトークンであるとは限りません。トークンは通常、単語の一部です。大まかに言うと、英語では 1 トークン ≈ 4 文字 ≈ 0.75 単語です。トルコ語とコードでは、この比率は異なります。トルコ語の単語は、接尾辞の構造とアルファベットの関係で、英語よりも多くのトークンに分割されることがよくあります。したがって、トークンの数を目で推測するのではなく、プロバイダーのトークンカウントツールを使用して測定する必要があります。
トークン化 (テキストをトークンに分割するプロセス) はモデルごとに異なる場合があります。これには 2 つの実際的な影響があります。(1) 同じテキストでも、異なるモデルでは異なる数のトークンが生成される可能性があります。 (2) 他のプロバイダーのトークナイザー (OpenAI の tiktoken ライブラリなど) で行われた予測は、Claude については不正確になります。使用しているモデルのトークン カウンティングのヒントを使用してください。
ヒント: 「トークンは何枚くらいですか?」質問に盲目的に答えないでください。トークンカウント API を介して代表的なテキストを渡します。測定に基づいて予算を決定します。
入力トークンと出力トークン
請求書は次の 2 つの項目で構成されます。
- 入力トークン: モデルに送信するもの - システム プロンプト、過去のツアー、ユーザー メッセージ、ドキュメント (存在する場合)。これらはすべて一度に処理されます。
- 出力トークン: モデルによって生成された応答。出力トークンごとに、モデルは段階的に計算を実行します。
ほとんどのプロバイダーでは、出力は入力よりも数倍高価です。理由は簡単です。出力トークンをトークンごとに生成するよりも、入力を一度に読み取る方がコストが低いからです。この非対称性を知ることで、「簡潔な回答を要求する」などの最適化がなぜ非常に効果的であるのかが説明されます。
サンプル価格 (100 万トークンあたり、米ドル)
以下の表は参考値です。価格は時間の経過とともに変更される可能性があります。ご自身のプロバイダーの現在のリストをご確認ください。
モデルクラス
サンプルモデル
インプット ($/100万)
生産高 ($/100万)
一般的な使用法
速い/安い
俳句 4.5
1.00
5.00
分類、表示、簡単なまとめ
バランスのとれた
ソネット5
3.00
15.00
汎用、コーディング、エージェント業務
強い
オーパス 4.8
5.00
25.00
複雑な推論、長期にわたるタスク
各クラスでは、出力は入力の 5 倍になります。さらに、強力なモデルの入力でも、安価なモデルの5倍の入力があります。これら 2 つの軸 (入力↔出力とモデル クラス) がコスト決定の枠組みを形成します。
コストを計算するにはどうすればよいですか?
式は簡単です:
コスト = (入力トークン / 1,000,000) × 入力価格 + (出力トークン / 1,000,000) × 出力価格
サンプルアカウント。 Sonnet 5 によるリクエスト: 1,500 入力トークン、400 出力トークン。
インプット = 1,500 / 1,000,000 × 3.00 = 0.0045 ドル アウトプット = 400 / 1,000,000 × 15.00 = 0.0060 ドル 合計 = 0.0105 ドル (約 1 セント)
1回の通話は安く見えます。ただし、ボリュームを乗算すると、1 日あたり 20,000 件の通話 → 1 日あたり 210 ドル、月額最大 6,300 ドルになります。ここでスケールが重要になります。
月次予算テンプレート
ワークロードの月額コストを抽出するには、次のテンプレートを使用します。
1) リクエストあたりの平均入力トークン: ......2) リクエストあたりの平均出力トークン: ......3) 1 日あたりのリクエスト数: ......4) 1 か月あたりの作業日数: ......5) リクエストあたりのコスト = (1)/1M×input_price + (2)/1M×output_price6) 月額コスト = (5) × (3) × (4)
このパターンをスプレッドシートに注ぎ込み、モデルを変更したときに合計がどのように展開されるかを確認すると、モデルの選択 (ユニット 5) とキャッシュ (ユニット 6) の決定が具体化されます。
コピー可能なテンプレートを使用してプロンプトを短縮する
コストのほとんどは、不必要に長いプロンプトと無駄な出力によって発生します。以下のテンプレートは直接的な節約を提供します。
# 出力の長さを制限します。最大 3 項目でお答えください。根拠や紹介文を追加します。
# 要求されたフィールドのみを返します。次の JSON のみを返します。他のテキストは追加しないでください:{"category": "...", "urgency": "low|medium|high"}
# 不要なコンテキストを削除します。次のテキストから日付と金額のみを削除します。テキスト全体を繰り返さないでください。テキスト: """{{text}}"""
# 長いスピーチを要約する（入力節約） このスピーチを5つの項目に要約します。今後のラウンドでは、過去全体の代わりにこの要約を使用します。スピーチ: """{{過去}}"""
弱いプロンプト / 強いプロンプト (コストの点で)
# WEAK (リリース出力、高価) このサポート リクエストを分析し、包括的なレビューを書いてください。
# STRONG (出力を制限し、安価で予測可能) このサポート リクエストを分類します。次の JSON を返すだけです:{"category":"invoice|technical|refund|other","urgency":"low|medium|high"}説明は書かないでください。
弱いバージョンでは、おそらく 500 個の出力トークンが生成されます。強力なバージョン ~15。出力にはコストがかかるため、これはコールごとに大きな違いとなり、量に応じて倍増します。
ミニケース3個
ケース 1 — 長いプロンプトの隠れたコスト。会計自動化が各請求書をソートすると、各リクエストへの入力として 40 ページの「ルールブック」が追加されました。リクエストごとに最大 12,000 個の入力トークンが追加されました。 Sonnet 5 では 12,000/1M×3 = $0.036 が入力されたばかりです。 1日5,000枚→1日180ドル。ルールブック (ユニット 6) をキャッシュすることにより、入力コストが最大 90% 減少しました。
ケース 2 — モデルのダウンサイジングによる効果。あるチームは、Opus 4.8 を使用して単純な「ポジティブ/ネガティブ」センチメント タグ付けを行っていました: 300 個の入力トークン + 10 個の出力トークン。オーパスのコストは 300/1M×5 + 10/1M×25 = $0.00175 です。 Haiku に切り替えると、300/1M×1 + 10/1M×5 = $0.00035 — 5 倍安くなり、精度の差は計り知れません。 1 か月あたり 300 万回の通話の場合、その差は 5,250 ドル → 1,050 ドルになります。
ケース 3 — 出力を解放します。マーケティング チームが製品説明を作成するとき、出力に制限はありませんでした。モデルは時々 1,500 トークンと言っています。 「最大 60 ワード」命令を追加すると、平均出力は 900 トークンから 90 トークンに減少しました。印刷代が高かったので月々の料金が3分の1に減り、テキストがより便利になりました。
よくある間違い
- トークンを目で推測する: 特にトルコ語とコードでは間違う可能性があります。測定。
- 入力と出力が同じであると仮定すると、通常、出力の方がはるかに高価になります。最適化のほとんどは、出力を短縮することによって行われます。
- 1 回の通話の安さに騙されないでください。決定は量によって行われます。 0.01 ドル × 100 万 = 10,000 ドル。
- 別のプロバイダーのトークナイザーを使用した予測: 間違った結果が得られます。モデルのトークンカウントツールを使用します。
- 会話履歴の無制限の拡大: 各ラウンドがエントリに追加されます。長い会話で要約します。
- 「max_tokens」を不必要に高く維持すると、予算計画と削減のリスクが隠蔽されます。現実的な値を指定してください。
より深い: コンテキスト ウィンドウと長い入力コスト
「リクエストごと」だけでなく、「会話全体で」価格がどのように積み重なるかを確認することが重要です。モデルが処理できるテキストの総量はコンテキスト ウィンドウと呼ばれます。入力と出力の合計がこのウィンドウに収まる必要があります。最新のモデルは非常に大きなウィンドウ (数十万、さらには数百万のトークン) を提供しますが、それは「無限に埋める」ことができるという意味ではありません。ウィンドウに入力したものはすべて入力として請求されます。
長い会話の落とし穴は次のとおりです。新しいラウンドが発生するたびに、履歴全体が再度送信されます (ユニット 1 ではステートレスになります)。 20 ラウンドの会話では、20 番目のリクエストは最初の 19 ラウンド全体を入力として伝送します。したがって、会話が長くなるにつれて、リクエストあたりのコストは直線的ではなく累積的に増加します。エージェント アシスタントとの 50 ラウンドの会話では、最初のラウンドの数十倍の入力コストが発生する可能性があります。
これを管理するには 2 つの方法があります。 1 つ目は要約です。古いラウンドを 1 つの要約ブロックに圧縮し、最後の数ラウンドのみを生の状態に保ちます。 2 つ目はプロンプト キャッシュ (ユニット 6) です。固定コンテキストを定価で繰り返し処理するのではなく、10 分の 1 の価格で読み取ります。これらを組み合わせることで、長時間のコンテキスト集約型ワークロードの料金が大幅に削減されます。したがって、トークンエコノミクスは単一のリクエストではなく、セッション全体の設計に関するものです。
要約すると
トークンはテキストが処理される最小単位です。入力と出力の価格は別々に設定されており、多くの場合、出力の方がはるかに高価です。コストはトークンの数に単価を掛けたもので、実際の決定は量によって決まります。プロンプトを短縮し、出力を制限し、タスクを達成する最軽量のモデルを選択することが、コストを何倍にも削減する最も直接的な手段となります。
アプリケーションタスク
あなた自身のタスクを選択してください。 (1) 代表的なプロンプトの入力トークンと推定出力トークンの数を決定します (可能であればトークン カウント ツールを使用して測定します)。 (2) 3 つのモデル クラスのリクエストあたりのコストを計算します。 (3) 1 日のリクエスト数を見積もり、3 つのモデルの月次予算を導き出します。 (4) 出力を短縮し、予想される節約量を記録する命令を追加します。
チェックリスト
- [ ] トークンの概念と、トークン化がモデルによって異なることを説明できます。
- [ ] 入力トークンと出力トークンの価格が異なる理由はわかりました。
- [ ] リクエストのコストは次の式で計算できます。
- [ ] テンプレートを使用して、ワークロードの月次予算を作成できます。
- [ ] 出力の短縮とモデルの削減の利点を例で示します。