トークンとリクエストの説明

リクエストとトークンは同じものではありません

アン APIリクエスト エンドポイントへの 1 回の呼び出しです。 トークン は、その呼び出し内のテキストの単位です。 1 つのリクエストで数個のトークン、または数十万のトークンが送信されることがあります。 LLM プロバイダーはトークンによって請求します。他の多くの API (支払い、マップ、SMS) はリクエストごとまたはアクションごとに請求されます。この 2 つを混同することは、予算編成で最もよくある間違いです。

各モデルが適用される場所

建てる前に見積もりをする方法

LLM 機能の場合、次のように推定します。 通話あたりのトークン × ユーザーあたりの通話 × ユーザー数。チャットの返信は、最大 500 個の入力トークンと最大 300 個の出力トークンになる可能性があります。毎月の会話を乗算してトークンの量を取得し、価格を設定します。リクエストごとのトークン数は大幅に変化するため、これは「リクエストごと」に推測するよりもはるかに正確です。入力と出力を常に分離しておきます。プロバイダーによって価格が異なり、多くの場合 3 ～ 5 倍の差があるため、混合された「平均トークン」の推定値は大幅に異なる可能性があります。

同じ分割がレート制限に再び表示されます

ほとんどの LLM プロバイダーは使用量を次のように制限しています。 両方 1 分あたりのリクエスト数 (RPM) の上限と 1 分あたりのトークン数 (TPM) の上限。どちらを最初にヒットするかは、平均的な呼び出しで運ばれるトークンの数、つまりこのページで取り上げている正確な数に完全に依存します。

• 短い通話、高頻度の通話 (キーストロークごとに分類器が起動するなど) 回転数 まずキャップを使用します。各コールのトークンは安価ですが、トークンの量は大量です。
• 長電話、頻度が少ない (例: 20,000 トークンのコンテキストを持つドキュメント要約エンドポイント) TPM 最初に上限を設定する — 少数の呼び出しですでにトークン バジェットが飽和状態になる可能性があります。

どの制限に達するかを知ることで、修正方法が変わります。RPM バウンドのワークロードには次の利点があります。 バッチ処理 複数の小さな呼び出しを 1 つの大きなリクエストに変換する (リクエストは少なく、トークンの総数は同じ) 一方で、TPM バウンドのワークロードは次のようなメリットを享受できます。 トリミング 呼び出し頻度を減らすのではなく、コンテキストまたは出力の長さを変更します。見る API レート制限の説明 プロバイダーごとの具体的な RPM/TPM 層については。

実用的な例: チャットボット機能のサイジング

次のサポート チャットボットを計画しているとします。 月間アクティブ ユーザー数 5,000、それぞれの平均 2セッション/月 の 3ターン 一枚。毎ターン大体運んでくる 900 入力トークン (システムプロンプト + 最近の会話履歴 + ユーザーのメッセージ) および 出力トークン 250 個.

• ターンあたりのトークン: 900 + 250 = 1,150
• ユーザーあたりのターン数/月: 3 × 2 = 6
• ユーザーあたり/月のトークン: 1,150 × 6 = 6,900 (約 4,900 入力 / 1,500 出力)
• 月間トークンの合計: 6,900 × 5,000 = 34.5M (≈24.5M 入力 / ~10M 出力)

選択したモデルに対して個別にトークン コスト計算ツールを使用して入力と出力の合計を実行します。出力の価格が高くなるため、1,000 万の出力トークンは、量が 3 分の 1 であるにもかかわらず、2,450 万の入力トークンと同じくらいのコストがかかる可能性があります。

見積もりを大幅に狂わせるよくある間違い

• インプットとアウトプットを 1 つの価格にブレンドします。 出力トークンは通常、入力レートの 3 ～ 5 倍です。入力価格で両方を見積もると、請求額は過小評価されます。
• 最近の歴史を忘れてしまいます。 呼び出しごとに以前のメッセージを再送信するマルチターン チャットでは、メッセージごとだけでなく、セッションを通じてターンごとのトークン数が増加します。
• トークンではなく文字で推定します。 文字あたりのトークン数は言語やコンテンツによって異なります。コード、JSON、および英語以外のテキストは通常​​、普通の英語よりも文字あたり多くのトークンを使用します。
• 再試行を無視します。 失敗した呼び出しが再試行されてもリクエスト クォータが消費され、多くの場合トークンも消費されるため、エラーが発生しやすい統合にはハッピー パスの計算が示すよりもコストがかかります。
• パイプラインの残りの部分をスキップします。 RAG またはエージェント機能は通常、埋め込みリクエスト、ベクトル検索呼び出し、および場合によってはより小さなルーティング モデルを追加します。これらはそれぞれ、メイン モデルのトークンとは別に独自に請求されます。

学び続ける

よくある質問

トークンと API リクエストの違いは何ですか?

API リクエストはエンドポイントへの 1 回の呼び出しです。トークンは、その中のテキストの単位です。 1 つのリクエストには、ごく少数のトークン、または数十万のトークンが含まれる場合があります。 LLM はトークンごとに請求されますが、他の多くの API はリクエストごとに請求されます。

一般的なチャットボット メッセージはどれくらいのトークンですか?

短いユーザー メッセージとシステム プロンプトは、多くの場合、数百の入力トークン、応答は数百の出力トークンになります。これは、プロンプトの長さや応答の冗長さによって異なりますが、交換ごとにおよそ 500 ～ 1,000 トークンになります。

毎月のトークン使用量を見積もるにはどうすればよいですか?

通話あたりのトークンとユーザーあたりの通話をユーザー数で乗算します。入力トークンと出力トークンの価格は異なるため、個別に見積もり、選択したモデルのトークン コスト計算ツールで合計を実行します。

トークンのコストは入力でも出力でも同じですか?

いいえ – 出力トークンの価格は通常、同じモデルの入力トークンよりも高く、多くの場合 3 ～ 5 倍です。インプットとアウトプットの合計を 1 つの平均に混合するのではなく、別々にしておくと、より正確なコスト見積もりが得られます。

メインモデルのトークン以外に何を予算に入れるべきですか?

RAG またはエージェント パイプラインでは、埋め込みリクエスト、ベクター データベース クエリ、および小規模なルーティングまたは分類モデル呼び出しの予算。それぞれがメイン モデルのトークンとは別に請求され、大容量機能全体で合計される可能性があります。

レート制限はリクエストまたはトークンをカウントしますか?

通常は両方を一度に行います。プロバイダーは 1 分あたりのリクエスト数 (RPM) の上限と 1 分あたりのトークン数 (TPM) の上限を別々に設定し、トラフィック パターンが最初に飽和する方に到達します。高頻度のショートコールは最初に RPM に達する傾向があります。低頻度のロングコンテキスト呼び出しは、最初に TPM に到達する傾向があります。