メトリック 1日あたり 月あたり

再試行によって実際に費用がかかるのは何でしょうか?

429 エラー自体は無料です — 処理が開始される前にリクエストがレート制限されている場合、トークンは請求されません。実際のコストは次のとおりです。

  1. リクエストの再試行 — 再試行するたびに、完全な入力プロンプトが再度送信されます。再試行が成功した場合は、トークンの料金を支払います。入力が 2,000 トークンの場合、リクエストの 3% で 3 回再試行すると、成功したリクエストごとに 0.09 個の追加入力が追加されます。
  2. タイムアウトの重複 — リクエストに時間がかかりすぎてコードが再試行されたが、実際には元のリクエストが処理された場合。 2 回の完了に対して料金を支払います。これは、大規模な出力リクエストの場合に特にコストがかかります。
  3. 失敗したリクエスト — すべての再試行が終わってリクエストが失敗した場合、プロバイダーが受信時に料金を請求する場合、待ち時間と部分的な入力トークンのコストが無駄になります。

修正してください: ローカルのトークン/分レート リミッターを使用します (例: LangChain の ContextWindowExceededHandler または単純なトークン バケット)を使用して、API に到達する前にバーストを滑らかにします。これにより、コストを増加させることなく、ほとんどの 429 が排除されます。

関連している: API予算プランナー · コスト予測 · 無料枠の滑走路

よくある質問

429 レート制限エラーを返す API 呼び出しに対して料金はかかりますか?

いいえ — 429 エラーは処理前に拒否され、料金は発生しません。実際のコストは、再試行ロジック、応答の遅延、および再試行ロジックにバグがある場合に完了が重複することです。

指数関数的バックオフとは何ですか?また、なぜレイテンシ コストが増加するのでしょうか?

指数バックオフとは、再試行の間に 1 秒、2 秒、4 秒、8 秒... 待機することを意味します。 1 つの 429 と 2 回の再試行では、3 ~ 7 秒の遅延が追加されます。ダウンストリーム システムに SLA がある場合、トークン コストがゼロであっても実際の運用コストがかかります。

再試行により重複料金が発生するのはなぜですか?

リクエストは成功したが、レスポンスが到着する前にタイムアウトした場合、単純な再試行が再送信され、最初の試行が成功した場合は、2 回の完了に対して料金が発生します。タイムアウト時に再試行する前に、常に冪等キーを使用するか、既存の結果を確認してください。

LLM API の平均 429 レートはどれくらいですか?

バーストトラフィックでは、エラー率が 10 ~ 30% に達する可能性があります。制限を大幅に下回る安定したトラフィックの場合、通常は 0.1% 未満になります。現在、ほとんどのプロバイダーは 1 分あたりのトークン制限を使用しており、大きなコンテキストのリクエストをリクエスト数の制限よりも厳しく罰します。

API の再試行コストを削減するにはどうすればよいですか?

4 つのアプローチ: (1) トークン バケットを使用したローカルでのレート制限。 (2) 同時実行性が制御されたキューを使用します。 (3) バックグラウンドで再試行が行われるように非同期処理を設定します。 (4) 同一のプロンプトに対する応答をキャッシュします。