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

Grounded vLLM operational knowledge for AI SRE

Schema.ai is a grounding layer for vLLM source code and official docs that lets AI tools reason more reliably about how vLLM works in production.

Search results for "What denominator should I use for vLLM request error rate"

Answerableanswerable

The local vLLM corpus has source-grounded blocks matching the query terms.

35 results

Atomic, version-qualified results. Expand evidence only when you need the source text.

factclaim.vllm.metric.e2e_request_latency_seconds.v0230.guarded_guidance

In vLLM v0.23.0, vllm:e2e_request_latency_seconds use phase histograms as companions before assigning cause; compare like request populations and workload distributions.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics stats.pyvllm/v1/metrics/loggers.py:430–475
        finish_reason: "FinishReason",
        request_id: str,
        num_prompt_tokens: int,
        max_tokens_param: int | None,
        req_stats: RequestStateStats,
        num_cached_tokens: int = 0,
    ):
        e2e_latency = self._time_since(req_stats.arrival_time)

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

        # Prefill interval is from first SCHEDULED to first NEW_TOKEN
        # Any preemptions during prefill is included in the interval
        prefill_time = req_stats.first_token_ts - req_stats.scheduled_ts

        # Decode interval is from first NEW_TOKEN to last NEW_TOKEN
        # Any preemptions during decode are included
        decode_time = req_stats.last_token_ts - req_stats.first_token_ts

        # Inference interval is from first SCHEDULED to last NEW_TOKEN
        # Any preemptions during prefill or decode are included
        inference_time = req_stats.last_token_ts - req_stats.scheduled_ts

        # Do not count the token generated by the prefill phase
        mean_time_per_output_token = (
            decode_time / (req_stats.num_generation_tokens - 1)
            if req_stats.num_generation_tokens - 1 > 0
            else 0
        )

        finished_req = FinishedRequestStats(
            finish_reason=finish_reason,
            request_id=request_id,
            e2e_latency=e2e_latency,
            num_prompt_tokens=num_prompt_tokens,
            num_generation_tokens=req_stats.num_generation_tokens,
            max_tokens_param=max_tokens_param,
            queued_time=queued_time,
            prefill_time=prefill_time,
            inference_time=inference_time,
            decode_time=decode_time,
            mean_time_per_output_token=mean_time_per_output_token,
            is_corrupted=req_stats.is_corrupted,
            num_cached_tokens=num_cached_tokens,
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.generation_tokens.v0230.guarded_guidance

In vLLM v0.23.0, vllm:generation_tokens use rate for aggregate decode throughput and pair it with ITL/TPOT/TTFT distributions before judging user experience.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1149–1166
        self.counter_num_preempted_reqs[engine_idx].inc(
            iteration_stats.num_preempted_reqs
        )
        self.counter_prompt_tokens[engine_idx].inc(iteration_stats.num_prompt_tokens)
        # Labeled prompt token counters by source
        pts = iteration_stats.prompt_token_stats
        for source in PromptTokenStats.ALL_SOURCES:
            self.counter_prompt_tokens_by_source[source][engine_idx].inc(
                pts.get_by_source(source)
            )
        self.counter_prompt_tokens_cached[engine_idx].inc(pts.cached_tokens)
        self.counter_generation_tokens[engine_idx].inc(
            iteration_stats.num_generation_tokens
        )
        self.histogram_iteration_tokens[engine_idx].observe(
            iteration_stats.prompt_token_stats.computed
            + iteration_stats.num_generation_tokens
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.generation_tokens.v0230.prometheus_type

In vLLM v0.23.0, vllm:generation_tokens is registered as a Prometheus counter.

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • the metric's unit of measure
  • what the metric measures semantically
  • a healthy or expected value range
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:662–666
        counter_generation_tokens = self._counter_cls(
            name="vllm:generation_tokens",
            documentation="Number of generation tokens processed.",
            labelnames=labelnames,
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.inter_token_latency_seconds.v0230.guarded_guidance

In vLLM v0.23.0, vllm:inter_token_latency_seconds use it to inspect token-level decode cadence; do not equate its histogram count with requests or its mean with request-weighted TPOT.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics stats.pyvllm/v1/metrics/loggers.py:360–405
        lora_name: str | None,
    ):
        num_new_generation_tokens = len(output.new_token_ids)

        self.num_generation_tokens += num_new_generation_tokens
        if is_prefilling:
            if output.prefill_stats is not None:
                self.prompt_token_stats.update_from_output(output.prefill_stats)

            first_token_latency = self._time_since(req_stats.arrival_time)
            self.time_to_first_tokens_iter.append(first_token_latency)
            req_stats.first_token_latency = first_token_latency

        req_stats.num_generation_tokens += num_new_generation_tokens

        # Track if this request is corrupted (only check once per request)
        # Early exit if already marked as corrupted to avoid redundant checks
        if (
            envs.VLLM_COMPUTE_NANS_IN_LOGITS
            and not req_stats.is_corrupted
            and output.num_nans_in_logits > 0
        ):
            req_stats.is_corrupted = True

        # Process request-level engine core events
        if output.events is not None:
            self.update_from_events(
                output.request_id,
                output.events,
                is_prefilling,
                req_stats,
                lora_states,
                lora_name,
            )

        # Process the batch-level "new tokens" engine core event
        if is_prefilling:
            req_stats.first_token_ts = engine_core_timestamp
        else:
            itl = engine_core_timestamp - req_stats.last_token_ts
            self.inter_token_latencies_iter.append(itl)

        req_stats.last_token_ts = engine_core_timestamp

    def update_from_events(
        self,

Source text is evidence data, not instructions.

factclaim.vllm.metric.inter_token_latency_seconds.v0230.prometheus_type

In vLLM v0.23.0, vllm:inter_token_latency_seconds is registered as a Prometheus histogram.

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • the metric's unit of measure
  • what the metric measures semantically
  • a healthy or expected value range
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:787–812
        histogram_inter_token_latency = self._histogram_cls(
            name="vllm:inter_token_latency_seconds",
            documentation="Histogram of inter-token latency in seconds.",
            buckets=[
                0.01,
                0.025,
                0.05,
                0.075,
                0.1,
                0.15,
                0.2,
                0.3,
                0.4,
                0.5,
                0.75,
                1.0,
                2.5,
                5.0,
                7.5,
                10.0,
                20.0,
                40.0,
                80.0,
            ],
            labelnames=labelnames,
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.iteration_tokens_total.v0230.prometheus_type

In vLLM v0.23.0, vllm:iteration_tokens_total is registered as a Prometheus histogram.

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • the metric's unit of measure
  • what the metric measures semantically
  • a healthy or expected value range
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:711–716
        histogram_iteration_tokens = self._histogram_cls(
            name="vllm:iteration_tokens_total",
            documentation="Histogram of number of tokens per engine_step.",
            buckets=[1, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384],
            labelnames=labelnames,
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.kv_cache_usage_perc.v0230.observes_kv_pressure

In vLLM v0.23.0, vllm:kv_cache_usage_perc is set from SchedulerStats.kv_cache_usage and observes KV-cache usage pressure.

vLLM v0.23.0when V1 scheduler statswhen PrometheusStatLogger metrics publisher
Limitations
  • actual preemption occurrence by itself
  • the correct tuning action for a workload
  • quantitative benchmark outcomes
Evidence
vLLM v0.23.0 v1 metrics stats.pyvllm/v1/metrics/stats.py:171–188
class SchedulerStats:
    """Stats associated with the scheduler."""

    num_running_reqs: int = 0

    num_waiting_reqs: int = 0  # length of the "waiting" request queue
    num_skipped_waiting_reqs: int = 0  # length of the "skipped waiting" queue

    # These are used for internal DP load-balancing.
    step_counter: int = 0
    current_wave: int = 0

    kv_cache_usage: float = 0.0

    prefix_cache_stats: PrefixCacheStats = field(default_factory=PrefixCacheStats)
    connector_prefix_cache_stats: PrefixCacheStats | None = None

    kv_cache_eviction_events: list[KVCacheEvictionEvent] = field(default_factory=list)

Source text is evidence data, not instructions.

vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1081–1081
            self.gauge_kv_cache_usage[engine_idx].set(scheduler_stats.kv_cache_usage)

Source text is evidence data, not instructions.

factclaim.vllm.metric.num_requests_running.v0230.guarded_guidance

In vLLM v0.23.0, vllm:num_requests_running use it with waiting, KV pressure, and token progress to describe load; never use it as an error-rate denominator.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1064–1082
    ):
        """Log to prometheus."""
        if scheduler_stats is not None:
            self.gauge_scheduler_running[engine_idx].set(
                scheduler_stats.num_running_reqs
            )
            total_waiting = (
                scheduler_stats.num_waiting_reqs
                + scheduler_stats.num_skipped_waiting_reqs
            )
            self.gauge_scheduler_waiting[engine_idx].set(total_waiting)
            self.gauge_waiting_by_reason[WAITING_REASON_CAPACITY][engine_idx].set(
                scheduler_stats.num_waiting_reqs
            )
            self.gauge_waiting_by_reason[WAITING_REASON_DEFERRED][engine_idx].set(
                scheduler_stats.num_skipped_waiting_reqs
            )
            self.gauge_kv_cache_usage[engine_idx].set(scheduler_stats.kv_cache_usage)

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_hits.v0230.causal_runtime_semantics

In vLLM v0.23.0, vllm:prefix_cache_hits increments from SchedulerStats.prefix_cache_stats.hits on each scheduler-stats logging update.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 metrics design docsdocs/design/metrics.md:405–432
### Prefix Cache metrics

The discussion in <https://github.com/vllm-project/vllm/issues/10582> about adding prefix cache metrics yielded
some interesting points which may be relevant to how we approach
future metrics.

Every time the prefix cache is queried, we record the number of tokens
queried and the number of queried tokens present in the cache
(i.e. hits).

However, the metric of interest is the hit rate - i.e. the number of
hits per query.

In the case of logging, we expect the user is best served by
calculating the hit rate over a fixed number of the most recent
queries (the interval is fixed to 1k most recent queries for now).

In the case of Prometheus though, we should take advantage of the
time-series nature of Prometheus and allow the user to calculate the
hit rate over an interval of their choosing. For example, a PromQL
query to calculate the hit interval of the past 5 minutes:

```text
rate(cache_query_hit[5m]) / rate(cache_query_total[5m])
```

To achieve this, we should record the queries and hits as counters in
Prometheus, rather than recording the hit rate as a gauge.

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_hits.v0230.guarded_guidance

In vLLM v0.23.0, vllm:prefix_cache_hits divide same-window hit and query rates; no universal healthy percentage follows because reuse is workload-dependent.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 metrics design docsdocs/design/metrics.md:405–432
### Prefix Cache metrics

The discussion in <https://github.com/vllm-project/vllm/issues/10582> about adding prefix cache metrics yielded
some interesting points which may be relevant to how we approach
future metrics.

Every time the prefix cache is queried, we record the number of tokens
queried and the number of queried tokens present in the cache
(i.e. hits).

However, the metric of interest is the hit rate - i.e. the number of
hits per query.

In the case of logging, we expect the user is best served by
calculating the hit rate over a fixed number of the most recent
queries (the interval is fixed to 1k most recent queries for now).

In the case of Prometheus though, we should take advantage of the
time-series nature of Prometheus and allow the user to calculate the
hit rate over an interval of their choosing. For example, a PromQL
query to calculate the hit interval of the past 5 minutes:

```text
rate(cache_query_hit[5m]) / rate(cache_query_total[5m])
```

To achieve this, we should record the queries and hits as counters in
Prometheus, rather than recording the hit rate as a gauge.

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_hits.v0230.hit_rate_interpretation

The vLLM v0.23.0 metrics design docs state the metric of interest is the prefix cache hit rate (hits per query): the counters are exposed raw so operators compute the rate over an interval of their choosing with PromQL (rate(hits)/rate(queries)); vLLM's own logging equivalent aggregates hit_rate over the most recent queries.

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • a healthy or target hit rate (workload-dependent)
  • how to increase hit rate for a given workload
Evidence
vLLM v0.23.0 metrics design docsdesign/metrics.md:405–432
### Prefix Cache metrics

The discussion in <https://github.com/vllm-project/vllm/issues/10582> about adding prefix cache metrics yielded
some interesting points which may be relevant to how we approach
future metrics.

Every time the prefix cache is queried, we record the number of tokens
queried and the number of queried tokens present in the cache
(i.e. hits).

However, the metric of interest is the hit rate - i.e. the number of
hits per query.

In the case of logging, we expect the user is best served by
calculating the hit rate over a fixed number of the most recent
queries (the interval is fixed to 1k most recent queries for now).

In the case of Prometheus though, we should take advantage of the
time-series nature of Prometheus and allow the user to calculate the
hit rate over an interval of their choosing. For example, a PromQL
query to calculate the hit interval of the past 5 minutes:

```text
rate(cache_query_hit[5m]) / rate(cache_query_total[5m])
```

To achieve this, we should record the queries and hits as counters in
Prometheus, rather than recording the hit rate as a gauge.

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_hits.v0230.interpretation_composition

In vLLM v0.23.0, vllm:prefix_cache_hits is the token numerator for a same-label, same-window prefix-cache hit ratio.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 metrics design docsdocs/design/metrics.md:405–432
### Prefix Cache metrics

The discussion in <https://github.com/vllm-project/vllm/issues/10582> about adding prefix cache metrics yielded
some interesting points which may be relevant to how we approach
future metrics.

Every time the prefix cache is queried, we record the number of tokens
queried and the number of queried tokens present in the cache
(i.e. hits).

However, the metric of interest is the hit rate - i.e. the number of
hits per query.

In the case of logging, we expect the user is best served by
calculating the hit rate over a fixed number of the most recent
queries (the interval is fixed to 1k most recent queries for now).

In the case of Prometheus though, we should take advantage of the
time-series nature of Prometheus and allow the user to calculate the
hit rate over an interval of their choosing. For example, a PromQL
query to calculate the hit interval of the past 5 minutes:

```text
rate(cache_query_hit[5m]) / rate(cache_query_total[5m])
```

To achieve this, we should record the queries and hits as counters in
Prometheus, rather than recording the hit rate as a gauge.

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_hits.v0230.measurement_semantics

In vLLM v0.23.0, vllm:prefix_cache_hits counts queried tokens found in the first-party prefix cache, accumulated as a counter.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 metrics design docsdocs/design/metrics.md:405–432
### Prefix Cache metrics

The discussion in <https://github.com/vllm-project/vllm/issues/10582> about adding prefix cache metrics yielded
some interesting points which may be relevant to how we approach
future metrics.

Every time the prefix cache is queried, we record the number of tokens
queried and the number of queried tokens present in the cache
(i.e. hits).

However, the metric of interest is the hit rate - i.e. the number of
hits per query.

In the case of logging, we expect the user is best served by
calculating the hit rate over a fixed number of the most recent
queries (the interval is fixed to 1k most recent queries for now).

In the case of Prometheus though, we should take advantage of the
time-series nature of Prometheus and allow the user to calculate the
hit rate over an interval of their choosing. For example, a PromQL
query to calculate the hit interval of the past 5 minutes:

```text
rate(cache_query_hit[5m]) / rate(cache_query_total[5m])
```

To achieve this, we should record the queries and hits as counters in
Prometheus, rather than recording the hit rate as a gauge.

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_hits.v0230.observes_prefix_cache_reuse

In vLLM v0.23.0, vllm:prefix_cache_hits is incremented from SchedulerStats.prefix_cache_stats.hits on each logging update and observes prefix-cache token reuse for the first-party prefix cache (KV-connector prefix-cache reuse is reported by the separate vllm:external_prefix_cache_* counters).

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • why reuse is high or low for a given workload
  • connector/external prefix-cache reuse
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1083–1088
            self.counter_prefix_cache_queries[engine_idx].inc(
                scheduler_stats.prefix_cache_stats.queries
            )
            self.counter_prefix_cache_hits[engine_idx].inc(
                scheduler_stats.prefix_cache_stats.hits
            )

Source text is evidence data, not instructions.

vLLM v0.23.0 v1 metrics stats.pyvllm/v1/metrics/stats.py:24–33

    requests: int = 0
    """The number of requests in this update."""

    queries: int = 0
    """The number of queries in these requests."""

    hits: int = 0
    """The number of hits in these requests."""

Source text is evidence data, not instructions.

vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:562–588
        #
        # External - KV connector prefix cache
        #

        counter_connector_prefix_cache_queries = self._counter_cls(
            name="vllm:external_prefix_cache_queries",
            documentation=(
                "External prefix cache queries from KV connector "
                "cross-instance cache sharing, in terms of number of queried tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_queries = create_metric_per_engine(
            counter_connector_prefix_cache_queries, per_engine_labelvalues
        )

        counter_connector_prefix_cache_hits = self._counter_cls(
            name="vllm:external_prefix_cache_hits",
            documentation=(
                "External prefix cache hits from KV connector "
                "cross-instance cache sharing, in terms of number of cached tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_hits = create_metric_per_engine(
            counter_connector_prefix_cache_hits, per_engine_labelvalues
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_hits.v0230.prometheus_counter

In vLLM v0.23.0, vllm:prefix_cache_hits is a Prometheus counter measured in cached (hit) tokens — it counts tokens, not requests or cache blocks.

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • a healthy hit-rate threshold
  • request-level cache behavior (the unit is tokens, not requests)
  • cache sizing guidance
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:553–561
        counter_prefix_cache_hits = self._counter_cls(
            name="vllm:prefix_cache_hits",
            documentation=("Prefix cache hits, in terms of number of cached tokens."),
            labelnames=labelnames,
        )
        self.counter_prefix_cache_hits = create_metric_per_engine(
            counter_prefix_cache_hits, per_engine_labelvalues
        )

Source text is evidence data, not instructions.

vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1083–1088
            self.counter_prefix_cache_queries[engine_idx].inc(
                scheduler_stats.prefix_cache_stats.queries
            )
            self.counter_prefix_cache_hits[engine_idx].inc(
                scheduler_stats.prefix_cache_stats.hits
            )

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_queries.v0230.causal_runtime_semantics

In vLLM v0.23.0, vllm:prefix_cache_queries increments from SchedulerStats.prefix_cache_stats.queries on each scheduler-stats logging update.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:562–588
        #
        # External - KV connector prefix cache
        #

        counter_connector_prefix_cache_queries = self._counter_cls(
            name="vllm:external_prefix_cache_queries",
            documentation=(
                "External prefix cache queries from KV connector "
                "cross-instance cache sharing, in terms of number of queried tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_queries = create_metric_per_engine(
            counter_connector_prefix_cache_queries, per_engine_labelvalues
        )

        counter_connector_prefix_cache_hits = self._counter_cls(
            name="vllm:external_prefix_cache_hits",
            documentation=(
                "External prefix cache hits from KV connector "
                "cross-instance cache sharing, in terms of number of cached tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_hits = create_metric_per_engine(
            counter_connector_prefix_cache_hits, per_engine_labelvalues
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_queries.v0230.guarded_guidance

In vLLM v0.23.0, vllm:prefix_cache_queries use rate or increase over a chosen window with prefix_cache_hits; do not interpret the cumulative total as a rate.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:562–588
        #
        # External - KV connector prefix cache
        #

        counter_connector_prefix_cache_queries = self._counter_cls(
            name="vllm:external_prefix_cache_queries",
            documentation=(
                "External prefix cache queries from KV connector "
                "cross-instance cache sharing, in terms of number of queried tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_queries = create_metric_per_engine(
            counter_connector_prefix_cache_queries, per_engine_labelvalues
        )

        counter_connector_prefix_cache_hits = self._counter_cls(
            name="vllm:external_prefix_cache_hits",
            documentation=(
                "External prefix cache hits from KV connector "
                "cross-instance cache sharing, in terms of number of cached tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_hits = create_metric_per_engine(
            counter_connector_prefix_cache_hits, per_engine_labelvalues
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_queries.v0230.interpretation_composition

In vLLM v0.23.0, vllm:prefix_cache_queries is the token denominator for a same-label, same-window prefix-cache hit ratio.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:562–588
        #
        # External - KV connector prefix cache
        #

        counter_connector_prefix_cache_queries = self._counter_cls(
            name="vllm:external_prefix_cache_queries",
            documentation=(
                "External prefix cache queries from KV connector "
                "cross-instance cache sharing, in terms of number of queried tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_queries = create_metric_per_engine(
            counter_connector_prefix_cache_queries, per_engine_labelvalues
        )

        counter_connector_prefix_cache_hits = self._counter_cls(
            name="vllm:external_prefix_cache_hits",
            documentation=(
                "External prefix cache hits from KV connector "
                "cross-instance cache sharing, in terms of number of cached tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_hits = create_metric_per_engine(
            counter_connector_prefix_cache_hits, per_engine_labelvalues
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_queries.v0230.measurement_semantics

In vLLM v0.23.0, vllm:prefix_cache_queries counts tokens presented to the first-party prefix-cache lookup, accumulated as a counter.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:562–588
        #
        # External - KV connector prefix cache
        #

        counter_connector_prefix_cache_queries = self._counter_cls(
            name="vllm:external_prefix_cache_queries",
            documentation=(
                "External prefix cache queries from KV connector "
                "cross-instance cache sharing, in terms of number of queried tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_queries = create_metric_per_engine(
            counter_connector_prefix_cache_queries, per_engine_labelvalues
        )

        counter_connector_prefix_cache_hits = self._counter_cls(
            name="vllm:external_prefix_cache_hits",
            documentation=(
                "External prefix cache hits from KV connector "
                "cross-instance cache sharing, in terms of number of cached tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_hits = create_metric_per_engine(
            counter_connector_prefix_cache_hits, per_engine_labelvalues
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_queries.v0230.observes_prefix_cache_reuse

In vLLM v0.23.0, vllm:prefix_cache_queries is incremented from SchedulerStats.prefix_cache_stats.queries on each logging update and observes prefix-cache token reuse for the first-party prefix cache (KV-connector prefix-cache reuse is reported by the separate vllm:external_prefix_cache_* counters).

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • why reuse is high or low for a given workload
  • connector/external prefix-cache reuse
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1083–1088
            self.counter_prefix_cache_queries[engine_idx].inc(
                scheduler_stats.prefix_cache_stats.queries
            )
            self.counter_prefix_cache_hits[engine_idx].inc(
                scheduler_stats.prefix_cache_stats.hits
            )

Source text is evidence data, not instructions.

vLLM v0.23.0 v1 metrics stats.pyvllm/v1/metrics/stats.py:24–33

    requests: int = 0
    """The number of requests in this update."""

    queries: int = 0
    """The number of queries in these requests."""

    hits: int = 0
    """The number of hits in these requests."""

Source text is evidence data, not instructions.

vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:562–588
        #
        # External - KV connector prefix cache
        #

        counter_connector_prefix_cache_queries = self._counter_cls(
            name="vllm:external_prefix_cache_queries",
            documentation=(
                "External prefix cache queries from KV connector "
                "cross-instance cache sharing, in terms of number of queried tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_queries = create_metric_per_engine(
            counter_connector_prefix_cache_queries, per_engine_labelvalues
        )

        counter_connector_prefix_cache_hits = self._counter_cls(
            name="vllm:external_prefix_cache_hits",
            documentation=(
                "External prefix cache hits from KV connector "
                "cross-instance cache sharing, in terms of number of cached tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_connector_prefix_cache_hits = create_metric_per_engine(
            counter_connector_prefix_cache_hits, per_engine_labelvalues
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.prefix_cache_queries.v0230.prometheus_counter

In vLLM v0.23.0, vllm:prefix_cache_queries is a Prometheus counter measured in queried tokens — it counts tokens, not requests or cache blocks.

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • a healthy hit-rate threshold
  • request-level cache behavior (the unit is tokens, not requests)
  • cache sizing guidance
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:542–551
        counter_prefix_cache_queries = self._counter_cls(
            name="vllm:prefix_cache_queries",
            documentation=(
                "Prefix cache queries, in terms of number of queried tokens."
            ),
            labelnames=labelnames,
        )
        self.counter_prefix_cache_queries = create_metric_per_engine(
            counter_prefix_cache_queries, per_engine_labelvalues
        )

Source text is evidence data, not instructions.

vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1083–1088
            self.counter_prefix_cache_queries[engine_idx].inc(
                scheduler_stats.prefix_cache_stats.queries
            )
            self.counter_prefix_cache_hits[engine_idx].inc(
                scheduler_stats.prefix_cache_stats.hits
            )

Source text is evidence data, not instructions.

factclaim.vllm.metric.prompt_tokens.v0230.guarded_guidance

In vLLM v0.23.0, vllm:prompt_tokens use rate for prompt throughput and pair it with cached/computed-token and queue/TTFT metrics before drawing efficiency conclusions.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1149–1166
        self.counter_num_preempted_reqs[engine_idx].inc(
            iteration_stats.num_preempted_reqs
        )
        self.counter_prompt_tokens[engine_idx].inc(iteration_stats.num_prompt_tokens)
        # Labeled prompt token counters by source
        pts = iteration_stats.prompt_token_stats
        for source in PromptTokenStats.ALL_SOURCES:
            self.counter_prompt_tokens_by_source[source][engine_idx].inc(
                pts.get_by_source(source)
            )
        self.counter_prompt_tokens_cached[engine_idx].inc(pts.cached_tokens)
        self.counter_generation_tokens[engine_idx].inc(
            iteration_stats.num_generation_tokens
        )
        self.histogram_iteration_tokens[engine_idx].observe(
            iteration_stats.prompt_token_stats.computed
            + iteration_stats.num_generation_tokens
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.prompt_tokens.v0230.prometheus_type

In vLLM v0.23.0, vllm:prompt_tokens is registered as a Prometheus counter.

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • the metric's unit of measure
  • what the metric measures semantically
  • a healthy or expected value range
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:628–632
        counter_prompt_tokens = self._counter_cls(
            name="vllm:prompt_tokens",
            documentation="Number of prefill tokens processed.",
            labelnames=labelnames,
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.request_prefill_kv_computed_tokens.v0230.causal_runtime_semantics

In vLLM v0.23.0, vllm:request_prefill_kv_computed_tokens is computed in finished-request logging after request completion from num_prompt_tokens and num_cached_tokens.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1179–1213
        for finished_request in iteration_stats.finished_requests:
            self.counter_request_success[finished_request.finish_reason][
                engine_idx
            ].inc()
            self.histogram_e2e_time_request[engine_idx].observe(
                finished_request.e2e_latency
            )
            self.histogram_queue_time_request[engine_idx].observe(
                finished_request.queued_time
            )
            self.histogram_prefill_time_request[engine_idx].observe(
                finished_request.prefill_time
            )
            self.histogram_inference_time_request[engine_idx].observe(
                finished_request.inference_time
            )
            self.histogram_decode_time_request[engine_idx].observe(
                finished_request.decode_time
            )
            # Calculate prefill KV compute (excludes cached tokens)
            prefill_kv_computed = finished_request.num_prompt_tokens - max(
                finished_request.num_cached_tokens, 0
            )
            self.histogram_prefill_kv_computed_request[engine_idx].observe(
                prefill_kv_computed
            )
            self.histogram_num_prompt_tokens_request[engine_idx].observe(
                finished_request.num_prompt_tokens
            )
            self.histogram_num_generation_tokens_request[engine_idx].observe(
                finished_request.num_generation_tokens
            )
            self.histogram_request_time_per_output_token[engine_idx].observe(
                finished_request.mean_time_per_output_token
            )

Source text is evidence data, not instructions.

factclaim.vllm.metric.request_prefill_kv_computed_tokens.v0230.guarded_guidance

In vLLM v0.23.0, vllm:request_prefill_kv_computed_tokens compare distributions under matched workloads; use cached-token counters as companions and do not treat one bucket count as token throughput.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1179–1213
        for finished_request in iteration_stats.finished_requests:
            self.counter_request_success[finished_request.finish_reason][
                engine_idx
            ].inc()
            self.histogram_e2e_time_request[engine_idx].observe(
                finished_request.e2e_latency
            )
            self.histogram_queue_time_request[engine_idx].observe(
                finished_request.queued_time
            )
            self.histogram_prefill_time_request[engine_idx].observe(
                finished_request.prefill_time
            )
            self.histogram_inference_time_request[engine_idx].observe(
                finished_request.inference_time
            )
            self.histogram_decode_time_request[engine_idx].observe(
                finished_request.decode_time
            )
            # Calculate prefill KV compute (excludes cached tokens)
            prefill_kv_computed = finished_request.num_prompt_tokens - max(
                finished_request.num_cached_tokens, 0
            )
            self.histogram_prefill_kv_computed_request[engine_idx].observe(
                prefill_kv_computed
            )
            self.histogram_num_prompt_tokens_request[engine_idx].observe(
                finished_request.num_prompt_tokens
            )
            self.histogram_num_generation_tokens_request[engine_idx].observe(
                finished_request.num_generation_tokens
            )
            self.histogram_request_time_per_output_token[engine_idx].observe(
                finished_request.mean_time_per_output_token
            )

Source text is evidence data, not instructions.

factclaim.vllm.metric.request_prefill_kv_computed_tokens.v0230.interpretation_composition

In vLLM v0.23.0, vllm:request_prefill_kv_computed_tokens measures newly computed prefill KV work per completed request, not total prompt length when caching contributes.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1179–1213
        for finished_request in iteration_stats.finished_requests:
            self.counter_request_success[finished_request.finish_reason][
                engine_idx
            ].inc()
            self.histogram_e2e_time_request[engine_idx].observe(
                finished_request.e2e_latency
            )
            self.histogram_queue_time_request[engine_idx].observe(
                finished_request.queued_time
            )
            self.histogram_prefill_time_request[engine_idx].observe(
                finished_request.prefill_time
            )
            self.histogram_inference_time_request[engine_idx].observe(
                finished_request.inference_time
            )
            self.histogram_decode_time_request[engine_idx].observe(
                finished_request.decode_time
            )
            # Calculate prefill KV compute (excludes cached tokens)
            prefill_kv_computed = finished_request.num_prompt_tokens - max(
                finished_request.num_cached_tokens, 0
            )
            self.histogram_prefill_kv_computed_request[engine_idx].observe(
                prefill_kv_computed
            )
            self.histogram_num_prompt_tokens_request[engine_idx].observe(
                finished_request.num_prompt_tokens
            )
            self.histogram_num_generation_tokens_request[engine_idx].observe(
                finished_request.num_generation_tokens
            )
            self.histogram_request_time_per_output_token[engine_idx].observe(
                finished_request.mean_time_per_output_token
            )

Source text is evidence data, not instructions.

factclaim.vllm.metric.request_prefill_kv_computed_tokens.v0230.measurement_semantics

In vLLM v0.23.0, vllm:request_prefill_kv_computed_tokens observes one histogram sample per finished request: prompt tokens minus non-negative cached tokens.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1179–1213
        for finished_request in iteration_stats.finished_requests:
            self.counter_request_success[finished_request.finish_reason][
                engine_idx
            ].inc()
            self.histogram_e2e_time_request[engine_idx].observe(
                finished_request.e2e_latency
            )
            self.histogram_queue_time_request[engine_idx].observe(
                finished_request.queued_time
            )
            self.histogram_prefill_time_request[engine_idx].observe(
                finished_request.prefill_time
            )
            self.histogram_inference_time_request[engine_idx].observe(
                finished_request.inference_time
            )
            self.histogram_decode_time_request[engine_idx].observe(
                finished_request.decode_time
            )
            # Calculate prefill KV compute (excludes cached tokens)
            prefill_kv_computed = finished_request.num_prompt_tokens - max(
                finished_request.num_cached_tokens, 0
            )
            self.histogram_prefill_kv_computed_request[engine_idx].observe(
                prefill_kv_computed
            )
            self.histogram_num_prompt_tokens_request[engine_idx].observe(
                finished_request.num_prompt_tokens
            )
            self.histogram_num_generation_tokens_request[engine_idx].observe(
                finished_request.num_generation_tokens
            )
            self.histogram_request_time_per_output_token[engine_idx].observe(
                finished_request.mean_time_per_output_token
            )

Source text is evidence data, not instructions.

factclaim.vllm.metric.request_queue_time_seconds.v0230.guarded_guidance

In vLLM v0.23.0, vllm:request_queue_time_seconds use quantiles with running/KV/token-progress metrics to distinguish admission delay from decode delay; no universal threshold is established.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics stats.pyvllm/v1/metrics/loggers.py:406–455
        req_id: str,
        events: list["EngineCoreEvent"],
        is_prefilling: bool,
        req_stats: RequestStateStats,
        lora_states: "LoRARequestStates",
        lora_name: str | None,
    ):
        # Avoid circular dependency
        from vllm.v1.engine import EngineCoreEventType

        for event in events:
            if event.type == EngineCoreEventType.QUEUED:
                req_stats.queued_ts = event.timestamp
                lora_states.request_waiting(req_id, lora_name)
            elif event.type == EngineCoreEventType.SCHEDULED:
                if req_stats.scheduled_ts == 0.0:  # ignore preemptions
                    req_stats.scheduled_ts = event.timestamp
                lora_states.request_running(req_id, lora_name)
            elif event.type == EngineCoreEventType.PREEMPTED:
                self.num_preempted_reqs += 1
                lora_states.request_waiting(req_id, lora_name)

    def update_from_finished_request(
        self,
        finish_reason: "FinishReason",
        request_id: str,
        num_prompt_tokens: int,
        max_tokens_param: int | None,
        req_stats: RequestStateStats,
        num_cached_tokens: int = 0,
    ):
        e2e_latency = self._time_since(req_stats.arrival_time)

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

        # Prefill interval is from first SCHEDULED to first NEW_TOKEN
        # Any preemptions during prefill is included in the interval
        prefill_time = req_stats.first_token_ts - req_stats.scheduled_ts

        # Decode interval is from first NEW_TOKEN to last NEW_TOKEN
        # Any preemptions during decode are included
        decode_time = req_stats.last_token_ts - req_stats.first_token_ts

        # Inference interval is from first SCHEDULED to last NEW_TOKEN
        # Any preemptions during prefill or decode are included
        inference_time = req_stats.last_token_ts - req_stats.scheduled_ts

        # Do not count the token generated by the prefill phase
        mean_time_per_output_token = (

Source text is evidence data, not instructions.

factclaim.vllm.metric.request_success.v0230.guarded_guidance

In vLLM v0.23.0, vllm:request_success sum only intended finish reasons for the question; use API or ingress telemetry for a denominator covering every HTTP attempt.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:1179–1188
        for finished_request in iteration_stats.finished_requests:
            self.counter_request_success[finished_request.finish_reason][
                engine_idx
            ].inc()
            self.histogram_e2e_time_request[engine_idx].observe(
                finished_request.e2e_latency
            )
            self.histogram_queue_time_request[engine_idx].observe(
                finished_request.queued_time
            )

Source text is evidence data, not instructions.

factclaim.vllm.metric.request_time_per_output_token_seconds.v0230.guarded_guidance

In vLLM v0.23.0, vllm:request_time_per_output_token_seconds use it for per-request decode experience; compare distributions under matched output lengths rather than substituting aggregate tokens per second.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics stats.pyvllm/v1/metrics/loggers.py:439–475
        # Queued interval is from first QUEUED event to first SCHEDULED
        queued_time = req_stats.scheduled_ts - req_stats.queued_ts

        # Prefill interval is from first SCHEDULED to first NEW_TOKEN
        # Any preemptions during prefill is included in the interval
        prefill_time = req_stats.first_token_ts - req_stats.scheduled_ts

        # Decode interval is from first NEW_TOKEN to last NEW_TOKEN
        # Any preemptions during decode are included
        decode_time = req_stats.last_token_ts - req_stats.first_token_ts

        # Inference interval is from first SCHEDULED to last NEW_TOKEN
        # Any preemptions during prefill or decode are included
        inference_time = req_stats.last_token_ts - req_stats.scheduled_ts

        # Do not count the token generated by the prefill phase
        mean_time_per_output_token = (
            decode_time / (req_stats.num_generation_tokens - 1)
            if req_stats.num_generation_tokens - 1 > 0
            else 0
        )

        finished_req = FinishedRequestStats(
            finish_reason=finish_reason,
            request_id=request_id,
            e2e_latency=e2e_latency,
            num_prompt_tokens=num_prompt_tokens,
            num_generation_tokens=req_stats.num_generation_tokens,
            max_tokens_param=max_tokens_param,
            queued_time=queued_time,
            prefill_time=prefill_time,
            inference_time=inference_time,
            decode_time=decode_time,
            mean_time_per_output_token=mean_time_per_output_token,
            is_corrupted=req_stats.is_corrupted,
            num_cached_tokens=num_cached_tokens,
        )

Source text is evidence data, not instructions.

factclaim.vllm.metric.time_to_first_token_seconds.v0230.interpretation_composition

In vLLM v0.23.0, vllm:time_to_first_token_seconds its histogram count follows first-token events and need not equal a finished-request counter across abort and error paths.

vLLM v0.23.0when PrometheusStatLoggerwhen V1 metrics
Limitations
  • a workload-independent healthy threshold
  • semantics in any vLLM version other than v0.23.0
Evidence
vLLM v0.23.0 v1 metrics stats.pyvllm/v1/metrics/loggers.py:360–389
        lora_name: str | None,
    ):
        num_new_generation_tokens = len(output.new_token_ids)

        self.num_generation_tokens += num_new_generation_tokens
        if is_prefilling:
            if output.prefill_stats is not None:
                self.prompt_token_stats.update_from_output(output.prefill_stats)

            first_token_latency = self._time_since(req_stats.arrival_time)
            self.time_to_first_tokens_iter.append(first_token_latency)
            req_stats.first_token_latency = first_token_latency

        req_stats.num_generation_tokens += num_new_generation_tokens

        # Track if this request is corrupted (only check once per request)
        # Early exit if already marked as corrupted to avoid redundant checks
        if (
            envs.VLLM_COMPUTE_NANS_IN_LOGITS
            and not req_stats.is_corrupted
            and output.num_nans_in_logits > 0
        ):
            req_stats.is_corrupted = True

        # Process request-level engine core events
        if output.events is not None:
            self.update_from_events(
                output.request_id,
                output.events,
                is_prefilling,

Source text is evidence data, not instructions.

factclaim.vllm.metric.time_to_first_token_seconds.v0230.prometheus_type

In vLLM v0.23.0, vllm:time_to_first_token_seconds is registered as a Prometheus histogram.

vLLM v0.23.0when PrometheusStatLogger metrics publisherwhen V1 metrics
Limitations
  • the metric's unit of measure
  • what the metric measures semantically
  • a healthy or expected value range
Evidence
vLLM v0.23.0 v1 metrics loggers.pyvllm/v1/metrics/loggers.py:754–782
        histogram_time_to_first_token = self._histogram_cls(
            name="vllm:time_to_first_token_seconds",
            documentation="Histogram of time to first token in seconds.",
            buckets=[
                0.001,
                0.005,
                0.01,
                0.02,
                0.04,
                0.06,
                0.08,
                0.1,
                0.25,
                0.5,
                0.75,
                1.0,
                2.5,
                5.0,
                7.5,
                10.0,
                20.0,
                40.0,
                80.0,
                160.0,
                640.0,
                2560.0,
            ],
            labelnames=labelnames,
        )

Source text is evidence data, not instructions.

use casescenario.vllm.issue-12077-kv-use-versus-cache-residency

Semantics resolve the interpretation; actual reuse requires same-window hit/query observations.

vLLM v0.23.0
Limitations
  • Same-label same-window prefix hit/query rates
  • Controlled repeated-prefix request before eviction

Exact supporting evidence is not available for this result yet.

use casescenario.vllm.issue-35048-throughput-versus-experience

Schema supplies the decomposition; root cause requires controlled A/B or commit bisect.

vLLM v0.23.0
Limitations
  • Fixed matched workload environment and dependencies
  • Same-window throughput and per-request latency distributions

Exact supporting evidence is not available for this result yet.

use casescenario.vllm.issue-38194-prefix-hit-rate-comparability

Schema defines the vLLM side; the other system and matched runtime data are required for comparison.

vLLM v0.23.0
Limitations
  • Both formulas and scopes
  • Identical rendered token streams and routing
  • Matched warm-up and windows

Exact supporting evidence is not available for this result yet.

Coverage gaps

A gap means Schema does not yet hold enough knowledge here; it is not evidence that the thing is absent.

  • vllm:external_prefix_cache_queries/hits (KV-connector prefix cache) are availability-inventoried but carry no semantic claims. — Existence answers are available for the external counters; interpretation claims are not.
  • The corpus has no benchmark or operator evidence for healthy prefix-cache hit-rate ranges; hit rate is workload-dependent (prompt-prefix sharing). — Schema.ai can explain how to compute the hit rate but must not grade an observed value as good or bad.