In vLLM v0.23.0, vllm:num_requests_running is set from SchedulerStats.num_running_reqs and observes scheduler running-request state.

Why this matters

Useful for questions about what vllm:num_requests_running observes and where its value comes from: the scheduler's running-request count published via SchedulerStats.num_running_reqs.

Metric

Applies when

Evidence

171: class SchedulerStats:
172:     """Stats associated with the scheduler."""
173: 
174:     num_running_reqs: int = 0
175: 
176:     num_waiting_reqs: int = 0  # length of the "waiting" request queue

1066:         if scheduler_stats is not None:
1067:             self.gauge_scheduler_running[engine_idx].set(
1068:                 scheduler_stats.num_running_reqs
1069:             )

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

• queue latency
• request success or failure
• capacity saturation by itself

Guards

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

Freshness

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