Schema.ai· vLLMA curated, source-grounded knowledge base for vLLM operations. Search above for building blocks, or browse by category. Schema.ai returns evidence-backed ingredients, not answers.
Start here for a high-level map of what Schema.ai knows about vLLM. Topics group related claims, surfaces, and known gaps into the operational areas a human visitor is most likely to evaluate first.
Coverage for the vLLM v0.23.0 first-party prefix-cache counters and how to compute and interpret the prefix cache hit rate.
Strong for what vllm:prefix_cache_queries and vllm:prefix_cache_hits count (tokens), where they are set from, and how to compute hit rate; none for healthy hit-rate thresholds or workload-specific tuning. Known gaps are tracked explicitly so coverage is not o…
Coverage for a small vLLM v0.23.0 metric slice that exposes scheduler queue state, KV cache usage, and preemption signals.
Strong for whether the selected v0.23.0 metrics exist and what source fields they observe; weak for alert thresholds and workload-specific interpretation. Known gaps are tracked explicitly so coverage is not overstated.
Scenarios show concrete operator question shapes and whether the current corpus can answer them. They are a practical way to understand product coverage before drilling into individual claims or metrics.
prometheus_client renames samples at exposition: counters gain _total and histograms emit _bucket/_count/_sum series, so the names operators see in scrapes and PromQL differ from the declared registration names. Before 2026-07-15 the _total form dre…
The vLLM design docs record prefix-cache activity as two token-denominated counters but state the metric of interest is the derived hit rate. The rationale section never names the real metrics (its PromQL example uses placeholder names), so no keywo…