All versions · Version range: v0.4.2

Scheduler sequence capacity

seed slicecovered at legacy evidence: v0.4.2legacy evidence: main-2026-07-21evidence: source code and documentation

Coverage for max_num_seqs scheduler capacity, configuration exposure, constraints, and KV-cache pressure guidance.

Strong for seeded v0.4.2 SchedulerConfig exposure and constraints; partial for operational tuning guidance.

This topic connects max_num_seqs facts to scheduler capacity and KV-cache pressure, but it is not a full vLLM memory-management model.

Every declared topic entity has applicable claims, availability, or admitted history at this version.

4 claims0 history facts1/1 entities

Claim	Verified
In vLLM v0.4.2, `max_num_seqs` is exposed through the `SchedulerConfig.__init__` Python parameter `max_num_seqs`.	Sep 29
In vLLM v0.4.2 `SchedulerConfig`, `max_num_seqs` is documented and stored as the maximum number of sequences to process in a single scheduler iteration.	Sep 29
In vLLM v0.4.2, `SchedulerConfig` raises an error when `max_num_batched_tokens` is smaller than `max_num_seqs`.	Sep 29
The latest optimization docs snapshot says that decreasing `max_num_seqs` can reduce concurrent requests in a batch and require less KV cache space when preemptions are frequent.	Aug 20

The corpus does not yet include runtime telemetry tying max_num_seqs changes to specific preemption rates.

Schema.ai can surface the documented tuning direction but should not prescribe an exact value for a workload.

Check: Add telemetry-backed examples or benchmark evidence before value-specific recommendations.

Adjacent features such as speculative decoding are not covered by this topic.

Questions about those features should return guidance-only until source-grounded claims are added.

Check: Capture and promote source snapshots for each adjacent scheduler feature before including it in catalog coverage.