vLLM v0.23.0 · Version scoped

In vLLM v0.23.0, `decode_time` is computed as `req_stats.last_token_ts` - `req_stats.first_token_ts`; the source comment describes the decode interval as from first `NEW_TOKEN` to last `NEW_TOKEN` and says any preemptions during decode are included.

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

Why this matters

Useful for questions about what request_decode_time_seconds measures and whether decode-phase preemptions are included in that duration.

Metric

request_decode_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:446-448)

definesprimarysource_codecode_introspection

Open cited lines in immutable upstream source ↗

446:         # Decode interval is from first NEW_TOKEN to last NEW_TOKEN
447:         # Any preemptions during decode are included
448:         decode_time = req_stats.last_token_ts - req_stats.first_token_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 decode-time durations (workload-dependent)
how much of a given decode_time observation is attributable to preemptions
decode interval semantics in vLLM versions other than v0.23.0

Guards

vllm_version = v0.23.0
metric_name = vllm:request_decode_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.