From 3c9623ac2e20349177e8c3c78752eacdbbcde6c0 Mon Sep 17 00:00:00 2001 From: Seongho Bae Date: Wed, 4 Feb 2026 22:02:21 +0900 Subject: [PATCH] docs: wrap prometheus metric explanation --- docs/my-website/docs/proxy/prometheus.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/docs/my-website/docs/proxy/prometheus.md b/docs/my-website/docs/proxy/prometheus.md index 93429561624..bca492b1bf7 100644 --- a/docs/my-website/docs/proxy/prometheus.md +++ b/docs/my-website/docs/proxy/prometheus.md @@ -182,12 +182,17 @@ Use this for LLM API Error monitoring and tracking remaining rate limits and tok This metric is computed **inside LiteLLM** as `latency_seconds / output_tokens`: -- **Non-streaming requests**: `latency_seconds` is the time from when LiteLLM starts the deployment request to when it receives the final response. -- **Streaming requests**: `latency_seconds` is the **time-to-first-token (TTFT)** (time until LiteLLM receives the first token from the provider). +- **Non-streaming requests**: `latency_seconds` is the time from when LiteLLM + starts the deployment request to when it receives the final response. +- **Streaming requests**: `latency_seconds` is the **time-to-first-token + (TTFT)** (time until LiteLLM receives the first token from the provider). -Because the timer is taken at the LiteLLM boundary, it reflects **provider latency + any LiteLLM proxy overhead** that occurs during that interval (and can include network overhead). +Because the timer is taken at the LiteLLM boundary, it reflects **provider +latency + any LiteLLM proxy overhead** that occurs during that interval (and can +include network overhead). -If you need a metric that targets *just the provider LLM API call latency*, use `litellm_llm_api_latency_metric`. +If you need a metric that targets *just the provider LLM API call latency*, use +`litellm_llm_api_latency_metric`. #### Fallback (Failover) Metrics