TaskManager: label 単位の RPM/TPM レート制限（token bucket）を検討

[isamu]

Background

#1304 で導入予定の concurrency per label は「同時実行数」を制御するが、これは 時間窓ベースのレート制限（RPM/TPM）と本質的に別 である。

多くのケースでは concurrency 調整 + 429 リトライで実用上カバーできるため、本機能は 後追い で検討する。以下のケースに該当するユーザが現れたら優先度を上げる。

concurrency で代替できる場合

API 応答時間 × 並列数 ≒ 実効 RPM。応答時間がほぼ一定なら concurrency を低めに設定すれば RPM は自然に抑えられる（例: 最低 200ms かかる API なら concurrency=1 で実効 ≤ 300 RPM）。

→ この前提が成り立つなら本 issue は不要。retry filter で 429 を吸収すれば運用回る。

concurrency では代替できないケース

A. TPM (Tokens Per Minute) 制御

• 「100 トークンの問い合わせ」と「50k トークンの長文要約」では消費トークン量が桁違い
• concurrency をいくら絞っても 1 リクエストで巨大なトークンを投げれば TPM 上限を一発で超える
• 解決にはリクエスト前にトークン数を見積もって bucket から消費する仕組みが必要 → token bucket が要る

B. バースト耐性（応答時間が読めない）

• LLM の応答時間は数百ms〜数十秒まで変動
• concurrency=3 で「速い時は 600 RPM、遅い時は 10 RPM」のように振れる
• RPM 上限ギリギリまで使い切りたい場合は応答時間に依存しない時間窓ベースの制御が必要

C. 複数 GraphAI インスタンス間の協調

• TaskManager はインスタンス内で閉じている
• 同一プロセスで複数グラフ並走 / 別プロセスで API キー共有 などの場合、concurrency は共有できないが rate limit は共有したいことがある
• これは rate limiter を外部化する話なので別途検討

Proposal（将来）

concurrency:
  global: 20
  labels:
    openai:
      concurrent: 3
      rate:
        rpm: 500       # requests per minute
        tpm: 30000     # tokens per minute (要：token推定)

• label ごとに簡易 token bucket を持たせる
• TPM は事前にトークン見積関数を渡す or weight を tokens として流用
• 既存の concurrency limit と AND で適用

Why this is a separate ticket

• 設計が広い（token 推定 API、token bucket、複数インスタンス間共有）
• 多くのユーザは concurrency + 429 retry でカバーできる
• TPM をカリカリにチューニングしたいユースケースが具体化してから着手したい

Related

• GraphAIでagent / label単位のconcurrency制御をサポートしたい #1304 (concurrency per label + HoL skip) — まず concurrent 数だけ制御
• TaskManager: queue で待機中のタスクの優先度を時間経過で自動昇格 (aging) させたい #1311 (aging) — フォローアップ
• TaskManager: タスクに weight を持たせて concurrency を「重みの合計」で制御したい #1312 (weight) — フォローアップ