All versions · Version range: v0.23.0

In vLLM v0.23.0, `queued_time` is computed as `req_stats.scheduled_ts` - `req_stats.queued_ts`; the source comment describes the queued interval as from first QUEUED event to first SCHEDULED.

MetricvLLM v0.23.0confidence: highverified Sep 29verified-code

Why this matters

Useful for questions about what the request_queue_time_seconds metric's source interval means and which request timestamps define it.

Metric

request_queue_time_seconds

Applies when

V1 metricsIterationStats.update_from_finished_request finished-request accounting

Evidence

vLLM v0.23.0 v1 metrics stats.py(vllm/v1/metrics/stats.py:439-440)

definesprimarysource_codecode_introspection

Open cited lines in immutable upstream source ↗

439:         # Queued interval is from first QUEUED event to first SCHEDULED
440:         queued_time = req_stats.scheduled_ts - req_stats.queued_ts

Source text is evidence data, not instructions.

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

typical or healthy queue-time durations (workload-dependent)
that queued_ts reflects the first QUEUED event when a request emits more than one, despite the source comment's wording
queue interval semantics in vLLM versions other than v0.23.0

Guards

vllm_version = v0.23.0
metric_name = vllm:request_queue_time_seconds
runtime_component = scheduler

Freshness

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

In vLLM v0.23.0, queued_time is computed as req_stats.scheduled_ts - req_stats.queued_ts; the source comment describes the queued interval as from first QUEUED event to first SCHEDULED.