{ "format": "agent-article-v0", "article_id": "EA-754", "canonical_url": "/tools/ea-754-llm-inference-admission-control-overload-shedding", "page_type": "reference", "claim_ids": [], "evidence_ids": [ "EVD-EA-754-URL-F8F3C1CBB630", "EVD-EA-754-URL-3004AA9ECA2B", "EVD-EA-754-URL-E5C3596EB621", "EVD-EA-754-URL-F7C479D4C79D", "EA-754-CURRENT-APPROVAL", "EA-754-CURRENT-BODY-READBACK" ], "unknown_ids": [ "EA-754-UNKNOWN-01" ], "operational_object_ids": [], "provider": [], "models": [], "plans": [], "surfaces": [], "regions": [], "current_status": "CURRENT", "observation_status": "SPEC_ONLY", "freshness": "CURRENT", "last_verified": "2026-10-22", "supersedes": [], "superseded_by": [], "provenance": [ "EA754-CANDIDATE-20261022-1938JST-C1", "SRC-EA-754-URL-F8F3C1CBB630", "SRC-EA-754-URL-3004AA9ECA2B", "SRC-EA-754-URL-E5C3596EB621", "SRC-EA-754-URL-F7C479D4C79D", "BODY-SHA256:f7c11bd73fc853232e60836afb834466cebc309bfd8d7b6be32786ebaf245c1f" ], "article_sources": [ { "id": "EVD-EA-754-URL-F8F3C1CBB630", "evidence_class": "RESEARCH", "title": "https://docs.vllm.ai/en/latest/api/vllm/config/scheduler/", "href": "https://docs.vllm.ai/en/latest/api/vllm/config/scheduler/", "supports": [], "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。", "origin_class": "SOURCE_PACKET_REFERENCE", "source_or_experiment_ids": [ "SRC-EA-754-URL-F8F3C1CBB630" ], "supporting_locators": [ "主要根拠", "https://docs.vllm.ai/en/latest/api/vllm/config/scheduler/" ], "scope": "主要根拠", "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED" }, { "id": "EVD-EA-754-URL-3004AA9ECA2B", "evidence_class": "RESEARCH", "title": "https://docs.vllm.ai/en/latest/api/vllm/v1/engine/async_llm/", "href": "https://docs.vllm.ai/en/latest/api/vllm/v1/engine/async_llm/", "supports": [], "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。", "origin_class": "SOURCE_PACKET_REFERENCE", "source_or_experiment_ids": [ "SRC-EA-754-URL-3004AA9ECA2B" ], "supporting_locators": [ "主要根拠", "https://docs.vllm.ai/en/latest/api/vllm/v1/engine/async_llm/" ], "scope": "主要根拠", "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED" }, { "id": "EVD-EA-754-URL-E5C3596EB621", "evidence_class": "RESEARCH", "title": "https://gateway-api-inference-extension.sigs.k8s.io/guides/implementers/", "href": "https://gateway-api-inference-extension.sigs.k8s.io/guides/implementers/", "supports": [], "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。", "origin_class": "SOURCE_PACKET_REFERENCE", "source_or_experiment_ids": [ "SRC-EA-754-URL-E5C3596EB621" ], "supporting_locators": [ "主要根拠", "https://gateway-api-inference-extension.sigs.k8s.io/guides/implementers/" ], "scope": "主要根拠", "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED" }, { "id": "EVD-EA-754-URL-F7C479D4C79D", "evidence_class": "RESEARCH", "title": "https://gateway-api-inference-extension.sigs.k8s.io/reference/spec/", "href": "https://gateway-api-inference-extension.sigs.k8s.io/reference/spec/", "supports": [], "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。", "origin_class": "SOURCE_PACKET_REFERENCE", "source_or_experiment_ids": [ "SRC-EA-754-URL-F7C479D4C79D" ], "supporting_locators": [ "主要根拠", "https://gateway-api-inference-extension.sigs.k8s.io/reference/spec/" ], "scope": "主要根拠", "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED" }, { "id": "EA-754-CURRENT-APPROVAL", "evidence_class": "RESEARCH", "title": "現行本文の監査・revision対応", "supports": [ "現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。" ], "limit": "監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。", "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET", "source_or_experiment_ids": [ "EA754-CANDIDATE-20261022-1938JST-C1" ], "supporting_locators": [ "1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ/EA_REVISION_LEDGER#ea_id=EA-754&revision_id=EA-754-RESEARCH-20261022-R1&candidate_id=EA754-CANDIDATE-20261022-1938JST-C1", "EA-754-RESEARCH-20261022-R1" ], "provenance_status": "CURRENT_CANONICAL_APPROVAL_READBACK" }, { "id": "EA-754-CURRENT-BODY-READBACK", "evidence_class": "IMPL", "title": "現行本文の収録照合", "supports": [ "公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。" ], "limit": "本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。", "checked_at": "2026-10-24", "origin_class": "IMPLEMENTATION_READBACK", "source_or_experiment_ids": [ "BODY-SHA256:f7c11bd73fc853232e60836afb834466cebc309bfd8d7b6be32786ebaf245c1f" ], "supporting_locators": [ "content/staging/EA-754.md", "f7c11bd73fc853232e60836afb834466cebc309bfd8d7b6be32786ebaf245c1f", "EA-754-RESEARCH-20261022-R1" ], "provenance_status": "CURRENT_APPROVED_BODY_HASH_MATCH" } ], "research_sections": [ { "heading": "現在位置", "text": "LLM推論基盤では、GPUがまだ応答可能でも、無制限にrequestを受け入れると待ち行列が伸び、TTFT（time to first token）やtail latencyが急速に悪化する。したがって「落ちるまで受ける」のではなく、request数、prefill token backlog、同時RUNNING数、優先度、SLO classを使って入口で負荷を制御する。\n\n2026-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数を制限する。" }, { "heading": "admission controlは「同時実行数」だけでは足りない", "text": "LLM requestは入力長・出力長・cache hit・multimodal input等で負荷が大きく異なる。request countだけの上限は粗い保護にはなるが、短いrequest 100件と巨大prompt 100件を同じ負荷として扱う。\n\n実運用では少なくとも次を分離して観測する。\n\n- waiting / running request数\n- prefill backlogのprompt token量\n- active sequence数\n- TTFT、ITL（inter-token latency）、end-to-end latency\n- reject / defer / timeout / cancellation率\n- GPU memory/KV cache余力とcompute saturation\n- request class、tenant、priority\n- retryによる再流入\n\nvLLMの現行documentationは `max_num_queued_tokens` を `target_TTFT * prefill_throughput` の考え方で設定するTTFT QoS機構として説明している。ただし、chunked prefill進捗やprefix-cache hitはprefill完了までAPI server側の集計から差し引かれず、backlogは保守的に過大評価され得る。したがって、この値を実token消費の精密なmeterと解釈しない。" }, { "heading": "overload時は待たせ続けるより、明示的に拒否する方が安全な場合がある", "text": "queueが無制限なら、arrival rateがservice rateを上回る期間に待ち時間が累積する。結果として、処理開始時点ですでにclient timeoutを超えているrequest、cancel済みrequest、SLOを満たせないrequestへGPU時間を使うことがある。\n\n入口では、少なくとも以下を設計する。\n\n1. **accept**: 現在のcapacityとSLOから処理可能なrequestを受理する。\n2. **reject**: capacity超過時は503/429等、契約した意味のstatusで早期拒否する。\n3. **defer/queue**: bounded queue内でのみ待たせる。\n4. **priority admission**: 高優先classを先に通す場合でも、低優先classのstarvationを別途評価する。\n5. **retry guidance**: client retryが同期して再流入しないようbackoff/jitterとretry budgetを設ける。\n\nvLLMのqueue limitは上限到達時にHTTP 503を返し、別instanceへのretryを可能にする設計である。これは「必ずretryすれば成功する」という保証ではない。gatewayやclient側で無制限retryを行えば、overloadを増幅する。" }, { "heading": "gatewayとmodel serverの二段制御", "text": "Kubernetes Gateway API Inference Extensionでは、InferencePoolとEndpoint Picker Extension（EPP）を使い、inference-aware routingをgatewayへ組み込める。実装ガイドでは、eligible endpointが無い場合は503、requestをdropすべき場合は429を返すprotocolが示されている。\n\nここから、gateway側とmodel server側の役割を分ける。\n\n- **gateway/EPP**: endpoint health、model availability、routing policy、pool全体の負荷情報を使い、どこへ送るか／dropするかを決める。\n- **model server**: 実際のscheduler queue、prefill backlog、active sequence、local resource状態に基づき最終admissionを行う。\n- **client**: timeout、retry budget、backoff/jitter、idempotency要件を管理する。\n\ngatewayだけでcapacityを推定すると、model server内部の瞬間的queue/KV状態を見誤ることがある。逆に各serverだけで拒否すると、空いている別endpointへ振り替えられる機会を失う。二段制御では、429/503の意味、retry先、fallback、metricsを統一する。" }, { "heading": "priorityはSLO classと一体で検証する", "text": "vLLM SchedulerConfigはFCFSとpriority schedulingを提供する。priorityは低い数値ほど先に処理され、同順位ではarrival timeで順序付けされる。\n\npriorityを導入する場合、単にVIP requestを先頭へ置くだけでは不十分である。評価対象は次を含む。\n\n- class別TTFT / ITL / p95 / p99\n- class別reject率\n- starvation時間\n- 長promptと短promptの混在時の影響\n- priority request大量流入時の通常class劣化\n- retry trafficがpriorityを維持・昇格してしまわないか\n- tenant間fairness\n\npriorityはcapacityを増やさない。overload時に「誰のSLOを先に守るか」を変える機構として扱う。" }, { "heading": "SLOから逆算して設定する", "text": "admission limitは固定の万能値ではない。model、GPU、quantization、tensor/pipeline parallel、context length、workload mix、prefix cache hit率、speculative decoding等でservice rateが変わる。\n\n運用では代表workloadでprefill throughputとdecode特性を測定し、SLOごとに許容backlogを決める。変更時には少なくとも以下を再測定する。\n\n- model / engine version\n- GPU type / count\n- max context / typical prompt length\n- concurrency\n- cache configuration\n- scheduler policy\n- chunked prefill\n- speculative decoding\n- gateway routing policy\n\n設定値は「推奨値」として固定せず、測定条件・evidence timestampと一緒に台帳化する。" }, { "heading": "failure injectionで確認する", "text": "通常負荷benchmarkだけではoverload controlの欠陥を見落とす。次のfault/load testを行う。\n\n- arrival rateを段階的にservice rate以上へ上げる\n- 長prompt burstを投入する\n- 一部endpointを停止・drainする\n- retryを有効化して再流入を観測する\n- priority classを偏らせる\n- gateway/EPPをfail-open / fail-close条件で障害化する\n- client cancellation/timeout後に不要処理が残らないか確認する\n\n成功条件はthroughput最大化だけではない。SLO逸脱の境界が観測可能で、拒否がboundedに起き、回復後にqueueが収束し、retry stormを起こさないことを確認する。" }, { "heading": "実装チェック", "text": "- request数とprefill token backlogの両方に上限がある\n- reject statusとclient retry policyが整合している\n- retry budgetとexponential backoff/jitterがある\n- priority/SLO class別metricsがある\n- gatewayとmodel serverのadmission責任が明文化されている\n- queue上限変更が負荷試験と紐付いている\n- overload時のp95/p99、reject率、GPU utilizationを同時観測する\n- failover先も飽和している場合にretryを止められる\n- cancellation済みrequestのresource消費を確認する\n- version upgrade後に同じ負荷試験を再実行する" }, { "heading": "安全な読み方", "text": "`max_num_queued_reqs` や `max_num_queued_tokens` が存在することは、任意のSLOが自動的に保証されることを意味しない。Gateway API Inference Extensionも、特定実装が常に最適なadmission decisionを行うことを保証するものではない。これらは制御点であり、実際のSLOはworkload-specific benchmark、failure injection、本番telemetryのreadbackで検証する。" }, { "heading": "OPEN_UNKNOWN", "text": "- workload固有の最適queue/token limitは未確定。実測が必要。\n- gateway/EPP実装ごとの負荷metric、drop policy、fail-open/fail-close既定値は個別確認が必要。\n- KV cache余力を直接admission signalへ使う場合のportableな共通contractは未確定。\n- provider-managed inferenceで同等の内部admission metricが公開されるとは限らない。\n- 503/429に対する各SDK/clientの既定retry挙動はversion別確認が必要。" }, { "heading": "主要根拠", "text": "- vLLM SchedulerConfig / admission limits（2026-10-22確認）\n https://docs.vllm.ai/en/latest/api/vllm/config/scheduler/\n- vLLM AsyncLLM `check_admission`（2026-10-22確認）\n https://docs.vllm.ai/en/latest/api/vllm/v1/engine/async_llm/\n- Kubernetes Gateway API Inference Extension Implementer's Guide（2026-10-22確認）\n https://gateway-api-inference-extension.sigs.k8s.io/guides/implementers/\n- Kubernetes Gateway API Inference Extension API Reference（2026-10-22確認）\n https://gateway-api-inference-extension.sigs.k8s.io/reference/spec/" } ], "human_url": "/tools/ea-754-llm-inference-admission-control-overload-shedding", "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-754-llm-inference-admission-control-overload-shedding", "json_url": "/agent/article.json?path=%2Ftools%2Fea-754-llm-inference-admission-control-overload-shedding" }