continuous batchingの公平性・starvation・SLO class設計

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そのものを保証する契約ではありません。

公平性には複数の単位があります。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まで含めて評価します。

第一に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分布が異なれば効果も変わります。

厳密な公平性を強めるほど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のどの単位を公平性の基準にするかを先に定義します。

• 対象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をどこまで利用者が制御できるか。

「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を実測する」とします。

• 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