コンテキストウィンドウ計算機

ウィンドウが思ったより早く埋まる理由

コンテキスト ウィンドウは、単に「ドキュメントをどれだけ長く貼り付けることができるか」を示すものではありません。実際のチャット アプリでは、モデルは 会話全体 API はステートレスであるため、呼び出しの間にメモリがないため、毎回履歴を再送信することになります。 200 トークンのシステム プロンプトと 250 トークンのメッセージを 10 回繰り返すと、ユーザーが次の質問を入力する前にすでに 2,800 トークンになり、そのブロック全体が送信されます。 また 次のターン。返信用の予約スペースを追加すると、「小さな」チャットがどのように制限に近づいているか、そして会話が長くなるにつれて請求額が上昇する理由がわかります。

この計算機は、システム プロンプト、再送信履歴、新しいメッセージ ルーム、予約された出力の 4 つの部分を分離し、各モデルのウィンドウに対して合計を表示します。見出しのパーセンテージは、どのくらいの余裕が残っているかを示します。 「まだ適合するターン数」は、古いメッセージをトリミングまたは要約する必要があるまで会話を実行できる時間を示します。出力もウィンドウ内に存在するため、長い回答用に 4,000 個のトークンを予約すると、コンテキストに使用できるスペースが圧迫されてしまいます。これが、大きなウィンドウ モデルでも長い出力タスクが窮屈に感じられる理由です。

適合することがわかったら、価格を設定します。の LLM トークンコスト計算ツール これらのトークンをすべてのモデルの通話ごとのコストに変換します。 プロンプトキャッシュ計算ツール は、修正されたシステム プロンプトを再請求する代わりにキャッシュすることでどれだけ節約できるかを示しています。 チャットボットのコスト計算ツール すべてを月間ボリュームに結び付けます。

使い方

1. モデルを選択します。そのコンテキスト ウィンドウが自動的に読み込まれます。
2. システム プロンプト サイズ、メッセージあたりの平均トークン、履歴に保持する過去のターン数を入力します。
3. モデルの応答用にトークンを予約します (長い応答にはさらに多くのトークンが必要です)。
4. 使用率、まだ適合する回転数、コストを読み取り、表内のモデルを比較します。

よくある間違い

出力カウントを忘れます。 応答は入力とウィンドウを共有します。大きく予約する max_tokens 渡すことができるコンテキストを縮小します。 すべてを永遠に再送信します。 増加する履歴をターンごとに再請求することが、チャットのコストが膨らむ主な理由です。つまり、履歴を要約またはウィンドウ化します。 文字数を信頼します。 トークンは言葉ではありません。コード、JSON、および英語以外のテキストでは、文字ごとにはるかに多くのトークンが使用されます。 コストとウィンドウが混同されている。 1M ウィンドウは無料で使用できますが、通話ごとに埋めるには費用がかかります。

見積もりの​​み。トークン数、コンテキスト ウィンドウ、価格は参考値であり、モデルやプロバイダーによって異なります。信頼する前に確認してください。