Schema.ai· vLLM
vLLM official site Log in
All versions · Version range: v0.23.0

For each EngineCoreEventType.QUEUED event processed by IterationStats.update_from_events, req_stats.queued_ts is set to event.timestamp.

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

Why this matters

Answers how the start timestamp behind vLLM's request queue-time metric is captured. The assignment carries no first-event guard, unlike the SCHEDULED branch alongside it, so for a request that is queued more than once the recorded start is the most recent QUEUED event rather than the first — which matters when reading queue-time for re-queued requests.

Metric

request_queue_time_seconds

Applies when

V1 metricsIterationStats.update_from_events engine-core event accounting

Evidence

vLLM v0.23.0 v1 metrics stats.py(vllm/v1/metrics/stats.py:416-419)
definesprimarysource_codecode_introspection

Open cited lines in immutable upstream source ↗

416:         for event in events:
417:             if event.type == EngineCoreEventType.QUEUED:
418:                 req_stats.queued_ts = event.timestamp
419:                 lora_states.request_waiting(req_id, lora_name)

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

  • how many QUEUED events a request emits under any given workload
  • whether repeated queueing of a request indicates a fault

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.