In vLLM v0.23.0, vllm:num_preemptions increments from IterationStats.num_preempted_reqs, which is increased when engine-core events mark requests as preempted.

Why this matters

Useful for questions about what vllm:num_preemptions counts and when it increments: engine-core events that mark a request preempted increase IterationStats.num_preempted_reqs, which feeds the counter.

Metric

Applies when

Evidence

419:                 lora_states.request_waiting(req_id, lora_name)
420:             elif event.type == EngineCoreEventType.SCHEDULED:
421:                 if req_stats.scheduled_ts == 0.0:  # ignore preemptions
422:                     req_stats.scheduled_ts = event.timestamp
423:                 lora_states.request_running(req_id, lora_name)
424:             elif event.type == EngineCoreEventType.PREEMPTED:
425:                 self.num_preempted_reqs += 1
426:                 lora_states.request_waiting(req_id, lora_name)

1149:         self.counter_num_preempted_reqs[engine_idx].inc(
1150:             iteration_stats.num_preempted_reqs

Claim support

No independent claim-support receipt is recorded. Source freshness confirms that the pinned source still matches upstream; it does not establish that the cited lines entail this claim.

Does not establish

• that every preemption is caused by KV cache pressure
• which config knob should be changed
• the operational severity of a given counter value

Guards

• vllm_version = v0.23.0
• metric_name = vllm:num_preemptions
• runtime_component = scheduler

Freshness

Pinned release-tag source snapshot; re-check if target phase-1 release changes or metrics API compatibility becomes customer-facing.