LLM 推論 admission 制御とoverload shedding

LLM推論基盤では、GPUがまだ応答可能でも、無制限にrequestを受け入れると待ち行列が伸び、TTFT（time to first token）やtail latencyが急速に悪化する。したがって「落ちるまで受ける」のではなく、request数、prefill token backlog、同時RUNNING数、優先度、SLO classを使って入口で負荷を制御する。

2026-10-22時点のvLLM公式documentationでは、max_num_queued_reqs によりwaiting+runningのin-flight request数を制限でき、上限到達時は新規requestをHTTP 503で拒否する。また max_num_queued_tokens はprefill中requestのprompt token総量を制限し、TTFT QoS用のcapacity valveとして説明されている。max_num_active_seqs はRUNNINGへadmitするrequest数を制限する。

LLM requestは入力長・出力長・cache hit・multimodal input等で負荷が大きく異なる。request countだけの上限は粗い保護にはなるが、短いrequest 100件と巨大prompt 100件を同じ負荷として扱う。

実運用では少なくとも次を分離して観測する。

• waiting / running request数
• prefill backlogのprompt token量
• active sequence数
• TTFT、ITL（inter-token latency）、end-to-end latency
• reject / defer / timeout / cancellation率
• GPU memory/KV cache余力とcompute saturation
• request class、tenant、priority
• retryによる再流入

vLLMの現行documentationは max_num_queued_tokens を target_TTFT * prefill_throughput の考え方で設定するTTFT QoS機構として説明している。ただし、chunked prefill進捗やprefix-cache hitはprefill完了までAPI server側の集計から差し引かれず、backlogは保守的に過大評価され得る。したがって、この値を実token消費の精密なmeterと解釈しない。

queueが無制限なら、arrival rateがservice rateを上回る期間に待ち時間が累積する。結果として、処理開始時点ですでにclient timeoutを超えているrequest、cancel済みrequest、SLOを満たせないrequestへGPU時間を使うことがある。

入口では、少なくとも以下を設計する。

• accept: 現在のcapacityとSLOから処理可能なrequestを受理する。
• reject: capacity超過時は503/429等、契約した意味のstatusで早期拒否する。
• defer/queue: bounded queue内でのみ待たせる。
• priority admission: 高優先classを先に通す場合でも、低優先classのstarvationを別途評価する。
• retry guidance: client retryが同期して再流入しないようbackoff/jitterとretry budgetを設ける。

vLLMのqueue limitは上限到達時にHTTP 503を返し、別instanceへのretryを可能にする設計である。これは「必ずretryすれば成功する」という保証ではない。gatewayやclient側で無制限retryを行えば、overloadを増幅する。

Kubernetes Gateway API Inference Extensionでは、InferencePoolとEndpoint Picker Extension（EPP）を使い、inference-aware routingをgatewayへ組み込める。実装ガイドでは、eligible endpointが無い場合は503、requestをdropすべき場合は429を返すprotocolが示されている。

ここから、gateway側とmodel server側の役割を分ける。

• gateway/EPP: endpoint health、model availability、routing policy、pool全体の負荷情報を使い、どこへ送るか／dropするかを決める。
• model server: 実際のscheduler queue、prefill backlog、active sequence、local resource状態に基づき最終admissionを行う。
• client: timeout、retry budget、backoff/jitter、idempotency要件を管理する。

gatewayだけでcapacityを推定すると、model server内部の瞬間的queue/KV状態を見誤ることがある。逆に各serverだけで拒否すると、空いている別endpointへ振り替えられる機会を失う。二段制御では、429/503の意味、retry先、fallback、metricsを統一する。

vLLM SchedulerConfigはFCFSとpriority schedulingを提供する。priorityは低い数値ほど先に処理され、同順位ではarrival timeで順序付けされる。

priorityを導入する場合、単にVIP requestを先頭へ置くだけでは不十分である。評価対象は次を含む。

• class別TTFT / ITL / p95 / p99
• class別reject率
• starvation時間
• 長promptと短promptの混在時の影響
• priority request大量流入時の通常class劣化
• retry trafficがpriorityを維持・昇格してしまわないか
• tenant間fairness

priorityはcapacityを増やさない。overload時に「誰のSLOを先に守るか」を変える機構として扱う。

admission limitは固定の万能値ではない。model、GPU、quantization、tensor/pipeline parallel、context length、workload mix、prefix cache hit率、speculative decoding等でservice rateが変わる。

運用では代表workloadでprefill throughputとdecode特性を測定し、SLOごとに許容backlogを決める。変更時には少なくとも以下を再測定する。

• model / engine version
• GPU type / count
• max context / typical prompt length
• concurrency
• cache configuration
• scheduler policy
• chunked prefill
• speculative decoding
• gateway routing policy

設定値は「推奨値」として固定せず、測定条件・evidence timestampと一緒に台帳化する。

通常負荷benchmarkだけではoverload controlの欠陥を見落とす。次のfault/load testを行う。

• arrival rateを段階的にservice rate以上へ上げる
• 長prompt burstを投入する
• 一部endpointを停止・drainする
• retryを有効化して再流入を観測する
• priority classを偏らせる
• gateway/EPPをfail-open / fail-close条件で障害化する
• client cancellation/timeout後に不要処理が残らないか確認する

成功条件はthroughput最大化だけではない。SLO逸脱の境界が観測可能で、拒否がboundedに起き、回復後にqueueが収束し、retry stormを起こさないことを確認する。

• request数とprefill token backlogの両方に上限がある
• reject statusとclient retry policyが整合している
• retry budgetとexponential backoff/jitterがある
• priority/SLO class別metricsがある
• gatewayとmodel serverのadmission責任が明文化されている
• queue上限変更が負荷試験と紐付いている
• overload時のp95/p99、reject率、GPU utilizationを同時観測する
• failover先も飽和している場合にretryを止められる
• cancellation済みrequestのresource消費を確認する
• version upgrade後に同じ負荷試験を再実行する

max_num_queued_reqs や max_num_queued_tokens が存在することは、任意のSLOが自動的に保証されることを意味しない。Gateway API Inference Extensionも、特定実装が常に最適なadmission decisionを行うことを保証するものではない。これらは制御点であり、実際のSLOはworkload-specific benchmark、failure injection、本番telemetryのreadbackで検証する。

• workload固有の最適queue/token limitは未確定。実測が必要。
• gateway/EPP実装ごとの負荷metric、drop policy、fail-open/fail-close既定値は個別確認が必要。
• KV cache余力を直接admission signalへ使う場合のportableな共通contractは未確定。
• provider-managed inferenceで同等の内部admission metricが公開されるとは限らない。
• 503/429に対する各SDK/clientの既定retry挙動はversion別確認が必要。

• vLLM SchedulerConfig / admission limits（2026-10-22確認） https://docs.vllm.ai/en/latest/api/vllm/config/scheduler/
• vLLM AsyncLLM check_admission（2026-10-22確認） https://docs.vllm.ai/en/latest/api/vllm/v1/engine/async_llm/
• Kubernetes Gateway API Inference Extension Implementer's Guide（2026-10-22確認） https://gateway-api-inference-extension.sigs.k8s.io/guides/implementers/
• Kubernetes Gateway API Inference Extension API Reference（2026-10-22確認） https://gateway-api-inference-extension.sigs.k8s.io/reference/spec/