# continuous batchingの公平性・starvation・SLO class設計 CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-755-continuous-batching-starvation-slo-class CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-755-URL-F8F3C1CBB630, EVD-EA-755-URL-F76CB2488D37, EVD-EA-755-URL-BD2312AAD388, EVD-EA-755-URL-1A2DD1AD22AF, EVD-EA-755-URL-2A1735B40525, EVD-EA-755-URL-4D6F9B1AB3B2, EA-755-CURRENT-APPROVAL, EA-755-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-755-UNKNOWN-01 OPS_IDS: none ## Summary 「continuous batchingは公平である」「priority schedulingでstarvationを防げる」とは断定しません。「continuous batchingではrequest長・prefill/decode負荷・priority・KV footprintの差によりclass間のtail latencyやwaiting timeが偏り得るため、SLO class、aging/wait bound、prefill/decode budget、class別metricsを明示し、混合workloadでstarvationとtailを実測する」とします。 ## Current judgment 「continuous batchingは公平である」「priority schedulingでstarvationを防げる」とは断定しません。「continuous batchingではrequest長・prefill/decode負荷・priority・KV footprintの差によりclass間のtail latencyやwaiting timeが偏り得るため、SLO class、aging/wait bound、prefill/decode budget、class別metricsを明示し、混合workloadでstarvationとtailを実測する」とします。 ## Scope continuous batchingの公平性・starvation・SLO class設計 ## Confirmed ## UNKNOWN - EA-755-UNKNOWN-01: - 対象workloadで公平性の単位をrequest、token、GPU-time、tenantのどれに置くべきか。 - low-priority classの最大waiting timeまたはminimum service shareの適切な値。 - prefix-cache hitやspeculative decodingをresource-cost推定へどう織り込むか。 - disaggregated prefill/decode構成でclass別fairnessをpool間でどう整合させるか。 - managed inference APIでpriority/aging/resource shareをどこまで利用者が制御できるか。 ## Evidence - EVD-EA-755-URL-F8F3C1CBB630 (RESEARCH): vLLM SchedulerConfig, live verified 2026-10-21: — https://docs.vllm.ai/en/latest/api/vllm/config/scheduler/ - EVD-EA-755-URL-F76CB2488D37 (RESEARCH): vLLM run-batch CLI, live verified 2026-10-21: — https://docs.vllm.ai/en/latest/cli/run-batch/ - EVD-EA-755-URL-BD2312AAD388 (RESEARCH): vLLM Ascend ShortRequestFirst, live verified 2026-10-21: — https://docs.vllm.ai/projects/ascend/zh-cn/v0.30.0rc1/user_guide/feature_guide/short_request_first.html - EVD-EA-755-URL-1A2DD1AD22AF (RESEARCH): vLLM Ascend Batch-Job-Aware Scheduler, live verified 2026-10-21: — https://docs.vllm.ai/projects/ascend/en/main/user_guide/feature_guide/batch_job_aware_scheduler.html - EVD-EA-755-URL-2A1735B40525 (RESEARCH): FairBatching: Fairness-Aware Batch Formation for LLM Inference, arXiv:2510.14392, 2025-10-16: — https://arxiv.org/abs/2510.14392 - EVD-EA-755-URL-4D6F9B1AB3B2 (RESEARCH): Efficiency and Cost Alignment in Batched LLM Serving via Resource-Fair Scheduling, arXiv:2608.02244, 2026-08-03: — https://arxiv.org/abs/2608.02244 - EA-755-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-755-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits 公平性には複数の単位があります。request-count fairnessは各requestへ同程度の機会を与える考え方ですが、prompt/output token数が大きく違えばresource fairnessとは一致しません。priority class fairnessも、高priorityを常に先にすれば低priorityがstarveし得ます。短いrequest優先は平均TTFTを改善し得ますが、長いrequestのwaiting timeを悪化させます。 continuous batchingではdecode中requestを優先しすぎると新規prefillが待たされTTFT tailが悪化し、prefillを強く割り込ませすぎるとongoing decodeのITL/TPOTが悪化します。FairBatchingはこのprefill/decode間の計算資源配分を公平性問題として扱い、固定decode優先ではなくdynamic workloadに応じたbatch capacity調整を提案しています。ただし論文benchmarkの改善率を特定runtimeの保証値へ外挿してはなりません。 さらにbatched decodeでは、長いKV-cache footprintを持つrequestと短いrequestの同居により、短いrequestが自分のtoken量以上のbatch costを負担するresource-fairness問題が研究されています。したがって公平性はqueue順だけでなく、batch formationとKV/cache length heterogeneityまで含めて評価します。 ## Failure / limits 厳密な公平性を強めるほどthroughputや平均latencyが悪化する場合があります。長requestへ最低service shareを予約すると短requestのTTFT改善余地が減り、agingは高priority workloadのtailを悪化させ得ます。公平性は単一の最適値ではなく、business SLOとresource efficiencyのtrade-offです。 request単位の公平性はtoken/resource単位の公平性と一致しません。短いrequestを多数投入するtenantがrequest-count shareを占有する可能性もあるため、tenant、request、token、GPU-timeのどの単位を公平性の基準にするかを先に定義します。 ## 要点と前提 Continuous batchingはGPU利用率とthroughputを高めますが、requestごとのprompt長、decode長、到着時刻、priority、SLOが異なる環境では、単純なFCFSや短い仕事優先だけで公平性は保証されません。運用上はTTFT、ITL/TPOT、tail latency、waiting time、deadline miss、class別goodputを分けて観測し、interactive・batch・background等のSLO classごとに何を保護するかを明示します。 vLLMの現行SchedulerConfigはFCFSとpriority policyを持ち、priorityでは小さいpriority値を先に、同値ならarrival timeで順序付けます。chunked prefillでは `long_prefill_token_threshold` が長いprefillによるtoken budget独占を抑え、adaptive modeはqueued/running request数からfair shareを計算して実効thresholdの下限を調整します。これらは公平性設計の部品ですが、tenant公平性やstarvation freedomそのものを保証する契約ではありません。 ## 運用上の意味・failure 公平性には複数の単位があります。request-count fairnessは各requestへ同程度の機会を与える考え方ですが、prompt/output token数が大きく違えばresource fairnessとは一致しません。priority class fairnessも、高priorityを常に先にすれば低priorityがstarveし得ます。短いrequest優先は平均TTFTを改善し得ますが、長いrequestのwaiting timeを悪化させます。 continuous batchingではdecode中requestを優先しすぎると新規prefillが待たされTTFT tailが悪化し、prefillを強く割り込ませすぎるとongoing decodeのITL/TPOTが悪化します。FairBatchingはこのprefill/decode間の計算資源配分を公平性問題として扱い、固定decode優先ではなくdynamic workloadに応じたbatch capacity調整を提案しています。ただし論文benchmarkの改善率を特定runtimeの保証値へ外挿してはなりません。 さらにbatched decodeでは、長いKV-cache footprintを持つrequestと短いrequestの同居により、短いrequestが自分のtoken量以上のbatch costを負担するresource-fairness問題が研究されています。したがって公平性はqueue順だけでなく、batch formationとKV/cache length heterogeneityまで含めて評価します。 ## 具体的control / implementation implication 第一にSLO classを明示します。interactiveはTTFT/ITL、batchはcompletion throughput、backgroundはcost効率など、classごとにpriority、admission、queue budget、deadline、reserved capacityを定義します。priority値だけを設定して完了とせず、低priority classの最大waiting timeまたはminimum service shareを監視します。 第二にagingまたはwait boundを持たせます。短いrequest優先を採用する場合、長いrequestが一定時間を超えたら優先度を上げる、reserved slotを与える、別queueへ分離するなど、starvationを防ぐ境界を設けます。vLLM AscendのShortRequestFirstには `long_max_wait_ms` があり、長いprefillを短いprefillより前へ昇格可能にする最大待ち時間を設定できます。`0` は昇格を無効にし、strict short-request priorityを維持します。 第三にprefill/decode budgetを分離して観測します。class別TTFT p50/p95/p99、ITL/TPOT p95/p99、queue wait、deadline miss、tokens/sec、preemption、KV usage、class別admitted/rejected/completedを収集し、全体平均だけで公平性を判断しません。長prompt/短prompt、高priority/低priority、interactive/batchを混ぜたload testでstarvationとtailを再現します。 第四にpolicy変更は同一traceで比較します。FCFS、priority、short-request-first、chunked prefill threshold等について、throughputだけでなくclass別tailと最大waiting timeを確認します。公平性policyがGPU利用率を下げる場合もあるため、SLO保護とcapacityのtrade-offを明示します。 vLLM AscendのBatch-Job-Aware Schedulerはoffline batch向けで、公式文書がstarvation preventionを実装しないと明記しています。strict latency/fairness requirementがあるonline servingへ流用しないことが重要です。 ## 適用境界 vLLMのpriority policyはrequest priorityとarrival timeによる順序付けであり、weighted fair queueingやtenant quotaを意味しません。複数tenantのresource shareを保証したい場合はgateway/admission layer、separate pools、weighted queues等の上位controlが必要になる場合があります。 ShortRequestFirstはvLLM Ascend固有機能で、mainline vLLM一般の契約として扱いません。Batch-Job-Aware Schedulerもoffline batch中心で、starvation preventionを持たないためinteractive SLOへそのまま適用しません。 FairBatchingやresource-fair schedulingの論文は研究成果であり、採用runtimeで同じschedulerが利用可能とは限りません。benchmark条件、model、GPU、trace、prompt/output分布が異なれば効果も変わります。 ## Counterevidence / limitations 厳密な公平性を強めるほどthroughputや平均latencyが悪化する場合があります。長requestへ最低service shareを予約すると短requestのTTFT改善余地が減り、agingは高priority workloadのtailを悪化させ得ます。公平性は単一の最適値ではなく、business SLOとresource efficiencyのtrade-offです。 request単位の公平性はtoken/resource単位の公平性と一致しません。短いrequestを多数投入するtenantがrequest-count shareを占有する可能性もあるため、tenant、request、token、GPU-timeのどの単位を公平性の基準にするかを先に定義します。 ## OPEN_UNKNOWN - 対象workloadで公平性の単位をrequest、token、GPU-time、tenantのどれに置くべきか。 - low-priority classの最大waiting timeまたはminimum service shareの適切な値。 - prefix-cache hitやspeculative decodingをresource-cost推定へどう織り込むか。 - disaggregated prefill/decode構成でclass別fairnessをpool間でどう整合させるか。 - managed inference APIでpriority/aging/resource shareをどこまで利用者が制御できるか。 ## SAFE_WORDING 「continuous batchingは公平である」「priority schedulingでstarvationを防げる」とは断定しません。「continuous batchingではrequest長・prefill/decode負荷・priority・KV footprintの差によりclass間のtail latencyやwaiting timeが偏り得るため、SLO class、aging/wait bound、prefill/decode budget、class別metricsを明示し、混合workloadでstarvationとtailを実測する」とします。 ## Source / provenance locators - vLLM SchedulerConfig, live verified 2026-10-21: https://docs.vllm.ai/en/latest/api/vllm/config/scheduler/ - vLLM run-batch CLI, live verified 2026-10-21: https://docs.vllm.ai/en/latest/cli/run-batch/ - vLLM Ascend ShortRequestFirst, live verified 2026-10-21: https://docs.vllm.ai/projects/ascend/zh-cn/v0.30.0rc1/user_guide/feature_guide/short_request_first.html - vLLM Ascend Batch-Job-Aware Scheduler, live verified 2026-10-21: https://docs.vllm.ai/projects/ascend/en/main/user_guide/feature_guide/batch_job_aware_scheduler.html - FairBatching: Fairness-Aware Batch Formation for LLM Inference, arXiv:2510.14392, 2025-10-16: https://arxiv.org/abs/2510.14392 - Efficiency and Cost Alignment in Batched LLM Serving via Resource-Fair Scheduling, arXiv:2608.02244, 2026-08-03: https://arxiv.org/abs/2608.02244 NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.