Azure API Managementゲートウェイ、800トークン上限でも1,472に到達

テストは単一のポリシーllm-token-limitに焦点を当てた。これは期間のクォータを超えると403を返し、毎分のレートを超えると429を返す。Microsoftのドキュメント自体が、並列実行で一時的な超過が起こり得ると注記しており、この実験はその範囲を直接測定することを目的とした。構成はAPIM Developer classicインスタンス1ユニット（Japan East）、gpt-4.1-miniモデル（2025-04-14、Regional Standard）、Chat Completions API（2024-10-21）を使用。各試行では固定の合成プロンプトとmax_tokens 128でカウンターを新規に用意したため、成功した各応答は同じ184トークン（入力56＋出力128）を消費した。

著者は3つの構成——通常応答で事前推定OFF、通常で事前推定ON、ストリーミング——を並列度1、4、8で比較し、各5回の計45回の本試行を実施した。逐次送信の中央値は920トークンだったのに対し、並列度4と8はいずれも1,472だった。この差はリクエストが同時に到着する方法に起因する。実行中の合計がまだ上限未満のうちに4件の呼び出しが受け入れられ、その後になって初めてゲートウェイが403を返し始める。著者は、並列度8では最初のバッチだけで既に1,472に達したため、超過が並列度に比例するという一般的なルールを確立するものではないと慎重に述べている。5回のストリーミング実行のうち1回も1,472を示したが、この差を著者は内部的な原因まで追跡できなかった。

もう一つの実務的な論点は消費量をどこで測定するかだ。ストリーミングの場合、APIMのx-lab-consumedヘッダーは56トークンと報告したが、応答を最後まで読むとモデルの使用量は184だった。これはヘッダーがボディの完了前に届くためだ。ヘッダーを最終消費量として数えると128の出力トークンが落ちる。コントロール18回とレート制限9回を含む全72試行・795リクエストで、使用量が欠落した成功応答はなく、モデル側のエラーもなかった。ここでの争点は、同じパターンが異なる条件でも成り立つかどうかにある。例えば残りの予算を超える長い入力や、バッチ全体を待たず各応答の完了ごとに次のリクエストを送る場合だ。これらは著者が次にテストする予定のケースであり、それまではこの知見はこの特定の短いプロンプト・バッチ待ちの構成に紐づく。